[Forrás] Magas rendelkezésre állás az SQL Serverben (1) ---- áttekintés a magas rendelkezésre állásról

Az SQL Server 2005 óta a Microsoft számos magas rendelkezésre állási technológiát kínál az állás csökkentésére és az üzleti adatok védelmének növelésére, és az SQL Server 2008, SQL Server 2008 R2 és SQL Server 2012 folyamatos kiadásával számos magas rendelkezésre álló technológia létezik az SQL Serverben, amelyek különböző helyzetekhez igazodnak.

    Mielőtt elkezdenék ezt a cikket, egy rövid áttekintéssel kezdem arról, mi határozza meg, melyik nagy elérhetőségű technológiát használjam.

    Sok cégnek szüksége van arra, hogy az adataik teljes egészében vagy részben magas szinten elérhetőek legyenek, például online vásárlási oldalak, az online termékadatbázisoknak 24/7 online kell lenniük, különben a rendkívül versenyképes piaci környezetben a leállás ügyfelek és bevétel elvesztését jelenti. Például egy SQL Serverre támaszkodó call centerben, ha az adatbázis leáll, minden hívó csak ott ülhet és válaszolhat az ügyfélnek: "Bocsánat, rendszerhiba", ami szintén elfogadhatatlan.

    Természetesen egy ideális világban minden kritikus adat mindig online lesz, de a való világban számos oka lehet az adatbázis elérhetetlenségének, mivel lehetetlen előre jelezni a katasztrófa idejét és formáját, előre szükséges intézkedéseket tenni a vészhelyzetek megelőzésére, ezért az SQL Server számos magas rendelkezésre állási technológiát kínál, ezek a technológiák főként a következők: klaszterezés, replikáció, tükrözés, napló szállítása, AlwaysOn elérhetőségi csoportok és egyéb megoldások, mint a fájlcsoport mentése és helyreállítása, Egypéldányos, magas elérhetőségű technológiák, mint például az online újraépítési indexek. A magas rendelkezésre állású technológia használata nem azért jelent, hogy közvetlen felhasználásra válasszunk egy ismerős technológiát, hanem hogy átfogó módon vizsgáljuk az üzletet és a technológiát. Mert nincs egyetlen technológia, amely minden funkciót elérne. Az, hogy ezeket a technológiákat a saját vállalkozásodhoz és költségvetésedhez igazítsuk, az úgynevezett magas elérhetőségi stratégia.

Magas rendelkezésre állási stratégia tervezésekor először a következő tényezőket kell figyelembe venni:

• RTO (Recovery Time Objective) – azaz a helyreállítási idő célkitűzése azt jelenti, mennyi leállás engedélyezett, általában néhány 9-es másodperccel kifejezve, például a 99,999% elérhetőség nem jelent több mint 5 perc leállást évente, 99,99% elérhetőség nem jelent több mint 52,5 perc állásidőt évente, és a 99,9% elérhetőség nem jelent több mint 8,75 óra leállást évente. Érdemes megjegyezni, hogy az RTO számítási módszere figyelembe veszi, hogy a rendszer 24*365-ös vagy csak reggel 6-tól este 9-ig van-e. Figyelned kell arra is, hogy a karbantartási ablak leállásnak számít-e, és könnyebb elérni a nagyobb elérhetőséget, ha az adatbázis karbantartása és javítása engedélyezett a karbantartási időszakban.
• RPO (Recovery Point Objective) – Más néven helyreállítási pont cél, azt jelenti, mennyi adatvesztés engedélyezett. Általában ha jó mentést készítesz, könnyen elérheted a nulla adatveszteséget. De amikor katasztrófa történik, az adatbázis korrupciójának mértékétől függően, az adatok visszaállításához szükséges idő miatt az adatbázis elérhetetlenné válik, ami hatással lesz az RTO megvalósítására. Egy korai és híresebb példa egy európai és amerikai bankrendszer, amely csak az RPO-t veszi figyelembe, a rendszerben csak teljes biztonsági mentések és naplók vannak, 3 havonta teljes mentés, 15 percenként, katasztrófa esetén csak a teljes mentések és a naplómentések képesek adatokat visszaállítani, így bár nincs adatvesztés, de mivel két teljes napig tartott az adatok visszaállítása, a bankrendszer két napig nem volt elérhető, így sok ügyfél veszett el. Egy másik ellentétes példa egy hazai online videó weboldal, amely SQL Servert használ háttérrelációs adatbázisként, a front-end No-SQL-t használ, és rendszeresen importál No-SQL adatokat a relációs adatbázisba biztonsági mentésként.
  

    Költségvetés – Az RTO és az RPO együttesen SLA-knak (Service Level Agreements) nevezik, és a magas rendelkezésre állási stratégia tervezésekor meg kell mérni, mennyire teljesíted az SLA-kat az üzleted alapján, a költségvetésed és a különböző SLA-k költségének mérése alapján egy meghibásodás esetén. Általánosságban nehéz magas SLA-kat elérni korlátozott költségvetéssel, és még ha a magas SLA-kat összetett architektúrákkal is elérik, a bonyolult architektúrák magas üzemeltetési és karbantartási költségeket is jelentenek, ezért szükséges a költségvetésen belül a megfelelő technológiát választani az SLA-k teljesítéséhez.

