GFS2 - GFS2

V oblasti výpočetní techniky je Global File System 2 nebo GFS2 souborový systém se sdíleným diskem pro počítačové klastry Linuxu . GFS2 umožňuje všem členům klastru mít přímý souběžný přístup ke stejnému úložišti sdílených bloků , na rozdíl od distribuovaných souborových systémů, které distribuují data v celém klastru. GFS2 lze také použít jako místní souborový systém na jednom počítači.

GFS2 nemá žádný odpojený provozní režim a žádné role klienta nebo serveru. Všechny uzly v clusteru GFS2 fungují jako peer. Používání GFS2 v klastru vyžaduje hardware umožňující přístup ke sdílenému úložišti a správce zámku pro řízení přístupu k úložišti. Manažer zámek funguje jako samostatný modul: tak GFS2 lze použít Distributed Lock správce (DLM) pro clusteru konfigurací a „NOLOCK“ zámku manažer lokální souborové systémy. Starší verze GFS také podporují GULM, správce zámků na serveru, který implementuje redundanci prostřednictvím převzetí služeb při selhání.

GFS a GFS2 jsou bezplatný software distribuovaný podle licencí GNU General Public License .

Dějiny

Vývoj GFS začal v roce 1995 a byl původně vyvinut profesorem University of Minnesota Matthew O'Keefe a skupinou studentů. To byla původně napsána pro SGI je IRIX operačním systému, ale v roce 1998 byl portován na Linux , protože open source kód za předpokladu, pohodlnější platformu pro vývoj. Na konci roku 1999/začátkem roku 2000 se dostal do Sistina Software , kde žil nějaký čas jako open-source projekt. V roce 2001 se Sistina rozhodla udělat z GFS proprietární produkt.

Vývojáři rozdvojili OpenGFS z posledního veřejného vydání GFS a poté jej dále vylepšili o aktualizace, které mu umožňují pracovat s OpenDLM. OpenGFS a OpenDLM však zanikly, protože Red Hat v prosinci 2003 koupil Sistinu a koncem června 2004 vydal GFS a mnoho kusů infrastruktury klastru pod GPL .

Red Hat následně financovala další vývoj zaměřený na opravu chyb a stabilizaci. Další vývoj, GFS2, pochází z GFS a byl zahrnut spolu s jeho distribuovaným správcem zámků (sdíleným s GFS) v Linuxu 2.6.19. Red Hat Enterprise Linux 5.2 obsahoval GFS2 jako modul jádra pro účely hodnocení. S aktualizací 5.3 se GFS2 stal součástí balíčku jádra.

GFS2 je součástí distribucí Fedora , Red Hat Enterprise Linux a souvisejících distribucí CentOS Linux. Uživatelé si mohou zakoupit komerční podporu pro provozování GFS2 plně podporovaného nad Red Hat Enterprise Linux . Od verze Red Hat Enterprise Linux 8.3 je GFS2 podporován v prostředích cloud computingu, ve kterých jsou k dispozici sdílená paměťová zařízení.

Následující seznam shrnuje některá čísla verzí a hlavní zavedené funkce:

• v1.0 (1996) Pouze SGI IRIX
• v3.0 Linux port
• v4 deníku
• v5 Redundant Lock Manager
• v6.1 (2005) Distributed Lock Manager
• Linux 2.6.19 - GFS2 a DLM sloučeny do linuxového jádra
• Red Hat Enterprise Linux 5.3 vydává první plně podporovaný GFS2

Hardware

Konstrukce GFS a GFS2 cílí na prostředí podobná SAN . Ačkoli je možné je použít jako souborový systém s jedním uzlem, celá sada funkcí vyžaduje SAN. To může mít podobu iSCSI , FibreChannel , AoE nebo jakéhokoli jiného zařízení, které lze v Linuxu prezentovat jako blokové zařízení sdílené několika uzly, například zařízení DRBD .

DLM vyžaduje IP sítě založené na kterém jsou ke komunikaci. Obvykle je to jen ethernet , ale opět existuje mnoho dalších možných řešení. V závislosti na volbě SAN může být možné toto kombinovat, ale běžná praxe zahrnuje oddělené sítě pro DLM a úložiště.

GFS vyžaduje nějaký mechanismus oplocení . Toto je požadavek na infrastrukturu klastru, nikoli na samotný GFS/GFS2, ale je vyžadován pro všechny víceuzlové klastry. Mezi obvyklé možnosti patří vypínače a ovladače vzdáleného přístupu (např. DRAC , IPMI nebo ILO ). Lze použít také mechanismy oplocení založené na virtuálním a hypervisoru. Oplocení se používá k zajištění toho, aby uzel, o kterém klastr věří, že selhal, nemohl najednou začít znovu fungovat, zatímco jiný uzel obnovuje deník pro nefunkční uzel. Po dokončení obnovy může také volitelně automaticky restartovat nefunkční uzel.

