[Zdroj] Vysoká dostupnost v SQL Serveru (1) ---- přehled vysoké dostupnosti

Od SQL Server 2005 Microsoft poskytuje řadu technologií vysoké dostupnosti pro snížení výpadků a zvýšení ochrany obchodních dat, a s kontinuálním vydáváním SQL Server 2008, SQL Server 2008 R2 a SQL Server 2012 je v SQL Serveru mnoho technologií s vysokou dostupností, které vyhovují různým scénářům.

    Než začnu tento článek, začnu stručným přehledem toho, co určuje, kterou technologii s vysokou dostupností použít.

    Mnoho společností potřebuje, aby všechna nebo část jejich dat byla vysoce dostupná, například na internetových nákupních stránkách, online databáze produktů musí být online 24/7, jinak v konkurenčním tržním prostředí znamená výpadek zákazníků a příjmů. Například v call centru, které spoléhá na SQL Server, pokud databáze vypadne, všichni volající mohou jen sedět a odpovědět zákazníkovi "Promiňte, selhání systému", což je také nepřijatelné.

    Samozřejmě, v ideálním světě by všechna kritická data byla neustále online, ale v reálném světě by existovalo několik důvodů, proč by databáze nebyla dostupná, protože není možné předpovědět čas a formu katastrofy, je nutné předem přijmout opatření, aby se předešlo různým nouzovým situacím, proto SQL Server poskytuje různé technologie s vysokou dostupností, mezi které patří hlavně: shlukování, replikace, zrcadlení, doručování logů, skupiny dostupnosti AlwaysOn a další, jako je zálohování a obnova souborů souborů. Technologie s vysokou dostupností v jedné instanci, jako jsou online indexy obnovy. Používání technologie s vysokou dostupností není o výběru známé technologie pro přímé použití, ale o komplexním posouzení podnikání a technologií. Protože neexistuje jediná technologie, která by dokázala dosáhnout všech funkcí. Jak tyto technologie zavést podle vašeho konkrétního podnikání a rozpočtu, je takzvaná strategie vysoké dostupnosti.

Při navrhování strategie vysoké dostupnosti byste měli nejprve zvážit následující faktory:

• RTO (Recovery Time Objective) – tedy cíl doby obnovy znamená, kolik prostojů je povoleno, obvykle vyjádřených několika devítkami, například 99,999% dostupnost znamená maximálně 5 minut propadu za rok, 99,99% dostupnost znamená maximálně 52,5 minuty prostojů za rok a 99,9% dostupnost znamená maximálně 8,75 hodin prostojů za rok. Stojí za zmínku, že metoda výpočtu RTO zohledňuje, zda je systém 24*365 nebo jen od 6:00 do 21:00 atd. Musíte také věnovat pozornost tomu, zda je údržbové okno počítáno jako propadák, a je snazší dosáhnout vyšší dostupnosti, pokud je během údržby povolena údržba a záplaty databáze.
• RPO (Recovery Point Objective) – Také známý jako cíl recovery point, znamená, kolik ztráty dat je povoleno. Obvykle, pokud uděláte kvalitní zálohu, můžete snadno dosáhnout nulové ztráty dat. Když však dojde k katastrofě, v závislosti na rozsahu poškození databáze, doba potřebná k obnovení dat ze zálohy způsobí, že databáze bude nedostupná, což ovlivní implementaci RTO. Raným a slavnějším příkladem je bankovní systém v Evropě a Spojených státech, přičemž pouze RPO jsou v systému pouze plné zálohy a logové zálohy, plné zálohy každé 3 měsíce, logy každých 15 minut, při katastrofě lze data obnovit pouze prostřednictvím plných záloh a logů, takže i když nedochází ke ztrátě dat, ale protože obnova dat trvala dva dny, bankovní systém byl 2 dny nedostupný, takže přišlo o velké množství zákazníků. Dalším opačným příkladem je domácí online video web, který používá SQL Server jako backendovou relační databázi, front-end používá NoSQL a pravidelně importuje No-SQL data do relační databáze jako zálohu.
  

    Rozpočet – RTO a RPO jsou společně známé jako SLA (Service Level Agreements) a při navrhování strategie vysoké dostupnosti je potřeba měřit, jak dobře SLA splňujete, podle vašeho podnikání, podle rozpočtu a měření nákladů na různé SLA v případě selhání. Obecně platí, že je obtížné dosáhnout vysokých SLA s omezeným rozpočtem, a i když jsou vysoká SLA dosažena prostřednictvím složitých architektur, složité architektury také znamenají vysoké provozní a údržbové náklady, proto je nutné zvolit správnou technologii v rámci rozpočtu, aby SLA splnila.

Obecně tedy lze velký rámec pro vysokou dostupnost určit několika otázkami při přijímání objednávek:

• Jaké jsou prostoje, které jsou akcionáři ochotni přijmout?
• Jaký čas na volnost je pro manažery přijatelný?
• Jaký je rozpočet pro scénář vysoké dostupnosti?
• Jaká je ztráta za hodinu kvůli výpadku?
  

• Studené zálohování: Záložní server je nakonfigurován tak, aby přijímal data primárního serveru a v případě selhání ručně obnovil data do primární databáze, nebo překonfiguroval spojovací řetězec či oprávnění programu, aby se zálohovací databáze spustila.
• Teplá záloha: Primární data serveru budou průběžně přenášet záznamy záložnímu serveru (v nepravidelných intervalech, může to být 15 minut, 30 minut, 1 minuta atd.), tímto způsobem je primární server na záložní server obvykle aktualizován asynchronně, takže data primárního a záložního serveru nelze zaručit. Navíc tento systém obvykle neimplementuje automatické monitorování poruch a přepínání v případě záložního provozu.
• Horká záloha: Data primárního serveru jsou automaticky synchronizována na záložním serveru a ve většině případů je zahrnuto automatické monitorování poruch a přepnutí v záložním režimu, přičemž lze zaručit konzistenci dat mezi primárním serverem a záložním serverem.
  

    Od studených přes teplé až po horké zálohy ceny raketově vystřelují.

    Funkce vysoké dostupnosti podporované v SQL Serveru úzce souvisejí s verzí a Enterprise edice podporuje všechny funkce vysoké dostupnosti, včetně:

• Failover cluster
• l Obrázek databáze
• l Přenos transakčních logů
• l Snímky databáze
• Vylepšení s vysokou dostupností
• l Hot load paměť
• l Online indexační operace
• l Částečně online databáze (pouze skupina hlavních souborů nebo skupina hlavních souborů a další NDF soubory jsou obnoveny)
  

    Pro konkrétní verze s vysokou dostupností viz:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxStojí za zmínku, že bezplatná verze Expressu může sloužit jako witness server pro zrcadlení databází, což vede k úsporám nákladů.

Failover cluster

    Failover clustery poskytují vysokou dostupnost pro celou SQL Server instanci, což znamená, že instance SQL Serveru na uzlu clusteru selže na jiné uzly clusteru kvůli hardwarovým chybám, chybám operačního systému atd. Vysoká dostupnost je dosažena tím, že více serverů (uzlů) sdílí jeden nebo více disků, a failover clustery se v síti objevují podobně jako jeden počítač, ale s vysokou dostupností. Je důležité poznamenat, že protože failover clustery jsou založeny na sdílených discích, existuje jediný bod selhání disku, takže je třeba nasadit další ochrany, jako je replikace SAN, na úrovni disku. Nejčastějším failover clusterem je dvouuzlový failover cluster, včetně master a slave.