Ezért általánosságban a nagy rendelkezésre állás keretrendszere több rendelési kérdés alapján határozható meg:

• Milyen leállási időszakot hajlandóak elfogadni a részvényesek?
• Milyen szabadidők elfogadhatók a vezetők számára?
• Mekkora a költségvetés egy magas rendelkezésre állási helyzethez?
• Mennyi a veszteség óránként a leállás miatt?
  

• Hideg mentés: A készenléti szerver úgy van beállítva, hogy elfogadja az elsődleges szerver adatait, és ha meghibásodik, manuálisan visszaállítja az adatokat az elsődleges adatbázisba, vagy újrakonfigurálja a program csatlakozási láncsorát vagy jogosultságait, hogy a biztonsági adatbázist online tegyék.
• Meleg mentés: Az elsődleges szerver adatai folyamatosan továbbítják a naplókat a biztonsági mentési szervernek (szabálytalan időközönként, akár 15 perc, 30 perc, 1 perc stb.), így az elsődleges szerver a biztonsági mentés szerverre általában aszinkron módon frissül, így a fő szerver és a biztonsági mentés szerver adatai nem garantálhatók. Ezen felül ez a rendszer általában nem valósít meg automatikus hibafigyelést és rendszerátvételt.
• Forró mentés: Az elsődleges szerver adatai automatikusan szinkronizálódnak a biztonsági mentési szerveren, és a legtöbb esetben automatikus hibafigyelés és visszacsatolás is szerepel, így garantált az elsődleges szerver és a biztonsági mentés szerver adatainak konzisztenciája.
  

    A hidegtől a melegig, a meleg biztonsági alkatrészektől a költségek az egekbe szöknek.

    Az SQL Server által támogatott magas rendelkezésre állási funkciók szorosan kapcsolódnak a verzióhoz, és az Enterprise kiadás minden magas rendelkezésre állású funkciót támogat, többek között:

• Failover klaszter
• l Adatbázis kép
• l Tranzakciónapló továbbítása
• l Adatbázis pillanatképek
• l Magas rendelkezésre állási fejlesztések
• l Forró memória töltése
• l Online indexelési műveletek
• l Az adatbázis részlegesen online (csak a master fájlcsoport, a fő fájlcsoport és további NDF fájlok helyreállítódnak)
  

    A magas rendelkezésre állás jellemző konkrét verziókról lásd:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxÉrdemes megjegyezni, hogy az ingyenes Express verzió tanúszerverként szolgálhat az adatbázis tükrözéséhez, ami költségmegtakarítást eredményez.

Failover klaszter

    A failover klaszterek magas rendelkezésre állást biztosítanak az egész SQL Server példány számára, ami azt jelenti, hogy egy SQL Server példány a klaszteren egy csomóponton hardverhibák, operációs rendszer hibák stb. miatt átvált más csomópontokra is. A magas rendelkezésre állást több szerver (csomópont) egy vagy több lemezen osztozik meg, és a failover klaszterek ugyanúgy jelennek meg a hálózatban, mint egy számítógép, de magas elérhetőségi jellemzőkkel. Fontos megjegyezni, hogy mivel a failover klaszterek megosztott lemezeken alapulnak, egyetlen lemezhiba pont van, ezért további védelmeket, például a SAN replikációt kell telepíteni a lemez szintjén. A leggyakoribb failover klaszter egy kétcsomópontos failover klaszter, beleértve a mastert és a slave-t.

