ZFS czy coś innego?

[theqkash]

Pytanie jak w temacie - ZFS czy coś innego?
 

Przyznam szczerze, że ZFS był mi wcześniej nieznany i szczerze mówiąc jestem mocno zaskoczony mnogością ciekawych rozwiązań, które w tym systemie plików działają. Aktualnie np. do proxmoxa można dorzucić moduł zsync i robić np. zdalne backupy na bazie snapshotów wykonywanych na serwerze źródłowym. 

[Archi]

Backupy na bazie snapshotów możesz robić już w lvm, nawet jeśli pod spodem jest ext4.

 

ZFS ma zalety i wady, swojego czasu testowałem naprawdę dużo file systemów i w zasadzie jedynie ext4 mogę z czystym sercem polecić jako coś produkcyjnego i nie cierpiącego na ubytki wydajności czy inne problemy. ZFS jest fajny i na pewno ma zastosowanie jeśli umiesz go przyrównać do ext4 i stwierdzić "tak, z tego na pewno będę korzystał", ale dla samego FSa jako takiego bym go nie wybierał.

[sebak]

Nie polecam ZFS'a jeśli nie chcesz poświęcić dość dużej ilości czasu na jego poznanie i zrozumienie.

Jest to system plików, który niestety ma lekko inną implementacje w zależności od systemu operacyjnego na którym działa(Linux, Unix, Solaris).

ZFS ma bardzo wiele opcji konfiguracyjnych, które dają ogromne możliwości doświadczonym użytkownikom.

Jednak przy złych ustawieniach, wydajność można zdegradować kilkusetkrotnie, czego nie doświadczymy praktycznie na żadnym innym systemie plików.

Natomiast ustawienia nie są uniwersalne, w dużej mierze zależą od tego jakie dane trzymamy i jakimi dyskami dysponujemy.

 

Osobiście uwielbiam ZFS'a, stosuję go już produkcyjnie od kilku lat i odpowiednio skonfigurowany działa perfekcyjnie.

Jednak zanim to nastąpiło, było wiele momentów gdy nienawidziłem tego systemu plików ;-).

[theqkash]

@sebak ja na początku też przeklinałem, zwłaszcza z uwagi na stare przyzwyczajenia (chociażby głupi df), ale po opanowaniu tego jest już super.

[sebak]

df to najmniejszy problem w przypadku zfs'a ;-)

[Adam Szendzielorz]

Używam produkcyjnie ZFSa (zfs on linux) na wielu maszynach od ok dwóch-trzech lat. Rzeczywiście ma wady i zalety - przy dużej ilości poolów tworzenie snapshotów długo trwa. Długo trwa też odmontowanie wszystkiego przy konieczności np. restartu maszyny (przy ~600 poolach trwa to ok 40 minut sic!). Za to ma sporo zalet - wiadomo - snapshoty, synchronizacja snapów po sieci (na serwer backupowy) ale też chociażby brak konieczności sprawdzania konsystencji filesystemu przed jego zamontowaniem, co przy ext4, partycji 2TB z kilkunastoma milionami plików potrafi trwać 40 minut  Wydajnościowo jest nieźle, choć zapis dużej liczby małych plików jest niestety znacznie wolniejszy niż ext4. No i potrzebuje duuużo RAMu, inaczej potrafi "czkać" 

[samu]

Ja tylko zaznaczę, że z implementacją na Linuxa nie jest tak kolorowo i również odczułem dziwne problemy, których na solarisie i freebsd zwyczajnie nie miałem. Np. Tworzenie snapshotow które by długo trwało nigdy mi się nie przytrafiło, a też tych danych trcje tam jest. Ja go osobiście z całego serca polecam, używam go od dawna, również produkcyjnie, ale muszę się zgodzić, że jest w nim dużo więcej do konfiguracji i dużo więcej miejsc gdzie można coś zepsuć

 

A zalety ma, oj ma. Kompresja, deduplikacja, snapshoty, raid-z i wydajność. Potrzebuje dużo ramu, ale wie co z nim robić, nie zjada go sobie ot tak

[Adam Szendzielorz]

