GFS2 - GFS2

I computing er Global File System 2 eller GFS2 et filsystem med delt disk til Linux- computerklynger. GFS2 tillader alle medlemmer af en klynge for at have direkte samtidig adgang til den samme fælles blok opbevaring i modsætning til distribuerede filsystemer som fordeler data i hele klyngen. GFS2 kan også bruges som et lokalt filsystem på en enkelt computer.

GFS2 har ingen afbrudt driftstilstand og ingen klient- eller serverroller. Alle noder i en GFS2 -klynge fungerer som peers. Brug af GFS2 i en klynge kræver hardware for at give adgang til det delte lager og en låsemanager til at styre adgangen til lageret. Låseadministratoren fungerer som et separat modul: GFS2 kan således bruge Distributed Lock Manager (DLM) til klyngekonfigurationer og "nolock" -låsemanager til lokale filsystemer. Ældre versioner af GFS understøtter også GULM, en serverbaseret låsemanager, der implementerer redundans via failover.

GFS og GFS2 er gratis software , der distribueres under vilkårene i GNU General Public License .

Historie

Udviklingen af ​​GFS begyndte i 1995 og blev oprindeligt udviklet af professor Matthew O'Keefe fra University of Minnesota og en gruppe studerende. Det blev oprindeligt skrevet til SGI 's IRIX -operativsystem, men i 1998 blev det portet til Linux, da open source -koden gav en mere bekvem udviklingsplatform. I slutningen af ​​1999/begyndelsen af ​​2000 tog den vej til Sistina Software , hvor den en tid boede som et open source- projekt. I 2001 tog Sistina valget om at gøre GFS til et proprietært produkt.

Udviklere forkled OpenGFS fra den sidste offentlige udgivelse af GFS og forbedrede den derefter yderligere med opdateringer, der tillod den at fungere med OpenDLM. Men OpenGFS og OpenDLM blev nedlagt, siden Red Hat købte Sistina i december 2003 og frigav GFS og mange klynge-infrastrukturstykker under GPL i slutningen af ​​juni 2004.

Red Hat finansierede efterfølgende videreudvikling rettet mod fejlrettelse og stabilisering. En videreudvikling, GFS2 stammer fra GFS og blev inkluderet sammen med sin distribuerede låsemanager (delt med GFS) i Linux 2.6.19. Red Hat Enterprise Linux 5.2 inkluderede GFS2 som et kernemodul til evalueringsformål. Med opdateringen 5.3 blev GFS2 en del af kernepakken.

GFS2 er en del af Fedora , Red Hat Enterprise Linux og tilhørende CentOS Linux -distributioner. Brugere kan købe kommerciel support for at køre GFS2 fuldt ud understøttet Red Hat Enterprise Linux . Fra Red Hat Enterprise Linux 8.3 understøttes GFS2 i cloud computing -miljøer, hvor der er tilgængelige lagringsenheder.

Følgende liste opsummerer nogle versionnumre og de vigtigste funktioner, der blev introduceret:

• v1.0 (1996) SGI IRIX kun
• v3.0 Linux -port
• v4 journalføring
• v5 Redundant Lock Manager
• v6.1 (2005) Distribueret Lock Manager
• Linux 2.6.19 - GFS2 og DLM fusioneret til Linux -kerne
• Red Hat Enterprise Linux 5.3 frigiver den første fuldt understøttede GFS2

Hardware

Designet af GFS og GFS2 er målrettet mod SAN -lignende miljøer. Selvom det er muligt at bruge dem som et enkelt node-filsystem, kræver det fulde funktionssæt et SAN. Dette kan tage form af iSCSI , Fibrechannel , AOE , eller enhver anden anordning, som kan præsenteres under Linux som en blokenhed deles af en række af knudepunkter, fx en DRDB enhed.

Den DLM kræver en IP- baseret netværk, hvorover til at kommunikere. Dette er normalt bare Ethernet , men igen er der mange andre mulige løsninger. Afhængigt af valget af SAN kan det være muligt at kombinere dette, men normal praksis involverer separate netværk til DLM og lagring.

GFS kræver en hegnemekanisme af en eller anden art. Dette er et krav i klyngeinfrastrukturen frem for GFS/GFS2 selv, men det er påkrævet for alle multi-node klynger. De sædvanlige muligheder inkluderer afbrydere og fjernadgangskontroller (f.eks. DRAC , IPMI eller ILO ). Virtuelle og hypervisor-baserede hegnsmekanismer kan også bruges. Hegn bruges til at sikre, at en node, som klyngen mener at være mislykket, ikke pludselig kan begynde at fungere igen, mens en anden node gendanner journalen for den mislykkede node. Det kan også valgfrit genstarte den mislykkede node automatisk, når gendannelsen er fuldført.

