Zuverlässigkeit in Load Balancer

Dieser Artikel enthält spezifische Zuverlässigkeitsempfehlungen für Load Balancer sowie detaillierte Informationen zur regionalen Load Balancer-Resilienz mit Verfügbarkeitszonen sowie zur regionsübergreifenden Notfallwiederherstellung und Geschäftskontinuität.

Eine Übersicht über die Architektur der Zuverlässigkeit in Azure finden Sie unter Zuverlässigkeit in Azure.

Zuverlässigkeitsempfehlungen

Dieser Abschnitt enthält Empfehlungen für das Erreichen von Resilienz und Verfügbarkeit. Jede Empfehlung fällt in eine von zwei Kategorien:

• Integritätselemente umfassen Bereiche wie Konfigurationselemente und die ordnungsgemäße Funktion der Hauptkomponenten, aus denen Ihr Azure-Workload besteht, wie z. B. Konfigurationseinstellungen der Azure-Ressourcen oder Abhängigkeiten von anderen Diensten.

• Risikoelemente umfassen Bereiche wie Verfügbarkeits- und Wiederherstellungsanforderungen, Tests, Überwachung, Bereitstellung und andere Elemente, die die Wahrscheinlichkeit von Problemen in der Umgebung erhöhen, wenn sie nicht gelöst werden.

Prioritätsmatrix der Zuverlässigkeitsempfehlungen

Jede Empfehlung wird gemäß der folgenden Prioritätsmatrix gekennzeichnet:

Image	Priority	BESCHREIBUNG
	High	Sofortige Korrektur erforderlich.
	Mittel	Korrektur innerhalb von 3-6 Monaten.
	Niedrig	Muss überprüft werden.

Zusammenfassung der Zuverlässigkeitsempfehlungen

Category	Priority	Empfehlung
Verfügbarkeit		Sicherstellen, dass Load Balancer Standard zonenredundant ist
		Sicherstellen, dass der Back-End-Pool mindestens zwei Instanzen enthält
Systemeffizienz		Verwenden des NAT Gateways anstelle von Ausgangsregeln für Produktionsworkloads
		Verwenden der Load Balancer Standard-SKU

Verfügbarkeit

Sicherstellen, dass Load Balancer Standard zonenredundant ist

In einer Region, die Verfügbarkeitszonen unterstützt, sollte Load Balancer Standard mit Zonenredundanz bereitgestellt werden. Ein zonenredundanter Load Balancer ermöglicht die Zustellung des Datenverkehrs durch eine einzelne Front-End-IP-Adresse, die einen Zonenausfall überstehen kann. Die Front-End-IP kann verwendet werden, um alle (nicht betroffenen) Back-End-Poolmitglieder unabhängig von der Zone zu erreichen. Wenn eine Verfügbarkeitszone fehlschlägt, kann der Datenpfad bestehen bleiben, solange die verbleibenden Zonen in der Region fehlerfrei bleiben. Weitere Informationen Sie unter Zonenredundanter Load Balancer.

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)

Sicherstellen, dass der Back-End-Pool mindestens zwei Instanzen enthält

Stellen Sie Load Balancer mit mindestens zwei Instanzen im Back-End bereit. Wenn Sie nur eine einzige Instanz bereitstellen, kann ein Single Point of Failure entstehen. Es empfiehlt sich im Hinblick auf eine Ausbaureserve, Load Balancer mit Virtual Machine Scale Sets zu koppeln.

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)

Systemeffizienz

Verwenden des NAT Gateways anstelle von Ausgangsregeln für Produktionsworkloads

Ausgangsregeln ordnen jeder virtuellen Computerinstanz in einem Back-End-Pool eine feste Menge von SNAT-Ports zu. Diese Methode der Zuordnung kann zu SNAT-Portauslastung führen, insbesondere wenn ungleichmäßige Datenverkehrsmuster dazu führen, dass ein bestimmter virtueller Computer ein höheres Volumen von ausgehenden Verbindungen sendet. Für Produktionsworkloads wird empfohlen, Load Balancer Standard oder eine Subnetzbereitstellung mit Azure NAT Gateway zu koppeln. NAT Gateway weist SNAT-Ports dynamisch allen Instanzen virtueller Computer in einem Subnetz zu und reduziert wiederum das Risiko der SNAT-Portauslastung.

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"

