[Vir] Visoka razpoložljivost v SQL Serverju (1) ---- pregled visoke razpoložljivosti

Od SQL Server 2005 naprej je Microsoft zagotovil različne tehnologije visoke razpoložljivosti za zmanjšanje izpadov in povečanje zaščite poslovnih podatkov, z neprekinjeno izdajo SQL Server 2008, SQL Server 2008 R2 in SQL Server 2012 pa je v SQL Serverju na voljo veliko visokorazpoložljivih tehnologij za različne scenarije.

    Preden začnem s tem člankom, bom na kratko predstavil, kaj določa, katero visoko razpoložljivo tehnologijo uporabiti.

    Mnoga podjetja potrebujejo, da so vsi ali del njihovih podatkov zelo dostopni, na primer spletne nakupovalne spletne strani; spletne baze podatkov izdelkov morajo biti na voljo 24/7, sicer v zelo konkurenčnem tržnem okolju izpadi pomenijo izgubo strank in prihodkov. Na primer, v klicnem centru, ki temelji na SQL Serverju, če baza podatkov ne deluje, lahko vsi klicatelji le sedijo in odgovorijo stranki "Oprostite, okvara sistema", kar je prav tako nesprejemljivo.

    Seveda bi bili v idealnem svetu vsi kritični podatki ves čas na spletu, v resničnem svetu pa bi obstajali različni razlogi, zakaj baza podatkov ni na voljo, saj ni mogoče napovedati časa in vrste nesreče, zato je treba vnaprej sprejeti ukrepe za preprečevanje različnih izrednih razmer, zato SQL Server ponuja različne tehnologije z visoko dostopnostjo, ki predvsem vključujejo: gručenje, replikacijo, zrcaljenje, dostavo dnevnikov, skupine razpoložljivosti AlwaysOn in druge, kot so varnostno kopiranje in obnova skupin datotek, Enkratne tehnologije visoke razpoložljivosti, kot so spletni indeksi obnove. Uporaba tehnologije z visoko razpoložljivostjo ni namenjena izbiri znane tehnologije za neposredno uporabo, temveč celovitemu razmisleku o poslu in tehnologiji. Ker ni ene same tehnologije, ki bi lahko dosegla vse funkcije. Kako sprejeti te tehnologije glede na vaše podjetje in proračun, je t. i. strategija visoke razpoložljivosti.

Pri oblikovanju strategije visoke razpoložljivosti morate najprej upoštevati naslednje dejavnike:

• RTO (Cilj časa okrevanja) – torej cilj časa okrevanja, pomeni, koliko izpadov je dovoljeno, običajno izraženih z nekaj devetkami, na primer, 99,999 % razpoložljivosti pomeni največ 5 minut izpadov na leto, 99,99 % razpoložljivosti pomeni največ 52,5 minute izpadov na leto, 99,9 % razpoložljivosti pa ne več kot 8,75 ur izpadov na leto. Vredno je omeniti, da metoda izračuna RTO upošteva, ali je sistem 24*365 ali le od 6. do 21. ure itd. Prav tako morate biti pozorni, ali se vzdrževalno okno šteje kot izpad, in lažje je doseči večjo razpoložljivost, če je vzdrževanje in popravljanje podatkovne baze dovoljeno med vzdrževalnim oknom.
• RPO (Cilj točke okrevanja) – Znan tudi kot cilj točke okrevanja, pomeni, koliko izgube podatkov je dovoljeno. Običajno, če narediš dobro varnostno kopijo, lahko brez izgube podatkov dosežeš. Ko pa pride do nesreče, odvisno od obsega poškodbe podatkovne baze, čas, potreben za obnovo podatkov iz varnostne kopije, povzroči, da baza podatkov postane nedosegljiva, kar vpliva na implementacijo RTO. Zgodnji in bolj znan primer je bančni sistem v Evropi in Združenih državah Amerike, upoštevajoč le RPO, kjer so v sistemu le popolne varnostne kopije in varnostne kopije dnevnikov, polne varnostne kopije vsakih 3 mesece, varnostne kopije dnevnikov vsakih 15 minut; ko pride do nesreče, lahko podatke obnovijo le popolne varnostne kopije, in varnostne kopije dnevnikov lahko obnovijo, tako da čeprav ni izgube podatkov, je bil bančni sistem 2 dni nedosegljiv, zato je bilo izgubljenih veliko strank. Drug nasproten primer je domača spletna video spletna stran, ki uporablja SQL Server kot ozadje relacijske baze podatkov, front-end uporablja NoSQL in redno uvaža No-SQL podatke v relacijsko bazo kot varnostno kopijo.
  

    Proračun – RTO in RPO sta skupaj znana kot SLA (Service Level Agreements), pri oblikovanju strategije visoke razpoložljivosti pa morate izmeriti, kako dobro izpolnjujete SLA glede na vaše podjetje, glede na vaš proračun in meriti stroške različnih SLA v primeru neuspeha. Na splošno je težko doseči visoke SLA-je z omejenim proračunom, in tudi če so visoki SLA-ji doseženi s kompleksnimi arhitekturami, kompleksne arhitekture pomenijo tudi visoke stroške obratovanja in vzdrževanja, zato je treba izbrati pravo tehnologijo znotraj proračuna za izpolnjevanje SLA-jev.

