{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"A fost publicat\u0103 versiunea de urgen\u021b\u0103 a serverului de email","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"A<\/p>\n

<\/p>\n

Bun\u0103, cititori ai Habr. Cu acest articol deschidem un ciclu care va vorbi despre sistemul nostru hiperconvergent AERODISK vAIR. Ini\u021bial, am vrut ca prima noastr\u0103 articol s\u0103 fie o prezentare complet\u0103, dar sistemul este destul de complex, a\u0219a c\u0103 vom aborda subiectul pas cu pas. <\/p>\n

<\/p>\n

Vom \u00eencepe povestea cu istoria cre\u0103rii sistemului, vom explora sistemul de fi\u0219iere ARDFS, care st\u0103 la baza vAIR, \u0219i vom discuta pu\u021bin despre pozi\u021bionarea acestei solu\u021bii pe pia\u021ba din Rom\u00e2nia. <\/p>\n

<\/p>\n

\u00cen articolele viitoare, vom detalia diferitele componente arhitecturale (cluster, hypervisor, load balancer, sistem de monitorizare etc.), procesul de configurare, vom aborda \u00eentreb\u0103rile legate de licen\u021biere, vom prezenta teste de stres \u0219i, desigur, vom scrie despre testarea performan\u021bei \u0219i dimensionarea. De asemenea, vom dedica un articol versiunii community a vAIR.<\/p>\n

<\/a><\/noindex><\/p>\n

AERODISK este oare o poveste despre stocare? Sau de ce am \u00eenceput s\u0103 ne ocup\u0103m de hiperconvergen\u021b\u0103?<\/h2>\n

<\/p>\n

Ini\u021bial, ideea de a crea propria solu\u021bie hiperconvergent\u0103 ne-a venit \u00een jurul anului 2010. Atunci nu existau \u00eenc\u0103 AERODISK sau solu\u021bii similare (sisteme hiperconvergente comerciale) pe pia\u021b\u0103. Sarcina noastr\u0103 era urm\u0103toarea: dintr-un set de servere cu discuri locale, interconectate prin protocol Ethernet, trebuia s\u0103 realiz\u0103m un stocare distribuit\u0103 \u0219i s\u0103 rul\u0103m acolo ma\u0219ini virtuale \u0219i o re\u021bea software. Totul trebuia implementat f\u0103r\u0103 solu\u021bii de stocare (deoarece nu aveam buget pentru un astfel de sistem, iar propria solu\u021bie de stocare nu o inventasem \u00eenc\u0103).<\/p>\n

<\/p>\n

Am \u00eencercat multe solu\u021bii open source \u0219i, \u00een cele din urm\u0103, am rezolvat aceast\u0103 sarcin\u0103, dar solu\u021bia a fost foarte complex\u0103 \u0219i greu de reprodus. \u00cen plus, aceast\u0103 solu\u021bie era de tipul \u201eFunc\u021bioneaz\u0103? Nu o atinge!\u201d. Prin urmare, dup\u0103 ce am rezolvat problema, nu am continuat s\u0103 dezvolt\u0103m ideea de a transforma rezultatul muncii noastre \u00eentr-un produs complet. <\/p>\n

<\/p>\n

Dup\u0103 acel incident, am abandonat aceast\u0103 idee, dar ne-a r\u0103mas \u00een minte senza\u021bia c\u0103 aceast\u0103 sarcin\u0103 este complet realizabil\u0103 \u0219i c\u0103 beneficiile unei astfel de solu\u021bii sunt mai mult dec\u00e2t evidente. Ulterior, produsele HCI lansate de companii str\u0103ine au confirmat aceast\u0103 senza\u021bie. <\/p>\n

<\/p>\n

Prin urmare, \u00een mijlocul anului 2016, ne-am \u00eentors la aceast\u0103 sarcin\u0103 \u00een cadrul cre\u0103rii unui produs complet. Atunci nu aveam niciun fel de rela\u021bii cu investitorii, a\u0219a c\u0103 a fost necesar s\u0103 cump\u0103r\u0103m standul de dezvoltare din banii no\u0219tri destul de pu\u021bini. Dup\u0103 ce am c\u0103utat servere second-hand \u0219i switch-uri pe Avito, ne-am apucat de treab\u0103.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Principala sarcin\u0103 ini\u021bial\u0103 a fost s\u0103 cre\u0103m propriul nostru sistem de fi\u0219iere, chiar dac\u0103 simplu, dar care s\u0103 poat\u0103 distribui automat \u0219i uniform datele sub form\u0103 de blocuri virtuale pe un num\u0103r n de noduri ale clusterei, care sunt conectate prin interconectare Ethernet. \u00cen acela\u0219i timp, sistemul de fi\u0219iere trebuie s\u0103 fie bine \u0219i u\u0219or scalabil \u0219i s\u0103 fie independent de sistemele \u00eenvecinate, adic\u0103 s\u0103 fie disociabil de vAIR sub forma unei \u201esimple stoc\u0103ri\u201d.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Prima conceptie vAIR<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Am renun\u021bat inten\u021bionat la utilizarea solu\u021biilor open source gata f\u0103cute pentru organizarea unui depozit distribuit (ceph, gluster, lustre \u0219i similare) \u00een favoarea dezvolt\u0103rii noastre proprii, deoarece aveam deja mult\u0103 experien\u021b\u0103 de proiectare cu ele. F\u0103r\u0103 \u00eendoial\u0103, aceste solu\u021bii sunt excelente \u00een sine, iar p\u00e2n\u0103 la lucr\u0103rile asupra Aerodisc-ului am realizat cu ele nu unul, ci mai multe proiecte de integrare. Dar este un lucru s\u0103 implementezi o sarcin\u0103 specific\u0103 pentru un client, s\u0103 instrui\u021bi personalul \u0219i, poate, s\u0103 cump\u0103ra\u021bi suport de la un mare furnizor, \u0219i cu totul altceva este s\u0103 crea\u021bi un produs u\u0219or reproducibil, care va fi utilizat pentru sarcini diferite, pe care poate nici m\u0103car noi, ca furnizor, nu le vom cunoa\u0219te. Pentru a doua sarcin\u0103, produsele open source existente nu ne-au fost potrivite, a\u0219a c\u0103 am decis s\u0103 ne dezvolt\u0103m noi sistemul de fi\u0219iere distribuit.
\nDup\u0103 doi ani, cu ajutorul c\u00e2torva dezvoltatori (care combinau activitatea pe vAIR cu munca asupra sistemului de stocare clasic Engine) am ob\u021binut un rezultat concret.<\/p>\n

<\/p>\n

P\u00e2n\u0103 \u00een 2018, am scris un sistem de fi\u0219iere simplu \u0219i l-am completat cu leg\u0103turile necesare. Sistemul combina prin interconectarea intern\u0103 discuri fizice (locale) de pe diferite servere \u00eentr-un singur pool plat \u0219i le \u201et\u0103ia\u201d \u00een blocuri virtuale, iar din blocurile virtuale erau create dispozitive bloc cu un anumit grad de rezisten\u021b\u0103 la defec\u021biuni, pe care, cu ajutorul hipervizorului KVM, erau create \u0219i rulate ma\u0219ini virtuale. <\/p>\n

<\/p>\n

Nu ne-am complicat prea mult cu numele sistemului de fi\u0219iere \u0219i l-am numit simplu ARDFS (ghici\u021bi ce \u00eenseamn\u0103))<\/p>\n