Verwenden der Load Balancer Standard-SKU

Die Load Balancer Standard-SKU unterstützt Verfügbarkeitszonen und Zonenresilienz, die Basic-SKU jedoch nicht. Wenn eine Zone ausfällt, wird ihr zonenredundanter Load Balancer Standard nicht beeinträchtigt, und Ihre Bereitstellungen können Zonenfehlern innerhalb einer Region standhalten. Darüber hinaus unterstützt Load Balancer Standard den zonenübergreifenden Lastenausgleich, um sicherzustellen, dass Ihre Anwendung nicht von Regionsausfällen betroffen ist.

Hinweis

Für Basic-Lastenausgleichsmodule gilt keine Vereinbarung zum Servicelevel (Service Level Agreement, 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")

Unterstützung für Verfügbarkeitszonen

Azure-Verfügbarkeitszonen sind mindestens drei physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Die Rechenzentren innerhalb jeder Zone sind mit unabhängiger Stromversorgung, Kühlung und Netzwerkinfrastruktur ausgestattet. Bei einem Fehler in der lokalen Zone sind Verfügbarkeitszonen so konzipiert, dass regionale Dienste, Kapazität und Hochverfügbarkeit von den verbleibenden beiden Zonen unterstützt werden, wenn eine Zone betroffen ist.

Ausfälle können von Software- und Hardwareausfällen bis hin zu Ereignissen wie Erdbeben, Überflutungen und Bränden reichen. Fehlertoleranz wird durch Redundanz und logische Isolierung von Azure-Diensten erreicht. Ausführlichere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Regionen und Verfügbarkeitszonen.

Azure-Dienste mit Unterstützung von Verfügbarkeitszonen bieten das richtige Maß an Zuverlässigkeit und Flexibilität. Für die Konfiguration gibt es zwei Möglichkeiten. Sie können entweder zonenredundant mit automatischer zonenübergreifender Replikation oder zonenbasiert mit Instanzen sein, die an eine bestimmte Zone angeheftet werden. Sie können diese Ansätze auch kombinieren. Weitere Informationen zur zonalen im Vergleich zur zonenredundanten Architektur finden Sie unter Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen.

Azure Load Balancer unterstützt Szenarien mit Verfügbarkeitszonen. Sie können Load Balancer Standard verwenden, um die Verfügbarkeit im gesamten Szenario zu erhöhen, indem Sie Ressourcen an Zonen ausrichten und die Verteilung zonenübergreifend ausführen. Lesen Sie dieses Dokument, um diese Konzepte und die Entwurfsanleitung für das grundlegende Szenario zu verstehen.

Obwohl empfohlen wird, Load Balancer mit Zonenredundanz bereitzustellen, kann ein Load Balancer entweder zonenredundant, zonal oder nicht zonal sein. Die Auswahl der Verfügbarkeitszone des Lastenausgleichs ist gleichbedeutend mit der Zonenauswahl der Front-End-IP. Wenn bei öffentlichen Lastenausgleichen die öffentliche IP-Adresse im Front-End des Lastenausgleichs zonenredundant ist, ist auch der Lastenausgleich zonenredundant. Wenn die öffentliche IP-Adresse im Front-End des Lastenausgleichs zonal ist, wird der Lastenausgleich auch für dieselbe Zone festgelegt. Um die Zoneneigenschaften für den Load Balancer zu konfigurieren, wählen Sie den entsprechenden Typ des erforderlichen Frontends aus.

Hinweis

Es ist nicht erforderlich, für jede Zone einen Lastenausgleich zu haben. Stattdessen erfüllt ein einziger Lastenausgleich mit mehreren Front-Ends (zonal oder zonenredundant), die ihren jeweiligen Back-End-Pools zugeordnet sind, den Zweck.

Voraussetzungen

• Um Verfügbarkeitszonen mit Load Balancer zu verwenden, müssen Sie Ihr Lastenausgleichsmodul in einer Region erstellen, die Verfügbarkeitszonen unterstützt. Informationen dazu, welche Regionen Verfügbarkeitszonen unterstützen, finden Sie in der Liste der unterstützten Regionen.

• Verwenden Sie Standard-SKU für den Lastenausgleich und öffentliche IP-Adressen für Verfügbarkeitszonenunterstützung.

• Der SKU-Typ „Basic“ wird nicht unterstützt.

• Um Ihre Ressource zu erstellen, müssen Sie über die Rolle „Netzwerkmitwirkender“ oder höher verfügen.

Begrenzungen

• Zonen können nach der Erstellung nicht geändert, aktualisiert oder für die Ressource erstellt werden.
• Nach der Erstellung kann für Ressourcen kein Update von der zonalen auf die zonenredundante Einstellung oder umgekehrt ausgeführt werden.

Zonenredundanter Load Balancer

In einer Region mit Verfügbarkeitszonen kann ein Load Balancer Standard zonenredundant sein, da Datenverkehr von einer einzelnen IP-Adresse bereitgestellt wird. Eine einzelne Frontend-IP-Adresse übersteht einen Zonenfehler. Die Front-End-IP kann verwendet werden, um alle (nicht betroffenen) Back-End-Poolmitglieder unabhängig von der Zone zu erreichen. Bis zu eine Verfügbarkeitszone kann fehlschlagen, und der Datenpfad bleibt bestehen, solange die verbleibenden Zonen in der Region fehlerfrei bleiben.

Die IP-Adresse des Front-Ends wird gleichzeitig durch mehrere unabhängige Infrastrukturbereitstellungen in mehreren Verfügbarkeitszonen bereitgestellt. Alle Wiederholungen oder Wiederherstellungen sind in anderen Zonen erfolgreich, die nicht von dem Zonenausfall betroffen sind.

Hinweis

VMs 1, 2 und 3 können zum gleichen Subnetz gehören und müssen sich nicht unbedingt in separaten Zonen befinden, wie die Diagrammvorschläge.

Die Mitglieder im Back-End-Pool eines Lastenausgleichs sind normalerweise einer einzelnen Zone zugeordnet, wie z. B. bei zonengebundenen VMs. Ein üblicher Entwurf für Produktionsworkloads besteht in der Verwendung mehrerer Zonenressourcen. Wenn Sie beispielsweise VMs aus den Zonen 1, 2 und 3 im Back-End eines Lastenausgleichs mit einem zonenredundanten Front-End platzieren, entspricht das diesem Entwurfsprinzip.

Zonales Lastenausgleichsmodul

Sie können festlegen, dass ein Front-End einer einzelnen Zone zugesichert wird. Das Front-End wird dann als zonales Front-End bezeichnet. In diesem Szenario dient eine einzelne Zone in einer Region dem gesamten eingehenden oder ausgehenden Datenfluss. Ihr Front-End ist von der Integrität der Zone abhängig. Der Datenpfad ist nicht betroffen von Fehlern in Zonen, in denen er nicht zugesichert wurde. Mit zonalen Front-Ends können Sie eine IP-Adresse pro Verfügbarkeitszone verfügbar machen.

Darüber hinaus wird die Verwendung zonaler Front-Ends direkt für Endpunkte mit Lastenausgleich innerhalb der einzelnen Zonen unterstützt. Sie können diese Konfiguration verwenden, um pro Zone Lastenausgleichsendpunkte zur individuellen Überwachung jeder Zone verfügbar zu machen. Bei öffentlichen Endpunkten können Sie sie mit einem DNS-Lastenausgleichsprodukt wie Traffic Manager kombinieren und einen einzelnen DNS-Namen verwenden.

Für ein öffentliches Load Balancer-Front-End fügen Sie der öffentlichen IP-Adresse einen zones-Parameter hinzu. Auf diese öffentliche IP-Adresse wird von der Front-End-IP-Konfiguration verwiesen, die von der jeweiligen Regel verwendet wird.

Für ein internes Load Balancer-Front-End fügen Sie der internen Load Balancer-Front-End-IP-Konfiguration einen zones-Parameter hinzu. Ein zonales Front-End sichert eine IP-Adresse in einem Subnetz für eine bestimmte Zone zu.

Nicht zonales Lastenausgleichsmodul

Lastenausgleichsmodule können auch in einer nicht zonenbasierten Konfiguration erstellt werden, indem Sie ein Front-End ohne Zone verwenden. In diesen Szenarien würde ein öffentlicher Lastenausgleich eine öffentliche IP-Adresse oder ein öffentliches IP-Präfix verwenden, während ein interner Lastenausgleich eine private IP-Adresse nutzen würde. Diese Option bietet keine Garantie für Redundanz.

Hinweis

Alle öffentlichen IP-Adressen, für die ein Upgrade von der Basic-SKU auf die Standard-SKU durchgeführt wird, sind dem Typ „Keine Zone“ zugeordnet. Erfahren Sie mehr über das Durchführen eines Upgrades für eine öffentliche IP-Adresse mithilfe des Azure-Portals.

SLA-Verbesserungen

Da Verfügbarkeitszonen physisch getrennt sind und unterschiedliche Stromquellen, Netzwerke und Kühlung bieten, können sich SLAs (Service-Level Agreements, Vereinbarungen zum Servicelevel) erhöhen. Weitere Informationen finden Sie unter Service Level Agreements (SLA) for Online Services (Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) für Onlinedienste).