Zato je na splošno mogoče velik okvir za visoko razpoložljivost določiti z več vprašanji o sprejemanju naročil:

• Kakšen čas izpada so delničarji pripravljeni sprejeti?
• Kateri čas brez dela je sprejemljiv za vodje?
• Kakšen je proračun za scenarij visoke razpoložljivosti?
• Koliko je izguba na uro zaradi izpadov?
  

• Hladno varnostno kopiranje: Rezervni strežnik je konfiguriran tako, da sprejema podatke primarnega strežnika, in ko ta odpove, ročno obnovi podatke v primarno bazo podatkov ali ponovno nastavi povezovalni niz oziroma dovoljenja programa, da se varnostna baza omogoči zagonu.
• Topla varnostna kopija: Primarni podatki strežnika neprekinjeno prenašajo dnevnike na varnostni strežnik (v nerednih intervalih, lahko 15 minut, 30 minut, 1 minuto itd.), na ta način se primarni strežnik do rezervnega strežnika običajno posodablja asinhrono, zato podatkov primarnega strežnika in varnostnega strežnika ni mogoče zagotoviti. Poleg tega ta shema običajno ne izvaja samodejnega spremljanja napak in preklopa v primeru izpadov.
• Vroča varnostna kopija: Podatki primarnega strežnika se samodejno sinhronizirajo na varnostnem strežniku, v večini primerov pa so vključeni tudi samodejno spremljanje napak in preklop v primeru izpada, poleg tega pa je zagotovljena konsistentnost podatkov med primarnim in rezervnim strežnikom.
  

    Od hladnih do toplih in vročih rezervnih kopij stroški strmo narastejo.

    Funkcije visoke razpoložljivosti, ki jih podpira SQL Server, so tesno povezane z različico, Enterprise različica pa podpira vse funkcije visoke razpoložljivosti, vključno z:

• Preklopni gručič
• l Slika baze podatkov
• Prenos transakcijskega dnevnika
• l Posnetki baze podatkov
• Nadgradnje z visoko razpoložljivostjo
• l Vroča obremenitev pomnilnika
• l Spletne indeksne operacije
• l Podatkovna baza delno na spletu (samo skupina glavnih datotek ali skupina glavnih datotek ter dodatne NDF datoteke so obnovljene)
  

    Za specifične različice z visoko razpoložljivostjo glejte:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxVredno je omeniti, da lahko brezplačna Express različica služi kot strežnik za zrcaljenje, kar prinaša prihranke stroškov.

Preklopni gručič

    Failover grozdi zagotavljajo visoko razpoložljivost za celotno SQL Server instanco, kar pomeni, da SQL Server instanca na vozlišču gruče zaradi napak strojne opreme, operacijskega sistema itd. preklopi na druga vozlišča v gruči. Visoka razpoložljivost je dosežena z več strežniki (vozlišči), ki si delijo enega ali več diskov, preklopni gruči pa se v omrežju pojavijo na enak način kot en računalnik, vendar z visokimi značilnostmi razpoložljivosti. Pomembno je poudariti, da ker so preklopni grozdi osnovani na skupnih diskih, obstaja ena sama točka okvare diska, zato je treba na ravni diska uvesti dodatne zaščite, kot je SAN replikacija. Najpogostejši gruči za preklop v primeru izpada je grozd z dvema vozliščatoma, vključno z glavnim in podrejenim grozdom.