<\/p>\n

Acest prototip ar\u0103ta bine (nu vizual, desigur, nu existau \u00eenc\u0103 aspecte vizuale) \u0219i ar\u0103ta rezultate bune \u00een ceea ce prive\u0219te performan\u021ba \u0219i scalabilitatea. Dup\u0103 prima realizare real\u0103, am dat start acestui proiect, organiz\u00e2nd deja un mediu complet de dezvoltare \u0219i o echip\u0103 separat\u0103 care s-a ocupat doar de vAIR.<\/p>\n

<\/p>\n

Exact atunci s-a maturizat arhitectura general\u0103 a solu\u021biei, care nu a suferit modific\u0103ri semnificative p\u00e2n\u0103 \u00een prezent.<\/p>\n

<\/p>\n

S\u0103 ne ad\u00e2ncim \u00een sistemul de fi\u0219iere ARDFS<\/h2>\n

<\/p>\n

ARDFS este baza vAIR, care ofer\u0103 stocare distribuit\u0103 \u0219i tolerant\u0103 la defec\u021biuni a datelor \u00eentregului cluster. Una dintre (dar nu singura) caracteristicile distincte ale ARDFS este c\u0103 nu utilizeaz\u0103 aditivi serverelor dedicate<\/a> sub met\u0103 \u0219i management. A fost g\u00e2ndit\u0103 astfel de la \u00eenceput pentru a simplifica configurarea solu\u021biei \u0219i pentru fiabilitatea acesteia. <\/p>\n

<\/p>\n

Structura de stocare<\/h3>\n

<\/p>\n

