GFS2 - GFS2

În calcul , Global File System 2 sau GFS2 este un sistem de fișiere pe disc partajat pentru clusterele de calculatoare Linux . GFS2 permite tuturor membrilor unui cluster să aibă acces simultan direct la același stoc de blocuri partajate , spre deosebire de sistemele de fișiere distribuite care distribuie date în întregul cluster. GFS2 poate fi folosit și ca sistem de fișiere local pe un singur computer.

GFS2 nu are un mod de operare deconectat și nici un rol de client sau server. Toate nodurile dintr-un cluster GFS2 funcționează ca peeri. Utilizarea GFS2 într-un cluster necesită hardware pentru a permite accesul la stocarea partajată și un manager de blocare pentru a controla accesul la stocare. Managerul de blocare funcționează ca un modul separat: astfel GFS2 poate utiliza Distributed Lock Manager (DLM) pentru configurațiile clusterului și managerul de blocare „nolock” pentru sistemele de fișiere locale. Versiunile mai vechi ale GFS acceptă, de asemenea, GULM, un manager de blocare bazat pe server care implementează redundanță prin failover.

GFS și GFS2 sunt programe gratuite , distribuite în condițiile licenței publice generale GNU .

Istorie

Dezvoltarea GFS a început în 1995 și a fost inițial dezvoltată de profesorul Universității din Minnesota, Matthew O'Keefe și de un grup de studenți. Acesta a fost scris inițial pentru SGI lui IRIX sistem de operare, dar în 1998 a fost portat pentru Linux , deoarece open source codul a oferit o platformă de dezvoltare mai convenabil. La sfârșitul anului 1999 / începutul anului 2000 și-a făcut drum spre Sistina Software , unde a trăit o vreme ca proiect open source . În 2001, Sistina a ales să facă din GFS un produs propriu.

Dezvoltatorii au furnizat OpenGFS de la ultima versiune publică a GFS și l-au îmbunătățit ulterior pentru a include actualizări care îi permit să funcționeze cu OpenDLM. Dar OpenGFS și OpenDLM au dispărut, deoarece Red Hat a cumpărat Sistina în decembrie 2003 și a lansat GFS și multe piese de infrastructură cluster sub GPL la sfârșitul lunii iunie 2004.

Red Hat a finanțat ulterior dezvoltarea ulterioară orientată spre remedierea erorilor și stabilizarea. O dezvoltare ulterioară, GFS2 derivă din GFS și a fost inclus împreună cu managerul său de blocare distribuită (partajat cu GFS) în Linux 2.6.19. Red Hat Enterprise Linux 5.2 a inclus GFS2 ca modul de kernel în scopuri de evaluare. Odată cu actualizarea 5.3, GFS2 a devenit parte a pachetului kernel.

GFS2 face parte din Fedora , Red Hat Enterprise Linux și distribuțiile CentOS Linux asociate . Utilizatorii pot achiziționa asistență comercială pentru a rula GFS2 complet acceptat pe Red Hat Enterprise Linux . Începând cu Red Hat Enterprise Linux 8.3, GFS2 este acceptat în mediile de cloud computing în care sunt disponibile dispozitive de stocare partajate.

Următoarea listă rezumă câteva numere de versiuni și caracteristici majore introduse:

• v1.0 (1996) Numai SGI IRIX
• v3.0 port Linux
• jurnalizare v4
• v5 Redundant Lock Manager
• v6.1 (2005) Distribuit Lock Manager
• Linux 2.6.19 - GFS2 și DLM au fuzionat în nucleul Linux
• Red Hat Enterprise Linux 5.3 lansează primul GFS2 complet acceptat

Hardware

Proiectarea GFS și a GFS2 vizează medii de tip SAN . Deși este posibil să le utilizați ca un sistem de fișiere cu un singur nod, setul complet de caracteristici necesită un SAN. Acest lucru poate lua forma iSCSI , FibreChannel , AoE sau orice alt dispozitiv care poate fi prezentat sub Linux ca un dispozitiv bloc partajat de un număr de noduri, de exemplu un dispozitiv DRBD .

DLM necesită un IP de rețea pe baza peste care sa comunice. Acesta este în mod normal doar Ethernet , dar din nou, există multe alte soluții posibile. În funcție de alegerea SAN-ului, poate fi posibil să se combine acest lucru, dar practica normală implică rețele separate pentru DLM și stocare.

GFS necesită un fel de mecanism de împrejmuire . Aceasta este o cerință a infrastructurii cluster, mai degrabă decât GFS / GFS2 în sine, dar este necesară pentru toate clusterele multi-nod. Opțiunile obișnuite includ comutatoare de alimentare și controlere de acces la distanță (de exemplu , DRAC , IPMI sau ILO ). Pot fi de asemenea utilizate mecanisme de garduri virtuale și bazate pe hipervizor. Împrejmuirea este utilizată pentru a se asigura că un nod despre care clusterul crede că eșuează nu poate începe din nou să funcționeze din nou în timp ce un alt nod recuperează jurnalul pentru nodul eșuat. De asemenea, opțional poate reporni automat nodul eșuat automat după finalizarea recuperării.