Tranzakciónapló továbbítása

    A tranzakciónapló szállítása adatbázis-szintű, magas rendelkezésre álló védelmet nyújt. A naplózást arra használják, hogy fenntartsanak egy vagy több készenléti adatbázist (úgynevezett "másodlagos adatbázisokat") a megfelelő termelési adatbázisban (az úgynevezett "elsődleges adatbázis"). A visszalépés előtt a másodlagos adatbázist teljesen frissíteni kell, hogy manuálisan alkalmazzák az összes vissza nem állított naplómentést. A napló szállítása rugalmas ahhoz, hogy több készenléti adatbázist is támogatjon. Ha több alternatív adatbázisra van szükség, a napló továbbítása külön vagy kiegészítőként használható az adatbázis tükrözéséhez. Ha ezeket a megoldásokat együtt használják, a jelenlegi adatbázis tükröző konfigurációjának fő adatbázisa egyben a jelenlegi napló szállítási konfigurációjának elsődleges adatbázisa is.

    A tranzakciónapló kézbesítése hideg és meleg biztonsági mentések elvégzésére is használható.

Adatbázis tükröződés

    Az adatbázis-tükrözés valójában egy szoftveres megoldás, amely adatbázis-szintű védelmet is nyújt, szinte azonnali failover-t biztosítva az adatbázis elérhetőségének javítására. Egy adatbázis tükör használható egyetlen készenléti adatbázis (vagy "tüköradatbázis") fenntartására a megfelelő termelési adatbázis (ezt "fő adatbázisnak" nevezik) számára.
Mivel a tükör adatbázis mindig helyreállítási állapotban van, de az adatbázis nem áll helyre, a tüköradatbázis közvetlenül nem érhető el. Azonban csak olvasható betöltéseknél, például jelentéseknél a tükrözött adatbázist közvetetten is használhatod, ha létrehozhatod a tükrözött adatbázis pillanatképét. Az adatbázis snapshot-ok csak olvasható hozzáférést biztosítanak az ügyfeleknek az adatbázisban lévő adatokhoz, amikor a snapshot létrejött. Minden adatbázis-tükröző konfiguráció magában foglal egy "fő szervert", amely tartalmazza a fő adatbázist, és egyben egy tükörszervert is, amely tartalmazza a tükrözött adatbázist. A tükörszerver folyamatosan frissíti a tüköradatbázist a fő adatbázissal.
    Az adatbázis-tükrözés szinkron működésben fut magas biztonsági módban, vagy aszinkron üzemmódban nagy teljesítményű módban. Nagy teljesítményű módban a tranzakcióknak nem kell megvárniuk, amíg a tükörszerver naplókat ír a lemezre, mielőtt beküldhetnék őket, ami maximalizálja a teljesítményt. Magas biztonsági módban mindkét partner elkötelezett tranzakciókat köt el, de a tranzakciós késleltetési idő meghosszabb. Az adatbázis tükrözésének legegyszerűbb konfigurációja csak a fő szervert és a tükörszervert foglalja magában. Ebben a konfigurációban, ha a fő szerver elveszik, a tükörszerver használható várakozó szerverként, de adatvesztést okozhat. A magas biztonsági mód támogatja a kellentétben való konfigurációt, magas biztonsági módot automatikus rendszerrel. Ez a konfiguráció egy harmadik féltől származó szerverpéldányt, úgynevezett "tanúszervert" foglal magában, amely lehetővé teszi a tükörszerver használatát forró biztonsági mentésként. A visszakapcsolódás az elsődleges adatbázisból a tüköradatbázisba általában néhány másodpercet vesz igénybe.

    Az adatbázis tükrözése mind meleg, mind forró mentéshez használható.

másolat

    A replikáció nem szigorúan magas rendelkezésre álló funkció, de alkalmazható magas elérhetőségre is. A replikáció adatbázis-objektumszintű védelmet nyújt. A replikáció egy publish-subscribe modellt alkalmaz, ahol az adatokat az elsődleges szerver, az úgynevezett kiadó teszi közzé egy vagy több másodlagos vagy előfizetőnek. A replikáció valós idejű elérhetőséget és skálázhatóságot biztosít ezek között a szerverek között. Támogatja a szűrést, hogy az előfizetőknek egy adathalmazt biztosítson, miközben a partíciós frissítéseket is támogatja. Az előfizető online van, és elérhető jelentésre vagy egyéb funkciókra, lekérdezések helyreállítása nélkül. Az SQL Server négy replikációs típust kínál: snapshot replikáció, tranzakciós replikáció, peer-to-peer replikáció és merge replikáció.