Erstellen einer Ressource mit aktivierter Verfügbarkeitszone

Informationen zum Lastenausgleich von VMs innerhalb einer Zone oder über mehrere Zonen mithilfe eines Load Balancer finden Sie unter Schnellstart: Erstellen eines öffentlichen Lastenausgleichs zum Lastenausgleich von VMs.

Hinweis

• Zonen können nach der Erstellung nicht geändert, aktualisiert oder für die Ressource erstellt werden.
• Nach der Erstellung kann für Ressourcen kein Update von der zonalen auf die zonenredundante Einstellung oder umgekehrt ausgeführt werden.

Fehlertoleranz

Für VMs kann ein Failover auf einen anderen Server in einem Cluster ausgeführt werden, wobei das Betriebssystem der VM auf dem neuen Server neu gestartet wird. Sie sollten den Failoverprozess für die Notfallwiederherstellung heranziehen, VMs in der Wiederherstellungsplanung einbeziehen und Notfallwiederherstellungsübungen durchführen, um sicherzustellen, dass ihre Fehlertoleranzlösung erfolgreich ist.

Weitere Informationen finden Sie unter Prozesse für die Sitewiederherstellung.

Zonenausfall

Zonenredundanz impliziert weder eine störungsfreie Datenebene noch eine störungsfreie Steuerebene. Zonenredundante Datenströme können alle Zonen verwenden, und Ihre Datenströme verwenden alle fehlerfreien Zonen in einer Region. Bei einem Zonenfehler sind Datenströme, die fehlerfreie Zonen verwenden, nicht betroffen.

