Kult ZFS

W środowiskach IT dość powszechne jest rozwijanie pewnego kultu lub mentalności “fanboya”. Nie jestem do końca pewien, co wywołuje taką reakcję wobec technologii i produktów, ale że tak się dzieje, jest niezaprzeczalne. Jednym z obszarów, w którym nigdy nie spodziewałem się tego zobaczyć, jest obszar systemów plików – jednego z najbardziej “ukrytych” komponentów systemu, który do niedawna nie otrzymywał dosłownie żadnej uwagi nawet w dość technicznych kręgach. Powiedzmy sobie szczerze: niezrozumienie tego, co pochodzi z Active Directory, a co z NTFS, jest niemal powszechne. Systemy plików są po prostu ignorowane. Od czasu wydania Windows NT 4 i pojawienia się NTFS jako jedynej sensownej opcji, idea, że system plików nie jest nieodłączną częścią systemu operacyjnego i że mogą istnieć inne opcje przechowywania plików, prawie całkowicie znikła. Przynajmniej do niedawna.

Jedną społecznością, w której – w pewnym małym stopniu – tak się nie stało, była społeczność Linux, ale nawet tam Ext2 i jego potomkowie tak całkowicie zdominowały rynek, że alternatywne systemy plików – choć szeroko dostępne – były zepchnięte na margines, a historycznie jedynie XFS przyciągał jakąkolwiek uwagę, i to bardzo niewielką.

Naprawdę dziwne zachowanie wystąpiło, całkiem niedawno, wokół systemu plików ZFS firmy Oracle, pierwotnie opracowanego dla systemu operacyjnego Solaris i platformy open storage X4500 “Thumper” (pierwotnie pod auspicjami Sun, przed przejęciem przez Oracle). W tamtym czasie (dziewięć lat temu), gdy ZFS się pojawił, konkurencyjne systemy plików były w większości nieprzygotowane do obsługi dużych macierzy dyskowych, jakich oczekiwano w nadchodzących latach. ZFS został zaprojektowany do ich obsługi i zapowiadał erę wielkoskalowych systemów plików. Jak większość ówczesnych systemów plików, ZFS był ograniczony do jednego systemu operacyjnego i dlatego, choć był powszechnie uważany za ogromny krok naprzód w projektowaniu systemów plików, wytworzył niewiele falowania w świecie pamięci masowych, a jeszcze mniej w świecie “systemów”, gdzie nawet administratorzy Solarisa przez dość długi czas traktowali go jako punkt zainteresowania, przeważnie decydując się pozostać przy sprawdzonym UFS, którego używali przez wiele lat.

ZFS był, naprawdę, przełomowym systemem plików i byłem i pozostaję jego wielkim zwolennikiem. Ale bardzo ważne jest zrozumienie, dlaczego ZFS zrobił to, co zrobił, jakie są jego cele, dlaczego te cele były ważne i jak ma się to do nas dzisiaj. Złożoność ZFS doprowadziła do dużego zamieszania i niezrozumienia tego, jak działa ten system plików i kiedy właściwe jest jego użycie.

Głównymi celami ZFS było stworzenie systemu plików zdolnego do dobrego skalowania na bardzo duże macierze dyskowe. W momencie jego wprowadzenia skala, do której ZFS był zdolny, była niespotykana w innych systemach plików, ale w rzeczywistości nie było realnej potrzeby, żeby system plików mógł rosnąć tak duży. Do czasu pojawienia się tej potrzeby wiele innych systemów plików, takich jak NTFS, XFS, Ext3 i inne, przeskalowało się, żeby ją zaspokoić. ZFS z pewnością prowadził szarżę w kierunku obsługi większych systemów plików, ale wkrótce dołączyło do niego wielu innych.

