Tillförlitlighet i Load Balancer

Den här artikeln innehåller specifika tillförlitlighetsrekommendationer för Load Balancer, samt detaljerad information om regional återhämtning i Load Balancer med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet.

En arkitekturöversikt över tillförlitlighet i Azure finns i Azures tillförlitlighet.

Tillförlitlighetsrekommendationer

Det här avsnittet innehåller rekommendationer för att uppnå återhämtning och tillgänglighet. Varje rekommendation ingår i någon av två kategorier:

• Hälsoobjekt omfattar områden som konfigurationsobjekt och rätt funktion för de huvudkomponenter som utgör din Azure-arbetsbelastning, till exempel Konfigurationsinställningar för Azure-resurser, beroenden för andra tjänster och så vidare.

• Riskobjekt omfattar områden som tillgänglighets- och återställningskrav, testning, övervakning, distribution och andra objekt som, om de lämnas olösta, ökar risken för problem i miljön.

Prioritetsmatris för tillförlitlighetsrekommendationer

Varje rekommendation markeras i enlighet med följande prioritetsmatris:

Bild	Prioritet	beskrivning
	Högst	Omedelbar korrigering krävs.
	Medium	Åtgärda inom 3–6 månader.
	Lägst	Måste granskas.

Sammanfattning av tillförlitlighetsrekommendationer

Kategori	Prioritet	Rekommendation
Tillgänglighet		Kontrollera att Standard Load Balancer är zonredundant
		Kontrollera att serverdelspoolen innehåller minst två instanser
Systemeffektivitet		Använda NAT Gateway i stället för regler för utgående trafik för produktionsarbetsbelastningar
		Använda Standard Load Balancer SKU

Tillgänglighet

Kontrollera att Standard Load Balancer är zonredundant

I en region som stöder tillgänglighetszoner bör Standard Load Balancer distribueras med zonredundans. Med en zonredundant lastbalanserare kan trafik hanteras av en enda IP-adress på klientdelen som kan överleva zonfel. Klientdels-IP-adressen kan användas för att nå alla (icke-påverkade) medlemmar i serverdelspoolen oavsett zon. Om en tillgänglighetszon misslyckas kan datasökvägen överleva så länge de återstående zonerna i regionen förblir felfria. Mer information finns i Zonredundant lastbalanserare.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Kontrollera att serverdelspoolen innehåller minst två instanser

Distribuera Load Balancer med minst två instanser i serverdelen. En enskild instans kan resultera i en felpunkt. För att kunna skapa för skalning kanske du vill koppla lastbalanserare med VM-skalningsuppsättningar.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Systemeffektivitet

Använda NAT Gateway i stället för regler för utgående trafik för produktionsarbetsbelastningar

Utgående regler allokerar fasta mängder SNAT-portar till varje virtuell datorinstans i en serverdelspool. Den här allokeringsmetoden kan leda till SNAT-portöverbelastning, särskilt om ojämna trafikmönster resulterar i att en specifik virtuell dator skickar en högre volym utgående anslutningar. För produktionsarbetsbelastningar rekommenderar vi att du kopplar ihop Standard Load Balancer eller någon undernätsdistribution med Azure NAT Gateway. NAT Gateway allokerar SNAT-portar dynamiskt över alla virtuella datorinstanser i ett undernät och minskar i sin tur risken för SNAT-portöverbelastning.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Använda Standard Load Balancer SKU

Standard SKU Load Balancer stöder tillgänglighetszoner och zonåterhämtning, medan Basic SKU inte gör det. När en zon slutar fungera påverkas inte din zonredundanta Standard Load Balancer och dina distributioner klarar zonfel i en region. Dessutom har Standard Load Balancer stöd för belastningsutjämning mellan regioner för att säkerställa att programmet inte påverkas av regionfel.

Kommentar

Grundläggande lastbalanserare har inget serviceavtal (SLA).

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

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.

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.

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

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.

Valv 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:

• 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 bakom en enda slutpunkt.
• Statisk global IP-adress för anycast
• Klient-IP-bevarande
• Bygga på en befintlig lastbalanserare utan inlärningskurva

Klientdels-IP-konfigurationen för lastbalanseraren mellan regioner är statisk och annonseras i de flesta Azure-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.

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.

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

• Tillförlitlighet i Azure
• Se Självstudie: Skapa en lastbalanserare mellan regioner med hjälp av Azure-portalen för att skapa en lastbalanserare mellan regioner.
• Läs mer om lastbalanserare mellan regioner.
• Läs mer om Azure Load Balancer.