Tillförlitlighet i Load Balancer

Den här artikeln innehåller detaljerad information om regional motståndskraft för Load Balancer med tillgänglighetszoner och global haveriberedskap och affärskontinuitet.

Stöd för tillgänglighetszon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure Load Balancer stöder scenarier med tillgänglighetszoner. Du kan använda Standard Load Balancer för att öka tillgängligheten i hela scenariot genom att anpassa resurser till och distribuera mellan zoner. Läs det här dokumentet för att förstå dessa begrepp och grundläggande designvägledning för scenarion.

Även om det rekommenderas att man distribuerar Load Balancer med zonredundans kan en Load Balancer antingen vara zonredundant eller zonindelad (i regioner med tillgänglighetszoner). Valet av tillgänglighetszon för lastbalanseraren är synonymt med klientdels-IP:ens zonval. För offentliga lastbalanserare är lastbalanseraren även zonredundant om den offentliga IP-adressen i lastbalanserarens klientdel är zonredundant. Om den offentliga IP-adressen i lastbalanserarens klientdel är zonindelad kommer lastbalanseraren också att tilldelas samma zon. Om du vill konfigurera zonrelaterade egenskaper för lastbalanseraren väljer du den typ av klientdel som behövs.

Förutsättningar

• Om du vill använda tillgänglighetszoner med Load Balancer måste du skapa lastbalanseraren i en region som stöder tillgänglighetszoner. Information om vilka regioner som stöder tillgänglighetszoner finns i listan över regioner som stöds.

• Använd Standard SKU för lastbalanserare och offentlig IP för stöd för tillgänglighetszoner.

• Grundläggande SKU-typ stöds inte.

• För att skapa din resurs måste du ha rollen Nätverksbidragsgivare eller högre.

Begränsningar

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

Zonredundant lastbalanserare

I en region med tillgänglighetszoner kan en Standard Load Balancer vara zonredundant med trafik som hanteras av en enda IP-adress. En enskild IP-adress för klientdelen överlever zonfel. Frontend-IP-adressen kan användas för att nå alla (icke-påverkade) medlemmar i backendpoolen oavsett zon. Upp till en tillgänglighetszon kan misslyckas och datavägen överlever så länge de återstående zonerna i hela regionen förblir felfria.

Klientdelens IP-adress hanteras 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.

Medlemmar i serverdelspoolen i en lastbalanserare associeras normalt med en enda zon, till exempel med zonindelade virtuella datorer. En vanlig design för produktionsarbetsbelastningar är att ha flera zonindeliga resurser. Till exempel uppfyller placering av virtuella datorer från zon 1, 2 och 3 i serverdelen för en lastbalanserare med en zonredundant klientdel den här designprincipen.

Zonindelad lastbalanserare

Du kan välja att ha en frontend garanterad till en enda zon, vilket kallas zonala. I det här scenariot hanterar en enda zon i en region alla inkommande eller utgående flöde. Din gränssnitt delar ödet med zonens hälsa. Datasökvägen påverkas inte av fel i andra zoner än där den garanterades. Du kan använda zonal frontends för att exponera en IP-adress per tillgänglighetszon.

Dessutom stöds användningen av zonindelade frontändar direkt för slutpunkter med belastningsutjämning i varje zon. Du kan använda den här konfigurationen för att exponera belastningsutjämningsslutpunkter per zon för individuell övervakning av varje zon. För offentliga slutpunkter kan du integrera dem med en DNS-belastningsutjämningsprodukt som Traffic Manager och använda ett enda DNS-namn.

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

För en intern lastbalanserare, lägg till en parameter zones till IP-konfigurationen för den interna lastbalanserarens frontend. En zonal frontend garanterar en IP-adress i ett undernät till en specifik zon.

Lastbalanserare som inte är zonindelad

I regioner utan tillgänglighetszoner kan lastbalanserare också skapas i en icke-zonindelad konfiguration med hjälp av en klientdel utan zon. I dessa scenarier använder en offentlig lastbalanserare ett offentligt IP- eller offentligt IP-prefix, en intern lastbalanserare använder en privat IP-adress. Det här alternativet ger ingen garanti för redundans.

Förbättringar av serviceavtal

Eftersom tillgänglighetszoner är fysiskt åtskilda och ger separata energikällor, nätverk och kylning, kan tjänstnivåavtalen (SLAs) förbättras. Mer information finns i serviceavtal (SLA) för onlinetjänster.

Skapa en resurs med tillgänglighetszonen aktiverad

Information om hur du lastbalanserar virtuella datorer i en zon eller över flera zoner med hjälp av en lastbalanserare finns i Snabbstart: Skapa en offentlig lastbalanserare för att belastningsutjämning av virtuella datorer.

Feltolerans