Ponieważ ZFS wywodzi się ze świata Solarisa, gdzie – jak we wszystkich dużych systemach UNIX – nie ma sprzętowego RAID, musiał być użyty programowy RAID. Solaris zawsze miał programowy RAID dostępny jako własny podsystem. Zdecydowano się na wbudowanie nowej implementacji programowego RAID bezpośrednio w ZFS. Pozwoliłoby to na uproszczone zarządzanie za pomocą jednego zestawu narzędzi zarówno dla warstwy RAID, jak i systemu plików. Nie wprowadzało to żadnej istotnej zmiany ani przewagi dla ZFS, jak to jest często błędnie uważane – po prostu przeniosło interfejs dla warstwy programowego RAID z własnego zestawu poleceń do zestawu poleceń ZFS.

Implementacja RAID w ZFS wprowadza paski o zmiennej szerokości w poziomach RAID z parzystością. Ta innowacja zamknęła drobne ryzyko RAID z parzystością znane jako “write hole”. Ta innowacja była bardzo dobra, ale pojawiła się bardzo późno, gdy era niezawodnego RAID z parzystością zaczynała się kończyć, a problem write hole był już uważany za nienazywane ryzyko “szumu w tle” macierzy parzystościowych, ponieważ nie był ogólnie uważany za zagrożenie ze względu na jego eliminację poprzez stosowanie buforów macierzy zabezpieczonych baterią i – mniej więcej w tym samym czasie – nieulotnych buforów macierzy: unikaj utraty zasilania, a unikniesz write hole. ZFS musiał zająć się tym problemem, ponieważ jako programowy RAID był bardziej narażony na write hole niż sprzętowy RAID, gdyż nie ma możliwości zastosowania buforu chronionego przed utratą zasilania – sprzętowy RAID oferuje możliwość dodatkowej warstwy ochrony zasilania dla macierzy.

Prawdziwą “innowacją”, którą ZFS niezamierzenie wprowadził, było to, że zamiast po prostu implementować zwykłe poziomy RAID 1, 5, 6 i 10, “opatentowali” te poziomy własnymi konwencjami nazewnictwa. RAID 5 jest znany jako RAIDZ. RAID 6 jest znany jako RAIDZ2. RAID 1 jest znany po prostu jako mirroring. I tak dalej. Było to powszechnie uważane za głupie i niepotrzebnie dezorientujące, ale, jak się okazało, ta dezorientacja stała się kamieniem węgielnym odrodzenia ZFS wiele lat później.

Należy zaznaczyć, że ZFS później dodał pierwszą branżową produkcyjną implementację RAID 7 (znany również jako RAID 7.3) – system RAID z potrójną parzystością – i opatentował go jako RAIDZ3. To późniejsze uzupełnienie jest ważną innowacją dla wielkoskalowych macierzy wymagających maksymalnej pojemności przy zachowaniu wyjątkowego bezpieczeństwa, ale gotowych poświęcić wydajność. Pozostaje unikalną cechą ZFS, choć rzadko używaną.

W duchu konsolidacji stosu pamięci masowej i używania jednego zestawu poleceń do zarządzania wszystkimi aspektami pamięci masowej, funkcje logicznego zarządzania woluminami zostały również włączone do ZFS. W niektórych kręgach błędnie uważa się, że ZFS wprowadził logiczne zarządzanie woluminami, ale prawie wszystkie korporacyjne platformy, w tym AIX, Linux, Windows, a nawet sam Solaris, posiadały logiczne zarządzanie woluminami od wielu lat. ZFS nie wprowadzał nowego paradygmatu, lecz po prostu konsolidował zarządzanie i łączył wszystkie trzy kluczowe warstwy pamięci masowej (RAID, logiczne zarządzanie woluminami i system plików) w jedną całość, która byłaby łatwiejsza do zarządzania i mogła zapewnić inherentną komunikację w górę i w dół stosu. Istnieją zalety i wady tej metody, a opinia branżowa pozostaje nieprzesądzona prawie dekadę później.

Jednym z najważniejszych aspektów tej konsolidacji trzech systemów w jeden jest to, że teraz mamy bardzo dezorientujący produkt do omówienia. ZFS jest systemem plików, tak, ale nie tylko systemem plików. Jest logicznym menedżerem woluminów, ale nie tylko logicznym menedżerem woluminów. Ludzie odnoszą się do ZFS jako systemu plików, co jest jego główną funkcją, ale to, że jest o wiele więcej niż systemem plików, może być bardzo dezorientujące i sprawia, że porównania z innymi systemami pamięci masowej są trudne. W tamtym czasie sądzę, że to zamieszanie nie było przewidziane.

