Betrouwbaarheid in Load Balancer

Dit artikel bevat specifieke aanbevelingen voor betrouwbaarheid voor Load Balancer, evenals gedetailleerde informatie over regionale tolerantie van Load Balancer met beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit.

Zie Azure-betrouwbaarheid voor een architectuuroverzicht van betrouwbaarheid in Azure.

Aanbevelingen voor betrouwbaarheid

Deze sectie bevat aanbevelingen voor het bereiken van tolerantie en beschikbaarheid. Elke aanbeveling valt in een van de volgende twee categorieën:

• Statusitems hebben betrekking op gebieden zoals configuratie-items en de juiste functie van de belangrijkste onderdelen waaruit uw Azure-workload bestaat, zoals azure-resourceconfiguratie-instellingen, afhankelijkheden van andere services, enzovoort.

• Risico-items hebben betrekking op gebieden zoals beschikbaarheids- en herstelvereisten, testen, bewaken, implementeren en andere items die, indien onopgeloste, de kans op problemen in de omgeving vergroten.

Prioriteitsmatrix voor aanbevelingen voor betrouwbaarheid

Elke aanbeveling wordt gemarkeerd in overeenstemming met de volgende prioriteitsmatrix:

Image	Prioriteit	Beschrijving
	Hoog	Onmiddellijke oplossing nodig.
	Gemiddeld	Herstel binnen 3-6 maanden.
	Laag	Moet worden gecontroleerd.

Samenvatting van aanbevelingen voor betrouwbaarheid

Categorie	Prioriteit	Aanbeveling
Beschikbaarheid		Zorg ervoor dat Standard Load Balancer zone-redundant is
		Zorg ervoor dat de back-endpool ten minste twee exemplaren bevat
Systeemefficiëntie		NAT-gateway gebruiken in plaats van uitgaande regels voor productieworkloads
		Standard Load Balancer-SKU gebruiken

Beschikbaarheid

Zorg ervoor dat Standard Load Balancer zone-redundant is

In een regio die beschikbaarheidszones ondersteunt, moet Standard Load Balancer worden geïmplementeerd met zoneredundantie. Met een zone-redundante load balancer kan verkeer worden bediend door één front-end-IP-adres dat de zonefout kan overleven. Het front-end-IP-adres kan worden gebruikt om alle (niet-beïnvloede) back-endpoolleden te bereiken, ongeacht de zone. Als een beschikbaarheidszone mislukt, kan het gegevenspad overleven zolang de resterende zones in de regio in orde blijven. Zie Zone-redundante load balancer voor meer informatie.

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)

Zorg ervoor dat de back-endpool ten minste twee exemplaren bevat

Implementeer Load Balancer met ten minste twee exemplaren in de back-end. Eén exemplaar kan leiden tot een single point of failure. Als u wilt bouwen voor schaal, wilt u mogelijk een load balancer koppelen aan virtuele-machineschaalsets.

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)

Systeemefficiëntie

NAT-gateway gebruiken in plaats van uitgaande regels voor productieworkloads

Uitgaande regels wijzen vaste hoeveelheden SNAT-poorten toe aan elk exemplaar van de virtuele machine in een back-endpool. Deze toewijzingsmethode kan leiden tot uitputting van SNAT-poorten, met name als ongelijke verkeerspatronen resulteren in een specifieke virtuele machine die een hoger volume uitgaande verbindingen verzendt. Voor productieworkloads is het raadzaam om Standard Load Balancer of een subnetimplementatie te koppelen aan Azure NAT Gateway. NAT Gateway wijst dynamisch SNAT-poorten toe aan alle exemplaren van virtuele machines in een subnet en vermindert op zijn beurt het risico op uitputting van SNAT-poorten.

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"

Standard Load Balancer-SKU gebruiken

Standard SKU Load Balancer ondersteunt beschikbaarheidszones en zonetolerantie, terwijl de Basic-SKU dat niet doet. Wanneer een zone uitvalt, wordt uw zone-redundante Standard Load Balancer niet beïnvloed en kunnen uw implementaties bestand zijn tegen zonefouten binnen een regio. Daarnaast biedt Standard Load Balancer ondersteuning voor taakverdeling in meerdere regio's om ervoor te zorgen dat uw toepassing niet wordt beïnvloed door regiofouten.

Notitie

Basic Load Balancers hebben geen SLA (Service Level Agreement).

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")

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.

