[Sursă] Disponibilitate ridicată în SQL Server (1) ---- o prezentare generală a disponibilității ridicate

De la SQL Server 2005, Microsoft a oferit o varietate de tehnologii de înaltă disponibilitate pentru a reduce perioadele de nefuncționare și a crește protecția datelor de afaceri, iar odată cu lansarea continuă a SQL Server 2008, SQL Server 2008 R2 și SQL Server 2012, există multe tehnologii de înaltă disponibilitate în SQL Server pentru a răspunde diferitelor scenarii.

    Înainte să încep acest articol, voi începe cu o scurtă prezentare generală a ceea ce determină ce tehnologie de înaltă disponibilitate să folosesc.

    Multe companii au nevoie ca toate sau parțial datele lor să fie foarte disponibile, cum ar fi site-urile de cumpărături online, bazele de date de produse online trebuie să fie online non-stop, altfel, într-un mediu de piață foarte competitiv, timpul de nefuncționare înseamnă pierdere de clienți și venituri. De exemplu, într-un call center care se bazează pe SQL Server, dacă baza de date cade, toți apelanții pot doar să stea acolo și să răspundă clientului "Ne pare rău, defecțiune a sistemului", ceea ce este de asemenea inacceptabil.

    Desigur, într-o lume ideală, toate datele critice ar fi online tot timpul, dar în lumea reală vor exista diverse motive pentru care baza de date nu este disponibilă, deoarece este imposibil să se prezică ora și forma dezastrului, este necesar să se ia măsuri dinainte pentru a preveni diverse urgențe, astfel SQL Server oferă o varietate de tehnologii de înaltă disponibilitate, acestea incluzând în principal: clusterizare, replicare, oglindire, livrare jurnal, grupuri de disponibilitate AlwaysOn și altele, cum ar fi backup-ul și restaurarea grupurilor de fișiere, Tehnologii de înaltă disponibilitate cu o singură instanță, cum ar fi indexurile online de reconstrucție. Utilizarea tehnologiei de înaltă disponibilitate nu are ca scop alegerea unei tehnologii familiare pentru utilizare directă, ci pentru a analiza afacerea și tehnologia în mod cuprinzător. Pentru că nu există o tehnologie unică care să poată îndeplini toate funcțiile. Modul în care poți adopta aceste tehnologii în funcție de afacerea și bugetul tău specific este ceea ce se numește o strategie de disponibilitate ridicată.

Când proiectezi o strategie de disponibilitate ridicată, ar trebui mai întâi să iei în considerare următorii factori:

• RTO (Obiectivul Timpului de Recuperare) - adică obiectivul timpului de recuperare, înseamnă cât timp de nefuncționare este permis, de obicei exprimat prin câteva 9s, de exemplu, disponibilitatea 99,999% înseamnă nu mai mult de 5 minute de nefuncționare pe an, disponibilitate 99,99% înseamnă nu mai mult de 52,5 minute pe an, iar disponibilitate 99,9% înseamnă nu mai mult de 8,75 ore de nefuncționare pe an. Este demn de menționat că metoda de calcul a RTO ia în considerare dacă sistemul este 24*365 sau doar de la 6 dimineața la 9 seara, etc. De asemenea, trebuie să fii atent dacă fereastra de întreținere este considerată ca perioadă de nefuncționare, iar este mai ușor să obții o disponibilitate mai mare dacă întreținerea bazei de date și aplicarea de patch-uri sunt permise în timpul ferestrei de mentenanță.
• RPO (Obiectivul Punctului de Recuperare) – Cunoscut și ca obiectivul punctului de recuperare, înseamnă câtă pierdere de date este permisă. De obicei, atâta timp cât faci un backup bun, poți obține cu ușurință zero pierderi de date. Dar când apare un dezastru, în funcție de gradul coruperii bazei de date, timpul necesar pentru restaurarea datelor dintr-un backup va face ca baza de date să devină indisponibilă, ceea ce va afecta implementarea RTO. Un exemplu timpuriu și mai cunoscut este un sistem bancar din Europa și Statele Unite, care doar luând în considerare RPO, există doar backup-uri complete și backup-uri de log în sistem, backup-uri complete la fiecare 3 luni, backup-uri de log la fiecare 15 minute; când apare un dezastru, doar prin backup-uri complete și backup-uri de log pot fi restaurate datele, deci, deși nu există pierderi de date, pentru că a durat două zile întregi restaurarea datelor, sistemul bancar a fost indisponibil timp de 2 zile, astfel că s-au pierdut un număr mare de clienți. Un alt exemplu opus este un site video online intern, care folosește SQL Server ca bază de date relațională din spate, front-end-ul folosește No-SQL și importă regulat date No-SQL în baza de date relațională ca backup.
  

    Buget – RTO-ul și RPO sunt cunoscute colectiv ca SLA-uri (Acorduri de Nivel de Serviciu), iar atunci când proiectezi o strategie de disponibilitate ridicată, trebuie să măsori cât de bine îndeplinești SLA-urile în funcție de afacerea ta, în funcție de buget și de măsurarea costului diferitelor SLA-uri în caz de eșec. În general, este dificil să se obțină SLA-uri mari cu un buget limitat, iar chiar dacă SLA-urile mari se obțin prin arhitecturi complexe, arhitecturile complexe implică și costuri mari de operare și întreținere, așa că este necesar să alegi tehnologia potrivită în buget pentru a respecta SLA-urile.