Efektem tego dezorientującego połączenia jest to, że ZFS jest często porównywany do innych systemów plików, takich jak XFS czy Ext4. Ale jest to dezorientujące, ponieważ ZFS jest kompletnym stosem, a XFS jest tylko jednym aspektem stosu. ZFS lepiej byłoby porównywać do MD (programowy RAID Linux) / LVM / XFS lub SmartArray (sprzętowy RAID HP) / LVM / XFS niż do samego XFS. W przeciwnym razie wydaje się, że ZFS jest pełen funkcji, których brakuje XFS, ale w rzeczywistości jest to tylko zwycięstwo semantyczne. Większość funkcji często chwalonych przez zwolenników ZFS nie pochodzi z ZFS i była powszechnie dostępna w alternatywnych systemach plików na długo przed powstaniem ZFS. Ale trudno porównywać “czy Twój system plików to robi”, ponieważ odpowiedź brzmi “nie... mój RAID lub mój logiczny menedżer woluminów to robi.” I prawdę mówiąc, to nie ZFS jako system plików zapewnia RAIDZ – to ZFS jako podsystem programowego RAID to robi.

W celu sprawnego obsługiwania bardzo dużych systemów plików do ZFS wbudowano funkcje integralności danych, w tym sumę kontrolną lub sprawdzenie skrótu w całym systemie plików, które mogło wykorzystać wbudowany programowy RAID do naprawy uszkodzonych plików. Uznano to za konieczne ze względu na przewidywany rozmiar systemów plików ZFS w przyszłości. Uszkodzenie systemu plików jest rzadko spotykanym zjawiskiem, ale wraz ze wzrostem rozmiarów systemów plików ryzyko rośnie. Ta mniej znana cecha ZFS jest być może jego największą.

ZFS zmienił też sposób obsługi sprawdzania systemu plików. Ze względu na założenie, że ZFS będzie używany na bardzo dużych systemach plików, pojawiła się realna obawa, że sprawdzenie systemu plików przy rozruchu może trwać niemożliwie długo, więc znaleziono alternatywną strategię. Zamiast czekać na sprawdzenie podczas ponownego uruchomienia, system wymaga uruchomienia procesu scrubowania i wykonania podobnego sprawdzenia podczas działania systemu. Wymaga to większego narzutu systemowego, gdy system działa na żywo, ale pozwala systemowi na szybsze odtworzenie po nieoczekiwanym ponownym uruchomieniu. To kompromis, który jest jednak powszechnie postrzegany jako bardzo pozytywny.

ZFS ma zaawansowane możliwości snapshotowania w warstwie logicznego woluminu i w warstwie RAID wdrożył bardzo solidne mechanizmy buforowania, co sprawia, że ZFS jest doskonałym wyborem w wielu przypadkach użycia. Te funkcje nie są unikalne dla ZFS, ale są szeroko dostępne w systemach starszych niż ZFS. Są jednak bardzo dobrymi implementacjami każdej z nich i bardzo dobrze zintegrowanymi ze względu na naturę ZFS.

Kiedyś ZFS był open source i w tej erze jego kod stał się częścią systemów operacyjnych Apple Mac OSX i FreeBSD, ponieważ były one zgodne z licencją ZFS. Linux nie otrzymał ZFS w tamtym czasie ze względu na problemy z licencjonowaniem. Gdyby licencja ZFS pozwoliła Linuxowi na korzystanie z niego bez ograniczeń, krajobraz Linuxa byłby dziś prawdopodobnie bardzo inny. Mac OSX ostatecznie porzucił ZFS, ponieważ nie uznano, że ma wystarczające zalety, żeby uzasadnić jego stosowanie w tym środowisku. FreeBSD trzymał się ZFS i z czasem stał się najpopularniejszym systemem plików na tej platformie, choć UFS jest nadal szeroko używany. Oracle zamknął źródło ZFS po przejęciu Sun, pozostawiając FreeBSD bez dalszych aktualizacji do jego wersji ZFS, podczas gdy Oracle kontynuowało wewnętrzny rozwój ZFS dla Solarisa.