Diferențe față de un sistem de fișiere local

Deși proiectanții GFS / GFS2 au urmărit să emuleze îndeaproape un sistem de fișiere local, există o serie de diferențe de care trebuie să fii conștient. Unele dintre acestea se datorează interfețelor existente ale sistemului de fișiere care nu permit transmiterea informațiilor referitoare la cluster. Unele provin din dificultatea de a implementa aceste caracteristici în mod eficient într-un mod grupat. De exemplu:

• Turma () sistem de apel de SFG / GFS2 nu este interuptibil de semnale .
• Fcntl () apelul sistem F_GETLK returnează un PID de orice blocare de blocare. Deoarece acesta este un sistem de fișiere cluster, acel PID se poate referi la un proces pe oricare dintre nodurile care au sistemul de fișiere montat. Deoarece scopul acestei interfețe este de a permite trimiterea unui semnal către procesul de blocare, acest lucru nu mai este posibil.
• Închirierile nu sunt acceptate cu modulul de blocare lock_dlm (cluster), dar sunt acceptate atunci când sunt utilizate ca sistem de fișiere local
• dnotify va funcționa pe „același nod”, dar utilizarea acestuia cu GFS / GFS2 nu este recomandată
• inotify va funcționa, de asemenea, pe baza "aceluiași nod" și, de asemenea, nu este recomandat (dar poate fi acceptat în viitor)
• splice este acceptat numai pe GFS2

Cealaltă diferență principală, și care este partajată de toate sistemele de fișiere cluster similare, este că mecanismul de control al cache-ului, cunoscut sub numele de glocks (pronunțate Gee-locks) pentru GFS / GFS2, are un efect pe întregul cluster. Fiecare inode pe sistemul de fișiere are două glocks asociate cu ea. Unul (numit iopen glock) ține evidența carei procese au inodul deschis. Cealaltă (inock glock) controlează cache-ul aferent acelui inode. Un glock are patru state, UN (deblocat), SH (partajat - un blocaj de citire), DF (amânat - un blocaj de citire incompatibil cu SH) și EX (exclusiv). Fiecare dintre cele patru moduri se mapează direct la un mod de blocare DLM .

Când este în modul EX, unui inod îi este permis să cache date și metadate (care ar putea fi „murdare”, adică așteaptă scrierea înapoi în sistemul de fișiere). În modul SH, inodul poate cache date și metadate, dar nu trebuie să fie murdar. În modul DF, inodului este permis să cache doar metadatele și, din nou, nu trebuie să fie murdar. Modul DF este utilizat numai pentru I / O directe. În modul UN, inodul nu trebuie să memoreze în cache nicio metadată.

Pentru ca operațiile care modifică datele sau metadatele unui inod să nu interfereze unele cu altele, se folosește o blocare EX. Aceasta înseamnă că anumite operațiuni, cum ar fi crearea / deconectarea fișierelor din același director și scrierea în același fișier, ar trebui, în general, să fie restricționate la un singur nod din cluster. Desigur, efectuarea acestor operațiuni de la mai multe noduri va funcționa așa cum era de așteptat, dar datorită cerinței de a spăla frecvent cache-urile, nu va fi foarte eficient.

Cea mai frecventă întrebare despre performanța GFS / GFS2 este de ce performanța poate fi slabă la serverele de e-mail. Soluția este de a împărți spoolul de e-mail în directoare separate și de a încerca să păstreze (atât cât este posibil) fiecare nod citind și scriind într-un set privat de directoare.

Jurnalizare

GFS și GFS2 sunt ambele sisteme de fișiere jurnalizate ; iar GFS2 acceptă un set similar de moduri de jurnalizare ca ext3 . În modul date = readback , sunt înregistrate numai metadatele. Acesta este singurul mod acceptat de GFS, cu toate acestea este posibil să activați jurnalizarea fișierelor de date individuale, dar numai atunci când acestea sunt de dimensiuni zero. Fișierele jurnalizate din GFS au o serie de restricții, cum ar fi nicio asistență pentru apelurile de sistem mmap sau sendfile, de asemenea, utilizează un format diferit pe disc față de fișierele obișnuite. Există, de asemenea, un atribut „inherit-journal” care, atunci când este setat într-un director, face ca toate fișierele (și subdirectoarele) create în acel director să aibă setat jurnalul (sau inherit-journal, respectiv). Aceasta poate fi utilizată în locul opțiunii de montare date = jurnal, care acceptă ext3 (și GFS / GFS2 nu).

GFS2 acceptă, de asemenea, datele = modul ordonat , care este similar cu datele = scriere, cu excepția faptului că datele murdare sunt sincronizate înainte de finalizarea fiecărei coli de jurnal. Acest lucru asigură că blocurile care au fost adăugate la un inod vor avea conținutul sincronizat înapoi pe disc înainte ca metadatele să fie actualizate pentru a înregistra noua dimensiune și astfel împiedică blocurile neinițializate să apară într-un fișier în condiții de eșec al nodului. Modul de jurnal implicit este data = comandat , pentru a se potrivi cu valoarea implicită a ext3 .