Prenos transakcijskega dnevnika

    Pošiljanje transakcijskih dnevnikov zagotavlja visoko razpoložljivost na ravni baze podatkov. Beleženje se uporablja za vzdrževanje ene ali več rezervnih podatkovnih baz (imenovanih "sekundarne baze") ustrezne produkcijske baze podatkov (imenovane "primarna podatkovna baza"). Preden pride do failoverja, je treba sekundarno bazo podatkov popolnoma posodobiti z ročno uporabo vseh neobnovljenih varnostnih kopij dnevnikov. Dostava dnevnikov ima prilagodljivost za podporo več rezervnih baz podatkov. Če je potrebnih več alternativnih baz podatkov, se lahko dostava dnevnikov uporablja ločeno ali kot dopolnilo k zrcaljenju podatkovne baze. Ko se te rešitve uporabljajo skupaj, je glavna podatkovna baza trenutne konfiguracije zrcaljenja podatkovne baze tudi primarna podatkovna baza trenutne konfiguracije pošiljanja dnevnikov.

    Dostava dnevnikov transakcij se lahko uporablja za hladne in tople varnostne kopije.

Zrcaljenje podatkovne baze

    Zrcaljenje podatkovne baze je pravzaprav programska rešitev, ki zagotavlja tudi zaščito na ravni podatkovne baze, saj omogoča skoraj takojšen failover za izboljšanje razpoložljivosti podatkovne baze. Zrcalo baze podatkov se lahko uporablja za vzdrževanje ene rezervne baze podatkov (ali "zrcalne baze") za ustrezno produkcijsko bazo podatkov (imenovano "glavna podatkovna baza").
Ker je zrcalna baza podatkov vedno v obnovitvenem stanju, vendar baza ni obnovljena, zrcalne baze podatkov ni mogoče neposredno dostopati. Vendar pa lahko za nalaganja samo za branje, kot so poročila, posredno uporabite zrcaljeno bazo z ustvarjanjem posnetka zrcaljene baze podatkov. Posnetki baze podatkov omogočajo strankam dostop do podatkov v bazi samo za branje, ko je posnetek ustvarjen. Vsaka konfiguracija zrcaljenja baze podatkov vključuje "glavni strežnik", ki vsebuje glavno bazo podatkov, prav tako pa zrcalni strežnik, ki vsebuje zrcalno bazo podatkov. Zrcalni strežnik neprekinjeno posodablja zrcalno bazo podatkov z glavno bazo podatkov.
    Zrcaljenje podatkovnih baz deluje sinhrono v načinu visoke varnosti ali asinhrono v načinu visoke zmogljivosti. V načinu visoke zmogljivosti transakcijam ni treba čakati, da zrcalni strežnik zapiše dnevnike na disk, preden jih lahko odda, kar maksimira zmogljivost. V načinu visoke varnosti oba partnerja izvajata zavezujoče transakcije, vendar se zamik transakcije podaljša. Najpreprostejša konfiguracija zrcaljenja baze podatkov vključuje le glavni strežnik in zrcalni strežnik. V tej konfiguraciji, če se glavni strežnik izgubi, se zrcalni strežnik lahko uporabi kot rezervni strežnik, vendar lahko povzroči izgubo podatkov. Način visoke varnosti podpira konfiguracijo v pripravljenosti z visokim varnostnim načinom z avtomatskim preklopom v primeru izpada v sili. Ta konfiguracija vključuje tretjo osebno strežniško instanco, imenovano "witness server", ki omogoča uporabo zrcalnega strežnika kot vročega varnostnega kopije. Preklop iz primarne baze podatkov v zrcalno bazo običajno traja nekaj sekund.

    Zrcaljenje baze podatkov se lahko uporablja tako za tople kot za vroče varnostne kopije.

kopirati

    Replikacija ni strogo zasnovana za visoko razpoložljivost, vendar jo je mogoče uporabiti za visoko razpoložljivost. Replikacija zagotavlja zaščito na ravni objektov na ravni baze podatkov. Replikacija uporablja model objave-naročnine, kjer podatke objavi primarni strežnik, znan kot založnik, enemu ali več sekundarnim ali naročnikom. Replikacija omogoča dostopnost v realnem času in razširljivost med temi strežniki. Podpira filtriranje, ki naročnikom zagotavlja podmnožico podatkov, hkrati pa podpira posodobitve particij. Naročnik je na spletu in na voljo za poročanje ali druge funkcije brez obnove poizvedb. SQL Server ponuja štiri vrste replikacije: snapshot replikacijo, transakcijsko replikacijo, peer-to-peer replikacijo in združitveno replikacijo.

