Czy ZFS radzi sobie z nagłą utratą zasilania? (Jakie zdarzenia powodują, że pula jest nie do odzyskania, jeśli sam dysk nie zawiódł lub stał się zawodny)

Wszystkie zasoby mówią, że ZFS nie ma fsck, ani narzędzi do odzyskiwania, używa SSD z podtrzymaniem bateryjnym dla ZIL itp.

Jeśli wtyczka zostanie nagle w jakiś sposób wyciągnięta (całkowita utrata mocy pomimo UPS itp., Ale zakładając brak uszkodzeń fizycznych, brak awarii głowic itp.), Dyski SSD będą zapisywać pamięć podręczną do nvram, a następnie wyciszać ....

Jaka jest szansa, że ​​ZFS będzie w stanie spójnym (nawet jeśli niektóre dane zostały utracone), a pula będzie użyteczna / czytelna, gdy uruchomi się ponownie?

aktualizacja

Zdaję sobie sprawę, że rzeczywiście chciałem zapytać o coś bliższego, jakie wydarzenia doprowadziłyby do sytuacji, w której ZFS rezygnuje z możliwości odczytu puli, mimo że dane są w zasadzie nienaruszone? Nie jest jasne, z czego ZFS może odzyskać dane (lub czy może odzyskać dane przy odpowiednim sprzęcie) i czego nie może (lub nie może bez odpowiedniego sprzętu), ponieważ robi to wewnętrznie, aby sprawdzić i naprawić rzeczy. Niewątpliwie niedostateczna nadmiarowość + awaria dysku (lub inny poważny problem sprzętowy) to jeden przypadek, a całkowite wymazanie / nadpisanie z powodu błędu oprogramowania układowego / oprogramowania jest inne. Ale zakładając, że nośniki pamięci, sprzęt i oprogramowanie nadal działają niezawodnie / prawidłowo , co jeszcze musiało pójść nie tak, ponieważ wynikiem jest utrata puli? Gdzie są granice mocowania basenów? Które sytuacje muszą powstać, zanim się zdarzą i co musi się wydarzyć, aby je wywołać?

Jaka jest szansa, że ​​ZFS jest w stanie spójnym (nawet jeśli niektóre dane zostały utracone), a pula jest użyteczna / czytelna, gdy się zrestartuje?

ZFS działa jak transakcja system zarządzania bazą danych w tym przypadku stare dane nie są zastępowane na miejscu podczas aktualizacji, jak w przypadku tradycyjnych systemów plików. Zamiast tego nowe dane są zapisywane w innym miejscu na dysku, a następnie struktury metadanych systemu plików są aktualizowane tak, aby wskazywały na nowe dane, i dopiero wtedy blok starych danych zostaje zwolniony do ponownego wykorzystania przez system plików. W ten sposób nagła utrata zasilania spowoduje pozostawienie starej kopii danych, jeśli nowe aktualizacje danych nie są w 100% zobowiązane do trwałego przechowywania. Nie zastąpisz połowy bloku lub czegoś podobnego, powodując uszkodzenie danych.

Do tego ZFS używa zaawansowany system sum kontrolnych który pozwala systemowi plików wykrywać błędne lub uszkodzone dane.

Jeśli używasz ZFS z nadmiarową pamięcią, ten sam schemat pozwala systemowi plików wybierać między dwiema lub więcej nadmiarowymi kopiami danych podczas naprawy systemu plików. Oznacza to, że jeśli masz dwie kopie danego bloku i tylko jedna z nich pasuje do przechowywanej sumy kontrolnej, system plików wie, że powinien naprawić uszkodzoną kopię / kopie za pomocą czystej.

Naprawy te mogą się zdarzyć w locie, gdy próbujesz odczytać lub zmodyfikować dane - wtedy system plików może zdać sobie sprawę, że żądane bloki nie są całkowicie koszerne - lub podczas zfs scrub operacja. Powszechnie planuje się okresowe uruchamianie scrubu w pulach ZFS, które mają pliki rzadko dostępne, ponieważ system plików w przeciwnym razie nie wykryłby utraty danych sprzętowych w normalnym trybie działania. Powszechnie zdarza się, że pule ZFS działają na podejrzanym sprzęcie, aby po każdym zaroślach pokazać pewną liczbę stałych bloków.

