Scenariusze utraty danych ZFS

Chciałbym zbudować dużą pulę ZFS (150 TB +) i chciałbym usłyszeć, jak ludzie doświadczają scenariuszy utraty danych z powodu awarii sprzętu, w szczególności rozróżniając przypadki, w których tylko niektóre dane zostały utracone w porównaniu do całego systemu plików ( czy w ZFS istnieje takie rozróżnienie).

Na przykład: powiedzmy, że urządzenie vdev zostało utracone z powodu awarii, takiej jak utrata zasilania zewnętrznej obudowy napędu lub awaria karty kontrolera. Z tego, co przeczytałem, pula powinna przejść w tryb usterki, ale jeśli zwróci się vdev, pula powinna się zregenerować? albo nie? lub jeśli vdev jest częściowo uszkodzony, czy ktoś traci całą pulę, niektóre pliki itp.?

Co się stanie, jeśli urządzenie ZIL ulegnie awarii? Czy tylko jeden z kilku ZIL?

Doceniamy wszelkie anegdoty i hipotetyczne scenariusze poparte głęboką wiedzą techniczną!

Dzięki!

Aktualizacja:

Robimy to tanio, ponieważ jesteśmy małą firmą (około 9 osób), ale generujemy sporo danych obrazowych.

Dane to w większości niewielkie pliki, według mojej oceny około 500 000 plików na TB.

Dane są ważne, ale nie krytyczne. Planujemy użyć puli ZFS do wykonania kopii lustrzanej macierzy danych „na żywo” 48 TB (w użyciu przez około 3 lata), a resztę miejsca na „zarchiwizowane” dane wykorzystamy.

Pula zostanie udostępniona przy użyciu NFS.

Stelaż jest podobno na linii generatora rezerwowego budynku, a my mamy dwa zasilacze APC zdolne do zasilania szafy przy pełnym obciążeniu przez około 5 minut.

Zaprojektuj właściwą drogę, a zminimalizujesz ryzyko utraty danych ZFS. Jednak nie wyjaśniłeś, co przechowujesz na basenie. W moich aplikacjach obsługuje głównie VMWare VMDK i eksportuje zvols przez iSCSI. 150 TB nie jest banalną kwotą, więc skorzystałbym z porady profesjonalisty w zakresie skalowania.

Nigdy nie straciłem danych w ZFS.

I nie doświadczył wszystkiego innego:

• kilkanaście awarii dysków SSD (niektóre w służbie L2ARC )
• wiele nieudanych dysków puli
• nieprzewidywalne błędy napędu SATA wymagające ostatecznej wymiany na dyski SAS nearline
• skutki nieprawidłowo skonfigurowanych działań deduplikacyjnych
• odzyskiwanie uszkodzonych lub uszkodzonych basenów Zpool z trybu awaryjnego
• złe porty / okablowanie karty sieciowej 10GbE
• częste awarie systemu operacyjnego
• uderzenie pioruna ...

Ale dzięki temu nigdy nie nastąpiła znacząca utrata danych. Po prostu przestój. Dla VMWK VMDK siedzących na tym magazynie, po zdarzeniu często konieczny był fsck lub restart, ale nie gorszy niż jakakolwiek inna awaria serwera.

Jeśli chodzi o utratę urządzenia ZIL, to zależy od projektu, tego, co przechowujesz, a także od twoich I / O i wzorców zapisu. Urządzenia ZIL, których używam, są stosunkowo małe (4 GB-8 GB) i działają jak pamięć podręczna zapisu. Niektórzy ludzie odzwierciedlają swoje urządzenia ZIL. Korzystanie z wysokiej klasy urządzeń SSD STEC sprawia, że ​​tworzenie kopii lustrzanych jest zabronione. Zamiast tego używam pojedynczych kart PCIe DDRDrive . Zaplanuj ochronę akumulatora / zasilacza UPS i użyj kart SSD lub PCIe z kopią zapasową superkondensatora (podobną do implementacji kontrolerów RAID BBWC i FBWC ).

Większość moich doświadczeń dotyczyła Solaris / OpenSolaris i NexentaStor . Wiem, że ludzie używają ZFS na FreeBSD, ale nie jestem pewien, jak daleko stoją wersje Zpool i inne funkcje. W przypadku wdrożeń wykorzystujących czystą pamięć masową zalecam skorzystanie z trasy Nexentastor (i rozmowę z doświadczonym partnerem ), ponieważ jest to specjalnie zaprojektowany system operacyjny, a na pochodnych Solaris jest więcej krytycznych wdrożeń niż FreeBSD.

