Design för säkerhetskopiering och återställning
Organisationer, till exempel Tailwind Traders, kräver en hög grad av tillförlitlighet från sina verksamhetskritiska appar. För att uppnå önskad tillförlitlighet för lokala appar är det vanligt att köpa mer databehandlingsresurser, till exempel servrar och lagring. Genom att köpa fler databehandlingsresurser skapas redundans i en lokal infrastruktur.
Det är också viktigt att alla verksamhetskritiska appar och dess associerade data kan återställas efter ett fel. Den här återställningen tillhandahålls ofta av säkerhetskopiering, återställningskomponenter och procedurer. För organisationer med appar som finns i Azure eller organisationer med hybridappdistributioner finns det andra överväganden och alternativ.
Tillförlitliga appar är:
Motståndskraftig mot komponentfel.
Hög tillgänglighet och kan köras i ett felfritt tillstånd utan betydande stilleståndstid.
För att uppnå önskad motståndskraft och hög tillgänglighet måste du först definiera dina krav.
Kommentar
I den här modulen används termen återhämtning som systemets förmåga att korrekt hantera och återställa från fel, både oavsiktliga och skadliga.
Definiera dina krav
När du definierar dina krav ingår:
Identifiera dina affärsbehov.
Skapa din återhämtningsplan för att tillgodose dessa behov.
Använd följande tabell med överväganden för att ge vägledning om den här processen.
| Övervägande | Beskrivning |
|---|---|
| Vad är dina arbetsbelastningar och deras användning? | En arbetsbelastning är en distinkt funktion eller uppgift som är logiskt separerat från andra uppgifter med avseende på affärslogik och krav på datalagring. Varje arbetsbelastning har förmodligen olika krav för tillgänglighet, skalbarhet, datakonsekvens och haveriberedskap. |
| Vilka är användningsmönstren för dina arbetsbelastningar? | Användningsmönster kan fastställa dina krav. Identifiera skillnader i krav under både kritiska och icke-kritiska perioder. Planera redundans i flera regioner om en region misslyckas för att säkerställa drifttiden. Om du vill minimera kostnaderna under icke-kritiska perioder kan du däremot köra ditt program i en enda region. |
| Vilka är tillgänglighetsmåtten? | Genomsnittlig tid till återställning (MTTR) och genomsnittlig tid mellan fel (MTBF) är de mått som vanligtvis används. MTBF avser hur länge en komponent rimligen kan förväntas hålla mellan avbrott. MTTR är den genomsnittliga tid det tar att återställa en komponent efter ett haveri. Använd dessa mått för att avgöra var du behöver lägga till redundans och för att fastställa serviceavtal (SLA) för kunder. |
| Vilka är återställningsmåtten? | Målet för återställningstid (RTO) är den maximala godkända tiden som en av dina appar kan vara otillgänglig efter en incident. Målet för återställningspunkten (RPO) är den maximala varaktigheten för dataförlust som är acceptabel under en katastrof. Tänk också på målet på återställningsnivå (RLO). Det här måttet bestämmer kornigheten för återställning. Med andra ord, om du måste kunna återställa en servergrupp, en webbapp, en webbplats eller bara ett specifikt objekt. Utför en riskbedömning för att fastställa dessa värden. Se till att du förstår kostnaden och risken för stilleståndstid eller dataförlust i din organisation. |
| Vilka är tillgänglighetsmålen för arbetsbelastningen? | För att säkerställa att din apparkitektur uppfyller dina affärskrav definierar du målavtal för varje arbetsbelastning. Ta med kostnaden och komplexiteten för att uppfylla tillgänglighetskraven samt programberoenden i beräkningen. |
| Vad är dina serviceavtal? | I Azure beskriver serviceavtal Microsofts åtaganden gällande drifttid och anslutning. Om serviceavtalet för en viss tjänst är 99,9 procent bör du förvänta dig att tjänsten är tillgänglig 99,9 procent av tiden. |
Dricks
Om MTTR för någon kritisk komponent i ett scenario med hög tillgänglighet överskrider systemets RTO kan ett fel i systemet orsaka ett oacceptabelt avbrott i verksamheten. Med andra ord kan du inte återställa systemet i den definierade RTO:en.
Definiera dina egna målavtal för varje arbetsbelastning i din lösning genom att svara på föregående frågor. Detta säkerställer att arkitekturen uppfyller dina affärskrav. Om en arbetsbelastning till exempel kräver 99,99 procent drifttid, men är beroende av en tjänst med ett serviceavtal på 99,9 procent, kan tjänsten inte vara en enda felpunkt i systemet.
När du har definierat dina återställningskrav kan du välja en lämplig återställningsteknik.