\u00cen cadrul tuturor nodurilor clusterului, ARDFS organizeaz\u0103 un pool logic din tot spa\u021biul de stocare disponibil. Este important de \u00een\u021beles c\u0103 un pool nu reprezint\u0103 datele \u0219i nici un spa\u021biu formatat, ci este pur \u0219i simplu o marcare, adic\u0103 orice nod cu vAIR instalat, atunci c\u00e2nd este ad\u0103ugat la cluster, este automat inclus \u00een pool-ul comun ARDFS, iar resursele de stocare devin automat comune pentru \u00eentregul cluster (\u0219i disponibile pentru stocarea viitoare a datelor). Aceast\u0103 abordare permitem ad\u0103ugarea \u0219i eliminarea rapid\u0103 a nodurilor f\u0103r\u0103 a afecta semnificativ sistemul deja func\u021bional. Asta \u00eenseamn\u0103 c\u0103 sistemul este foarte u\u0219or de scalat \u201ecu c\u0103r\u0103mizi\u201d, ad\u0103ug\u00e2nd sau elimin\u00e2nd noduri \u00een cluster dup\u0103 necesitate.<\/p>\n

<\/p>\n

Deasupra pool-ului ARDFS sunt ad\u0103ugate discuri virtuale (obiecte de stocare pentru virtuale), care sunt construite din blocuri virtuale de 4 megabytes. Pe discurile virtuale sunt stocate datele propriu-zise. La nivelul discurilor virtuale se stabile\u0219te de asemenea schema de toleran\u021b\u0103 la defec\u021biuni. <\/p>\n

<\/p>\n

A\u0219a cum a\u021bi putea ghici, pentru rezilien\u021ba subsistemului de stocare, nu folosim conceptul RAID (Redundant array of independent Disks), ci RAIN (Redundant array of independent Nodes). Asta \u00eenseamn\u0103 c\u0103 rezilien\u021ba este m\u0103surat\u0103, automatizat\u0103 \u0219i gestionat\u0103 pe baza nodurilor, nu a discurilor. Desigur, discurile sunt de asemenea obiecte de stocare, ele, la fel ca tot restul, sunt monitorizate \u0219i cu ele se pot efectua toate opera\u021biunile standard, inclusiv construirea unui RAID hardware local, dar clusterul opereaz\u0103 la nivel de noduri. <\/p>\n

<\/p>\n

\u00cen situa\u021bia \u00een care dori\u021bi cu adev\u0103rat RAID (de exemplu, un scenariu care suport\u0103 multiple defec\u021biuni pe clustere mici), nimic nu \u00eempiedic\u0103 utilizarea controlerelor RAID locale, iar deasupra s\u0103 se construiasc\u0103 un stocaj extins \u0219i o arhitectur\u0103 RAIN. Acest scenariu este destul de viabil \u0219i este suportat de noi, a\u0219a c\u0103 vom vorbi despre el \u00een articolul despre scenariile tipice de utilizare a vAIR.<\/p>\n

<\/p>\n

Scheme de rezilien\u021b\u0103 a stoc\u0103rii<\/h3>\n

<\/p>\n

Exist\u0103 dou\u0103 scheme de rezilien\u021b\u0103 a discurilor virtuale \u00een vAIR:<\/p>\n

<\/p>\n

1) Factor de replicare sau pur \u0219i simplu replicare \u2013 aceast\u0103 metod\u0103 de rezilien\u021b\u0103 este simpl\u0103 \u00abca un b\u0103\u021b \u0219i o fr\u00e2nghie\u00bb. Se efectueaz\u0103 replicarea sincron\u0103 \u00eentre noduri cu un factor de 2 (2 copii pe cluster) sau 3 (3 copii, respectiv). RF-2 permite discului virtual s\u0103 reziste la defec\u021biunea unei noduri \u00een cluster, dar \u201econsum\u0103\u201d jum\u0103tate din volumul util, iar RF-3 va rezista la defec\u021bia a 2 noduri \u00een cluster, dar va rezerva deja 2\/3 din volumul util pentru propriile nevoi. Aceast\u0103 schem\u0103 seam\u0103n\u0103 foarte mult cu RAID-1, adic\u0103 discul virtual configurat \u00een RF-2 este rezistent la defec\u021bia oric\u0103rei noduri din cluster. \u00cen acest caz, datele vor fi \u00een regul\u0103 \u0219i chiar intrarea-ie\u0219irea nu se va opri. C\u00e2nd nodul c\u0103zut revine \u00een func\u021biune, va \u00eencepe restaurarea\/sincronizarea automat\u0103 a datelor. <\/p>\n

<\/p>\n

Mai jos sunt exemple de distribu\u021bie a datelor RF-2 \u0219i RF-3 \u00een mod normal \u0219i \u00een situa\u021bii de defec\u021biuni.<\/p>\n

<\/p>\n

