Betrouwbaarheid in Load Balancer

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

Ondersteuning voor beschikbaarheidszone

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?

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 voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken 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.