Deduplikacja na środowiskach produkcyjnych, przynajmniej w przypadku ZFS on Linux jest mocno niewskazana (choć szczególnie w shared hostingu mogłaby uwolnić sporo miejsca  Ale jest po prostu zbyt mocno zasobożerna  Raid-z, dynamiczne powiększanie/pomniejszanie pooli - szczególnie na maszynie backupowej jest bardzo przydatne (my na backupie używamy zestawów maszyn z 18 dyskami i spokojnie można sobie dokładać kolejne w miarę wykorzystania). Resilvering po wymianie uszkodzonego dysku trochę trwa ale da się przeżyć - przy dysku 2TB - około 48h. Ja ogólnie - polecam, co do stabilności - nie mam absolutnie żadnych zastrzeżeń. ZFS działa u nas już na wszystkim, choć migrację ext4 -> ZFS robiliśmy przy okazji wymiany dysków SAS -> SSD, więc do końca nie mam porównania jak zachowywałby się ZFS w obciążonym środowisku produkcyjnym na SASach

Edytowane 13 Września 2017 przez Adam Szendzielorz

[sebak]

Moje doświadczenie jest głównie z ZFS na Freebsd, na Linux mam tylko 1 maszynę produkcyjną. Robiąc kiedyś porównanie wydajności i zachowania się ZFS'a na obu systemach, doszedłem do wniosku, że ZFS on Linux to zbyt duże ryzyko dla mnie. Testowałem też ZFS'a na Solarisie, jednak tam z kolei system wydawał się zbyt niszowy.

 

Poza backupem, 100% danych trzymam na SSD. Nie wiem jak teraz, ale kiedyś ZFS on Linux nie dorobił się wsparcia dla trim'a, oferował gorszą wydajność na Linux, oraz większe zapotrzebowanie na ram. Dodatkowo nie ZFS na Linux nie wspierał partycji systemowej na ZFS, a to jest bardzo przydatne przy tworzeniu macierzy dyskowej.

 

Moja najwieksza macierz na ZFS składa się z 25 dysków SSD, 2 dysków SSD pod system i 2 dyski PCIe.

 

Jeśli chodzi o deduplikację, wcale nie jest aż tak obciążająca jak mówisz @Adam Szendzielorz. Oczywiście wymaga to odpowiednio dużego recordsize, oraz kilku innych optymalizacji (jak np. dysk pod l2arc dedykowany na metadane). Przy odpowiednio szybkim dysku SSD l2arc nawet nie potrzebujesz dużo ramu do deduplikacji. Oczywiscie l2arc sam w sobie wymaga też tuningu... W Freebsd standardowo l2arc zapis do pamięci ssd jest ograniczony do 5 MB/s, oraz domyślnie dysk może na raz tylko odczytywać lub zapisywać dane. Przy NVMe te limity są śmieszne ;-).

 

Podsumowując, ZFS ma masę zalet, ale trzeba mieć o tym pojęcie. Inaczej dużo łatwiej zrobić sobie krzywdę, niż na innym systemie plików.

[nrm]

Adam możesz coś więcej o waszym setupie powiedzieć? ZFS jest na wszystkim czy też sam OS (co macie, Debian?) jest osobno, a storage na ZFS osobno?

Jak to dyskowo wychodzi per maszyna?

 

 

 

(Mega ciekawa dyskusja, o takie RN walczyłem  )

[spox]

Ja się na ZFS przejechałem, miałem z tym systemem dużo problemów głównie z wydajnością. Prawdopodobnie głównie ze względu na brak doświadczenia, ale tuning tego systemu to naprawdę droga przez mękę. Było to jednak jakiś czas temu i może teraz inaczej to wygląda. Generalnie na backup to fajna sprawa, bo można sobie snapshotować do bólu wersji, do tego dochodzi kompresja więc można uzyskać fajne upakowanie. 

 

Uwagi warty jest też btrfs, który świetnie sprawuje się na maszynach pod backup. 

[samu]

Tylko wspomnę, że jeszcze za czasów dysków talerzowych wyszło nam, że talerz + kompresja działał dużo szybciej niż bez - zwyczajnie bottleneckiem były dyski, a CPU się nudził

[Adam Szendzielorz]

Dnia 13.09.2017 o 19:33, nrm napisał:

Adam możesz coś więcej o waszym setupie powiedzieć? ZFS jest na wszystkim czy też sam OS (co macie, Debian?) jest osobno, a storage na ZFS osobno?

