GFS2

„Globalny system plików” przekierowuje tutaj. Aby zapoznać się z ogólną koncepcją, zobacz Globalny system plików .
GFS2
Deweloperzy czerwony kapelusz
Pełne imię i nazwisko Globalny system plików 2
wprowadzony 2005 z Linuksem 2.6.19
Struktury
Zawartość katalogu Haszowane (małe katalogi upchane w i-węźle)
Alokacja plików mapa bitowa (grupy zasobów)
Złe bloki NIE
Granice
Maks. liczba plików Zmienny
Maks. długość nazwy pliku 255 bajtów
Dozwolone znaki w nazwach plików Wszystkie oprócz NUL
Cechy
Zapisane daty modyfikacja atrybutu (ctime), modyfikacja (mtime), dostęp (atime)
Rozdzielczość daty Nanosekunda
Atrybuty No-atime, dane z kroniki (tylko zwykłe pliki), dziedziczenie danych z kroniki (tylko katalogi), zapis synchroniczny, tylko dołączanie, niezmienność, exhash (tylko katalogi, tylko do odczytu)
Uprawnienia systemu plików Uprawnienia systemu Unix, listy ACL i dowolne atrybuty bezpieczeństwa
Przezroczysta kompresja NIE
Przejrzyste szyfrowanie NIE
Deduplikacja danych tylko w węzłach
Inny
Obsługiwane systemy operacyjne Linuks
GFS
Deweloperzy Red Hat (dawniej Sistina Software )
Pełne imię i nazwisko Globalny system plików
wprowadzony 1996 z IRIX (1996), Linuksem (1997)
Struktury
Zawartość katalogu Haszowane (małe katalogi upchane w i-węźle)
Alokacja plików mapa bitowa (grupy zasobów)
Złe bloki NIE
Granice
Maks. liczba plików Zmienny
Maks. długość nazwy pliku 255 bajtów
Dozwolone znaki w nazwach plików Wszystkie oprócz NUL
Cechy
Zapisane daty modyfikacja atrybutu (ctime), modyfikacja (mtime), dostęp (atime)
Rozdzielczość daty 1s
Atrybuty No-atime, dane w dzienniku (tylko zwykłe pliki), dziedziczenie danych w dzienniku (tylko katalogi), zapis synchroniczny, tylko dołączanie, niezmienność, exhash (tylko katalogi, tylko do odczytu)
Uprawnienia systemu plików Uprawnienia Unix, listy ACL
Przezroczysta kompresja NIE
Przejrzyste szyfrowanie NIE
Deduplikacja danych tylko w węzłach
Inny
Obsługiwane systemy operacyjne IRIX (obecnie przestarzały), FreeBSD (obecnie przestarzały), Linux

W informatyce Global File System 2 lub GFS2 to system plików na dysku współdzielonym dla klastrów komputerów z systemem Linux . GFS2 umożliwia wszystkim członkom klastra bezpośredni jednoczesny dostęp do tej samej współdzielonej pamięci blokowej , w przeciwieństwie do rozproszonych systemów plików , które rozprowadzają dane w klastrze. GFS2 może być również używany jako lokalny system plików na pojedynczym komputerze.

GFS2 nie ma rozłączonego trybu operacyjnego ani ról klienta ani serwera. Wszystkie węzły w klastrze GFS2 działają jako elementy równorzędne. Używanie GFS2 w klastrze wymaga sprzętu umożliwiającego dostęp do współdzielonej pamięci masowej oraz menedżera blokad do kontrolowania dostępu do pamięci masowej. Menedżer blokad działa jako oddzielny moduł: w ten sposób GFS2 może używać Distributed Lock Manager (DLM) do konfiguracji klastrów i menedżera blokad „nolock” do lokalnych systemów plików. Starsze wersje GFS obsługują również GULM, opartego na serwerze menedżera blokad, który implementuje redundancję poprzez przełączanie awaryjne.

GFS i GFS2 to wolne oprogramowanie , rozpowszechniane na warunkach Powszechnej Licencji Publicznej GNU .

Historia

Rozwój GFS rozpoczął się w 1995 roku i został pierwotnie opracowany przez profesora Matthew O'Keefe z University of Minnesota oraz grupę studentów. Pierwotnie został napisany dla IRIX firmy SGI , ale w 1998 roku został przeniesiony na Linuksa , ponieważ kod open source zapewnił wygodniejszą platformę programistyczną. Na przełomie 1999 i 2000 roku trafiła do Sistina Software , gdzie przez pewien czas żyła jako projekt open-source . W 2001 roku Sistina zdecydowała, że ​​GFS będzie produktem zastrzeżonym.

Deweloperzy rozwidlili OpenGFS z ostatniej publicznej wersji GFS, a następnie udoskonalili go, dodając aktualizacje umożliwiające współpracę z OpenDLM. Ale OpenGFS i OpenDLM przestały istnieć, ponieważ Red Hat kupił Sistinę w grudniu 2003 roku i wypuścił GFS i wiele elementów infrastruktury klastra na licencji GPL pod koniec czerwca 2004 roku.

Red Hat następnie sfinansował dalszy rozwój ukierunkowany na naprawianie błędów i stabilizację. Dalszy rozwój, GFS2 wywodzi się z GFS i został dołączony wraz z rozproszonym menedżerem blokad (współdzielony z GFS) w Linuksie 2.6.19. Red Hat Enterprise Linux 5.2 zawierał GFS2 jako moduł jądra do celów ewaluacyjnych. Wraz z aktualizacją 5.3 GFS2 stał się częścią pakietu jądra.

GFS2 stanowi część dystrybucji Fedora , Red Hat Enterprise Linux i powiązanych dystrybucji CentOS Linux. Użytkownicy mogą wykupić komercyjne wsparcie, aby w pełni obsługiwać GFS2 w systemie Red Hat Enterprise Linux . Począwszy od Red Hat Enterprise Linux 8.3, GFS2 jest obsługiwany w przetwarzania w chmurze , w których dostępne są współdzielone urządzenia pamięci masowej.

Poniższa lista podsumowuje niektóre numery wersji i główne wprowadzone funkcje:

Sprzęt komputerowy

Projekt GFS i GFS2 jest ukierunkowany na środowiska podobne do SAN . Chociaż możliwe jest użycie ich jako systemu plików z jednym węzłem, pełny zestaw funkcji wymaga sieci SAN. Może to przybrać postać iSCSI , FibreChannel , AoE lub dowolnego innego urządzenia, które może być prezentowane w systemie Linux jako urządzenie blokowe współdzielone przez wiele węzłów, na przykład urządzenie DRBD .

DLM wymaga do komunikacji sieci opartej na protokole IP . Zwykle jest to po prostu Ethernet , ale znowu istnieje wiele innych możliwych rozwiązań. W zależności od wybranej sieci SAN możliwe jest połączenie tego, ale normalna praktyka [ potrzebne źródło ] obejmuje oddzielne sieci dla DLM i pamięci masowej.

GFS wymaga pewnego rodzaju mechanizmu ogrodzenia . Jest to wymaganie infrastruktury klastra, a nie samego GFS/GFS2, ale jest wymagane dla wszystkich klastrów wielowęzłowych. Zwykłe opcje obejmują przełączniki zasilania i kontrolery zdalnego dostępu (np. DRAC , IPMI lub ILO ). Można również zastosować mechanizmy ogrodzenia wirtualnego i hiperwizora. Ogrodzenie służy do zapewnienia, że ​​węzeł, który według klastra uległ awarii, nie może nagle zacząć ponownie działać, podczas gdy inny węzeł odzyskuje dziennik uszkodzonego węzła. Opcjonalnie może również automatycznie zrestartować uszkodzony węzeł po zakończeniu odzyskiwania.

Różnice w stosunku do lokalnego systemu plików

Chociaż projektanci GFS/GFS2 dążyli do ścisłej emulacji lokalnego systemu plików, istnieje wiele różnic, o których należy pamiętać. Niektóre z nich wynikają z istniejących interfejsów systemu plików, które nie pozwalają na przekazywanie informacji dotyczących klastra. Niektóre wynikają z trudności w skutecznym wdrażaniu tych funkcji w sposób klastrowy. Na przykład:

  • flock () w GFS/GFS2 nie można przerwać sygnałami .
  • fcntl () F_GETLK zwraca PID dowolnej blokady blokującej. Ponieważ jest to system plików klastra, ten PID może odnosić się do procesu w dowolnym węźle, w którym zamontowany jest system plików. Ponieważ celem tego interfejsu jest umożliwienie wysłania sygnału do procesu blokowania, nie jest to już możliwe.
  • Dzierżawy nie są obsługiwane przez moduł blokady lock_dlm (cluster), ale są obsługiwane, gdy są używane jako lokalny system plików
  • dnotify będzie działać na zasadzie „tego samego węzła”, ale jego użycie z GFS/GFS2 nie jest zalecane
  • inotify będzie również działać na zasadzie „tego samego węzła” i również nie jest zalecane (ale może zostać obsługiwane w przyszłości)
  • splice jest obsługiwane tylko w GFS2