Datenströme, die zum Zeitpunkt des Zonenausfalls eine Zone verwenden, können beeinträchtigt werden, aber Anwendungen können wiederhergestellt werden. Der Datenverkehr wird in den fehlerfreien Zonen innerhalb der Region nach nochmaliger Übertragung fortgesetzt, wenn Azure den Zonenausfall in den Griff bekommen hat.

Informationen zur Verbesserung der Resilienz Ihrer Anwendung in Ausfallszenarien finden Sie unter Cloudentwurfsmuster.

Mehrere Front-Ends

Mithilfe mehrerer Front-Ends können Sie einen Lastenausgleich für Datenverkehr auf mehrere Ports und/oder IP-Adressen ermöglichen. Achten Sie beim Entwurf Ihrer Architektur auf das Zusammenspiel der Zonenredundanz mit mehreren Front-Ends. Wenn Ihr Ziel darin besteht, dass jedes Front-End jederzeit ausfallsicher ist, dann müssen alle als Front-Ends zugewiesenen IP-Adressen zonenredundant sein. Wenn eine Gruppe von Front-Ends einer einzelnen Zone zugeordnet werden soll, muss jede IP-Adresse für diese Gruppe dieser spezifischen Zone zugeordnet werden. Ein Lastenausgleich wird nicht in jeder Zone benötigt. Stattdessen kann jedes Zonen-Front-End bzw. jede Gruppe von Zonen-Front-Ends mit VMs im Back-End-Pool verknüpft werden, die der jeweiligen Verfügbarkeitszone angehören.

