Beskriva mål för återställningstid och mål för återställningspunkt
Att förstå mål för återställningstid och återställningspunkter är avgörande för din hadr-plan (high availability and disaster recovery) eftersom de är grunden för alla tillgänglighetslösningar.
Mål för återställningstid
Mål för återställningstid (RTO) är den maximala tid som är tillgänglig för att aktivera resurser efter ett avbrott eller problem. Om den processen tar längre tid än rto kan det få konsekvenser som ekonomiska påföljder, arbete som inte kan utföras och så vidare. RTO kan anges för hela lösningen, som innehåller alla resurser, samt för enskilda komponenter som SQL Server-instanser och databaser.
Mål för återställningspunkt
Mål för återställningspunkt (RPO) är den tidpunkt då en databas ska återställas och motsvarar den maximala mängden dataförlust som företaget är villigt att acceptera. Anta till exempel att en virtuell IaaS-dator som innehåller SQL Server upplever ett avbrott kl. 10:00 och att databaserna i SQL Server-instansen har ett RPO på 15 minuter. Oavsett vilken funktion eller teknik som används för att ta tillbaka den instansen och dess databaser, är förväntningarna att det kommer att finnas högst 15 minuters data förlorade. Det innebär att databasen kan återställas till 09:45 eller senare för att säkerställa minimalt till inget dataförlustmöte som angav RPO. Det kan finnas faktorer som avgör om det RPO kan uppnås.
Definiera mål för återställningstid och återställningspunkt
RTO:er och RRPOs drivs av affärskrav men baseras också på olika tekniska och andra faktorer, till exempel administratörernas färdigheter och förmågor (inte bara dbas). Även om företaget kanske inte vill ha någon avbrottstid eller noll dataförlust, kanske det inte är realistiskt eller möjligt av olika skäl. Att fastställa lösningens RTO och RPO bör vara en öppen och ärlig diskussion mellan alla inblandade parter.
En av de aspekter som är avgörande för både RTO och RPO är att känna till kostnaden för stilleståndstid. Om du definierar det talet och den övergripande effekten som är nere eller otillgänglig har för verksamheten är det lättare att definiera lösningar. Om företaget till exempel kan förlora 10 000 per timme eller kan bötfällas av en myndighet om något inte kunde bearbetas, är det ett mätbart sätt att definiera RTO och RPO. Utgifterna för lösningen bör vara proportionella mot mängden eller kostnaden för stilleståndstid. Om din HADR-lösning kostar $X, men du bara påverkas i några sekunder i stället för timmar eller dagar när ett problem uppstår, har den betalat för sig själv.
Från en icke-affärssynpunkt bör RTO definieras på komponentnivå (till exempel SQL Server) samt för hela programarkitekturen. Förmågan att återhämta sig från ett avbrott är bara lika bra som dess svagaste länk. Om TILL exempel SQL Server och dess databaser kan tas online på fem minuter, men det tar programservrar 20 minuter att göra detsamma, skulle den totala RTO:en vara 20 minuter, inte fem. SQL Server-miljön kan fortfarande ha en RTO på fem minuter. Den ändrar fortfarande inte den totala tiden för återställning.
RPO handlar specifikt om data och påverkar direkt utformningen av en HADR-lösning samt administrativa principer och procedurer. De funktioner som används måste ha stöd för både RTO och RRPOs som har definierats. Om säkerhetskopieringar av transaktionsloggar till exempel schemaläggs var 30:e minut, men det finns ett RPO på 15 minuter, kan en databas bara återställas till den senaste tillgängliga säkerhetskopieringen av transaktionsloggen, vilket i värsta fall skulle vara 30 minuter sedan. Den här tidpunkten förutsätter inga andra problem och säkerhetskopiorna har testats och är kända för att vara bra. Det är svårt att testa varje säkerhetskopia som genereras för varje databas i din miljö, men säkerhetskopieringar är bara filer i ett filsystem. Utan att göra åtminstone periodiska återställningar finns det ingen garanti för att de är bra. Att köra kontroller under säkerhetskopieringsprocessen kan ge dig viss grad av förtroende.
De specifika funktioner som används, till exempel en AlwaysOn-tillgänglighetsgrupp (AG) eller en AlwaysOn-redundansklusterinstans (FCI) påverkar också dina RTO:er och RRPOs. Beroende på hur funktionerna konfigureras kan IaaS- eller PaaS-lösningar redundansväxla automatiskt till en annan plats, vilket kan leda till längre driftstopp. Genom att definiera RTO och RPO kan den tekniska lösning som stöder detta krav utformas med vetskap om ersättningar för tids- och dataförlust. Om dessa avvecklingar är orealistiska måste rtos och RRPOs justeras i enlighet med detta. Om det till exempel finns en önskad RTO på två timmar, men en säkerhetskopia tar tre timmar att kopiera till målservern för återställning, har RTO redan missats. Dessa typer av faktorer måste tas med i beräkningen när du fastställer dina RTO:er och RRPOs.
Det bör finnas RTO:er och RRPO:er som definierats för både HA och DR. Ha anses vara en mer lokaliserad händelse som kan återställas från enklare. Ett exempel på hög tillgänglighet skulle vara en tillgänglighetsgrupp som automatiskt redigerar från en replik till en annan i en Azure-region. Det kan ta några sekunder, och då måste du se till att programmet kan ansluta efter redundansväxlingarna. SQL Server-stilleståndstiden skulle vara minimal. En lokal RTO eller RPO kan eventuellt mätas i minuter beroende på lösningens eller systemets kritiska karaktär.
DR skulle likna att ta upp ett helt nytt datacenter. Det finns massor av bitar i pusslet; SQL Server är bara en komponent. Det kan ta timmar eller längre att få allt online. Det är därför rtos och RRPOs är separata. Även om många av de tekniker och funktioner som används för HA och DR är desamma, är det inte säkert att den aktuella ansträngningsnivån och tiden är det.
Alla RTO:er och RRPO:er bör formellt dokumenteras och revideras regelbundet eller efter behov. När de har dokumenterats kan du fundera över vilka tekniker och funktioner du kan använda för arkitekturen.