[Zdroj] Vysoká dostupnosť v SQL Serveri (1) ---- prehľad o vysokej dostupnosti

Od SQL Server 2005 Microsoft poskytuje rôzne technológie s vysokou dostupnosťou na zníženie výpadkov a zvýšenie ochrany obchodných dát, a s neustálym vydávaním SQL Server 2008, SQL Server 2008 R2 a SQL Server 2012 existuje v SQL Serveri mnoho technológií s vysokou dostupnosťou, ktoré vyhovujú rôznym scenárom.

    Predtým, než začnem tento článok, začnem stručným prehľadom toho, čo určuje, ktorú technológiu s vysokou dostupnosťou použiť.

    Mnohé spoločnosti potrebujú, aby všetky alebo časť ich dát boli vysoko dostupné, napríklad online nákupné stránky, online databázy produktov musia byť online 24/7, inak v prostredí vysoko konkurenčného trhu prestávky znamenajú stratu zákazníkov a príjmov. Napríklad v call centre, ktoré sa spolieha na SQL Server, ak databáza vypadne, všetci volajúci môžu len sedieť a odpovedať zákazníkovi "Prepáčte, zlyhanie systému", čo je tiež neprijateľné.

    Samozrejme, v ideálnom svete by boli všetky kritické dáta online neustále, ale v reálnom svete by existovalo viacero dôvodov, prečo databáza nie je dostupná, pretože nie je možné predpovedať čas a formu katastrofy, je potrebné prijať opatrenia vopred na prevenciu rôznych núdzových situácií, preto SQL Server poskytuje rôzne technológie s vysokou dostupnosťou, medzi ktoré patria hlavne: klastrovanie, replikácia, zrkadlenie, doručovanie logov, skupiny dostupnosti AlwaysOn a ďalšie, ako zálohovanie a obnova súborov súborov, Technológie s vysokou dostupnosťou v jednej inštancii, ako sú online indexy obnovy. Používanie technológií s vysokou dostupnosťou nie je o výbere známej technológie na priame použitie, ale o komplexnom zvážení podnikania a technológií. Pretože neexistuje jediná technológia, ktorá by dokázala dosiahnuť všetky funkcie. Ako tieto technológie prijať na základe vášho konkrétneho podnikania a rozpočtu je takzvaná stratégia vysokej dostupnosti.

Pri navrhovaní stratégie vysokej dostupnosti by ste mali najprv zvážiť nasledujúce faktory:

• RTO (Recovery Time Objective) – teda cieľ času zotavenia, znamená, koľko prestojov je povolených, zvyčajne vyjadrených niekoľkými deviatkami, napríklad 99,999 % dostupnosť znamená maximálne 5 minút prestojov ročne, 99,99 % dostupnosť znamená najviac 52,5 minút prestojev ročne a 99,9 % dostupnosť znamená maximálne 8,75 hodiny prestojov ročne. Stojí za zmienku, že metóda výpočtu RTO zohľadňuje, či je systém 24*365 alebo len od 6:00 do 21:00 a podobne. Musíte tiež venovať pozornosť tomu, či sa údržbové okno počíta ako prestávka, a je jednoduchšie dosiahnuť vyššiu dostupnosť, ak je počas údržby povolená údržba a záplaty databázy.
• RPO (Recovery Point Objective) – Tiež známy ako cieľ recovery point, znamená, koľko straty dát je povolené. Zvyčajne, ak urobíte dobrú zálohu, môžete ľahko dosiahnuť nulovú stratu dát. Keď však dôjde k katastrofe, v závislosti od rozsahu poškodenia databázy, čas potrebný na obnovenie dát zo zálohy spôsobí, že databáza bude nedostupná, čo ovplyvní implementáciu RTO. Skorým a známejším príkladom je bankový systém v Európe a Spojených štátoch, pričom len pri RPO sú v systéme len úplné zálohy a logové zálohy, kompletné zálohy každé 3 mesiace, logy každých 15 minút, keď nastane katastrofa, iba plné zálohy a logové zálohy môžu obnoviť dáta, takže hoci nedochádza k strate dát, pretože obnova dát trvala dva celé dni, bankový systém bol 2 dni nedostupný, takže stratilo veľké množstvo zákazníkov. Ďalším opačným príkladom je domáca online video stránka, ktorá používa SQL Server ako back-end relačnú databázu, front-end používa No-SQL a pravidelne importuje No-SQL dáta do relačnej databázy ako zálohu.
  

    Rozpočet – RTO a RPO sú spoločne známe ako SLA (Service Level Agreements) a pri navrhovaní stratégie vysokej dostupnosti je potrebné merať, ako dobre SLA spĺňate podľa vášho podnikania, podľa rozpočtu a merania nákladov na rôzne SLA v prípade zlyhania. Vo všeobecnosti je ťažké dosiahnuť vysoké SLA s obmedzeným rozpočtom, a aj keď sa vysoké SLA dosahujú prostredníctvom zložitých architektúr, zložité architektúry znamenajú aj vysoké prevádzkové a údržbové náklady, preto je potrebné vybrať správnu technológiu v rámci rozpočtu, aby SLA vyhovovala.