Dziś Solaris nadal używa oryginalnej implementacji ZFS z kilkoma aktualizacjami od czasu jej rozdziału ze społecznością open source. FreeBSD i inne platformy kontynuowały używanie ZFS w stanie, w jakim był, gdy kod został zamknięty – nie mając już dostępu do najnowszych aktualizacji Oracle. Ostatecznie podjęto prace nad aktualizacją opuszczonej bazy kodu ZFS open source, która jest teraz znana jako OpenZFS. OpenZFS jest wciąż w powijakach i nie zdobył jeszcze swojego miejsca, ale ma pewien potencjał do ożywienia platformy ZFS w przestrzeni open source, choć w tej chwili OpenZFS nadal pozostaje w tyle za ZFS.

Rozwój open source przez ostatnie kilka lat w tej przestrzeni skupiał się bardziej na nowym rywalu ZFS – BtrFS, który jest rozwijany natywnie na Linuksie i jest dobrze wspierany przez wielu głównych dostawców systemów operacyjnych. BtrFS jest bardzo młody, ale robi duże postępy w dążeniu do parytetu funkcji z ZFS w implementowanych cechach, ma wielkie aspiracje i ze względu na zamknięty charakter źródła ZFS ma tę zaletę, że ma momentum rynkowe. BtrFS został uruchomiony, podobnie jak ZFS, przez Oracle i był powszechnie postrzegany jako wizja Oracle na przyszłość – jako zamiennik ZFS nawet w Oracle. W tej chwili BtrFS już – jak ZFS – połączył warstwy systemu plików, logicznego zarządzania woluminami i programowego RAID, zaimplementował sumowanie kontrolne dla integralności systemu plików, skaluje się nawet większy niż ZFS (ten sam bezwzględny limit, ale obsługuje więcej plików), snapshoty copy-on-write itp.

ZFS bez wątpienia był niesamowitym systemem plików w swoim czasie i pozostaje liderem do dziś. Byłem jego zwolennikiem w 2005 roku i nadal mocno w niego wierzę. Ale zasmuca mnie obserwowanie, jak społeczność wokół ZFS nabrała zapału i zapalczywości, które mu nie służą i sprawiają, że wzmianka o ZFS niemal brzmi negatywnie – ZFS jest tak powszechnie wybierany z błędnych powodów: przede wszystkim z przekonania, że jego funkcje nie istnieją nigdzie indziej, że jego RAID nie podlega ryzykom i ograniczeniom, którym te poziomy RAID zawsze podlegają, lub że został zaprojektowany do innego celu (głównie wydajnościowego) niż ten, do którego był przeznaczony. A kiedy ZFS jest dobrym wyborem, jest często słabo wdrożony na podstawie nieprawdziwych założeń.

ZFS oczywiście nie jest winny. Ani, o ile potrafię ocenić, jego korporacyjni wspierający lub deweloperzy open source. Wydaje się, że ZFS zszedł na manowce przez luźną, nieformalną społeczność, która dopiero niedawno poznała ZFS, często wierząc, że jest nowy lub “następnej generacji”, bo dopiero go odkryli. Z tego, co widziałem, dzieje się to prawie nigdy przez kanały Solaris lub FreeBSD, lecz niemal wyłącznie za pośrednictwem mniejszych firm chcących używać spakowanego “NAS OS”, jak FreeNAS lub NAS4Free, które nie są zaznajomione z systemami operacyjnymi UNIX. Używanie spakowanych systemów NAS OS, głównie przez firmy IT nieposiadające ani głębokiej wiedzy o UNIX, ani o pamięciach masowych, a w konsekwencji mające niewielki kontakt z szerszym światem systemów plików poza Windows i często mające małe lub żadne doświadczenie z logicznym zarządzaniem woluminami i RAID, szczególnie z programowym RAID, wydaje się prowadzić do kultury “mitów” wokół ZFS, w której nabiera on statusu niemal nie do zakwestionowania, nieomylnego.