Přenos transakčních záznamů

    Doručení transakčních záznamů poskytuje ochranu na úrovni databáze s vysokou dostupností. Logování se používá k udržování jedné nebo více záložních databází (nazývaných "sekundární databáze") odpovídající produkční databáze (nazývané "primární databáze"). Před přehozením musí být sekundární databáze plně aktualizována ručně aplikací všech neobnovených záloh logů. Log delivery má flexibilitu podporovat více záložních databází. Pokud je potřeba více alternativních databází, může být doručování logů použito samostatně nebo jako doplněk k zrcadlení databáze. Když jsou tato řešení používána společně, hlavní databáze aktuální konfigurace zrcadlení databáze je zároveň primární databází aktuální konfigurace odesílání logů.

    Doručení transakčních logů lze použít pro zálohování studených i teplých záznamů.

Zrcadlení databází

    Zrcadlení databáze je ve skutečnosti softwarové řešení, které zároveň poskytuje ochranu na úrovni databáze, téměř okamžité failover pro zlepšení dostupnosti databáze. Databázové zrcadlo lze použít k udržování jedné záložní databáze (nebo "zrcadlové databáze") pro odpovídající produkční databázi (nazývanou "hlavní databáze").
Protože zrcadlová databáze je vždy ve stavu obnovy, ale databáze není obnovena, nelze k zrcadlové databázi přistupovat přímo. Pro načítání pouze pro čtení, jako jsou reporty, však můžete zrcadlovou databázi použít nepřímo vytvořením snímku databáze zrcadlené databáze. Snímky databáze poskytují klientům přístup pouze pro čtení k datům v databázi při jejich vytvoření. Každá konfigurace zrcadlení databáze zahrnuje "hlavní server", který obsahuje hlavní databázi, a také zrcadlový server, který obsahuje zrcadlenou databázi. Zrcadlový server neustále aktualizuje zrcadlovou databázi hlavní databází.
    Zrcadlení databází běží synchronně v režimu vysoké bezpečnosti nebo asynchronně v režimu vysokého výkonu. V režimu vysokého výkonu nemusí transakce čekat, až zrcadlový server zapíše logy na disk, než je lze odeslat, což maximalizuje výkon. V režimu vysoké bezpečnosti jsou závazky realizovány oběma partnery, ale doba zpoždění transakce se prodlužuje. Nejjednodušší konfigurace zrcadlení databáze zahrnuje pouze hlavní server a zrcadlový server. V této konfiguraci, pokud je hlavní server ztracen, může být zrcadlový server použit jako záložní server, ale může to způsobit ztrátu dat. Režim vysoké bezpečnosti podporuje pohotovostní konfiguraci s automatickým přepínáním. Tato konfigurace zahrnuje instanci serveru třetí strany nazývanou "witness server", která umožňuje použití zrcadlového serveru jako hot backup serveru. Přepnutí z primární databáze do zrcadlové databáze obvykle trvá několik sekund.

    Zrcadlení databáze lze použít jak pro teplé, tak pro horké zálohy.

kopírovat

    Replikace není striktně určena pro vysokou dostupnost, ale může být aplikována na vysokou dostupnost. Replikace poskytuje ochranu na úrovni objektů v databázi. Replikace využívá model publish-subscribe, kdy jsou data publikována primárním serverem, známým jako vydavatel, jednomu nebo více sekundárním nebo předplatitelům. Replikace zajišťuje dostupnost a škálovatelnost v reálném čase mezi těmito servery. Podporuje filtrování, které poskytuje podmnožinu dat předplatitelům, a zároveň podporuje aktualizace oddílů. Odběratel je online a dostupný pro reportování nebo jiné funkce bez obnovy dotazu. SQL Server nabízí čtyři typy replikace: replikaci snapshotů, transakční replikaci, peer-to-peer replikaci a merge replikaci.