Szorowanie jest trochę podobne fsck dla innych systemów plików typu Unix, z wyjątkiem tego, że dzieje się on online, podczas gdy system plików jest zamontowany i użyteczny; dzieje się to w tle i tylko wtedy, gdy basen jest bezczynny. Również, fsck implementacje zazwyczaj sprawdzają tylko metadane, a nie dane, ale zarówno sumy kontrolne ZFS, jak i mogą wykrywać błędy w obu. Jeśli te mechanizmy integralności zdecydują, że jeden z bloków wymaga wymiany, może użyć sum kontrolnych, aby zdecydować, która kopia zastąpić uszkodzone kopie.

zakładając, że nośniki pamięci, sprzęt i oprogramowanie nadal działają niezawodnie / poprawnie, co jeszcze musiało pójść nie tak, aby wynik był utratą puli?

O ile mi wiadomo, nie ma takiego przypadku. Albo jedna z trzech rzeczy, o których wspomniałeś, nie powiodła się, albo ZFS zamontuje pulę i odczyta z niej.

Niewątpliwie niedostateczna nadmiarowość + awaria dysku (lub inny poważny problem sprzętowy) to jedna sprawa

Tak, choć może się to zdarzyć w subtelniejszym przypadku niż myślę, że rozważasz.

Weź proste lustro dwukierunkowe. Myślę, że myślisz, że jeden z dysków został fizycznie usunięty z komputera lub przynajmniej z jakiegoś powodu niedostępny. Ale wyobraź sobie, że sektor 12345 jest uszkodzony na obu dyskach. Wtedy wszystkie sprytne sumy kontrolne i nadmiarowość w ZFS nie pomogą: obie kopie są uszkodzone, więc nie można odczytać całego bloku zawierającego ten sektor.

Ale tutaj jest sprytny bit: ponieważ ZFS jest zarówno systemem plików, jak i menedżerem woluminów - w przeciwieństwie do Lash-Up, takiego jak sprzętowy RAID + ext4 lub LVM2 + ext4 - a zpool status polecenie powie Ci, który plik jest nieodwracalnie uszkodzony. Po usunięciu tego pliku pula natychmiast powraca do stanu nieuszkodzonego; problem został usunięty. Lash-upy, które oddzielają system plików od elementów RAID i LVM, nie mogą tego zrobić.

Które sytuacje muszą powstać, zanim się zdarzą i co musi się wydarzyć, aby je wywołać?

Jedyny znany mi przypadek to coś w rodzaju powyższego przykładu, w którym uszkodzenie danych spowodowało uszkodzenie wystarczającej liczby nadmiarowych kopii kluczowych metadanych systemu plików, których ZFS nie może odczytać.

Z tego powodu dzięki dzisiejszym niezwykle dużym dyskom - 100 bilionom bitów! - Zalecam skonfigurowanie ZFS (lub innego systemu RAID lub LVM) o co najmniej podwójnej redundancji. Oznacza to w kategoriach ZFS raidz2 , 3-kierunkowe lustra lub wyższe.

Mimo to ZFS zwykle przechowuje dodatkowe kopie wszystkich metadanych systemu plików poza normalnymi poziomami nadmiarowości używanymi w zwykłych danych pliku. Na przykład 2-kierunkowe lustro będzie przechowywać 2 kopie zwykłych danych użytkownika, ale 4 kopie wszystkich metadanych. Możesz wybrać ten numer, aby uzyskać wydajność, ale nie możesz go całkowicie wyłączyć.

W podręczniku ZFS znajduje się rozdział Tryby awarii ZFS które możesz znaleźć oświecające.

Ponieważ moje komentarze są coraz dłuższe, ta odpowiedź wydaje się przydatna. Warren Young poprawnie opisał już wszystkie podstawowe rozważania w swojej odpowiedzi, więc po prostu skupię się na części „lustrzanej lub nie odzwierciedlającej urządzenia SLOG?”.

Sytuacja wygląda następująco:

Podchodzę do mojego systemu ZFS i bez ostrzeżenia podskakuję i przypadkowo wyrywam P3500 ZIL w połowie bardzo ciężkiej sesji danych przychodzących, a system natychmiast zawiesza się. Dzięki dobremu zasilaczowi i MB, pozostałe dyski HDD / SSD nie są narażone na zakłócenia elektryczne. Każdy inny dysk / vol był zbędny, z wyjątkiem ZIL. Czy właśnie straciłem kilka ostatnich danych, całą pulę lub „to zależy”, a jeśli to zależy, to na czym? )

