Niezawodność w usłudze Load Balancer

Ten artykuł zawiera konkretne zalecenia dotyczące niezawodności usługi Load Balancer, a także szczegółowe informacje na temat regionalnej odporności usługi Load Balancer ze strefamidostępności i odzyskiwaniem po awarii między regionami i ciągłością działania.

Aby zapoznać się z omówieniem niezawodności architektury na platformie Azure, zobacz Niezawodność platformy Azure.

Zalecenia dotyczące niezawodności

Ta sekcja zawiera zalecenia dotyczące uzyskiwania odporności i dostępności. Każde zalecenie należy do jednej z dwóch kategorii:

• Elementy kondycji obejmują obszary, takie jak elementy konfiguracji i właściwa funkcja głównych składników tworzących obciążenie platformy Azure, takie jak ustawienia konfiguracji zasobów platformy Azure, zależności od innych usług itd.

• Elementy ryzyka obejmują obszary, takie jak wymagania dotyczące dostępności i odzyskiwania, testowanie, monitorowanie, wdrażanie i inne elementy, które, jeśli nie zostały rozwiązane, zwiększają szanse na problemy w środowisku.

Macierz priorytetów zaleceń dotyczących niezawodności

Każde zalecenie jest oznaczone zgodnie z następującą macierzą priorytetów:

Obraz	Priorytet	opis
	Maksimum	Wymagana jest natychmiastowa poprawka.
	Średnia	Poprawka w ciągu 3–6 miesięcy.
	Minimum	Należy przejrzeć.

Podsumowanie zaleceń dotyczących niezawodności

Kategoria	Priorytet	Zalecenie
Dostępność		Upewnij się, że usługa Load Balancer w warstwie Standardowa jest strefowo nadmiarowa
		Upewnij się, że pula zaplecza zawiera co najmniej dwa wystąpienia
Wydajność systemu		Używanie bramy translatora adresów sieciowych zamiast reguł ruchu wychodzącego dla obciążeń produkcyjnych
		Korzystanie z jednostki SKU usługa Load Balancer w warstwie Standardowa

Dostępność

Upewnij się, że usługa Load Balancer w warstwie Standardowa jest strefowo nadmiarowa

W regionie obsługującym strefy dostępności należy wdrożyć usługa Load Balancer w warstwie Standardowa z nadmiarowością strefową. Strefowo nadmiarowy moduł równoważenia obciążenia umożliwia obsługiwanie ruchu przez pojedynczy adres IP frontonu, który może przetrwać awarię strefy. Adres IP frontonu może służyć do uzyskiwania dostępu do wszystkich (bez wpływu) elementów członkowskich puli zaplecza niezależnie od strefy. Jeśli strefa dostępności nie powiedzie się, ścieżka danych może przetrwać tak długo, jak pozostałe strefy w regionie pozostaną w dobrej kondycji. Aby uzyskać więcej informacji, zobacz Moduł równoważenia obciążenia strefowo nadmiarowego.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Upewnij się, że pula zaplecza zawiera co najmniej dwa wystąpienia

Wdróż moduł równoważenia obciążenia z co najmniej dwoma wystąpieniami w zapleczu. Pojedyncze wystąpienie może spowodować pojedynczy punkt awarii. Aby utworzyć na potrzeby skalowania, warto sparować moduł równoważenia obciążenia z zestawami skalowania maszyn wirtualnych.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Wydajność systemu

Używanie bramy translatora adresów sieciowych zamiast reguł ruchu wychodzącego dla obciążeń produkcyjnych

Reguły ruchu wychodzącego przydzielają stałe ilości portów SNAT do każdego wystąpienia maszyny wirtualnej w puli zaplecza. Ta metoda alokacji może prowadzić do wyczerpania portów SNAT, zwłaszcza jeśli nierówne wzorce ruchu powodują wysłanie większej liczby połączeń wychodzących przez określoną maszynę wirtualną. W przypadku obciążeń produkcyjnych zaleca się połączenie usługa Load Balancer w warstwie Standardowa lub dowolnego wdrożenia podsieci z usługą Azure NAT Gateway. Brama translatora adresów sieciowych dynamicznie przydziela porty SNAT we wszystkich wystąpieniach maszyn wirtualnych w podsieci i z kolei zmniejsza ryzyko wyczerpania portów SNAT.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Korzystanie z jednostki SKU usługa Load Balancer w warstwie Standardowa

