Un cluster de servere vă permite să conectați mai multe servere fizice (noduri) care se servesc reciproc ca parteneri în procedura de tranziție către o resursă de rezervă.
Redundanța oferită de cluster oferă o durată semnificativ mai mare a muncii neîntrerupte necesare pentru critică
operațiuni. Timp de 13 ani de lucru cu SQL Server ™, am implementat multe clustere și, în fiecare caz, am propriile caracteristici. Această experiență mi-a permis să formulez o serie de sfaturi și recomandări care vor ajuta lucrul cu clustere să fie mai ușor și mai reușit.
Figura 1 Un alt grup
În cele din urmă, pentru a atinge adevăratul obiectiv al clustering-ului, este nevoie de un nivel ridicat de specialiști calificați în ceea ce privește disponibilitatea și de proceduri repetitive în caz de disfuncționalități. Deși gruparea este o asigurare bună împotriva defecțiunilor hardware, aceasta nu împiedică erorile utilizatorilor, cum ar fi dumpingul unui tabel important de către un administrator de baze de date nedorite în mijlocul nopții.
Clustere cu un nod
Chiar dacă este nevoie de un singur server în acest moment, este încă logic să ne gândim la crearea unui cluster cu un singur nod. Acest lucru va face posibilă actualizarea ulterioară a configurației în cluster fără a trebui să reanalizați sistemul. Trebuie doar să vă asigurați că echipamentul selectat este prezent în secțiunea Cluster Catalog Windows.
Abilitatea de a adăuga un nod mai târziu este utilă nu numai pentru a îmbunătăți nivelul de disponibilitate. Luați în considerare situația când, la un moment dat, se constată că puterea serverului este insuficientă. Aceasta înseamnă necesitatea migrației, adică a cheltuielilor de timp și de efort. Dacă aveți un cluster cu un singur nod, puteți efectua migrarea mult mai ușor și cu mai puțin timp de nefuncționare. Un nou nod este adăugat la cluster; Fișierele binare și pachetele de actualizare SQL Server sunt instalate pe noul nod, iar apoi serverul migrează la noul nod folosind procedura failover. După aceasta, trebuie să instalați patch-uri suplimentare lansate după service pack și, în final, să ștergeți vechiul nod. Timpul de oprire este limitat de timpul pentru a merge la resursele de rezervă și pentru a instala actualizări (dacă este necesar).
Desigur, asta ma făcut să mă gândesc din nou. La urma urmei, puteți crea script-uri care apelează CLUSTER.EXE pentru a adăuga un nod la Microsoft® Cluster Server (MSCS). Tot ce trebuie să faceți este să trimiteți numele nodului la scenariu, iar restul îl veți face singur. Într-o situație de urgență, automatizarea este un adevărat prieten.
Uneori, un nod este adăugat la cluster pentru a nu înlocui un alt nod. Poate că trebuie să adăugați instanțe suplimentare ale SQL Server în cluster și fiecare instanță necesită resurse separate pe disc. Deși mai multe instanțe ale serverului pot rula pe un nod, într-o astfel de situație trebuie să partajeze procesorul și memoria RAM, ceea ce duce la o scădere a performanței. Într-o situație ideală, o singură instanță trebuie să ruleze pe un singur nod. Cum pot garanta acest lucru când trec la o resursă de rezervă? Este foarte simplu! Unul dintre noduri nu trebuie să ruleze niciun serviciu, iar pe fiecare dintre nodurile rămase, o instanță a serverului SQL trebuie să fie difuzată. Aceasta este definiția clusterului "N + 1": N instanțe care rulează pe nodurile N + 1. Nodul suplimentar este rezervat.
Actualizarea serverului SQL
Care sunt opțiunile? Mai întâi, ia în considerare soluția cea mai scumpă: crearea unui cluster complet nou care va necesita servere noi și, eventual, o nouă rețea de stocare (SAN). Probabil, va fi posibil să păstrați întrerupătoarele de rețea existente, dar acest lucru epuizează posibilitățile de utilizare a echipamentului vechi. Evident, aceasta nu este o abordare ieftină, dar are avantaje. Echipamentele noi, de regulă, funcționează mult mai bine decât cele vechi; viteza și capacitatea discurilor sunt în continuă creștere. În consecință, productivitatea va crește datorită reînnoirii echipamentului. Pentru a avea întotdeauna echipamente moderne, poate chiar să aibă sens să o închiriezi.
Când hardware-ul este instalat, puteți crea un nou server virtual SQL Server și copiați bazele de date de producție în el și apoi supuneți noului sistem unui test cuprinzător pentru a rezolva problemele potențiale înainte ca serverul să se reseteze. Cu toate acestea, trebuie să creați scripturi pentru a transfera conturile de utilizator de la un server existent la unul nou. (Consultați support.microsoft.com/kb/246133 (în limba engleză)). De asemenea, este util să actualizați scriptul de creare a contului în cazul unei erori totale bruște.)
Pentru a minimiza timpul de nefuncționare, va trebui cel mai probabil să utilizați transportul jurnal, cu excepția cazului în care bazele de date sunt foarte mici și există o perioadă de timp în care nici un utilizator nu este conectat. Transportul în jurnal se poate face chiar înainte de transfer. Apoi, trebuie să deconectați utilizatorii, să tăiați și să livrați jurnalul final și să îndreptați aplicația către o instanță nouă. (Mai jos, în secțiunea despre oglindirea bazelor de date, este descrisă o alternativă interesantă pentru livrarea de jurnale.) Dacă utilizați aliasuri DNS, probabil că nici măcar nu trebuie să indicați aplicațiile într-o nouă instanță. În schimb, trebuie doar să actualizați aliasul DNS. Această abordare are următorul avantaj: dacă este necesar să opriți procesul de migrare la jumătatea drumului și să reveniți la starea inițială, această stare inițială va fi cel puțin disponibilă.
Puteți alege o opțiune mai puțin costisitoare, dar va necesita o planificare prealabilă mai complexă. Un cluster poate suporta mai multe instanțe ale unui server SQL Server, dar fiecare instanță trebuie să aibă propriile resurse de disc. Prin urmare, atunci când configurați o rețea de spațiu de stocare (SAN), un număr de unitate logică (LUN) ar trebui să fie rezervat pentru viitoarele actualizări. Pentru a face upgrade, trebuie să instalați fișiere binare SQL Server pe această resursă de disc. Apoi, ar trebui să testați sistemul și, când totul este gata, închideți serverul curent SQL, mutați resursele discului din vechiul grup SQL Server, actualizați dependențele și mutați noua instanță a SQL Server online. Apoi, trebuie să atașați bazele de date de la vechea instanță și puteți considera că operația a fost finalizată. (Ați făcut copii în avans, nu-i așa?)
Această abordare necesită mai puține cheltuieli, dar implică, de asemenea, o parte din risc. Dacă ceva nu merge bine, va fi imposibil să deconectați bazele de date de la noua instanță și să le returnați în locul lor original. În acest caz, recuperarea este posibilă numai din copii de rezervă, ceea ce poate conduce la perioade lungi de timp.
Alternativ, puteți pune două instanțe de SQL Server în rețeaua de stocare dacă există suficient spațiu în ea. Apoi, trebuie să restaurați copii de rezervă pentru producție (și să livrați jurnalele) o nouă instanță a serverului și să continuați aproximativ așa cum este descris mai sus. Cu toate acestea, acum există modalități de retragere. După terminarea migrării, puteți elibera resursele din rețeaua de stocare de la vechea instanță. Costul acestei acțiuni va fi egal doar cu prețul noilor discuri.
În primul rând, vom respinge o concepție greșită. Clustering MSCS este folosit pentru a crește nivelul de disponibilitate, nu pentru echilibrarea încărcării. În plus, SQL Server nu are capacitatea încorporată de a încărca automat echilibrarea. Echilibrarea încărcăturii este necesară prin proiectarea fizică a aplicației. Ce înseamnă asta?
Deoarece dimensiunea tabelului crește, este de așteptat o degradare a performanței, în special atunci când scanați masa. Atunci când numărul de linii ajunge la milioane și miliarde, soluția obișnuită până acum a fost utilizarea reprezentărilor partajate. Aceste viziuni partajate constau din tabele cu aceleași scheme, unite de instrucțiunile UNION ALL. În plus, pentru a verifica componentele tabelului, verificați constrângerile (instrucțiunea CHECK), care împiedică duplicarea datelor în vizualizarea partiționată. Dacă coloana utilizată în constrângerea de verificare face parte din cheia primară, vizualizarea este actualizabilă.
Poate că aveți câteva servere suplimentare, dar acestea nu sunt disponibile în secțiunea cluster director Windows. Nu aș vrea să cumpăr servere noi doar pentru suportul cluster atunci când există servere gratuite.
O alternativă tentantă pentru clustering este reflectarea bazelor de date. Pentru oglindire, aveți nevoie de trei componente: instanța în care este localizată baza de date oglindă (server primar), serverul de rezervă (mirror) și, dacă doriți să treceți automat la resursa de rezervă, al treilea (servant) server. Pe scurt, atunci când oglindesc o bază de date, se întâmplă următoarele: Tranzacția din baza de date de pe serverul principal este de asemenea pornită pe oglindă. Dacă serverul principal nu reușește, puteți să mutați baza de date într-o resursă de rezervă - un server oglindă. Dacă există un server de martori, acest lucru se va întâmpla automat. Reflecția oglindă trebuie să fie configurată pentru fiecare bază de date a aplicației dvs.; Pentru bazele de date de sistem, oglindirea nu este disponibilă.
Spre deosebire de un cluster, un server oglindit este o instanță separată a serverului SQL; acesta poate fi situat la mii de kilometri distanță de serverul principal. Cache-urile sale sunt populate prin acțiuni de actualizare care apar ca urmare a tranzacțiilor care sunt duplicate de pe serverul primar. Desigur, se presupune că serverul oglindă nu ia nicio măsură decât să primească tranzacții în oglindă de la serverul principal. Tranziția la resursa de rezervă în acest caz, ca regulă, are loc mai repede decât în cluster, deoarece serverele SQL Server cu oglindă funcționează deja. Deoarece cache-urile sunt deja pline (cel puțin parțial), performanța inițială nu este la fel de scăzută ca în scenariul cu clusterul. De asemenea, rețineți că, atunci când baza de date oglindită trece într-o resursă de rezervă, serverele primare și cele oglindite schimba rolurile.
Dezavantajul oglindării în oglindă a bazelor de date este nevoia de dublă capacitate a discurilor în comparație cu clusterul. De asemenea, este nevoie de mai multă putere de calcul dacă operația sincronă este necesară fără pierderi de date. După cum sa menționat deja, disponibilitatea ridicată nu este ieftină.
Deoarece serverul oglindă poate fi amplasat la o distanță mare de la sol, oglindire are sens să le utilizeze în caz de dezastru planuri de redresare (DR - de recuperare în caz de dezastru). Un cluster poate servi ca prima linie de apărare, dar ce se întâmplă dacă aplicăm atât gruparea congruente? Atunci când un cluster failover, atunci în cazul în care există este configurat serverul de oglindire martor devine ultimul majore la momentul respectiv, în timp ce SQL Server pus în cluster este din nou online. Cu toate acestea, trebuie amintit că failover la un server nou primar înapoi la noul server oglindă (cluster) nu se produce în mod automat. Prin urmare, este mai bine să nu activați failover automat pentru bazele de date oglindite atunci când este utilizat împreună cu un cluster.
Refacerea în caz de dezastru nu este singurul scop de a folosi oglindirea. Acest lucru este, de asemenea, util în situațiile în care trebuie să aplicați un pachet de actualizare sau un patch pe serverul principal; caz în care puteți comuta manual la o resursă de rezervă de pe serverul oglindă. În aplicarea pachetului de servicii sau remedierii rapide fostul serverul principal este temporar deconectat, iar tranzactiile finalizate efectuate pe noul server primar, să stea în linie, așteptând plecarea înapoi la noua oglindă (vechi principal) server. După instalarea pachetului service pack sau remediere rapidă este sincronizat, în urma căruia cele două servere sunt în deplină conformitate. Acum puteți schimba serverele primare și oglinda cu roluri. Timpul de inactivitate este de câteva secunde petrecute în tranziția către resursa de rezervă și înapoi. Această abordare poate fi, de asemenea, utilizată pentru a migra SQL Server pe un alt server fizic. Singura diferență este că nu trebuie să te întorci.
Creșteți flexibilitatea cu un server virtual
Figura 2 Utilizarea unui server virtual
Administratorul responsabil pentru implementarea SQL Server, trebuie să fiți sigur de disponibilitatea continuă a serverului. Pentru a atinge acest obiectiv, clustering-ul serverului ajută. Acest articol oferă câteva recomandări încercate și reale care vă ajută să începeți. Informații suplimentare suplimentare pot fi găsite pe bara laterală "Resurse pentru grupare".
Articole similare
Trimiteți-le prietenilor: