Równoległy wirtualny system plików
| Oryginalni autorzy | Clemson University , Argonne National Laboratory , Ohio Supercomputer Center |
|---|---|
| Deweloperzy | Walt Ligon, Rob Ross, Phil Carns, Pete Wyckoff, Neil Miller, Rob Latham, Sam Lang, Brad Settlemyer |
| Pierwsze wydanie | 2003 |
| Wersja stabilna | 2.8.2 / 1 stycznia 2010
|
| Napisane w | C |
| System operacyjny | Jądro Linuksa |
| Licencja | LGPL |
| Strona internetowa |
Równoległy wirtualny system plików ( PVFS ) to równoległy system plików typu open source . Równoległy system plików to rodzaj rozproszonego systemu plików , w którym dane w plikach są dystrybuowane na wielu serwerach i zapewnia równoczesny dostęp wielu zadaniom aplikacji równoległej. PVFS został zaprojektowany do użytku w obliczeniach klastrowych na dużą skalę . PVFS koncentruje się na wysokiej wydajności dostępu do dużych zbiorów danych. Składa się z procesu serwera i biblioteki klienckiej, z których obie są napisane w całości z kodu na poziomie użytkownika. Linuksa _ Moduł jądra i proces pvfs-client pozwalają na zamontowanie systemu plików i używanie go ze standardowymi narzędziami. Biblioteka kliencka zapewnia dostęp o wysokiej wydajności za pośrednictwem interfejsu przesyłania komunikatów (MPI). PVFS jest opracowywany wspólnie przez The Parallel Architecture Research Laboratory na Clemson University i Wydział Matematyki i Informatyki w Argonne National Laboratory oraz Ohio Supercomputer Center . Rozwój PVFS został sfinansowany przez Centrum Lotów Kosmicznych NASA Goddard , The DOE Office of Science Advanced Scientific Computing Research , programy NSF PACI i HECURA oraz inne agencje rządowe i prywatne. PVFS jest teraz znany jako OrangeFS w swojej najnowszej gałęzi programistycznej.
Historia
PVFS został po raz pierwszy opracowany w 1993 roku przez Walta Ligona i Erica Blumera jako równoległy system plików dla Parallel Virtual Machine (PVM) w ramach grantu NASA na badanie wzorców we / wy programów równoległych. PVFS w wersji 0 był oparty na Vesta, równoległym systemie plików opracowanym w IBM TJ Watson Research Center . Począwszy od 1994 roku Rob Ross ponownie napisał PVFS, aby korzystał z protokołu TCP/IP i odszedł od wielu oryginalnych punktów projektowych Vesta. PVFS w wersji 1 był skierowany do klastra DEC Alpha połączonych w sieć za pomocą przełączanego FDDI . Podobnie jak Vesta, PVFS rozdzielał dane na wiele serwerów i zezwalał na żądania wejścia/wyjścia na podstawie widoku pliku, który opisywał wzorzec dostępu krokowego. W przeciwieństwie do Westy, paski i widok nie były zależne od wspólnego rozmiaru rekordu. Badania Rossa koncentrowały się na planowaniu dyskowych operacji we/wy, gdy wielu klientów uzyskiwało dostęp do tego samego pliku. Poprzednie wyniki pokazały, że preferowane jest planowanie zgodnie z najlepszym możliwym wzorcem dostępu do dysku. Ross wykazał, że zależy to od wielu czynników, w tym względnej szybkości sieci i szczegółów widoku pliku. W niektórych przypadkach preferowane było planowanie oparte na ruchu sieciowym, dlatego dynamicznie dostosowywalny harmonogram zapewniał najlepszą ogólną wydajność.
Pod koniec 1994 roku Ligon spotkał się z Thomasem Sterlingiem i Johnem Dorbandem w Goddard Space Flight Center (GSFC) i omówił ich plany budowy pierwszego komputera Beowulf . Uzgodniono, że PVFS zostanie przeniesiony na Linuksa i będzie dostępny na nowej maszynie. Przez kilka następnych lat Ligon i Ross współpracowali z grupą GSFC, w skład której wchodzili Donald Becker, Dan Ridge i Eric Hendricks. W 1997 roku na spotkaniu klastrów w Pasadenie CA Sterling poprosił o udostępnienie PVFS jako pakietu open source.
PVFS2
W 1999 roku Ligon zaproponował opracowanie nowej wersji PVFS, początkowo nazwanej PVFS2000, a później PVFS2. Projekt został początkowo opracowany przez Ligona, Rossa i Phila Carnsa. Ross ukończył doktorat w 2000 roku i przeniósł się do Argonne National Laboratory , a projekt i wdrożenie wykonali Ligon, Carns, Dale Witchurch i Harish Ramachandran z Clemson University , Ross, Neil Miller i Rob Latham z Argonne National Laboratory i Pete Wyckoff z Ohio Supercomputer Center. Nowy system plików został wydany w 2003 roku. Nowy projekt obejmował serwery obiektowe, rozproszone metadane, widoki oparte na MPI, obsługę wielu typów sieci oraz architekturę oprogramowania ułatwiającą eksperymentowanie i rozszerzanie.
Wersja 1 PVFS została wycofana w 2005 roku. Wersja 2 PVFS jest nadal obsługiwana przez firmy Clemson i Argonne. Carns ukończył doktorat w 2006 roku i dołączył do Axicom, Inc., gdzie PVFS został wdrożony na kilku tysiącach węzłów do eksploracji danych. W 2008 roku Carns przeniósł się do Argonne i kontynuuje pracę nad PVFS wraz z Rossem, Lathamem i Samem Langiem. Brad Settlemyer opracował podsystem lustrzany w Clemson, a później szczegółową symulację PVFS wykorzystywaną do badania nowych rozwiązań. Settlemyer jest teraz w Oak Ridge National Laboratory . w 2007 roku Argonne zaczął przenosić PVFS do użytku na IBM Blue Gene /P. W 2008 Clemson zaczął opracowywać rozszerzenia do obsługi dużych katalogów małych plików, ulepszeń bezpieczeństwa i możliwości redundancji. Ponieważ wiele z tych celów było sprzecznych z rozwojem Blue Gene, utworzono drugą gałąź drzewa źródłowego CVS i nazwano ją „Orange”, a oryginalną gałąź nazwano „Blue”. PVFS i OrangeFS ściśle się śledzą, ale reprezentują dwie różne grupy wymagań użytkowników. Większość poprawek i aktualizacji dotyczy obu gałęzi. Od 2011 OrangeFS jest główną linią rozwojową.
Cechy
W klastrze korzystającym z PVFS węzły są wyznaczone jako jeden lub więcej z następujących: klient, serwer danych, serwer metadanych. Serwery danych przechowują dane plików. Serwery metadanych przechowują metadane, w tym informacje o statystykach, atrybuty i uchwyty plików danych, a także wpisy do katalogów. Klienci uruchamiają aplikacje korzystające z systemu plików, wysyłając żądania do serwerów przez sieć.
Projektowanie obiektowe
PVFS ma projekt oparty na obiektach, co oznacza, że wszystkie żądania serwera PVFS dotyczyły obiektów zwanych przestrzeniami danych. Przestrzeń danych może być używana do przechowywania danych pliku, metadanych pliku, metadanych katalogu, pozycji katalogu lub dowiązań symbolicznych. Każda przestrzeń danych w systemie plików ma unikalny uchwyt. Każdy klient lub serwer może sprawdzić, który serwer przechowuje przestrzeń danych na podstawie uchwytu. Przestrzeń danych składa się z dwóch komponentów: strumienia bajtów i zestawu par klucz/wartość. Strumień bajtów to uporządkowana sekwencja bajtów, zwykle używana do przechowywania danych pliku, a pary klucz/wartość są zwykle używane do przechowywania metadanych. Projektowanie obiektowe stało się typowe dla wielu rozproszonych systemów plików, w tym Luster , Panasas i pNFS .
Separacja danych i metadanych
PVFS jest zaprojektowany tak, aby klient mógł raz uzyskać dostęp do serwera w celu uzyskania metadanych, a następnie uzyskać dostęp do serwerów danych bez dalszej interakcji z serwerami metadanych. Usuwa to krytyczne wąskie gardło z systemu i pozwala na znacznie większą wydajność.
Żądania oparte na MPI
Kiedy program kliencki żąda danych z PVFS, może dostarczyć opis danych oparty na MPI_Datatypes. Ta funkcja umożliwia bezpośrednią implementację widoków plików MPI przez system plików. MPI_Datatypes może opisywać złożone, nieciągłe wzorce danych. Serwer PVFS i kody danych implementują przepływy danych, które efektywnie przesyłają dane między wieloma serwerami i klientami.
Obsługa wielu sieci
PVFS wykorzystuje warstwę sieciową o nazwie BMI, która zapewnia nieblokujący interfejs wiadomości zaprojektowany specjalnie dla systemów plików. BMI ma wiele modułów implementacyjnych dla wielu różnych sieci używanych w obliczeniach o wysokiej wydajności, w tym TCP/IP, Myrinet , Infiniband i portale .
Serwery bezstanowe (bez blokady).
Serwery PVFS są zaprojektowane tak, aby nie dzieliły żadnego stanu między sobą ani z klientami. W przypadku awarii serwera inny można łatwo uruchomić ponownie w jego miejsce. Aktualizacje są wykonywane bez użycia blokad.
Implementacja na poziomie użytkownika
Klienci i serwery PVFS działają na poziomie użytkownika. Modyfikacje jądra nie są potrzebne. Istnieje opcjonalny moduł jądra, który umożliwia montowanie systemu plików PVFS, jak każdy inny system plików, lub programy mogą łączyć się bezpośrednio z interfejsem użytkownika, takim jak MPI-IO lub interfejs podobny do Posix . Dzięki tym cechom PVFS jest łatwy w instalacji i mniej podatny na awarie systemu.
Interfejs na poziomie systemu
Interfejs PVFS jest przeznaczony do integracji na poziomie systemu. Ma podobieństwa z Linux VFS , dzięki czemu jest łatwy do wdrożenia jako montowalny system plików, ale można go równie łatwo dostosować do interfejsów na poziomie użytkownika, takich jak interfejsy typu MPI-IO lub Posix . Udostępnia wiele funkcji podstawowego systemu plików, dzięki czemu interfejsy mogą z nich korzystać w razie potrzeby.
Architektura
PVFS składa się z 4 głównych komponentów i szeregu programów użytkowych. Komponenty to serwer PVFS2, pvfslib, rdzeń klienta PVFS i moduł jądra PVFS. Narzędzia obejmują narzędzie do zarządzania karmą, narzędzia (np. pvfs-ping, pvfs-ls, pvfs-cp itp.), które działają bezpośrednio w systemie plików bez użycia modułu jądra (głównie do konserwacji i testowania). Innym kluczowym punktem projektu jest protokół PVFS, który opisuje komunikaty przekazywane między klientem a serwerem, chociaż nie jest to ściśle komponent.
Serwer PVFS2
Serwer PVFS działa jako proces w węźle wyznaczonym jako węzeł we/wy. Węzły we/wy są często węzłami dedykowanymi, ale mogą być zwykłymi węzłami, które również uruchamiają zadania aplikacji. Serwer PVFS zwykle działa jako root, ale można go uruchomić jako użytkownik, jeśli jest to preferowane. Każdy serwer może zarządzać wieloma odrębnymi systemami plików i jest przeznaczony do pracy jako serwer metadanych, serwer danych lub jedno i drugie. Cała konfiguracja jest kontrolowana przez plik konfiguracyjny określony w wierszu poleceń, a wszystkie serwery zarządzające danym systemem plików używają tego samego pliku konfiguracyjnego. Serwer odbiera żądania przez sieć, wykonuje żądanie, które może obejmować dyskowe operacje we/wy i odpowiada pierwotnemu żądającemu. Żądania zwykle pochodzą z węzłów klienckich uruchamiających zadania aplikacji, ale mogą pochodzić z innych serwerów. Serwer składa się z procesora żądań, warstwy zadań, Trove, BMI i warstw przepływu.
Procesor żądań
Procesor żądań składa się z głównej pętli procesu serwera i pewnej liczby maszyn stanowych. Maszyny stanowe są oparte na prostym języku opracowanym dla PVFS, który zarządza współbieżnością w obrębie serwera i klienta. Maszyna stanów składa się z pewnej liczby stanów, z których każdy albo uruchamia funkcję działania stanu C, albo wywołuje zagnieżdżoną (podprogram) maszynę stanów. W obu przypadkach kody powrotu wybierają stan, do którego należy przejść dalej. Funkcje akcji stanu zwykle przesyłają zadanie za pośrednictwem warstwy zadań, która wykonuje jakiś rodzaj operacji we/wy za pośrednictwem Trove lub BMI. Zadania są nieblokujące, więc po wydaniu zadania wykonanie automatu stanowego jest odraczane, aby inny automat stanowy mógł uruchomić obsługę innego żądania. Po zakończeniu zadań główna pętla ponownie uruchamia skojarzoną maszynę stanów. Procesor żądań ma maszyny stanowe dla każdego z różnych typów żądań zdefiniowanych w protokole żądań PVFS oraz pewną liczbę zagnieżdżonych maszyn stanowych używanych wewnętrznie. Architektura maszyny stanów sprawia, że stosunkowo łatwo jest dodawać nowe żądania do serwera w celu dodania funkcji lub optymalizacji pod kątem określonych sytuacji.
Warstwa pracy
Warstwa Job zapewnia wspólny interfejs do przesyłania zadań Trove, BMI i flow oraz raportowania ich ukończenia. Implementuje również harmonogram żądań jako zadanie nieblokujące, które rejestruje, jakiego rodzaju żądania są w toku na jakich obiektach i zapobiega błędom spójności wynikającym z jednoczesnego działania na tych samych danych pliku.
Skarb
Trove zarządza wejściami/wyjściami do obiektów przechowywanych na lokalnym serwerze. Trove działa na zbiorach przestrzeni danych. Kolekcja ma własną niezależną przestrzeń uchwytów i jest używana do implementacji różnych systemów plików PVFS. Przestrzeń danych jest obiektem PVFS i ma swój własny unikalny (w ramach kolekcji) uchwyt i jest przechowywana na jednym serwerze. Uchwyty są mapowane na serwery za pomocą tabeli w pliku konfiguracyjnym. Przestrzeń danych składa się z dwóch części: strumienia bajtów i zestawu par klucz/wartość. Strumień bajtów jest ciągiem bajtów o nieokreślonej długości i służy do przechowywania danych pliku, zwykle w pliku w lokalnym systemie plików. Pary klucz/wartość są używane do przechowywania metadanych, atrybutów i pozycji katalogu. Trove ma dobrze zdefiniowany interfejs i może być wdrażany na różne sposoby. Do tej pory jedyną implementacją była implementacja Trove-dbfs, która przechowuje strumienie bajtów w plikach i parach klucz/wartość w Berkeley DB . Operacje Trove są nieblokujące, API zapewnia funkcje post do odczytu lub zapisu różnych komponentów i funkcji do sprawdzenia lub oczekiwania na zakończenie.
BMI
przepływy
pvfslib
Rdzeń klienta PVFS
Moduł jądra PVFS
Zobacz też
Linki zewnętrzne
- Oficjalna strona internetowa
- Orange File System — gałąź Parallel Virtual File System
- Architektura równoległego systemu plików nowej generacji
- Archiwum wideo