Forskelle fra et lokalt filsystem

Selvom designerne af GFS/GFS2 havde til formål at efterligne et lokalt filsystem tæt, er der en række forskelle at være opmærksom på. Nogle af disse skyldes, at de eksisterende filsystemgrænseflader ikke tillader videregivelse af oplysninger vedrørende klyngen. Nogle stammer fra vanskeligheden ved at implementere disse funktioner effektivt på en klynge måde. For eksempel:

• Den flok () systemkaldet på GFS / GFS2 er ikke afbrydelig af signaler .
• Den fcntl () F_GETLK-system kald returnerer en PID nogen blokerende lås. Da dette er et klynge -filsystem, kan dette PID referere til en proces på en hvilken som helst af de noder, der har filsystemet monteret. Da formålet med denne grænseflade er at tillade et signal at blive sendt til blokeringsprocessen, er dette ikke længere muligt.
• Leasingkontrakter understøttes ikke med lock_dlm (cluster) låsemodulet, men de understøttes, når de bruges som et lokalt filsystem
• dnotify fungerer på "samme node" -basis, men dets brug med GFS/GFS2 anbefales ikke
• inotify fungerer også på et "samme node" -basis og anbefales heller ikke (men det kan blive understøttet i fremtiden)
• splice understøttes kun på GFS2

Den anden hovedforskel, og en, der deles af alle lignende klynge-filsystemer, er, at cachekontrolmekanismen, kendt som glocks (udtales Gee-locks) for GFS/GFS2, har en effekt på tværs af hele klyngen. Hver inode på filsystemet har to glocks forbundet med det. Den ene (kaldet iopen glock) holder styr på, hvilke processer der har inoden åben. Den anden (inode glock) styrer cachen, der vedrører den inode. En glock har fire stater, UN (ulåst), SH (delt - en læselås), DF (udskudt - en læselås, der er inkompatibel med SH) og EX (eksklusiv). Hver af de fire tilstande kortes direkte til en DLM -låsetilstand.

I EX -tilstand får en inode lov til at gemme data og metadata (som kan være "beskidte", dvs. vente på at skrive tilbage til filsystemet). I SH -tilstand kan inoden cache data og metadata, men det må ikke være snavset. I DF -tilstand må inoden kun gemme metadata, og igen må den ikke være snavset. DF -tilstanden bruges kun til direkte I/O. I UN -tilstand må inoden ikke gemme metadata i cachen.

For at operationer, der ændrer en inodes data eller metadata, ikke forstyrrer hinanden, bruges en EX -lås. Det betyder, at visse operationer, f.eks. Oprettelse/afbinding af filer fra den samme mappe og skrivning til den samme fil, generelt skal begrænses til en knude i klyngen. Selvfølgelig vil udførelse af disse operationer fra flere noder fungere som forventet, men på grund af kravet om at skylle caches ofte, vil det ikke være særlig effektivt.

Det mest hyppigt stillede spørgsmål om GFS/GFS2 -ydelse er, hvorfor ydelsen kan være dårlig med e -mailservere. Løsningen er at opdele mailrullen i separate biblioteker og forsøge at (så vidt muligt) holde hver node læsning og skrivning til et privat sæt biblioteker.

Journalføring

GFS og GFS2 er begge journaliserede filsystemer ; og GFS2 understøtter et lignende sæt journalingstilstande som ext3 . I data = tilbagekaldsmodus journaliseres kun metadata. Dette er den eneste tilstand, der understøttes af GFS, men det er muligt at aktivere journalføring på individuelle datafiler, men kun når de er af nul størrelse. Journal filer i GFS har en række restriktioner på dem, som ingen støtte til de mmap eller sendfile systemkald, de også bruge et andet on-disk-format fra almindelige filer. Der er også en "arv-journal" -attribut, som når den er angivet i et bibliotek, får alle filer (og underkataloger), der er oprettet inden for dette bibliotek, til at have journalen (henholdsvis arv-journal) markeret. Dette kan bruges i stedet for data = journal mount -indstillingen, som ext3 understøtter (og GFS/GFS2 ikke).