Azure Load Balancer ondersteunt scenario's voor beschikbaarheidszones. U kunt Standard Load Balancer gebruiken om de beschikbaarheid in uw scenario te vergroten door resources uit te lijnen met en distributie tussen zones. Raadpleeg dit document om inzicht te hebben in deze concepten en basisrichtlijnen voor scenarioontwerp.

Hoewel het raadzaam is om Load Balancer te implementeren met zoneredundantie, kan een load balancer zone-redundant, zone-redundant of niet-zonegebonden zijn. De selectie van de beschikbaarheidszone van de load balancer staat gelijk aan de zoneselectie van de front-end-IP. Als voor openbare load balancers het openbare IP-adres in de front-end van de load balancer zoneredundant is, is de load balancer ook zone-redundant. Als het openbare IP-adres in de front-end van de load balancer zonegebonden is, wordt de load balancer ook toegewezen aan dezelfde zone. Als u de zonegerelateerde eigenschappen voor uw load balancer wilt configureren, selecteert u het juiste type front-end dat nodig is.

Notitie

Het is niet vereist om voor elke zone een load balancer te hebben, maar een enkele load balancer met meerdere front-ends (zone-redundant of zone-redundant) die zijn gekoppeld aan hun respectieve back-endpools, hebben het doel.

Vereisten

• Als u beschikbaarheidszones wilt gebruiken met Load Balancer, moet u uw load balancer maken in een regio die beschikbaarheidszones ondersteunt. Zie de lijst met ondersteunde regio's om te zien welke regio's beschikbaarheidszones ondersteunen.

• Gebruik standard-SKU voor load balancer en openbaar IP-adres voor ondersteuning voor beschikbaarheidszones.

• Het type Basic-SKU wordt niet ondersteund.

• Als u uw resource wilt maken, moet u de rol Netwerkbijdrager of hoger hebben.

Beperkingen

• Zones kunnen na het maken niet worden gewijzigd, bijgewerkt of gemaakt voor de resource.
• Resources kunnen na het maken niet worden bijgewerkt van zone-redundant naar zone-redundant of omgekeerd.

Zone-redundante load balancer

In een regio met beschikbaarheidszones kan een Standard Load Balancer zone-redundant zijn met verkeer dat wordt geleverd door één IP-adres. Eén front-end-IP-adres overleeft de zonefout. Het front-end-IP-adres kan worden gebruikt om alle (niet-beïnvloede) back-endpoolleden te bereiken, ongeacht de zone. Maximaal één beschikbaarheidszone kan mislukken en het gegevenspad blijft behouden zolang de resterende zones in de regio in orde blijven.

Het IP-adres van de front-end wordt gelijktijdig geleverd door meerdere onafhankelijke infrastructuurimplementaties in meerdere beschikbaarheidszones. Nieuwe pogingen of herstelbewerkingen slagen in andere zones die niet worden beïnvloed door de zonefout.

Notitie

VM's 1,2 en 3 kunnen deel uitmaken van hetzelfde subnet en hoeven zich niet noodzakelijkerwijs in afzonderlijke zones te bevinden als de diagramsuggesties.

Leden in de back-endpool van een load balancer zijn normaal gesproken gekoppeld aan één zone, zoals met zonegebonden virtuele machines. Een gemeenschappelijk ontwerp voor productieworkloads is om meerdere zonegebonden resources te hebben. Bijvoorbeeld het plaatsen van virtuele machines uit zone 1, 2 en 3 in de back-end van een load balancer met een zoneredundante front-end voldoet aan dit ontwerpprincipe.

Zonegebonden load balancer

U kunt ervoor kiezen om een front-end te hebben die gegarandeerd is tot één zone, ook wel zonegebonden genoemd. In dit scenario dient één zone in een regio alle binnenkomende of uitgaande stromen. Uw front-end deelt het lot met de status van de zone. Het gegevenspad wordt niet beïnvloed door fouten in andere zones dan waar het is gegarandeerd. U kunt zonegebonden front-ends gebruiken om een IP-adres per beschikbaarheidszone beschikbaar te maken.

Daarnaast wordt het gebruik van zonegebonden front-endens rechtstreeks voor eindpunten met gelijke taakverdeling binnen elke zone ondersteund. U kunt deze configuratie gebruiken om eindpunten met gelijke taakverdeling per zone beschikbaar te maken om elke zone afzonderlijk te bewaken. Voor openbare eindpunten kunt u deze integreren met een DNS-taakverdelingsproduct zoals Traffic Manager en één DNS-naam gebruiken.

