Hola, lectors de Habr. Amb aquest article obrim una sèrie que parlarà del sistema hiperconvergent AERODISK vAIR que hem desenvolupat. Inicialment, volíem explicar-ho tot al primer article, però el sistema és força complex, així que ens menjarem l'elefant per parts.
Comencem la història amb la història de la creació del sistema, aprofundim en el sistema de fitxers ARDFS, que és la base de vAIR, i també parlem una mica sobre el posicionament d'aquesta solució al mercat rus.
En propers articles parlarem amb més detall sobre diferents components arquitectònics (clúster, hipervisor, equilibrador de càrrega, sistema de monitorització, etc.), el procés de configuració, plantejarem problemes de llicència, mostrarem per separat les proves de xoc i, per descomptat, escriurem sobre proves de càrrega i mida. També dedicarem un article a part a la versió comunitària de vAIR.
Aerodisk és una història sobre sistemes d'emmagatzematge? O per què vam començar a fer hiperconvergència en primer lloc?
Inicialment, la idea de crear la nostra pròpia hiperconvergència ens va sorgir cap al 2010. Aleshores, no hi havia ni Aerodisk ni solucions semblants (sistemes comercials hiperconvergents en caixa) al mercat. La nostra tasca era la següent: a partir d'un conjunt de servidors amb discs locals, units per una interconnexió mitjançant el protocol Ethernet, calia crear un emmagatzematge estès i llançar-hi màquines virtuals i una xarxa de programari. Tot això s'havia d'implementar sense sistemes d'emmagatzematge (perquè simplement no hi havia diners per als sistemes d'emmagatzematge i el seu maquinari, i encara no havíem inventat els nostres propis sistemes d'emmagatzematge).
Vam provar moltes solucions de codi obert i finalment vam resoldre aquest problema, però la solució era molt complexa i difícil de repetir. A més, aquesta solució estava en la categoria de “Funciona? No toquis! Per tant, després d'haver resolt aquest problema, no vam desenvolupar més la idea de transformar el resultat del nostre treball en un producte complet.
Després d'aquell incident, ens vam allunyar d'aquesta idea, però encara teníem la sensació que aquest problema era completament solucionable, i els beneficis d'aquesta solució eren més que evidents. Posteriorment, els productes HCI llançats d'empreses estrangeres només van confirmar aquesta sensació.
Per tant, a mitjan 2016, vam tornar a aquesta tasca com a part de la creació d'un producte complet. En aquell moment encara no teníem cap relació amb inversors, així que vam haver de comprar un estand de desenvolupament per uns diners no massa grans. Després d'haver recollit servidors i interruptors usats a Avito, ens vam posar mans a l'obra.
La tasca inicial principal va ser crear el nostre, encara que senzill, però el nostre propi sistema de fitxers, que pogués distribuir les dades de manera automàtica i uniforme en forma de blocs virtuals en l'èsè nombre de nodes del clúster, que estan connectats per una interconnexió via Ethernet. Al mateix temps, el FS hauria d'escalar bé i fàcilment i ser independent dels sistemes adjacents, és a dir. estar alienat de vAIR en forma de "només una instal·lació d'emmagatzematge".
Primer concepte vAIR
Vam abandonar deliberadament l'ús de solucions de codi obert preparades per organitzar l'emmagatzematge estirat (ceph, gluster, luster i similars) en favor del nostre propi desenvolupament, ja que ja teníem molta experiència en projectes amb elles. Per descomptat, aquestes solucions en si són excel·lents, i abans de treballar en Aerodisk, vam implementar més d'un projecte d'integració amb elles. Però una cosa és implementar una tasca específica per a un client, formar personal i, potser, comprar el suport d'un gran venedor, i una altra molt diferent és crear un producte fàcilment replicable que s'utilitzarà per a diverses tasques, que nosaltres, com a venedor, fins i tot potser sabem de nosaltres mateixos que no ho farem. Per al segon propòsit, els productes de codi obert existents no eren adequats per a nosaltres, així que vam decidir crear nosaltres mateixos un sistema de fitxers distribuït.
Dos anys més tard, diversos desenvolupadors (que van combinar el treball en vAIR amb el treball en el clàssic sistema d'emmagatzematge del motor) van aconseguir un cert resultat.
El 2018, havíem escrit un sistema de fitxers senzill i el vam complementar amb el maquinari necessari. El sistema va combinar discos físics (locals) de diferents servidors en una agrupació plana mitjançant una interconnexió interna i els va "tallar" en blocs virtuals, després es van crear dispositius de bloqueig amb diferents graus de tolerància a errors a partir dels blocs virtuals, en els quals es van crear els virtuals. i executat amb els cotxes d'hipervisor KVM.
No ens vam molestar massa amb el nom del sistema de fitxers i el vam anomenar succintament ARDFS (endevineu què significa))
Aquest prototip tenia un bon aspecte (no visualment, és clar, encara no hi havia disseny visual) i va mostrar bons resultats en termes de rendiment i escala. Després del primer resultat real, vam posar en marxa aquest projecte, organitzant un entorn de desenvolupament complet i un equip separat que només s'ocupava de vAIR.
Just en aquell moment, l'arquitectura general de la solució havia madurat, que encara no ha sofert grans canvis.
Submergir-se en el sistema de fitxers ARDFS
ARDFS és la base de vAIR, que proporciona emmagatzematge de dades distribuït i tolerant a errors a tot el clúster. Una de les característiques distintives (però no les úniques) d'ARDFS és que no utilitza cap servidor dedicat addicional per a metadades i gestió. Aquest va ser concebut originalment per simplificar la configuració de la solució i per a la seva fiabilitat.
Estructura d'emmagatzematge
Dins de tots els nodes del clúster, ARDFS organitza un grup lògic a partir de tot l'espai de disc disponible. És important entendre que una agrupació encara no és dades o espai formatat, sinó simplement un marcatge, és a dir. Qualsevol node amb vAIR instal·lat, quan s'afegeix al clúster, s'afegeix automàticament a l'agrupació ARDFS compartida i els recursos de disc es comparteixen automàticament a tot el clúster (i estan disponibles per a l'emmagatzematge de dades futur). Aquest enfocament us permet afegir i eliminar nodes sobre la marxa sense cap impacte greu en el sistema que ja està en funcionament. Aquells. el sistema és molt fàcil d'escalar "en maons", afegint o eliminant nodes del clúster si cal.
Els discos virtuals (objectes d'emmagatzematge per a màquines virtuals) s'afegeixen a la part superior del grup ARDFS, que es construeixen a partir de blocs virtuals de 4 megabytes de mida. Els discs virtuals emmagatzemen dades directament. L'esquema de tolerància a errors també s'estableix a nivell de disc virtual.
Com ja haureu endevinat, per a la tolerància a errors del subsistema de disc, no fem servir el concepte de RAID (Matriu redundant de discos independents), sinó que utilitzem RAIN (Matriu redundant de nodes independents). Aquells. La tolerància a errors es mesura, automatitza i gestiona en funció dels nodes, no dels discs. Els discs, per descomptat, també són un objecte d'emmagatzematge, que, com tota la resta, es controlen, podeu realitzar totes les operacions estàndard amb ells, inclòs el muntatge d'un RAID de maquinari local, però el clúster funciona específicament en nodes.
En una situació en què realment voleu RAID (per exemple, un escenari que admet múltiples errors en grups petits), res no us impedeix utilitzar controladors RAID locals i crear emmagatzematge ampliat i una arquitectura RAIN a la part superior. Aquest escenari és força viu i és recolzat per nosaltres, així que en parlarem en un article sobre escenaris típics per utilitzar vAIR.
Esquemes de tolerància a errors d'emmagatzematge
Hi pot haver dos esquemes de tolerància a errors per als discos virtuals a vAIR:
1) Factor de replicació o simplement replicació: aquest mètode de tolerància a fallades és tan senzill com un pal i una corda. La replicació síncrona es realitza entre nodes amb un factor de 2 (2 còpies per clúster) o 3 (3 còpies, respectivament). RF-2 permet que un disc virtual suporti la fallada d'un node del clúster, però "menja" la meitat del volum útil, i RF-3 suportarà la fallada de 2 nodes del clúster, però reserva 2/3 del volum útil per a les seves necessitats. Aquest esquema és molt similar al RAID-1, és a dir, un disc virtual configurat a RF-2 és resistent a la fallada de qualsevol node del clúster. En aquest cas, tot anirà bé amb les dades i fins i tot l'E/S no s'aturarà. Quan el node caigut torni al servei, començarà la recuperació/sincronització automàtica de dades.
A continuació es mostren exemples de la distribució de dades RF-2 i RF-3 en mode normal i en situació de fallada.
Tenim una màquina virtual amb una capacitat de 8 MB de dades úniques (útils), que s'executa en 4 nodes vAIR. Està clar que, en realitat, és poc probable que hi hagi un volum tan petit, però per a un esquema que reflecteix la lògica del funcionament d'ARDFS, aquest exemple és el més entenedor. AB són blocs virtuals de 4 MB que contenen dades úniques de la màquina virtual. RF-2 crea dues còpies d'aquests blocs A1+A2 i B1+B2, respectivament. Aquests blocs estan "dissenyats" entre nodes, evitant la intersecció de les mateixes dades al mateix node, és a dir, la còpia A1 no estarà situada al mateix node que la còpia A2. El mateix amb B1 i B2.
Si un dels nodes falla (per exemple, el node núm. 3, que conté una còpia de B1), aquesta còpia s'activa automàticament al node on no hi ha cap còpia de la seva còpia (és a dir, una còpia de B2).
Així, el disc virtual (i la VM, en conseqüència) poden sobreviure fàcilment a la fallada d'un node en l'esquema RF-2.
L'esquema de replicació, tot i que és senzill i fiable, pateix el mateix problema que RAID1: no hi ha prou espai utilitzable.
2) La codificació d'esborrat o la codificació d'esborrat (també coneguda com a "codificació redundant", "codificació d'esborrat" o "codi de redundància") existeix per resoldre el problema anterior. EC és un esquema de redundància que proporciona una alta disponibilitat de dades amb una sobrecàrrega d'espai en disc més baixa en comparació amb la rèplica. El principi de funcionament d'aquest mecanisme és similar al RAID 5, 6, 6P.
Quan es codifica, el procés EC divideix un bloc virtual (4MB per defecte) en diversos "trossos de dades" més petits segons l'esquema EC (per exemple, un esquema 2+1 divideix cada bloc de 4MB en 2 fragments de 2MB). A continuació, aquest procés genera "trossos de paritat" per als "trossos de dades" que no són més grans que una de les parts dividides anteriorment. Quan es descodifica, EC genera els trossos que falten llegint les dades "supervivents" a tot el clúster.
Per exemple, un disc virtual amb un esquema 2 + 1 EC, implementat en 4 nodes del clúster, suportarà fàcilment la fallada d'un node del clúster de la mateixa manera que RF-2. En aquest cas, els costos generals seran menors, en particular, el coeficient de capacitat útil per a RF-2 és 2, i per a EC 2+1 serà 1,5.
Per descriure-ho de manera més senzilla, l'essència és que el bloc virtual es divideix en 2-8 (per què de 2 a 8, vegeu més avall) "peces", i per a aquestes peces es calculen "peces" de paritat d'un volum similar.
Com a resultat, les dades i la paritat es distribueixen uniformement entre tots els nodes del clúster. Al mateix temps, com amb la replicació, ARDFS distribueix automàticament les dades entre nodes de manera que s'evita que dades idèntiques (còpies de dades i la seva paritat) s'emmagatzemin al mateix node, per tal d'eliminar la possibilitat de perdre dades a causa de al fet que les dades i la seva paritat acabaran de sobte en un node d'emmagatzematge que falla.
A continuació es mostra un exemple, amb la mateixa màquina virtual de 8 MB i 4 nodes, però amb un esquema EC 2+1.
Els blocs A i B es divideixen en dues peces de 2 MB cadascuna (dos perquè 2+1), és a dir, A1+A2 i B1+B2. A diferència d'una rèplica, A1 no és una còpia de l'A2, és un bloc virtual A, dividit en dues parts, igual que el bloc B. En total, obtenim dos conjunts de 4MB, cadascun dels quals conté dues peces de dos MB. A continuació, per a cadascun d'aquests conjunts, es calcula la paritat amb un volum de no més d'una peça (és a dir, 2 MB), obtenim un + 2 peces addicionals de paritat (AP i BP). En total tenim dades 4×2 + paritat 2×2.
A continuació, les peces es "distribueixen" entre els nodes de manera que les dades no s'intersequen amb la seva paritat. Aquells. A1 i A2 no estaran al mateix node que AP.
En cas de fallada d'un node (per exemple, també del tercer), el bloc B1 caigut es restaurarà automàticament des de la paritat BP, que s'emmagatzema al node núm. 2, i s'activarà al node on hi hagi. sense paritat B, és a dir. tros de BP. En aquest exemple, aquest és el node núm. 1
Estic segur que el lector té una pregunta:
"Tot el que heu descrit ha estat implementat durant molt de temps tant pels competidors com en solucions de codi obert, quina diferència hi ha entre la vostra implementació d'EC a ARDFS?"
I després hi haurà funcions interessants d'ARDFS.
Esborrar la codificació amb un enfocament en la flexibilitat
Inicialment, vam proporcionar un esquema EC X+Y força flexible, on X és igual a un nombre del 2 al 8, i Y és igual a un nombre de l'1 al 8, però sempre inferior o igual a X. Aquest esquema es proporciona per flexibilitat. Augmentar el nombre de peces de dades (X) en què es divideix el bloc virtual permet reduir els costos generals, és a dir, augmentar l'espai utilitzable.
Augmentar el nombre de fragments de paritat (Y) augmenta la fiabilitat del disc virtual. Com més gran sigui el valor Y, més nodes del clúster poden fallar. Per descomptat, augmentar el volum de paritat redueix la quantitat de capacitat utilitzable, però aquest és un preu a pagar per la fiabilitat.
La dependència del rendiment dels circuits EC és gairebé directa: com més "peces", menor és el rendiment; aquí, per descomptat, cal una visió equilibrada.
Aquest enfocament permet als administradors configurar l'emmagatzematge ampliat amb la màxima flexibilitat. Dins del grup ARDFS, podeu utilitzar qualsevol esquema de tolerància a fallades i les seves combinacions, cosa que, al nostre parer, també és molt útil.
A continuació es mostra una taula que compara diversos esquemes de RF i EC (no tots possibles).
La taula mostra que fins i tot la combinació més "terry" EC 8+7, que permet la pèrdua de fins a 7 nodes en un clúster simultàniament, "menja" menys espai utilitzable (1,875 enfront de 2) que la replicació estàndard i protegeix 7 vegades millor , la qual cosa fa que aquest mecanisme de protecció, encara que més complex, sigui molt més atractiu en situacions en què cal garantir la màxima fiabilitat en condicions d'espai en disc limitat. Al mateix temps, cal entendre que cada "plus" de X o Y suposarà una sobrecàrrega de rendiment addicional, de manera que en el triangle entre fiabilitat, estalvi i rendiment cal triar amb molta cura. Per aquest motiu, dedicarem un article a part a esborrar la mida de la codificació.
Fiabilitat i autonomia del sistema de fitxers
ARDFS s'executa localment a tots els nodes del clúster i els sincronitza mitjançant els seus propis mitjans mitjançant interfícies Ethernet dedicades. El punt important és que ARDFS sincronitza de manera independent no només les dades, sinó també les metadades relacionades amb l'emmagatzematge. Mentre treballàvem en ARDFS, vam estudiar simultàniament diverses solucions existents i vam descobrir que moltes sincronitzen el meta del sistema de fitxers mitjançant un SGBD distribuït extern, que també fem servir per a la sincronització, però només configuracions, no metadades FS (sobre aquest i altres subsistemes relacionats). en el següent article).
La sincronització de metadades de FS mitjançant un SGBD extern és, per descomptat, una solució de treball, però aleshores la consistència de les dades emmagatzemades a ARDFS dependria del SGBD extern i del seu comportament (i, francament, és una dama capriciosa), que en la nostra opinió és dolenta. Per què? Si les metadades de l'FS es fan malbé, les dades de l'FS també es poden dir "adéu", així que vam decidir prendre un camí més complex però fiable.
Hem creat el subsistema de sincronització de metadades per a ARDFS nosaltres mateixos i viu completament independentment dels subsistemes adjacents. Aquells. cap altre subsistema pot corrompre les dades ARDFS. Segons la nostra opinió, aquesta és la manera més fiable i correcta, però el temps dirà si realment és així. A més, hi ha un avantatge addicional amb aquest enfocament. ARDFS es pot utilitzar independentment de vAIR, igual que l'emmagatzematge estirat, que sens dubte utilitzarem en productes futurs.
Com a resultat, en desenvolupar ARDFS, hem rebut un sistema de fitxers flexible i fiable que ofereix una opció on podeu estalviar capacitat o renunciar a tot el rendiment, o fer un emmagatzematge ultra fiable a un cost raonable, però reduint els requisits de rendiment.
Juntament amb una política de llicències senzilla i un model de lliurament flexible (de cara al futur, vAIR té llicència per node i es lliura com a programari o com a paquet de programari), això us permet adaptar amb molta precisió la solució a una gran varietat de requisits del client i aleshores mantenir aquest equilibri fàcilment.
Qui necessita aquest miracle?
D'una banda, podem dir que ja hi ha actors al mercat que disposen de solucions serioses en l'àmbit de la hiperconvergència, i aquí és cap a on anem realment. Sembla que aquesta afirmació és certa, PERÒ...
D'altra banda, quan sortim al camp i ens comuniquem amb els clients, nosaltres i els nostres socis veiem que això no és gens així. Hi ha moltes tasques per a la hiperconvergència, en alguns llocs la gent simplement no sabia que existien aquestes solucions, en d'altres semblava car, en d'altres hi va haver proves de solucions alternatives sense èxit, i en d'altres prohibeixen la compra a causa de les sancions. En general, el camp va resultar sense llaurar, així que vam anar a aixecar terra verge))).
Quan és millor el sistema d'emmagatzematge que GCS?
Quan treballem amb el mercat, sovint se'ns pregunta quan és millor utilitzar un esquema clàssic amb sistemes d'emmagatzematge i quan utilitzar hiperconvergents? Moltes empreses que produeixen GCS (especialment aquelles que no tenen sistemes d'emmagatzematge a la seva cartera) diuen: "Els sistemes d'emmagatzematge s'estan convertint en obsolets, només hiperconvergents!" Aquesta és una afirmació atrevida, però no reflecteix completament la realitat.
De fet, el mercat de l'emmagatzematge s'està avançant cap a la hiperconvergència i solucions similars, però sempre hi ha un "però".
En primer lloc, els centres de dades i les infraestructures informàtiques construïdes segons l'esquema clàssic amb sistemes d'emmagatzematge no es poden reconstruir fàcilment, per la qual cosa la modernització i finalització d'aquestes infraestructures segueix sent un llegat durant 5-7 anys.
En segon lloc, la infraestructura que s'està construint actualment (és a dir, la Federació Russa) es construeix segons l'esquema clàssic utilitzant sistemes d'emmagatzematge, i no perquè la gent no conegui la hiperconvergència, sinó perquè el mercat de la hiperconvergència és nou, solucions i solucions. Els estàndards encara no s'han establert, els informàtics encara no estan formats, tenen poca experiència, però necessiten construir centres de dades aquí i ara. I aquesta tendència durarà 3-5 anys més (i després un altre llegat, vegeu el punt 1).
En tercer lloc, hi ha una limitació purament tècnica en petits retards addicionals de 2 mil·lisegons per escriptura (excloent la memòria cau local, per descomptat), que són el cost de l'emmagatzematge distribuït.
Bé, no ens oblidem de l'ús de servidors físics grans que estimen l'escala vertical del subsistema de disc.
Hi ha moltes tasques necessàries i populars on els sistemes d'emmagatzematge es comporten millor que GCS. Aquí, per descomptat, aquells fabricants que no tenen sistemes d'emmagatzematge a la seva cartera de productes no estaran d'acord amb nosaltres, però estem disposats a argumentar raonablement. Per descomptat, nosaltres, com a desenvolupadors d'ambdós productes, definitivament compararem sistemes d'emmagatzematge i GCS en una de les nostres futures publicacions, on demostrarem clarament quin és millor en quines condicions.
I on funcionaran millor les solucions hiperconvergents que els sistemes d'emmagatzematge?
A partir dels punts anteriors, es poden extreure tres conclusions òbvies:
- Quan 2 mil·lisegons addicionals de latència per a l'enregistrament, que es produeixen constantment en qualsevol producte (ara no parlem de sintètics, els nanosegons es poden mostrar en sintètics), no són crítics, és adequat hiperconvergent.
- Quan la càrrega dels grans servidors físics es pot convertir en molts petits virtuals i distribuir-se entre nodes, la hiperconvergència també funcionarà bé.
- Quan l'escala horitzontal és una prioritat més alta que l'escala vertical, GCS també ho farà bé.
Quines són aquestes solucions?
- Tots els serveis d'infraestructura estàndard (servei de directori, correu, EDMS, servidors de fitxers, petits o mitjans sistemes ERP i BI, etc.). A això anomenem "informàtica general".
- La infraestructura dels proveïdors de núvol, on és necessari expandir horitzontalment de manera ràpida i estandarditzada i "tallar" fàcilment un gran nombre de màquines virtuals per als clients.
- Infraestructura d'escriptori virtual (VDI), on moltes màquines virtuals d'usuaris petites funcionen i "floten" en silenci dins d'un clúster uniforme.
- Xarxes de sucursals, on cada sucursal necessita una infraestructura estàndard, tolerant a errors, però econòmica, de 15-20 màquines virtuals.
- Qualsevol informàtica distribuïda (serveis de big data, per exemple). On la càrrega no va "en profunditat", sinó "en amplada".
- Entorns de prova on s'accepten petits retards addicionals, però hi ha restriccions pressupostàries, perquè són proves.
De moment, és per a aquestes tasques que hem fet AERODISK vAIR i és en elles on ens estem centrant (fins ara amb èxit). Potser això canviarà aviat, perquè... el món no s'atura.
Tan…
Això completa la primera part d'una gran sèrie d'articles; en el següent article parlarem de l'arquitectura de la solució i dels components utilitzats.
Agraïm preguntes, suggeriments i disputes constructives.
Font: www.habr.com