[Allikas] Kõrge kättesaadavus SQL Serveris (1) ---- ülevaade kõrgest kättesaadavusest

Alates SQL Server 2005-st on Microsoft pakkunud mitmesuguseid kõrge kättesaadavusega tehnoloogiaid, et vähendada seisakuid ja suurendada äriandmete kaitset, ning SQL Server 2008, SQL Server 2008 R2 ja SQL Server 2012 pideva väljalaskmisega on SQL Serveris palju kõrge kättesaadavusega tehnoloogiaid, mis sobivad erinevateks olukordadeks.

    Enne kui selle artikli alustan, annan lühikese ülevaate sellest, mis määrab, millist kõrge kättesaadavusega tehnoloogiat kasutada.

    Paljud ettevõtted vajavad, et kogu või osa nende andmetest oleks kõrgelt kättesaadavad, näiteks veebipõhised ostusaidid, veebipõhised tooteandmebaasid peavad olema veebis 24/7, vastasel juhul väga konkurentsitihedas turukeskkonnas tähendab seisakud klientide ja tulude kaotust. Näiteks kõnekeskuses, mis tugineb SQL Serverile, kui andmebaas läheb rivist välja, saavad kõik helistajad lihtsalt istuda ja vastata kliendile "Vabandust, süsteemirike", mis on samuti vastuvõetamatu.

    Ideaalmaailmas on muidugi kogu kriitiline info kogu aeg võrgus, kuid päriselus on andmebaasi kättesaamatuks mitmeid põhjuseid, sest katastroofi aega ja vormi on võimatu ennustada, on vaja ette võtta meetmeid erinevate hädaolukordade vältimiseks, seega pakub SQL Server mitmesuguseid kõrge kättesaadavusega tehnoloogiaid, mis hõlmavad peamiselt: klasterdamist, replikatsiooni, peegeldamist, logide edastamist, AlwaysOn kättesaadavusgruppe ja muid nagu failigrupi varundamine ja taastamine, Ühe instantsi kõrge kättesaadavusega tehnoloogiad, nagu veebipõhised rekonstrueerimise indeksid. Kõrge kättesaadavusega tehnoloogia kasutamine ei tähenda tuttavat tehnoloogiat otseseks kasutamiseks, vaid äri ja tehnoloogia terviklikku kaalumist. Sest puudub üksainus tehnoloogia, mis suudaks kõiki funktsioone täita. Kuidas neid tehnoloogiaid rakendada vastavalt oma konkreetsele ettevõttele ja eelarvele, on nn kõrge kättesaadavuse strateegia.

Kõrge kättesaadavusega strateegia koostamisel tuleks esmalt arvestada järgmiste teguritega:

• RTO (taastumisaja eesmärk) – see tähendab, et taastumisaja eesmärk tähendab, kui palju seisakuid on lubatud, tavaliselt väljendatud mõne üheksaga, näiteks 99,999% kättesaadavus tähendab mitte rohkem kui 5 minutit seisakut aastas, 99,99% kättesaadavus tähendab mitte rohkem kui 52,5 minutit seisakut aastas ja 99,9% kättesaadavus tähendab mitte rohkem kui 8,75 tundi seisakut aastas. Tasub märkida, et RTO arvutusmeetod arvestab, kas süsteem on 24*365 või lihtsalt 6–9 õhtul jne. Samuti tuleb tähelepanu pöörata, kas hooldusaken loetakse seisakuteks ning suurema kättesaadavuse saavutamine on lihtsam, kui andmebaasi hooldus ja parandused on hooldusakna ajal lubatud.
• RPO (Recovery Point Objective) – tuntud ka kui taastamispunkti eesmärk, tähendab, kui palju andmekadu on lubatud. Tavaliselt, kui teed hea varukoopia, on lihtne saavutada null andmekaotus. Kuid katastroofi korral, sõltuvalt andmebaasi korruptsiooni ulatusest, muudab andmete taastamine varukoopiast andmebaasi kättesaamatuks, mis mõjutab RTO rakendamist. Varajane ja kuulsam näide on pangandussüsteem Euroopas ja Ameerika Ühendriikides, kus arvestatakse ainult RPO-d, süsteemis on ainult täielikud varukoopiad ja logide varukoopiad, täielikud varukoopiad iga 3 kuu tagant, logi varukoopiad iga 15 minuti järel, kui katastroof juhtub, saab andmeid taastada ainult täielike varukoopiate kaudu, nii et kuigi andmete kadu ei toimu, kuid kuna andmete taastamine võttis kaks täispäeva, oli pangandussüsteem kahe päeva jooksul kättesaamatu ning suur hulk kliente kaotati. Teine vastupidine näide on kodumaine veebipõhine videoveebileht, kus SQL Serverit kasutatakse taustarelatsioonilise andmebaasina, esiosa kasutab No-SQL-i ja impordib regulaarselt No-SQL andmeid relatsioonilisse andmebaasi varukoopiana.
  

    Eelarve – RTO ja RPO on ühiselt tuntud kui SLA-d (teenindustaseme kokkulepped) ning kõrge kättesaadavuse strateegia koostamisel tuleb mõõta, kui hästi sa SLA-d täidad, lähtudes oma ettevõttest, sõltuvalt eelarvest ja erinevate SLA-de maksumust rikke korral. Üldiselt on piiratud eelarvega raske saavutada kõrgeid SLA-sid ning isegi kui kõrged SLA-d saavutatakse keerukate arhitektuuride kaudu, tähendavad keerukad arhitektuurid ka kõrgeid tegevus- ja hoolduskulusid, mistõttu tuleb valida eelarve sees õige tehnoloogia, et täita SLA-sid.