Voor een front-end van een openbare load balancer voegt u een zoneparameter toe aan het openbare IP-adres. Naar dit openbare IP-adres wordt verwezen door de front-end-IP-configuratie die wordt gebruikt door de respectieve regel.

Voor een front-end voor een interne load balancer voegt u een zoneparameter toe aan de front-end-IP-configuratie van de interne load balancer. Een zonegebonden front-end garandeert een IP-adres in een subnet naar een specifieke zone.

Niet-zonegebonden load balancer

Load Balancers kunnen ook worden gemaakt in een niet-zonegebonden configuratie door gebruik te maken van een front-end zonder zone. In deze scenario's zou een openbare load balancer een openbaar IP- of openbaar IP-voorvoegsel gebruiken, een interne load balancer een privé-IP-adres zou gebruiken. Deze optie biedt geen garantie voor redundantie.

Notitie

Alle openbare IP-adressen die worden bijgewerkt van Basic SKU naar Standard SKU, zijn van het type 'no-zone'. Meer informatie over het upgraden van een openbaar IP-adres in Azure Portal.

SLA-verbeteringen

Omdat beschikbaarheidszones fysiek gescheiden zijn en afzonderlijke energiebron, netwerk en koeling bieden, kunnen SLA's (Service level agreements) toenemen. Zie de SLA (Service Level Agreements) voor onlineservices voor meer informatie.

Een resource maken waarvoor beschikbaarheidszone is ingeschakeld

Zie quickstart: Een openbare load balancer maken om taken te verdelen over VM's binnen een zone of meerdere zones met behulp van een Load Balancer.

Notitie

• Zones kunnen na het maken niet worden gewijzigd, bijgewerkt of gemaakt voor de resource.
• Resources kunnen na het maken niet worden bijgewerkt van zone-redundant naar zone-redundant of omgekeerd.

Fouttolerantie

Virtuele machines kunnen een failover naar een andere server in een cluster uitvoeren, waarbij het besturingssysteem van de virtuele machine opnieuw wordt opgestart op de nieuwe server. Raadpleeg het failoverproces voor herstel na noodgevallen, het verzamelen van virtuele machines in herstelplanning en het uitvoeren van noodherstelanalyses om ervoor te zorgen dat de fouttolerantieoplossing is geslaagd.

Zie de siteherstelprocessen voor meer informatie.

Zone-down-ervaring

Zoneredundantie impliceert geen gegevensvlak of besturingsvlak zonder druk. Zone-redundante stromen kunnen elke zone gebruiken en uw stromen gebruiken alle zones in een regio die in orde zijn. In een zonefout worden verkeersstromen die gebruikmaken van zones die in orde zijn, niet beïnvloed.

Verkeersstromen die gebruikmaken van een zone op het moment van zonefouten, kunnen worden beïnvloed, maar toepassingen kunnen worden hersteld. Verkeer wordt voortgezet in de zones die in orde zijn binnen de regio wanneer het opnieuw wordt verzonden wanneer Azure is geconvergeerd rond de zonefout.

Bekijk ontwerppatronen in de Azure-cloud om de tolerantie van uw toepassing te verbeteren bij foutscenario's.

Meerdere frontends

Door meerdere front-ends te gebruiken, kunt u verkeer op meer dan één poort en/of IP-adres verdelen. Zorg er bij het ontwerpen van uw architectuur voor dat u rekening houdt met de interactie tussen zoneredundantie en meerdere front-ends. Als u altijd elke front-end wilt hebben die bestand is tegen fouten, moeten alle IP-adressen die als front-ends zijn toegewezen, zone-redundant zijn. Als een set front-ends is bedoeld om te worden gekoppeld aan één zone, moet elk IP-adres voor die set worden gekoppeld aan die specifieke zone. Een load balancer is niet vereist in elke zone. In plaats daarvan kan elke zonegebonden front-end of set zonegebonden front-ends worden gekoppeld aan virtuele machines in de back-endpool die deel uitmaken van die specifieke beschikbaarheidszone.

Veilige implementatietechnieken

Bekijk ontwerppatronen in de Azure-cloud om de tolerantie van uw toepassing te verbeteren bij foutscenario's.

Migreren naar ondersteuning voor beschikbaarheidszones

