Acest articol are ca subiect sistemul de stocare care se pretează cel mai bine într-un centru de calcul. Înainte de a prezenta considerațiile privitoare la selecția sistemului de fișiere pentru un centru de calcul, vom realiza o scurtă clasificare și istorie a sistemelor de fișiere.
Sistemele de fișiere se împart în două categorii, în funcție de localizarea lor:
A. Sisteme de fișiere locale - de obicei aceste sisteme rezidă pe un dispozitiv local:
B. Sisteme de fișiere pe rețea (nu le voi enumera pe toate, ci voi da doar câteva exemple, în ordinea evoluției, pentru a ilustra arhitecturile și conceptele ce le au în comun și care stau la baza funcționării lor):
Istoric, calculatoarele erau sisteme izolate a căror arhitectură consta în: Procesor, Memorie și Periferice. Între Periferice, mediul de stocare a evoluat de la un mediu de pe care se poate doar citi la un mediu pe care sistemul poate să și scrie.
Evoluția sistemelor de stocare locale a fost în linii mari următoarea:
A urmat revoluția rețelelor, când a apărut nevoia de a transfera fișiere fără a duce fizic un suport de date (discheta) de la un sistem la altul, în special în scopul comunicării în timp real.
Astfel a apărut ideea de „model server - client” în care un sistem care deținea o resursă (de exemplu un fișier) putea să o pună la dispoziția altor sisteme folosind un limbaj de comunicare (protocol) printr-un canal de comunicație (rețeaua); acest sistem joacă rolul de „server” (sau servitor, pentru că servește resurse). Un sistem de calcul care are nevoie de o resursă (clientul) ce se găsește pe un alt sistem, poate contacta sistemul de la distanță (serverul) prin canalul de comunicație (rețeaua), folosind un limbaj de comunicare (protocolul) pe care ambele sisteme îl înțeleg (exemple de protocoale: FTP sau HTTP sau IMAP din enumerarea de mai sus; „P” în aceste nume provine de la cuvântul „protocol”). O teorie frumoasă.
Problemele practice întâmpinate în scenariul de mai sus sunt următoarele (în cazul în care acestora li se găsesc soluții, rezolvarea lor este notată cu R):
Din lista de mai sus se observă că cel mai mic multiplu comun când vine vorba despre reziliență la „catastrofe” este tipul de stocare pe rețea „c” - cu acest tip de stocare rezolvăm cele mai multe probleme.
În ceea ce privește protecția datelor, companiile care vând soluții de stocare s-au axat pe stocarea locală și au creat matrici de discuri (RAID = Redundant Array of Inexpensive Disks) în diferite formații:
Aceste soluții oferă o oarecare protecție câteodată, altădată viteză, dar nu rezolvă probleme ce pot apărea la alte componente ale sistemului: procesor, memorie, placă de bază, placă de rețea, dorința imperioasă a administratorului de a opri sistemul, etc.
Prima soluție de a oferi disponibilitate sporită (high availability) a serverelor de fișiere a fost aceea de a crea RAID1 prin rețea. Astfel a apărut DRBD, care simulează un mediu de stocare ce are ca motor discurile locale a două servere pereche. Aceste două servere țin fișierele sincronizate, pot accesa sistemul de fișiere simulat și îl pot pune la dispoziția clienților din rețea folosind un protocol standard (CIFS, NFS, rsync, etc.). Pentru a obține disponibilitate sporită, sistemul de fișiere e accesat prin rețea printr-o „adresă IP de serviciu”, care e mutată de pe un server pe celălalt manual sau automat. Astfel un server este considerat „activ”, iar celălalt e „în așteptare”. Problema este că sistemul de fișiere poate fi extins anevoios: se oprește câte un server, se mărește spațiul pe primul, se copiază datele de pe al doilea, se mărește spațiul pe al doilea, se recreează replicarea. O altă problemă este costul: pentru a obține o „instanță server” disponibilă pentru client se dublează capacitatea de calcul, cu costurile aferente, fără a se obține un beneficiu continuu. Beneficiul apare doar în momentul când unul din servere devine inoperabil, ceea ce practic reprezintă aproximativ 0% din durata de viață a sistemului. În unele cazuri aceste costuri sunt justificate (când datele și accesul neîntrerupt la ele este vital - de exemplu la sistemele de menținere a vieții).
Aceeași problemă o au toate sistemele care replică datele la nivel de bloc. De asemenea, faptul că replică la nivel de bloc de date înseamnă că spațiul pe care îl va utiliza trebuie prealocat, ceea ce conduce la un management ineficient din partea administratorului: cât spațiu să se aloce, achiziția de servere noi, identice, care să ofere suficient spațiu de la început (nu se pot folosi servere care deja există în centrul de calcul), timp de indisponibilitate a sistemului (până când este reconfigurat spațiul de stocare și este reinstalat serverul). Dacă se reconfigurează un server mai vechi, intervine și migrarea vechilor date în altă parte.
În încheierea introducerii doresc să fac o paranteză la adresa capitalismului și a consumerismului: mulți programatori și administratori de sisteme se plâng de faptul că firma la care lucrează le face viața grea încercând să folosească servere vechi, deja existente, în loc să investească bani în utilaje noi, de ultimă oră. Aceasta denotă o lene sau o inabilitate a administratorului sau programatorului în a face planurile necesare pentru reutilizarea sistemelor sau pentru optimizarea codului.
Bineînțeles, cu bani oricine poate face orice. Arta adevărată e să poți obține profit cu cea mai mică investiție posibilă. Cu cât profitul este mai mare, cu atât angajații, nu companii externe, care vând sisteme noi, programe sau consultanță se bucură de acel profit. De aceea, Google, Facebook și alte firme de succes nu doar că își scriu propriile programe și folosesc programe gratuite, ci își și proiectează sistemele fizice și centrele de calcul și le comandă direct la producătorii originali de echipamente din China (OEM - Original Equipment Manufacturers).
Cu cât munca unui angajat poate fi externalizată (outsourced) mai ușor, cu atât valorează mai puțin. Valoarea unei companii constă în calitatea muncii angajaților ei, care se măsoară în profit minus cheltuială, nicidecum în bunurile pe care le achiziționează. Altfel, o companie poate avea activitățile total externalizate și ar deveni fond de investiții.
Deși în urma unui vot noi folosim momentan GlusterFS, voi prezenta o soluție pe care am testat-o timp de 3 ani: MooseFS. În articolul trecut menționam faptul că am început să folosim XtreemFS. Arhitectura acelui sistem de fișiere părea la prima vedere una interesantă, fără nici un punct de slăbiciune la catastrofe (no single point of failure). Între timp am aflat că nu este suficient de extensibil în ceea ce-i privește componentele - serviciul de replici și metadate (MRC) și servicul director (DIR), iar autorii doresc să îl distribuie doar ca binar în viitor, ceea ce este ortogonal cu principiile enunțate la sfârșitul introducerii.
Inițial am studiat toate variantele de sisteme de fișiere de rețea, documentâdu-mă din experiențele altora și înțelegând funcționarea teoretică a fiecărui sistem de fișiere în parte. Ca urmare a acestui proces, am ales pentru intenția de testare practică două sisteme: Lustre și MooseFS. Când un arhitect al infrastructurii decide asupra tehnologiei ce se va folosi în companie, mare parte a timpului trebuie petrecută asupra documentației și stabilirii de liste pro și contra pentru fiecare soluție, atât din punct de vedere tehnic (observând exact facilitățile oferite), cât și din punct de vedere al costurilor financiare și de timp de implementare.
În ceea ce privește vechimea pe piață și popularitatea soluției, acestea sunt subiecte critice care trebuie dezbătute atent pentru a nu trage concluzii greșite. Un sistem care există de mult timp pe piață este categoric mai popular decât un sistem mai nou, deoarece a avut timp să fie adoptat cât încă cel nou nu exista. Pentru a face o comparație corectă, echitabilă, trebuie să se calculeze o statistică estimată pentru noul sistem pentru același număr de ani pe care îl are sistemul vechi, la rata de adopție (creștere) comparată pentru perioada de viață a sistemului nou.
De exemplu, dacă ar fi să comparăm GlusterFS și MooseFS, am face următorul calcul. Presupunând că GlusterFS este de zece ani pe piață, iar MooseFS de doi ani, privim la rata de creștere a MooseFS în primii doi ani și estimăm creșterea pentru următorii zce ani folosind rata din primii doi ani. Apoi comparăm creșterea MooseFS estimată pe zece ani cu cea existentă pe zece ani a GlusterFS.
Un sistem nou care este distribuit gratuit nu apare pentru că un programator s-a gândit că nu are cu ce să-și piardă nopțile. Acel programator a investigat piața soluțiilor gratuite și nu a găsit ceva satisfăcător. Probabil a investigat chiar și piața soluțiilor comerciale. Decizia de a scrie de la zero un program distribuit gratuit nu se ia ușor. Mai ales când este vorba un sistem de fișiere care are ca public țintă tocmai organizațiile a căror funcționare se bazează pe acele date, inclusiv organizația din care face parte programatorul. Iar dacă un proiect atrage mulți contribuitori și soluția este adoptată în medii de afaceri și academice în detrimentul altor soluții, avem dovada că acel sistem nou este superior celui vechi și în timp îl va înlocui, acolo unde este posibil.
Exită mitul, că sistemele vechi sunt mai stabile și mai de încredere decât cele noi. Într-adevăr se poate întâmpla ca sistemele vechi să conțină mai puține defecte (bug-uri), dar e important de luat în considerare faptul că și un sistem vechi care e încă în dezvoltare continuă să acumuleze defecte. Nu există o metodă de a demonstra matematic că un sistem mai are sau nu defecte sau că are mai multe sau mai puține decât un alt sistem de orice vârstă. Un sistem utilizat de organizații în producție de mai mulți ani (chiar și de un an), poate fi considerat la fel de stabil și de încredere ca și unul vechi. Pe de altă parte, despre un sistem vechi se știe că are defecte arhitecturale ireparabile care au dus la crearea de sisteme noi. În concluzie, cel mai înțelept din partea arhitectului de sisteme este să ia o soluție cât mai nouă, marcată ca și stabilă și utilizată în producție de alte organizații. Totodată, administratorul de sisteme trebuie să își asume resposabilitatea de a contribui la proiectele care au produs programele utilizate prin corectarea sau măcar raportarea erorilor către producători. O altă responsabilitate a administratorului de sisteme este aceea de a proteja datele organizației împotriva pierderii sau deteriorării. (Nu vom vorbi aici despre protecția împotriva furtului, deoarece subiectul articolului este stocarea datelor, nu securitatea lor.) Administratorul trebuie să ateste organizației că responsabilitatea este a lui și nu trebuie externalizată altei companii. Orice program are defecte, iar administratorul este cel ce are responsabilitatea pentru aceste defecte.
Lustre este folosit în mediile academice și de cercetare unde este nevoie să se prelucreze o cantitate imensă de date folosind supercalculatoare. Sistemul este testat și folosit de supercalculatoarele din top 500 mondial. Administratorii de sisteme de acolo sunt vârful inteligenței în domeniu, iar pe deciziile lor se pot baza administratorii din companii private. În momentul în care am luat decizia de a testa Lustre (2011) am aflat că nu suportă versiuni noi de nucleu de Linux (avea nevoie de un nucleu versiunea 2.6.18, modificat) - care nu era compatibil cu cerințele de drivere și de performanță din compania noastră. În anul următor, Intel a cumpărat Lustre și a promis suport pentru versiunea 3.0 a nucleului, totodată redenumindu-l în Whamcloud. Promisiunea nu s-a materializat, însă varianta dezvoltată de comunitate a Lustre a evoluat, iar în acest an clientul se găsește în nucleul de Linux.
Totuși noi aveam nevoie în 2011 de ceva. Următorul pe listă, care oferea cele mai multe facilități, iar arhitectura era rezilientă la catastrofe a fost MooseFS. MooseFS are două probleme:
Arhitectura MooseFS permite extinderea sistemului de fișiere pe toate serverele din centrul de calcul. MooseFS creează pe sistemele pe care le folosește o structură de fișiere numită „fișiere de date”, într-un mod asemănător cu baza de date Oracle.
În aceste fișiere de date, MooseFS stochează fișierele propriu-zise după un algoritm intern: prima dată împarte fișierele primite de la clienți în bucăți de mărime variabilă de maxim 64MB (chunks), apoi distribuie și clonează aceste bucăți pe mai multe servere (denumite noduri sau chunkservers). Fiecare fișier primit de la clienți spre a fi stocat, are asociat o țintă de multiplicare, denumită „goal”, care reprezintă numărul de copii ale acelui fișier în sistemul de fișiere MooseFS. Copiile sunt stocate pe noduri diferite, astfel că dacă un fișier trebuie să aibă două copii și un nod ce conține una din copii devine indisponibil, fișierul este încă accesibil pe celălalt nod. Desigur, un fișier poate avea oricâte copii, distribuite pe oricâte noduri, nu doar două.
Poziționarea fișierelor este memorată pe nodul „master” al cărui rol este de a arbitra distribuția și clonarea bucăților de fișier. Master reține informațiile despre fișiere într-un fișier: metadata.mfs. În afară de acest fișier, el creează și niște fișiere de loguri cu toate tranzacțiile ce au avut loc, astfel încât fișierul metadata.mfs poate fi recreat din aceste loguri, dacă se corupe. În afară de logurile locale, pentru a asigura recuperarea fișierelor în cazul dezastrelor ce îl pot afecta, master trimite în fiecare oră o copie a metadata.mfs și a fișierelor de loguri către un alt tip de nod din infrastructura MooseFS: nodul metalogger. Pe acest nod ajunge atât metadata.mfs cât și o copie a logurilor de tranzacții create de master. Oricând un server metalogger poate deveni master, folosind copiile sale locale ale metadata.mfs și logurilor. În arhitectura MooseFS pot exista oricâte noduri chunk, oricâte noduri metalogger, dar doar un nod master.
Clienții accesează MooseFS contactând nodul master, care îi redirecționează spre serverele de stocare (chunkservers), unde au loc operațiile de copiere. Deci copierea nu se desfășoară între clienți și master, ci între clienți și serverele de stocare, ceea ce înseamnă că transferurile au loc între toate serverele din centrul de calcul, cu viteză sporită.
Din arhitectura MooseFS decurge o aplicație interesantă: Putem avea un sistem de fișiere distribuit, performant și cu reziliență la indisponibilitatea nodurilor folosind toate sistemele din rețea. Aceasta nu se aplică doar la centrul de date, ci și la un birou tipic, unde există sute de stații cu spațiu liber pe discuri, nefolosit. Astfel, angajații din birou vor stoca fișiere „pe rețea” la propriu, nu pe un server dedicat, scump, care poate deveni indisponibil sau plin sau pe care administratorii trebuie să-l îngrijească.
Un ochi de administrator versat face imediat observația: dar discurile vor fi umplute?
Nu: MooseFS ține cont de gradul de umplere al discurilor pe care le folosește (nu doar în ceea ce-l privește, dar și cu datele pe care sistemul le stochează pe acel disc în afara MooseFS). MooseFS va încerca să egalizeze procentual gradul de utilizare a spațiului de stocare de pe toate discurile disponibile. Deci, datorită faptului că se face un calcul procentual al gradului de umplere, MooseFS nu impune ca toate discurile să aibă aceeași dimensiune. Astfel, de exemplu, toate discurile din nodurile MooseFS vor ajunge în timp la un grad de umplere egal procentual, indiferent de mărime.
Dat fiind faptul că fișierele sunt multiplicate pe noduri diferite, la nivel de nod nu avem nevoie de soluții RAID care să duplice conținutul sau să fie ineficiente ca viteză pentru a asigura protecția datelor. Datele sunt protejate prin replicare internod, nu intranod. Gradul de multiplicare poate fi controlat de administrator până la nivelul fiecărui fișier în parte și fără întreruperea funcționării sistemului sau oricărei componente ale sale. Dacă pe MooseFS nu se stochează nimic, atunci spațiul ocupat de MooseFS pe nodurile de stocare este aproape zero. Deci, MooseFS ocupă exact atât spațiu de stocare cât are nevoie și nu are nevoie de partiții separate - folosește un director; administratorul de sisteme nu trebuie să își planifice nimic din timp, ci doar să instaleze și să pornească serviciile de stocare, serviciul master și serviciile de metalogger.
Pentru a mări capacitatea de stocare, administratorul poate să adauge oricând, fără să anunțe, noduri noi, sau să extindă capacitatea de stocare a vechilor noduri, oprirea unui nod de stocare neafectând în nici un fel disponibilitatea sistemului. Singurul punct care prezintă pericol în configurația standard este nodul master, dar la intervenția manuală a administratorului, un nod metalogger poate fi pornit ca master în mai puțin de 10 secunde.
Momentan, la noi în companie se prelucrează cantități mari de date. Datele vin în formă denormalizată de la diferiți furnizori, periodic. Aceste date sunt atât gratuite, cât și plătite. Odată cu trecerea timpului cantitățile de date ce sunt primite cresc, iar echipa de administrare a fost pusă de mai multe ori în fața problemei epuizării spațiului de stocare. Câteodată, noaptea la ora 2:47. Nu doar datele care vin trebuie stocate. Nevoie de spațiu au și procesele de creare a copiilor de rezervă și procesele de arhivare a datelor prelucrate. Toate acestea cresc în timp. Utilizarea soluțiilor standard RAID pot să scaleze până când se umple suportul de discuri (enclosure). Bineînțeles că există și soluția extinderii cu un nou suport de discuri. Această scalare însă, nu oferă protecție la defectarea nodului la care acel suport de discuri e atașat.
De asemenea, „mașinile virtuale” au nevoie de o metodă de a se opri pe un nod și a porni pe alt nod în timp cât mai scurt, fără pierdere de date. Astfel, nu putem face o copie a unei „mașini virtuale” azi și să o pornim, iar apoi mâine să folosim copia de azi pentru a porni „mașina virtuală” pe alt nod, deoarece între timp, mașina și-a modificat starea. În cazul în care „mașina virtuală” este stocată „pe rețea”, putem pur și simplu să o oprim pe un nod și să o pornim pe altul, fără a copia nimic între noduri.
Într-un birou, administratorul de sisteme poate rula mașini virtuale pe stațiile colegilor. Acestea sunt stocate pe sistemul de fișiere de rețea și „sar” de pe un calculator pe altul automat, când calculatorul gazdă este oprit. Astfel se pot rula noaptea teste, build-uri, procese de calcul distribuit (grid computing) chiar pe stațiile angajaților, fără a mai fi nevoie de servere scumpe, dedicate.
Alegerea unui sistem de fișiere de rețea performant este vitală pentru rezistența sistemelor la dezastre și pentru utilizarea eficientă a resurselor. Ce poate fi mai important decât să știi că TOATE discurile din centrul de calcul sunt umplute la același procent și că oricând e nevoie de mai mult spațiu se pot adăuga noduri suplimentare, fără întreruperi în funcționarea sistemelor? MooseFS mai oferă două facilități interesante pentru cei ce rulează mașini virtuale aproape identice: snapshotting și coș de gunoi configurabil. Coșul de gunoi șterge fișierele care ating o anumită limită de timp configurabilă de către administratorul de sisteme. Deci, coșul de gunoi nu trebuie golit manual și complet, ci fiecare fișier ce ajunge acolo este șters automat după o anumită perioadă. Toate fișierele șterse ajung în coșul de gunoi și nu se poate configura să fie șterse direct. Se poate însă configura coșul de gunoi în așa fel încât să șteargă fișierele după 0 secunde, ceea ce are ca efect ștergerea imediată. Snapshotting-ul este o metodă de a stoca bucățile identice ale mai multor fișiere o singură dată. Aceste fișiere indică spre aceleași date de pe disc, creând iluzia că sunt stocate de mai multe ori. Această metodă mai e cunoscută și ca „deduplicare”. În momentul în care într-unul din aceste fișiere se produce o modificare (se modifică o porțiune de fișier), acea porțiune este stocată separat pentru cele două fișiere. Restul porțiunilor sunt stocate doar o singură dată, spațiul efectiv ocupat de acele două fișiere fiind egal cu mărimea părților comune plus mărimea diferențelor. Metoda de a stoca doar diferențele se numește „copiere în momentul scrierii” (COW - copy on write). Astfel, dacă administratorul are un șablon de mașină virtuală, el poate crea mai multe fișiere imagine ale acelei mașini virtuale pe care să le pornească independent. De exemplu, pentru a scala un webserver supraîncărcat, se pornesc multe mașini virtuale ce folosesc același fișier de disc, iar diferențele apar când fiecare clonă își scrie propriile fișiere de loguri sau alte date pe disc. Comanda mfsmakesnapshot creează aceste tipuri de fișiere.
În partea a III-a voi discuta despre LxC, o metodă de virtualizare a sistemelor Linux fără pierderi de performanță, care face posibilă actualizarea controlată fără întreruperea serviciului.
Schemele provin de pe site-ul www.moosefs.org și sunt proprietatea autorilor MooseFS.