Avem o ma\u0219in\u0103 virtual\u0103 cu 8 MB de date unice (utile), care func\u021bioneaz\u0103 pe 4 noduri vAIR. Este clar c\u0103, \u00een realitate, un volum at\u00e2t de mic este pu\u021bin probabil, dar pentru schema care reflect\u0103 logica de func\u021bionare a ARDFS, acest exemplu este cel mai clar. AB - sunt blocuri virtuale de 4 MB con\u021bin\u00e2nd date unice ale ma\u0219inii virtuale. La RF-2, se creeaz\u0103 dou\u0103 copii ale acestor blocuri A1+A2 \u0219i B1+B2, respectiv. Aceste blocuri sunt \u201edistribuite\u201d pe noduri, evit\u00e2nd suprapunerea acelora\u0219i date pe un singur nod, adic\u0103 copia A1 nu va fi pe acela\u0219i nod cu copia A2. La fel pentru B1 \u0219i B2.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

\u00cen cazul \u00een care unul dintre noduri (de exemplu, nodul Nr. 3, unde se afl\u0103 copia B1) e\u0219ueaz\u0103, aceast\u0103 copie se activeaz\u0103 automat pe nodul unde nu exist\u0103 copia sa (adic\u0103 copia B2). <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Astfel, discul virtual (\u0219i VM-ul, respectiv) va face fa\u021b\u0103 cu u\u0219urin\u021b\u0103 e\u0219ecului unui nod \u00een schema RF-2.<\/p>\n

<\/p>\n

Schema cu replicare, \u00een ciuda simplit\u0103\u021bii \u0219i fiabilit\u0103\u021bii sale, sufer\u0103 de aceea\u0219i problem\u0103 ca \u0219i RAID1 - pu\u021bin spa\u021biu util.<\/p>\n

<\/p>\n

2) Codificarea erorilor sau codificarea de \u0219tergere (cunoscut\u0103 \u0219i sub numele de \u201ecodificare redundant\u0103\u201d, \u201ecodificare de \u0219tergere\u201d sau \u201ecod de redundan\u021b\u0103\u201d) exist\u0103 tocmai pentru a rezolva problema de mai sus. EC - este o schem\u0103 de redundan\u021b\u0103 care asigur\u0103 o disponibilitate ridicat\u0103 a datelor, cu cheltuieli mai mici de spa\u021biu pe disc comparativ cu replicarea. Principiul de func\u021bionare al acestui mecanism este similar cu RAID 5, 6, 6P. <\/p>\n

<\/p>\n

\u00cen timpul codific\u0103rii, procesul EC \u00eemparte un bloc virtual (\u00een mod implicit 4 MB) \u00een mai multe \u201ebuc\u0103\u021bi de date\u201d mai mici, \u00een func\u021bie de schema EC (de exemplu, schema 2+1 \u00eemparte fiecare bloc de 4 MB \u00een 2 buc\u0103\u021bi de 2 MB). \u00cen plus, acest proces genereaz\u0103 pentru \u201ebuc\u0103\u021bile de date\u201d \u201ebuc\u0103\u021bi de paritate\u201d de dimensiune maxim\u0103 egal\u0103 cu una dintre p\u0103r\u021bile anterior \u00eemp\u0103r\u021bite. La decodare, EC genereaz\u0103 buc\u0103\u021bile lips\u0103 citind datele \u201esupravie\u021buitoare\u201d din \u00eentregul cluster. <\/p>\n

<\/p>\n

De exemplu, un disc virtual cu schema EC 2 + 1, implementat pe 4 noduri ale clusterului, va face fa\u021b\u0103 cu u\u0219urin\u021b\u0103 e\u0219ecului unui nod din cluster, la fel ca \u0219i RF-2. \u00cen acela\u0219i timp, cheltuielile vor fi mai mici, \u00een special coeficientul de utilizare util\u0103 la RF-2 este 2, iar la EC 2+1 va fi 1,5. <\/p>\n

<\/p>\n

Pentru a explica mai simplu, esen\u021ba const\u0103 \u00een faptul c\u0103 un bloc virtual este \u00eemp\u0103r\u021bit \u00een 2-8 (de ce de la 2 la 8, vezi mai jos) \u201ebuc\u0103\u021bi\u201d, iar pentru aceste buc\u0103\u021bi se calculeaz\u0103 \u201ebuc\u0103\u021bi\u201d de paritate de volum similar. <\/p>\n

<\/p>\n

\u00cen final, datele \u0219i paritatea sunt distribuite uniform pe toate nodurile clusterului. Totodat\u0103, ca \u0219i \u00een cazul replic\u0103rii, ARDFS distribuie automat datele pe noduri \u00eentr-un mod care s\u0103 previn\u0103 stocarea acelora\u0219i date (copia datelor \u0219i paritatea acestora) pe un singur nod, pentru a excluede riscul de pierdere a datelor din cauza faptului c\u0103 datele \u0219i paritatea lor se afl\u0103 brusc pe un singur nod de stocare care ar putea s\u0103 se defecteze. <\/p>\n

<\/p>\n

Mai jos este un exemplu, folosind aceea\u0219i ma\u0219in\u0103 virtual\u0103 de 8 MB \u0219i 4 noduri, dar deja cu schema EC 2+1. <\/p>\n