In het geval dat een regio wordt uitgebreid met beschikbaarheidszones, blijven bestaande IP-adressen niet-zonegebonden, zoals IP-adressen die worden gebruikt voor front-ends van load balancers. Om ervoor te zorgen dat uw architectuur kan profiteren van de nieuwe zones, wordt u aangeraden een nieuw front-end-IP-adres te maken. Zodra u deze hebt gemaakt, kunt u de bestaande niet-zonegebonden front-end vervangen door een nieuwe zone-redundante front-end. Zie Load Balancer migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie over het migreren van een VM naar ondersteuning voor beschikbaarheidszones.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Azure Standard Load Balancer biedt ondersteuning voor taakverdeling tussen regio's, waardoor geografisch redundante scenario's voor hoge beschikbaarheid mogelijk zijn, zoals:

• Binnenkomend verkeer dat afkomstig is van meerdere regio's.
• Directe wereldwijde failover naar de volgende optimale regionale implementatie.
• Laad distributie tussen regio's naar de dichtstbijzijnde Azure-regio met ultra lage latentie.
• Mogelijkheid om omhoog/omlaag te schalen achter één eindpunt.
• Statisch global IP-adres van anycast
• Behoud van CLIENT-IP
• Bouwen op een bestaande load balancer-oplossing zonder leercurve

De front-end-IP-configuratie van uw load balancer voor meerdere regio's is statisch en geadverteerd in de meeste Azure-regio's.

Notitie

De back-endpoort van uw taakverdelingsregel op load balancer tussen regio's moet overeenkomen met de front-endpoort van de taakverdelingsregel/inkomende nat-regel op regionale standaard load balancer.

Herstel na noodgevallen in geografie in meerdere regio's

Regionale redundantie

Configureer regionale redundantie door een load balancer tussen regio's naadloos te koppelen aan uw bestaande regionale load balancers.

Als de ene regio uitvalt, wordt het verkeer doorgestuurd naar de dichtstbijzijnde regionale load balancer.

De statustest van de load balancer tussen regio's verzamelt elke 5 seconden informatie over de beschikbaarheid van elke regionale load balancer. Als één regionale load balancer de beschikbaarheid tot 0 verlaagt, detecteert de load balancer in meerdere regio's de fout. De regionale load balancer wordt vervolgens uit rotatie gehaald.

Ultra-lage latentie

Het algoritme voor taakverdeling op geografische nabijheid is gebaseerd op de geografische locatie van uw gebruikers en uw regionale implementaties.

Verkeer dat vanaf een client is gestart, raakt de dichtstbijzijnde deelnemende regio en reist via de wereldwijde microsoft-netwerk-backbone om bij de dichtstbijzijnde regionale implementatie te komen.

U hebt bijvoorbeeld een load balancer voor meerdere regio's met standaard load balancers in Azure-regio's:

• VS - west
• Europa - noord

Als een stroom vanuit Seattle wordt gestart, wordt verkeer vs - west binnengegaan. Deze regio is de dichtstbijzijnde deelnemende regio vanuit Seattle. Het verkeer wordt doorgestuurd naar de dichtstbijzijnde load balancer van de regio, namelijk VS - west.

Azure-load balancer voor meerdere regio's maakt gebruik van een load balancing-algoritme voor geografische nabijheid voor de routeringsbeslissing.

De geconfigureerde loaddistributiemodus van de regionale load balancers wordt gebruikt voor het maken van de definitieve routeringsbeslissing wanneer meerdere regionale load balancers worden gebruikt voor geografische nabijheid.

Zie De distributiemodus configureren voor Azure Load Balancer voor meer informatie.

Uitgaand verkeer volgt de routeringsvoorkeur die is ingesteld op de regionale load balancers.

Mogelijkheid om omhoog/omlaag te schalen achter één eindpunt

Wanneer u het globale eindpunt van een load balancer voor meerdere regio's beschikbaar maakt voor klanten, kunt u regionale implementaties toevoegen of verwijderen achter het globale eindpunt zonder onderbreking.

Statisch global IP-adres van anycast

Load balancer voor meerdere regio's wordt geleverd met een statisch openbaar IP-adres, waardoor het IP-adres hetzelfde blijft. Lees hier meer voor meer informatie over statisch IP-adres

Behoud van CLIENT-IP

Load balancer voor meerdere regio's is een load balancer van laag 4-passthrough-netwerk. Deze passthrough behoudt het oorspronkelijke IP-adres van het pakket. Het oorspronkelijke IP-adres is beschikbaar voor de code die wordt uitgevoerd op de virtuele machine. Met dit behoud kunt u logica toepassen die specifiek is voor een IP-adres.

