Prozkoumání možností vysoké dostupnosti a zotavení po havárii

15 min

Abyste si mohli představit řešení pro virtuální počítače, musíte nejprve porozumět možnostem dostupnosti pro nasazení založená na IaaS.

Infrastruktura jako služba versus platforma jako služba

Pokud jde o dostupnost, volba IaaS nebo PaaS je rozdíl. S IaaS máte virtuální počítač, což znamená, že existuje operační systém s instalací SQL Serveru. Správce nebo skupina odpovědná za SQL Server by měli na výběr řešení s vysokou dostupností a zotavením po havárii (HADR) a velkou kontrolu nad tím, jak se toto řešení nakonfigurovalo.

Při nasazeních založených na PaaS, jako je Azure SQL Database, jsou řešení HADR integrovaná do této funkce a často je potřeba je povolit. Existují minimální možnosti, které je možné nakonfigurovat.

Vzhledem k těmto rozdílům může volba IaaS nebo PaaS ovlivnit konečný návrh řešení HADR.

Funkce HADR SQL Serveru pro virtuální počítač Azure

Při použití IaaS můžete ke zvýšení dostupnosti použít funkce poskytované SQL Serverem. V některých případech je možné je kombinovat s funkcemi na úrovni Azure, aby se ještě více zvýšila dostupnost.

Funkce dostupné v SQL Serveru jsou uvedené v následující tabulce.

Název funkce	Chrání
Instance clusteru s podporou převzetí služeb při selhání alwaysOn (FCI)	Instance
Skupina dostupnosti AlwaysOn (AG)	Databáze
Přesouvání protokolu	Databáze

Instance SQL Serveru je celá instalace SQL Serveru (binární soubory, všechny objekty v instanci, včetně přihlášení, úloh agenta SQL Serveru a databází). Ochrana na úrovni instance znamená, že celá instance je zohledněny ve funkci dostupnosti.

Databáze na SQL Serveru obsahuje data, která koncoví uživatelé a aplikace používají. Existují systémové databáze, na které SQL Server spoléhá, a také databáze vytvořené pro použití koncovými uživateli a aplikacemi. Instance SQL Serveru má vždy vlastní systémové databáze. Ochrana na úrovni databáze znamená, že cokoli, co je v databázi, nebo je zachyceno v transakčním protokolu pro uživatele nebo aplikační databázi, je považováno za součást funkce dostupnosti. Cokoli, co existuje mimo databázi nebo které není zachyceno jako součást transakčního protokolu, jako jsou úlohy agenta SQL Serveru a propojené servery, musí být ručně vyřešeny, aby cílový server mohl fungovat jako primární, pokud dojde k plánované nebo neplánované události převzetí služeb při selhání.

FcI i skupiny AG vyžadují základní mechanismus clusteru. Pro nasazení SQL Serveru běžící na Windows Serveru se jedná o cluster s podporou převzetí služeb při selhání windows serveru (WSFC) a pro Linux je to Pacemaker.

Instance clusteru s podporou převzetí služeb při selhání AlwaysOn

Při instalaci SQL Serveru se nakonfiguruje FCI. Samostatnou instanci SQL Serveru nelze převést na FCI. FCI má přiřazen jedinečný název a IP adresu, která se liší od základních serverů nebo uzlů, které se účastní clusteru. Název a IP adresa se také musí lišit od základního mechanismu clusteru. Aplikace a koncoví uživatelé by pro přístup použili jedinečný název FCI. Tato abstrakce umožňuje aplikacím, aby nemusely vědět, kde je instance spuštěná. Jedním z hlavních rozdílů mezi fci založenými na Azure a místními fcis je to, že pro Azure se vyžaduje interní nástroj pro vyrovnávání zatížení (ILB). Interní nástroj pro vyrovnávání zatížení slouží k zajištění toho, aby se koncoví uživatelé mohli připojit k jedinečnému názvu FCI.

Když služba FCI převezme služby při selhání do jiného uzlu clusteru, ať už je inicializována ručně nebo se stane kvůli problému, celá instance se restartuje na jiném uzlu. To znamená, že proces převzetí služeb při selhání je úplné zastavení a spuštění SQL Serveru. Všechny aplikace nebo koncoví uživatelé připojení k FCI se během převzetí služeb při selhání odpojí a automaticky se můžou znovu připojit jenom aplikace, které můžou toto přerušení zpracovat a obnovit.

Při spuštění na druhém uzlu prochází instance procesem obnovení. FCI bude konzistentní s bodem selhání, takže technicky vzato nedojde ke ztrátě dat, ale všechny transakce, které je potřeba vrátit zpět, to provede v rámci obnovení. Jak jsme uvedli výše, protože se jedná o ochranu na úrovni instance, všechno potřebné (přihlášení, úlohy agenta SQL Serveru atd.), takže firma může pokračovat obvyklým způsobem, jakmile budou databáze připravené.

FcI vyžadují jednu kopii databáze, ale to je také jediný bod selhání. Aby se zajistilo, že k databázi má přístup jiný uzel, vyžadují FCI určitou formu sdíleného úložiště. U architektur založených na Windows Serveru je to možné dosáhnout prostřednictvím sdílené složky Azure Premium, iSCSI, sdíleného disku Azure, Prostory úložiště s přímým přístupem (S2D) nebo podporovaného řešení třetích stran, jako je SIOS DataKeeper. FCI používající edice Standard SQL Serveru můžou mít až dva uzly. FcI také vyžadují použití služeb Doména služby Active Directory Services (AD DS) a DNS (Domain Name Services), takže služba AD DS a DNS musí být implementovány někde v Azure, aby FCI fungovala.

