Jak docílit vysoké dostupnosti v MS SQL Server

Microsoft SQL Server je široce využívané řešení pro ukládání, správu a zpracování dat v podnikovém prostředí. Dostupný je v edicích Express, Developer, Web, Standard a Enterprise. Edice Standard nabízí funkcionality z oblasti správy dat, Business Intelligence i nástroje pro vysokou dostupnost, které slušně pokryjí potřeby středně velkých firem.

Právě vysoká dostupnost a obnova po havárii (disaster recovery) jsou často diskutované aspekty, které nemají jednoznačné řešení. Implementaci totiž ovlivňuje celá řada faktorů majících dopad na výslednou funkčnost i stabilitu databáze. V tomto článku se proto podíváme na:

• způsoby, kterými jde zajistit vysokou dostupnost v SQL Server Standard;
• omezení pro využití technologií v edici Standard;
• technické aspekty nasazení metod v praxi;
• porovnání vlastností jednotlivých metod;
• doporučení pro výběr vhodné technologie.

Čtyři metody pro vysokou dostupnost v SQL Server Standard

V edici SQL Standard je k dispozici několik metod, pomocí nichž lze zvýšit odolnost databáze proti výpadku a ztrátě dat. K zajištění vysoké dostupnosti v pravém slova smyslu slouží technologie Always On Basic Availability Groups. Širší škálu problémů pak řeší replikace, Database Mirroring a Log Shipping.

SQL Always On Availability Groups a Failover

Always On byla do edice Standard zařazena od verze 2016. Konkrétně se jedná o funkci Basic Availability Groups, což je jednodušší varianta Always On Availability Groups, dostupné pouze v Enterprise edici. Basic Availability Groups umožňují nastavení vysoké dostupnosti pro jednotlivé databáze a Always On Failover Cluster Instances zase automatické spuštění provozu na záložním serveru.

V rámci SQL Server Standard lze provozovat Always On na dvou serverech (nodech). Jeden ze serverů vždy plní primární a druhý sekundární roli, přičemž si transparentně předávají HA IP adresu. Databáze, která na těchto serverech běží, se z primárního serveru kopíruje na sekundární. To může probíhat buď synchronně, nebo asynchronně podle konkrétní konfigurace.

Sekundární server udržuje kopii databáze, ale zůstává v neaktivním a nedostupném stavu, dokud nedostane pokyn k převzetí provozu. K tomu dojde například v případě hardwarové závady na primárním serveru. Díky transparentní IP adrese se role mezi primárním a sekundárním serverem přepnou v reálném čase. V praxi to znamená, že veškerý provoz se automaticky přesměruje na sekundární server a tato změna proběhne zcela bez datových ztrát a bez dopadu na klienta.

Database Mirroring v SQL

Mirroring neboli zrcadlení je technika, která pomáhá posílit dostupnost SQL databáze udržováním jejích dvou kopií na oddělených serverových instancích.

Mirroring je předchůdcem technologie Always On, jež má velmi podobné, avšak propracovanější funkce. Mirroring kupříkladu disponuje pouze omezenou možností automatického failoveru. Je to z důvodu absence transparentní IP adresy. Na úrovni klienta je proto potřeba adresu buď změnit, nebo mít k dispozici obě.

V edici SQL Standard je Mirroring dostupný pouze při nastavení režimu „Full“ u Recovery modelu, který umožňuje synchronní kopírování dat. Kvůli svým nedostatkům je však Mirroring na ústupu a z budoucích verzí SQL Serveru bude pravděpodobně vyřazen. Také proto není příliš vhodný pro nasazení v nových prostředích.

SQL Replication

Také replikace umožňuje kopírování databázových objektů z jedné instance do druhé. Na rozdíl od předchozích nemá vůbec schopnost failoveruFailoverFailover představuje proces, kdy v případě výpadku primárního zdroje dochází k přesměrování provozu na záložní zdroj.více. V případě selhání se musí změnit IP adresy serverů nebo rekonfigurovat databázoví klienti, což negativně ovlivňuje dobu výpadku.