To kultowe naśladownictwo i ogólne niezrozumienie ZFS często prowadzi do jego błędnych zastosowań lub ciągu podejmowania decyzji opartych na złych założeniach, które mogą bardzo daleko zaprowadzić na manowce.

Jedną z najbardziej zadziwiających zmian w tej przestrzeni jest zmiana w preferencjach ze sprzętowego RAID na programowy RAID. Tradycyjnie programowy RAID był w środowiskach administratorów Windows wyklęty bez dobrego powodu – administratorzy Windows i małe firmy, często nieznające się na większych serwerach UNIX, wierzyły, że sprzętowy RAID jest powszechny, gdy w rzeczywistości większe systemy zawsze używały programowego RAID. Sprzętowy RAID był, niemal w całej branży, uważany za konieczność, a programowy RAID całkowicie odrzucany. Ta sama publiczność, teraz stojąca przed ruchem “Kult ZFS”, reaguje dokładnie odwrotnie, wierząc, że sprzętowy RAID jest zły i że programowy RAID ZFS jest jedyną realną opcją. Zmiana jest dramatyczna i żadne z tych podejść nie jest prawidłowe – zarówno sprzętowy, jak i programowy RAID, a oba w wielu implementacjach, są bardzo prawidłowymi opcjami, a nawet używając ZFS, zastosowanie sprzętowego RAID może być z łatwością właściwe.

ZFS jest często wybierany, ponieważ uważa się, że jest opcją o najwyższej wydajności wśród systemów plików, ale nigdy nie był to kluczowy cel projektowy ZFS. Cechy pozwalające mu skalować się tak duże i obsługiwać tak wiele różnych aspektów pamięci masowej w rzeczywistości bardzo utrudniają osiąganie bardzo wysokiej wydajności. ZFS w momencie swojego powstania nie był nawet oczekiwany jako szybszy od czcigodnego UFS działającego na tych samych systemach. Jest to jednak często kwestią drugorzędną ze względu na fakt, że wydajność systemu plików jest szeroko rozumiana jako bezcelowa, ponieważ wszystkie nowoczesne systemy plików są niezwykle szybkie i szybkość systemu plików rzadko jest ważnym czynnikiem – szczególnie poza masowymi, wysokiej klasy systemami pamięci masowej na bardzo dużą skalę.

Ciekawe badanie dziesięciu systemów plików na Linuksie przeprowadzone przez Phoronix w 2013 roku wykazało ogromne różnice w systemach plików według obciążenia, ale brak wyraźnych zwycięzców pod względem ogólnej wydajności. Badanie wykazało jednoznacznie, że dopasowanie obciążenia do systemu plików jest najważniejszym wyborem, że ZFS plasuje się po wolniejszej stronie wszystkich głównych systemów plików nawet w nowszych implementacjach i że wybieranie systemu plików ze względu na wydajność bez bardzo głębokiego zrozumienia obciążenia będzie skutkować nieprzewidywalną wydajnością – żadnego systemu plików nie należy wybierać ślepo, jeśli wydajność jest ważnym czynnikiem. Niestety, ponieważ test był przeprowadzony na Linuksie, brakowało w nim UFS, który często jest kluczowym konkurentem ZFS szczególnie na Solaris i FreeBSD, oraz HFS+ z Mac OSX.

Przejście ze sprzętowego RAID na programowy RAID niesie ze sobą dodatkowe, często nieprzewidziane ryzyko dla firm nieposiadających doświadczenia w UNIX. Choć ZFS pozwala na gorącą wymianę, często zapomina się, że gorąca wymiana jest przede wszystkim cechą sprzętu, a nie oprogramowania, i jest też powszechnie nieznane, że ślepa wymiana (usuwanie dysków twardych bez uprzedniego odłączenia ich w systemie operacyjnym) nie jest synonimem gorącej wymiany – co może prowadzić do katastrof dla firm przechodzących z tradycji sprzętowego RAID, który obsługiwał kompatybilność, gorącą wymianę i ślepą wymianę transparentnie za nie, do systemu programowego RAID wymagającego znacznie więcej planowania, koordynacji i zrozumienia systemu, żeby używać go bezpiecznie.

