Plánování a zavádění plánu vysoké dostupnosti a obnovy po havárii, který splňuje všechny smlouvy o úrovni služeb, je netriviální záležitost a vyžaduje velmi jasné pochopení nativních silných a slabých stránek SQL Serveru. Při porovnávání požadavků s kombinací funkcí mohou být některé kritické detaily přehlédnuty a v tomto příspěvku projdu několika běžnými zkresleními a špatnými předpoklady, které se mohou vloudit do řešení – což nakonec způsobí, že mineme cíl. o našich cílech bodů obnovy a doby obnovy. Některé příklady zkreslení nebo sebeklamů, které zde podrobně uvádím, lze zobecnit napříč různými funkcemi a některé jsou specifické pro jednotlivé funkce.
"Při prvním spuštění projektu jsme testovali náš plán obnovy po havárii a víme, že bude fungovat."
Pracoval jsem s klienty, kteří skutečně dostali svůj přístup k obnově po havárii „správně“ – jednou. Jakmile si však všichni byli jisti účinností řešení, žádná další cvičení obnovy po havárii již nebyla provedena. Samozřejmě – mezitím se datová vrstva a aplikace v průběhu času mění. Tyto změny zavádějí nové objekty a procesy, které jsou pro aplikaci zásadní. A i když vše zůstane po spuštění statické, stále musíte počítat s personální fluktuací a různými sadami dovedností. Mohou dnešní zaměstnanci úspěšně provést cvičení obnovy po havárii? A i ten nejlepší personál potřebuje neustálou praxi.
"Nedojde ke ztrátě dat, protože používáme synchronní zrcadlení databáze"
Řekněme, že používáte synchronní zrcadlení databáze mezi dvěma instancemi SQL Server, přičemž každá instance je v samostatném datovém centru. V tomto příkladu předpokládejme, že latence transakce je přijatelná, přestože se jedná o relaci synchronního zrcadlení databáze s několika mil mezi datovými centry. V mixu nemáte svědka, protože chcete řídit převzetí služeb při selhání zrcadlení databáze ručně.
Nyní řekněme, že vaše datové centrum pro obnovu po havárii odešlo – ale vaše primární datové centrum je stále dostupné. Vaše hlavní databáze je odpojena od zrcadlové databáze, ale stále přijímá připojení a úpravy dat. Jak je to nyní s požadavkem „bez ztráty dat“? Pokud transakce probíhaly proti odpojenému principálovi další hodinu, jaký je váš plán, pokud dojde také ke ztrátě primárního datového centra?
„Vlastník naší firmy říká, že můžeme ztratit až 12 hodin dat“
Je důležité položit některé otázky více než jednou a více než jednomu jednotlivci v organizaci. Pokud vám někdo řekne, že „12hodinová ztráta dat je přijatelná“ – zeptejte se ho znovu nebo se ho zeptejte, jaké by byly důsledky této ztráty dat. Zeptejte se i ostatních lidí. Mohou vám dát mnohem přísnější požadavky. Zjistil jsem, že cíle bodů obnovy vyžadují určité vyjednávání a více než několik promyšlených a promyšlených diskuzí.
„Používáme [zrcadlení databáze nebo skupiny dostupnosti], takže máme pokryto, co potřebujeme v případě katastrofy.“
Zrcadlení databáze a skupiny dostupnosti lze jistě použít k ochraně na úrovni databáze, ale co všechno ostatní? A co vaše přihlašovací údaje? SSIS balíčky? Pracovní místa? Neúplné databáze modelu obnovy? Propojené servery?
"Používáme funkci SQL Server XYZ, takže nepřijdeme o žádné transakce během letu"
Ne Promiň. I když některé funkce umožňují transparentní přesměrování, není to totéž jako zachování a zachování otevřených transakcí v době převzetí služeb při selhání. Tuto funkci dnes neposkytuje žádná funkce SQL Server.
"Tým podporující datovou vrstvu pro tuto aplikaci nenávidí funkci SQL Server XYZ, ale my s ní jdeme kupředu, protože nám to doporučil externí konzultant"
I když by bylo hezké, kdyby lidé nevytvářeli specifické předsudky týkající se funkcí v SQL Server, často tomu tak není. Pokud se pokusíte vnutit řešení personálu, který s nimi není na palubě, vystavujete se riziku předem určeného selhání. V rámci cvičení HA/DR, se kterými jsem v minulosti pomáhal, mě vždy zajímá, jaké mají lidé minulé zkušenosti s konkrétními funkcemi. Některé společnosti například velmi dobře využívají stovky instancí Failover Clusteru – zatímco jiné se jim vyhýbají kvůli špatným zkušenostem z předchozích verzí. Při plánování řešení nemůžete ignorovat historii ani predispozice personálu, který bude nakonec odpovědný za nasazení a podporu doporučeného řešení.
"Jako DBA rozhoduji, kterou technologii HA/DR použít pro datovou vrstvu, takže v budoucnu budeme používat skupiny dostupnosti"
Správce databáze by mohl potenciálně nastavit zrcadlení databáze s malým nebo žádným zapojením ostatních týmů. Nyní se skupinami dostupnosti, i kdyby správce databáze mohl dělat vše sám, nemusí být moudré to dělat. Koneckonců – pokud nasazujete skupiny dostupnosti pro účely obnovy po havárii, budete chtít, aby každý, kdo se účastní operace obnovy po havárii, věděl o vašem řešení a o požadavcích, které jsou potřeba k úspěšnému návratu online a obnově dat. Se skupinami dostupnosti budete muset myslet na cluster Windows Server Failover Cluster, konfigurace kvora, hlasování uzlů, posluchač skupiny dostupnosti a další. Pokud budete potřebovat další lidi, aby usnadnili řešení, ujistěte se, že jsou zapojeni do počátečního doporučení.
"Používáme skupiny dostupnosti, abychom mohli mít dostupnost pouze pro čtení v případě výpadku naší repliky pro čtení a zápis"
Toto je jen jeden příklad scénáře „co kdyby“. S jakoukoli implementací funkcí si budete chtít představit různé způsoby, jak může dojít k selhání – a pak to nezapomeňte otestovat, abyste se ujistili, že vaše požadavky jsou stále splněny. Například – pokud si myslíte, že asynchronní repliky skupiny dostupnosti SQL Server 2012 budou dostupné pouze pro čtení, když replika pro čtení a zápis nebude k dispozici, budete nepříjemně překvapeni, když uvidíte Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections zpráva ve výrobě.
"Testovali jsme funkci SQL Server XYZ a převzetí služeb při selhání bylo rychlé, takže jsme zjistili, že naše cíle doby obnovy můžeme snadno splnit."
Řekněme, že se rozhodnete použít zrcadlení databáze pro vysokou dostupnost na úrovni uživatelské databáze. Chcete rychlé převzetí služeb při selhání (měřeno v sekundách) a během testování skutečně vidíte rychlé převzetí služeb při selhání. Ale byl to realistický test? Tlačili jste na velkou zátěž? V příkladu zrcadlení databáze může být nejdelší částí vaší operace převzetí služeb při selhání operace opakování. Pokud nevyužíváte realistické pracovní zatížení, nemůžete skutečně říci, že vaše převzetí služeb při selhání bude skutečně „rychlé“.
"Pokud dojde ke katastrofě a potřebujeme zachránit a sladit data, přijdeme na to, až přijde čas"
Tohle je těžké. Řekněme, že máte katastrofu a potřebujete zprovoznit sekundární datové centrum. Rozhodnete se vynutit službu pro nejkritičtější databáze v sekundárním datovém centru a nyní máte rozdělení v řadě úprav dat (některé nesrovnané řádky v primárním datovém centru a nyní nové úpravy v sekundárním datovém centru). Nakonec je vaše primární datové centrum zprovozněno online – ale nyní máte data, která je třeba zachránit a uvést do souladu, než budete moci znovu vytvořit celkové řešení HA/DR. Co děláš? Co můžeš udělat? Tato diskuse je zřídkakdy snadná a může záviset na několika faktorech, jako jsou softwarové balíčky, které jste si zakoupili, složitost datové vrstvy a nástroje pro konvergenci dat, které máte k dispozici. Ve skutečnosti je diskuse obvykle tak obtížná, že ji lidé vůbec nemají. Pokud jsou však data dostatečně kritická na to, abyste mohli zřídit sekundární datové centrum, pak by klíčová část diskuse měla zahrnovat, jak nejlépe data zachránit a také je sladit poté, co došlo ke katastrofě.
Shrnutí
Tento článek obsahoval jen několik příkladů toho, jak se můžeme oklamat a myslet si, že řešení plně vyhovuje jejich požadavkům. I když je to v lidské přirozenosti dělat to – pokud jde o ztrátu dat a kontinuitu podnikání, naše práce bude záviset na tom, abychom byli agresivnější při testování našich vlastních přesvědčení a předpokladů.