Acesta este un mit destul de comun în domeniul hardware-ului serverului. În practică, soluțiile hiperconvergente (când totul este într-una) sunt necesare pentru multe lucruri. Din punct de vedere istoric, primele arhitecturi au fost dezvoltate de Amazon și Google pentru serviciile lor. Apoi ideea a fost de a face o fermă de calcul din noduri identice, fiecare dintre ele având propriile discuri. Toate acestea au fost unite de un software de formare a sistemului (hypervisor) și au fost împărțite în mașini virtuale. Scopul principal este un efort minim pentru deservirea unui nod și un minim de probleme la scalare: doar cumpărați încă o mie sau două de aceleași servere și conectați-le în apropiere. În practică, acestea sunt cazuri izolate și mult mai des vorbim despre un număr mai mic de noduri și o arhitectură puțin diferită.
Dar plusul rămâne același - ușurință incredibilă de scalare și gestionare. Dezavantajul este că diferitele sarcini consumă resurse în mod diferit, iar în unele locuri vor exista o mulțime de discuri locale, în altele va fi puțin RAM și așa mai departe, adică pentru diferite tipuri de sarcini, utilizarea resurselor va scădea.
Se pare că plătiți cu 10–15% mai mult pentru ușurință de configurare. Acesta este ceea ce a stârnit mitul din titlu. Am petrecut mult timp căutând unde ar fi aplicată în mod optim tehnologia și am găsit-o. Cert este că Cisco nu avea propriile sisteme de stocare, dar își dorea o piață completă de servere. Și au creat Cisco Hyperflex - o soluție cu stocare locală pe noduri.
Și aceasta sa dovedit brusc a fi o soluție foarte bună pentru centrele de date de rezervă (Disaster Recovery). Vă spun de ce și cum acum. Și vă voi arăta testele cluster.
Acolo unde este nevoie
Hiperconvergența este:
- Transferarea discurilor la nodurile de calcul.
- Integrarea completă a subsistemului de stocare cu subsistemul de virtualizare.
- Transfer/integrare cu subsistemul de rețea.
Această combinație vă permite să implementați multe caracteristici ale sistemului de stocare la nivel de virtualizare și toate dintr-o singură fereastră de control.
În compania noastră, proiectele de proiectare a centrelor de date redundante sunt la mare căutare, iar o soluție hiperconvergentă este adesea aleasă datorită unei mulțimi de opțiuni de replicare (până la un metrocluster) din cutie.
În cazul centrelor de date de rezervă, de obicei vorbim despre o instalație la distanță pe un site din cealaltă parte a orașului sau într-un alt oraș cu totul. Vă permite să restaurați sistemele critice în cazul unei defecțiuni parțiale sau complete a centrului de date principal. Datele de vânzări sunt replicate în mod constant acolo, iar această replicare poate fi la nivel de aplicație sau la nivel de dispozitiv bloc (stocare).
Prin urmare, acum voi vorbi despre proiectarea și testele sistemului și apoi despre câteva scenarii de aplicații din viața reală cu date de economisire.
teste
Instanța noastră este formată din patru servere, fiecare dintre ele având 10 unități SSD de 960 GB. Există un disc dedicat pentru stocarea în cache a operațiunilor de scriere și stocarea mașinii virtuale de serviciu. Soluția în sine este a patra versiune. Prima este sincer brută (judecând după recenzii), a doua este umedă, a treia este deja destul de stabilă, iar aceasta poate fi numită o lansare după încheierea testării beta pentru publicul larg. În timpul testării nu am văzut probleme, totul funcționează ca un ceas.
Modificări în v4Au fost remediate o grămadă de erori.
Inițial, platforma putea funcționa doar cu hypervisorul VMware ESXi și suporta un număr mic de noduri. De asemenea, procesul de implementare nu s-a încheiat întotdeauna cu succes, unii pași au trebuit reporniți, au existat probleme cu actualizarea de la versiuni mai vechi, datele din GUI nu au fost întotdeauna afișate corect (deși încă nu sunt mulțumit de afișarea graficelor de performanță ), uneori au apărut probleme la interfața cu virtualizarea .
Acum toate problemele din copilărie au fost rezolvate, HyperFlex poate gestiona atât ESXi, cât și Hyper-V, plus că este posibil să:
- Crearea unui cluster întins.
- Crearea unui cluster pentru birouri fără a utiliza Fabric Interconnect, de la două până la patru noduri (cumpărăm doar servere).
- Abilitatea de a lucra cu sisteme de stocare externe.
- Suport pentru containere și Kubernetes.
- Crearea zonelor de disponibilitate.
- Integrare cu VMware SRM dacă funcționalitatea încorporată nu este satisfăcătoare.
Arhitectura nu este mult diferită de soluțiile principalelor săi concurenți; aceștia nu au creat o bicicletă. Totul rulează pe platforma de virtualizare VMware sau Hyper-V. Hardware-ul este găzduit pe servere Cisco UCS proprietare. Sunt cei care urăsc platforma pentru complexitatea relativă a setării inițiale, o mulțime de butoane, un sistem non-trivial de șabloane și dependențe, dar sunt și cei care au învățat Zen, sunt inspirați de idee și nu mai doresc pentru a lucra cu alte servere.
Vom lua în considerare soluția pentru VMware, deoarece soluția a fost creată inițial pentru acesta și are mai multe funcționalități; Hyper-V a fost adăugat pe parcurs pentru a ține pasul cu concurenții și a îndeplini așteptările pieței.
Există un grup de servere pline de discuri. Există discuri pentru stocarea datelor (SSD sau HDD - după gust și nevoi), există un disc SSD pentru cache. Când scrieți date în depozitul de date, datele sunt salvate pe stratul de cache (disc SSD dedicat și RAM al VM-ului de serviciu). În paralel, un bloc de date este trimis către nodurile din cluster (numărul de noduri depinde de factorul de replicare a clusterului). După confirmarea de la toate nodurile despre înregistrarea reușită, confirmarea înregistrării este trimisă la hypervisor și apoi la VM. Datele înregistrate sunt deduplicate, comprimate și scrise pe discuri de stocare în fundal. În același timp, un bloc mare este întotdeauna scris pe discurile de stocare și secvențial, ceea ce reduce sarcina pe discurile de stocare.
Deduplicarea și compresia sunt întotdeauna activate și nu pot fi dezactivate. Datele sunt citite direct de pe discurile de stocare sau din memoria cache RAM. Dacă se folosește o configurație hibridă, citirile sunt, de asemenea, stocate în cache pe SSD.
Datele nu sunt legate de locația curentă a mașinii virtuale și sunt distribuite uniform între noduri. Această abordare vă permite să încărcați toate discurile și interfețele de rețea în mod egal. Există un dezavantaj evident: nu putem reduce cât mai mult posibil latența de citire, deoarece nu există nicio garanție a disponibilității datelor la nivel local. Dar cred că acesta este un sacrificiu minor în comparație cu beneficiile primite. Mai mult, întârzierile rețelei au atins astfel de valori încât practic nu afectează rezultatul general.
Un controler special pentru platforma de date Cisco HyperFlex VM, care este creat pe fiecare nod de stocare, este responsabil pentru întreaga logică de funcționare a subsistemului de disc. În configurația noastră de serviciu VM, au fost alocate opt vCPU și 72 GB de RAM, ceea ce nu este atât de puțin. Permiteți-mi să vă reamintesc că gazda în sine are 28 de nuclee fizice și 512 GB de RAM.
VM-ul de serviciu are acces direct la discurile fizice prin redirecționarea controlerului SAS către VM. Comunicarea cu hypervisorul are loc printr-un modul special IOVisor, care interceptează operațiunile I/O și folosind un agent care vă permite să trimiteți comenzi către API-ul hypervisor. Agentul este responsabil pentru lucrul cu instantaneele și clonele HyperFlex.
Resursele de disc sunt montate în hypervisor ca partajări NFS sau SMB (în funcție de tipul de hypervisor, ghiciți care este unde). Iar sub capotă, acesta este un sistem de fișiere distribuit care vă permite să adăugați caracteristici ale sistemelor de stocare cu drepturi depline pentru adulți: alocare de volum subțire, compresie și deduplicare, instantanee folosind tehnologia Redirect-on-Write, replicare sincronă/asincronă.
Serviciul VM oferă acces la interfața de gestionare WEB a subsistemului HyperFlex. Există integrare cu vCenter și majoritatea sarcinilor de zi cu zi pot fi efectuate din acesta, dar depozitele de date, de exemplu, sunt mai convenabile pentru a tăia dintr-o cameră web separată dacă ați trecut deja la o interfață rapidă HTML5 sau utilizați un client Flash complet. cu integrare deplină. În camera web de serviciu puteți vizualiza performanța și starea detaliată a sistemului.
Există un alt tip de nod într-un cluster - noduri de calcul. Acestea pot fi servere rack sau blade fără discuri încorporate. Aceste servere pot rula VM ale căror date sunt stocate pe servere cu discuri. Din punct de vedere al accesului la date, nu există nicio diferență între tipurile de noduri, deoarece arhitectura presupune abstracția de la locația fizică a datelor. Raportul maxim dintre nodurile de calcul și nodurile de stocare este de 2:1.
Utilizarea nodurilor de calcul crește flexibilitatea la scalarea resurselor clusterului: nu trebuie să cumpărăm noduri suplimentare cu discuri dacă avem nevoie doar de CPU/RAM. În plus, putem adăuga o cușcă blade și putem economisi pe amplasarea în rack a serverelor.
Ca rezultat, avem o platformă hiperconvergentă cu următoarele caracteristici:
- Până la 64 de noduri într-un cluster (până la 32 de noduri de stocare).
- Numărul minim de noduri dintr-un cluster este de trei (două pentru un cluster Edge).
- Mecanism de redundanță a datelor: oglindire cu factorul de replicare 2 și 3.
- Cluster de metrou.
- Replicare asincronă a VM către un alt cluster HyperFlex.
- Orchestrarea comutării VM-urilor la un centru de date la distanță.
- Instantanee native folosind tehnologia Redirect-on-Write.
- Până la 1 PB de spațiu utilizabil la factorul de replicare 3 și fără deduplicare. Nu luăm în considerare factorul de replicare 2, deoarece aceasta nu este o opțiune pentru vânzări serioase.
Un alt avantaj uriaș este ușurința de gestionare și implementare. Toate complexitățile instalării serverelor UCS sunt îngrijite de un VM specializat pregătit de inginerii Cisco.
Configurația bancului de testare:
- 2 x Cisco UCS Fabric Interconnect 6248UP ca cluster de management și componente de rețea (48 de porturi care funcționează în modul Ethernet 10G/FC 16G).
- Patru servere Cisco UCS HXAF240 M4.
Caracteristicile serverului:
Procesor
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Reţea
UCSC-MLOM-CSC-02 (VIC 1227). 2 porturi Ethernet 10G
HBA de stocare
Controller Cisco 12G Modular SAS Pass through
Discuri de stocare
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Mai multe opțiuni de configurareÎn plus față de hardware-ul selectat, sunt disponibile în prezent următoarele opțiuni:
- HXAF240c M5.
- Unul sau două procesoare, de la Intel Silver 4110 la Intel Platinum I8260Y. A doua generație disponibilă.
- 24 sloturi de memorie, benzi de la 16 GB RDIMM 2600 la 128 GB LRDIMM 2933.
- De la 6 la 23 de discuri de date, un disc de cache, un disc de sistem și un disc de pornire.
Unități de capacitate
- HX-SD960G61X-EV 960 GB 2.5 inchi Enterprise Value 6G SATA SSD (1X anduranță) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 inchi Enterprise Value 6G SATA SSD (1X anduranță) SAS 3.8 TB.
- Memorarea în cache a unităților
- HX-NVMEXPB-I375 Unitate Intel Optane de 375 inchi de 2.5 GB, performanță și rezistență extreme.
- HX-NVMEHW-H1600* 1.6TB 2.5 inchi Ent. Perf. SSD NVMe (rezistență 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inchi Ent. Perf. SSD SAS 12G (rezistență 10X) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inchi Ent. Perf. 12G SAS SED SSD (10X anduranță) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 inchi SSD SAS 12G de performanță Enterprise (rezistență 3X).
Unități de sistem/jurnal
- HX-SD240GM1X-EV 240 GB SSD Enterprise Value 2.5G SATA de 6 inchi (Necesită upgrade).
Unități de pornire
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Conectați-vă la rețea prin porturi Ethernet 40G, 25G sau 10G.
FI poate fi HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Testul în sine
Pentru a testa subsistemul disc, am folosit HCIBench 2.2.1. Acesta este un utilitar gratuit care vă permite să automatizați crearea unei încărcări de pe mai multe mașini virtuale. Sarcina în sine este generată de fio-ul obișnuit.
Clusterul nostru este format din patru noduri, factor de replicare 3, toate discurile sunt Flash.
Pentru testare, am creat patru depozite de date și opt mașini virtuale. Pentru testele de scriere, se presupune că discul de cache nu este plin.
Rezultatele testului sunt după cum urmează:
100% citit 100% aleatoriu
0% citit 100% aleatoriu
Adâncimea blocului/cozii
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16 K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32 K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64 K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Bold indică valori după care nu există o creștere a productivității, uneori chiar și degradarea este vizibilă. Acest lucru se datorează faptului că suntem limitați de performanța rețelei/controlerelor/discurilor.
- Citire secvenţială 4432 MB/s.
- Scriere secvenţială 804 MB/s.
- Dacă un controler eșuează (defecțiunea unei mașini virtuale sau a unei gazde), scăderea performanței este dublă.
- Dacă discul de stocare eșuează, reducerea este de 1/3. Reconstrucția discului necesită 5% din resursele fiecărui controler.
Pe un bloc mic, suntem limitați de performanța controlerului (mașină virtuală), CPU-ul acestuia este încărcat la 100%, iar când blocul crește, suntem limitați de lățimea de bandă a portului. 10 Gbps nu este suficient pentru a debloca potențialul sistemului AllFlash. Din păcate, parametrii standului demo furnizat nu ne permit să testăm funcționarea la 40 Gbit/s.
În impresia mea din teste și studierea arhitecturii, datorită algoritmului care plasează datele între toate gazdele, obținem performanțe scalabile, predictibile, dar aceasta este și o limitare la citire, deoarece ar fi posibil să stoarcem mai mult de pe discurile locale, aici se poate salva o rețea mai productivă, de exemplu, este disponibil FI la 40 Gbit/s.
De asemenea, un singur disc pentru stocarea în cache și deduplicare poate fi o limitare; de fapt, în acest banc de testare putem scrie pe patru discuri SSD. Ar fi grozav să puteți crește numărul de unități de cache și să vedeți diferența.
Utilizare reală
Pentru a organiza un centru de date de rezervă, puteți utiliza două abordări (nu luăm în considerare plasarea unei copii de rezervă pe un site la distanță):
- Activ pasiv. Toate aplicațiile sunt găzduite în centrul de date principal. Replicarea este sincronă sau asincronă. Dacă centrul de date principal eșuează, trebuie să activăm cel de rezervă. Acest lucru se poate face manual/scripturi/aplicații de orchestrare. Aici vom obține un RPO proporțional cu frecvența de replicare, iar RTO depinde de reacția și abilitățile administratorului și de calitatea dezvoltării/depanării planului de comutare.
- Activ-Activ. În acest caz, există doar replicare sincronă; disponibilitatea centrelor de date este determinată de un cvorum/arbitru situat strict pe al treilea site. RPO = 0, iar RTO poate ajunge la 0 (dacă aplicația permite) sau egal cu timpul de failover al unui nod dintr-un cluster de virtualizare. La nivel de virtualizare, este creat un cluster extins (Metro) care necesită stocare Active-Active.
De obicei vedem că clienții au implementat deja o arhitectură cu un sistem clasic de stocare în centrul de date principal, așa că proiectăm alta pentru replicare. După cum am menționat, Cisco HyperFlex oferă replicare asincronă și crearea de clustere de virtualizare extinsă. În același timp, nu avem nevoie de un sistem de stocare dedicat de nivel Midrange și mai mare cu funcții de replicare costisitoare și acces la date Active-Active pe două sisteme de stocare.
Scenariul 1: Avem un centru de date primar și de rezervă, o platformă de virtualizare pe VMware vSphere. Toate sistemele productive sunt amplasate în centrul de date principal, iar replicarea mașinilor virtuale se realizează la nivel de hypervisor, acest lucru va evita menținerea mașinilor virtuale pornite în centrul de date de rezervă. Replicăm bazele de date și aplicațiile speciale folosind instrumente încorporate și menținem VM-urile pornite. Dacă centrul de date principal eșuează, lansăm sisteme în centrul de date de rezervă. Credem că avem aproximativ 100 de mașini virtuale. În timp ce centrul de date primar este operațional, centrul de date de așteptare poate rula medii de testare și alte sisteme care pot fi închise dacă centrul de date primar trece. De asemenea, este posibil să folosim replicarea în două sensuri. Din punct de vedere hardware, nimic nu se va schimba.
În cazul arhitecturii clasice, vom instala în fiecare centru de date un sistem de stocare hibrid cu acces prin FibreChannel, tiering, deduplicare și compresie (dar nu online), 8 servere pentru fiecare site, 2 switch-uri FibreChannel și 10G Ethernet. Pentru replicarea și gestionarea comutării într-o arhitectură clasică, putem folosi instrumente VMware (Replication + SRM) sau instrumente terțe, care vor fi puțin mai ieftine și uneori mai convenabile.
Figura prezintă diagrama.
Când utilizați Cisco HyperFlex, se obține următoarea arhitectură:
Pentru HyperFlex, am folosit servere cu resurse mari CPU/RAM, deoarece... Unele dintre resurse vor merge către VM-ul controlerului HyperFlex; în ceea ce privește CPU și memorie, chiar am re-configurat puțin configurația HyperFlex pentru a nu juca împreună cu Cisco și a garanta resursele pentru VM-urile rămase. Dar putem abandona comutatoarele FibreChannel și nu vom avea nevoie de porturi Ethernet pentru fiecare server; traficul local este comutat în FI.
Rezultatul a fost următoarea configurație pentru fiecare centru de date:
Servere
8 x Server 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Sistem de stocare hibrid cu FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x switch Ethernet 10G 12 porturi
-
SAN
2 x switch FC 32/16Gb 24 porturi
2 x Cisco UCS FI 6332
Licențe
VMware Ent Plus
Replicarea și/sau orchestrarea comutării VM
VMware Ent Plus
Nu am furnizat licențe de software de replicare pentru Hyperflex, deoarece acestea sunt disponibile imediat pentru noi.
Pentru arhitectura clasică, am ales un furnizor care s-a impus ca un producător de înaltă calitate și ieftin. Pentru ambele variante am aplicat discountul standard pentru o anumita solutie, iar drept urmare am primit preturi reale.
Soluția Cisco HyperFlex s-a dovedit a fi cu 13% mai ieftină.
Scenariul 2: crearea a două centre de date active. În acest scenariu, proiectăm un cluster extins pe VMware.
Arhitectura clasică constă din servere de virtualizare, un SAN (protocol FC) și două sisteme de stocare care pot citi și scrie pe volumul întins între ele. Pe fiecare sistem de stocare punem o capacitate utila de stocare.
La HyperFlex pur și simplu creăm un Stretch Cluster cu același număr de noduri pe ambele site-uri. În acest caz, se utilizează un factor de replicare de 2+2.
Rezultatul este următoarea configurație:
arhitectura clasica
HyperFlex
Servere
16 x Server 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x NIC 10G)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x sisteme de stocare AllFlash (SSD de 150 TB)
-
LAN
4 x switch Ethernet 10G 24 porturi
-
SAN
4 x switch FC 32/16Gb 24 porturi
4 x Cisco UCS FI 6332
Licențe
VMware Ent Plus
VMware Ent Plus
În toate calculele nu am ținut cont de infrastructura de rețea, costurile centrului de date etc.: vor fi aceleași pentru arhitectura clasică și pentru soluția HyperFlex.
În ceea ce privește costul, HyperFlex s-a dovedit a fi cu 5% mai scump. Este demn de remarcat aici că în ceea ce privește resursele CPU/RAM am avut o declinare pentru Cisco, deoarece în configurație am umplut canalele controlerului de memorie în mod egal. Costul este puțin mai mare, dar nu de un ordin de mărime, ceea ce indică în mod clar că hiperconvergența nu este neapărat o „jucărie pentru cei bogați”, dar poate concura cu abordarea standard pentru construirea unui centru de date. Acest lucru poate fi de interes și pentru cei care au deja servere Cisco UCS și infrastructura corespunzătoare pentru acestea.
Printre avantaje, obținem absența costurilor pentru administrarea SAN și a sistemelor de stocare, compresia și deduplicarea online, un singur punct de intrare pentru suport (virtualizare, servere, sunt și sisteme de stocare), economisirea spațiului (dar nu în toate scenariile), simplificarea operațiunii.
În ceea ce privește suportul, aici îl obțineți de la un furnizor - Cisco. Judecând după experiența mea cu serverele Cisco UCS, îmi place; nu a trebuit să-l deschid pe HyperFlex, totul a funcționat la fel. Inginerii răspund prompt și pot rezolva nu numai probleme tipice, ci și cazuri complexe. Uneori mă întorc la ei cu întrebări: „Este posibil să faci asta, dă-i drumul?” sau „Am configurat ceva aici și nu vrea să funcționeze. Ajutor!" - vor găsi acolo cu răbdare ghidul necesar și vor indica acțiunile corecte; nu vor răspunde: „Rezolvăm doar problemele hardware”.
referințe
- Poșta mea - [e-mail protejat]
Sursa: www.habr.com