Zwevend IP-adres

Zwevend IP-adres kan worden geconfigureerd op zowel het globale IP-niveau als het regionale IP-niveau. Ga voor meer informatie naar Meerdere front-ends voor Azure Load Balancer

Het is belangrijk te weten dat zwevend IP-adres dat is geconfigureerd op de Azure-load balancer voor meerdere regio's onafhankelijk van zwevende IP-configuraties op regionale load balancers van de back-end werkt. Als zwevend IP-adres is ingeschakeld op de load balancer voor meerdere regio's, moet de juiste loopback-interface worden toegevoegd aan de back-end-VM's.

Statustests

Load Balancer in meerdere regio's van Azure maakt gebruik van de status van de regionale load balancers van de back-end bij het bepalen waar verkeer naar moet worden gedistribueerd. Statuscontroles door een load balancer in meerdere regio's worden elke vijf seconden automatisch uitgevoerd, aangezien een gebruiker statustests heeft ingesteld op de regionale load balancer.

Een oplossing voor meerdere regio's bouwen op bestaande Azure Load Balancer

De back-endpool van load balancer tussen regio's bevat een of meer regionale load balancers.

Voeg uw bestaande load balancer-implementaties toe aan een load balancer voor meerdere regio's voor een maximaal beschikbare implementatie in meerdere regio's.

Thuisregio is waar de load balancer voor meerdere regio's of het openbare IP-adres van de globale laag wordt geïmplementeerd. Deze regio heeft geen invloed op hoe het verkeer wordt gerouteerd. Als een thuisregio uitvalt, wordt de verkeersstroom niet beïnvloed.

Thuisregio's

• Central US
• Azië - oost
• VS - oost 2
• Europa - noord
• Azië - zuidoost
• Verenigd Koninkrijk Zuid
• VS (overheid) - Virginia
• Europa -west
• VS - west

Notitie

U kunt uw load balancer voor meerdere regio's of het openbare IP-adres alleen implementeren in de globale laag in een van de vermelde basisregio's.

Een deelnemende regio is waar het wereldwijde openbare IP-adres van de load balancer wordt geadverteerd.

Verkeer dat door de gebruiker is gestart, gaat naar de dichtstbijzijnde deelnemende regio via het Microsoft Core-netwerk.

Load balancer tussen regio's stuurt het verkeer naar de juiste regionale load balancer.

Deelnemende regio's

• Australië - oost
• Australië - zuidoost
• India - centraal
• Central US
• Azië - oost
• VS - oost
• VS - oost 2
• Japan - oost
• VS - noord-centraal
• Europa - noord
• VS - zuid-centraal
• Azië - zuidoost
• Verenigd Koninkrijk Zuid
• US DoD Central
• US DoD East
• US Gov - Arizona
• US Gov - Texas
• VS (overheid) - Virginia
• VS - west-centraal
• Europa -west
• VS - west
• VS - west 2

Notitie

De regionale load balancers voor de back-end kunnen worden geïmplementeerd in elke openbaar beschikbare Azure-regio en zijn niet beperkt tot alleen deelnemende regio's.

Beperkingen

• Front-end-IP-configuraties tussen regio's zijn alleen openbaar. Een interne front-end wordt momenteel niet ondersteund.

• Privé- of interne load balancer kan niet worden toegevoegd aan de back-endpool van een load balancer tussen regio's

• NAT64-vertaling wordt momenteel niet ondersteund. De front-end- en back-end-IP-adressen moeten van hetzelfde type zijn (v4 of v6).

• UDP-verkeer wordt niet ondersteund in Load Balancer voor meerdere regio's voor IPv6.

• UDP-verkeer op poort 3 wordt niet ondersteund in load balancer tussen regio's

• Uitgaande regels worden niet ondersteund in load balancer voor meerdere regio's. Gebruik voor uitgaande verbindingen uitgaande regels op de regionale load balancer of NAT-gateway.

Prijzen en SLA

Load balancer voor meerdere regio's deelt de SLA van standard load balancer.

Volgende stappen

• Betrouwbaarheid in Azure
• Zie zelfstudie: Een load balancer voor meerdere regio's maken met behulp van Azure Portal om een load balancer voor meerdere regio's te maken.
• Meer informatie over load balancer tussen regio's.
• Meer informatie over Azure Load Balancer.