Usługa Load Balancer w warstwie Standardowa obsługuje strefy dostępności i odporność stref, a jednostka SKU w warstwie Podstawowa nie. Gdy strefa ulegnie awarii, strefowo nadmiarowa usługa Load Balancer w warstwie Standardowa nie będzie mieć wpływu, a wdrożenia będą mogły wytrzymać awarie strefy w obrębie regionu. Ponadto usługa Load Balancer w warstwie Standardowa obsługuje równoważenie obciążenia między regionami, aby upewnić się, że aplikacja nie ma wpływu na awarie regionów.

Uwaga

Podstawowe moduły równoważenia obciążenia nie mają umowy dotyczącej poziomu usług (SLA).

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

Obsługa strefy dostępności

Strefy dostępności platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.

Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.

Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Rekomendacje na potrzeby korzystania ze stref dostępności i regionów.

Usługa Azure Load Balancer obsługuje scenariusze stref dostępności. Można użyć usługa Load Balancer w warstwie Standardowa, aby zwiększyć dostępność w całym scenariuszu, dostosowując zasoby do i dystrybucji między strefami. Zapoznaj się z tym dokumentem, aby zrozumieć te pojęcia i podstawowe wskazówki dotyczące projektowania scenariuszy.

Mimo że zaleca się wdrożenie usługi Load Balancer z nadmiarowością stref, moduł równoważenia obciążenia może być strefowo nadmiarowy, strefowy lub nienależące do strefy. Wybór strefy dostępności modułu równoważenia obciążenia jest synonimem wyboru strefy adresu IP frontonu. W przypadku publicznych modułów równoważenia obciążenia, jeśli publiczny adres IP frontonu modułu równoważenia obciążenia jest strefowo nadmiarowy, moduł równoważenia obciążenia jest również strefowo nadmiarowy. Jeśli publiczny adres IP frontonu modułu równoważenia obciążenia jest strefowy, moduł równoważenia obciążenia również zostanie wyznaczony do tej samej strefy. Aby skonfigurować właściwości związane z strefą dla modułu równoważenia obciążenia, wybierz odpowiedni typ wymaganego frontonu.

Uwaga

Nie jest wymagane posiadanie modułu równoważenia obciążenia dla każdej strefy, a nie pojedynczego modułu równoważenia obciążenia z wieloma frontonami (strefowo lub strefowo nadmiarowymi) skojarzonymi z odpowiednimi pulami zaplecza.

Wymagania wstępne

• Aby używać stref dostępności z usługą Load Balancer, musisz utworzyć moduł równoważenia obciążenia w regionie obsługującym strefy dostępności. Aby zobaczyć, które regiony obsługują strefy dostępności, zobacz listę obsługiwanych regionów.

• Użyj jednostki SKU w warstwie Standardowa dla modułu równoważenia obciążenia i publicznego adresu IP w celu obsługi stref dostępności.

• Podstawowy typ jednostki SKU nie jest obsługiwany.

• Aby utworzyć zasób, musisz mieć rolę Współautor sieci lub wyższy.

Ograniczenia

• Strefy nie można zmienić, zaktualizować ani utworzyć dla zasobu po utworzeniu.
• Nie można zaktualizować zasobów z strefowego na strefowo nadmiarowy lub odwrotnie po utworzeniu.

Strefowo nadmiarowy moduł równoważenia obciążenia

W regionie ze strefami dostępności usługa Load Balancer w warstwie Standardowa może być strefowo nadmiarowa z ruchem obsługiwanym przez pojedynczy adres IP. Pojedynczy adres IP frontonu przetrwa awarię strefy. Adres IP frontonu może służyć do uzyskiwania dostępu do wszystkich elementów członkowskich puli zaplecza (bez wpływu) niezależnie od strefy. Maksymalnie jedna strefa dostępności może zakończyć się niepowodzeniem, a ścieżka danych przetrwa tak długo, jak pozostałe strefy w regionie pozostają w dobrej kondycji.

Adres IP frontonu jest obsługiwany jednocześnie przez wiele niezależnych wdrożeń infrastruktury w wielu strefach dostępności. Wszelkie ponawianie prób lub ponowne opublikowanie zakończy się powodzeniem w innych strefach, na które nie ma wpływu awaria strefy.

