Planlægning og udrulning af en plan for høj tilgængelighed og disaster recovery, der opfylder alle serviceniveauaftaler, er en ikke-triviel opgave og kræver en meget klar forståelse af SQL Servers oprindelige styrker og svagheder. Når man matcher krav mod en kombination af funktioner, kan nogle af de kritiske detaljer blive sløret over, og i dette indlæg vil jeg gennemgå et par almindelige forvrængninger og dårlige antagelser, der kan snige sig ind i en løsning – hvilket i sidste ende får os til at gå glip af målet på vores restitutionspunkt og restitutionstidsmål. Nogle af de eksempler på forvrængninger eller selvbedrag, jeg beskriver her, kan generaliseres på tværs af forskellige funktioner, og nogle er funktionsspecifikke.
"Vi testede vores katastrofegenopretningsplan, da vi første gang lancerede vores projekt, og vi ved, at det vil fungere"
Jeg har arbejdet med kunder, der faktisk fik deres katastrofeopsvingstilgang "rigtigt" - én gang. Men så snart alle følte sig sikre på effektiviteten af løsningen, blev der ikke udført andre øvelser efter katastrofeopsving igen. Selvfølgelig – i mellemtiden bliver datalaget og applikationen ved med at ændre sig over tid. Disse ændringer introducerer nye objekter og processer, der er kritiske for applikationen. Og selvom alt forbliver statisk efter lanceringen, skal du stadig tage højde for personaleomsætning og varierende færdighedssæt. Kan nutidens personale med succes udføre en disaster recovery-øvelse? Og selv det bedste personale har brug for løbende øvelse.
"Vi vil ikke have noget datatab, fordi vi bruger synkron databasespejling"
Lad os sige, at du bruger synkron databasespejling mellem to SQL Server-instanser, med hver instans i et separat datacenter. Antag i dette eksempel, at transaktionsforsinkelsen er acceptabel på trods af, at dette er en synkron databasespejlingssession med et par miles mellem datacentrene. Du har ikke et vidne i blandingen, fordi du vil kontrollere databasespejlets failover manuelt.
Lad os nu sige, at dit datacenter for gendannelse efter katastrofe forsvinder - men dit primære datacenter er stadig tilgængeligt. Din hoveddatabase er afbrudt fra spejldatabasen, men den accepterer stadig forbindelser og dataændringer. Hvad med "ingen datatab"-kravet nu? Hvis transaktioner kørte mod den afbrudte hovedstol i endnu en time, hvad er din plan, hvis det primære datacenter også går tabt?
"Vores virksomhedsejer siger, at vi kan miste op til 12 timers data"
Det er vigtigt at stille nogle spørgsmål mere end én gang og til mere end én person i en organisation. Hvis nogen fortæller dig, at "12 timers datatab er acceptabelt" - spørg dem igen, eller spørg dem, hvad konsekvensen af dette datatab ville være. Spørg også andre mennesker. De kan give dig et meget strengere krav. Jeg har fundet ud af, at genopretningspunkter kræver nogle forhandlinger og mere end et par tankevækkende, bevidste diskussioner.
"Vi bruger [databasespejling eller tilgængelighedsgrupper], og vi er derfor dækket ind, hvad vi har brug for i tilfælde af en katastrofe"
Databasespejling og tilgængelighedsgrupper kan bestemt bruges til at beskytte dig på databaseniveau, men hvad med alt det andet? Hvad med dine logins? SSIS pakker? Jobs? Ikke-FULDE gendannelsesmodeldatabaser? Tilknyttede servere?
"Vi bruger SQL Server-funktionen XYZ, så vi mister ikke nogen transaktioner under flyvningen"
Nej undskyld. Mens nogle funktioner giver mulighed for gennemsigtig omdirigering, er dette ikke det samme som at bevare og vedholde åbne transaktioner på tidspunktet for failover. Ingen SQL Server-funktion leverer denne funktionalitet i dag.
"Teamet, der understøtter datalaget for denne applikation, hader SQL Server-funktionen XYZ, men vi går videre med det, fordi det er det, der blev anbefalet til os af en ekstern konsulent"
Selvom det ville være rart, hvis folk ikke udviklede specifikke skævheder omkring funktioner i SQL Server, er dette ofte ikke tilfældet. Hvis du forsøger at tvinge løsninger på et personale, der ikke er ombord med dem, risikerer du at få forudbestemt fiasko. Som en del af de HA/DR-øvelser, jeg tidligere har hjulpet med, er jeg altid interesseret i at høre om folks tidligere erfaringer med specifikke funktioner. For eksempel udnytter nogle virksomheder hundredvis af Failover Cluster Instances meget godt – mens andre undgår dem på grund af dårlige erfaringer fra tidligere versioner. Når du planlægger en løsning, kan du ikke ignorere historikken eller dispositionerne hos de ansatte, som i sidste ende vil være ansvarlige for at implementere og understøtte den anbefalede løsning.
"Som DBA beslutter jeg, hvilken HA/DR-teknologi der skal bruges til datalaget, så vi vil fremover bruge tilgængelighedsgrupper"
En databaseadministrator kan potentielt konfigurere databasespejling med ringe eller ingen involvering med andre teams. Nu med tilgængelighedsgrupper, selvom en databaseadministrator kunne gøre det hele på egen hånd, kan de være uklogt at gøre det. Når alt kommer til alt – hvis du implementerer tilgængelighedsgrupper til katastrofegendannelsesformål, vil du have, at alle, der er involveret i en katastrofegendannelse, er opmærksomme på din løsning og de krav, der er nødvendige for at komme online igen og gendanne data. Med tilgængelighedsgrupper skal du tænke på Windows Server Failover Cluster, kvorumskonfigurationer, nodestemmer, tilgængelighedsgruppelytteren og mere. Hvis du har brug for andre til at lette en løsning, skal du være sikker på, at de er involveret i den første anbefaling.
"Vi bruger tilgængelighedsgrupper, så vi kan have skrivebeskyttet tilgængelighed i tilfælde af udfald af vores læse-skrive-replika"
Dette er blot et eksempel på et "hvad nu hvis"-scenarie. Med enhver implementering af funktionalitet vil du gerne forestille dig de forskellige måder, hvorpå fejl kan opstå - og så sørg for at teste det for at sikre, at dine krav stadig bliver opfyldt. For eksempel – hvis du tror, at din SQL Server 2012 tilgængelighedsgruppe asynkrone skrivebeskyttede replikaer vil være tilgængelige, når read-write replikaen ikke er tilgængelig, vil du blive ubehageligt overrasket over at se Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections besked i produktion.
"Vi testede SQL Server-funktionen XYZ, og failover var hurtig, så vi har fastslået, at vi nemt kan opfylde vores mål for genoprettelsestiden"
Lad os sige, at du beslutter dig for at bruge databasespejling for høj tilgængelighed på brugerdatabaseniveau. Du vil have hurtig failover (målt i sekunder), og du ser faktisk hurtig failover under test. Men var det en realistisk test? Udsatte du en betydelig arbejdsbyrde? I eksemplet med databasespejling kan den længste del af din failover-operation være for redo-handlingerne. Hvis du ikke kører realistiske arbejdsbelastninger, så kan du ikke rigtig sige, at din failover faktisk vil være "hurtig".
"Hvis vi har en katastrofe og har brug for at redde og afstemme data, finder vi ud af det, når tiden kommer"
Det her er en hård en. Lad os sige, at du har en katastrofe og har brug for at gøre dit sekundære datacenter operationelt. Du beslutter dig for at tvinge service til de mest kritiske databaser i det sekundære datacenter, og du har nu en opdeling i rækken af dataændringer (nogle uafstemte rækker i det primære datacenter, og nu nye ændringer i det sekundære datacenter). Til sidst bringes dit primære datacenter online – men nu har du data, der skal reddes og afstemmes, før du kan genetablere den overordnede HA/DR-løsning. Hvad laver du? Hvad kan du gøre? Denne diskussion er sjældent nem at have og kan afhænge af flere faktorer, såsom de softwarepakker, du har købt, kompleksiteten af datalaget og de datakonvergensværktøjer, du har til rådighed. Faktisk er diskussionen som regel så svær, at folk slet ikke har den. Men hvis dataene er kritiske nok til, at du har oprettet et sekundært datacenter, bør en vigtig del af diskussionen omfatte, hvordan man bedst kan redde data og også afstemme dem, efter at en katastrofe har fundet sted.
Oversigt
Denne artikel indeholdt blot nogle få eksempler på, hvordan vi kan narre os selv til at tro, at en løsning fuldt ud opfylder deres krav. Selvom det er menneskets natur at gøre dette – når det kommer til tab af data og forretningskontinuitet, vil vores job afhænge af, at vi er mere aggressive i at teste vores egne overbevisninger og antagelser.