Deze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
Dit artikel bevat gedetailleerde informatie over regionale tolerantie van Load Balancer met beschikbaarheidszones en wereldwijde herstel na noodgevallen en bedrijfscontinuïteit.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Bekijk ontwerppatronen in de Azure-cloud om de tolerantie van uw toepassing te verbeteren bij foutscenario's.
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 (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 wereldwijde taakverdeling voor scenario's met geografisch redundante hoge beschikbaarheid, zoals:
De front-end-IP-configuratie van uw globale load balancer is statisch en geadverteerd in de meeste Azure-regio's.
Notitie
De back-endpoort van uw taakverdelingsregel op de globale load balancer moet overeenkomen met de front-endpoort van de taakverdelingsregel/inkomende NAT-regel op regionale standaard load balancer.
Configureer regionale redundantie door een globale load balancer 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 globale load balancer verzamelt elke 5 seconden informatie over de beschikbaarheid van elke regionale load balancer. Als één regionale load balancer de beschikbaarheid verlaagt tot 0, detecteert de globale load balancer de fout. De regionale load balancer wordt vervolgens uit rotatie gehaald.
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 globale load balancer met standaard load balancers in Azure-regio's:
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 Global Load Balancer maakt gebruik van een algoritme voor geo-nabijheidstaakverdeling 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.
Wanneer u het globale eindpunt van een globale load balancer beschikbaar maakt voor klanten, kunt u regionale implementaties toevoegen of verwijderen achter het globale eindpunt zonder onderbreking.
Globale load balancer wordt geleverd met een statisch openbaar IP-adres, waardoor het IP-adres hetzelfde blijft. Lees hier meer voor meer informatie over statisch IP-adres
Globale load balancer is een load balancer voor pass-through-netwerk op laag 4. 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 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 om te weten dat zwevend IP-adres dat is geconfigureerd op de globale Load Balancer van Azure onafhankelijk van zwevende IP-configuraties op regionale load balancers van de back-end werkt. Als zwevend IP-adres is ingeschakeld op de globale load balancer, moet de juiste loopback-interface worden toegevoegd aan de back-end-VM's.
Azure Global Load Balancer 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 globale load balancer worden elke 5 seconden automatisch uitgevoerd, aangezien een gebruiker statustests configureert op hun regionale load balancer.
De back-endpool van een globale load balancer bevat een of meer regionale load balancers.
Voeg uw bestaande load balancer-implementaties toe aan een globale load balancer voor een maximaal beschikbare, globale implementatie.
Thuisregio is waar de globale load balancer 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.
Notitie
U kunt uw globale load balancer of openbaar 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.
Globale load balancer stuurt het verkeer naar de juiste regionale load balancer.
Notitie
De regionale load balancers voor de back-end kunnen worden geïmplementeerd in elke openbaar beschikbare Azure-regio en is niet beperkt tot alleen deelnemende regio's.
Globale front-end-IP-configuraties 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 globale load balancer
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 op een globale Load Balancer voor IPv6.
UDP-verkeer op poort 3 wordt niet ondersteund op een globale Load Balancer
Uitgaande regels worden niet ondersteund op een globale Load Balancer. Gebruik voor uitgaande verbindingen uitgaande regels op de regionale load balancer of NAT-gateway.
Globale load balancer deelt de SLA van standard load balancer.
Training
Module
In deze module leert u hoe u Azure Load Balancer gebruikt om verkeer te distribueren tussen meerdere virtuele servers of services.
Certificering
Microsoft Certified: Azure Network Engineer Associate - Certifications
Demonstrate the design, implementation, and maintenance of Azure networking infrastructure, load balancing traffic, network routing, and more.
Documentatie
Globale load balancer - Azure Load Balancer
Overzicht van de globale load balancer-laag voor Azure Load Balancer.
In deze zelfstudie wordt gedemonstreerd hoe u een Standard Load Balancer maakt met zonegebonden front-end om taken van VM's binnen een beschikbaarheidszone te verdelen met behulp van Azure Portal.
Wat is Azure Load Balancer? - Azure Load Balancer
Bekijk een overzicht van azure Load Balancer-functies, -architectuur en -implementatie. Meer informatie over hoe de service werkt en hoe u deze kunt gebruiken in de cloud.