NFSp: rozproszony i równoległy serwer NFS
Transkrypt
NFSp: rozproszony i równoległy serwer NFS
NFSp: rozproszony i równoległy serwer NFS ∗ Piotr Rak1, Maciej Sikora2 , Przemysław Sowa1 , Piotr Wachowski2 Wydział Inżynierii Mechanicznej i Informatyki Kierunek Informatyka, 1 rok III, 2 rok IV Streszczenie Wysoce wydajny system plików jest zwykle sprawa˛ kluczowa˛ dla dużych instalacji klastrowych, w których setki lub nawet tysiace ˛ w˛ezłów stale operuja˛ na ogromnych zbiorach danych. Podczas gdy wi˛ekszość rozwiazań ˛ używa specjalnego sprz˛etu i protokołów, to NFSp (ang. NFS Parallel) stara si˛e poprawić wydajność standardowego systemu NFS, oszcz˛edzajac ˛ pieniadze ˛ i wysiłek wymagany przy instalacji dedykowanego oprogramowania. Praca ta przedstawia model rozproszonego serwera NFS, omawia implementacj˛e jego prototypu i ocen˛e wydajności oraz kierunek rozwoju projektu. 1 Wst˛ep Wraz z rozwojem nowych technologii i spadkiem cen sprz˛etu komputerowego, klastry wcia˛ż zwi˛ekszaja˛ swoja˛ wielkość i możliwości, rozwiazuj ˛ ac ˛ coraz bardziej zło żone zadania. Ciagły ˛ wzrost rozmiaru klastrów spowodował pojawienie si˛e nowego problemu: jak zarzadzać ˛ przechowywaniem rosnacej ˛ ilości danych? Biorac ˛ pod uwag˛e potencjalne waskie ˛ gardło, jakim sa˛ tradycyjne sieciowe systemy plików (NFS[5]) oraz uwzgl˛edniajac ˛ fakt, że kosztowne rozwiazania ˛ technologiczne nie pasuja˛ do filozofii b˛edacej ˛ podstawa˛ klastrów typu Beowulf, twórcy klastrowych systemów plików skłaniaja˛ si˛e do rozdzielania magazynu danych na wi˛eksza˛ liczb˛e w˛ezłów. W celu uzyskania równowagi pomi˛edzy wydajnościa˛ a prostota˛ administracji, projekt NFSp[4] proponuje rozproszona˛ wersj˛e tradycyjnego serwera NFS, który znacznie lepiej radzi sobie z obsługa˛ dużej liczby równoczesnych żadań ˛ i jednocześnie pozostaje zgodny z klientami systemu NFS obecnymi na każdym systemie rodziny Unix. NFSp jest alternatywa˛ dla obecnie używanych systemów w średnich lub dużych klastrach. Wykorzystuje on stabilny i dobrze znany protokół oraz nie wymaga aktualizacji oprogramowania czy zakupu drogiego sprz˛etu. Praca ta zorganizowana jest w nast˛epujacy ˛ sposób: rozdział drugi przedstawia szczegóły modelu NFSp, w rozdziale 3 opisano proponowany model powielania serwerów a w rozdziale 4 wyniki przeprowadzonych eksperymentów. Kolejny fragment opisuje perspektywy rozwoju projektu, a całość kończy si˛e podsumowaniem. ∗ Jest to połaczony ˛ projekt pomi˛edzy Instytutem Informatyki Teoretycznej i Stosowanej Politechniki Cz˛estochowskiej, Laboratoire ID (Grenbole, Francja) oraz Universidade Federal do Rio Grande do Sul (Brazylia). Wi˛ecej na: http://nfsp.imag.fr 1 1 (4). wysłanie żądania 2 (5). wysłanie żądania do właściwego węzła we/wy 3 (6). wysyłanie odpowiedzi metaserwer 1 4 2 5 Strzałki 1−3 przedstawiają pierwsze żądanie. Strzałki 4−6 przedstawiają inne żądanie. Stacje mogą być klientami i/lub węzłami we/wy klient klient węzeł we/wy +klient 3 węzeł we/wy Kilka węzłow we/wy może być uruchomionych na jednej fizycznej maszynie. 6 Rys. 1: Przesyłanie żadań ˛ w NFSp 2 NFSp System NFSp (NFS Parallel) jest rozszerzeniem tradycyjnej implementacji NFS. Rozdziela on funkcjonalność serwera NFS na kilka procesów działajacych ˛ na klastrze[4]. Idea˛ NFSp jest usprawnienie wydajności i skalowalności przy jednoczesnym zachowaniu pełnej zgodności ze standardem NFS, co oznacza zachowanie kompatybilności ze wszystkimi klientami tego systemu plików. Wzorowany na PVFS[1], NFSp wykorzystuje w˛ezły wejścia/wyjścia, działajace ˛ na kilku komputerach wchodzacych ˛ w skład klastra, w celu rozproszenia pojedynczego pliku na zbiorze dysków, poprzez mechanizm podobny do technologii RAID-0. Dane stanowiace ˛ plik rozdzielane sa˛ na oddzielne bloki, które nast˛epnie przechowuje sa˛ na kilku niezależnych komputerach. Kiedy nast˛epuje odczyt pliku, odczytywanych jest wiele bloków, które znajduja˛ si˛e na osobnych komputerach, co w efekcie zwi˛eksza wydajność, ponieważ całkowita przepustowość jest suma˛ przepustowości poszczególnych w˛ezłów. W przypadku NFSp jednostka˛ podziału jest blok danych NFS – zazwyczaj 8192 bajty. Serwer NFSp spełnia rol˛e serwera NFS, ale ze wzgl˛edu na to, że przechowuje jedynie opis danych nazywamy go metaserwerem. Dla klienta wyglada ˛ on jak zwykły serwer NFS. Kiedy nadchodzi żadanie ˛ odczytania bloku danych, metaserwer, w odró żnieniu od pierwowzoru, nie wykonuje go, ale przekazuje do odpowiedniego w˛ezła we/wy, który wykonuje żadan ˛ a˛ operacj˛e i wysyła dane bezpośrednio do klienta1 . Rysunek 1 przedstawia ten mechanizm. Informacje opisujace ˛ gdzie dany plik jest przechowywany sa˛ zapisane w lokalnym systemie plików metaserwera, b˛edac ˛ cz˛eścia˛ metadanych (podobnie jak czas utworzenia, właściciel, prawa dost˛epu, rozmiar, itd.). Projekt NFSp zezwala na wydajne zrównoleglenie równoczesnych operacji odczytu, dzi˛eki temu, że różne żadania ˛ moga˛ odnosić sie do różnych w˛ezłów we/wy. Jednak operacja zapisu nadal musi być wykonana przez centralny metaserwer, poniewa ż dane pochodza˛ od klientów, którzy z założenia używaja˛ tradycyjnego protokołu NFS. Rozwiazaniem ˛ tego problemu sa˛ rozproszone metaserwery, które zostały omówione w kolejnej sekcji. 1 Aby zapewnić takie zachowanie potrzebne moga˛ być techniki podszywania si˛ e pod adresy IP, ponieważ klient oczekuje odpowiedzi od serwera, a nie od w˛ezła we/wy, o którego istnieniu nie ma poj˛ecia. 2 widok globalnego metaserwera węzły we/wy klienci metaserwery 111111111111111111 000000000000000000 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 Rys. 2: Model rozproszonych metaserwerów 3 Model powielania serwerów Klasyczny NFS składa si˛e z jednego serwera, z którym nawiazuj ˛ a˛ połaczenia ˛ komputery klienckie. Naszym celem jest próba zwi˛ekszenia skalowalności i wydajności systemu poprzez powielenie serwera na kilku maszynach. Dwa główne da˛żenia tego rozwiazania ˛ to udost˛epnienie klientowi kilku punktów wejścia (w efekcie umożliwia to użycie wi˛ekszej przepustowości podczas operacji zapisu) i zrównoważenie obcia˛żenia poprzez rozłożenie go na kilka metaserwerów. Najważniejszym założeniem jest odpowiednie pogrupowanie w˛ezłów tak, aby każda instancja metaserwera obsługiwała określona˛ ilość klientów. Na przykład, jeśli metaserwer jest powielony na 10 komputerach i mamy 50 w˛ezłów, wtedy każda instancja metaserwera b˛edzie mogła obsłużyć (uwzgl˛edniajac ˛ równy podział obcia˛żenia) do 5 klientów. 3.1 Powielenie NFSp Dla każdej grupy w˛ezłów korzystajacych ˛ z danego metaserwera sytuacja jest bardzo zbliżona do oryginalnego modelu NFS, tzn. odwołania do systemu plików sa˛ kierowane do jednego serwera. Oprócz poprawionej skalowalności, rozwiazanie ˛ to umożliwia znaczne zwi˛ekszenie wydajności, ponieważ mniej obcia˛żony serwer jest w stanie szybciej realizować poszczególne żadania. ˛ Metaserwery współpracuja˛ ze soba˛ za pośrednictwem sieci tworzac ˛ wspólnie jeden globalny metaserwer (zob. rys. 2). Dzi˛eki rozło żeniu obcia˛żenia operacji wykonywanych na metadanych, pojedynczy serwer nie zostanie zarzucony wielokrotnymi żadaniami. ˛ Dodatkowo to rozwiazanie ˛ pozwala na przyszłe udoskonalenia w zakresie tolerancji bł˛edów, automatycznego wykonywania kopii zapasowych, itp. 3.2 Model spójności Powielenie metaserwera wymaga utrzymania spójności pomi˛edzy jego wieloma instancjami. Aby tego dokonać bez ponoszenia wi˛ekszych strat (np. wynikajacymi ˛ z obcia˛żenia sieci komunikatami kontrolnymi), opieramy si˛e na luźnym modelu spójności opartym o właściwości zaobserwowane w typowych klastrowych środowiskach obliczeniowych. 3 Zwykle procedura używania rozproszonego programu na klastrze polega na alokacji określonej liczby w˛ezłów lub partycji i uruchomienia go na nich. Oczywiście, rozmiar partycji oraz czas alokacji ściśle zależa˛ od uruchamianej aplikacji, jak również od lokalnej polityki zażadania ˛ siecia˛ (w której dany klaster si˛e znajduje). Polityka ta to mi˛edzy innymi uprawnienia użytkowników, ich priorytety, itp. Dodatkowo, każdy użytkownik pracuje na swym prywatnym koncie gdzie znajduja˛ si˛e jego pliki, zatem cz˛eść plików modyfikowanych przez jedna˛ aplikacj˛e zwykle różni si˛e od tych samych plików modyfikowanych przez inna aplikacj˛e. Oznacza to, że nie musimy mieć wszystkich plików dost˛epnych wsz˛edzie przez cały czas. Jako protokół zgodności dla rozproszonego metaserwera NFSp u żywa zmodyfikowanego protokołu Lazy Release Consistency[2] (LRC) jakiego użyto w TreadMarks rozproszonym systemie współdzielenia pami˛eci[3]. Jego podstawowa˛ zasada˛ jest odłożenie sprawdzenia spójności danych do czasu aż klient rzeczywiście ich potrzebuje. Podobnie jak TreadMarks, gdzie spójność jest sprawdzana tylko wtedy, kiedy nowy klient odwołuje si˛e do współdzielonego segmentu (który mógł być zmodyfikowany przez innego klienta), nasza propozycja systemu sprawdza plik tylko wtedy, kiedy klient bezpośrednio si˛e do niego odwoła. Komunikaty sprawdzania spójności sa˛ wysyłane w momencie wystapienia ˛ bł˛edu, który może oznaczać, że metadane odwołujace ˛ si˛e do tego pliku uległy zmianie. Na przykład, ˛ niemożność jeśli wynikiem operacji otwarcia pliku jest kod bł˛edu ENOENT - sygnalizujacy odnalezienia pliku, możliwe, że plik został utworzony przez klienta podłaczonego ˛ do innego metaserwera. Oznacza to, że właściwe metadane znajduja˛ si˛e na tym konkretnym metaserwerze. W takim wypadku, metadane musza˛ zostać skopiowane do systemu plików bieżacego ˛ metaserwera wtedy dopiero operacja (otwarcia pliku) może być wykonana. W pewnych przypadkach operacja może być wykonana nawet wtedy, gdy metadane sa˛ nieaktualne. Na przykład, jeśli klient chce odczytać pierwsze 4kB pliku, którego metadane wskazuja,˛ że ma on długość 10kB, wtedy operacja może być wykonana nawet jeśli plik został w mi˛edzyczasie powi˛ekszony (przez innego klienta) do 100kB. Należy zauważyć, że nawet jeśli metadane sa˛ nieaktualne, zawartość pliku (tj. "właściwe" dane) sa˛ przechowywane na w˛ezłach we/wy, wi˛ec sa˛ aktualizowane przez operacj˛e, która zwi˛ekszyła rozmiar pliku. Innymi słowy, nawet jeśli metadane sa˛ nieaktualne, klient odczyta poprawna˛ zawartość pliku. Oczywiście, niektóre operacje takie jak usuni˛ecie pliku musza˛ być koniecznie odnotowane na wszystkich metaserwerach żeby zapobiec odwoływaniu si˛e do danych, które nie sa˛ prawidłowe. Zdajemy sobie spraw˛e z tego, ale takie operacje wyst˛epuja˛ dość rzadko, głównie podczas startu/zatrzymania aplikacji, przez co nie powinno to znaczaco ˛ wpłynać ˛ na wydajność. Jedyna˛ kwestia˛ jest decyzja, z którym metaserwerem skontaktować si˛e kiedy metadane sa˛ niekompletne/nieaktualne. Można rozważać kilka rozwiazań, ˛ takich jak ustalenie powiazań ˛ pomi˛edzy sasiednimi ˛ metaserwerami i przeszukiwanie od najbliższego do najdalszego. Inna˛ możliwościa˛ jest ustawienie metaserwerów hierarchicznie w postaci drzewa. Jest to obecnie jednym z przedmiotów naszych rozważań. 4 Sumaryczna przepustowość [MB/s] 120 100 80 60 zwykły NFS pojedynczy NFSp rozproszony NFSp 40 20 0 2 4 6 8 10 12 14 Liczba klientów 16 18 20 Rys. 3: Sumaryczna przepustowość dla odczytu 4 Ocena wydajności Aby udowodnić działanie rozproszonego modelu, zaimplementowany został prototyp powielonego metaserwera bazujacy ˛ na kodzie NFSp, który z kolei wywodzi si˛e od projektu uNFS b˛edacego ˛ implementacja˛ NFS dla Linuksa. Jest to zwykły program przestrzeni użytkownika - obecnie system Linux wykorzystuje serwer b˛ed acy ˛ modułem jadra. ˛ Główna˛ intencja˛ testów było wyznaczenie wzrostu wydajności, uzyskanego poprzez rozłożenie obcia˛żenia metaserwera na kilka powielonych instancji. Oryginalna implementacja NFSp, została rozszerzona o unikalne adresy każdego metaserwera oraz komunikacj˛e miedzy nimi. Aby zachować prostot˛e zmian, do transferu danych wykorzystaliśmy warstw˛e RPC - używana˛ również przez klasyczny NFS. Dzi˛eki temu całość komunikatów transmitowana jest w ujednolicony sposób, ale minusem tego rozwiazania ˛ jest wi˛ekszy narzut w porównaniu z dedykowanym protokołem. Testy zostały wykonane na klastrze i-cluster umieszczonym w Laboratoire ID. Na system składa si˛e 225 w˛ezłów z procesorami Pentium III 733 MHz oraz dyskami twardymi o pojemności 15 GB (IDE). Całość połaczona ˛ jest siecia˛ FastEthernet i pracuje pod kontrola˛ systemu Linux z jadrem ˛ 2.4. 4.1 Wydajność operacji odczytu Przeprowadzony został eksperyment, majacy ˛ na celu ocen˛e wydajności zaimplementowanego prototypu oraz porównanie uzyskanych osiagów ˛ z poprzednia˛ wersja˛ NFSp. Pierwszy test polegał na sprawdzeniu operacji odczytu rozproszonej na w˛ezły we/wy. Eksperyment polegał na odczycie dużego pliku, wykonywanym równolegle przez wszystkich klientów. W tym celu stworzony został plik o wielkość 1 GB, a na w˛ezłach obliczeniowych uruchomiono komend˛e dd if=file of=/dev/null bs=1M count=1024. Przed eksperymentem nie wymuszono aktualizacji metadanych na wszystkich serwerach, ponieważ czas odczytu pliku jest nieporównywalnie wi˛ekszy niż koszt synchronizacji metadanych. System testowy składał si˛e z 12 w˛ezłów we/wy, 7 metaserwerów i 21 klientów (co daje 3 klientów na 1 metaserwer) – w sumie 40 w˛ezłów. 5 Sumaryczna przepustowość [MB/s] 60 55 50 45 40 35 30 25 zwykły NFS rozproszony NFSp 20 15 10 5 2 4 6 8 10 12 14 Liczba klientów 16 18 20 Rys. 4: Sumaryczna przepustowość dla zapisu Wykres przedstawiony na rysunku 3 porównuje sumaryczna˛ przepustowość odczytu uzyskana˛ przez pojedynczy serwer NFSp z wydajnościa˛ rozproszonych metaserwerów. Jak można było przewidzieć, wiele instancji metaserwera zapewniło równowa żenie obcia˛żenia generowanego przez klientów i pozwoliło uzyskać wi˛eksza˛ przepustowość. Jak wykazano w pracy[4], wydajność pojedynczego metaserwera jest ograniczona pr˛edkościa˛ przetwarzania procesora. W modelu rozproszonym mo żemy zaobserwować, że wydajność osiaga ˛ maksimum, gdy liczba klientów jest równa liczbie w˛ezłów we/wy. Jako alternatywna˛ form˛e oceny, możemy rozważyć miar˛e wydajności dla każdego z klientów w relacji do maksymalnej przepustowości sieci dost˛epnej dla pojedynczego w˛ezła. Przy przepustowości sieci równej 11 MB/s (FastEthernet) uzyskano praktycznie 100% wzrost efektywności dla 10 klientów. Przy dużej liczbie klientów krzywa spłaszcza si˛e i stabilizuje w granicach 110 MB/s, co oznacza 50% efektywności dla 21 klientów. Dla porównania, klasyczny serwer NFS osiaga ˛ tylko 4% wydajności z taka˛ sama˛ liczba˛ (21) klientów, ponieważ pojedyncze łacze ˛ b˛edzie zawsze ograniczone do 11 MB/s. 4.2 Wydajność operacji zapisu Podobny eksperyment został przeprowadzony, aby przetestować zapis. Każdy klient zapisywał 1GB danych do oddzielnego pliku. Porównanie z oryginalna˛ implementacja˛ NFSp nie jest znaczace ˛ w tym przypadku, ponieważ, jak wspominaliśmy wcześniej, dla pojedynczego metaserwera zapis jest scentralizowany, tak samo jak w zwykłym NFS. Wyniki testu przedstawia rysunek 4. Eksperyment został wykonany tak, aby (kiedy to możliwe) wykorzystana była maksymalna liczba metaserwerów (na przykład dla 7 klientów, każdy klient łaczy ˛ si˛e z odr˛ebnym metaserwerem). Krzywa oznaczajaca ˛ wynik rozproszonego NFSp wyraźnie dzieli si˛e na 3 fragmenty, oddzielone poprzez spadki wydajności. Wyst˛epuja˛ one za każdym razem, gdy liczba klientów osiagała ˛ wielokrotność liczby metaserwerów. Jest to spowodowane tym, że pojedynczy metaserwer musi nagle obsłużyć wi˛eksza˛ liczb˛e klientów niż pozostałe. Dla przykładu wydajność zwi˛eksza si˛e konsekwentnie do 7 klientów, ponieważ wtedy każdy z metaserwerów jest połaczony ˛ z najwyżej jednym klientem. Kiedy dodamy ósmego klienta, pierwszy metaserwer zacznie obsługiwać dwóch klientów, którzy dziela˛ przepustowość serwera i w rezultacie obni żaja˛ 6 wydajność. Ponownie możemy zauważyć przewag˛e posiadania wielu punktów wejścia dla klientów, a zwłaszcza w przypadku operacji zapisu. Z jednym metaserwerem, szybkość zapisu jest ograniczona głównie przez pojedyncze połaczenie ˛ sieciowe i b˛edzie przedstawiać najniższa˛ wartość dla dowolnej liczby klientów. Jeśli rozważymy wynik osiagany ˛ przez poszczególnych klientów, powielony model prezentuje wydajność rz˛edu 33% w danej konfiguracji, w przeciwieństwie dla 9% osiaganych ˛ przez scentralizowany serwer. 5 Kierunki dalszych prac Od pewnego czasu na Politechnice Cz˛estochowskiej tworzona jest nowa wersja NFSp, oparta na kodzie serwera NFS z jadra ˛ systemu Linux w wersji 2.6.16. Po przeniesieniu metaserwera do przestrzeni jadra ˛ planowany jest kolejny etap prac, który ma na celu wyeliminowanie słabych punktów omawianego w tej pracy prototypu. Podstawowym ulepszeniem b˛edzie dodanie obsługi protokołu NFS wersji 3[6], co pozwoli m. in. zwi˛ekszyć wydajność operacji zapisu poprzez ich buforowanie (ang. write-behind). Kolejna˛ planowana˛ nowościa˛ jest umożliwienie dodawania i usuwania w˛ezłów we/wy dynamicznie, podczas pracy systemu. Rozwiazanie ˛ to jest w tej chwili opracowywane na UFRGS2 . Istnieje również kilka możliwości poprawy wydajności omawianego systemu. Jedna˛ z propozycji jest zastosowanie Remote DMA[7] do komunikacji mi˛edzy metaserwerami i w˛ezłami we/wy[9] lub np. składowanie metadanych przy użyciu „lekkiego” i szybkiego mechanizmu jak rozszerzone atrybuty systemy Linux (xattrs) czy baza danych Berkeley DB[8]. W ciagu ˛ najbliższych miesi˛ecy przewidziana jest integracja NFSp ze specjalnym planista˛ operacji we/wy dla środowisk klastrowych - aIOLi3 - który może usprawnić[10] realizowanie żadań ˛ i ich koordynacj˛e na metaserwerach, jak równie ż operacje na danych w przypadku w˛ezłów we/wy. 6 Podsumowanie W pracy tej zaprezentowano oryginalny pomysł poprawy wydajności dost˛epu do danych w środowisku klastrowym poprzez zastapienie ˛ tradycyjnego serwera NFS nowym, w pełni kompatybilnym rozwiazaniem, ˛ które wykorzystuje metody obecne w nowoczesnych, równoległych systemach plików. Poprawność i efektywność proponowanego systemu została potwierdzona przez wykonane eksperymenty. Kolejnym zadaniem b˛edzie stworzenie produkcyjnej wersji serwera NFSp, pozbawionego wad prototypu i rozszerzonego o te z planowanych usprawnień, które okaża˛ si˛e być wydajne w praktyce. 2 Universidade Federal do Rio Grande do Sul - Brazylia: http://www.ufrgs.br/ufrgs/ 3 http://aioli.imag.fr 7 Literatura [1] P. H. Carns, W. B. Ligon III, R. B. Ross, and R. Thakur. PVFS: a parallel file system for Linux clusters. In Proc. of the 4th Annual Linux Showcase and Conference, strony 317–327, Atlanta, GA, 2000. Best Paper Award. [2] P. Keleher, A. L. Cox, and W. Zwaenepoel. Lazy release consistency for software distributed shared memory., Proc. of the 19th Annual International Symposium on Computer Architecture, strony 13–21, Gold Coast, Queensland, Australia, 1992. New York, ACM Press. [3] C. Amza, A. L. Cox, S. Dwarkadas, P. Keleher, H. Lu, R. Rajamony, W. Yu, and W. Zwaenepoel. Treadmarks: Shared memory computing on networks of workstations. IEEE Computer, 29(2):18–28, Feb. 1996. [4] P. Lombard and Y. Denneulin. nfsp: a distributed NFS server for clusters of workstations. Proc. of the 16th International Parallel & Distributed Processing Symposium, IPDPS, strona 35, Ft. Lauderdale, Florida, USA, Apr. 2002. Los Alamitos, IEEE Computer Society. [5] B. Callaghan, B. Pawlowski, and P. Staubach. NFS Version 3 Protocol Specification: RFC 1831. Internet Engineering Task Force, Network Working Group, June 1995. [6] Pawlowski, B., Juszczak, C., Staubach, P., Smith, C., Lebel, D. and D. Hitz. NFS Version 3 Design and Implementation, Proceedings of the USENIX Summer 1994 Technical Conference. [7] B. Callaghan, T. Lingutla-Raj, A. Chiu, P. Staubach, O. Asad. NFS over RDMA, Proceedings ot the ACM SIGCOMM 2003 Workshops. [8] Sleepycat Software: Berkeley DB, http://www.sleepycat.com/products/bdb.html [9] K. Magoutis, S. Addetia, A. Fedorova, M. I. Seltzer, J. S. Chase, A. Gallatin, R. Kisley, R. Wickremesinghe, and E. Gabber. Structure and performance of the Direct Access File System. In Submitted for publication, July 2001. [10] A. Lebre and Y. Denneulin. aIOLi: An input/output library for cluster of SMP. In Proceeding of the 5th International Symposium on Cluster Computing and Grid, Cardiff, UK, May 2005. 8