Preto možno všeobecne určiť veľký rámec pre vysokú dostupnosť niekoľkými otázkami pri prijímaní objednávok:

• Aké sú prestoje, ktoré sú akcionári ochotní akceptovať?
• Aké voľné hodiny sú pre manažérov prijateľné?
• Aký je rozpočet určený na scenár vysokej dostupnosti?
• Aká je strata za hodinu kvôli prestojom?
  

• Studené zálohovanie: Záložný server je nastavený tak, aby prijímal dáta primárneho servera a v prípade jeho zlyhania manuálne obnovil dáta do primárnej databázy alebo prekonfiguroval spojovací reťazec či oprávnenia programu, aby sa zálohovacia databáza spustila.
• Teplá záloha: Primárne serverové dáta neustále prenášajú logy na záložný server (v nepravidelných intervaloch, môže to byť 15 minút, 30 minút, 1 minúta atď.), takto sa primárny server k záložnému serveru zvyčajne aktualizuje asynchrónne, takže dáta primárneho a záložného servera nie sú zaručené. Okrem toho tento systém zvyčajne neimplementuje automatické monitorovanie chýb a failover.
• Horúca záloha: Dáta primárneho servera sú automaticky synchronizované na záložnom serveri a vo väčšine prípadov sú zahrnuté automatické monitorovanie chýb a prepnutie v zálohe, pričom je zaručená konzistentnosť dát medzi primárnym serverom a záložným serverom.
  

    Keďže zálohy od studeného do teplého a teplého do tepla vystrelia do výšky.

    Funkcie vysokej dostupnosti podporované v SQL Serveri úzko súvisia s verziou a Enterprise edícia podporuje všetky funkcie s vysokou dostupnosťou, vrátane:

• Failover klaster
• l Obrázok databázy
• l Prenos transakčného denníka
• l Databázové snímky
• l Vylepšenia s vysokou dostupnosťou
• l Horúca pamäť
• l Online indexačné operácie
• l Databáza čiastočne online (obnovujú sa len skupina hlavných súborov alebo skupina hlavných súborov a ďalšie NDF súbory)
  

    Pre konkrétne verzie s vysokou dostupnosťou pozri:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxStojí za zmienku, že bezplatná verzia Express môže slúžiť ako witness server pre zrkadlenie databáz, čo vedie k úspore nákladov.

Failover klaster

    Failover klastry poskytujú vysokú dostupnosť pre celú SQL Server inštanciu, čo znamená, že SQL Server inštancia na jednom uzle v klastri zlyháva na iné uzly v klastri kvôli hardvérovým chybám, chybám operačného systému a podobne. Vysoká dostupnosť sa dosahuje tým, že viaceré servery (uzly) zdieľajú jeden alebo viac diskov, pričom failover klastry sa v sieti objavujú podobne ako jeden počítač, ale s vysokou dostupnosťou. Je dôležité poznamenať, že keďže failover klastry sú založené na zdieľaných diskoch, existuje jeden bod zlyhania disku, preto je potrebné na úrovni disku nasadiť ďalšie ochrany, ako je replikácia SAN. Najbežnejším failover klastrom je dvojuzolový failover klaster, vrátane master a slave.