Przypadkowo nadpisałem oba ZIL w ostatniej wersji OpenSolarisa, co spowodowało nieodwracalną utratę całej puli. (Naprawdę zły błąd z mojej strony! Nie rozumiałem, że utrata ZIL oznaczałaby utratę puli. Na szczęście wyzdrowiała z kopii zapasowej z przestojem.)

Od wersji 151a (nie wiadomo od razu, co to znaczy wersja ZPool), ten problem został rozwiązany. I mogę zaświadczyć, że to działa.

Poza tym straciłem dane ZERO na serwerze o pojemności 20 TB - w tym z powodu kilku dalszych błędów użytkownika, wielu awarii zasilania, niewłaściwego zarządzania dyskiem, błędnej konfiguracji, wielu uszkodzonych dysków itp. Mimo że zarządzanie i interfejsy konfiguracyjne w systemie Solaris zmieniają się często i irytująco z wersji na wersję i stanowią znaczący, ciągle zmieniający się cel umiejętności, jest to nadal najlepsza opcja dla ZFS.

Nie tylko nie straciłem danych na ZFS (po moim strasznym błędzie), ale ciągle mnie chroni. Nie doświadczam już uszkodzenia danych - co dręczy mnie od 20 lat na dowolnej liczbie serwerów i stacji roboczych, z tym, co robię. Ciche (lub po prostu „całkiem ciche”) uszkodzenie danych zabijało mnie wiele razy, gdy dane wycofują się z rotacji kopii zapasowych, ale w rzeczywistości uległy uszkodzeniu na dysku. Lub inne scenariusze, w których kopie zapasowe utworzyły kopię zapasową uszkodzonych wersji. Był to o wiele większy problem niż zwykła utrata danych naraz, co i tak prawie zawsze jest archiwizowane. Z tego powodu po prostu uwielbiam ZFS i nie mogę zrozumieć, dlaczego sumowanie kontrolne i automatyczne leczenie nie były standardowymi funkcjami w systemach plików od dekady. (Uznane, systemy życia lub śmierci zwykle mają inne sposoby zapewnienia integralności,

Mówiąc mądrze, jeśli nie chcesz schodzić do piekła ACL, nie używaj wbudowanego serwera CIFS w ZFS. Użyj Samby. (Powiedziałeś, że używasz NFS.)

Nie zgadzam się z argumentem SAS vs. SATA, przynajmniej sugestią, że SAS jest zawsze preferowany w stosunku do SATA, dla ZFS. Nie wiem, czy te komentarze odnosiły się do prędkości obrotu talerza, przypuszczalnej niezawodności, szybkości interfejsu lub innych atrybutów. (A może po prostu „kosztują więcej i na ogół nie są używane przez konsumentów, dlatego są lepsi”. Niedawno opublikowane badanie branżowe (jestem pewien, że w wiadomościach) ujawniło, że SATA faktycznie przeżywa SAS średnio, przynajmniej z znacząca wielkość próby w ankiecie (zszokowało mnie to na pewno.) Nie pamiętam, czy to były wersje „SATA” dla przedsiębiorstw lub konsumenta, czy jakie prędkości - ale z mojego dużego doświadczenia modele korporacyjne i konsumenckie zawodzą tak samo. stawki istotne statystycznie. (Istnieje jednak problem, że dyski konsumenckie zbyt długo tracą czas na awarię, co jest zdecydowanie ważne w przedsiębiorstwie - ale to mnie nie ugryzło i myślę, że jest bardziej odpowiednie dla kontrolerów sprzętowych, które mogą zająć całość w takich przypadkach wolumen jest wyłączony. Ale to nie jest problem SAS vs SATA, a ZFS nigdy mnie nie zawiódł. W wyniku tego doświadczenia używam teraz mieszanki 1/3 dysków SATA dla przedsiębiorstw i 2/3 konsumenckich .) Co więcej, nie widziałem żadnego znaczącego spadku wydajności z tym połączeniem SATA, gdy właściwie skonfigurowanym (np. Paskiem trójdrożnych lusterek), ale znowu mam niskie zapotrzebowanie na IOPS, więc w zależności od wielkości twojego sklepu i typowe przypadki użycia, YMMV. Zdecydowanie zauważyłem, że rozmiar pamięci podręcznej wbudowanej na dysk ma większe znaczenie w przypadku problemów z opóźnieniami niż prędkości obrotowej talerza.

Innymi słowy, jest to koperta z wieloma parametrami: kosztem, przepustowością, IOPS, rodzajem danych, liczbą użytkowników, przepustowością administracyjną i typowymi przypadkami użycia. Stwierdzenie, że SAS jest zawsze właściwym rozwiązaniem, oznacza zlekceważenie dużego wszechświata permutacji tych czynników.

Ale tak czy inaczej, ZFS absolutnie kołysze.