Salutare, cititori Habr! Subiectul acestui articol va fi implementarea instrumentelor de recuperare în caz de dezastru în sistemele de stocare AERODISK Engine. Inițial, am vrut să scriem într-un singur articol despre ambele instrumente: replicare și metrocluster, dar, din păcate, articolul s-a dovedit a fi prea lung, așa că am împărțit articolul în două părți. Să trecem de la simplu la complex. În acest articol, vom configura și testa replicarea sincronă - vom renunța la un centru de date și, de asemenea, vom întrerupe canalul de comunicare dintre centrele de date și vom vedea ce se întâmplă.
Clienții noștri ne pun adesea diverse întrebări despre replicare, așa că înainte de a trece la configurarea și testarea implementării replicilor, vă vom spune puțin despre ce este replicarea în stocare.
Un pic de teorie
Replicarea în sistemele de stocare este un proces continuu de asigurare a identității datelor pe mai multe sisteme de stocare simultan. Din punct de vedere tehnic, replicarea se realizează în două moduri.
Replicare sincronă – aceasta este copierea datelor din sistemul de stocare principal pe cel de rezervă, urmată de confirmarea obligatorie din ambele sisteme de stocare că datele au fost înregistrate și confirmate. După confirmarea de ambele părți (ambele sisteme de stocare), datele sunt considerate înregistrate și pot fi lucrate cu acestea. Acest lucru asigură identitatea garantată a datelor pe toate sistemele de stocare care participă la replica.
Avantajele acestei metode:
- Datele sunt întotdeauna identice pe toate sistemele de stocare
Contra:
- Costul ridicat al soluției (canale de comunicații rapide, fibră optică scumpă, transceiver cu undă lungă etc.)
- Restricții de distanță (în mai multe zeci de kilometri)
- Nu există protecție împotriva coruperii datelor logice (dacă datele sunt corupte (intenționat sau accidental) pe sistemul de stocare principal, acestea vor deveni automat și instantaneu corupte pe cel de rezervă, deoarece datele sunt întotdeauna identice (acesta este paradoxul)
Replicare asincronă – aceasta este și copierea datelor din sistemul de stocare principal în cel de rezervă, dar cu o anumită întârziere și fără a fi nevoie să confirmi scrierea pe cealaltă parte. Puteți lucra cu datele imediat după ce le-ați înregistrat în sistemul de stocare principal, iar pe sistemul de stocare de rezervă datele vor fi disponibile după ceva timp. Identitatea datelor în acest caz, desigur, nu este deloc asigurată. Datele din sistemul de stocare de rezervă sunt întotdeauna puțin „în trecut”.
Avantajele replicării asincrone:
- Soluție low cost (orice canale de comunicație, optica opțională)
- Fără restricții de distanță
- Pe sistemul de stocare de rezervă, datele nu se deteriorează dacă sunt deteriorate pe cel principal (cel puțin pentru o perioadă de timp); dacă datele devin corupte, puteți oricând opri replica pentru a preveni coruperea datelor pe sistemul de stocare de rezervă.
Contra:
- Datele din diferite centre de date nu sunt întotdeauna identice
Astfel, alegerea modului de replicare depinde de obiectivele afacerii. Dacă este esențial pentru dvs. ca centrul de date de rezervă să conțină exact aceleași date ca și centrul de date principal (adică, cerințele de afaceri pentru RPO = 0), atunci va trebui să scoateți banii și să suportați limitările unui sistem sincron. replica. Și dacă întârzierea în starea datelor este acceptabilă sau pur și simplu nu există bani, atunci cu siguranță trebuie să utilizați metoda asincronă.
Să evidențiem, de asemenea, separat un astfel de mod (mai precis, o topologie) ca un metrocluster. În modul metrocluster, se utilizează replicarea sincronă, dar, spre deosebire de o replică obișnuită, un metrocluster permite ambelor sisteme de stocare să funcționeze în modul activ. Acestea. nu aveți o separare între centrele de date active și cele de așteptare. Aplicațiile funcționează simultan cu două sisteme de stocare, care sunt situate fizic în centre de date diferite. Timpii de nefuncţionare în timpul accidentelor într-o astfel de topologie sunt foarte mici (RTO, de obicei minute). În acest articol nu vom lua în considerare implementarea noastră a metroclusterului, deoarece acesta este un subiect foarte amplu și încăpător, așa că îi vom dedica un articol separat, următor, în continuarea acestuia.
De asemenea, foarte des, când vorbim despre replicare folosind sisteme de stocare, mulți oameni au o întrebare rezonabilă: > „Multe aplicații au propriile lor instrumente de replicare, de ce să folosești replicarea pe sistemele de stocare? Este mai bine sau mai rău?
Nu există un răspuns clar aici, așa că iată argumentele PENTRU și CONTRA:
Argumente pentru replicarea stocării:
- Simplitatea soluției. Cu un singur instrument, vă puteți replica întregul set de date, indiferent de tipul de încărcare și de aplicație. Dacă utilizați o replică din aplicații, va trebui să configurați fiecare aplicație separat. Dacă există mai mult de 2 dintre ele, atunci aceasta este extrem de laborioasă și costisitoare (replicarea aplicației necesită de obicei o licență separată și nu gratuită pentru fiecare aplicație. Dar mai multe despre asta mai jos).
- Puteți replica orice - orice aplicație, orice date - și va fi întotdeauna consecvent. Multe (majoritatea) aplicațiilor nu au capabilități de replicare, iar replicile din sistemul de stocare sunt singura modalitate de a oferi protecție împotriva dezastrelor.
- Nu este nevoie să plătiți în plus pentru funcționalitatea de replicare a aplicației. De regulă, nu este ieftin, la fel ca licențele pentru o replică a unui sistem de stocare. Dar trebuie să plătiți o singură dată pentru o licență pentru replicarea stocării, iar o licență pentru replica aplicației trebuie achiziționată separat pentru fiecare aplicație. Dacă există o mulțime de astfel de aplicații, atunci costă un ban și costul licențelor pentru replicarea stocării devine o picătură în găleată.
Argumente CONTRA replicarea stocării:
- Replica prin aplicații are mai multă funcționalitate din punctul de vedere al aplicațiilor în sine, aplicația își cunoaște mai bine datele (evident), deci există mai multe opțiuni de lucru cu ele.
- Producătorii unor aplicații nu garantează consistența datelor lor dacă replicarea se face folosind instrumente terțe. *
* - teză controversată. De exemplu, un producător binecunoscut de SGBD a declarat oficial de foarte mult timp că SGBD-ul lor poate fi replicat numai în mod normal folosind mijloacele sale, iar restul replicării (inclusiv sistemele de stocare) este „nu adevărat”. Dar viața a arătat că nu este așa. Cel mai probabil (dar acest lucru nu este sigur) aceasta nu este pur și simplu cea mai sinceră încercare de a vinde mai multe licențe clienților.
Drept urmare, în majoritatea cazurilor, replicarea din sistemul de stocare este mai bună, deoarece Aceasta este o opțiune mai simplă și mai puțin costisitoare, dar există cazuri complexe când este necesară o funcționalitate specifică a aplicației și este necesar să se lucreze cu replicarea la nivel de aplicație.
Gata cu teoria, acum practică
Vom configura replica în laboratorul nostru. În condiții de laborator, am emulat două centre de date (de fapt, două rafturi adiacente care păreau să fie în clădiri diferite). Standul este format din două sisteme de stocare Engine N2, care sunt conectate între ele prin cabluri optice. Un server fizic care rulează Windows Server 2016 este conectat la ambele sisteme de stocare folosind Ethernet de 10 Gb. Standul este destul de simplu, dar asta nu schimbă esența.
Schematic arată astfel:
În mod logic, replicarea este organizată după cum urmează:
Acum să ne uităm la funcționalitatea de replicare pe care o avem acum.
Sunt acceptate două moduri: asincron și sincron. Este logic ca modul sincron este limitat de distanță și canal de comunicare. În special, modul sincron necesită utilizarea fibrei ca fizică și 10 Gigabit Ethernet (sau mai mare).
Distanța acceptată pentru replicarea sincronă este de 40 de kilometri, valoarea întârzierii canalului optic între centrele de date este de până la 2 milisecunde. În general, va funcționa cu întârzieri mari, dar apoi vor exista încetiniri puternice în timpul înregistrării (ceea ce este și logic), așa că dacă plănuiți o replicare sincronă între centrele de date, ar trebui să verificați calitatea opticii și întârzierile.
Cerințele pentru replicarea asincronă nu sunt atât de serioase. Mai exact, nu sunt deloc acolo. Orice conexiune Ethernet funcțională va funcționa.
În prezent, sistemul de stocare AERODISK ENGINE acceptă replicarea pentru dispozitive bloc (LUN) prin protocolul Ethernet (pe cupru sau optic). Pentru proiectele în care este necesară replicarea printr-o țesătură SAN prin Fibre Channel, în prezent adăugăm o soluție adecvată, dar nu este încă gata, deci în cazul nostru, doar Ethernet.
Replicarea poate funcționa între orice sisteme de stocare din seria ENGINE (N1, N2, N4), de la sisteme junior la cele mai vechi și invers.
Funcționalitatea ambelor moduri de replicare este complet identică. Mai jos sunt mai multe detalii despre ceea ce este disponibil:
- Replicare „one to one” sau „one to one”, adică versiunea clasică cu două centre de date, principal și backup
- Replicarea este „unu la mulți” sau „unu la mulți”, adică. un LUN poate fi replicat pe mai multe sisteme de stocare simultan
- Activați, dezactivați și, respectiv, „inversați” replicarea pentru a activa, dezactiva sau schimba direcția de replicare
- Replicarea este disponibilă atât pentru pool-urile RDG (Raid Distributed Group) cât și pentru DDP (Dynamic Disk Pool). Cu toate acestea, LUN-urile unui pool RDG pot fi replicate doar la un alt RDG. La fel și cu DDP.
Există multe alte caracteristici mici, dar nu are niciun rost să le enumeram; le vom menționa pe măsură ce le vom configura.
Configurarea replicării
Procesul de configurare este destul de simplu și constă din trei etape.
- Configurare rețea
- Configurare stocare
- Stabilirea de reguli (conexiuni) și cartografiere
Un punct important în configurarea replicării este că primele două etape ar trebui repetate pe sistemul de stocare la distanță, a treia etapă - doar pe cea principală.
Configurarea resurselor de rețea
Primul pas este să configurați porturile de rețea prin care va fi transmis traficul de replicare. Pentru a face acest lucru, trebuie să activați porturile și să le setați adresele IP în secțiunea Adaptoare front-end.
După aceasta, trebuie să creăm un pool (în cazul nostru RDG) și un IP virtual pentru replicare (VIP). VIP este o adresă IP plutitoare care este legată de două adrese „fizice” ale controlerelor de stocare (porturile pe care tocmai le-am configurat). Aceasta va fi interfața principală de replicare. De asemenea, puteți opera nu cu un VIP, ci cu un VLAN, dacă trebuie să lucrați cu trafic etichetat.
Procesul de creare a unui VIP pentru o replică nu este mult diferit de crearea unui VIP pentru I/O (NFS, SMB, iSCSI). În acest caz, creăm un VIP obișnuit (fără VLAN), dar asigurați-vă că indicați că este pentru replicare (fără acest pointer nu vom putea adăuga VIP la regulă în pasul următor).
VIP-ul trebuie să fie în aceeași subrețea cu porturile IP între care plutește.
Repetăm aceste setări pe un sistem de stocare la distanță, cu un IP diferit, desigur.
VIP-urile din diferite sisteme de stocare pot fi în diferite subrețele, principalul lucru este că există rutare între ele. În cazul nostru, acest exemplu este afișat exact (192.168.3.XX și 192.168.2.XX)
Aceasta completează pregătirea părții de rețea.
Configurarea stocării
Configurarea stocării pentru o replică diferă de cea obișnuită doar prin faptul că maparea o facem printr-un meniu special „Replicare Mapping”. În rest, totul este la fel ca în configurația normală. Acum, în ordine.
În pool-ul R02 creat anterior, trebuie să creați un LUN. Să-l creăm și să-l numim LUN1.
De asemenea, trebuie să creăm același LUN pe un sistem de stocare la distanță de dimensiuni identice. Noi creăm. Pentru a evita confuzia, să apelăm la distanță LUN LUN1R
Dacă ar fi nevoie să luăm un LUN care există deja, atunci în timp ce configuram replica, ar trebui să demontăm acest LUN productiv de pe gazdă și pur și simplu să creăm un LUN gol de dimensiune identică pe sistemul de stocare la distanță.
Configurarea stocării este completă, să trecem la crearea unei reguli de replicare.
Configurarea regulilor de replicare sau a legăturilor de replicare
După crearea LUN-urilor pe sistemul de stocare, care va fi cel primar în acest moment, configuram regula de replicare LUN1 pe sistemul de stocare 1 la LUN1R pe sistemul de stocare 2.
Setarea se face în meniul „Replicare la distanță”.
Să creăm o regulă. Pentru a face acest lucru, trebuie să specificați destinatarul replicii. Acolo setăm și numele conexiunii și tipul de replicare (sincronă sau asincronă).
În câmpul „sisteme la distanță” adăugăm sistemul nostru de stocare2. Pentru a adăuga, trebuie să utilizați sistemele de stocare IP de gestionare (MGR) și numele LUN-ului la distanță în care vom efectua replicarea (în cazul nostru, LUN1R). IP-urile de control sunt necesare doar în etapa de adăugare a unei conexiuni; traficul de replicare nu va fi transmis prin acestea; VIP-ul configurat anterior va fi folosit pentru aceasta.
Deja în această etapă putem adăuga mai mult de un sistem la distanță pentru topologia „unu la mulți”: faceți clic pe butonul „adăugați nod”, ca în figura de mai jos.
În cazul nostru, există un singur sistem la distanță, așa că ne limităm la asta.
Regula este gata. Vă rugăm să rețineți că este adăugat automat la toți participanții la replicare (în cazul nostru sunt doi). Puteți crea oricâte astfel de reguli doriți, pentru orice număr de LUN și în orice direcție. De exemplu, pentru a echilibra sarcina, putem replica o parte din LUN-urile de la sistemul de stocare 1 la sistemul de stocare 2, iar cealaltă parte, dimpotrivă, de la sistemul de stocare 2 la sistemul de stocare 1.
Sistem de depozitare 1. Imediat după creare, a început sincronizarea.
Sistem de stocare 2. Vedem aceeași regulă, dar sincronizarea s-a încheiat deja.
LUN1 pe sistemul de stocare 1 este în rolul Primar, adică este activ. LUN1R pe sistemul de stocare 2 este în rol de Secundar, adică este în standby în cazul în care sistemul de stocare 1 eșuează.
Acum ne putem conecta LUN-ul la gazdă.
Ne vom conecta prin iSCSI, deși se poate face și prin FC. Configurarea mapării prin iSCSI LUN într-o replică nu este practic diferită de scenariul obișnuit, așa că nu vom lua în considerare acest lucru în detaliu aici. Dacă ceva, acest proces este descris în articolul „".
Singura diferență este că creăm maparea în meniul „Mapping Replication”.
Am configurat maparea și am dat LUN-ul gazdei. Gazda a văzut LUN-ul.
Îl formatăm într-un sistem de fișiere local.
Gata, configurarea este completă. Testele vor veni în continuare.
Testarea
Vom testa trei scenarii principale.
- Schimbarea regulată a rolului Secundar > Primar. Schimbarea regulată a rolurilor este necesară în cazul în care, de exemplu, trebuie să efectuăm unele operațiuni preventive în centrul de date principal și în acest timp, pentru ca datele să fie disponibile, transferăm încărcarea în centrul de date de rezervă.
- Schimbarea de urgență a rolului Secundar > Primar (defecțiune a centrului de date). Acesta este scenariul principal pentru care există replicarea, care poate ajuta la supraviețuirea unei eșecuri complete a centrului de date fără a opri compania pentru o perioadă îndelungată.
- Defalcarea canalelor de comunicare între centrele de date. Verificarea comportamentului corect a două sisteme de stocare în condițiile în care, dintr-un motiv oarecare, canalul de comunicare între centrele de date este indisponibil (de exemplu, un excavator a săpat în locul nepotrivit și a spart optica întunecată).
În primul rând, vom începe să scriem date în LUN-ul nostru (scrierea fișierelor cu date aleatorii). Vedem imediat că canalul de comunicare între sistemele de stocare este utilizat. Acest lucru este ușor de înțeles dacă deschideți monitorizarea încărcării porturilor care sunt responsabile pentru replicare.
Ambele sisteme de stocare au acum date „utile”, putem începe testul.
Pentru orice eventualitate, să ne uităm la sumele hash ale unuia dintre fișiere și să le scriem.
Schimbarea regulată a rolului
Operația de schimbare a rolurilor (schimbarea direcției de replicare) se poate face cu orice sistem de stocare, dar va trebui totuși să mergeți la ambele, deoarece va trebui să dezactivați maparea pe Primar și să o activați pe Secundar (care va deveni Primar). ).
Poate că acum apare o întrebare rezonabilă: de ce să nu automatizăm acest lucru? Răspunsul este: este simplu, replicarea este un mijloc simplu de rezistență la dezastre, bazat exclusiv pe operațiuni manuale. Pentru a automatiza aceste operațiuni, există un mod metrocluster; este complet automatizat, dar configurația sa este mult mai complicată. Despre crearea unui metrocluster vom scrie în articolul următor.
Pe sistemul de stocare principal, dezactivăm maparea pentru a ne asigura că înregistrarea se oprește.
Apoi, pe unul dintre sistemele de stocare (nu contează, pe principal sau de rezervă) în meniul „Replicare la distanță”, selectați conexiunea noastră REPL1 și faceți clic pe „Schimbați rolul”.
După câteva secunde, LUN1R (sistem de stocare de rezervă) devine Primar.
Cartografiam LUN1R cu sistem de stocare2.
După aceasta, unitatea noastră E: este atașată automat la gazdă, doar că de această dată „a sosit” de la LUN1R.
Pentru orice eventualitate, comparăm sumele hash.
Identic. Test trecut.
Failover. Eșecul centrului de date
În prezent, sistemul de stocare principal după comutarea regulată este sistemul de stocare 2 și, respectiv, LUN1R. Pentru a emula un accident, vom opri alimentarea ambelor controlere de stocare2.
Nu mai există acces la el.
Să vedem ce se întâmplă pe sistemul de stocare 1 (cel de rezervă în acest moment).
Vedem că LUN primar (LUN1R) este indisponibil. Un mesaj de eroare a apărut în jurnale, în panoul de informații și, de asemenea, în regula de replicare în sine. În consecință, datele de la gazdă sunt momentan indisponibile.
Schimbați rolul LUN1 în Primar.
Fac cartografiere către gazdă.
Asigurați-vă că unitatea E apare pe gazdă.
Verificăm hașul.
Totul e bine. Sistemul de stocare a supraviețuit cu succes căderii centrului de date, care era activ. Timpul aproximativ pe care l-am petrecut conectând replicarea „inversare” și conectând LUN de la centrul de date de rezervă a fost de aproximativ 3 minute. Este clar că în producția reală totul este mult mai complicat și, pe lângă acțiunile cu sistemele de stocare, trebuie să efectuați mult mai multe operațiuni în rețea, pe gazde, în aplicații. Și în viață această perioadă de timp va fi mult mai lungă.
Aici aș vrea să scriu că totul, testul a fost finalizat cu succes, dar să nu ne grăbim. Principalul sistem de stocare este „minciuna”, știm că atunci când „a căzut”, a fost în rolul Primar. Ce se întâmplă dacă se aprinde brusc? Vor exista două roluri principale, ceea ce înseamnă corupția datelor? Să verificăm acum.
Să pornim brusc sistemul de stocare de bază.
Se incarca cateva minute si apoi revine in service dupa o scurta sincronizare, dar in rol de Secundar.
Toate ok. Creierul divizat nu s-a întâmplat. Ne-am gândit la asta și întotdeauna după o cădere sistemul de stocare se ridică la rolul de Secundar, indiferent de ce rol a avut în „în timpul vieții”. Acum putem spune cu siguranță că testul de eșec al centrului de date a avut succes.
Eșecul canalelor de comunicare între centrele de date
Sarcina principală a acestui test este să ne asigurăm că sistemul de stocare nu începe să se comporte ciudat dacă pierde temporar canalele de comunicare între două sisteme de stocare și apoi apare din nou.
Asa de. Deconectăm firele dintre sistemele de depozitare (să ne imaginăm că au fost săpate de un excavator).
Pe Primar vedem că nu există nicio legătură cu Secundar.
Pe Secundar vedem că nu există nicio legătură cu Primar.
Totul funcționează bine și continuăm să scriem date în sistemul de stocare principal, adică se garantează că sunt diferite de cel de rezervă, adică s-au „separat”.
În câteva minute „reparăm” canalul de comunicare. De îndată ce sistemele de stocare se văd, sincronizarea datelor este activată automat. Nu este necesar nimic de la administrator aici.
După ceva timp, sincronizarea este finalizată.
Conexiunea a fost restabilită, pierderea canalelor de comunicare nu a provocat situații de urgență, iar după pornire, sincronizarea a avut loc automat.
Constatări
Am analizat teoria - ce este necesar și de ce, unde sunt avantajele și unde sunt contra. Apoi am configurat replicarea sincronă între două sisteme de stocare.
În continuare, au fost efectuate teste de bază pentru comutarea normală, eșecul centrului de date și eșecul canalului de comunicație. În toate cazurile, sistemul de stocare a funcționat bine. Nu există pierderi de date și operațiunile administrative sunt reduse la minimum pentru un scenariu manual.
Data viitoare vom complica situația și vom arăta cum funcționează toată această logică într-un metrocluster automat în mod activ-activ, adică atunci când ambele sisteme de stocare sunt primare, iar comportamentul în cazul defecțiunilor sistemului de stocare este complet automatizat.
Vă rugăm să scrieți comentarii, vom fi bucuroși să primim critici temeinice și sfaturi practice.
Pana data viitoare.
Sursa: www.habr.com