Seetõttu saab üldiselt kõrge kättesaadavuse suurt raamistikku määrata mitme tellimuse võtmise küsimusega:

• Millist seisakut on aktsionärid valmis aktsepteerima?
• Milline vaba aeg on juhtidele vastuvõetav?
• Milline on kõrge kättesaadavuse stsenaariumi eelarve?
• Kui suur on tunnikaotus seisakute tõttu?
  

• Külmvarundamine: Ooteserver on seadistatud vastu võtma esmase serveri andmeid ning kui see ebaõnnestub, taastab andmed käsitsi põhiandmebaasi või konfigureerib ümber ühenduse stringi või programmi õigused, et varundusandmebaas võrgutada.
• Soe varundamine: Esmase serveri andmed edastavad pidevalt logisid varundusserverisse (ebaregulaarselt, see võib olla 15 minutit, 30 minutit, 1 minut jne), nii uuendatakse esmaserverit varundusserverisse tavaliselt asünkroonselt, mistõttu ei saa peaserveri ja varuserveri andmeid garanteerida. Lisaks ei rakenda see skeem tavaliselt automaatset rikete jälgimist ega varukoopiat.
• Kuum varundamine: Esmase serveri andmed sünkroniseeritakse automaatselt varundusserveris ning enamasti on kaasatud automaatne rikete jälgimine ja varukoopia ning põhiserveri ja varundusserveri andmete järjepidevus on garanteeritud.
  

    Külma kuni sooja ja kuuma varukoopia puhul tõusevad kulud taevasse.

    SQL Serveri toetatud kõrge kättesaadavusega funktsioonid on tihedalt seotud selle versiooniga ning Enterprise versioon toetab kõiki kõrge kättesaadavusega funktsioone, sealhulgas:

• Failover-klaster
• l Andmebaasi pilt
• l Tehingulogi edastus
• l Andmebaasi hetkepildid
• l Kõrge saadavuse uuendused
• l Mälu kuumlaadimine
• l Veebiindekseerimise operatsioonid
• l Andmebaas osaliselt veebis (taastatakse ainult põhifailigrupp või peafailigrupp ja täiendavad NDF-failid)
  

    Konkreetsete kõrge kättesaadavusega versioonide kohta vaata:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxTasub märkida, et tasuta Expressi versioon võib toimida andmebaasi peegeldamise tunnistajaserverina, mis toob kaasa kulude kokkuhoiu.

Failover-klaster

    Failover-klastrid pakuvad kõrge kättesaadavuse tuge kogu SQL Serveri instantsile, mis tähendab, et SQL Serveri eksemplar klastri sõlmes liigub üle teistele sõlmedele klastris riistvaravigade, operatsioonisüsteemi vigade jms tõttu. Kõrge kättesaadavus saavutatakse, kui mitu serverit (sõlme) jagavad üht või mitut ketast, ning varuklastrid ilmuvad võrgus samamoodi nagu üks arvuti, kuid kõrge kättesaadavuse omadustega. Oluline on märkida, et kuna failover-klastrid põhinevad jagatud ketastel, on ketta rikke üks punkt, mistõttu tuleb kettatasemel rakendada täiendavaid kaitsemeetmeid, nagu SAN replikatsioon. Kõige levinum varukoopiaklaster on kahe sõlmega failover-klaster, mis sisaldab masterit ja slave'i.