Data lze replikovat pouze asynchronně např. pomocí transakční replikace. Objekty se při ní kopírují s několikavteřinovým zpožděním z publikace (zdrojové databáze) do jednoho nebo několika odběratelů.

V některých případech ale dochází k vícenásobným změnám dat na několika databázových instancích současně. Tady se pro zachování konzistence využívá slučovací replikace. Při změně záznamu na několika místech přijme slučovací agent data ze všech směrů, vyřeší konfliktní situace a změny provedené na všech instancích spojí do jednoho datasetu. Vše probíhá podle předem definovaných pravidel, která nesou informaci o tom, jaká změna má přednost. Oba přístupy k replikaci jsou v edici Standard dostupné bez omezení.

SQL Log Shipping

Log Shipping nepracuje přímo s databázovými objekty, ale se záznamy událostí, k nimž v databázi došlo. Tyto záznamy v podobě transakčních logů automaticky posílá z primární databázové instance do jedné nebo několika dalších (sekundárních), kde jsou uchovávány v podobě repliky.

K posílání dochází v pravidelných intervalech, které se nastavují pro každé řešení individuálně. Nejčastěji to bývá po 15 minutách. Nicméně záleží na tom, jaké má organizace požadavky na RPORPOHodnota RPO udává, ke kterému bodu je v případě výpadku možné data obnovitvíce.

Do celého procesu lze zahrnout ještě monitorovací server, jehož úlohou je zaznamenávat stav a historii operací a upozorňovat na případné chyby.

Log Shipping tedy nezajišťuje primárně vysokou dostupnost, ale slouží především pro účely disaster recovery. Stejně jako replikace nemá mechanismus pro okamžitý failover. Při selhání primární instance je proto potřeba počítat s dobou obnovy dat. Funkcionalita je dostupná v edici Standard bez omezení.

Nasazení technologií v praxi

Přestože mají zmíněné metody podobné vlastnosti, jejich použití v ostrém provozu je značně odlišné. Některé z nich navíc nebudou správně fungovat na nevhodně nakofigurované infrastruktuře. Na co si tedy dát pozor?

Provoz bez výpadků s Always On

Basic Availability Groups je ideální nasadit na řešení kompletně provozovaném v jednom datacentru nebo městě. Jako základ infrastruktury je vhodné zvolit clustery běžící v synchronním režimu na technologii Windows Server Failover Cluster (WSFC). K takovým clusterům v MasterDC nastavujeme vždy dvě sítě, aby bylo možné zajistit vysokou dostupnost. Jedná se rovněž o typ architektury, který je celkově citlivý na propustnost a vyžaduje latenci na úrovni do 10 ms.

Metoda Always On zároveň funguje pouze při „Full Log“ režimu databáze, při němž se do logu zapisují veškeré datové změny. To zvyšuje nároky na kapacitu hardwarových prostředků. Bez pravidelné údržby logu může dojít k zaplnění úložiště, následkem čehož se celý cluster stane nefunkčním.

Pokud architektura splňuje výše uvedené parametry, je technologie Always On velmi spolehlivá a současně jediná, která umožňuje provádět údržbu serverů v clusteru zcela bez výpadku.

Mirroring jako snazší alternativa k Always On

Modernější technologie Always On postupně Mirroring vytlačuje. Přesto se najdou případy, kdy Mirroring oceníte. Například pokud stávající infrastruktura využívá starší verzi SQL, je Mirroring jedinou variantou, která zajistí vysokou dostupnost řešení.

Mirroring nepožaduje WSFC clustery a nedisponuje ani transparentní IP adresou. Jeho konfigurace je proto jednodušší a má méně technických návazností. Také u Mirroringu se ale musí počítat s kapacitou navíc pro zápis logů.

Replikace pro infrastruktury s více uzly

Replikace je o několik sekund pomalejší než Always On a Mirroring. Toto zpomalení je ovlivněno samotným principem, na němž replikace funguje. Nejprve dochází ke čtení logů, změny se následně zapisují do distribuční databáze a až poté do odběratele. Zásadní rozdíl však vyplývá z vlastností sekundárního nodu – v tomto kontextu odběratele.