Prin urmare, în general, cadrul mare pentru disponibilitate ridicată poate fi determinat de mai multe întrebări legate de luarea comenzilor:

• Care este perioada de inactivitate pe care acționarii sunt dispuși să o accepte?
• Ce perioadă de inactivitate este acceptabilă pentru manageri?
• Care este bugetul oferit pentru un scenariu de disponibilitate ridicată?
• Cât este pierderea pe oră din cauza perioadelor de nefuncționare?
  

• Backup la rece: Serverul de rezervă este configurat să accepte datele serverului principal, iar când acesta eșuează, să restaureze manual datele în baza de date principală sau să reconfigureze șirul de conexiune sau permisiunile programului pentru a aduce baza de date de backup online.
• Backup cald: Datele serverului principal vor transmite continuu jurnale către serverul de backup (la intervale neregulate, pot fi de 15 minute, 30 de minute, 1 minut etc.), astfel, serverul principal către serverul de backup este de obicei actualizat asincron, astfel încât datele serverului principal și ale serverului de backup nu pot fi garantate. În plus, acest sistem nu implementează de obicei monitorizarea automată a defectelor și failover-ul.
• Backup la cald: Datele serverului principal sunt sincronizate automat pe serverul de backup și, în majoritatea cazurilor, monitorizarea automată a defectelor și failover-ul sunt incluse, iar consistența datelor dintre serverul principal și serverul de backup poate fi garantată.
  

    Pe măsură ce backup-urile de la rece la cald sau la cald cresc vertiginos.

    Funcțiile de disponibilitate ridicată suportate în SQL Server sunt strâns legate de această versiune, iar ediția Enterprise suportă toate funcțiile de disponibilitate ridicată, inclusiv:

• Clusterul de failover
• L Imagine din baza de date
• L Transmisia jurnalului tranzacțiilor
• L Instantanee din baza de date
• L Upgrade-uri de disponibilitate ridicată
• L Memorie de încărcare la cald
• L Operațiuni de indexare online
• Baza de date parțial online (doar grupul de fișiere master sau grupul de fișiere master și fișierele NDF suplimentare sunt restaurate)
  

    Pentru versiuni specifice care au o disponibilitate ridicată, vezi:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxMerită menționat că versiunea gratuită Express poate servi ca server martor pentru oglindirea bazei de date, ceea ce duce la economii de costuri.

Clusterul de failover

    Clusterele de failover oferă suport de disponibilitate ridicată pentru întreaga instanță SQL Server, ceea ce înseamnă că o instanță SQL Server de pe un nod din cluster face failover către alte noduri din cluster din cauza unor erori hardware, erori de sistem de operare etc. Disponibilitatea ridicată este realizată prin faptul că mai multe servere (noduri) împart unul sau mai multe discuri, iar clusterele de failover apar în rețea în același mod ca un singur calculator, dar cu caracteristici de disponibilitate ridicată. Este important de menționat că, deoarece clusterele de failover se bazează pe discuri partajate, există un singur punct de defecțiune al discului, astfel încât protecții suplimentare, cum ar fi replicarea SAN, trebuie implementate la nivel de disc. Cel mai comun cluster de failover este un cluster de failover cu două noduri, incluzând masterul și slavul.