Jak to dyskowo wychodzi per maszyna?

 

 

Nasz setup jest prosty do bólu (ale taki ma być). Maszyny klienckie to albo 4 x SSD 1TB albo 8 x SSD 500GB w RAID10. ZFS działa najwydajniej jeżeli puści się dyski jako "volume" (bez RAIDa z kontrolera sprzętowego) i zrobi RAIDa ZFSowego. Są nawet przeróbki firmware kontrolerów żeby działało to jeszcze szybciej  Ale z racji na problemy z bootem z partycji ZFS jakie występowały jak robiliśmy testy, naszym dość małym doświadczeniem z zachowaniem się macierzy przy padach dysków (przy RAIDach sprzętowych mamy procedury przećwiczone dziesiątki razy) oraz nie aż tak tak znowu niższą wydajnością jak się spodziewaliśmy - używamy jednak sprzętowego RAID10 i systemy bootujemy z partycji ext4, a jedynie dane użytkowników są na ZFSie.

 

Na maszynach backupowych mamy już RAID-Z ZFSowy, ponieważ mamy maszyny z 18 HDD, mamy taki konfig:

 

        NAME                                        STATE     READ WRITE CKSUM
        zapas                                       ONLINE       0     0     0
          raidz1-0                                  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de72184e300fd6c  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de72258dc556c0b  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de7231de8488404  ONLINE       0     0     0
          raidz1-1                                  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de7239d48cc4c45  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de723ddf8abfeca  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de724368a8f5f33  ONLINE       0     0     0
          raidz1-2                                  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de724753cebb2fc  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de724b6ec0e4cc8  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de724fc956b50f8  ONLINE       0     0     0
          raidz1-3                                  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de725354ddbfe0a  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de7257201e52a2d  ONLINE       0     0     0
            scsi-3600605b000ebb0e01de725abbb8dbf41  ONLINE       0     0     0
          raidz1-4                                  ONLINE       0     0     0
            scsi-2853df09b00d00000                  ONLINE       0     0     0
            scsi-20c5d95ae00d00000                  ONLINE       0     0     0
            scsi-20aeddcae00d00000                  ONLINE       0     0     0
          raidz1-5                                  ONLINE       0     0     0
            scsi-20a41b16f00d00000                  ONLINE       0     0     0
            scsi-2109b993100d00000                  ONLINE       0     0     0
            scsi-2097da79c00d00000                  ONLINE       0     0     0

 

... i cały czas zbieramy doświadczenie - póki co kilka padów dysków już przeżyliśmy i ZFS wydaje się "rock-stable", choć na parę drobnych bugów się natknęliśmy :-)

[sebak]

@Adam Szendzielorz moje doświadczenie mówi, że RAIDZ jest wydajniejszy niż RAID 10. Tutaj masz stronę z fajnymi testami: https://calomel.org/zfs_raid_speed_capacity.html

 

Moja konfiguracja 5x RAIDZ 5 dysków (25 łącznie), przyjmuje obecnie następujące obciążenie:

https://www.dropbox.com/s/x8i44awm950uf4v/Zrzut ekranu 2017-09-15 00.18.22.png?dl=0

 

Wykres przedstawia sumaryczne operacje na wszystkich dyskach, realne obciążenie(po odrzuceniu dysków z parzystością) to 4/5 tych wartości.

 

A jakie obciążenia średnio generują Wasze macierze?

 

[Adam Szendzielorz]

7 minut temu, sebak napisał:

@Adam Szendzielorz moje doświadczenie mówi, że RAIDZ jest wydajniejszy niż RAID 10. Tutaj masz stronę z fajnymi testami: https://calomel.org/zfs_raid_speed_capacity.html

 

Tak, rzeczywiście jest trochę wydajniejszy  Ale nie zawsze tylko o wydajność chodzi - na korzyść RAID10 przeważyła u nas przede wszystkim wieloletnia znajomość kontrolerów i doświadczenie w przypadku przeróżnych awarii. Przerobiliśmy chyba wszystkie możliwe scenariusze, więc nic nas nie zaskoczy - przy ZFS (a przypomnę - ja działam na ZFS on Linux!) np. nadal raz na kilka padów, resilvering potrafi się zawiesić (LA rośnie do 2, wszystkie procesy śpią, dostęp do I/O niby jest normalny ale aktywność dysków spada do zera i tak sobie wisi). Na backupie to dla nas żaden problem - po resecie resilvering leci dalej i nie ma żadnego problemu z utratą danych etc. Ale takie zachowanie na maszynie produkcyjnej nie byłoby już zbyt miłe

 

