Dela via

Tillförlitlighet i Load Balancer

  • Artikel

Den här artikeln innehåller detaljerad information om regional återhämtning i Load Balancer med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet.

Stöd för tillgänglighetszon

Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.

Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.

Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

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 vi rekommenderar att du distribuerar Load Balancer med zonredundans kan en lastbalanserare antingen vara zonredundant, zonindelad eller icke-zonindelad. 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.

Kommentar

Det är inte nödvändigt att ha en lastbalanserare för varje zon, snarare att ha en enda lastbalanserare med flera klientdelar (zon- eller zonredundant) som är associerade till respektive serverdelspooler kommer att tjäna syftet.

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.

  • Om du vill skapa resursen måste du ha rollen Nätverksdeltagare 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. Klientdels-IP-adressen kan användas för att nå alla (icke-påverkade) medlemmar i serverdelspoolen oavsett zon. Upp till en tillgänglighetszon kan misslyckas och datasökvägen överlever så länge de återstående zonerna i 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.

Bild som visar en zonredundant standardlastbalanserare som dirigerar trafik i tre olika zoner till tre olika undernät i en zonredundant konfiguration.

Kommentar

Virtuella datorer 1,2 och 3 kan tillhöra samma undernät och behöver inte nödvändigtvis finnas i separata zoner som diagramförslagen.

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 klientdel garanterad till en enda zon, som kallas zonindelning. I det här scenariot hanterar en enda zon i en region alla inkommande eller utgående flöde. Klientdelen 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 zonindelade klientdelar för att exponera en IP-adress per tillgänglighetszon.

Dessutom stöds användningen av zonindelade klientdelar direkt för belastningsutjämningsslutpunkter 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.

Bild som visar tre zonindela standardlastbalanserare som var och en dirigerar trafik i en zon till tre olika undernät i en zonindelad konfiguration.

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ägger du till en zonparameter i ip-konfigurationen för den interna lastbalanserarens klientdel. En zonindelad klientdel garanterar en IP-adress i ett undernät till en specifik zon.

Lastbalanserare som inte är zonindelad

Load Balancers kan också skapas i en icke-zonindelad konfiguration med hjälp av en "no-zone"-klientdel. 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.

Kommentar

Alla offentliga IP-adresser som uppgraderas från Basic SKU till Standard SKU kommer att vara av typen "no-zone". Lär dig hur du uppgraderar en offentlig IP-adress i Azure Portal.

Förbättringar av serviceavtal

Eftersom tillgänglighetszoner är fysiskt åtskilda och ger distinkta energikällor, nätverk och kylning kan serviceavtal (serviceavtal) öka. 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.

Kommentar

  • 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.

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 redundansväxlingsprocessen för haveriberedskap, insamling av virtuella datorer i återställningsplanering och körning av haveriberedskapstest för att säkerställa att feltoleranslösningen lyckas.

Mer information finns i site recovery-processerna.

Zon-ned-upplevelse

Zonredundans innebär inte träfffritt dataplan eller kontrollplan. Zonredundanta 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 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 klienter

Om du använder flera klientdelar kan du belastningsutjämningstrafik på 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.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om 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 fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data 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 och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

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

Klientdels-IP-konfigurationen för lastbalanseraren mellan regioner är statisk och annonseras i de flesta Azure-regioner.

Diagram över lastbalanserare mellan regioner.

Kommentar

Serverdelsporten för din belastningsutjämningsregel för lastbalanserare mellan regioner ska matcha klientdelsporten för belastningsutjämningsregeln/inkommande nat-regeln på den regionala standardlastbalanseraren.

Haveriberedskap i geografi för flera regioner

Regional redundans

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

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

Hälsoavsökningen för lastbalanseraren mellan regioner samlar in information om tillgängligheten för varje regional lastbalanserare var femte sekund. Om en regional lastbalanserare släpper sin tillgänglighet till 0 identifierar lastbalanseraren mellan regioner felet. Den regionala lastbalanseraren tas sedan ur rotation.

Diagram över trafikvyn för den globala regionen.

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 lastbalanserare mellan regioner med standardlastbalanserare i Azure-regioner:

  • Västra USA
  • Europa, norra

Om ett flöde startas från Seattle kommer trafiken till USA, västra. 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.

Azures lastbalanserare mellan regioner använder algoritmen för geo-närhetsbelastningsutjämning 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 enskild slutpunkt

När du exponerar den globala slutpunkten för en lastbalanserare mellan regioner 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

Lastbalanseraren mellan regioner 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

Lastbalanserare mellan regioner ä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å. Mer information finns i Flera klientdelar för Azure Load Balancer

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

Hälsotillståndsavsökningar

Azures lastbalanserare mellan regioner använder hälsotillståndet för de regionala lastbalanserarna i serverdelen när de bestämmer var trafiken ska distribueras till. Hälsokontroller av lastbalanserare mellan regioner utförs automatiskt var femte sekund, med tanke på att en användare har konfigurerat hälsoavsökningar på sin regionala lastbalanserare.

Skapa lösning mellan regioner på befintlig Azure Load Balancer

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

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

I hemregionen distribueras lastbalanseraren mellan regioner 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

  • Central US
  • Asien, östra
  • USA, östra 2
  • Europa, norra
  • Sydostasien
  • Storbritannien, södra
  • US Gov, Virginia
  • Europa, västra
  • USA, västra

Kommentar

Du kan bara distribuera lastbalanseraren mellan regioner eller offentlig IP-adress på global nivå i någon av de angivna startregionerna.

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.

Lastbalanseraren mellan regioner dirigerar trafiken till lämplig regional lastbalanserare.

Diagram över global trafik i flera regioner.

Deltagande regioner

  • Australien, östra
  • Australien, sydöstra
  • Indien, centrala
  • Central US
  • Asien, östra
  • East US
  • USA, östra 2
  • Japan, östra
  • USA, norra centrala
  • Europa, norra
  • USA, södra centrala
  • Sydostasien
  • Storbritannien, södra
  • US DoD, centrala
  • US DoD, östra
  • US Gov, Arizona
  • US Gov, Texas
  • US Gov, Virginia
  • USA, västra centrala
  • Europa, västra
  • USA, västra
  • USA, västra 2

Kommentar

Serverdelsregionens lastbalanserare kan distribueras i alla offentligt tillgängliga Azure-regioner och är inte begränsade till enbart deltagande regioner.

Begränsningar

  • IP-konfigurationer mellan regioner är endast offentliga. En intern klientdel stöds för närvarande inte.

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

  • 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å Lastbalanserare mellan regioner för IPv6.

  • UDP-trafik på port 3 stöds inte på lastbalanserare mellan regioner

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

Priser och SLA

Lastbalanseraren mellan regioner delar serviceavtalet för standardlastbalanseraren.

Nästa steg