Hei Habr!
După sărbătorile de Anul Nou, am relansat un cloud rezistent la dezastre bazat pe două site-uri. Astăzi vă vom spune cum funcționează și vă vom arăta ce se întâmplă cu mașinile virtuale client atunci când elementele individuale ale clusterului eșuează și întregul site se blochează (spoiler – totul este în regulă cu ele).
Sistem de stocare în cloud rezistent la dezastre pe site-ul OST.
Ce este înăuntru
Sub capotă, clusterul are servere Cisco UCS cu un hypervisor VMware ESXi, două sisteme de stocare INFINIDAT InfiniBox F2240, echipamente de rețea Cisco Nexus, precum și switch-uri Brocade SAN. Clusterul este împărțit în două site-uri - OST și NORD, adică fiecare centru de date are un set identic de echipamente. De fapt, acesta este ceea ce îl face rezistent la dezastre.
Într-un singur site, elementele principale sunt, de asemenea, duplicate (gazde, switch-uri SAN, rețea).
Cele două site-uri sunt conectate prin rute dedicate de fibră optică, de asemenea rezervate.
Câteva cuvinte despre sistemele de stocare. Am construit prima versiune a unui cloud rezistent la dezastre pe NetApp. Aici am ales INFINIDAT și iată de ce:
- Opțiune de replicare activ-activ. Permite mașinii virtuale să rămână operaționale chiar dacă unul dintre sistemele de stocare eșuează complet. Vă voi spune mai multe despre replicare mai târziu.
- Trei controlere de disc pentru a crește toleranța la erori de sistem. De obicei sunt două.
- Soluție gata. Am primit un rack pre-asamblat care trebuie doar conectat la rețea și configurat.
- Suport tehnic atent. Inginerii INFINIDAT analizează în mod constant jurnalele și evenimentele sistemului de stocare, instalează versiuni noi de firmware și ajută la configurare.
Iată câteva fotografii de la despachetare:
Cum funcționează
Norul este deja tolerant la greșeli în sine. Protejează clientul de erori unice hardware și software. Rezistent la dezastre va ajuta la protejarea împotriva defecțiunilor masive într-un singur site: de exemplu, defecțiunea unui sistem de stocare (sau a unui cluster SDS, ceea ce se întâmplă destul de des 🙂), erori masive într-o rețea de stocare etc. Ei bine, și cel mai important: un astfel de nor salvează atunci când un întreg site devine inaccesibil din cauza unui incendiu, pană de curent, preluare a unui raider sau aterizare extraterestră.
În toate aceste cazuri, mașinile virtuale client continuă să funcționeze și iată de ce.
Designul clusterului este conceput astfel încât orice gazdă ESXi cu mașini virtuale client să poată accesa oricare dintre cele două sisteme de stocare. Dacă sistemul de stocare de pe site-ul OST eșuează, mașinile virtuale vor continua să funcționeze: gazdele pe care rulează vor accesa sistemul de stocare de pe NORD pentru date.
Așa arată diagrama de conexiune într-un cluster.
Acest lucru este posibil datorită faptului că o legătură Inter-Switch este configurată între fabricile SAN ale celor două site-uri: comutatorul Fabric A OST SAN este conectat la comutatorul Fabric A NORD SAN și, în mod similar, comutatorul Fabric B SAN.
Ei bine, pentru ca toate aceste complexități ale fabricilor SAN să aibă sens, replicarea Active-Active este configurată între cele două sisteme de stocare: informațiile sunt scrise aproape simultan în sistemele de stocare locale și la distanță, RPO = 0. Se pare că datele originale sunt stocate pe un sistem de stocare, iar replica sa este stocată pe celălalt. Datele sunt replicate la nivelul volumelor de stocare, iar datele VM (discurile sale, fișierul de configurare, fișierul swap etc.) sunt stocate pe acestea.
Gazda ESXi vede volumul principal și replica sa ca un singur dispozitiv de disc (Dispozitiv de stocare). Există 24 de căi de la gazda ESXi la fiecare dispozitiv de disc:
12 căi îl conectează la sistemul de stocare local (căi optime), iar restul de 12 la sistemul de stocare la distanță (căi neoptimale). Într-o situație normală, ESXi accesează datele din sistemul de stocare local folosind căi „optime”. Când acest sistem de stocare eșuează, ESXi pierde căile optime și trece la cele „neoptimale”. Așa arată pe diagramă.
Schema unui cluster rezistent la dezastre.
Toate rețelele client sunt conectate la ambele site-uri printr-o rețea comună. Fiecare site rulează un Provider Edge (PE), pe care rețelele clientului sunt terminate. PE sunt unite într-un cluster comun. Dacă un PE nu reușește la un site, tot traficul este redirecționat către al doilea site. Datorită acestui fapt, mașinile virtuale de pe site rămase fără PE rămân accesibile prin rețea clientului.
Să vedem acum ce se va întâmpla cu mașinile virtuale client în timpul diferitelor defecțiuni. Să începem cu cele mai ușoare opțiuni și să terminăm cu cea mai gravă - eșecul întregului site. În exemple, platforma principală va fi OST, iar platforma de rezervă, cu replici de date, va fi NORD.
Ce se întâmplă cu mașina virtuală client dacă...
Legătura de replicare eșuează. Replicarea între sistemele de stocare ale celor două site-uri se oprește.
ESXi va funcționa numai cu dispozitive de disc locale (prin căi optime).
Mașinile virtuale continuă să funcționeze.
ISL (Inter-Switch Link) se rupe. Un eveniment improbabil. Cu excepția cazului în care un excavator nebun săpa mai multe rute optice deodată, care rulează pe rute independente și sunt aduse la șantier prin diferite intrări. Dar oricum. În acest caz, gazdele ESXi pierd jumătate din căi și pot accesa doar sistemele lor locale de stocare. Replicile sunt colectate, dar gazdele nu le vor putea accesa.
Mașinile virtuale funcționează normal.
Comutatorul SAN eșuează pe unul dintre site-uri. Gazdele ESXi pierd unele dintre căile către sistemul de stocare. În acest caz, gazdele de pe site-ul în care comutatorul a eșuat vor funcționa numai printr-unul dintre HBA-urile lor.
Mașinile virtuale continuă să funcționeze normal.
Toate comutatoarele SAN de pe unul dintre site-uri eșuează. Să presupunem că un astfel de dezastru s-a întâmplat pe site-ul OST. În acest caz, gazdele ESXi de pe acest site vor pierde toate căile către dispozitivele lor de disc. Intră în joc mecanismul standard VMware vSphere HA: va reporni toate mașinile virtuale ale site-ului OST în NORD în maximum 140 de secunde.
Mașinile virtuale care rulează pe gazdele site-ului NORD funcționează normal.
Gazda ESXi eșuează pe un site. Aici mecanismul vSphere HA funcționează din nou: mașinile virtuale de la gazda eșuată sunt repornite pe alte gazde - pe același site sau la distanță. Timpul de repornire a mașinii virtuale este de până la 1 minut.
Dacă toate gazdele ESXi de pe site-ul OST eșuează, nu există opțiuni: VM-urile sunt repornite pe alta. Ora de repornire este aceeași.
Sistemul de stocare eșuează la un loc. Să presupunem că sistemul de stocare eșuează la site-ul OST. Apoi, gazdele ESXi ale site-ului OST trec la lucrul cu replici de stocare în NORD. După ce sistemul de stocare eșuat revine la funcționare, va avea loc replicarea forțată și gazdele ESXi OST vor începe din nou să acceseze sistemul de stocare local.
Mașinile virtuale au funcționat normal în tot acest timp.
Unul dintre site-uri eșuează. În acest caz, toate mașinile virtuale vor fi repornite pe site-ul de rezervă prin mecanismul vSphere HA. Timpul de repornire a VM este de 140 de secunde. În acest caz, toate setările de rețea ale mașinii virtuale vor fi salvate și acestea rămân accesibile clientului prin rețea.
Pentru a vă asigura că repornirea mașinilor de la site-ul de rezervă se desfășoară fără probleme, fiecare site este plin doar pe jumătate. A doua jumătate este o rezervă în cazul în care toate mașinile virtuale se mută de pe al doilea site, deteriorat.
Un nor rezistent la dezastre bazat pe două centre de date protejează împotriva unor astfel de defecțiuni.
Această plăcere nu este ieftină, deoarece, pe lângă resursele principale, este nevoie de o rezervă pe al doilea site. Prin urmare, serviciile critice pentru afaceri sunt plasate într-un astfel de cloud, al cărui timp de nefuncționare pe termen lung provoacă pierderi financiare și de reputație mari sau dacă sistemul informațional este supus cerințelor de rezistență la dezastre din partea autorităților de reglementare sau a reglementărilor interne ale companiei.
Surse:
Sursa: www.habr.com