<\/p>\n

Blocurile A \u0219i B sunt \u00eemp\u0103r\u021bite \u00een c\u00e2te dou\u0103 piese de 2 MB fiecare (\u00een dou\u0103 deoarece 2+1), adic\u0103 \u00een A1+A2 \u0219i B1+B2. Spre deosebire de replicat, A1 nu este o copie a A2, este un bloc virtual A, \u00eemp\u0103r\u021bit \u00een dou\u0103 p\u0103r\u021bi, la fel \u0219i blocul B. \u00cen total, ob\u021binem dou\u0103 seturi de c\u00e2te 4 MB, fiecare con\u021bin\u00e2nd c\u00e2te dou\u0103 piese de c\u00e2te 2 MB. Apoi, pentru fiecare dintre aceste seturi se calculeaz\u0103 paritatea cu o dimensiune de maximum o pies\u0103 (adic\u0103 2 MB), astfel ob\u021binem suplimentar + 2 piese de paritate (A-P \u0219i B-P). \u00cen total avem 4\u00d72 date + 2\u00d72 paritate.<\/p>\n

<\/p>\n

Apoi, buc\u0103\u021bile sunt \u201e\u00eempr\u0103\u0219tiate\u201d pe noduri astfel \u00eenc\u00e2t datele s\u0103 nu se intersecteze cu paritatea lor. Adic\u0103 A1 \u0219i A2 nu vor coexista pe acela\u0219i nod cu A-P.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

\u00cen cazul unei defec\u021biuni a unui nod (s\u0103 zicem, al treilea), blocul c\u0103zut B1 va fi restaurat automat din paritatea B-P, care este stocat\u0103 pe nodul nr. 2, \u0219i va fi activat pe nodul unde nu exist\u0103 paritatea B, adic\u0103 B-P. \u00cen acest exemplu, acesta este nodul nr. 1.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Sunt sigur c\u0103 cititorului \u00eei apare \u00eentrebarea:<\/p>\n

<\/p>\n

\u201eTot ce a\u021bi descris este deja implementat de concuren\u021bi \u0219i \u00een solu\u021bii open source, care este diferen\u021ba implement\u0103rii dvs. EC \u00een ARDFS?\u201d<\/p><\/blockquote>\n

Apoi, vor urma tr\u0103s\u0103turi interesante ale func\u021bion\u0103rii ARDFS.<\/p>\n

<\/p>\n

Codificarea erorilor cu un accent pe flexibilitate<\/h3>\n

<\/p>\n

Ini\u021bial, am prev\u0103zut un sistem EC X+Y destul de flexibil, unde X este un num\u0103r de la 2 la 8, iar Y este un num\u0103r de la 1 la 8, dar \u00eentotdeauna mai mic sau egal cu X. Acest sistem este destinat flexibilit\u0103\u021bii. Cre\u0219terea num\u0103rului de buc\u0103\u021bi de date (X) \u00een care se \u00eemparte un blok virtual permite reducerea costurilor generale, adic\u0103 cre\u0219terea spa\u021biului util.
\nCre\u0219terea num\u0103rului de buc\u0103\u021bi de paritate (Y) cre\u0219te fiabilitatea discului virtual. Cu c\u00e2t valoarea lui Y este mai mare, cu at\u00e2t mai multe noduri din cluster pot ie\u0219i din func\u021biune. Evident, cre\u0219terea volumului de paritate reduce capacitatea util\u0103, dar acestea sunt costurile pentru fiabilitate. <\/p>\n

<\/p>\n

Dependen\u021ba performan\u021bei de schemele EC este aproape direct\u0103: cu c\u00e2t sunt mai multe \u201ebuc\u0103\u021bi\u201d, cu at\u00e2t performan\u021ba este mai sc\u0103zut\u0103; aici, este evident c\u0103 este nevoie de o viziune echilibrat\u0103. <\/p>\n

<\/p>\n

Aceast\u0103 abordare le permite administratorilor s\u0103 configureze \u00een mod flexibil stocarea extins\u0103. \u00cen cadrul grupului ARDFS se pot folosi orice scheme de redundan\u021b\u0103 \u0219i combina\u021biile acestora, ceea ce, de asemenea, consider\u0103m foarte util. <\/p>\n

<\/p>\n