Virtuella datorer kan redundansväxla till en annan server i ett kluster, där den virtuella datorns operativsystem startas om på den nya servern. Du bör referera till övergångsprocessen för haveriberedskap, samla in virtuella maskiner i återställningsplaneringen, och köra övningar för haveriberedskap för att säkerställa att feltoleranslösningen blir framgångsrik.

Mer information finns i site recovery-processerna.

Avslappningsupplevelse

Zonredundans innebär inte träfffritt dataplan eller kontrollplan. Zonredundanta flöden kan använda vilken zon som helst och dina flöden kommer att använda alla intakta 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 de felfria zonerna 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 återhämtning till felscenarier.

Flera gränssnitt

Genom att använda flera fronter kan du belastningsutjämna trafik över mer än en port och/eller IP-adress. När du utformar arkitekturen måste du ta hänsyn till hur zonredundans interagerar med flera klientdelar. Om målet är att alltid ha varje klientdel motståndskraftig mot fel måste alla IP-adresser som tilldelats som klientdelar vara zonredundanta. Om en uppsättning klientdelar är avsedd att associeras med en enda zon måste varje IP-adress för den uppsättningen associeras med den specifika zonen. En lastbalanserare krävs inte i varje zon. I stället kan varje zonindelad klientdel, eller uppsättning zonindelade klientdelar, associeras med virtuella datorer i serverdelspoolen som ingår i den specifika tillgänglighetszonen.

Säkra distributionstekniker

Granska designmönstren för Azure-molnet för att förbättra programmets återhämtning till felscenarier.

Migrera till stöd för tillgänglighetszoner

Om en region utökas för att ha tillgänglighetszoner skulle alla befintliga IP-adresser förbli icke-zonindelade som IP-adresser som används för lastbalanserarens klientdelar. För att säkerställa att arkitekturen kan dra nytta av de nya zonerna rekommenderar vi att du skapar en ny IP-adress för klientdelen. När du har skapat den kan du ersätta den befintliga klientdelen som inte är zonindelad med en ny zonredundant klientdel. Information om hur du migrerar en virtuell dator till stöd för tillgänglighetszoner finns i Migrera lastbalanserare till stöd för tillgänglighetszoner.

Global haveriberedskap och affärskontinuitet

Haveriberedskap (DR) refererar till metoder som organisationer använder för att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar skapa din haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

För DR använder Microsoft modellen delat ansvar. I den här modellen ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Många Azure-tjänster replikerar dock inte data automatiskt eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR. Du kan använda de tjänstspecifika funktionerna i till att underlätta snabb återställning för att hjälpa till att utveckla din DR-plan.

Azure Standard Load Balancer stöder global belastningsutjämning som möjliggör geo-redundanta scenarier med hög tillgänglighet, till exempel:

• Inkommande trafik som kommer från flera regioner.
• Omedelbar global redundans till nästa optimala regionala distribution.
• Läs in distribution mellan regioner till närmaste Azure-region med extremt låg svarstid.
• Möjlighet att skala upp/ned via en enda slutpunkt.
• Statisk global IP-adress för anycast
• Klient-IP-bevarande
• Utveckla vidare på en befintlig lastbalanseringslösning utan att behöva lära sig något nytt

IP-konfigurationen för klientdelen för din globala lastbalanserare är statisk och annonseras i de flesta Azure-regioner.

Haveriberedskap i geografi för flera regioner

Regional redundans

Konfigurera regional redundans genom att sömlöst länka en global lastbalanserare till dina befintliga regionala lastbalanserare.

Om en region misslyckas dirigeras trafiken till nästa närmaste felfria regionala lastbalanserare.

Hälsokontrollen för den globala lastbalanseraren samlar in information om tillgängligheten var femte sekund för varje regional lastbalanserare. Om en regional lastbalanserare minskar sin tillgänglighet till 0 identifierar den globala lastbalanseraren felet. Den regionala lastbalanseraren tas sedan ur rotation.

Ultralåg svarstid

Algoritmen för belastningsutjämning med geo-närhet baseras på användarnas geografiska plats och dina regionala distributioner.

Trafik som startas från en klient når den närmast deltagande regionen och färdas via Microsofts globala nätverksstomme för att komma fram till den närmaste regionala distributionen.

Du har till exempel en global lastbalanserare med standardlastbalanserare i Azure-regioner:

• Västra USA
• Europa, norra

Om ett flöde startas från Seattle går trafiken in i västra USA. Den här regionen är den närmaste deltagande regionen från Seattle. Trafiken dirigeras till den närmaste regionlastbalanseraren, som är USA, västra.

Den globala lastbalanseraren i Azure använder algoritmen för geo-närhetsbelastning för routningsbeslutet.