Rozdíly od místního souborového systému

Přestože se návrháři GFS/GFS2 snažili emulovat lokální souborový systém zblízka, je třeba si uvědomit řadu rozdílů. Některé z nich jsou kvůli existujícím rozhraním souborového systému, které neumožňují předávání informací týkajících se clusteru. Některé pramení z obtížnosti efektivní implementace těchto funkcí seskupeným způsobem. Například:

• Stádo () systémové volání na GFS / GFS2 není možnost je přerušit signály .
• Fcntl () volání F_GETLK systém vrátí PID jakéhokoliv blokování zámku. Protože se jedná o klastrový souborový systém, může tento PID odkazovat na proces na kterémkoli z uzlů, které mají připojený souborový systém. Protože účelem tohoto rozhraní je umožnit odeslání signálu do procesu blokování, není to již možné.
• Lease nejsou podporovány modulem lock_dlm (cluster) lock, ale jsou podporovány při použití jako lokální souborový systém
• dnotify bude fungovat na principu „stejného uzlu“, ale jeho použití s ​​GFS/GFS2 se nedoporučuje
• inotify bude fungovat také na základě „stejného uzlu“ a také se nedoporučuje (ale může být v budoucnu podporován)
• splice je podporována pouze na GFS2

Další hlavní rozdíl, který sdílejí všechny podobné klastrové souborové systémy, je ten, že mechanismus řízení mezipaměti, známý jako glocks (vyslovuje se Gee-locks) pro GFS/GFS2, má vliv na celý klastr. Ke každému inodu v souborovém systému jsou přiřazeny dvě glocky. Jeden (nazývaný iopen glock) sleduje, které procesy mají otevřený inode. Druhý (inode glock) ovládá mezipaměť vztahující se k tomuto inodu. Glock má čtyři stavy, UN (odemčený), SH (sdílený - zámek pro čtení), DF (odložený - zámek pro čtení nekompatibilní s SH) a EX (exkluzivní). Každý ze čtyř režimů se mapuje přímo do režimu zámku DLM .

V režimu EX může inode ukládat data a metadata do mezipaměti (což může být „špinavé“, tj. Čeká na zápis zpět do souborového systému). V režimu SH může inode ukládat do mezipaměti data a metadata, ale nesmí být špinavý. V režimu DF může inode ukládat do mezipaměti pouze metadata a opět nesmí být špinavá. Režim DF se používá pouze pro přímé I/O. V režimu UN nesmí inode ukládat do mezipaměti žádná metadata.

Aby operace, které mění data nebo metadata inodu, navzájem nerušily, používá se zámek EX. To znamená, že určité operace, jako je vytváření/odpojování souborů ze stejného adresáře a zápisy do stejného souboru, by obecně měly být omezeny na jeden uzel v klastru. Provádění těchto operací z více uzlů bude samozřejmě fungovat podle očekávání, ale vzhledem k požadavku na časté vyprázdnění mezipaměti to nebude příliš efektivní.

Nejčastěji kladenou otázkou ohledně výkonu GFS/GFS2 je, proč může být výkon u e -mailových serverů špatný. Řešením je rozdělit cívku pošty do samostatných adresářů a pokusit se udržet (pokud je to možné) každý uzel číst a zapisovat do soukromé sady adresářů.

Žurnálování

GFS i GFS2 jsou žurnálované souborové systémy ; a GFS2 podporuje podobnou sadu režimů žurnálování jako ext3 . V režimu data = zpětný zápis se do deníku zapisují pouze metadata. Toto je jediný režim podporovaný GFS, je však možné zapnout deníky u jednotlivých datových souborů, ale pouze pokud jsou nulové velikosti. Žurnálované soubory v GFS mají řadu omezení, například žádná podpora pro systémová volání mmap nebo sendfile, ale také používají jiný formát na disku než běžné soubory. Existuje také atribut „inherit-journal“, který při nastavení na adresář způsobí, že všechny soubory (a podadresáře) vytvořené v tomto adresáři budou mít nastaven příznak journal (respektive inherit-journal). To lze použít místo možnosti mount data = journal, kterou ext3 podporuje (a GFS/GFS2 nikoli).