Uwaga

Maszyny wirtualne 1,2 i 3 mogą należeć do tej samej podsieci i nie muszą znajdować się w oddzielnych strefach jako sugestie diagramu.

Elementy członkowskie w puli zaplecza modułu równoważenia obciążenia są zwykle skojarzone z jedną strefą, taką jak maszyny wirtualne strefowe. Typowym projektem obciążeń produkcyjnych byłoby posiadanie wielu zasobów strefowych. Na przykład umieszczenie maszyn wirtualnych ze strefy 1, 2 i 3 w zapleczu modułu równoważenia obciążenia z frontonem strefowo nadmiarowym spełnia tę zasadę projektowania.

Strefowy moduł równoważenia obciążenia

Można wybrać fronton gwarantowany dla pojedynczej strefy, która jest nazywana strefą. W tym scenariuszu pojedyncza strefa w regionie obsługuje cały przepływ przychodzący lub wychodzący. Fronton dzieli los z kondycją strefy. Ścieżka danych nie ma wpływu na błędy w strefach innych niż gwarantowane. Frontony strefowe umożliwiają uwidocznienie adresu IP dla strefy dostępności.

Ponadto obsługiwane jest używanie frontonów strefowych bezpośrednio dla punktów końcowych ze zrównoważonym obciążeniem w każdej strefie. Za pomocą tej konfiguracji można uwidaczniać punkty końcowe ze zrównoważonym obciążeniem strefy, aby indywidualnie monitorować każdą strefę. W przypadku publicznych punktów końcowych można zintegrować je z produktem równoważenia obciążenia DNS, takimi jak Traffic Manager , i użyć pojedynczej nazwy DNS.

W przypadku publicznego frontonu modułu równoważenia obciążenia należy dodać parametr stref do publicznego adresu IP. Do tego publicznego adresu IP odwołuje się konfiguracja adresu IP frontonu używana przez odpowiednią regułę.

W przypadku wewnętrznego frontonu modułu równoważenia obciążenia dodaj parametr stref do wewnętrznej konfiguracji adresu IP frontonu modułu równoważenia obciążenia. Fronton strefowy gwarantuje adres IP w podsieci do określonej strefy.

Moduł równoważenia obciążenia bez stref

Moduły równoważenia obciążenia można również utworzyć w konfiguracji niezwiązanej z strefą przy użyciu frontonu "bez strefy". W tych scenariuszach publiczny moduł równoważenia obciążenia używa publicznego adresu IP lub publicznego prefiksu adresu IP, wewnętrzny moduł równoważenia obciążenia będzie używać prywatnego adresu IP. Ta opcja nie daje gwarancji nadmiarowości.

Uwaga

Wszystkie publiczne adresy IP uaktualnione z jednostki SKU w warstwie Podstawowa do jednostki SKU w warstwie Standardowa będą typu "brak strefy". Dowiedz się, jak uaktualnić publiczny adres IP w witrynie Azure Portal.

Ulepszenia umowy SLA

Ponieważ strefy dostępności są fizycznie oddzielne i zapewniają różne źródła zasilania, sieć i chłodzenie, umowy SLA (umowy dotyczące poziomu usług) mogą wzrosnąć. Aby uzyskać więcej informacji, zobacz Umowy dotyczące poziomu usług (SLA) dla usług online.

Tworzenie zasobu z włączoną strefą dostępności

Aby dowiedzieć się, jak równoważyć obciążenie maszyn wirtualnych w strefie lub w wielu strefach przy użyciu modułu równoważenia obciążenia, zobacz Szybki start: tworzenie publicznego modułu równoważenia obciążenia w celu równoważenia obciążenia maszyn wirtualnych.

Uwaga

• Strefy nie można zmienić, zaktualizować ani utworzyć dla zasobu po utworzeniu.
• Nie można zaktualizować zasobów z strefowego na strefowo nadmiarowy lub odwrotnie po utworzeniu.

Odporność na uszkodzenia

Maszyny wirtualne mogą przejść w tryb failover na inny serwer w klastrze, a system operacyjny maszyny wirtualnej zostanie uruchomiony ponownie na nowym serwerze. Należy zapoznać się z procesem przechodzenia w tryb failover na potrzeby odzyskiwania po awarii, zbierania maszyn wirtualnych w planowaniu odzyskiwania i uruchamiania próbnego odzyskiwania po awarii, aby zapewnić pomyślne rozwiązanie odporności na uszkodzenia.

