Po rocznej przerwie w rozwoju prace nad nową gałęzią systemu rozproszonego plików odpornego na awarie i drugi kandydat na wydanie. Niedawno po zmianie właścicieli firmy rozwijającej LizardFS, nowe kierownictwo i programiści zmienili się. W ciągu ostatnich dwóch lat projekt oddalił się od społeczności i nie poświęcano mu odpowiedniej uwagi, ale nowy zespół ma zamiar przywrócić dawne relacje z społecznością i ustanowić z nią bliską współpracę. Kod projektu napisany jest w językach C i C++ i objęty licencją GPLv3.
LizardFS to rozproszony klastrowy system plików, który pozwala na rozmieszczenie danych na różnych serwerach, ale prezentuje dostęp do nich w formie jednego dużego udziału, z którym pracuje się analogicznie do tradycyjnych partycji dyskowych. W zamontowanym udziale LizardFS wspierane są atrybuty plików POSIX, ACL, blokady, gniazda, kanały, pliki urządzeń, dowiązania symboliczne i twarde. System nie ma jednego punktu awarii, wszystkie komponenty są rezerwowane. Wspierane jest równoległe przetwarzanie operacji na danych (kilku klientów może równocześnie uzyskiwać dostęp do plików).
Aby zapewnić odporność na awarie, dane są dzielone na repliki, które są rozmieszczane na różnych węzłach z rezerwowaniem (na różnych węzłach umieszczane są różne kopie) – w przypadku awarii węzłów lub dysków, system kontynuuje pracę bez utraty informacji i automatycznie redystrybuuje dane uwzględniając pozostałe węzły. Aby rozszerzyć magazyn, wystarczy podłączyć nowe węzły bez przerywania pracy serwisu (system sam replikuje część danych na nowe serwery i zrównoważy magazyn uwzględniając nowe serwery). Podobnie można postąpić w celu zmniejszenia rozmiaru klastra – wystarczy po prostu wyłączyć przestarzały sprzęt z systemu.
Dane i metadane są przechowywane oddzielnie. Zaleca się instalację dwóch serwerów metadanych działających w trybie master-slave, a także co najmniej dwóch serwerów przechowywania danych (chunkserver). Dodatkowo do rezerwacji metadanych mogą być używane serwery logów, które przechowują informacje o zmianach metadanych i pozwalają na przywrócenie działania w przypadku uszkodzenia wszystkich posiadanych serwerów metadanych. Każdy plik jest dzielony na bloki (chunk) o rozmiarze do 64 MB. Bloki są rozmieszczane na serwerach przechowywania zgodnie z wybranym trybem replikacji: standardowym (jawne określenie liczby kopii do umieszczenia na różnych węzłach, w tym w powiązaniu z osobnymi katalogami — dla ważnych danych liczba kopii może być zwiększona, a dla mniej istotnych zmniejszona), XOR (RAID5) i EC (RAID6).
Magazyn może być skalowany do rozmiarów petabajtowych. Wśród zastosowań wymienia się prowadzenie archiwów, przechowywanie obrazów maszyn wirtualnych, danych multimedialnych, kopii zapasowych, użycie jako DRC (Centrum Odzyskiwania po Awarii) oraz jako magazyn w klastrach wysokowydajnych obliczeń. LizardFS zapewnia bardzo wysoką prędkość odczytu plików dowolnego rozmiaru, a podczas zapisu wykazuje dobrą wydajność przy zapisie całych dużych i średnich plików, gdy nie ma stałej modyfikacji, intensywnej pracy z otwartymi plikami oraz jednorazowych operacji z dużą liczbą małych plików.
Wśród cech FS można również zauważyć wsparcie dla migawek, odzwierciedlających stan plików w określonym czasie, oraz wbudowaną realizację „kosza” (pliki nie są natychmiast usuwane i przez pewien czas są dostępne do przywrócenia). Dostęp do sekcji może być ograniczony według adresu IP lub hasła (podobnie jak w NFS). Istnieją mechanizmy kwot i zarządzania jakością usług, które pozwalają na ograniczenie rozmiaru oraz przepustowości dla niektórych kategorii użytkowników. Możliwe jest tworzenie zdalnych magazynów, których segmenty są umieszczone w różnych centrach danych.
Projekt LizardFS został założony w 2013 roku jako fork , i różni się przede wszystkim obecnością trybu replikacji opartego na kodach korekcji błędów Rida-Solomona (analog raidzN), rozszerzoną obsługą ACL, dostępnością klienta dla platformy Windows, dodatkowymi optymalizacjami (na przykład przy połączeniu klienta i serwera pamięci, bloki są, jeśli to możliwe, przekazywane z bieżącego węzła, a metadane są buforowane w pamięci), bardziej elastycznym systemem konfiguracji, obsługą prefetchingu danych, limitami katalogów oraz wewnętrznymi przeróbkami.
Wydanie LizardFS 3.13.0 planowane jest na koniec grudnia. Główną nowością LizardFS 3.13 jest zastosowanie algorytmu osiągania konsensusu do zapewnienia odporności na awarie (przełączanie serwerów głównych w przypadku awarii). (zastosowana jest własna implementacja uRaft, która wcześniej była używana w produktach komercyjnych). Użycie uRaft upraszcza konfigurację i skraca opóźnienia przy przywracaniu po awarii, ale wymaga co najmniej trzech działających węzłów, z których jeden jest używany do osiągnięcia kworum.
Z innych zmian: nowy klient oparty na systemie FUSE3, rozwiązanie problemów z korekcją błędów, wtyczka nfs-ganesha została przepisana w języku C. W aktualizacji 3.13.0-rc2 naprawiono kilka krytycznych błędów, które czyniły wcześniejsze wydania testowe wersji 3.13 mało użytecznymi (poprawki dla wersji 3.12 nie zostały jeszcze opublikowane, a aktualizacja z 3.12 do 3.13 wciąż prowadzi do całkowitej utraty danych).
W 2020 roku prace będą koncentrować się na rozwoju
, nowego, całkowicie przepisane rdzenia LizardFS, które, według zapewnień deweloperów, zapewni trzykrotny wzrost wydajności w porównaniu z wersją 3.12. W Agama nastąpi przejście na architekturę sterowaną zdarzeniami (event driven), asynchroniczny wejście/wyjście oparte na , głównie w przestrzeni użytkownika (aby zmniejszyć zależność od mechanizmów buforowania jądra). Dodatkowo oferowany będzie nowy system debugowania oraz analizator aktywności sieciowej z automatycznym dostrajaniem wydajności.
Klient LizardFS otrzyma pełne wsparcie dla wersjonowania operacji zapisu, co zwiększy niezawodność odzyskiwania po awarii, rozwiąże problemy związane z równoczesnym dostępem różnych klientów do tych samych danych oraz pozwoli na znaczne zwiększenie wydajności. Klient zostanie przeniesiony na własny system sieciowy działający w przestrzeni użytkownika. Pierwszy działający prototyp LizardFS oparty na Agama planowany jest do przygotowania w drugim kwartale 2020 roku. W tym samym czasie obiecują wdrożyć środki integracji LizardFS z platformą Kubernetes.
Źródło: opennet.ru