Transmiterea jurnalului tranzacțiilor

    Expedierea jurnalelor de tranzacții oferă protecție la nivel de bază de date cu disponibilitate ridicată. Jurnalismul este folosit pentru a menține una sau mai multe baze de date de rezervă (numite "baze de date secundare") ale bazei de date de producție corespunzătoare (numită "bază de date primară"). Înainte ca un failover să aibă loc, baza de date secundară trebuie actualizată complet prin aplicarea manuală a tuturor backup-urilor de log nerestaurate. Livrarea jurnalului are flexibilitatea de a susține mai multe baze de date de rezervă. Dacă sunt necesare mai multe baze de date alternative, livrarea jurnalului poate fi folosită separat sau ca un complement la oglindirea bazei de date. Când aceste soluții sunt folosite împreună, baza de date principală a configurației actuale de oglindire a bazei de date devine și baza de date principală a configurației curente de transport a buștenilor.

    Livrarea jurnalelor tranzacțiilor poate fi folosită pentru a face backup-uri la rece și la cald.

Oglindirea bazei de date

    Oglindirea bazei de date este, de fapt, o soluție software care oferă, de asemenea, protecție la nivel de bază de date, oferind failover aproape instantaneu pentru a îmbunătăți disponibilitatea bazei de date. O oglindă de bază de date poate fi folosită pentru a menține o singură bază de date de rezervă (sau "bază de date oglindă") pentru baza de date de producție corespunzătoare (numită "baza de date principală").
Deoarece baza de date oglindă este întotdeauna în stare de restaurare, dar baza de date nu este restaurată, baza de date oglindă nu poate fi accesată direct. Totuși, pentru încărcări doar în citire, cum ar fi rapoartele, poți folosi baza de date oglindită indirect prin crearea unui snapshot al bazei de date oglindată. Instantaneele de bază de date oferă clienților acces doar în citire la datele din baza de date atunci când instantaneele sunt create. Fiecare configurație de oglindire a bazei de date implică un "server principal" care conține baza de date principală și implică, de asemenea, un server oglindă care conține baza de date oglindată. Serverul oglindă actualizează continuu baza de date oglindă cu baza de date principală.
    Oglindirea bazei de date rulează în operare sincronă în modul de securitate ridicată sau asincronă în modul de înaltă performanță. În modul de înaltă performanță, tranzacțiile nu trebuie să aștepte ca serverul oglindă să scrie loguri pe disc înainte de a putea fi trimise, ceea ce maximizează performanța. În modul de securitate ridicată, tranzacțiile angajate sunt angajate de ambii parteneri, dar timpul de întârziere al tranzacțiilor este prelungit. Cea mai simplă configurație de oglindire a bazei de date implică doar serverul principal și serverul oglindă. În această configurație, dacă serverul principal este pierdut, serverul oglindă poate fi folosit ca server de rezervă, dar poate cauza pierdere de date. Modul de securitate ridicată suportă configurarea standby, modul de securitate ridicată cu failover automat. Această configurație implică o instanță a unui server terț numită "server martor", care permite folosirea serverului oglindă ca server de backup cald. Failover-ul de la baza de date principală la baza de date oglindă durează de obicei câteva secunde.

    Oglindirea bazei de date poate fi folosită atât pentru backup-uri la cald, cât și la cald.

copie

    Replicarea nu este strict o caracteristică concepută pentru o disponibilitate ridicată, dar poate fi aplicată și pentru disponibilitate ridicată. Replicarea oferă protecție la nivel de obiect a bazei de date. Replicarea folosește un model de publicare-abonament, în care datele sunt publicate de serverul principal, cunoscut sub numele de publisher, către unul sau mai mulți abonați secundari sau abonați. Replicarea oferă disponibilitate și scalabilitate în timp real între aceste servere. Suportă filtrarea pentru a furniza un subset de date abonaților, în timp ce suportă și actualizări ale partițiilor. Abonatul este online și disponibil pentru raportare sau alte funcții fără a permite recuperarea interogărilor. SQL Server oferă patru tipuri de replicare: replicare instantanee, replicare tranzacțională, replicare peer-to-peer și replicare prin fuziune.