GFS2 understøtter også data = ordnet tilstand, der ligner data = tilbagebetaling bortset fra, at beskidte data synkroniseres, før hver journalskylning er gennemført. Dette sikrer, at blokke, der er tilføjet til en inode, får deres indhold synkroniseret tilbage til disken, før metadata opdateres for at registrere den nye størrelse og forhindrer dermed, at uinitialiserede blokke vises i en fil under nodefejlbetingelser. Standardjournalingstilstanden er data = ordnet , så den matcher ext3 's standard.

Fra 2010 understøtter GFS2 endnu ikke data = journal- tilstand, men den bruger (i modsætning til GFS) det samme diskformat til både almindelige og journaliserede filer, og den understøtter også de samme journaliserede og arv-journalattributter. GFS2 lemper også på begrænsningerne for, hvornår en fil kan have sin journaliserede attribut ændret til enhver tid, hvor filen ikke er åben (også den samme som ext3 ).

Af ydelsesmæssige årsager har hver node i GFS og GFS2 sin egen journal. I GFS er tidsskrifterne diskudvidelser, i GFS2 er journalerne bare almindelige filer. Antallet af noder, der kan montere filsystemet til enhver tid, er begrænset af antallet af tilgængelige journaler.

Funktioner i GFS2 sammenlignet med GFS

GFS2 tilføjer en række nye funktioner, som ikke er i GFS. Her er en oversigt over de funktioner, der ikke allerede er nævnt i boksene til højre på denne side:

• Metadata -filsystemet (virkelig en anden rod) - se kompatibilitet og GFS2 meta -filsystemet nedenfor
• GFS2 -specifikke sporpunkter har været tilgængelige siden kerne 2.6.32
• Kvote-grænsefladen i XFS-stil har været tilgængelig i GFS2 siden kerne 2.6.33
• Caching ACL'er har været tilgængelige i GFS2 siden 2.6.33
• GFS2 understøtter generering af "kassér" -anmodninger til tynde provisioning/SCSI TRIM -anmodninger
• GFS2 understøtter I/O -barrierer (tændt som standard, forudsat at underliggende enhed understøtter det. Konfigurerbar fra kerne 2.6.33 og opefter)
• FIEMAP ioctl (forespørgsel på mappinger af inoder på disk)
• Splice (systemopkald) support
• mmap/splice support til journaliserede filer (aktiveret ved at bruge det samme på diskformat som til almindelige filer)
• Langt færre tunable (gør opsætningen mindre kompliceret)
• Bestilt skrivemåde (pr. Ext3, GFS har kun tilbagemeldingstilstand)

Kompatibilitet og GFS2 meta -filsystemet

GFS2 var designet, så opgradering fra GFS ville være en enkel procedure. Til dette formål er det meste af on-disk-strukturen forblevet den samme som GFS, herunder big-endian byte-bestilling. Der er dog et par forskelle:

• GFS2 har et "meta -filsystem", hvorigennem processer får adgang til systemfiler
• GFS2 bruger det samme format på disken til journaliserede filer som til almindelige filer
• GFS2 bruger almindelige (system) filer til journaler, mens GFS bruger særlige udvidelser
• GFS2 har nogle andre " per_node " systemfiler
• Layoutet af inoden er (meget lidt) anderledes
• Indretningen af ​​indirekte blokke adskiller sig en smule

Journalsystemerne i GFS og GFS2 er ikke kompatible med hinanden. Opgradering er mulig ved hjælp af et værktøj ( gfs2_convert ), der køres med filsystemet offline for at opdatere metadataene. Nogle reserveblokke i GFS -journaler bruges til at oprette de (meget små) per_node -filer, der kræves af GFS2 under opdateringsprocessen. De fleste data forbliver på plads.

GFS2 "meta -filsystemet" er ikke et filsystem i sig selv, men en alternativ rod til hovedfilsystemet. Selvom det opfører sig som et "normalt" filsystem, er dets indhold de forskellige systemfiler, der bruges af GFS2, og normalt behøver brugerne aldrig at se på det. GFS2 -værktøjerne monterer og afmonterer meta -filsystemet efter behov bag kulisserne.

Se også

• Sammenligning af filsystemer
• GPFS , ZFS , VxFS
• Glans
• GlusterFS
• Liste over filsystemer
• OCFS2
• QFS
• SAN filsystem
• Indhegning
• Åben rod
• Ceph (software)

Referencer

eksterne links

• Red Hat Red Hat Enterprise Linux 6 - Global File System 2
• Red Hat Cluster Suite og GFS dokumentationsside
• GFS -projektside
• OpenGFS -projektside (forældet)
• GFS2 udviklingsgit træet
• GFS2 -værktøjerne udvikler git -træ