Mniej powszechnym, ale nadal częstym nieporozumieniem dotyczącym ZFS jest przekonanie, że jest to klastrowany system plików nadający się do używania w scenariuszach z współdzielonym DAS lub SAN a la OCFS, VxFS i GFS2. ZFS nie jest klastrowanym systemem plików i ma te same ograniczenia w tej przestrzeni co wszyscy jego powszechni konkurenci.

ZFS może być doskonałym wyborem, ale jest daleki od bycia jedynym. ZFS niesie ze sobą duże zastrzeżenia, z których nie najmniejszym jest ograniczenia związane z systemem operacyjnym, i choć ma wiele zalet, niemal żadna nie jest unikalna dla ZFS i bardzo rzadko jakakolwiek firma skorzysta z każdej z nich. Jak z każdą technologią, istnieją kompromisy do rozważenia. Jeden rozmiar nie pasuje do wszystkich. Kluczem do wiedzy, kiedy ZFS jest dla Ciebie odpowiedni, jest zrozumienie, czym jest ZFS, co jest i co nie jest dla niego unikalne, jakie są jego cele projektowe, jak porównywanie kompletnego stosu pamięci masowej do czystego systemu plików daje wprowadzające w błąd wyniki, oraz jakie są z nim związane inherentne ograniczenia.

ZFS jest kluczowym rozwiązaniem i powszechnym wyborem, gdy Solaris lub FreeBSD jest wybranym systemem operacyjnym. Z rzadkimi wyjątkami, system operacyjny nigdy nie powinien być wybierany ze względu na ZFS, lecz ZFS powinien być często wybierany, choć nie zawsze, gdy wybierany jest system operacyjny. System operacyjny powinien kierować wyborami systemu plików w niemal wszystkich przypadkach. Wybór systemu operacyjnego jest dramatycznie ważniejszy niż wybór systemu plików.

ZFS może być używany na Linuksie, ale nie jest tam uważany za opcję korporacyjną, lecz bardziej za system hobbystyczny do eksperymentowania, ponieważ żaden dostawca korporacyjny (taki jak Red Hat, Suse czy Canonical) nie wspiera ZFS na Linuksie, a Linux ma już świetne alternatywy. Kiedyś ZFS może zostać awansowany do systemu plików pierwszej klasy na Linuksie, ale nie jest to oczekiwane, ponieważ BtrFS już wszedł do mainline kernela i został włączony do wydań produkcyjnych przez kilku głównych dostawców.

Choć ZFS będzie widoczny w zdecydowanej większości wdrożeń Solarisa i FreeBSD, jest to przede wszystkim dlatego, że przejął pozycję domyślnego systemu plików, a nie dlatego, że jest wyraźnie lepszym wyborem w tych przypadkach lub nawet był krytycznie oceniany. ZFS doskonale nadaje się do bycia ogólnodostępnym systemem plików tam, gdzie jest natywny i wspierany.

Jaki jest główny przypadek użycia ZFS?

Celem projektowym i głównym przypadkiem użycia ZFS są systemy open storage Solarisa i FreeBSD, zapewniające albo współdzieloną pamięć masową dla innych serwerów, albo masowe repozytoria danych dla lokalnie zainstalowanych aplikacji. W tych przypadkach skupienie ZFS na skalowalności i integralności danych naprawdę błyszczy. ZFS skłania się mocno ku dużym i korporacyjnym środowiskom i generalnie odchodzi od stosowalności w przestrzeni małych i średnich firm, gdzie umiejętności Solarisa i FreeBSD, a także potrzeby wielkoskalowej pamięci masowej, są rzadkie.

Odniesienie: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1