Mai jos se afl\u0103 un tabel de comparare a mai multor scheme RF \u0219i EC (dar nu toate posibile).<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Din tabel se poate observa c\u0103 chiar \u0219i cea mai \u201eextrem\u0103\u201d combina\u021bie EC 8+7, care permite pierderea simultan\u0103 a p\u00e2n\u0103 la 7 noduri din cluster, \u201econsum\u0103\u201d mai pu\u021bin spa\u021biu util (1,875 fa\u021b\u0103 de 2) dec\u00e2t replicarea standard, dar protejeaz\u0103 de 7 ori mai bine, ceea ce face ca acest mecanism de protec\u021bie s\u0103 fie, de\u0219i mai complex, semnificativ mai atractiv \u00een situa\u021biile \u00een care trebuie asigurat\u0103 o fiabilitate maxim\u0103 \u00een condi\u021bii de spa\u021biu de stocare insuficient. \u00cen acela\u0219i timp, trebuie \u00een\u021beles c\u0103 fiecare \u201eplus\u201d la X sau Y va reprezenta un cost suplimentar pentru performan\u021b\u0103, a\u0219a c\u0103 \u00een triunghiul dintre fiabilitate, economisire \u0219i performan\u021b\u0103, trebuie s\u0103 alegi cu foarte mare aten\u021bie. Din acest motiv, o articol\u0103 separat\u0103 va fi dedicat\u0103 dimension\u0103rii codific\u0103rii de \u00eendep\u0103rtare.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Fiabilitatea \u0219i autonomia sistemului de fi\u0219iere<\/h3>\n

<\/p>\n

ARDFS ruleaz\u0103 local pe toate nodurile clusterului \u0219i le sincronizeaz\u0103 prin propriile sale mijloace prin intermediul unor interfe\u021be Ethernet dedicate. Un aspect important este c\u0103 ARDFS sincronizeaz\u0103 nu doar datele, ci \u0219i meta-datele aferente stoc\u0103rii. \u00cen cursul lucr\u0103rilor la ARDFS, am studiat \u00een paralel o serie de solu\u021bii existente \u0219i am descoperit c\u0103 multe sincronizeaz\u0103 meta-datele sistemului de fi\u0219iere printr-o DB distribuit\u0103 extern\u0103, pe care o folosim \u0219i noi pentru sincronizare, dar doar a configura\u021biilor, nu a meta-datelor FS (despre aceasta \u0219i alte subsisteme conexe \u00een articolul urm\u0103tor). <\/p>\n

<\/p>\n

Sincronizarea metadatelor FS cu ajutorul unei SGBD externe este, desigur, o solu\u021bie func\u021bional\u0103, dar atunci consisten\u021ba datelor stocate pe ARDFS ar depinde de SGBD-ul extern \u0219i comportamentul s\u0103u (iar acesta, s\u0103 fim sinceri, este destul de capricios), ceea ce, \u00een opinia noastr\u0103, este un aspect negativ. De ce? Dac\u0103 metadatele FS se vor deteriora, datele FS ar trebui, de asemenea, s\u0103 spun\u0103 \u201eadio\u201d, a\u0219a c\u0103 am decis s\u0103 opt\u0103m pentru o cale mai complex\u0103, dar mai sigur\u0103. <\/p>\n

<\/p>\n

Subsystema de sincronizare a metadatelor pentru ARDFS a fost realizat\u0103 de noi, tr\u0103ind complet independent de subsistemele \u00eenvecinate. Adic\u0103, niciun alt subsistem nu poate afecta datele ARDFS. \u00cen opinia noastr\u0103, aceasta este cea mai sigur\u0103 \u0219i corect\u0103 cale, iar dac\u0103 este sau nu a\u0219a, timpul va ar\u0103ta. \u00cen plus, cu aceast\u0103 abordare apare un avantaj suplimentar. ARDFS poate fi utilizat independent de vAIR, pur \u0219i simplu ca un depozit extins, ceea ce cu siguran\u021b\u0103 vom folosi \u00een produsele viitoare.<\/p>\n

<\/p>\n

\u00cen cele din urm\u0103, dezvolt\u00e2nd ARDFS, am ob\u021binut un sistem de fi\u0219iere flexibil \u0219i fiabil, care ofer\u0103 op\u021biuni pentru economisirea capacit\u0103\u021bii sau maximizarea performan\u021bei sau pentru a crea un stocaj extrem de fiabil la un cost moderat, dar cu cerin\u021be mai pu\u021bin exigente \u00een ceea ce prive\u0219te performan\u021ba. <\/p>\n

<\/p>\n

\u00cempreun\u0103 cu o politic\u0103 de licen\u021biere simpl\u0103 \u0219i un model de livrare flexibil (pentru a anticipa, licen\u021ba vAIR este bazat\u0103 pe noduri, iar livrarea se face fie prin software, fie ca PAK), acest lucru permite o adaptare foarte precis\u0103 a solu\u021biei la cele mai diverse cerin\u021be ale clien\u021bilor \u0219i, ulterior, \u00eentre\u021binerea u\u0219oar\u0103 a acestui echilibru. <\/p>\n

<\/p>\n

Cui \u00eei trebuie aceast\u0103 minune?<\/h2>\n

<\/p>\n

