DR för Azure Data Platform – Rekommendationer

Lärdomar

1. Se till att alla berörda parter förstår skillnaden mellan hög tillgänglighet (HA) och haveriberedskap (DR): en vanlig fallgrop är att förvirra de två begreppen och matcha de lösningar som är associerade med dem
2. Diskutera med affärsintressenterna om deras förväntningar på följande aspekter för att definiera mål för återställningspunkter (RPO) och mål för återställningstid (RTO):
   1. Hur mycket stilleståndstid de kan tolerera, med tanke på att ju snabbare återställning, desto högre kostnad
   2. Den typ av incidenter som de vill skyddas från och som nämner den relaterade sannolikheten för en sådan händelse. Sannolikheten för att en server går ned är till exempel högre än en naturkatastrof som påverkar alla datacenter i en region
   3. Vilken inverkan har systemet som inte är tillgängligt på deras verksamhet?
   4. OPEX-budgeten för lösningen framöver
3. Överväg vilka degraderade tjänstalternativ som slutanvändarna kan acceptera. Dessa kan omfatta:
   1. Fortfarande har åtkomst till instrumentpaneler för visualisering även utan de senaste data som är, om inmatningspipelines inte fungerar, har slutanvändarna fortfarande åtkomst till sina data
   2. Har läsåtkomst men ingen skrivåtkomst
4. Dina MÅL-RTO- och RPO-mått kan definiera vilken strategi för haveriberedskap du väljer att implementera:
   1. Aktiv/aktiv
   2. Aktiv/passiv
   3. Aktiv/omdistribuera vid haveri
   4. Förlita dig på Microsofts serviceavtal
5. Se till att du förstår alla komponenter som kan påverka tillgängligheten för dina system, till exempel:
   1. Identitetshantering
   2. Nätverkstopologi
   3. Hantering av hemlighet/nyckel
   4. Datakällor
   5. Automation/jobbschemaläggare
   6. Källlagringsplats och distributionspipelines (GitHub, Azure DevOps)
6. Tidig identifiering av avbrott är också ett sätt att minska RTO- och RPO-värden avsevärt. Här följer några aspekter som bör tas upp:
   1. Definiera vad ett avbrott är och hur det mappar till Microsofts definition av ett avbrott. Microsoft-definitionen är tillgänglig på sidan Azure-serviceavtal på produkt- eller tjänstnivå.
   2. Ett effektivt övervaknings- och aviseringssystem med ansvariga team för att granska dessa mått och aviseringar i tid hjälper till att uppnå målet
7. Sammansatta serviceavtal innebär att ju fler komponenter du har i din arkitektur, desto högre är sannolikheten för ett fel. Du kan använda sammansatt serviceavtal för att definiera risken för ett komponentstopp.
8. När det gäller prenumerationsdesign kan ytterligare infrastruktur för haveriberedskap lagras i den ursprungliga prenumerationen. PaaS-tjänster som ADLS Gen2 eller Azure Data Factory har vanligtvis inbyggda funktioner som tillåter redundansväxling till sekundära instanser i andra regioner medan de finns kvar i den ursprungliga prenumerationen. Vissa kunder kanske vill överväga att ha en dedikerad resursgrupp för resurser som endast används i DR-scenarier i kostnadssyfte
   1. Det bör noteras att prenumerationsgränser kan fungera som en begränsning för den här metoden
   2. Andra begränsningar kan vara designkomplexitets- och hanteringskontroller för att säkerställa att DR-resursgrupperna inte används för BAU-arbetsflöden
9. Utforma DR-arbetsflödet baserat på en lösnings kritiskhet och beroenden. Försök till exempel inte återskapa en Azure Analysis Services-instans innan informationslagret är igång eftersom det utlöser ett fel. Lämna utvecklingslabb senare i processen och återställ kärnlösningar för företag först
10. Försök att identifiera återställningsuppgifter som kan parallelliseras mellan lösningar, vilket minskar det totala antalet RTO
11. Om Azure Data Factory används i en lösning ska du inte glömma att inkludera integrationskörningar med egen värd i omfånget. Azure Site Recovery är perfekt för dessa datorer
12. Manuella åtgärder bör automatiseras så mycket som möjligt för att undvika mänskliga fel, särskilt när det är under press. Vi rekommenderar att du:
    1. Implementera resursetablering via Bicep, ARM-mallar eller PowerShell-skript
    2. Anta versionshantering av källkod och resurskonfiguration
    3. Använd CI/CD-versionspipelines i stället för click-ops