Prenos transakčných záznamov

    Doručenie transakčných záznamov poskytuje ochranu vysokej dostupnosti na úrovni databázy. Logovanie sa používa na udržiavanie jednej alebo viacerých záložných databáz (nazývaných "sekundárne databázy") príslušnej produkčnej databázy (nazývanej "primárna databáza"). Pred záložným prepnutím musí byť sekundárna databáza úplne aktualizovaná manuálnym použitím všetkých neobnovených záloh logov. Doručovanie logov má flexibilitu podporovať viacero záložných databáz. Ak je potrebných viacero alternatívnych databáz, doručovanie logov môže byť použité samostatne alebo ako doplnok k zrkadleniu databázy. Keď sa tieto riešenia používajú spolu, hlavná databáza aktuálnej konfigurácie zrkadlenia databázy je zároveň primárnou databázou aktuálnej konfigurácie odosielania logov.

    Doručenie transakčných logov sa dá použiť na zálohovanie studených aj teplých záznamov.

Zrkadlenie databáz

    Zrkadlenie databázy je v skutočnosti softvérové riešenie, ktoré zároveň poskytuje ochranu na úrovni databázy, poskytujúc takmer okamžité failover na zlepšenie dostupnosti databázy. Databázové zrkadlo môže byť použité na udržiavanie jednej záložnej databázy (alebo "zrkadlovej databázy") pre zodpovedajúcu produkčnú databázu (nazývanú "hlavná databáza").
Keďže zrkadlová databáza je vždy v obnovovacom stave, ale databáza nie je obnovená, zrkadlová databáza nie je prístupná priamo. Avšak pri načítavaní iba na čítanie, ako sú reporty, môžete zrkadlenú databázu použiť nepriamo vytvorením databázového snímku zrkadlenej databázy. Databázové snímky poskytujú klientom prístup iba na čítanie k dátam v databáze pri vytvorení snímky. Každá konfigurácia zrkadlenia databázy zahŕňa "hlavný server", ktorý obsahuje hlavnú databázu, a tiež zrkadlový server, ktorý obsahuje zrkadlenú databázu. Zrkadlový server neustále aktualizuje zrkadlovú databázu o hlavnú databázu.
    Zrkadlenie databáz beží synchronne v režime vysokej bezpečnosti alebo asynchrónne v režime vysokého výkonu. V režime vysokého výkonu transakcie nemusia čakať, kým zrkadlový server zapíše logy na disk, aby ich mohol odoslať, čo maximalizuje výkon. V režime vysokej bezpečnosti sú záväzné transakcie realizované oboma partnermi, ale oneskorenie transakcie sa predlžuje. Najjednoduchšia konfigurácia zrkadlenia databázy zahŕňa iba hlavný server a zrkadlový server. V tejto konfigurácii, ak dôjde k strate hlavného servera, môže byť zrkadlový server použitý ako pohotovostný server, ale môže to spôsobiť stratu dát. Režim vysokej bezpečnosti podporuje konfiguráciu v pohotovostnom režime s automatickým prepínaním v zálohe. Táto konfigurácia zahŕňa inštanciu servera tretej strany nazývanú "witness server", ktorá umožňuje používať zrkadlový server ako horúci záložný server. Failover z primárnej databázy do zrkadlovej databázy zvyčajne trvá niekoľko sekúnd.

    Zrkadlenie databázy sa dá použiť pre teplé aj horúce zálohy.

kopírovať

    Replikácia nie je striktne funkcia navrhnutá pre vysokú dostupnosť, ale dá sa aplikovať na vysokú dostupnosť. Replikácia poskytuje ochranu na úrovni objektov databázy. Replikácia využíva model publikovania-predplatenia, kde údaje publikuje primárny server, známy ako vydavateľ, jednému alebo viacerým sekundárnym alebo odberateľom. Replikácia poskytuje dostupnosť a škálovateľnosť v reálnom čase medzi týmito servermi. Podporuje filtrovanie na poskytovanie podmnožiny dát odberateľom, pričom zároveň podporuje aktualizácie partícií. Predplatiteľ je online a dostupný na reportovanie alebo iné funkcie bez potreby obnovy dotazu. SQL Server ponúka štyri typy replikácie: replikáciu snapshotov, transakčnú replikáciu, peer-to-peer replikáciu a replikáciu cez zlúčenie.