Pe de o parte, s-ar putea spune c\u0103 pe pia\u021b\u0103 exist\u0103 deja juc\u0103tori cu solu\u021bii serioase \u00een domeniul hiperconvergent \u0219i de ce ne-am b\u0103ga, de fapt, aici. Se pare c\u0103 aceast\u0103 afirma\u021bie este adev\u0103rat\u0103, DAR...<\/p>\n

<\/p>\n

Pe de alt\u0103 parte, ie\u0219ind \u201e\u00een teren\u201d \u0219i discut\u00e2nd cu clien\u021bii, noi \u0219i partenerii no\u0219tri vedem c\u0103 lucrurile nu stau deloc a\u0219a. Exist\u0103 multe sarcini pentru hiperconvergent, \u00een unele cazuri oamenii pur \u0219i simplu nu \u0219tiau c\u0103 astfel de solu\u021bii exist\u0103, \u00een alte cazuri p\u0103rea prea scump, \u00een alte cazuri au fost teste nereu\u0219ite ale solu\u021biilor alternative, iar \u00een alte cazuri cump\u0103rarea este pur \u0219i simplu interzis\u0103 din cauza sanc\u021biunilor. \u00cen general, c\u00e2mpul s-a dovedit a fi neexploatat, a\u0219a c\u0103 am decis s\u0103 cultiv\u0103m p\u0103m\u00e2ntul neexploatat))). <\/p>\n

<\/p>\n

C\u00e2nd este un SCD mai bun dec\u00e2t un GKS?<\/h3>\n

<\/p>\n

\u00cen activitatea noastr\u0103 pe pia\u021b\u0103, suntem frecvent \u00eentreba\u021bi c\u00e2nd ar trebui s\u0103 utiliz\u0103m schema clasic\u0103 cu stocare ierarhic\u0103 \u0219i c\u00e2nd ar trebui s\u0103 ne \u00eendrept\u0103m c\u0103tre solu\u021bii hiperconvergente? Multe companii produc\u0103toare de GKS (\u00een special cele care nu au stocare ierarhic\u0103 \u00een portofoliu) afirm\u0103: \u201eStocarea ierarhic\u0103 ajunge la final, numai hiperconvergent!\u201d. Aceasta este o afirma\u021bie \u00eendr\u0103znea\u021b\u0103, dar nu reflect\u0103 complet realitatea. <\/p>\n

<\/p>\n

Adev\u0103rul este c\u0103 pia\u021ba stoc\u0103rii ierarhice migreaz\u0103 cu adev\u0103rat c\u0103tre solu\u021bii hiperconvergente, dar exist\u0103 \u00eentotdeauna un \u201edar\u201d.<\/p>\n

<\/p>\n

\u00cen primul r\u00e2nd, centrele de date \u0219i infrastructurile IT construite pe schem\u0103 clasic\u0103 cu stocare ierarhic\u0103 nu pot fi transformate at\u00e2t de u\u0219or, a\u0219adar modernizarea \u0219i completarea acestor infrastructuri va reprezenta \u00eenc\u0103 un mo\u0219tenire de 5-7 ani.<\/p>\n

<\/p>\n

\u00cen al doilea r\u00e2nd, infrastructurile care sunt construite \u00een prezent \u00een mas\u0103 (aici ne referim la Federa\u021bia Rus\u0103) sunt, \u00een principal, bazate pe schema clasic\u0103 cu stocare ierarhic\u0103, \u0219i nu din cauza c\u0103 oamenii nu sunt con\u0219tien\u021bi de solu\u021biile hiperconvergente, ci pentru c\u0103 pia\u021ba solu\u021biilor hiperconvergente este nou\u0103, solu\u021biile \u0219i standardele nu s-au stabilit \u00eenc\u0103, speciali\u0219tii IT nu sunt \u00eenc\u0103 instrui\u021bi, experien\u021ba este limitat\u0103, iar centrele de date trebuie construite imediat. Aceast\u0103 tendin\u021b\u0103 va continua \u00eenc\u0103 3-5 ani (\u0219i apoi va reprezenta din nou o mo\u0219tenire, vezi punctul 1).<\/p>\n

<\/p>\n

\u00cen al treilea r\u00e2nd, exist\u0103 o limitare tehnic\u0103 pur\u0103 \u00een \u00eent\u00e2rzierile suplimentare de 2 milisecunde la scriere (f\u0103r\u0103 a lua \u00een considerare memoria cache local\u0103, desigur), ce reprezint\u0103 pre\u021bul pl\u0103tit pentru stocarea distribuit\u0103. <\/p>\n

<\/p>\n

\u0218i s\u0103 nu uit\u0103m de utilizarea serverelor fizice mari, care prefer\u0103 scalarea vertical\u0103 a subsistemului de stocare.<\/p>\n

<\/p>\n