Începând cu 2010, GFS2 nu acceptă încă modul date = jurnal , dar (spre deosebire de GFS) folosește același format pe disc atât pentru fișierele obișnuite, cât și pentru jurnal și acceptă, de asemenea, aceleași atribute jurnalizate și moștenite din jurnal. GFS2 relaxează, de asemenea, restricțiile cu privire la momentul în care un fișier poate avea atributul jurnal modificat în orice moment în care fișierul nu este deschis (de asemenea, la fel ca ext3 ).

Din motive de performanță, fiecare nod din GFS și GFS2 are propriul jurnal. În GFS jurnalele sunt extinse pe disc, în GFS2 jurnalele sunt doar fișiere obișnuite. Numărul de noduri care pot monta sistemul de fișiere în orice moment este limitat de numărul de jurnale disponibile.

Caracteristicile GFS2 în comparație cu GFS

GFS2 adaugă o serie de funcții noi care nu sunt în GFS. Iată un rezumat al acelor caracteristici care nu sunt deja menționate în casetele din dreapta acestei pagini:

• Sistemul de fișiere cu metadate (într-adevăr o altă rădăcină) - consultați Compatibilitatea și meta-sistemul de fișiere GFS2 de mai jos
• Punctele de urmărire specifice GFS2 au fost disponibile de la nucleul 2.6.32
• Interfața de cotă în stil XFS a fost disponibilă în GFS2 de la kernel 2.6.33
• ACL-urile în cache sunt disponibile în GFS2 încă de la 2.6.33
• GFS2 acceptă generarea de cereri de „renunțare” pentru solicitări subțiri / cereri SCSI TRIM
• GFS2 acceptă bariere I / O (activat în mod implicit, presupunând că dispozitivul de bază îl acceptă. Configurabil din kernel 2.6.33 și în sus)
• FIEMAP ioctl (pentru interogarea mapărilor inodurilor de pe disc)
• Suport splice (apel sistem)
• suport mmap / splice pentru fișierele jurnalizate (activat utilizând același format pe disc ca pentru fișierele obișnuite)
• Mult mai puține reglaje (făcând setarea mai puțin complicată)
• Mod de scriere comandat (conform ext3, GFS are doar modul de scriere)

Compatibilitate și meta-sistem de fișiere GFS2

GFS2 a fost conceput astfel încât actualizarea de la GFS să fie o procedură simplă. În acest scop, cea mai mare parte a structurii de pe disc a rămas aceeași ca GFS, inclusiv ordinea de octet big-endian . Există însă câteva diferențe:

• GFS2 are un „meta-sistem de fișiere” prin care procesează acces la fișierele de sistem
• GFS2 utilizează același format pe disc pentru fișierele jurnalizate ca și pentru fișierele obișnuite
• GFS2 folosește fișiere regulate (de sistem) pentru jurnale, în timp ce GFS folosește extinderi speciale
• GFS2 are alte fișiere de sistem „ per_node ”
• Aspectul inodului este (foarte ușor) diferit
• Aspectul blocurilor indirecte diferă ușor

Sistemele de jurnalizare ale GFS și GFS2 nu sunt compatibile între ele. Actualizarea este posibilă prin intermediul unui instrument ( gfs2_convert ) care este rulat cu sistemul de fișiere off-line pentru a actualiza metadatele. Unele blocuri de rezervă din jurnalele GFS sunt utilizate pentru a crea fișierele (foarte mici) per_node cerute de GFS2 în timpul procesului de actualizare. Majoritatea datelor rămân la locul lor.

„Meta-sistemul de fișiere” GFS2 nu este un sistem de fișiere în sine, ci o rădăcină alternativă a sistemului de fișiere principal. Deși se comportă ca un sistem de fișiere „normal”, conținutul său este diferitele fișiere de sistem utilizate de GFS2 și, în mod normal, utilizatorii nu trebuie să se uite vreodată la el. Utilitarele GFS2 montează și demontează meta-sistemul de fișiere după cum este necesar, în culise.

Vezi si

• Compararea sistemelor de fișiere
• GPFS , ZFS , VxFS
• Luciu
• GlusterFS
• Lista sistemelor de fișiere
• OCFS2
• QFS
• Sistem de fișiere SAN
• Împrejmuire
• Open-Sharedroot
• Ceph (software)

Referințe

linkuri externe

• Red Hat Red Hat Enterprise Linux 6 - Sistem global de fișiere 2
• Red Hat Cluster Suite și pagina de documentare GFS
• Pagina proiectului GFS
• Pagina proiectului OpenGFS (învechită)
• Arborele git de dezvoltare GFS2
• Arborele git de dezvoltare a utilităților GFS2