AlwaysOnSkupina použiteľnosti

    AlwaysOn Availability Groups je nová funkcia predstavená v SQL Server 2012. Poskytuje sa aj ochrana na úrovni databázy. Tiež rozširuje limit, že zrkadlenie databáz môže byť len 1:1, takže jedna primárna replika môže zodpovedať až 4 sekundárnym replikám (v SQL Server 2014 je tento limit rozšírený na 8), z ktorých 2 sekundárne repliky môžu byť synchronizované ako horúce zálohy a primárne repliky v reálnom čase, a ďalšie dve asynchrónne sekundárne repliky môžu byť použité ako teplé zálohy. Okrem toho je možné sekundárne repliky nakonfigurovať ako iba na čítanie a môžu byť použité na prevzatie záťaže záloh.

    Preto je zrkadlenie databáz v SQL Server 2012 označené ako "zastarané".

    Po pochopení základných konceptov vysokej dostupnosti a technológií vysokej dostupnosti poskytovaných v SQL Serveri sa pozrime na návrh stratégie vysokej dostupnosti. Plánovanie stratégie vysokej dostupnosti možno rozdeliť do štyroch fáz:

Požiadavky na zber

    Prvým krokom pri rozhodovaní o stratégii vysokej dostupnosti je nepochybne zhromaždiť obchodné požiadavky na vytvorenie SLA. RTO a RPO sú najkritickejšie časti a na tomto základe stanovujú realistické očakávania požiadaviek na dostupnosť a stanovujú realistickú stratégiu vysokej dostupnosti založenú na týchto očakávaniach.

Limity hodnotenia

    Limity hodnotenia nie sú obmedzené len na rôzne technológie s vysokou dostupnosťou v SQL Serveri, ale aj na tie, ktoré nie sú technické. Ak máte rozpočet len desaťtisíc jüanov, ale chcete vytvoriť riešenie s vysokou dostupnosťou založené na dátových centrách mimo lokality a replikácii SAN, je to nepochybne bláznivý sen. Ďalším netechnickým obmedzením je úroveň prevádzkového personálu, pričom často zložité architektúry znamenajú viac kvalifikovaného prevádzkového personálu. Ďalšie netechnické obmedzenia zahŕňajú dostupnosť diskového priestoru v dátovom centre, či napájanie a klimatizácia splnia potreby, a čas potrebný na implementáciu stratégie dostupnosti.

    Technické obmedzenia zahŕňajú rôzne funkcie a obmedzenia vysokej dostupnosti, funkcie podporované rôznymi verziami SQL Servera, počet CPU a veľkosť pamäte. Dôrazne sa odporúča najskôr sa pozrieť na obmedzenia rôznych verzií a funkcií SQL Serveru na webovej stránke Microsoft MSDN pred implementáciou politiky vysokej dostupnosti.

Vybraná technológia

    Po zhromaždení požiadaviek a posúdení obmedzení je ďalším krokom vybrať technológie alebo ich kombinácie opísané vyššie v tomto článku, aby spĺňali požiadavky SLA. Ak vybraná technológia nespĺňa SLA, je jednoduché nahlásiť, ktoré obmedzenia nespĺňajú SLA, čo vám umožní požiadať o chýbajúce zdroje alebo kompromitovať SLA.

Testujte, overujte a dokumentujte

    Politiky vysokej dostupnosti musia byť od začiatku dôkladne testované a overované, aby sa zabezpečilo, že súčasné politiky dostupnosti spĺňajú SLA. Avšak pri spustení stratégie vysokej dostupnosti je tiež potrebné ju pravidelne testovať a overovať, aby sa zabezpečilo, že súčasná politika stále spĺňa SLA napriek rastu dát, obchodným zmenám alebo zmenám požiadaviek. Zároveň by mala byť súčasne zdokumentovaná konfigurácia riešenia dostupnosti, spôsob failoveru a plán obnovy po havárii, aby bolo možné ich vystopovať v prípade zlyhania alebo budúcich úprav stratégie vysokej dostupnosti.

Tento článok vysvetľuje základné koncepty vysokej dostupnosti, koncept SLA, rôzne druhy funkcií vysokej dostupnosti podporovaných v SQL Serveri a kroky potrebné na navrhnutie stratégie vysokej dostupnosti. Stojí za zmienku, že hoci tento článok hovorí len o vysokej dostupnosti na úrovni databázy, vysoká dostupnosť nie je len záležitosťou DBA, ale zahŕňa aj spoluprácu rôznych rolí, ako sú prevádzka a údržba systému, správcovia sietí, vývojári a manažéri, aby lepšie vyhovovali SLA.