Load Balancer och Tillgänglighetszoner

  • Artikel
  • 4 minuter för att läsa

Azure Load Balancer har stöd för scenarier med tillgänglighetszoner. Du kan använda Standard Load Balancer för att öka tillgängligheten i hela scenariot genom att justera resurser med och distribuera mellan zoner. Läs det här dokumentet för att förstå dessa begrepp och grundläggande riktlinjer för design av scenarier

En Load Balancer kan antingen vara zonredundant, zonindead eller icke-zonindead. Om du vill konfigurera zonrelaterade egenskaper (nämns ovan) för lastbalanseraren väljer du lämplig typ av frontend som behövs.

Zonredundant

I en region Tillgänglighetszoner kan en Standard Load Balancer vara zonredundant. Den här trafiken betjänas av en enda IP-adress.

En enda IP-adress för frontend klarar zonfel. Frontend-IP-adressen kan användas för att nå alla (icke-påverkade) medlemmar i backend-poolen oavsett zon. En eller flera tillgänglighetszoner kan misslyckas och datasökvägen klarar sig så länge en zon i regionen förblir felfri.

Serversidans IP-adress betjänas samtidigt av flera oberoende infrastrukturdistributioner i flera tillgänglighetszoner. Eventuella återförsök eller återetablering lyckas i andra zoner som inte påverkas av zonfelet.

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

Bild: Zonredundant lastbalanserare

Zonrelaterad

Du kan välja att en frontend ska garanteras av en enda zon, vilket kallas zonindelade. Det här scenariot innebär att alla inkommande eller utgående flöden betjänas av en enda zon i en region. Din frontend delar med sig av zonens hälsotillstånd. Datasökvägen påverkas inte av fel i andra zoner än där det garanterades. Du kan använda zonindelade frontends för att exponera en IP-adress per tillgänglighetszon.

Dessutom stöds användning av zonindelade klientsidan direkt för belastningsutjämnade slutpunkter i varje zon. Du kan använda den här konfigurationen för att exponera belastningsutjämnade slutpunkter per zon för att individuellt övervaka varje zon. För offentliga slutpunkter kan du integrera dem med en DNS-belastningsutjämning som Traffic Manager och använda ett enda DNS-namn.

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

Bild: Zonindelig lastbalanserare

För en offentlig lastbalanserare lägger du till en zonparameter till den offentliga IP-adressen. Den offentliga IP-adressen refereras av ip-konfigurationen på serversidan som används av respektive regel.

För en intern lastbalanserare lägger du till en zonparameter i ip-konfigurationen för den interna lastbalanserarens ip-adress på serversidan. En zonindelade frontend garanterar en IP-adress i ett undernät till en specifik zon.

Icke-zonindead

Lastbalanserare kan också skapas i en icke-zonindelade konfiguration med hjälp av en "ingen zon"-frontend (offentlig IP eller offentligt IP-prefix). Det här alternativet ger inte någon garanti för redundans. Observera att alla offentliga IP-adresser som uppgraderas är av typen "ingen zon".

Designöverväganden

Nu när du förstår zonrelaterade egenskaper för Standard Load Balancer kan följande designöverväganden vara till hjälp när du utformar för hög tillgänglighet.

Tolerans till zonfel

  • En zonredundant Load Balancer kan hantera en zonindead resurs i alla zoner med en IP-adress. IP-adressen kan överleva ett eller flera zonfel så länge minst en zon är felfri i regionen.
  • En zonindelade frontend är en minskning av tjänsten till en enda zon och delar med respektive zon. Om zonen som distributionen finns i fungerar inte, kommer distributionen inte att överleva det här felet.

Vi rekommenderar att du använder zonredundant Load Balancer för dina produktionsarbetsbelastningar.

Flera klienter

Genom att använda flera frontends kan du belastningsutjämna trafik på mer än en port och/eller IP-adress. När du utformar din arkitektur är det viktigt att ta hänsyn till hur zonredundans och flera frontend-datorer kan interagera. Observera att om målet är att alltid ha varje frontend motståndskraftig mot fel, måste alla IP-adresser som används tilldelade som frontends vara zonredundant. Om en uppsättning frontend-adresser är avsedda att associeras med en enda zon måste varje IP-adress för den uppsättningen associeras med den specifika zonen. Det krävs inte någon lastbalanserare för varje zon. I stället kan varje zonindelade serverdel (eller en uppsättning zonindelade serverdelsdatorer) associeras med virtuella datorer i serverdelspoolen som ingår i den specifika tillgänglighetszonen.

Övergång mellan regionala zonindeala modeller

Om en region utökas till att ha tillgänglighetszoner förblir den icke-zonindelade. För att säkerställa att din arkitektur kan dra nytta av de nya zonerna rekommenderar vi att nya IP-adresser för frontend skapas och att lämpliga regler och konfigurationer replikeras för att använda dessa nya offentliga IP-adresser.

Kontroll kontra dataplanskonsekvenser

Zonredundans innebär inte hitless-dataplan eller kontrollplan. Zonredundant flöden kan använda valfri zon och dina flöden använder alla felfria zoner i en region. I ett zonfel påverkas inte trafikflöden som använder felfria zoner.

Trafikflöden som använder en zon vid tidpunkten för zonfel kan påverkas, men program kan återställas. Trafiken fortsätter i felfria zoner i regionen vid återöverföring när Azure har konvergerat runt zonfelet.

Granska designmönstren för Azure-molnet för att förbättra programmets motståndskraft mot felscenarier.

Begränsningar

  • Zoner kan inte ändras, uppdateras eller skapas för resursen när de har skapats.
  • Resurser kan inte uppdateras från zonindead till zonredundant eller vice versa när de har skapats.

Nästa steg