AlwaysOnHasználhatósági csoport

    Az AlwaysOn Availability Groups egy új funkció, amelyet az SQL Server 2012-ben vezettek be. Adatbázis-szintű védelem is biztosított. Ez továbbá kiterjeszti azt a korlátot, hogy az adatbázis tükröződése csak 1:1 lehet, így egy elsődleges replika legfeljebb 4 másodlagos replikának felelhet meg (az SQL Server 2014-ben ez a korlát 8-ra van kiterjesztve), amelyekből 2 másodlagos replika valós időben szinkronizálható forró mentésként és elsődleges másolatként, míg a másik két aszinkron másodlagos replika meleg biztonsági mentésként használható. Ezen felül a másodlagos replikák csak olvashatóként konfigurálhatók, és használhatók a biztonsági mentések terhelésének átvételére.

    Ennek következtében az adatbázis-tükrözés az SQL Server 2012-ben "elavultnak" minősül.

    Miután megértettük a magas rendelkezésre állás alapfogalmait és az SQL Server által kínált magas rendelkezésre állási technológiákat, nézzük meg a magas rendelkezésre állási stratégia tervezését. A magas rendelkezésre állású stratégia tervezése négy szakaszra bontható:

Gyűjtési követelmények

    Az első lépés a magas rendelkezésre állási stratégia kiválasztásában kétségtelenül az üzleti követelmények összegyűjtése az SLA-k létrehozásához. Az RTO és az RPO a legkritikusabb részek, és ezen alapulva reális elvárásokat állapítanak meg a rendelkezésre állási követelményekre, valamint ezek alapján reális magas rendelkezésre állási stratégiát alakítanak ki.

Értékelési határok

    Az értékelési korlátok nemcsak az SQL Server különböző magas rendelkezésre állású technológiáinak korlátaira korlátozódnak, hanem azokra is, amelyek nem technikaiak. Ha csak tízezer jüan költségvetésed van, de magas elérhetőségű megoldást szeretnél létrehozni a külső adatközpontok és SAN replikáció alapján, az kétségtelenül bolondálom. Egy másik nem technikai korlát a műveleti személyzet szintje, és gyakran a bonyolult architektúrák képzettebb műveleti személyzetet jelentenek. Egyéb nem technikai korlátok közé tartozik az adatközpontban rendelkezésre álló lemezhely, az áramellátás és a légkondicionálás megfelel-e az igényeknek, valamint a rendelkezésre állási stratégia megvalósításához szükséges idő.

    A technikai korlátok közé tartoznak a különböző magas rendelkezésre állású funkciók és korlátok, az SQL Server verziók által támogatott funkciók, a CPU-k száma és a memória mérete. Erősen ajánlott, hogy először a Microsoft MSDN weboldalán található különböző SQL Server verziók és funkciók korlátaira hivatkozz, mielőtt magas rendelkezésre állási szabályzatot vezetnének be.

Kiválasztott technológia

    A követelmények összegyűjtése és a korlátok értékelése után a következő lépés a korábban említett technológiák vagy azok kombinációjának kiválasztása, hogy megfeleljenek az SLA követelményeknek. Ha a kiválasztott technológia nem felel meg az SLA-nak, könnyű jelenteni, hogy mely korlátok nem felelnek meg az SLA-nak, így hiányzó erőforrásokat kérhetsz vagy kompromitumot köthetsz az SLA-n.

Tesztelj, validálj és dokumentálj

    A magas rendelkezésre állási politikákat alaposan tesztelni és ellenőrizni kell már az elejétől fogva, hogy a jelenlegi elérhetőségi politikák megfeleljenek az SLA-knak. Azonban amikor egy magas rendelkezésre állási stratégia elindul, rendszeresen tesztelni és validálni kell, hogy a jelenlegi szabályzat továbbra is megfeleljen az SLA-knak az adatnövekedés, az üzleti vagy igények változása ellenére. Ugyanakkor a rendelkezésre állási megoldás konfigurációját, a failover módszerét és a katasztrófa-helyreállítási tervet egyszerre kell dokumentálni, hogy nyomon követhető legyen hiba esetén vagy a magas rendelkezésre állási stratégia jövőbeni módosítása esetén.

Ez a cikk bemutatja a magas rendelkezésre állás alapvető fogalmait, az SLA-k fogalmát, az SQL Server által támogatott különféle magas rendelkezésre állási funkciókat, valamint a magas rendelkezésre állási stratégia megtervezéséhez szükséges lépéseket. Érdemes megjegyezni, hogy bár ez a cikk csak az adatbázis szintű magas elérhetőségről szól, a magas rendelkezésre állás nemcsak a DBA hatásköre, hanem magában foglalja különböző szerepkörök, például rendszerüzemeltetési és karbantartó személyzet, hálózatadminisztrátorok, fejlesztők és menedzserek együttműködését is, hogy jobban megfeleljenek az SLA-knak.