Aby uzyskać więcej informacji, zobacz procesy odzyskiwania lokacji.

Środowisko strefowe w dół

Nadmiarowość strefy nie oznacza bez trafienia płaszczyzny danych ani płaszczyzny sterowania. Przepływy strefowo nadmiarowe mogą używać dowolnej strefy, a przepływy będą używać wszystkich stref w dobrej kondycji w regionie. W przypadku awarii strefy przepływy ruchu korzystające ze stref w dobrej kondycji nie mają wpływu.

Może to mieć wpływ na przepływy ruchu korzystające ze strefy w czasie awarii strefy, ale aplikacje mogą odzyskiwać dane. Ruch w strefach w dobrej kondycji w regionie jest kontynuowany po ponownym przetransmisji, gdy platforma Azure zbiegła się z awarią strefy.

Przejrzyj wzorce projektowe chmury platformy Azure, aby poprawić odporność aplikacji na scenariusze awarii.

Wiele frontonów

Użycie wielu frontonów umożliwia równoważenie obciążenia ruchu na więcej niż jednym porcie i/lub adresie IP. Podczas projektowania architektury upewnij się, że uwzględniasz sposób interakcji nadmiarowości stref z wieloma frontonami. Jeśli twoim celem jest zawsze posiadanie każdej frontonu odpornej na awarię, wszystkie adresy IP przypisane jako frontony muszą być strefowo nadmiarowe. Jeśli zestaw frontonów ma być skojarzony z jedną strefą, każdy adres IP tego zestawu musi być skojarzony z tą określoną strefą. Moduł równoważenia obciążenia nie jest wymagany w każdej strefie. Zamiast tego każdy fronton strefowy lub zestaw frontonów strefowych może być skojarzony z maszynami wirtualnymi w puli zaplecza, które są częścią tej konkretnej strefy dostępności.

Sejf technik wdrażania

Przejrzyj wzorce projektowe chmury platformy Azure, aby poprawić odporność aplikacji na scenariusze awarii.

Migrowanie do obsługi strefy dostępności

W przypadku rozszerzenia regionu w celu uzyskania stref dostępności wszystkie istniejące adresy IP pozostaną nienależące do stref, tak jak adresy IP używane na potrzeby frontonów modułu równoważenia obciążenia. Aby zapewnić, że architektura może korzystać z nowych stref, zaleca się utworzenie nowego adresu IP frontonu. Po utworzeniu można zastąpić istniejący fronton nienależące do strefy nowym frontonem strefowo nadmiarowym. Aby dowiedzieć się, jak przeprowadzić migrację maszyny wirtualnej do obsługi stref dostępności, zobacz Migrowanie modułu równoważenia obciążenia do obsługi stref dostępności.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii dotyczy odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Rekomendacje na potrzeby projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania planu odzyskiwania po awarii.

Usługa Azure usługa Load Balancer w warstwie Standardowa obsługuje równoważenie obciążenia między regionami, umożliwiając scenariusze wysokiej dostępności geograficznie nadmiarowej, takie jak:

• Ruch przychodzący pochodzący z wielu regionów.
• Natychmiastowe globalne przejście w tryb failover do następnego optymalnego wdrożenia regionalnego.
• Załaduj dystrybucję między regionami w najbliższym regionie świadczenia usługi Azure z bardzo małym opóźnieniem.
• Możliwość skalowania w górę/w dół za jednym punktem końcowym.
• Statyczny globalny adres IP emisji
• Zachowywanie adresów IP klienta
• Tworzenie istniejącego rozwiązania modułu równoważenia obciążenia bez krzywej uczenia

Konfiguracja adresu IP frontonu modułu równoważenia obciążenia między regionami jest statyczna i anonsowana w większości regionów świadczenia usługi Azure.

Uwaga

Port zaplecza reguły równoważenia obciążenia w module równoważenia obciążenia między regionami powinien być zgodny z portem frontonu reguły równoważenia obciążenia/reguły nat dla ruchu przychodzącego w regionalnym standardowym module równoważenia obciążenia.

Odzyskiwanie po awarii w lokalizacji geograficznej obejmującej wiele regionów