AlwaysOnSkupina uporabnosti

    AlwaysOn Availability Groups je nova funkcija, uvedena v SQL Server 2012. Zagotovljena je tudi zaščita na ravni baze podatkov. Prav tako razširja mejo, da je zrcaljenje baze podatkov lahko le 1:1, tako da lahko ena primarna replika ustreza do 4 sekundarnim replikam (v SQL Server 2014 je ta omejitev razširjena na 8), od katerih sta 2 sekundarni repliki lahko sinhronizirani kot vroče varnostne kopije in primarni repliki v realnem času, drugi dve asinhroni sekundarni repliki pa se lahko uporabljata kot topli varnostni kopiji. Poleg tega je mogoče sekundarne replike konfigurirati kot samo za branje in se uporabljajo za prevzem obremenitve varnostnih kopij.

    Zaradi tega je zrcaljenje baz podatkov v SQL Server 2012 označeno kot "zastarelo".

    Po razumevanju osnovnih konceptov visoke razpoložljivosti in tehnologij visoke razpoložljivosti, ki jih ponuja SQL Server, si poglejmo oblikovanje strategije visoke razpoložljivosti. Načrtovanje strategije visoke razpoložljivosti lahko razdelimo na štiri faze:

Zahteve za zbiranje

    Prvi korak pri odločitvi o strategiji visoke razpoložljivosti je nedvomno zbiranje poslovnih zahtev za vzpostavitev SLA-jev. RTO in RPO sta najpomembnejša dela, na tej podlagi pa določita realna pričakovanja glede zahtev po razpoložljivosti in na podlagi teh pričakovanj vzpostavita realno strategijo visoke razpoložljivosti.

Omejitve ocenjevanja

    Omejitve ocenjevanja niso omejene le na omejitve različnih tehnologij visoke razpoložljivosti v SQL Serverju, temveč tudi na tiste, ki niso tehnične. Če imate proračun v višini deset tisoč juanov, a želite narediti rešitev z visoko razpoložljivostjo, ki temelji na podatkovnih centrih zunaj lokacije in replikaciji SAN-ov, je to nedvomno norčev sanjski cilj. Druga netehnična omejitev je raven operativnega osebja, pogosto pa kompleksne arhitekture pomenijo več usposobljenega operativnega osebja. Druge netehnične omejitve vključujejo razpoložljivost prostora na disku v podatkovnem centru, ali napajanje in klimatska naprava lahko zadovoljita potrebe ter čas, potreben za izvedbo strategije razpoložljivosti.

    Tehnične omejitve vključujejo različne funkcije in omejitve visoke razpoložljivosti, funkcije, ki jih podpirajo različne različice SQL Serverja, število procesorjev in velikost pomnilnika. Močno priporočamo, da najprej preverite omejitve različnih različic in funkcij SQL Serverja na spletni strani Microsoft MSDN, preden uvedete politiko visoke razpoložljivosti.

Izbrana tehnologija

    Po zbiranju zahtev in oceni omejitev je naslednji korak izbira tehnologij ali kombinacij tehnologij, opisanih prej v tem članku, da izpolnite zahteve SLA. Če izbrana tehnologija ne izpolnjuje SLA, je enostavno poročati, katere omejitve ne izpolnjujejo SLA, kar vam omogoča zahtevo za manjkajoče vire ali kompromis glede SLA.

Testirajte, validirajte in dokumentirajte

    Politike visoke razpoložljivosti je treba od začetka temeljito testirati in validirati, da se zagotovi, da trenutne politike razpoložljivosti izpolnjujejo SLA. Vendar pa je ob uvedbi strategije visoke razpoložljivosti potrebno tudi redno testirati in preverjati, da se zagotovi, da trenutna politika še vedno izpolnjuje SLA-je kljub rasti podatkov, spremembam poslovanja ali zahtev. Hkrati je treba hkrati dokumentirati konfiguracijo rešitve razpoložljivosti, način preklopa in načrt za obnovo po nesreči, da jih je mogoče slediti v primeru okvare ali prihodnje prilagoditve strategije visoke razpoložljivosti.

Ta članek pojasnjuje osnovne koncepte visoke razpoložljivosti, koncept SLA-jev, različne vrste funkcij visoke razpoložljivosti, ki jih podpira SQL Server, ter korake, potrebne za oblikovanje strategije visoke razpoložljivosti. Vredno je omeniti, da čeprav ta članek govori le o visoki razpoložljivosti na ravni baze podatkov, visoka razpoložljivost ni le stvar DBA, temveč vključuje tudi sodelovanje različnih vlog, kot so osebje za upravljanje in vzdrževanje sistemov, omrežni administratorji, razvijalci in vodje, da bi bolje izpolnili SLA-je.