Load Balancer en Beschikbaarheidszones

Azure Load Balancer ondersteunt scenario's met beschikbaarheidszones. U kunt deze Standard Load Balancer beschikbaarheid in uw scenario te vergroten door resources af te stemmen met en te distribueren over zones. Lees dit document om inzicht te krijgen in deze concepten en richtlijnen voor het ontwerpen van fundamentele scenario's

Een Load Balancer kan zone-redundant, zonelijk of niet-zonelijk zijn. Als u de zonegerelateerde eigenschappen (hierboven) wilt configureren voor uw load balancer selecteert u het juiste type front-end dat nodig is.

Zone-redundant

In een regio met Beschikbaarheidszones kan Standard Load Balancer zone-redundant zijn. Dit verkeer wordt bediend door één IP-adres.

Eén front-end-IP-adres overleeft zonestoringen. Het front-end-IP-adres kan worden gebruikt om alle (niet-beïnvloede) leden van de back-endpool te bereiken, ongeacht de zone. Een of meer beschikbaarheidszones kunnen mislukken en het gegevenspad blijft bestaan zolang één zone in de regio in orde blijft.

Het IP-adres van de front-end wordt tegelijkertijd bediend door meerdere implementaties van onafhankelijke infrastructuur in meerdere beschikbaarheidszones. Nieuwe proberen of herstellen slaagt in andere zones die niet worden beïnvloed door de zonefout.

Figure depicts a zone-redundant standard load balancer directing traffic in three different zones to three different subnets in a zone redundant configuration.

Afbeelding: Zone-redundante load balancer

Zonal

U kunt ervoor kiezen om een front-end te hebben die gegarandeerd is voor één zone, ook wel zonelijk genoemd. Dit scenario betekent dat elke binnenkomende of uitgaande stroom wordt bediend door één zone in een regio. Uw front-end-shares staan in het bezit van de status van de zone. Het gegevenspad wordt niet beïnvloed door fouten in andere zones dan waar het is gegarandeerd. U kunt zone-frontends gebruiken om per beschikbaarheidszone een IP-adres beschikbaar te maken.

Daarnaast wordt het gebruik van zonelijke front-ends rechtstreeks voor eindpunten met load balanced binnen elke zone ondersteund. U kunt deze configuratie gebruiken om eindpunten met load balanced per zone weer te geven om elke zone afzonderlijk te bewaken. Voor openbare eindpunten kunt u deze integreren met een PRODUCT voor DNS-taakverdeling, Traffic Manager en één DNS-naam gebruiken.

Figure depicts three zonal standard load balancers each directing traffic in a zone to three different subnets in a zonal configuration.

Afbeelding: Load balancer

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

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

Ontwerpoverwegingen

Nu u de zone-gerelateerde eigenschappen voor Standard Load Balancer begrijpt, kunnen de volgende ontwerpoverwegingen u helpen bij het ontwerpen voor hoge beschikbaarheid.

Tolerantie voor zonefout

  • Een zone-redundante Load Balancer kan een zoneresource in elke zone met één IP-adres gebruiken. Het IP-adres kan een of meer zonefouten overleven zolang ten minste één zone in orde blijft binnen de regio.
  • Een zonele front-end is een vermindering van de service tot één zone en deelt deze met de respectieve zone. Als de zone waarin uw implementatie zich bevindt uitvallen, overleeft uw implementatie deze fout niet.

Het wordt aanbevolen om zone-redundante Load Balancer voor uw productieworkloads te gebruiken.

Meerdere frontends

Met behulp van meerdere front-ends kunt u verkeer op meer dan één poort en/of IP-adres laden. Bij het ontwerpen van uw architectuur is het belangrijk om rekening te houden met de manier waarop zone-redundantie en meerdere front-ends kunnen communiceren. Houd er rekening mee dat als het doel is om ervoor te zorgen dat elke front-end altijd bestand is tegen fouten, alle IP-adressen die als front-ends worden gebruikt, zone-redundant moeten 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. Het is niet vereist om een load balancer voor elke zone; In plaats van kan elke zonelijke front-end (of set zonelijke front-ends) worden gekoppeld aan virtuele machines in de back-end-pool die deel uitmaken van die specifieke beschikbaarheidszone.

Overgang tussen regionale, zonale modellen

In het geval dat een regio wordt uitgebreid met beschikbaarheidszones,blijven alle bestaande front-end-VIP's niet-zonelijk. Om ervoor te zorgen dat uw architectuur gebruik kan maken van de nieuwe zones, is het raadzaam om nieuwe front-end-IP's te maken en de juiste regels en configuraties te repliceren om deze nieuwe openbare IP's te gebruiken.

Gevolgen van controle versus gegevensvlak

Zone-redundantie impliceert geen gegevensvlak of besturingsvlak zonder hit. Zone-redundante stromen kunnen elke zone gebruiken en uw stromen gebruiken alle zones in orde in een regio. In een zonefout worden verkeersstromen met zones met een goede gezondheid niet beïnvloed.

Verkeersstromen die een zone gebruiken op het moment van zonestoringen kunnen worden beïnvloed, maar toepassingen kunnen wel worden hersteld. Het verkeer blijft in de zones in orde binnen de regio na het opnieuw overzenden wanneer Azure is geconvergeerd rond de zonefout.

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

Beperkingen

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

Volgende stappen