Load Balancer och Tillgänglighetszoner

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 distribution mellan zoner. Läs det här dokumentet för att förstå dessa begrepp och grundläggande riktlinjer för utformning av scenarier

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

Zonredundant

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

En enda IP-adress på 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 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 hälsa med zonen. Datasökvägen påverkas inte av fel i andra zoner än där den garanterades. Du kan använda zonindelade frontends för att exponera en IP-adress per tillgänglighetszon.

Dessutom stöds användning av zonindelade klientlar 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ämnare 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 här offentliga IP-adressen refereras av den IP-konfiguration på serversidan som används av respektive regel.

För en intern lastbalanserare på serversidan lägger du till en zonparameter i IP-konfigurationen för den interna lastbalanseraren 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 från Basic till Standard-SKU ä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.

Fel vid tolerans mot zon

  • 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 förblir 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 ligger nere klarar inte distributionen 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 alltid är att varje frontend ska vara 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 uppsättning zonindelade serverdelsdatorer) associeras med virtuella datorer i serverdelspoolen som ingår i den specifika tillgänglighetszonen.

Övergång mellan regionala zonindeala modeller

I de fall där en region utökas till att ha tillgänglighetszoner förbliralla befintliga IP-adresser för frontend 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 serverdelen skapas och att lämpliga regler och konfigurationer replikeras för att använda dessa nya offentliga IP-adresser.

Kontroll- och dataplanskonsekvenser

Zonredundans innebär inte träfffritt dataplan eller kontrollplan. Zonredundant flöden kan använda valfri zon och dina flöden använder alla felfria zoner i en region. Vid 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önster för Azure-moln 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 zonindetal till zonredundant eller vice versa när de har skapats.

Nästa steg