7 minut temu, sebak napisał:

Moja konfiguracja 5x RAIDZ 5 dysków (25 łącznie), przyjmuje obecnie następujące obciążenie:

https://www.dropbox.com/s/x8i44awm950uf4v/Zrzut ekranu 2017-09-15 00.18.22.png?dl=0

 

Wykres przedstawia sumaryczne operacje na wszystkich dyskach, realne obciążenie(po odrzuceniu dysków z parzystością) to 4/5 tych wartości.

 

A jakie obciążenia średnio generują Wasze macierze?

 

 

Znacznie mniejsze, np.:

 

 

Akurat tutaj nie ma legendy ale tak -> pierwszy większy czerwony "pik" to ok 28MB/sek, zapis średnio w granicach 1MB/sek. Szczyt IOPSów o północy sięgnął ledwo 1k IOPS / sek. To jest jedna zwykła maszyna kliencka z hostingiem współdzielonym. Także jak widać - w tym wypadku nie ma co walczyć o np. wydajność 50k IOPS wobec np. 35k IOPS, bo i tak zapotrzebowanie w tym wypadku jest znacznie niższe :)

 

Te maszyny spokojnie radziły sobie wcześniej na macierzy 6 x SAS 15k rpm ale boost w odpowiedzi MySQL, a szczególnie odpowiedzi IMAPa po migracji był niesamowity  Przy parugigowej skrzynce i kilkudziesięciu tysiącach maili webmail potrafił wcześniej ładować się kilkanaście sekund (10-12), teraz mu to zajmuje może pół sekundy :-)

[sebak]

U mnie ten storage, to akurat KVM'y, jak widać ten rodzaj klientów ma trochę większe zapotrzebowanie na przepustowość ;-).

Była to moja pierwsza duża macierz ZFS, stąd też wydajność była dla mnie jednym z priorytetów, bo nie wiedziałem wtedy czego mogę się spodziewać.

Zarówno po klientach, jak i ZFS'ie, niemniej chciałbym mieć takie obciążenia jak u Ciebie ;-).

 

 

 

[Adam Szendzielorz]

2 minuty temu, sebak napisał:

U mnie ten storage, to akurat KVM'y, jak widać ten rodzaj klientów ma trochę większe zapotrzebowanie na przepustowość ;-).

Była to moja pierwsza duża macierz ZFS, stąd też wydajność była dla mnie jednym z priorytetów, bo nie wiedziałem wtedy czego mogę się spodziewać.

Zarówno po klientach, jak i ZFS'ie, niemniej chciałbym mieć takie obciążenia jak u Ciebie ;-).

 

No ale weź pod uwagę ile maszyn u Ciebie z tej macierzy korzysta? U mnie to wykres jednej maszyny / serwera. Jak sobie pomnożysz to razy 10 to wyniki wyjdą pewnie podobne :-)

Edytowane 14 Września 2017 przez Adam Szendzielorz

[sebak]

@Adam Szendzielorz w tej chwili z tego storage korzysta około 400 serwerów VPS. 

 

Jako ciekawostkę dorzucę efektywność pamięci l2arc:

 

Wykorzystujecie w swoich konfiguracjach cache l2arc?

 

Edit:

Dodam jeszcze jeden ciekawy wykres pokazujący co się dzieje z pamiecią ARC po jej zwolnieniu:

 

Przed tuningiem l2arc, około 90% pamięci która była zwalniana z ARC, nie trafiała w ogóle do l2arc.

Edytowane 15 Września 2017 przez sebak

[mcbarlo]

Moje doświadczenie z ZFS-em nie jest bardzo duże, ale wygląda fajnie dlatego chciałbym go wykorzystać w środowisku gdzie potrzebuje bardzo dobrej wydajności w odczycie. Dyski zapisane będą w zasadzie raz albo zmiany będą sporadyczne.

 

