Dela via

Dokumentation om Azure-tillförlitlighet

  • Artikel

Tillförlitlighet består av två principer: återhämtning och tillgänglighet. Målet med återhämtning är att undvika fel och, om de fortfarande inträffar, att återställa programmet till ett fullt fungerande tillstånd. Målet med tillgängligheten är att ge konsekvent åtkomst till ditt program eller din arbetsbelastning. Det är viktigt att planera för proaktiv tillförlitlighet baserat på dina programkrav.

Azure innehåller inbyggda tillförlitlighetstjänster som du kan använda och hantera baserat på dina affärsbehov. Oavsett om det är ett fel på en enskild maskinvarunod, ett fel på racknivå, ett datacenterfel eller ett storskaligt regionalt avbrott tillhandahåller Azure lösningar som förbättrar tillförlitligheten. Tillgänglighetsuppsättningar säkerställer till exempel att de virtuella datorer som distribueras i Azure distribueras över flera isolerade maskinvarunoder i ett kluster. Tillgänglighetszoner skyddar kundernas program och data från datacenterfel på flera fysiska platser i en region. Regioner och tillgänglighetszoner är centrala för din strategi för programdesign och återhämtning och beskrivs mer detaljerat senare i den här artikeln.

Dokumentationen om Azures tillförlitlighet ger vägledning om tillförlitlighet för Azure-tjänster. Den här vägledningen innehåller information om stöd för tillgänglighetszoner, vägledning för haveriberedskap och tillgänglighet för tjänster.

Detaljerad vägledning för tjänstspecifik tillförlitlighet, inklusive tillgänglighetszoner, haveriberedskap eller hög tillgänglighet, finns i Översikt över azure-tjänstspecifik tillförlitlighetsvägledning.

Information om tillförlitlighets- och tillförlitlighetsprinciper och arkitektur i Microsoft Azure-tjänster finns i Microsoft Azure Well-Architected Framework: Reliability (Microsoft Azure Well-Architected Framework: Reliability).

Tillförlitlighetskrav

Vilken nivå av tillförlitlighet som krävs för alla Azure-lösningar beror på flera överväganden. Serviceavtal för tillgänglighet och svarstid och andra affärskrav styr arkitekturvalen och återhämtningsnivån och bör övervägas först. Tillgänglighetskraven sträcker sig från hur mycket stilleståndstid som är acceptabelt – och hur mycket det kostar ditt företag – till hur mycket pengar och tid du realistiskt kan investera i att göra ett program mycket tillgängligt.

Att skapa tillförlitlighetssystem i Azure är ett delat ansvar. Microsoft ansvarar för molnplattformens tillförlitlighet, inklusive dess globala nätverk och datacenter. Azure-kunder och partner ansvarar för motståndskraften i sina molnprogram med hjälp av metodtips för arkitektur baserat på kraven för varje arbetsbelastning. Azure strävar kontinuerligt efter högsta möjliga återhämtning i serviceavtalet för molnplattformen, men du måste definiera dina egna målavtal för varje arbetsbelastning i din lösning. Med ett serviceavtal kan du utvärdera om arkitekturen uppfyller företagets behov. När du strävar efter högre procentandelar av SLA-garanterad drifttid ökar kostnaden och komplexiteten för att uppnå den tillgänglighetsnivån. En drifttid på 99,99 procent innebär cirka fem minuters total stilleståndstid per månad. Är det värt mer komplexitet och kostnad för att nå den procentandelen? Svaret beror på de enskilda affärskraven. När du bestämmer dig för de slutliga SLA-åtagandena förstår du Microsofts serviceavtal som stöds. Varje Azure-tjänst har ett eget serviceavtal.

Diagram showing the shared responsibility model for Azure business continuity.

I den traditionella lokala modellen faller hela ansvaret för att hantera, från maskinvaran för beräkning, lagring och nätverk till programmet, på dig. Du måste planera för olika typer av fel och hur du hanterar dem genom att skapa en strategi för haveriberedskap. Med IaaS ansvarar molntjänstleverantören för kärninfrastrukturens återhämtning, inklusive lagring, nätverk och beräkning. När du flyttar från IaaS till PaaS och sedan till SaaS upptäcker du att du är ansvarig för mindre och molntjänstleverantören ansvarar för mer.  

Mer information om tillförlitlighetsprinciper finns i Dokumentation om välkonstruerad framework-tillförlitlighet.  

Skapa tillförlitlighet

Du bör definiera programmets tillförlitlighetskrav i början av planeringen. Om du vet vilka program som inte behöver 100 % hög tillgänglighet under vissa tidsperioder kan du optimera kostnaderna under dessa icke-kritiska perioder. Identifiera vilken typ av fel ett program kan uppleva och den potentiella effekten av varje fel. En återställningsplan bör omfatta alla kritiska tjänster genom att slutföra återställningsstrategin på den enskilda komponenten och den övergripande programnivån. Utforma din återställningsstrategi för att skydda mot zonindelningsfel, regionala fel och programnivåfel. Utför testning av programmiljön från slutpunkt till slutpunkt för att mäta programmets tillförlitlighet och återställning mot oväntade fel.