13. Eftersom du har en plan för redundans bör du överväga procedurer för att återställa till de primära instanserna
14. Definiera tydliga indikatorer/mått för att verifiera att redundansväxlingen har lyckats och att lösningarna är igång eller att situationen är tillbaka till det normala (även kallat primär funktionell)
15. Bestäm om dina serviceavtal ska förbli desamma efter en redundansväxling eller om du tillåter degraderad tjänst
    1. Det här beslutet beror i hög grad på vilken affärstjänstprocess som stöds. Redundansväxlingen för ett rumsbokningssystem ser till exempel mycket annorlunda ut än ett kärndriftsystem
16. En RTO/RPO-definition bör baseras på specifika användarscenarier/lösningar i stället för på infrastrukturnivå. Det ger dig mer detaljerad information om vilka processer och komponenter som ska återställas först om det uppstår ett avbrott eller en katastrof
17. Se till att du inkluderar kapacitetskontroller i målregionen innan du går vidare med en redundansväxling: Om det uppstår en större katastrof bör du tänka på att många kunder försöker redundansväxlar till samma kopplade region samtidigt, vilket kan orsaka fördröjningar eller konkurrens vid etablering av resurserna
    1. Om dessa risker är oacceptabla bör antingen en aktiv/aktiv eller aktiv/passiv DR-strategi övervägas
18. En haveriberedskapsplan bör skapas och underhållas för att dokumentera återställningsprocessen och åtgärdsägarna. Tänk också på att personer kan vara ledighetsbara, så se till att inkludera sekundära kontakter
19. Regelbundna haveriberedskapstest bör utföras för att verifiera arbetsflödet för haveriberedskapsplanen, att det uppfyller den nödvändiga RTO/RPO och för att träna de ansvariga teamen
    1. Säkerhetskopiering av data och konfiguration bör också regelbundet testas för att säkerställa att de är "lämpliga för ändamålet" för att stödja återställningsaktiviteter
20. Tidigt samarbete med team som ansvarar för nätverks-, identitets- och resursetablering möjliggör en överenskommelse om den mest optimala lösningen när det gäller:
    1. Så här omdirigerar du användare och trafik från din primära till den sekundära platsen. Begrepp som DNS-omdirigering eller användning av specifika verktyg som Azure Traffic Manager kan utvärderas
    2. Så här ger du åtkomst och rättigheter till den sekundära platsen i tid och på ett säkert sätt
21. Vid en katastrof är effektiv kommunikation mellan de många berörda parterna nyckeln till ett effektivt och snabbt genomförande av planen:
    1. Beslutsfattare
    2. Incidenthanteringsteam
    3. Påverkad intern målgrupp
    4. Externa team
22. Orkestrering av de olika resurserna vid rätt tidpunkt säkerställer effektiviteten i haveriberedskapsplanens körning

Att tänka på

Antimönster

• Kopiera/klistra in den här artikelserien Den här artikelserien är avsedd att ge vägledning till kunder som letar efter nästa detaljnivå för en Azure-specifik DR-process. Därför baseras den på microsofts allmänna IP- och referensarkitekturer snarare än någon enskild kundspecifik Azure-implementering.
  Även om informationen som tillhandahålls hjälper till att stödja en solid grundläggande förståelse, måste kunderna tillämpa sin egen specifika kontext, implementering och krav innan de får en dr-strategi och process som passar för ändamålet.

• Att behandla dr som en teknikbaserad process Affärsintressenter spelar en viktig roll när det gäller att definiera kraven för dr och slutföra de affärsvalideringssteg som krävs för att bekräfta en tjänståterställning. Att se till att affärsintressenter är engagerade i alla DR-aktiviteter ger en dr-process som är "lämplig för ändamålet", representerar affärsvärde och är körbar.