Dyski będą magnetyczne, bo potrzebna jest duża pojemność. Protekcja danych jest na poziomie aplikacji, więc na poziomie macierzy można ją pominąć. Czy w tym wypadku kompresja danych jest dobrym pomysłem? Według testów przy mocnym procesorze potrafi dać zysk na wydajności rzędu 50%. Czy poza kompresją warto dać osobny dysk SSD na cache l2?

 

Środowisko będzie Linuxowe.

[sebak]

Powiedz mi @mcbarlo jaki to będzie odczyt, liniowy, random? Jaki zapis?

 

Ogólnie cache ZFS'a działa bardzo prostu. Odczyt / Zapis danych trafia do ARC, który podzielony jest na dwa algorytmy: MRU i MFU. Jeden odpowiada za ostatnio używane dane, drugi za najczęściej używane dane.

 

Wszystkie dane trafiają najpierw do cache przewidzianego dla ostatnio dodanych danych. Jeśli brakuje ramu, nowe dane, wypierają najstarsze dane. Jeśli do danych znajdujących w cache ostatnio dodanych odwołasz się chociaż raz, dane te zostaną przeniesione do drugiego algorytmy, z którego wypieranie danych działa analogicznie. Każde dodatkowe odwołanie do danych, przenosi istniejące tam dane na ostatnie miejsce do zwolnienia z cache.

 

Załóżmy że masz 4GB ramu i masz zapis na poziomie 5GB, następnie odwołujesz się do 1 GB zapisanych danych. Nie znajdzie się on w cache. Stąd tak istotne jest dobór rozwiązań w zależności od charakterystyki danych.

 

L2arc to przedłużenie ARC, dane które wypadają z ARC'a trafiają w idealnej sytuacji 1:1 do L2arc.

[mcbarlo]

Jeśli dobrze rozumiem do cache trafiają również odczyty? Zapis możemy tutaj w ogóle pominąć, poza oknami serwisowymi w ogóle go nie będzie.

 

Odczyt będzie randomowy tj. pobierane będą duże pliki w kawałkach jednocześnie w wielu sesjach. Dlatego bardzo obiecująco wygląda kompresja, bo oszczędza sporo iopsów. Prędkości jakie chciałbym uzyskać to około 20 Gbps z 12 dysków HDD (może być to 6xRAID0). Dyski są wydajne, ale to niestety tylko 7.2k rpm. Do tego dypsonuje dyskiem NVMe, który mogę przeznaczyć na cache albo na poziomie aplikacji (gorsze rozwiązanie) albo na poziomie ZFS-a. Ewetualnie mogę wrzucić jezcze jeden dysk NVMe jeśli byłby potrzebny.

 

Istnieje spora szansa, że niektóre dane będą o wiele bardziej popularne niż inne.

[sebak]

Kompresja prawie zawsze daje plus ;-). Zwłaszcza, że jeśli dane mają pomijalny stopień kompresji, nie są kompresowane na dysku.

 

Jeśli odczyt do tych samych danych będzie zanim dane wypadną z kolejki ostatnio używanych, to warto stosować l2arc.

 

Jeśli odczytujesz duży plik losowo, a następnie kolejny i kolejny, a dopiero później wracasz do pierwszego, to jest duża szansa, że cache dużo Ci nie da.

[mcbarlo]

Czy zbyt duży cache nie ma negatywnego wpływu na wydajność? Chciałbym stosować dysk o pojemności 1 TB pod cache.

 

Ile powinienem zapewnić RAM-u przy pojemności storage 120 TB?

[sebak]

Zbyt duży cache, może mieć wpływ na wydajność, ale nie przy rozmiarze na poziomie 1 TB.

 

Im więcej ramu tym lepiej, L2ARC dodatkowo obciąża Ci ram, gdyż trzyma tablicę danych w RAMie.

 

Nie ma prostego przeliczenia RAM <-> pojemność, o ile nie używasz deduplikacji.

[mcbarlo]

Przeprowadziłem testy z użyciem RAID0 z ZFS-a i włączoną kompresją. Poza tym wszystkie ustawienia domyślne. Wynik jest rewelacyjny. Przyspieszenie w odczycie randomowym 3.1x. W moim wypadku to są same duże pliki i myślę, że duży rozmiar bloku robi robotę oszczędzając iopsy.