S Windows Serverem 2016 nebo novějším můžou fcis použít repliku úložiště k vytvoření nativního řešení zotavení po havárii pro FCI bez nutnosti používat jinou funkci, jako je odesílání protokolů nebo skupiny AG.

Skupiny dostupnosti Always On

Skupiny dostupnosti byly zavedeny v SQL Serveru 2012 edice Enterprise a od SQL Serveru 2016 jsou také v edice Standard. V edice Standard může skupina dostupnosti obsahovat jednu databázi, zatímco v edice Enterprise může mít skupina dostupnosti více než jednu databázi. Zatímco skupiny AG sdílejí některé podobnosti s FCI, ve většině způsobů se liší.

Největší rozdíl mezi FCI a skupinami dostupnosti spočívá v tom, že skupiny dostupnosti poskytují ochranu na úrovni databáze. Primární replika je instance, která se účastní skupiny dostupnosti, která obsahuje databáze pro čtení a zápis. Sekundární replika je místo, kde primární odesílá transakce přes přenos protokolu, aby byla synchronizovaná. Přesun dat mezi primární replikou může být synchronní nebo asynchronní. Databáze na jakékoli sekundární replice jsou ve stavu načítání, což znamená, že mohou přijímat transakce, ale nemohou být plně zapisovatelnou kopií, dokud se tato replika nestane primární. Skupina dostupnosti ve edice Standard může mít maximálně dvě repliky (jednu primární, jednu sekundární), zatímco edice Enterprise podporuje až devět (jednu primární, osm sekundární). Sekundární replika se inicializuje buď ze zálohy databáze, nebo z SQL Serveru 2016, můžete použít funkci s názvem automatické seeding. Automatické předvytváření používá přenos streamu protokolu k streamování zálohování do sekundární repliky pro každou databázi skupiny dostupnosti pomocí nakonfigurovaných koncových bodů.

Skupina dostupnosti poskytuje abstrakci s naslouchacím procesem. Naslouchací proces funguje jako jedinečný název přiřazený k FCI a má vlastní název a IP adresu, které se liší od čehokoli jiného (WSFC, uzel atd.). Naslouchací proces také vyžaduje interní vyrovnávání zatížení a prochází zastavením a spuštěním. Aplikace a koncoví uživatelé můžou k připojení použít naslouchací proces, ale na rozdíl od FCI nemusí být naslouchací proces použit. K připojení přímo k instanci může dojít. S edice Enterprise je možné v případě potřeby nakonfigurovat sekundární repliky v edice Enterprise pro přístup jen pro čtení a dají se použít pro jiné funkce, jako jsou kontroly konzistence databáze (DBCC) a zálohy.

Skupiny AG můžou mít v porovnání s FCI rychlejší dobu převzetí služeb při selhání, což je jedním z důvodů, proč jsou atraktivní. I když skupiny dostupnosti nevyžadují sdílené úložiště, každá replika má kopii dat, což zvyšuje celkový počet kopií databáze a celkové náklady na úložiště. Úložiště je místní pro každou repliku. Pokud jsou například nároky na data databází na primární replice 1 TB, bude mít každá replika také stejnou velikost. Pokud existuje pět replik, znamená to, že potřebujete 5 TB místa.

Mějte na paměti, že každý objekt, který existuje mimo databázi nebo není zachycen v transakčním protokolu databáze, musí být ručně vytvořen a účetován v jakékoli jiné instanci SQL Serveru, pokud by se tato instance musela stát novou primární replikou. Příklady objektů, za které byste zodpovídají, patří úlohy agenta SQL Serveru, přihlášení na úrovni instance a propojené servery. Pokud můžete použít ověřování systému Windows nebo používat obsažené databáze se skupinami AG, zjednoduší se přístup.

Řada organizací může čelit problémům s implementací vysoce dostupných architektur a může potřebovat pouze vysokou dostupnost poskytovanou platformou Azure nebo použití řešení PaaS, jako je Spravovaná instance Azure SQL. Než se podíváme na řešení platformy Azure, existuje jedna další funkce SQL Serveru, o které byste měli vědět: přesouvání protokolů.

Přesouvání protokolu

Přesouvání protokolů už bylo od raných dnů SQL Serveru. Tato funkce je založená na zálohování, kopírování a obnovení a je jednou z nejjednodušších metod dosažení HADR pro SQL Server. Přesouvání protokolů se primárně používá pro zotavení po havárii, ale dá se také použít k vylepšení místní dostupnosti.

Přesouvání protokolů, jako jsou skupiny AG, poskytuje ochranu na úrovni databáze, což znamená, že stále potřebujete počítat s úlohami agenta SQL Serveru, propojenými servery, přihlášeními na úrovni instance atd. Odesílání protokolů neposkytuje nativně žádné abstrakce, takže přepnutí na jiný server, který se účastní přesouvání protokolů, musí být schopen tolerovat změnu názvu. Pokud to není možné, existují metody, jako je alias DNS, který je možné nakonfigurovat na síťové vrstvě, aby se pokusil zmírnit problémy se změnou názvu.

Mechanismus odesílání protokolů je jednoduchý: nejprve proveďte úplnou zálohu zdrojové databáze na primárním serveru, obnovte ho ve stavu načítání (POHOTOVOSTNÍ REŽIM nebo NORECOVERY) v jiné instanci, která se označuje jako sekundární server nebo záložní pohotovostní režim. Tato nová kopie databáze se označuje jako sekundární databáze. Automatizovaný proces integrovaný do SQL Serveru pak automaticky zálohuje transakční protokol primární databáze, zkopíruje zálohu na pohotovostní server a nakonec obnoví zálohu do pohotovostního režimu.