Sichere Bereitstellungsverfahren

Informationen zur Verbesserung der Resilienz Ihrer Anwendung in Ausfallszenarien finden Sie unter Cloudentwurfsmuster.

Unterstützung für das Migrieren zu Verfügbarkeitszonen

Wenn eine Region um Verfügbarkeitszonen erweitert wird, sind alle vorhandenen IP-Adressen weiterhin nicht zonengebunden, wie zum Beispiel IP-Adressen, die für Front-Ends zum Lastenausgleich genutzt werden. Damit Ihre Architektur die Vorteile der neuen Zonen nutzen kann, wird empfohlen, dass Sie eine neue Front-End-IP-Adresse erstellen. Nach der Erstellung können Sie das vorhandene nicht zonale Front-End durch ein neues zonenredundantes Front-End ersetzen. Informationen zum Migrieren einer VM zur Unterstützung von Verfügbarkeitszonen finden Sie unter Migrieren von Load Balancer zur Unterstützung von Verfügbarkeitszonen.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.

Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.

Azure Load Balancer Standard unterstützt regionsübergreifenden Lastenausgleich, wodurch georedundante Hochverfügbarkeitsszenarien ermöglicht werden, beispielsweise:

• Eingehender Datenverkehr aus mehreren Regionen.
• Sofortiges globales Failover zur nächsten optimalen regionalen Bereitstellung.
• Regionsübergreifende Lastverteilung in die nächstgelegene Azure-Region mit extrem geringer Latenz.
• Möglichkeit, hinter einem einzelnen Endpunkt zentral hoch- oder herunterzuskalieren.
• Statische globale Anycast-IP-Adresse
• Client-IP-Beibehaltung
• Aufbauen auf vorhandener Lastenausgleichslösung ohne Lernkurve

Die Front-End-IP-Konfiguration Ihres regionsübergreifenden Lastenausgleichs ist statisch und wird in den meisten Azure-Regionen angekündigt.

Hinweis

Der Back-End-Port Ihrer Lastenausgleichsregel für den regionsübergreifenden Lastenausgleich muss mit dem Front-End-Port der Lastenausgleichsregel/NAT-Regel für eingehenden Datenverkehr für den regionalen Standardlastenausgleich identisch sein.

Notfallwiederherstellung für mehrere Regionen

Regionale Redundanz

Konfigurieren Sie regionale Redundanz, indem Sie einen regionsübergreifenden Lastenausgleich nahtlos mit Ihrem vorhandenen regionalen Lastenausgleich verknüpfen.

Wenn eine Region ausfällt, wird der Datenverkehr an den nächstgelegenen fehlerfreien Lastenausgleich weitergeleitet.

Der Integritätstest des regionsübergreifenden Lastenausgleichs erfasst alle 5 Sekunden Informationen zur Verfügbarkeit der einzelnen regionalen Lastenausgleichsmodule. Wenn die Verfügbarkeit eines regionalen Lastenausgleichs auf 0 sinkt, erkennt der regionsübergreifende Lastenausgleich den Ausfall. Der regionale Lastenausgleich wird dann von der Rotation ausgenommen.