Jeśli się nad tym zastanowić, normalnie ZIL jest przechowywany na wszystkich dyskach puli i dlatego cieszy się taką samą redundancją, jaką ma pula. Jeśli przeniesiesz go na oddzielne urządzenie w celu zwiększenia prędkości, musisz ustanowić inne odbicie lustrzane, jeśli chcesz nadmiarowość. Ale nawet jeśli go nie masz, po prostu utracisz niewielką ilość danych w ZIL (przywracanie z kopii zapasowej jest potrzebne tylko wtedy, gdy wymagane są zapisy synchronizacji, a dane aplikacji są uszkodzone) i nie sprawiają, że cała pula jest niespójna (co w każdym przypadku zostanie przywrócony z kopii zapasowej).

Teraz na pytanie, co wybrać:

w pewnym momencie muszę wybrać, na czym mam się oprzeć, gdy rozłożę swoje pieniądze na specyfikację sprzętową.

Zależy to od Twojej sytuacji (jak zawsze):

• Jeśli masz tylko zwykłe przechowywanie danych (klasyczny serwer plików), nie masz zbyt wiele (lub nic) z przeniesienia ZIL na urządzenie SLOG, ponieważ SMB jest asynchroniczny i może obsłużyć nagłą utratę zasilania. Wierzę, że dla NFS to zależy od twoich wyborów / oprogramowania, ale obecnie większość ludzi używa SMB we wszystkich trzech głównych systemach.
• Jeśli potrzebujesz szybkości i integralności (głównie dla baz danych i pamięci VM), będziesz (powinien) działać sync=always i będziesz potrzebował urządzenia SLOG dla ZIL lub będzie bardzo, bardzo powoli. W takich przypadkach można albo odbić lustrzanie urządzenia SLOG, albo zdecydować, że zdarzenie „nagła awaria lub usunięcie sprzętu SSD / kontrolera ORAZ nagła utrata zasilania” jest na tyle rzadkie, że można go uruchomić bez niego. Następnie możesz zdecydować, czy koszt jest uzasadniony, czy nie (w większości przypadków tak jest, ponieważ reszta sprzętu jest dość droga, ale nadal znacznie tańsza niż oferty komercyjne).
• Jeśli chcesz mieć spokój ducha, ale masz budżet, mogę polecić Intel SSD 730. Jest on sprzedawany jako produkt „dla graczy” lub „entuzjastów”, ale jest bardzo podobny do mniejszej linii 3700, jeśli porównasz karty . Posiada również superkondensatory, jak kilka źródeł w stanie sieci. Oczywiście oficjalnie Intel nie przyzna się do tego, ponieważ wtedy nikt nie kupiłby tych drogich.

Edytuj: w odniesieniu do twojego komentarza:

NFS / ESXi / sync będzie głównym przypadkiem użycia. Ponieważ koszty i ryzyko są na moich barkach, staram się zrozumieć ryzyko, a nie uzyskać zalecane podejście - jeśli oddzielny ZIL zawiedzie jako część przerwy w dostawie prądu (niezależnie od tego, czy miał on być zbędny, czy nie, itd.), ale nic innego nie jest zagrożone, jest możliwa utrata / uszkodzenie ograniczone do danych otrzymanych przez ZIL i jeszcze nie zapisanych do puli (dane w ostatnich kilku sekundach w najgorszym przypadku) i możliwe do odzyskania, czy też istnieją sposoby, że nagła ZIL + awaria zasilania zakładając, że nie będzie innego rodzaju awarii w tym samym czasie) może spowodować, że pula będzie nieodwracalna?

Wszystkie punkty obowiązują tylko przy założeniu Twojego przykładu i żadne z poniższych nie jest prawdziwe: (a) błędy w ZFS, (b) całkowita awaria sprzętu wszystkich dysków puli, (c) błąd ludzki / złośliwość.