Inną główną różnicą, która jest wspólna dla wszystkich podobnych klastrowych systemów plików, jest to, że mechanizm kontroli pamięci podręcznej, znany jako glocks (czyt. Gee-locks) dla GFS/GFS2, ma wpływ na cały klaster. Z każdym i-węzłem w systemie plików są powiązane dwa glocki. Jeden (nazywany iopen glock) śledzi, które procesy mają otwarty i-węzeł. Drugi (i-węzeł glock) kontroluje pamięć podręczną związaną z tym i-węzłem. Glock ma cztery stany, UN (odblokowany), SH (wspólny – blokada odczytu), DF (odroczony – blokada odczytu niekompatybilna z SH) i EX (wyłączny). Każdy z czterech trybów odwzorowuje bezpośrednio DLM .

W trybie EX i-węzeł może buforować dane i metadane (które mogą być „brudne”, tj. oczekujące na zapis zwrotny do systemu plików). W trybie SH i-węzeł może buforować dane i metadane, ale nie może być brudny. W trybie DF i-węzeł może buforować tylko metadane i znowu nie może być brudny. Tryb DF jest używany tylko do bezpośredniego wejścia/wyjścia. W trybie UN i-węzeł nie może buforować żadnych metadanych.

Aby operacje zmieniające dane lub metadane i-węzła nie kolidowały ze sobą, stosowana jest blokada EX. Oznacza to, że niektóre operacje, takie jak tworzenie/odłączanie plików z tego samego katalogu i zapisywanie do tego samego pliku, powinny być ogólnie ograniczone do jednego węzła w klastrze. Oczywiście wykonywanie tych operacji z wielu węzłów będzie działać zgodnie z oczekiwaniami, ale ze względu na konieczność częstego opróżniania pamięci podręcznych nie będzie zbyt wydajne.

Najczęściej zadawanym pytaniem dotyczącym wydajności GFS/GFS2 jest to, dlaczego wydajność serwerów e-mail może być niska. Rozwiązaniem jest rozbicie kolejki poczty na osobne katalogi i próba utrzymania (na tyle, na ile to możliwe) każdego węzła odczytu i zapisu w prywatnym zestawie katalogów.

Dziennikowanie

GFS i GFS2 są systemami plików z kronikowaniem ; a GFS2 obsługuje podobny zestaw trybów kronikowania jak ext3 . W data=writeback kronikowane są tylko metadane. Jest to jedyny tryb obsługiwany przez GFS, jednak możliwe jest włączenie kronikowania dla poszczególnych plików danych, ale tylko wtedy, gdy mają one zerowy rozmiar. Pliki kronikowane w GFS mają szereg ograniczeń, takich jak brak obsługi mmap lub sendfile, a także używają innego formatu na dysku niż zwykłe pliki. Istnieje również atrybut „inherit-journal”, który po ustawieniu w katalogu powoduje, że wszystkie pliki (i podkatalogi) utworzone w tym katalogu mają ustawioną flagę dziennika (lub odpowiednio dziedziczenia dziennika). Można tego użyć zamiast opcji montowania data=journal , którą obsługuje ext3 (a GFS/GFS2 nie).

GFS2 obsługuje również tryb data=ordered , który jest podobny do data=writeback, z tą różnicą, że brudne dane są synchronizowane przed zakończeniem każdego opróżniania dziennika. Zapewnia to, że bloki, które zostały dodane do i-węzła, będą miały zsynchronizowaną zawartość z powrotem z dyskiem, zanim metadane zostaną zaktualizowane w celu zarejestrowania nowego rozmiaru, a tym samym zapobiega pojawianiu się niezainicjowanych bloków w pliku w warunkach awarii węzła. Domyślnym trybem kronikowania jest data=ordered , aby dopasować domyślny tryb ext3 .