GFS2 také podporuje režim data = seřazený, který je podobný datu = zpětný zápis, kromě toho, že se před dokončením každého žurnálování synchronizují špinavá data. Tím je zajištěno, že u bloků, které byly přidány do inodu, bude jejich obsah synchronizován zpět na disk před aktualizací metadat, aby zaznamenal novou velikost, a tím se zabrání tomu, aby se neinicializované bloky objevovaly v souboru za podmínek selhání uzlu. Výchozí režim deníku je data = seřazeno , aby odpovídalo výchozímu nastavení ext3 .

Od roku 2010 GFS2 zatím nepodporuje režim data = deník , ale používá (na rozdíl od GFS) stejný formát na disku pro běžné i žurnálované soubory a také podporuje stejné atributy žurnálovaného a zděděného deníku. GFS2 také uvolňuje omezení, kdy může být u souboru změněn jeho žurnálovaný atribut, kdykoli soubor není otevřen (také stejný jako ext3 ).

Z důvodů výkonu má každý uzel v GFS a GFS2 svůj vlastní deník. V GFS jsou deníky rozsahy disků, v GFS2 jsou deníky jen běžné soubory. Počet uzlů, které mohou současně připojit souborový systém, je omezen počtem dostupných žurnálů.

Funkce GFS2 ve srovnání s GFS

GFS2 přidává řadu nových funkcí, které v GFS nejsou. Zde je souhrn těchto funkcí, které ještě nebyly zmíněny v polích napravo od této stránky:

• Souborový systém metadat (opravdu jiný root) - viz Kompatibilita a meta souborový systém GFS2 níže
• Trasovací body specifické pro GFS2 jsou k dispozici od jádra 2.6.32
• Rozhraní kvót ve stylu XFS je v GFS2 k dispozici od jádra 2.6.33
• ACL s mezipamětí jsou v GFS2 k dispozici od 2.6.33
• GFS2 podporuje generování požadavků „vyřazení“ pro požadavky na tenké zřizování/SCSI TRIM
• GFS2 podporuje I/O bariéry (ve výchozím nastavení zapnuto, za předpokladu, že to základní zařízení podporuje. Konfigurovatelné od jádra 2.6.33 a výše)
• FIEMAP ioctl (dotazování mapování inodů na disku)
• Podpora spojování (systémové volání)
• podpora mmap/splice pro žurnálované soubory (povoleno použitím stejného formátu na disku jako u běžných souborů)
• Mnohem méně laditelných (nastavení je méně komplikované)
• Objednaný režim zápisu (podle ext3 má GFS pouze režim zpětného zápisu)

Kompatibilita a meta souborový systém GFS2

GFS2 byl navržen tak, aby upgrade z GFS byl jednoduchý postup. Za tímto účelem většina struktury na disku zůstala stejná jako GFS, včetně big-endian bajtového uspořádání. Existuje však několik rozdílů:

• GFS2 má „meta souborový systém“, jehož prostřednictvím zpracovává přístup k systémovým souborům
• GFS2 používá pro žurnálované soubory stejný formát na disku jako pro běžné soubory
• GFS2 používá pro časopisy běžné (systémové) soubory, zatímco GFS používá speciální rozsahy
• GFS2 má některé další systémové soubory „ per_node “
• Rozložení inody je (velmi mírně) odlišné
• Rozložení nepřímých bloků se mírně liší

Deníkové systémy GFS a GFS2 nejsou navzájem kompatibilní. Upgradování je možné pomocí nástroje ( gfs2_convert ), který se spouští s off-line souborovým systémem pro aktualizaci metadat. Některé náhradní bloky v denících GFS se používají k vytváření (velmi malých) souborů per_node požadovaných GFS2 během procesu aktualizace. Většina dat zůstává na svém místě.

„Meta souborový systém“ GFS2 není souborový systém sám o sobě, ale alternativní kořen hlavního souborového systému. Přestože se chová jako „normální“ souborový systém, jeho obsahem jsou různé systémové soubory používané GFS2 a uživatelé se na něj obvykle nemusí vůbec dívat. Obslužné programy GFS2 podle potřeby v zákulisí připojují a odpojují meta souborový systém.

Viz také

• Porovnání souborových systémů
• GPFS , ZFS , VxFS
• Lesk
• GlusterFS
• Seznam souborových systémů
• OCFS2
• QFS
• Systém souborů SAN
• Oplocení
• Otevřený sdílený kořen
• Ceph (software)

Reference

externí odkazy

• Red Hat Red Hat Enterprise Linux 6 - Global File System 2
• Stránka Red Hat Cluster Suite a stránka dokumentace GFS
• Stránka projektu GFS
• Stránka projektu OpenGFS (zastaralá)
• Strom GIT pro vývoj GFS2
• Strom gitů pro vývoj nástrojů GFS2