AlwaysOnSkupina použitelnosti

    AlwaysOn Availability Groups je nová funkce představená v SQL Server 2012. Je také poskytována ochrana na úrovni databáze. Dále rozšiřuje limit, že zrcadlení databází může být pouze 1:1, takže jedna primární replika může odpovídat až 4 sekundárním replikám (v SQL Server 2014 je tento limit rozšířen na 8), z nichž 2 sekundární repliky lze synchronizovat jako hot-backup a primární repliky v reálném čase a další dvě asynchronní sekundární repliky lze použít jako teplé zálohy. Kromě toho lze sekundární repliky nastavit pouze pro čtení a použít je k převzetí zátěže záloh.

    Z tohoto důvodu je zrcadlení databází v SQL Server 2012 označeno jako "zastaralé".

    Po pochopení základních konceptů vysoké dostupnosti a technologií vysoké dostupnosti, které SQL Server poskytuje, se podívejme na návrh strategie vysoké dostupnosti. Plánování strategie vysoké dostupnosti lze rozdělit do čtyř fází:

Požadavky na sběr

    Prvním krokem při rozhodování o strategii vysoké dostupnosti je bezpochyby shromáždění obchodních požadavků pro vytvoření SLA. RTO a RPO jsou nejdůležitější části a na tomto základě stanovují realistická očekávání požadavků na dostupnost a stanovují realistickou strategii vysoké dostupnosti založenou na těchto očekáváních.

Limity hodnocení

    Limity hodnocení nejsou omezeny pouze na různé technologie vysoké dostupnosti v SQL Serveru, ale také na ty, které nejsou technické. Pokud máte rozpočet jen desítky tisíc jüanů, ale chcete vytvořit řešení s vysokou dostupností založené na vzdálených datových centrech a replikaci SAN, je to bezpochyby bláznivý sen. Dalším netechnickým omezením je úroveň provozního personálu, a často složité architektury znamenají více kvalifikovaného provozního personálu. Další netechnická omezení zahrnují dostupnost místa na disku v datovém centru, zda napájení a klimatizace pokryjí potřeby, a čas potřebný k implementaci strategie dostupnosti.

    Technická omezení zahrnují různé funkce a omezení vysoké dostupnosti, funkce podporované různými verzemi SQL Serveru, počet CPU a velikost paměti. Důrazně se doporučuje nejprve se podívat na omezení různých verzí a funkcí SQL Serveru na webu Microsoft MSDN, než zavedete politiku vysoké dostupnosti.

Vybraná technologie

    Po shromáždění požadavků a posouzení omezení je dalším krokem vybrat technologie nebo jejich kombinaci popsanou dříve v tomto článku, aby splňovaly požadavky SLA. Pokud vybraná technologie SLA nesplňuje požadavky, je snadné nahlásit, která omezení SLA nesplňují, což vám umožní požádat o chybějící zdroje nebo udělat kompromis na SLA.

Testujte, ověřte a dokumentujte

    Politiky vysoké dostupnosti je třeba od začátku důkladně testovat a ověřovat, aby bylo zajištěno, že současné politiky dostupnosti splňují SLA. Když je však spuštěna strategie vysoké dostupnosti, je také nutné ji pravidelně testovat a ověřovat, aby bylo zajištěno, že současná politika může splnit SLA i přes růst dat, změny podnikání nebo požadavků. Současně by měla být současně dokumentována konfigurace řešení dostupnosti, způsob failoveru a plán obnovy po havárii, aby bylo možné je sledovat v případě selhání nebo budoucí úpravy strategie vysoké dostupnosti.

Tento článek vysvětluje základní koncepty vysoké dostupnosti, koncept SLA, různé typy funkcí vysoké dostupnosti podporované SQL Serverem a kroky potřebné k navržení strategie vysoké dostupnosti. Stojí za zmínku, že ačkoli tento článek hovoří pouze o vysoké dostupnosti na úrovni databáze, vysoká dostupnost není jen záležitostí DBA, ale zahrnuje také spolupráci různých rolí, jako jsou provozní a údržbářští pracovníci systému, správci sítí, vývojáři a manažeři, aby lépe vyhověli SLA.