Nadmiarowość regionalna

Skonfiguruj nadmiarowość regionalną, bezproblemowo łącząc moduł równoważenia obciążenia między regionami z istniejącymi regionalnymi modułami równoważenia obciążenia.

Jeśli jeden region ulegnie awarii, ruch jest kierowany do najbliższego najbliższego regionalnego modułu równoważenia obciążenia w dobrej kondycji.

Sonda kondycji modułu równoważenia obciążenia między regionami zbiera informacje o dostępności każdego regionalnego modułu równoważenia obciążenia co 5 sekund. Jeśli jeden regionalny moduł równoważenia obciążenia spadnie jego dostępność do 0, moduł równoważenia obciążenia między regionami wykryje błąd. Regionalny moduł równoważenia obciążenia jest następnie wyjęty z rotacji.

Bardzo małe opóźnienie

Algorytm równoważenia obciążenia w pobliżu geograficznym opiera się na lokalizacji geograficznej użytkowników i wdrożeń regionalnych.

Ruch rozpoczęty od klienta trafia do najbliższego regionu uczestniczącego i przechodzi przez sieć szkieletową sieci globalnej firmy Microsoft, aby dotrzeć do najbliższego wdrożenia regionalnego.

Na przykład masz moduł równoważenia obciążenia między regionami ze standardowymi modułami równoważenia obciążenia w regionach świadczenia usługi Azure:

• Zachodnie stany USA
• Europa Północna

Jeśli przepływ jest uruchamiany z Seattle, ruch przechodzi do zachodnich stanów USA. Ten region jest najbliższym regionem uczestniczącym z Seattle. Ruch jest kierowany do najbliższego modułu równoważenia obciążenia regionu, który to Zachodnie stany USA.

Moduł równoważenia obciążenia między regionami platformy Azure używa algorytmu równoważenia obciążenia w odległości geograficznej do podejmowania decyzji o routingu.

Skonfigurowany tryb dystrybucji obciążenia regionalnych modułów równoważenia obciążenia jest używany do podejmowania ostatecznej decyzji o routingu, gdy wiele regionalnych modułów równoważenia obciążenia jest używanych na potrzeby sąsiedztwa geograficznego.

Aby uzyskać więcej informacji, zobacz Konfigurowanie trybu dystrybucji dla usługi Azure Load Balancer.

Ruch wychodzący jest zgodny z preferencjami routingu ustawionymi w regionalnych modułach równoważenia obciążenia.

Możliwość skalowania w górę/w dół za jednym punktem końcowym

Gdy uwidaczniasz globalny punkt końcowy modułu równoważenia obciążenia między regionami klientom, możesz dodawać lub usuwać wdrożenia regionalne za globalnym punktem końcowym bez przerwy.

Statyczny globalny adres IP emisji

Moduł równoważenia obciążenia między regionami jest dostarczany ze statycznym publicznym adresem IP, co gwarantuje, że adres IP pozostanie taki sam. Aby dowiedzieć się więcej o statycznym adresie IP, przeczytaj więcej tutaj

Zachowywanie adresów IP klienta

Moduł równoważenia obciążenia między regionami to moduł równoważenia obciążenia sieciowego w warstwie 4. To przekazywanie zachowuje oryginalny adres IP pakietu. Oryginalny adres IP jest dostępny dla kodu uruchomionego na maszynie wirtualnej. Dzięki temu można zastosować logikę specyficzną dla adresu IP.

Pływający adres IP

Pływający adres IP można skonfigurować zarówno na poziomie globalnego adresu IP, jak i na poziomie regionalnego adresu IP. Aby uzyskać więcej informacji, odwiedź stronę Wiele frontonów dla usługi Azure Load Balancer

Należy pamiętać, że zmienny adres IP skonfigurowany w usłudze Load Balancer między regionami platformy Azure działa niezależnie od pływających konfiguracji adresów IP w regionalnych modułach równoważenia obciążenia zaplecza. Jeśli pływający adres IP jest włączony w module równoważenia obciążenia między regionami, odpowiedni interfejs sprzężenia zwrotnego musi zostać dodany do maszyn wirtualnych zaplecza.

Sondy kondycji