Od 2010 roku GFS2 nie obsługuje jeszcze trybu data=journal , ale (w przeciwieństwie do GFS) używa tego samego formatu na dysku zarówno dla plików zwykłych, jak i kronikowanych, a także obsługuje te same atrybuty kronikowania i dziedziczenia dziennika. GFS2 rozluźnia również ograniczenia dotyczące tego, kiedy plik może mieć swój dziennikowany atrybut zmieniany na dowolny czas, kiedy plik nie jest otwarty (również tak samo jak ext3 ).

Ze względu na wydajność każdy węzeł w GFS i GFS2 ma swój własny dziennik. W GFS dzienniki są zakresami dysku, w GFS2 dzienniki są zwykłymi plikami. Liczba węzłów, które mogą jednocześnie montować system plików, jest ograniczona liczbą dostępnych dzienników.

Cechy GFS2 w porównaniu z GFS

GFS2 dodaje szereg nowych funkcji, których nie ma w GFS. Oto podsumowanie tych funkcji, które nie zostały jeszcze wymienione w polach po prawej stronie tej strony:

  • System plików metadanych (naprawdę inny katalog główny) – patrz Kompatybilność i metasystem plików GFS2 poniżej
  • Punkty śledzenia specyficzne dla GFS2 są dostępne od wersji jądra 2.6.32
  • Interfejs limitów w stylu XFS jest dostępny w GFS2 od wersji jądra 2.6.33
  • Buforowanie list ACL jest dostępne w GFS2 od wersji 2.6.33
  • GFS2 obsługuje generowanie żądań „odrzucenia” dla żądań elastycznego udostępniania/SCSI TRIM
  • GFS2 obsługuje bariery I/O (domyślnie włączone, zakładając, że obsługuje je podstawowe urządzenie. Konfigurowalne od jądra 2.6.33 i nowszych)
  • FIEMAP ioctl (do wyszukiwania mapowań i-węzłów na dysku)
  • Obsługa splicingu (wywołań systemowych).
  • obsługa mmap/splice dla plików kronikowanych (włączona przy użyciu tego samego formatu na dysku, co w przypadku zwykłych plików)
  • Znacznie mniej dostrojeń (dzięki czemu konfiguracja jest mniej skomplikowana)
  • Uporządkowany tryb zapisu (zgodnie z ext3, GFS ma tylko tryb zapisu zwrotnego)

Kompatybilność i metasystem plików GFS2

GFS2 został zaprojektowany tak, aby aktualizacja z GFS była prostą procedurą. W tym celu większość struktury na dysku pozostała taka sama jak GFS, w tym big-endian . Jest jednak kilka różnic:

  • GFS2 ma „meta system plików”, przez który procesy uzyskują dostęp do plików systemowych
  • GFS2 używa tego samego formatu na dysku dla plików kronikowanych, jak dla zwykłych plików
  • GFS2 używa zwykłych (systemowych) plików dla dzienników, podczas gdy GFS używa specjalnych zakresów
  • GFS2 ma kilka innych plików systemowych „ per_node ”.
  • Układ i -węzła jest (bardzo nieznacznie) inny
  • Układ bloków pośrednich różni się nieznacznie

Systemy kronikowania GFS i GFS2 nie są ze sobą kompatybilne. Aktualizacja jest możliwa za pomocą narzędzia ( gfs2_convert ), które jest uruchamiane z systemem plików w trybie off-line w celu aktualizacji metadanych. Niektóre zapasowe bloki w dziennikach GFS są używane do tworzenia (bardzo małych) per_node wymaganych przez GFS2 podczas procesu aktualizacji. Większość danych pozostaje na swoim miejscu.

„Metasystem plików” GFS2 nie jest samodzielnym systemem plików, ale alternatywnym katalogiem głównym głównego systemu plików. Chociaż zachowuje się jak „normalny” system plików, jego zawartość to różne pliki systemowe używane przez GFS2 i zwykle użytkownicy nie muszą go przeglądać. Narzędzia GFS2 montują i odmontowują metasystem plików zgodnie z wymaganiami, w tle.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=GFS2&oldid=1122120640 ”