Zatímco u Always On a Mirroringu lze na sekundární uzly pouze kopírovat data a jakékoli další operace nejsou dostupné, v případě replikace je možný i zápis. Tato vlastnost se někdy označuje jako „writable secondary“ a je klíčová pro potřeby distribuce zátěže. Umožňuje totiž provádět čtení a zápis na úrovni sekundárních databází (odběratelů), které spolu mohou komunikovat.

Replikace je současně jedinou z metod, u níž jde pracovat jen s určitou částí dat, nikoli celou databází.

Obnova dat pomocí Log Shippingu

Log Shipping je snadno konfigurovatelná metoda pro účely disaster recovery. Není omezena vzdáleností od primárního cíle a nemá ani požadavky na shodné verze SQL. Jedná se o osvědčenou technologii nabízející široké možnosti nastavení.

U infrastruktur s více uzly se nabízí kombinovat Log Shipping s metodou Always On, a získat tak podporu vyššího počtu cílových lokalit.

Srovnání technologií

6 aspektů, které zohlednit při výběru technologie

Na začátku je potřeba přihlédnout k tomu, kolik můžete do řešení investovat a jaké kapacity máte na jeho údržbu. S tím je spojena také volba edice SQL Serveru. Některé z metod mají v edici Enterprise širokou škálu funkcí, které v jiných edicích dostupné nejsou nebo mají určitá omezení. Kompletní přehled funkcionalit v jednotlivých verzích najdete v oficiální dokumentaci Microsoft.

Při výběru je dále důležité zohlednit:

1. Jak dlouhou nedostupnost si můžete dovolit

Doba nedostupnosti odpovídá času, který bude řešení potřebovat pro obnovu dat. V případě Always On, Mirroringu nebo replikace jsou to milisekundy, maximálně sekundy. Naproti tomu doba obnovy u Log Shippingu je delší a ovlivňuje ji zvolený interval kopírování logů, jejich velikost, konfigurace procesu obnovy nebo výkon sekundárního serveru.

2. O kolik dat můžete přijít

Princip kopírování, volba synchronního nebo asynchronního režimu (u Always On a Mirroring) či nastavení intervalu pro vytvoření kopie určuje, do jakého bodu v čase se při obnově vrátíte. A tedy kolik dat ztratíte. U metody Always On a Mirroringu v synchronním režimu jsou ztráty nulové a minimalizuje je i replikace. V případě Log Shippingu se musí se ztrátou dat počítat. Její míra se opět odvíjí od nastaveného intervalu.

3. Do kolika cílových lokalit chcete data kopírovat

Jestliže potřebujete mít data jen na jedné sekundární instanci, můžete u SQL Standard využít metodu Always On nebo Mirroring. Pro kopírování do několika sekundárních instancí už budete muset využít Log Shipping či replikaci, které v počtu instancí nekladou žádná omezení.

4. Jaké jsou požadavky na failover

Pokud nároky řešení vyžadují automatický failover, doporučujeme zvolit metodu Always On. Basic Availability Groups umožňují lépe definovat kritéria pro detekci selhání. Podrobná znalost technologie je ale v tomto případě nezbytná, proto je lepší konfiguraci řešit ve spolupráci s odborníky. Chybné nastavení na úrovni Windows Cluster může vyvolat nežádoucí failover například při nestabilitě na úrovni sítě.

5. Jak proměnlivá jsou data v databázi

V neposlední řadě záleží i na tom, jak často a na kolika místech současně se data v databázi mění. Při rozhodnutí je dobré zohlednit, jak rychle lze změny zaznamenat na sekundární instance.

6. Jaká je kvalita spojení mezi uzly

Zejména u metody Always On a Mirroring je důležitá kvalita síťového spojení. Pokud servery běží v několika různých datacentrech, bude řešení vyžadovat propojení optickým kabelem. Spojení přes veřejný internet má vyšší latenci a ohrožuje správné fungování automatického failoveru.