• Twoje dane puli będą bezpieczne, a integralność danych w stanie spoczynku zostanie zachowana, co oznacza, że ​​możesz zaimportować pulę i nie zostanie ona uszkodzona z punktu widzenia ZFS. To jest normalne zachowanie utraty mocy w ZFS i część jego konstrukcji.
• Po przywróceniu zasilania normalnie ZIL byłby czytany, aby powtórzyć utracone transakcje (podobnie jak w RDBMS). Teraz możliwe jest następujące:
  • Twoje urządzenie SLOG nie jest uszkodzone lub uszkodzone części można przywrócić z lustra SLOG: wszystko działa jak zwykle (po ewentualnym resilver), więc ostatnie 5 sekund jest zapisywane z powrotem na pulę.
  • Twoje urządzenie SLOG jest uszkodzone: ZIL nie może zostać prawidłowo przywrócony. Nie wiem, czy wypróbowano częściowe wycofanie, ale z twojego punktu widzenia nie ma to większego znaczenia (ponieważ potrzebujesz wszystkich transakcji), więc zakładam, że twoje ostatnie 5 sekund zostanie odrzucone.

Z perspektywy puli nawet ten najgorszy przypadek jest całkiem dobry - 5 sekund straconych, ale pula jest importowalna (jeśli jest to wersja jest co najmniej 19 ). Ale z punktu widzenia aplikacji może to być błąd krytyczny - aplikacja po prostu napisała 5 sekund danych synchronizacyjnych, uzyskała potwierdzenie, że została pomyślnie napisana i po ponownym uruchomieniu brakuje danych, ale aplikacja o tym nie wie. Dokładny błąd zależy od aplikacji. DBMS mógł stać się niespójny i wymagać naprawy, duży plik danych może być nieczytelny, pliki systemowe mogą powodować trudności ze znalezieniem awarii, zaszyfrowana partycja pamięci masowej może być całkowicie nie do odzyskania - wszystko dlatego, że jej część brakuje / jest błędna.

Inna kwestia, o której rzadko wspomina się: dyski SSD mogą niespodziewanie umrzeć, więc tworzenie kopii lustrzanych staje się ważniejsze niż w przypadku dysków twardych, ale jeśli dwa identyczne dyski SSD zostaną fabrycznie wprowadzone do systemu, awarie mogą wystąpić w tym samym czasie.

Możesz przeczytać dobre podsumowanie Solaris ZFS, Synchronous Writes i ZIL Explained oraz kilka szczegółów na temat sytuacji utraty danych Efekty utraty urządzenia ZFS ZIL SLOG, jak je rozumiem . Dokumentacja Oracle jest nieco krótszy, ale wspomina również, że podczas normalnej pracy ZIL przechodzi z SLOG do automatycznego łączenia urządzeń w przypadku awarii SLOG (oczywiście masz tam 5 sekund luki).

Strona podręcznika zawiera również informacje na temat importowania pul bez ZIL:

 zpool import -a [-DfmN] [-F [-n]] [-c cachefile|-d dir] [-o mntopts] [-o
         property=value]... [-R root]

     -m      Allows a pool to import when there is a missing log
             device. Recent transactions can be lost because the log
             device will be discarded.

Używam ZFS na 4 serwerach, a także mój laptop przez ponad 5 lat. Miałem kilka awarii zasilania na serwerach intensywnego zapisu (uszkodzone oprogramowanie UPS zgłaszające fałszywe dane) i nie zauważyłem KAŻDY* błędy danych / problemy z montowaniem puli (co nie oznacza, że ​​nie nastąpiła utrata danych z ostatniej transakcji, która nie zakończyła pisania, jak wyjaśniono wcześniej / CoW)

* z wyjątkiem jednego zdarzenia, gdy odstąpiłem od instrukcji ZFS: Miałem ZFS na pojedynczym dysku (iSCIS SAN LUN zmapowany na hoście) wewnątrz gościa KVM i po początkowej kopii danych zapomniałem zmienić tryb pamięci podręcznej z WriteBack na WriteThrough. Pula (5 TB) była czytelna, ale zgłoszono błędy 20 k +. Musiałem odtworzyć pulę przy użyciu danych z serwera zapasowego - dzięki zfs snapshots i zfs send / receive straciłem tylko (co oznacza, że ​​może być znacznie gorzej) 2 min danych. Użyj pamięci ECC, wyłącz wszystkie buforowania zapisu (przynajmniej bez BBU / FBU - temat dla innej historii), RTFM i ZFS są solidne.