AlwaysOnGrupul de uzabilitate

    AlwaysOn Availability Groups este o funcționalitate nouă introdusă în SQL Server 2012. Este oferită și protecție la nivel de bază de date. De asemenea, extinde limita conform căreia oglindirea bazei de date poate fi doar 1:1, astfel încât o replică primară poate corespunde până la 4 replici secundare (în SQL Server 2014, această limită este extinsă la 8), dintre care 2 replici secundare pot fi sincronizate ca backup-uri la cald și replici primare în timp real, iar celelalte două replici secundare asincrone pot fi folosite ca backup-uri calde. În plus, replicile secundare pot fi configurate ca fiind doar în citire și pot fi folosite pentru a prelua sarcina backup-urilor.

    Din această cauză, oglindirea bazei de date este marcată ca fiind "învechită" în SQL Server 2012.

    După ce am înțeles conceptele de bază ale high availability și tehnologiile de înaltă disponibilitate oferite în SQL Server, să aruncăm o privire asupra designului unei strategii de înaltă disponibilitate. Planificarea unei strategii de disponibilitate ridicată poate fi împărțită în patru faze:

Cerințe de colectare

    Primul pas în alegerea unei strategii de disponibilitate ridicată este, fără îndoială, colectarea cerințelor de business pentru a stabili SLA-uri. RTO și RPO sunt cele mai critice părți și, pe această bază, stabiliți așteptări realiste privind cerințele de disponibilitate și stabiliți o strategie realistă de disponibilitate ridicată bazată pe aceste așteptări.

Limite de evaluare

    Limitele de evaluare nu sunt limitate doar la limitările diferitelor tehnologii de înaltă disponibilitate în SQL Server, ci și la cele care nu sunt tehnice. Dacă ai un buget de zeci de mii de yuani, dar vrei să faci o soluție de înaltă disponibilitate bazată pe centre de date off-site și replicare SAN, este fără îndoială un vis nebunesc. O altă limitare non-tehnică este nivelul personalului operațional, iar adesea, arhitecturile complexe înseamnă mai mult personal operațional calificat. Alte limitări non-tehnice includ disponibilitatea spațiului pe disc în centrul de date, dacă sursa de alimentare și aerul condiționat pot satisface nevoile și timpul necesar pentru implementarea strategiei de disponibilitate.

    Limitările tehnice includ funcții și limitări de înaltă disponibilitate, funcții suportate de versiuni diferite de SQL Server, numărul de procesoare și dimensiunea memoriei. Se recomandă cu tărie să consultați mai întâi limitările diferitelor versiuni și funcționalități SQL Server de pe site-ul Microsoft MSDN înainte de a implementa o politică de disponibilitate ridicată.

Tehnologie selectată

    După colectarea cerințelor și evaluarea constrângerilor, următorul pas este selectarea tehnologiilor sau combinației de tehnologii descrise anterior în acest articol pentru a îndeplini cerințele SLA. Dacă tehnologia selectată nu respectă SLA-ul, este ușor să raportezi ce limitări nu respectă SLA-ul, permițându-ți să soliciti resurse lipsă sau să faci compromisuri asupra SLA-ului.

Testează, validează și documentează

    Politicile de disponibilitate ridicată trebuie testate și validate riguros de la început pentru a se asigura că politicile actuale de disponibilitate respectă SLA-urile. Totuși, atunci când o strategie de disponibilitate ridicată este lansată, este necesar să o testezi și să o validezi regulat pentru a te asigura că politica actuală poate respecta SLA-urile în ciuda creșterii datelor, a schimbărilor de afaceri sau a cerințelor. În același timp, configurația soluției de disponibilitate, metoda de failover și planul de recuperare în caz de dezastru trebuie documentate simultan, astfel încât să poată fi urmărite în caz de eșec sau ajustare viitoare a strategiei de disponibilitate ridicată.

Acest articol explică conceptele de bază despre disponibilitate ridicată, conceptul de SLA-uri, diferitele tipuri de funcționalități de disponibilitate înaltă suportate în SQL Server și pașii necesari pentru a proiecta o strategie de disponibilitate ridicată. Este demn de menționat că, deși acest articol vorbește doar despre disponibilitatea ridicată la nivel de bază de date, disponibilitatea ridicată nu este doar o chestiune pentru DBA, ci include și colaborarea diferitelor roluri, cum ar fi personalul de operare și mentenanță a sistemului, administratorii de rețea, dezvoltatorii și managerii pentru a respecta mai bine SLA-urile.