Extrem geringe Latenz

Der Lastenausgleichsalgorithmus für geografische Nähe basiert auf dem geografischen Standort Ihrer Benutzer und Ihren regionalen Bereitstellungen.

Der von einem Client gestartete Datenverkehr erreicht die nächstgelegene Region und durchläuft den globalen Microsoft-Netzwerkbackbone, um die nächstgelegene regionale Bereitstellung zu erreichen.

Beispielsweise verfügen Sie über einen regionsübergreifenden Lastenausgleich mit Standard-Lastenausgleichsmodule in Azure-Regionen:

• USA (Westen)
• Nordeuropa

Wenn Datenverkehr in Seattle gestartet wird, durchläuft er die Region „USA, Westen“. Diese Region ist die Seattle nächstgelegene teilnehmende Region. Der Datenverkehr wird an den nächstgelegenen Regionslastenausgleich weitergeleitet, d. h. an „USA, Westen“.

Der regionsübergreifende Azure-Lastenausgleich verwendet den Lastenausgleichsalgorithmus für geografische Nähe für die Routingentscheidung.

Der konfigurierte Lastenverteilungsmodus des regionalen Lastenausgleichsmoduls wird verwendet, um die endgültige Routingentscheidung zu treffen, wenn mehrere regionale Lastenausgleichsmodule für geografische Nähe verwendet werden.

Weitere Informationen finden Sie unter Konfigurieren des Verteilungsmodus für Azure Load Balancer.

Der ausgehende Datenverkehr erfolgt nach der Routingpräferenz, die für die regionalen Lastenausgleichsmodule festgelegt wurde.

Möglichkeit, hinter einem einzelnen Endpunkt zentral hoch- oder herunterzuskalieren

Wenn Sie den globalen Endpunkt eines regionsübergreifenden Lastenausgleichs für Kunden verfügbar machen, können Sie regionale Bereitstellungen hinter dem globalen Endpunkt ohne Unterbrechung hinzufügen oder entfernen.

Statische globale Anycast-IP-Adresse

Der regionsübergreifende Lastenausgleich verfügt über eine statische öffentliche IP-Adresse, wodurch sichergestellt wird, dass die IP-Adresse unverändert bleibt. Weitere Informationen zu statischen IP-Adressen finden Sie hier.

Client-IP-Beibehaltung

Der regionsübergreifende Lastenausgleich ist ein Layer-4-Passthrough-Netzwerklastenausgleich. Dieses Passthrough-Verfahren behält die ursprüngliche IP-Adresse des Pakets bei. Die ursprüngliche IP-Adresse ist für den Code verfügbar, der auf dem virtuellen Computer ausgeführt wird. Diese Beibehaltung ermöglicht Ihnen das Anwenden von Programmlogik, die für eine IP-Adresse spezifisch ist.

Unverankerte IP

Floating IP kann sowohl auf globaler IP-Adressenebene als auch auf regionaler IP-Adressenebene konfiguriert werden. Weitere Informationen finden Sie unter Mehrere Front-Ends für Azure Load Balancer.

Es ist wichtig zu beachten, dass die für den regionsübergreifenden Azure-Load Balancer konfigurierte Floating IP unabhängig von Floating IP-Konfigurationen auf regionalen Back-End-Lastenausgleichsmodulen funktioniert. Wenn Floating IP auf dem regionsübergreifenden Lastenausgleich aktiviert ist, muss die entsprechende Loopback-Schnittstelle den Back-End-VMs hinzugefügt werden.

Integritätstests

Der regionsübergreifende Azure Load Balancer nutzt die Integrität der regionalen Lastenausgleichsmodule des Back-Ends bei der Entscheidung, wie Datenverkehr verteilt werden soll. Integritätsprüfungen durch den regionsübergreifenden Lastenausgleich werden automatisch alle 5 Sekunden durchgeführt, sofern der Benutzer/die Benutzerin Integritätstests für den regionalen Lastenausgleich eingerichtet hat.