• "Ange och glöm" DR-planer Azure utvecklas ständigt, liksom enskilda kunders användning av olika komponenter och tjänster. En dr-process som är lämplig för ändamålet måste utvecklas med dem. Antingen via SDLC-processen eller regelbundna granskningar bör kunderna regelbundet gå tillbaka till sin DR-plan. Målet är att säkerställa att tjänståterställningsplanen är giltig och att alla deltan mellan komponenter, tjänster eller lösningar har redovisats.

• Pappersbaserade utvärderingar Även om slutpunkt till slutpunkt-simulering av en DR-händelse kommer att vara svår i ett modernt data eco-system, bör ansträngningar göras för att komma så nära en fullständig simulering över berörda komponenter som möjligt. Regelbundet schemalagda övningar skapar det "muskelminne" som krävs av organisationen för att kunna köra DR-planen med tillförsikt.

• Om microsoft förlitar sig på att göra allt inom Microsoft Azure-tjänsterna finns det en tydlig ansvarsfördelning som är förankrad i den molntjänstnivå som används: Även om en fullständig SaaS-stack används behåller kunden fortfarande ansvaret för att säkerställa att konton, identiteter och data är korrekta/uppdaterade, tillsammans med de enheter som används för att interagera med Azure-tjänsterna.

Händelseomfång och strategi

Omfång för haveriberedskap

Olika händelser har olika effektomfång och därför ett annat svar. Följande diagram visar detta för en katastrofhändelse:

Alternativ för haveristrategi

Det finns fyra övergripande alternativ för en strategi för haveriberedskap:

• Vänta på Microsoft – Som namnet antyder är lösningen offline tills den fullständiga återställningen av tjänster i den berörda regionen av Microsoft. När lösningen har återställts verifieras den av kunden och uppdateras sedan för tjänståterställning
• Omdistribuera vid haveri – Lösningen distribueras manuellt till en tillgänglig region från grunden, efter en katastrofhändelse
• Warm Spare (Aktiv/Passiv) – En sekundär värdbaserad lösning skapas i en alternativ region och komponenter distribueras för att garantera minimal kapacitet. Komponenterna tar dock inte emot produktionstrafik. Sekundära tjänster i den alternativa regionen kan vara "avstängda" eller köras på en lägre prestandanivå tills en DR-händelse inträffar
• Hot Spare (Aktiv/Aktiv) – Lösningen finns i en aktiv/aktiv installation i flera regioner. Den sekundära värdbaserade lösningen tar emot, bearbetar och hanterar data som en del av det större systemet

Påverkan på DR-strategin

Även om driftskostnaderna som tillskrivs de högre nivåerna av tjänståterhämtning ofta dominerar KDD (Key Design Decision) för en DR-strategi. Det finns andra viktiga överväganden.

Dr-scenariot för det här arbetsexemplet är ett fullständigt regionalt avbrott i Azure som direkt påverkar den primära region som är värd för Contoso Data Platform. För det här avbrottsscenariot är den relativa effekten på de fyra högnivåstrategierna för haveriberedskap:

Klassificeringsnyckel

• Mål för återställningstid (RTO) – den förväntade förflutna tiden från haverihändelsen till plattformstjänstens återställning
• Komplexitet att köra – komplexiteten för organisationen att köra återställningsaktiviteterna
• Komplexitet att implementera – komplexiteten för organisationen att implementera DR-strategin
• Påverkan på kunder – den direkta effekten för kunderna i dataplattformstjänsten från DR-strategin
• Opex-kostnad över rad – den extra kostnad som förväntas av implementeringen av den här strategin, till exempel ökad månatlig fakturering för Azure för ytterligare komponenter och ytterligare resurser som krävs för att stödja

Nästa steg

Nu när du har lärt dig om rekommendationerna i scenariot kan du lära dig hur du distribuerar det här scenariot

Relaterade resurser

• DR för Azure Data Platform – Översikt
• DR för Azure Data Platform – Arkitektur
• DR för Azure Data Platform – Scenarioinformation
• DR för Azure Data Platform – sammanfattning