Tehingulogi edastamine

    Tehingulogi saatmine tagab andmebaasitasemel kõrge kättesaadavuse kaitse. Logimist kasutatakse ühe või mitme ooteandmebaasi (nn "sekundaarandmebaasid") haldamiseks vastavas tootmisandmebaasis (nn "primaarne andmebaas"). Enne varuülekannet tuleb sekundaarne andmebaas täielikult uuendada, rakendades käsitsi kõik taastatud logide varukoopiad. Logide edastamisel on paindlikkus toetada mitut ooteandmebaasi. Kui on vaja mitut alternatiivset andmebaasi, saab logide edastamist kasutada eraldi või andmebaasi peegeldamise täiendusena. Kui neid lahendusi koos kasutada, on praeguse andmebaasi peegeldava konfiguratsiooni peamine andmebaas ka praeguse logisaatmise konfiguratsiooni peamine andmebaas.

    Tehingulogi edastamist saab kasutada nii külmade kui soojade varukoopiate tegemiseks.

Andmebaasi peegeldamine

    Andmebaasi peegeldamine on tegelikult tarkvaralahendus, mis pakub ka andmebaasi tasandi kaitset, pakkudes peaaegu kohest ülekannet andmebaasi kättesaadavuse parandamiseks. Andmebaasi peeglit saab kasutada ühe reservandmebaasi (või nn "peegelandmebaasi") haldamiseks vastava tootmisandmebaasi jaoks (nn "põhiandmebaas").
Kuna peegelandmebaas on alati taastamise seisundis, kuid andmebaasi ei taastata, ei saa peegliandmebaasile otse ligi. Kuid ainult lugemiseks mõeldud laadimiste, nagu aruannete, puhul saab peegeldatavat andmebaasi kasutada kaudselt, luues peegeldatud andmebaasist hetkepildi. Andmebaasi hetktõmmised annavad klientidele ainult lugemisõiguse andmebaasis olevatele andmetele hetktõmmise loomisel. Iga andmebaasi peegeldamise konfiguratsioon hõlmab "põhiserverit", mis sisaldab peamist andmebaasi, ning samuti peegelserverit, mis sisaldab peegeldatud andmebaasi. Peegliserver uuendab pidevalt peegli andmebaasi peamise andmebaasiga.
    Andmebaasi peegeldamine töötab sünkroonses töös kõrge turvalisuse režiimis või asünkroonses töös kõrge jõudluse režiimis. Kõrge jõudlusega režiimis ei pea tehingud ootama, kuni peegelserver logid kettale kirjutab, enne kui need esitatakse, mis maksimeerib jõudlust. Kõrge turvalisusega režiimis sõlmivad mõlemad partnerid pühendunud tehinguid, kuid tehingu viivituse aeg pikeneb. Lihtsaim andmebaasi peegeldamise konfiguratsioon hõlmab ainult peamist serverit ja peegelserverit. Selles konfiguratsioonis, kui peamine server kaob, saab peegelserverit kasutada ooteserverina, kuid see võib põhjustada andmekadu. Kõrge turvalisusega režiim toetab ooterežiimi konfiguratsiooni koos automaatse varuülekandega. See konfiguratsioon hõlmab kolmanda osapoole serveri instantsi, mida nimetatakse "tunnistajaserveriks", mis võimaldab peegelserverit kasutada kuuma varundusserverina. Varuülekanne esmasest andmebaasist peegelandmebaasi võtab tavaliselt paar sekundit.

    Andmebaasi peegeldamist saab kasutada nii soojade kui kuumade varukoopiate jaoks.

koopia

    Replikatsioon ei ole rangelt kõrge kättesaadavuse jaoks mõeldud funktsioon, kuid seda saab rakendada kõrge kättesaadavuse puhul. Replikatsioon pakub andmebaasi objektitasandi kaitset. Replikatsioon kasutab avalda-telli mudelit, kus andmed avaldatakse peamise serveri ehk kirjastaja kaudu ühele või mitmele teisele või tellijale. Replikatsioon tagab reaalajas kättesaadavuse ja skaleeritavuse nende serverite vahel. See toetab filtreerimist, et pakkuda abonentidele alamhulka andmeid, ning toetab ka partitsioonide uuendusi. Tellija on veebis ja saadaval aruandluseks või muuks funktsiooniks ilma päringute taastamiseta. SQL Server pakub nelja replikatsioonitüüpi: hetktõmmise replikatsioon, tehinguline replikatsioon, peer-to-peer replikatsioon ja ühinemisreplikatsioon.

