Het plannen en uitrollen van een plan voor hoge beschikbaarheid en noodherstel dat aan alle serviceniveau-overeenkomsten voldoet, is een niet-triviale onderneming en vereist een zeer duidelijk begrip van de sterke en zwakke punten van SQL Server. Bij het vergelijken van vereisten met een combinatie van functies, kunnen enkele van de kritieke details worden verdoezeld, en in dit bericht zal ik een paar veelvoorkomende vervormingen en slechte aannames doornemen die in een oplossing kunnen kruipen - waardoor we uiteindelijk het doel missen op onze doelstellingen voor herstelpunten en hersteltijden. Sommige van de voorbeelden van vervormingen of zelfbedrog die ik hier beschrijf, kunnen worden gegeneraliseerd over verschillende functies en sommige zijn functiespecifiek.
"We hebben ons noodherstelplan getest toen we ons project voor het eerst lanceerden en we weten dat het zal werken"
Ik heb een keer met klanten gewerkt die inderdaad hun aanpak voor rampenherstel "goed" hadden. Maar toen iedereen vertrouwen had in de doeltreffendheid van de oplossing, werden er geen andere ramphersteloefeningen meer uitgevoerd. Natuurlijk - in de tussentijd blijven de gegevenslaag en de applicatie in de loop van de tijd veranderen. Die veranderingen introduceren nieuwe objecten en processen die essentieel zijn voor de applicatie. En zelfs als alles na de lancering statisch blijft, moet je nog steeds rekening houden met personeelsverloop en wisselende vaardigheden. Kan het personeel van vandaag met succes een ramphersteloefening uitvoeren? En zelfs het beste personeel heeft voortdurende oefening nodig.
"We hebben geen gegevensverlies omdat we synchrone database-mirroring gebruiken"
Stel dat u synchrone database-mirroring gebruikt tussen twee SQL Server-instanties, waarbij elke instantie zich in een afzonderlijk datacenter bevindt. Neem in dit voorbeeld aan dat de transactielatentie acceptabel is, ondanks dat dit een synchrone database-mirroringsessie is met enkele kilometers tussen de datacenters. U hebt geen getuige in de mix omdat u de failover van de database-mirror handmatig wilt beheren.
Stel nu dat uw datacenter voor noodherstel verdwijnt, maar dat uw primaire datacenter nog steeds beschikbaar is. Uw hoofddatabase is losgekoppeld van de spiegeldatabase, maar accepteert nog steeds verbindingen en gegevenswijzigingen. Hoe zit het nu met de eis "geen gegevensverlies"? Als transacties nog een uur lopen tegen de niet-verbonden principal, wat is uw plan als het primaire datacenter ook verloren gaat?
"Onze bedrijfseigenaar zegt dat we tot 12 uur aan gegevens kunnen verliezen"
Het is belangrijk om sommige vragen meer dan eens en aan meer dan één persoon in een organisatie te stellen. Als iemand u vertelt dat "12 uur gegevensverlies acceptabel is", vraag hem dan opnieuw, of vraag hem wat de gevolgen van dat gegevensverlies zouden zijn. Vraag het ook aan andere mensen. Ze kunnen u een veel strengere eis stellen. Ik heb gemerkt dat doelstellingen voor herstelpunten enige onderhandeling en meer dan een paar doordachte, weloverwogen discussies vereisen.
"We gebruiken [database mirroring of beschikbaarheidsgroepen] en dus zijn we gedekt voor wat we nodig hebben in het geval van een ramp"
Database-mirroring en beschikbaarheidsgroepen kunnen zeker worden gebruikt om u op databaseniveau te beschermen, maar hoe zit het met al het andere? Hoe zit het met uw inloggegevens? SSIS-pakketten? Banen? Niet-VOLLEDIGE herstelmodeldatabases? Gelinkte servers?
"We gebruiken SQL Server-functie XYZ, dus we verliezen geen transacties tijdens de vlucht"
Nee sorry. Hoewel sommige functies transparante omleiding mogelijk maken, is dit niet hetzelfde als het behouden en volhouden van open transacties op het moment van failover. Geen enkele SQL Server-functie biedt deze functionaliteit vandaag.
"Het team dat de gegevenslaag voor deze applicatie ondersteunt, heeft een hekel aan SQL Server-functie XYZ, maar we gaan ermee door omdat dat is wat ons werd aanbevolen door een externe consultant"
Hoewel het leuk zou zijn als mensen geen specifieke vooroordelen zouden ontwikkelen rond functies in SQL Server, is dit vaak niet het geval. Als u oplossingen probeert op te dringen aan een staf die niet met hen aan boord is, loopt u het risico van een vooraf bepaalde mislukking. Als onderdeel van de HA/DR-oefeningen waarmee ik in het verleden heb geholpen, ben ik altijd geïnteresseerd om te horen over eerdere ervaringen van mensen met specifieke functies. Sommige bedrijven maken bijvoorbeeld heel goed gebruik van honderden Failover Cluster-instanties, terwijl andere ze vermijden vanwege slechte ervaringen met eerdere versies. Bij het plannen van een oplossing kunt u niet voorbijgaan aan de geschiedenis of de aanleg van het personeel dat uiteindelijk verantwoordelijk zal zijn voor het implementeren en ondersteunen van de aanbevolen oplossing.
"Als DBA bepaal ik welke HA/DR-technologie ik ga gebruiken voor de datalaag, dus we gaan in de toekomst beschikbaarheidsgroepen gebruiken"
Een databasebeheerder zou mogelijk database-mirroring kunnen opzetten met weinig of geen betrokkenheid bij andere teams. Nu met beschikbaarheidsgroepen, zelfs als een databasebeheerder het allemaal alleen zou kunnen doen, zou het onverstandig kunnen zijn om dit te doen. Immers:als u beschikbaarheidsgroepen inzet voor noodherstel, wilt u dat iedereen die betrokken is bij een noodhersteloperatie op de hoogte is van uw oplossing en de vereisten die nodig zijn om weer online te gaan en gegevens te herstellen. Met beschikbaarheidsgroepen moet u nadenken over het Windows Server Failover Cluster, quorumconfiguraties, knooppuntstemmen, de beschikbaarheidsgroeplistener en meer. Als je andere mensen nodig hebt om een oplossing te vergemakkelijken, zorg er dan voor dat ze betrokken zijn bij de eerste aanbeveling.
"We gebruiken beschikbaarheidsgroepen zodat we alleen-lezen beschikbaarheid kunnen hebben in het geval van een storing van onze lees-schrijfreplica"
Dit is slechts een voorbeeld van een 'wat als'-scenario. Bij elke implementatie van functionaliteit moet u zich de verschillende manieren voorstellen waarop storingen kunnen optreden - en deze vervolgens testen om er zeker van te zijn dat nog steeds aan uw vereisten wordt voldaan. Als u bijvoorbeeld denkt dat uw SQL Server 2012-beschikbaarheidsgroep asynchrone alleen-lezen replica's beschikbaar zullen zijn wanneer de lees-schrijfreplica niet beschikbaar is, zult u onaangenaam verrast zijn om de Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections bericht in productie.
"We hebben SQL Server-functie XYZ getest en de failover was snel, dus we hebben vastgesteld dat we onze doelstellingen voor hersteltijd gemakkelijk kunnen halen"
Stel dat u besluit databasemirroring te gebruiken voor hoge beschikbaarheid op gebruikersdatabaseniveau. U wilt een snelle failover (gemeten in seconden) en u ziet inderdaad een snelle failover tijdens het testen. Maar was het een realistische test? Had u een aanzienlijke werkdruk? In het voorbeeld van database-mirroring kan het langste deel van uw failover-bewerking voor de bewerkingen opnieuw zijn. Als u geen realistische workloads aanstuurt, kunt u niet echt zeggen dat uw failover daadwerkelijk "snel" zal zijn.
"Als we een ramp hebben en gegevens moeten redden en met elkaar in overeenstemming moeten brengen, komen we er wel uit wanneer de tijd daar is"
Dit is een lastige. Stel dat u een ramp heeft en uw secundaire datacenter operationeel moet maken. U besluit service te forceren voor de meest kritieke databases in het secundaire datacenter en u heeft nu een splitsing in de lijn van gegevenswijzigingen (enkele niet-afgestemde rijen in het primaire datacenter en nu nieuwe wijzigingen in het secundaire datacenter). Uiteindelijk wordt uw primaire datacenter online gebracht, maar nu heeft u gegevens die moeten worden geborgen en afgestemd voordat u de algehele HA/DR-oplossing opnieuw kunt opzetten. Wat doe je? Wat kan je doen? Deze discussie is zelden gemakkelijk te voeren en kan afhankelijk zijn van verschillende factoren, zoals de softwarepakketten die u hebt gekocht, de complexiteit van de gegevenslaag en de gegevensconvergentietools die tot uw beschikking staan. In feite is de discussie meestal zo moeilijk dat mensen hem helemaal niet hebben. Maar als de gegevens voor u kritiek genoeg zijn om een secundair datacenter op te zetten, dan zou een belangrijk onderdeel van de discussie moeten zijn hoe u gegevens het beste kunt redden en ook kunt afstemmen nadat zich een ramp heeft voorgedaan.
Samenvatting
Dit artikel bevatte slechts een paar voorbeelden van hoe we onszelf kunnen wijsmaken dat een oplossing volledig aan hun eisen voldoet. Hoewel het de menselijke natuur is om dit te doen - als het gaat om gegevensverlies en bedrijfscontinuïteit, zullen onze banen ervan afhangen dat we agressiever zijn in het testen van onze eigen overtuigingen en aannames.