Följande checklista omfattar omfattningen av tillförlitlighetsplanering.

Planering av tillförlitlighet
Definiera tillgänglighets- och återställningsmål för att uppfylla affärskraven.
Utforma tillförlitlighetsfunktionerna i dina program baserat på tillgänglighetskraven.
Justera program och dataplattformar för att uppfylla dina tillförlitlighetskrav.
Konfigurera anslutningsvägar för att öka tillgängligheten.
Använd tillgänglighetszoner och planering för haveriberedskap där det är tillämpligt för att förbättra tillförlitligheten och optimera kostnaderna.
Se till att programarkitekturen är motståndskraftig mot fel.
Vet vad som händer om SLA-kraven inte uppfylls.
Identifiera möjliga felpunkter i systemet. Programdesignen bör tolerera beroendefel genom att distribuera kretsbrytning.
Skapa program som fungerar i avsaknad av deras beroenden.

RTO och RPO

Återställningstid och återställningspunkter är två viktiga saker att tänka på gällande haveriberedskap.  Mer information om funktionella och icke-funktionella designkrav finns i Väldesignade ramverk funktionella och icke-funktionella krav.

  • Mål för återställningstid (RTO) är den tid som programmet får vara otillgängligt efter en incident.

  • Mål för återställningspunkter (RPO) är den maximala dataförlusten som är acceptabel vid ett haveri.

RTO och RPO är icke-funktionella krav i ett system och bör styras av affärskrav. För att ta fram de här värdena kan det vara bra att göra en riskbedömning och tydliggöra kostnaden för avbrott och dataförlust.  

Regioner och tillgänglighetszoner

Regioner och tillgänglighetszoner är en stor del av tillförlitlighetsekvationen. Regioner har flera, fysiskt separata tillgänglighetszoner. Dessa tillgänglighetszoner är anslutna via ett högpresterande nätverk med kortare svarstid än 2 ms mellan fysiska zoner. Låg svarstid hjälper dina data att förbli synkroniserade och tillgängliga när saker går fel. Du kan använda den här infrastrukturen strategiskt när du skapar program och datainfrastruktur som automatiskt replikerar och levererar oavbrutna tjänster mellan zoner och mellan regioner.

Microsoft Azure-tjänster har stöd för tillgänglighetszoner och är aktiverade för att driva molnåtgärderna till optimal hög tillgänglighet samtidigt som de stöder dina behov av återställning och affärskontinuitet.

För planering av haveriberedskap erbjuder regioner som är kopplade till andra regioner replikering mellan regioner och ger skydd genom att asynkront replikera data i andra Azure-regioner. Regioner utan par följer riktlinjerna för datahemvist och erbjuder hög tillgänglighet med tillgänglighetszoner och lokalt redundant eller zonredundant lagring. Kunder måste planera för haveriberedskap mellan regioner baserat på deras RTO/RPO-behov.

Välj den bästa regionen för dina behov baserat på tekniska och regelmässiga överväganden – tjänstfunktioner, datahemvist, efterlevnadskrav, svarstid – och börja utveckla din tillförlitlighetsstrategi. Mer information finns i Azure-regioner och tillgänglighetszoner.

Azure-tjänstberoenden

Microsoft Azure-tjänster är tillgängliga globalt för att driva molndriften på en optimal nivå.

Azure-tjänster som distribueras till Azure-regioner visas på sidan globala infrastrukturprodukter i Azure. Mer information om regioner och Tillgänglighetszoner i Azure finns i Regioner och Tillgänglighetszoner i Azure.

Azure-tjänster är byggda för tillförlitlighet, inklusive hög tillgänglighet och haveriberedskap. Det finns inga tjänster som är beroende av ett enda logiskt datacenter (för att undvika enskilda felpunkter). Icke-regionala tjänster som listas på globala Infrastrukturprodukter i Azure är tjänster som det inte finns något beroende av en specifik Azure-region för. Icke-regionala tjänster distribueras till två eller flera regioner och om det uppstår ett regionalt fel fortsätter instansen av tjänsten i en annan region att betjäna kunder. Vissa icke-regionala tjänster gör det möjligt för kunder att ange den region där den underliggande virtuella datorn (VM) som tjänsten körs på ska distribueras. Azure Virtual Desktop gör det till exempel möjligt för kunder att ange den regionplats där den virtuella datorn finns. Med alla Azure-tjänster som lagrar kunddata kan kunden ange de specifika regioner där deras data ska lagras. Undantaget är Microsoft Entra-ID, som har geoplacering (till exempel Europa eller Nordamerika). Mer information om lagringshemvist för data finns i datahemvistkartan.

Om du behöver förstå beroenden mellan Azure-tjänster för att hjälpa dig att bättre utforma dina program och tjänster kan du begära dokumentationen om Azure-tjänstberoende genom att kontakta din Microsoft-säljare eller kundrepresentant. I det här dokumentet visas beroenden för Azure-tjänster, inklusive beroenden för vanliga större interna tjänster, till exempel kontrollplanstjänster. För att få den här dokumentationen måste du vara Microsoft-kund och ha rätt sekretessavtal (NDA) med Microsoft.

Nästa steg