Erstellen einer regionsübergreifenden Lösung für einen vorhandenem Azure Load Balancer

Der Back-End-Pool des regionsübergreifenden Lastenausgleichs enthält mindestens einen regionalen Lastenausgleich.

Fügen Sie Ihre vorhandenen Lastenausgleichsbereitstellungen einem regionsübergreifenden Lastenausgleich für eine hochverfügbare, regionsübergreifende Bereitstellung hinzu.

In der Startregion wird der regionsübergreifende Load Balancer oder die öffentliche IP-Adresse der globalen Ebene bereitgestellt. Diese Region wirkt sich nicht darauf aus, wie der Datenverkehr weitergeleitet wird. Wenn eine Startregion ausfällt, wirkt sich dies nicht auf den Fluss des Datenverkehrs aus.

Startregionen

• USA (Mitte)
• Asien, Osten
• USA (Ost) 2
• Nordeuropa
• Asien, Südosten
• UK, Süden
• US Government, Virginia
• Europa, Westen
• USA (Westen)

Hinweis

Sie können Ihren regionsübergreifenden Lastenausgleich oder die öffentliche IP-Adresse der globalen Ebene nur in einer gelisteten Home-Regionen bereitstellen.

In einer teilnehmenden Region wird die globale öffentliche IP-Adresse des Lastenausgleichs angekündigt.

Der vom Benutzer ausgelöste Datenverkehr wird über das Microsoft-Kernnetzwerk in die nächstgelegene teilnehmende Region übertragen.

Der regionsübergreifende Lastenausgleich leitet den Datenverkehr an den entsprechenden regionalen Lastenausgleich weiter.

Teilnehmende Regionen

• Australien (Osten)
• Australien, Südosten
• Indien, Mitte
• USA (Mitte)
• Asien, Osten
• East US
• USA (Ost) 2
• Japan, Osten
• USA Nord Mitte
• Nordeuropa
• USA Süd Mitte
• Asien, Südosten
• UK, Süden
• US DoD, Mitte
• US DoD, Osten
• US Gov Arizona
• US Gov Texas
• US Government, Virginia
• USA, Westen-Mitte
• Europa, Westen
• USA (Westen)
• USA, Westen 2

Hinweis

Die regionalen Lastenausgleichsmodule des Back-Ends können in jeder öffentlich verfügbaren Azure-Region bereitgestellt werden und sind nicht nur auf teilnehmende Regionen beschränkt.

Einschränkungen

• Regionsübergreifende Front-End-IP-Konfigurationen sind nur öffentlich. Ein internes Front-End wird derzeit nicht unterstützt.

• Ein privater oder interner Lastenausgleich kann nicht dem Back-End-Pool des regionsübergreifenden Lastenausgleichs hinzugefügt werden.

• NAT64-Übersetzung wird derzeit nicht unterstützt. Die Front-End- und Back-End-IP-Adressen müssen vom selben Typ (v4 oder v6) sein.

• UDP-Datenverkehr wird für einen regionsübergreifenden Lastenausgleich für IPv6 nicht unterstützt.

• UDP-Datenverkehr an Port 3 wird auf dem regionsübergreifenden Load Balancer nicht unterstützt

• Ausgangsregeln werden für regionsübergreifende Lastenausgleiche nicht unterstützt. Verwenden Sie für ausgehende Verbindungen Ausgangsregeln für den regionalen Lastenausgleich oder das NAT-Gateway.

Preise und SLA

Ein regionsübergreifender Lastenausgleich verwendet die SLA des Standardlastenausgleichs.

Nächste Schritte

• Zuverlässigkeit in Azure
• Siehe Tutorial: Erstellen eines regionsübergreifenden Lastenausgleichs im Azure-Portal, um einen regionsübergreifenden Lastenausgleich zu erstellen.
• Hier erfahren Sie mehr über den regionsübergreifenden Lastenausgleich.
• Weitere Informationen zu Azure Load Balancer.