Det konfigurerade lastdistributionsläget för de regionala lastbalanserarna används för att fatta det slutliga routningsbeslutet när flera regionala lastbalanserare används för geo-närhet.

Mer information finns i Konfigurera distributionsläget för Azure Load Balancer.

Utgående trafik följer routningsinställningen för de regionala lastbalanserarna.

Möjlighet att skala upp/ned bakom en enda slutpunkt

När du exponerar den globala slutpunkten för en global lastbalanserare för kunder kan du lägga till eller ta bort regionala distributioner bakom den globala slutpunkten utan avbrott.

Statisk global IP-adress för anycast

Global lastbalanserare levereras med en statisk offentlig IP-adress, vilket säkerställer att IP-adressen förblir densamma. Läs mer om statisk IP-adress här

Klient-IP-bevarande

Global lastbalanserare är en Layer-4-lastbalanserare för direktnätverk. Genomströmningen bevarar paketets ursprungliga IP-adress. Den ursprungliga IP-adressen är tillgänglig för koden som körs på den virtuella datorn. Med det här bevarandet kan du använda logik som är specifik för en IP-adress.

Flytande IP

Flytande IP-adress kan konfigureras på både global IP-nivå och regional IP-nivå. För mer information, besök Flera gränssnitt för Azure Load Balancer

Det är viktigt att observera att den flytande IP-adressen som konfigurerats på den globala Lastbalanseraren i Azure fungerar oberoende av flytande IP-konfigurationer på regionala lastbalanserare på serverdelen. Om flytande IP är aktiverat på den globala lastbalanseraren måste lämpligt loopback-gränssnitt läggas till i de virtuella serverdelsdatorerna.

Hälsokontroller

Azure Global Load Balancer använder hälsotillståndet för de regionala lastbalanserarna i serverdelen när du bestämmer var trafik ska distribueras till. Hälsokontroller av den globala lastbalanseraren utförs automatiskt var femte sekund, förutsatt att en användare konfigurerar hälsoövervakning på sin regionala lastbalanserare.

Skapa en global lösning på befintlig Azure Load Balancer

Serverdelspoolen för en global lastbalanserare innehåller en eller flera regionala lastbalanserare.

Lägg till dina befintliga distributioner av lastbalanserare till en global lastbalanserare för en global distribution med hög tillgänglighet.

I hemregionen distribueras den globala lastbalanseraren eller den offentliga IP-adressen för den globala nivån. Den här regionen påverkar inte hur trafiken dirigeras. Om en hemregion slutar fungera påverkas inte trafikflödet.

Hemregioner

• Centrala USA
• Asien, östra
• Östra USA 2
• Europa, norra
• Sydostasien
• Storbritannien, södra
• USA:s regering Virginia
• Europa, västra
• Västra USA

En deltagande region är den region där den globala offentliga IP-adressen för lastbalanseraren annonseras.

Trafik som startas av användaren färdas till den närmast deltagande regionen via Microsofts kärnnätverk.

Global lastbalanserare dirigerar trafiken till lämplig regional lastbalanserare.

Deltagande regioner

• Australien, östra
• Australien, sydöstra
• Centrala Indien
• Centrala USA
• Asien, östra
• Östra USA
• Östra USA 2
• Japan, östra
• USA, norra centrala
• Europa, norra
• Sydcentrala USA
• Sydostasien
• Storbritannien, södra
• Det amerikanska försvarsdepartementets centrala
• Amerikanska försvarsdepartementet Öst
• USA:s regering, Arizona
• USA:s regering Texas
• USA:s regering Virginia
• Västra centrala USA
• Europa, västra
• Västra USA
• Västra USA 2

Begränsningar

• Globala IP-konfigurationer för klientdelen är endast offentliga. En intern frontend stöds inte för närvarande.

• Privat eller intern lastbalanserare kan inte läggas till i serverdelspoolen för en global lastbalanserare

• NAT64-översättning stöds inte just nu. Ip-adresserna för klientdelen och serverdelen måste vara av samma typ (v4 eller v6).

• UDP-trafik stöds inte på en global lastbalanserare för IPv6.

• UDP-trafik på port 3 stöds inte på en global lastbalanserare

• Regler för utgående trafik stöds inte på en global lastbalanserare. För utgående anslutningar använder du regler för utgående trafik på den regionala lastbalanseraren eller NAT-gatewayen.

Priser och SLA

Global lastbalanserare delar serviceavtalet för standardlastbalanseraren.

Nästa steg

• Tillförlitlighet i Azure
• Se Självstudie: Skapa en global lastbalanserare med hjälp av Azure Portal för att skapa en global lastbalanserare.
• Lär dig mer om global lastbalansering i den här videon.
• Läs mer om Azure Load Balancer.