Aquest és un mite força comú en el camp del maquinari de servidors. A la pràctica, les solucions hiperconvergents (quan tot està en una) són necessàries per a moltes coses. Històricament, les primeres arquitectures van ser desenvolupades per Amazon i Google per als seus serveis. Aleshores la idea era fer una granja de computació a partir de nodes idèntics, cadascun dels quals tingués els seus propis discs. Tot això estava unit per algun programari de formació de sistemes (hipervisor) i estava dividit en màquines virtuals. L'objectiu principal és un mínim d'esforç per donar servei a un node i un mínim de problemes a l'hora d'escalar: només cal comprar mil o dos servidors iguals i connectar-los a prop. A la pràctica, es tracta de casos aïllats, i molt més sovint estem parlant d'un nombre reduït de nodes i una arquitectura una mica diferent.
Però l'avantatge segueix sent el mateix: increïble facilitat d'escalada i gestió. L'inconvenient és que les diferents tasques consumeixen recursos de manera diferent, i en alguns llocs hi haurà molts discs locals, en altres hi haurà poca memòria RAM, i així successivament, és a dir, per a diferents tipus de tasques, la utilització dels recursos disminuirà.
Resulta que pagueu entre un 10 i un 15% més per facilitar la configuració. Això és el que va provocar el mite del títol. Vam passar molt de temps buscant on s'aplicaria de manera òptima la tecnologia i ho vam trobar. El cas és que Cisco no tenia sistemes d'emmagatzematge propis, però volien un mercat de servidors complet. I van fer Cisco Hyperflex, una solució amb emmagatzematge local als nodes.
I això, de sobte, va resultar ser una molt bona solució per als centres de dades de seguretat (Disaster Recovery). Ara et diré per què i com. I us mostraré les proves de clúster.
On calgui
La hiperconvergència és:
- Transferència de discs a nodes de càlcul.
- Integració completa del subsistema d'emmagatzematge amb el subsistema de virtualització.
- Transferència/integració amb el subsistema de xarxa.
Aquesta combinació us permet implementar moltes funcions del sistema d'emmagatzematge a nivell de virtualització i tot des d'una finestra de control.
A la nostra empresa, els projectes per dissenyar centres de dades redundants tenen una gran demanda, i sovint s'escull una solució hiperconvergent a causa d'un munt d'opcions de replicació (fins a un metroclúster) de la caixa.
En el cas dels centres de dades de còpia de seguretat, normalment estem parlant d'una instal·lació remota en un lloc a l'altre costat de la ciutat o en una altra ciutat. Permet restaurar sistemes crítics en cas de fallada parcial o total del centre de dades principal. Les dades de vendes es reprodueixen constantment allà, i aquesta replicació pot ser a nivell d'aplicació o a nivell de dispositiu de bloc (emmagatzematge).
Per tant, ara parlaré del disseny i les proves del sistema, i després d'un parell d'escenaris d'aplicacions de la vida real amb dades d'estalvi.
Proves
La nostra instància consta de quatre servidors, cadascun dels quals té 10 unitats SSD de 960 GB. Hi ha un disc dedicat per a la memòria cau operacions d'escriptura i emmagatzemar la màquina virtual del servei. La solució en si és la quarta versió. El primer és francament cru (a jutjar per les crítiques), el segon és humit, el tercer ja és força estable i aquest es pot anomenar un llançament després del final de les proves beta per al públic en general. Durant les proves no vaig veure cap problema, tot funciona com un rellotge.
Canvis a la v4S'han corregit un munt d'errors.
Inicialment, la plataforma només podia funcionar amb l'hipervisor VMware ESXi i suportava un nombre reduït de nodes. A més, el procés de desplegament no sempre va acabar correctament, alguns passos s'havien de reiniciar, hi va haver problemes amb l'actualització de versions anteriors, les dades de la GUI no sempre es mostraven correctament (tot i que encara no estic satisfet amb la visualització dels gràfics de rendiment ), de vegades van sorgir problemes a la interfície amb la virtualització.
Ara s'han solucionat tots els problemes de la infància, HyperFlex pot gestionar tant ESXi com Hyper-V, a més és possible:
- Creació d'un clúster estirat.
- Creació d'un clúster per a oficines sense utilitzar Fabric Interconnect, de dos a quatre nodes (comprem només servidors).
- Capacitat per treballar amb sistemes d'emmagatzematge externs.
- Suport per a contenidors i Kubernetes.
- Creació de zones de disponibilitat.
- Integració amb VMware SRM si la funcionalitat integrada no és satisfactòria.
L'arquitectura no és gaire diferent de les solucions dels seus principals competidors, no van crear una bicicleta. Tot funciona a la plataforma de virtualització VMware o Hyper-V. El maquinari està allotjat en servidors propietaris de Cisco UCS. Hi ha qui odia la plataforma per la relativa complexitat de la configuració inicial, molts botons, un sistema no trivial de plantilles i dependències, però també hi ha qui ha après Zen, s'inspira en la idea i ja no vol. per treballar amb altres servidors.
Considerarem la solució per a VMware, ja que la solució es va crear originalment per a ella i té més funcionalitats; Hyper-V es va afegir al llarg del camí per mantenir-se al dia amb els competidors i satisfer les expectatives del mercat.
Hi ha un clúster de servidors ple de discs. Hi ha discs per a l'emmagatzematge de dades (SSD o HDD, segons els vostres gustos i necessitats), hi ha un disc SSD per a la memòria cau. Quan s'escriuen dades al magatzem de dades, les dades es desen a la capa de memòria cau (disc SSD dedicat i RAM de la màquina virtual del servei). Paral·lelament, s'envia un bloc de dades als nodes del clúster (el nombre de nodes depèn del factor de replicació del clúster). Després de la confirmació de tots els nodes sobre la gravació correcta, la confirmació de l'enregistrament s'envia a l'hipervisor i després a la màquina virtual. Les dades enregistrades es desdupliquen, es comprimeixen i s'escriuen en discs d'emmagatzematge en segon pla. Al mateix temps, sempre s'escriu un bloc gran als discs d'emmagatzematge i de manera seqüencial, la qual cosa redueix la càrrega dels discos d'emmagatzematge.
La deduplicació i la compressió sempre estan habilitades i no es poden desactivar. Les dades es llegeixen directament des dels discs d'emmagatzematge o des de la memòria cau RAM. Si s'utilitza una configuració híbrida, les lectures també s'emmagatzemen a la memòria cau a l'SSD.
Les dades no estan lligades a la ubicació actual de la màquina virtual i es distribueixen uniformement entre els nodes. Aquest enfocament us permet carregar tots els discos i les interfícies de xarxa per igual. Hi ha un inconvenient evident: no podem reduir al màxim la latència de lectura, ja que no hi ha cap garantia de disponibilitat de dades localment. Però crec que aquest és un petit sacrifici en comparació amb els beneficis rebuts. A més, els retards de la xarxa han arribat a valors tals que pràcticament no afecten el resultat global.
Un controlador de la plataforma de dades Cisco HyperFlex de servei especial, que es crea a cada node d'emmagatzematge, és responsable de tota la lògica de funcionament del subsistema de disc. A la nostra configuració de VM de servei, es van assignar vuit vCPU i 72 GB de RAM, cosa que no és tan poc. Us recordo que el propi host té 28 nuclis físics i 512 GB de RAM.
La màquina virtual de servei té accés als discs físics directament enviant el controlador SAS a la màquina virtual. La comunicació amb l'hipervisor es produeix mitjançant un mòdul especial IOVisor, que intercepta les operacions d'E/S i utilitza un agent que permet enviar ordres a l'API de l'hipervisor. L'agent és responsable de treballar amb instantànies i clons d'HyperFlex.
Els recursos de disc es munten a l'hipervisor com a comparticions NFS o SMB (segons el tipus d'hipervisor, endevineu quin és on). I sota el capó, es tracta d'un sistema de fitxers distribuït que us permet afegir funcions de sistemes d'emmagatzematge complets per a adults: assignació de volum prim, compressió i deduplicació, instantànies amb tecnologia Redirect-on-Write, replicació síncrona/asíncrona.
El servei VM proporciona accés a la interfície de gestió WEB del subsistema HyperFlex. Hi ha integració amb vCenter, i la majoria de les tasques quotidianes es poden realitzar des d'ell, però els magatzems de dades, per exemple, són més convenients per tallar des d'una càmera web independent si ja heu canviat a una interfície HTML5 ràpida o utilitzeu un client Flash complet. amb plena integració. A la càmera web del servei podeu veure el rendiment i l'estat detallat del sistema.
Hi ha un altre tipus de node en un clúster: els nodes informàtics. Aquests poden ser servidors de rack o blade sense discs integrats. Aquests servidors poden executar màquines virtuals les dades de les quals s'emmagatzemen en servidors amb discs. Des del punt de vista de l'accés a les dades, no hi ha diferència entre els tipus de nodes, perquè l'arquitectura implica l'abstracció de la ubicació física de les dades. La proporció màxima de nodes de càlcul a nodes d'emmagatzematge és de 2:1.
L'ús de nodes de càlcul augmenta la flexibilitat a l'hora d'escalar els recursos del clúster: no hem de comprar nodes addicionals amb discs si només necessitem CPU/RAM. A més, podem afegir una gàbia blade i estalviar en la col·locació en bastidor dels servidors.
Com a resultat, tenim una plataforma hiperconvergent amb les següents característiques:
- Fins a 64 nodes en un clúster (fins a 32 nodes d'emmagatzematge).
- El nombre mínim de nodes en un clúster és de tres (dos per a un clúster Edge).
- Mecanisme de redundància de dades: duplicació amb factor de replicació 2 i 3.
- Clúster de metro.
- Replicació de VM asíncrona a un altre clúster HyperFlex.
- Orquestració del canvi de màquines virtuals a un centre de dades remot.
- Imatges natives amb tecnologia Redirect-on-Write.
- Fins a 1 PB d'espai utilitzable al factor de replicació 3 i sense deduplicació. No tenim en compte el factor de replicació 2, perquè aquesta no és una opció per a vendes serioses.
Un altre gran avantatge és la facilitat de gestió i desplegament. Totes les complexitats de la configuració dels servidors UCS són ateses per una màquina virtual especialitzada preparada per enginyers de Cisco.
Configuració del banc de proves:
- 2 x Cisco UCS Fabric Interconnect 6248UP com a clúster de gestió i components de xarxa (48 ports que funcionen en mode Ethernet 10G/FC 16G).
- Quatre servidors Cisco UCS HXAF240 M4.
Característiques del servidor:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/ranking dual/x4/1.2 v
Xarxa
UCSC-MLOM-CSC-02 (VIC 1227). 2 ports Ethernet 10G
HBA d'emmagatzematge
Controlador Cisco 12G Modular SAS Pass through
Discs d'emmagatzematge
1 x SSD Intel S3520 de 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Més opcions de configuracióA més del maquinari seleccionat, les opcions següents estan disponibles actualment:
- HXAF240c M5.
- Una o dues CPU que van des d'Intel Silver 4110 fins a Intel Platinum I8260Y. Segona generació disponible.
- 24 ranures de memòria, tires de 16 GB RDIMM 2600 a 128 GB LRDIMM 2933.
- De 6 a 23 discos de dades, un disc de memòria cau, un disc del sistema i un disc d'arrencada.
Unitats de capacitat
- HX-SD960G61X-EV 960 GB 2.5 polzades Enterprise Value 6G SATA SSD (1X de resistència) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 polzades Enterprise Value 6G SATA SSD (1X de resistència) SAS 3.8 TB.
- Emmagatzematge en memòria cau
- HX-NVMEXPB-I375 375 GB 2.5 polzades Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6 TB 2.5 polzades Ent. Perf. SSD NVMe (resistència 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 polzades Ent. Perf. 12G SAS SSD (10X de resistència) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 polzades Ent. Perf. 12G SAS SED SSD (10X de resistència) SAS 800 GB.
- HX-SD16T123X-EP SSD SAS de 1.6 G de rendiment empresarial de 2.5 TB i 12 polzades (resistència 3X).
Sistema/Unitats de registre
- HX-SD240GM1X-EV 240 GB 2.5 polzades Enterprise Value 6G SATA SSD (Requereix actualització).
Unitats d'arrencada
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Connecteu-vos a la xarxa mitjançant ports Ethernet 40G, 25G o 10G.
El FI pot ser HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
La prova en si
Per provar el subsistema de disc, vaig utilitzar HCIBench 2.2.1. Aquesta és una utilitat gratuïta que us permet automatitzar la creació d'una càrrega des de diverses màquines virtuals. La càrrega en si la genera el fio habitual.
El nostre clúster consta de quatre nodes, factor de replicació 3, tots els discos són Flash.
Per provar, vaig crear quatre magatzems de dades i vuit màquines virtuals. Per a les proves d'escriptura, se suposa que el disc de memòria cau no està ple.
Els resultats de la prova són els següents:
100% llegit 100% aleatori
0% llegit 100% aleatori
Profunditat de bloc/cua
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
16K
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
32K
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
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
La negreta indica valors després dels quals no hi ha augment de la productivitat, de vegades fins i tot la degradació és visible. Això es deu al fet que estem limitats pel rendiment de la xarxa/controladors/discos.
- Lectura seqüencial 4432 MB/s.
- Escriptura seqüencial 804 MB/s.
- Si un controlador falla (falla d'una màquina virtual o host), la caiguda de rendiment és doble.
- Si el disc d'emmagatzematge falla, la reducció és d'1/3. La reconstrucció del disc ocupa el 5% dels recursos de cada controlador.
En un bloc petit, estem limitats pel rendiment del controlador (màquina virtual), la seva CPU es carrega al 100% i, quan el bloc augmenta, estem limitats per l'ample de banda del port. 10 Gbps no són suficients per desbloquejar el potencial del sistema AllFlash. Malauradament, els paràmetres de l'estand de demostració proporcionat no ens permeten provar el funcionament a 40 Gbit/s.
Segons la meva impressió de les proves i l'estudi de l'arquitectura, a causa de l'algoritme que col·loca les dades entre tots els hosts, obtenim un rendiment escalable i predictible, però això també és una limitació a l'hora de llegir, perquè seria possible extreure més dels discs locals, aquí pot estalviar una xarxa més productiva, per exemple, hi ha disponible FI a 40 Gbit/s.
A més, un disc per a la memòria cau i la desduplicació pot ser una limitació; de fet, en aquest banc de proves podem escriure en quatre discs SSD. Seria fantàstic poder augmentar el nombre d'unitats de memòria cau i veure la diferència.
Ús real
Per organitzar un centre de dades de còpia de seguretat, podeu utilitzar dos enfocaments (no pensem en col·locar una còpia de seguretat en un lloc remot):
- Actiu-Passiu. Totes les aplicacions estan allotjades al centre de dades principal. La replicació és síncrona o asíncrona. Si el centre de dades principal falla, hem d'activar el de còpia de seguretat. Això es pot fer manualment/guions/aplicacions d'orquestració. Aquí obtindrem un RPO proporcional a la freqüència de rèplica, i el RTO depèn de la reacció i les habilitats de l'administrador i de la qualitat del desenvolupament/depuració del pla de commutació.
- Actiu-Activ. En aquest cas, només hi ha replicació síncrona; la disponibilitat dels centres de dades està determinada per un quòrum/àrbitre situat estrictament al tercer lloc. RPO = 0 i RTO pot arribar a 0 (si l'aplicació ho permet) o igual al temps de migració per error d'un node en un clúster de virtualització. A nivell de virtualització, es crea un clúster estirat (Metro) que requereix emmagatzematge actiu-actiu.
Normalment veiem que els clients ja han implementat una arquitectura amb un sistema d'emmagatzematge clàssic al centre de dades principal, per això en dissenyem una altra per a la replicació. Com he esmentat, Cisco HyperFlex ofereix replicació asíncrona i creació de clúster de virtualització estesa. Al mateix temps, no necessitem un sistema d'emmagatzematge dedicat de nivell mitjà i superior amb funcions de replicació cares i accés a dades Active-Active en dos sistemes d'emmagatzematge.
Escenari 1: Tenim un centre de dades primari i de seguretat, una plataforma de virtualització a VMware vSphere. Tots els sistemes productius es troben al centre de dades principal i la replicació de les màquines virtuals es realitza a nivell d'hipervisor, això evitarà mantenir les VM enceses al centre de dades de còpia de seguretat. Repliquem bases de dades i aplicacions especials mitjançant eines integrades i mantenim les màquines virtuals enceses. Si el centre de dades principal falla, posem en marxa sistemes al centre de dades de còpia de seguretat. Creiem que tenim unes 100 màquines virtuals. Mentre el centre de dades principal està operatiu, el centre de dades en espera pot executar entorns de prova i altres sistemes que es poden tancar si es canvia el centre de dades principal. També és possible que utilitzem la replicació bidireccional. Des del punt de vista del maquinari, res canviarà.
En el cas de l'arquitectura clàssica, instal·larem a cada centre de dades un sistema d'emmagatzematge híbrid amb accés a través de FibreChannel, nivells, deduplicació i compressió (però no en línia), 8 servidors per a cada lloc, 2 commutadors FibreChannel i Ethernet 10G. Per a la gestió de rèplica i commutació en una arquitectura clàssica, podem utilitzar eines de VMware (Replication + SRM) o eines de tercers, que seran una mica més barates i de vegades més còmodes.
La figura mostra el diagrama.
Quan s'utilitza Cisco HyperFlex, s'obté l'arquitectura següent:
Per a HyperFlex, vaig utilitzar servidors amb grans recursos de CPU/RAM, perquè... Alguns dels recursos aniran a la VM del controlador HyperFlex; pel que fa a la CPU i la memòria, fins i tot vaig tornar a configurar una mica la configuració d'HyperFlex per no jugar amb Cisco i garantir els recursos per a les VM restants. Però podem abandonar els commutadors FibreChannel i no necessitarem ports Ethernet per a cada servidor; el trànsit local es canvia dins de FI.
El resultat va ser la configuració següent per a cada centre de dades:
Servidors
8 servidors 1U (384 GB de RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Sistema d'emmagatzematge híbrid amb FC Front-End (SSD de 20 TB, NL-SAS de 130 TB)
-
LEN
2 x Switch Ethernet 10G 12 ports
-
SANT
2 x commutador FC 32/16 Gb 24 ports
2 x Cisco UCS FI 6332
Llicències
VMware Ent Plus
Replicació i/o orquestració de la commutació de VM
VMware Ent Plus
No vaig proporcionar llicències de programari de rèplica per a Hyperflex, ja que això està disponible per a nosaltres.
Per a l'arquitectura clàssica, vaig triar un venedor que s'ha consolidat com un fabricant d'alta qualitat i econòmic. Per a ambdues opcions, vaig aplicar el descompte estàndard per a una solució específica i, com a resultat, vaig rebre preus reals.
La solució Cisco HyperFlex va resultar ser un 13% més barata.
Escenari 2: creació de dos centres de dades actius. En aquest escenari, estem dissenyant un clúster estirat a VMware.
L'arquitectura clàssica consta de servidors de virtualització, una SAN (protocol FC) i dos sistemes d'emmagatzematge que poden llegir i escriure al volum estirat entre ells. A cada sistema d'emmagatzematge hi posem una capacitat útil d'emmagatzematge.
A HyperFlex simplement creem un clúster d'estirament amb el mateix nombre de nodes als dos llocs. En aquest cas, s'utilitza un factor de replicació de 2+2.
El resultat és la configuració següent:
arquitectura clàssica
HyperFlex
Servidors
16 servidors 1U (384 GB de RAM, 2 x Intel Gold 6132, FC HBA, 2 x NIC 10G)
16 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x SSD de 3,8 TB, VIC 1387)
SHD
2 sistemes d'emmagatzematge AllFlash (SSD de 150 TB)
-
LEN
4 x Switch Ethernet 10G 24 ports
-
SANT
4 x commutador FC 32/16 Gb 24 ports
4 x Cisco UCS FI 6332
Llicències
VMware Ent Plus
VMware Ent Plus
En tots els càlculs, no he tingut en compte la infraestructura de xarxa, els costos del centre de dades, etc.: seran els mateixos per a l'arquitectura clàssica i per a la solució HyperFlex.
En termes de cost, HyperFlex va resultar ser un 5% més car. Val la pena assenyalar aquí que, pel que fa als recursos de CPU/RAM, tenia un esbiaix per a Cisco, perquè en la configuració vaig omplir els canals del controlador de memòria de manera uniforme. El cost és lleugerament superior, però no per un ordre de magnitud, la qual cosa indica clarament que la hiperconvergència no és necessàriament una "joguina per als rics", sinó que pot competir amb l'enfocament estàndard per construir un centre de dades. Això també pot interessar a aquells que ja tenen servidors Cisco UCS i la infraestructura corresponent per a ells.
Entre els avantatges, trobem l'absència de costos d'administració de sistemes SAN i emmagatzematge, compressió i deduplicació en línia, un únic punt d'entrada per al suport (virtualització, servidors, també són sistemes d'emmagatzematge), estalvi d'espai (però no en tots els escenaris), simplificant el funcionament.
Pel que fa al suport, aquí l'obté d'un proveïdor: Cisco. A jutjar per la meva experiència amb els servidors Cisco UCS, m'agrada; no vaig haver d'obrir-lo a HyperFlex, tot va funcionar igual. Els enginyers responen ràpidament i poden resoldre no només problemes típics, sinó també casos complexos. De vegades em dirigeixo a ells amb preguntes: "És possible fer-ho, cargol-ho?" o "He configurat alguna cosa aquí i no vol funcionar. Ajuda!" - Hi trobaran pacientment la guia necessària i assenyalaran les accions correctes; no respondran: "Només resolem problemes de maquinari".
Referències
- El meu correu - [protegit per correu electrònic]
Font: www.habr.com