Usługa Load Balancer między regionami platformy Azure korzysta ze kondycji regionalnych modułów równoważenia obciążenia zaplecza podczas podejmowania decyzji o tym, gdzie dystrybuować ruch. Sprawdzanie kondycji przez moduł równoważenia obciążenia między regionami odbywa się automatycznie co 5 sekund, biorąc pod uwagę, że użytkownik skonfigurował sondy kondycji w regionalnym module równoważenia obciążenia.

Tworzenie rozwiązania między regionami w istniejącej usłudze Azure Load Balancer

Pula zaplecza modułu równoważenia obciążenia między regionami zawiera co najmniej jeden regionalny moduł równoważenia obciążenia.

Dodaj istniejące wdrożenia modułu równoważenia obciążenia do modułu równoważenia obciążenia między regionami w celu wdrożenia o wysokiej dostępności między regionami.

Region główny to miejsce , w którym wdrożono moduł równoważenia obciążenia między regionami lub publiczny adres IP warstwy globalnej. Ten region nie ma wpływu na sposób kierowania ruchu. Jeśli region macierzysny ulegnie awarii, nie będzie to miało wpływu na przepływ ruchu.

Regiony główne

• Central US
• Azja Wschodnia
• Wschodnie stany USA 2
• Europa Północna
• Southeast Asia
• Południowe Zjednoczone Królestwo
• US Gov Wirginia
• West Europe
• Zachodnie stany USA

Uwaga

Moduł równoważenia obciążenia między regionami lub publiczny adres IP można wdrożyć tylko w warstwie globalnej w jednym z wymienionych regionów strony głównej.

Region uczestniczący to miejsce, w którym anonsowany jest globalny publiczny adres IP modułu równoważenia obciążenia.

Ruch uruchamiany przez użytkownika przechodzi do najbliższego regionu uczestniczącego za pośrednictwem sieci podstawowej firmy Microsoft.

Moduł równoważenia obciążenia między regionami kieruje ruch do odpowiedniego regionalnego modułu równoważenia obciążenia.

Regiony uczestniczące

• Australia Wschodnia
• Australia Południowo-Wschodnia
• Indie Środkowe
• Central US
• Azja Wschodnia
• East US
• Wschodnie stany USA 2
• Japonia Wschodnia
• Północno-środkowe stany USA
• Europa Północna
• South Central US
• Southeast Asia
• Południowe Zjednoczone Królestwo
• US DoD (region środkowy)
• US DoD (region wschodni)
• US Gov Arizona
• US Gov Teksas
• US Gov Wirginia
• Zachodnio-środkowe stany USA
• West Europe
• Zachodnie stany USA
• Zachodnie stany USA 2

Uwaga

Regionalne moduły równoważenia obciążenia zaplecza można wdrożyć w dowolnym publicznie dostępnym regionie świadczenia usługi Azure i nie jest ograniczone tylko do regionów uczestniczących.

Ograniczenia

• Konfiguracje adresów IP frontonu między regionami są tylko publiczne. Wewnętrzny fronton nie jest obecnie obsługiwany.

• Nie można dodać prywatnego lub wewnętrznego modułu równoważenia obciążenia do puli zaplecza modułu równoważenia obciążenia między regionami

• Tłumaczenie NAT64 nie jest obecnie obsługiwane. Adresy IP frontonu i zaplecza muszą być tego samego typu (wersja 4 lub v6).

• Ruch UDP nie jest obsługiwany w module równoważenia obciążenia między regionami dla protokołu IPv6.

• Ruch UDP na porcie 3 nie jest obsługiwany w usłudze Load Balancer między regionami

• Reguły ruchu wychodzącego nie są obsługiwane w module równoważenia obciążenia między regionami. W przypadku połączeń wychodzących użyj reguł ruchu wychodzącego w regionalnym module równoważenia obciążenia lub bramie translatora adresów sieciowych.

Cennik i umowy SLA

Moduł równoważenia obciążenia między regionami udostępnia umowę SLA modułu równoważenia obciążenia w warstwie Standardowa.

Następne kroki

• Niezawodność na platformie Azure
• Zobacz Samouczek: tworzenie modułu równoważenia obciążenia między regionami przy użyciu witryny Azure Portal w celu utworzenia modułu równoważenia obciążenia między regionami.
• Dowiedz się więcej na temat modułu równoważenia obciążenia między regionami.
• Dowiedz się więcej o usłudze Azure Load Balancer.