AlwaysOnKasutatavuse grupp

    AlwaysOn Availability Groups on uus funktsioon, mis tutvustati SQL Server 2012-s. Pakutakse ka andmebaasitasandi kaitset. See laiendab ka piiri, et andmebaasi peegeldamine võib olla ainult 1:1, nii et üks primaarne replika võib vastata kuni 4 sekundaarsele replikale (SQL Server 2014-s on see piirang laiendatud 8-ni), millest 2 sekundaarset replikat saab sünkroniseerida kuumade varukoopiatena ja primaarsete koopiatena reaalajas ning ülejäänud kaks asünkroonset sekundaarset replikat saab kasutada soojade varukoopiatena. Lisaks saab sekundaarseid replikasid konfigureerida ainult lugemiseks ning neid saab kasutada varukoopiate koormuse kandmiseks.

    Seetõttu on andmebaasi peegeldamine SQL Server 2012-s märgitud kui "aegunud".

    Pärast kõrge kättesaadavuse põhikontseptsioonide ja SQL Serveri pakutavate kõrge kättesaadavuse tehnoloogiate mõistmist vaatame üle kõrge kättesaadavuse strateegia disaini. Kõrge kättesaadavusega strateegia planeerimine jaguneb neljaks etapiks:

Kogumisnõuded

    Esimene samm kõrge kättesaadavuse strateegia otsustamisel on kahtlemata ärinõuete kogumine SLA-de kehtestamiseks. RTO ja RPO on kõige kriitilisemad osad ning selle põhjal kehtestatakse realistlikud ootused saadavuse nõuetele ja realistlik kõrge kättesaadavuse strateegia nende põhjal.

Hindamispiirid

    Hindamispiirangud ei piirdu ainult erinevate SQL Serveri kõrge kättesaadavusega tehnoloogiate piirangutega, vaid ka mittetehniliste tehnoloogiatega. Kui sul on eelarve vaid kümneid tuhandeid jüaane, kuid soovid teha kõrge kättesaadavusega lahenduse, mis põhineb väljaspool asuvaid andmekeskusi ja SAN replikatsiooni, siis on see kahtlemata rumal unistus. Teine mitte-tehniline piirang on operatsioonipersonali tase ning sageli tähendab keerukas arhitektuur oskuslikumat operatsioonipersonali. Muud mittetehnilised piirangud hõlmavad andmekeskuse kettaruumi olemasolu, seda, kas toiteallikas ja konditsioneer suudavad vajadusi rahuldada ning aeg, mis kulub saadavuse strateegia rakendamiseks.

    Tehnilised piirangud hõlmavad erinevaid kõrge kättesaadavusega funktsioone ja piiranguid, erinevate SQL Serveri versioonide toetatud funktsioone, protsessorite arvu ja mälu suurust. Soovitatav on esmalt viidata erinevate SQL Serveri versioonide ja funktsioonide piirangutele Microsoft MSDN veebilehel enne kõrge kättesaadavuse poliitika rakendamist.

Valiktehnoloogia

    Pärast nõuete kogumist ja piirangute hindamist on järgmine samm valida selles artiklis kirjeldatud tehnoloogiad või nende kombinatsioon, et täita SLA nõudeid. Kui valitud tehnoloogia ei vasta SLA-le, on lihtne teatada, millised piirangud SLA-le ei vasta, võimaldades teil taotleda puuduvaid ressursse või kompromisse SLA-s.

Testi, valideeri ja dokumenteeri

    Kõrge kättesaadavusega poliitikaid tuleb algusest peale põhjalikult testida ja valideerida, et tagada kehtivate saadavuse poliitikate vastavus SLA-dele. Kuid kõrge kättesaadavuse strateegia käivitamisel on vajalik seda regulaarselt testida ja valideerida, et veenduda, kas praegune poliitika suudab endiselt täita SLA-sid hoolimata andmete kasvust, ärist või nõuete muutustest. Samal ajal tuleks dokumenteerida saadavuse lahenduse konfiguratsioon, varukoopia meetod ja katastroofide taastamise plaan, et neid saaks jälgida rikke korral või tulevikus kõrge kättesaadavuse strateegia kohandamisel.

See artikkel selgitab kõrge kättesaadavuse põhikontseptsioone, SLA-de mõistet, SQL Serveri toetatud erinevaid kõrge kättesaadavusega funktsioone ning samme, mis on vajalikud kõrge kättesaadavuse strateegia kujundamiseks. Tasub märkida, et kuigi see artikkel käsitleb ainult kõrget kättesaadavust andmebaasi tasandil, ei ole kõrge kättesaadavus ainult DBA küsimus, vaid hõlmab ka erinevate rollide, nagu süsteemi opereerimise ja hoolduse personali, võrguadministraatorite, arendajate ja juhtide, koostööd, et paremini täita SLA-sid.