Exist\u0103 multe sarcini necesare \u0219i populare \u00een care stocarea ierarhic\u0103 se comport\u0103 mai bine dec\u00e2t solu\u021biile hiperconvergente. C\u0103 sunt de alt\u0103 opinie cei care nu au stocare ierarhic\u0103 \u00een portofoliu, este de \u00een\u021beles, dar suntem preg\u0103ti\u021bi s\u0103 argument\u0103m. Bine\u00een\u021beles, noi, ca dezvoltatori ai ambelor produse, vom realiza \u00een viitor o compara\u021bie \u00eentre stocarea ierarhic\u0103 \u0219i GKS, unde vom demonstra clar condi\u021biile \u00een care fiecare solu\u021bie este superioar\u0103.<\/p>\n

<\/p>\n

Unde vor func\u021biona mai bine solu\u021biile hiperconvergente dec\u00e2t stocarea ierarhic\u0103?<\/h3>\n

<\/p>\n

Pe baza tezelor de mai sus, se pot trasa trei concluzii evidente: <\/p>\n

<\/p>\n

    \n
  1. Acolo unde \u00eent\u00e2rzierile suplimentare de 2 milisecunde la scriere, care apar constant \u00een orice mediu de produc\u021bie (aici nu se discut\u0103 despre mediul sintetic, unde se pot ob\u021bine nano-seconds), sunt necritice, solu\u021biile hiperconvergente vor fi potrivite.<\/li>\n
  2. Acolo unde sarcina de pe serverele fizice mari poate fi transformat\u0103 \u00een mai multe servere virtuale mai mici \u0219i distribuit\u0103 pe noduri, hiperconvergen\u021ba se va integra bine.<\/li>\n
  3. Acolo unde scalarea orizontal\u0103 este mai prioritar\u0103 dec\u00e2t scalarea vertical\u0103, hiperconvergen\u021ba va fi foarte binevenit\u0103.<\/li>\n<\/ol>\n

    <\/p>\n

    Ce solu\u021bii sunt acestea?<\/h3>\n

    <\/p>\n

      \n
    1. Toate serviciile standard de infrastructur\u0103 (serviciul de director, po\u0219t\u0103, Sistem de Management al Documentelor, servere de fi\u0219iere, sisteme ERP \u0219i BI mici sau medii etc.). Noi le numim \u00abcalcul comun\u00bb. <\/li>\n
    2. Infrastructura furnizorilor de cloud, unde este necesar\u0103 extinderea rapid\u0103 \u0219i standardizat\u0103 orizontal \u0219i u\u0219or \u00abt\u0103ierea\u00bb unui num\u0103r mare de ma\u0219ini virtuale pentru clien\u021bi.<\/li>\n
    3. Infrastructur\u0103 birouri virtuale<\/a> (VDI), unde multe ma\u0219ini virtuale utilizator se activeaz\u0103 \u0219i \u00abnavigheaz\u0103\u00bb \u00een lini\u0219te \u00een interiorul unui cluster uniform.<\/li>\n
    4. Re\u021belele filialelor, unde \u00een fiecare filial\u0103 este necesar\u0103 o infrastructur\u0103 standard, tolerant\u0103 la defec\u021biuni, dar \u00een acela\u0219i timp ieftin\u0103, format\u0103 din 15-20 de ma\u0219ini virtuale.<\/li>\n
    5. Orice calcul distribuit (servicii big data, de exemplu). Acolo unde sarcina nu merge \u00ab\u00een ad\u00e2ncime\u00bb, ci \u00ab\u00een l\u0103\u021bime\u00bb. <\/li>\n
    6. Mediile de testare, unde \u00eent\u00e2rzierile suplimentare sunt acceptabile, dar exist\u0103 limit\u0103ri bugetare, deoarece sunt teste.<\/li>\n<\/ol>\n

      <\/p>\n

      \u00cen prezent, pentru aceste sarcini am creat AERODISK vAIR \u0219i ne concentr\u0103m pe acestea (deocamdat\u0103 cu succes). Este posibil s\u0103 se schimbe \u00een cur\u00e2nd, deoarece lumea nu st\u0103 pe loc.<\/p>\n

      <\/p>\n

      A\u0219adar...<\/h3>\n

      <\/p>\n

      Aici se \u00eencheie prima parte a unui mare ciclu de articole, \u00een urm\u0103torul articol vom vorbi despre arhitectura solu\u021biei \u0219i componentele utilizate.<\/p>\n

      <\/p>\n

      Vom fi bucuro\u0219i s\u0103 primim \u00eentreb\u0103ri, sugestii \u0219i dispute constructive.<\/p>\n

      Sursa: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Solu\u021bia hiperconvergent\u0103 AERODISK vAIR. Baza \u2013 sistemul de fi\u0219iere ARDFS | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}