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)

2

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ć?

Stilez
źródło
Sugestie do zrobienia to głównie bo z tych kilku transakcji, które zostałyby utracone w wypadku - dane w spoczynku są zawsze zapisywane (z wyjątkiem błędów lub całkowitej awarii sprzętu). W szczególnym przypadku dysków SSD może się również zdarzyć, że dane zostaną utracone wewnątrz SSD, ponieważ kontroler po cichu traci go po utracie zasilania, ale już zasygnalizował pomyślne zapisanie. Następnie ZFS nie może nic zrobić, a jeśli nie masz wystarczającej nadmiarowości, Twoja pula może ulec uszkodzeniu.
user121391
Czy możesz podać przykłady tego, co masz na myśli? Większość uszkodzonych pul pochodzi z błędów w ZFS (np illumos.org/issues/6214 ), awaria sprzętu (wszystkie zbędne kopie są uszkodzone lub metadane węzła głównego są uszkodzone lub urządzenie kłamie o bezpieczeństwie danych) lub błąd użytkownika / błędna konfiguracja (przypadkowe zniszczenie zpool, rozłożona pula bez nadmiarowości).
user121391
Tak. 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? ) OK, nie ten najbardziej prawdopodobny incydent, ale o to chodzi - w pewnym momencie muszę zdecydować, na co projektować, kiedy rozłożę swoje pieniądze na specyfikację sprzętową.
Stilez
@Stilez: Utracisz niezatwierdzone dane w ZIL, ale nie gorsze niż wyciągnięcie przewodu zasilającego z urządzenia. ZFS miał pełen wdzięku sposób na usunięcie ZIL od wersji puli 19 , wydany w 2009 roku.
Warren Young
Dzięki. Nie jest to jednak to samo, co niezawodne radzenie sobie z niewprawnym usuwaniem. Aby sprowadzić go do bardziej realistycznego poziomu, jeśli nie sprecyzujesz ZIL z lustrzanym odbiciem + superkapą i to się nie powiedzie (a moc jednocześnie zawiedzie, co nie jest nieprawdopodobnym zbiegiem okoliczności, jeśli obie mają wspólną przyczynę), czy użytkownik uniemożliwić całą ich pulę lub po prostu ryzykować ograniczoną ilość danych w locie? Wpłynie to na decyzję o uzyskaniu podwójnych dysków SSD lub premium, w przypadkach, gdy utrata niewielkiej ilości danych w locie może zostać zaakceptowana, ponieważ jest rzadka, ale utrata puli jest znacznie poważniejsza i nie może.
Stilez

Odpowiedzi:

3

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.

Warren Young
źródło
Myślę, że moje pytanie było naprawdę bliższe, „jakie są okoliczności, które powodują, że pula jest nieodwracalna” (poza oczywistym przypadkiem „niewystarczająca redundancja + zbyt wiele awarii dysku”). Jakie rzeczy muszą pójść źle w puli, aby stworzyć sytuację, w której ZFS nie może nic zrobić, aby to naprawić? Nie jest dla mnie oczywiste, ponieważ nie jest jasne, jakie zdarzenia ZFS może obsłużyć (lub może sobie poradzić z odpowiednim HW, które mu pomaga) i których nie może (lub nie może, chyba że ma odpowiednie HW). Edytowany tytuł + pytanie zaktualizowane dla jasności.
Stilez
Spot w tym czasie. Zwłaszcza link do trybów awarii (i zwrócenie uwagi na sekcję wyjaśniającą różne rodzaje uszkodzenia / zdarzeń danych i ich wpływ), a także rozróżnienie / implikację bycia zarówno menedżerem wolumenu, jak i systemem archiwizacji. Dziękuję Ci!
Stilez
Nie nazwałbym raidz2 „3-way redundancy”. Wspólne określenie w społeczności ZFS wydaje się raczej „podwójną redundancją”, w przeciwieństwie do „potrójnej redundancji” (raidz3), „pojedynczej redundancji” lub „bez redundancji”, odnosząc się do tego, ile dysków w vdev można stracić wcześniej nie ma nadmiarowości w konfiguracji pamięci masowej, w związku z czym dane są narażone na rzeczywiste ryzyko. Lustro trójdrożne lub raidz2 zapewniają podwójną redundancję, ponieważ możesz stracić dwa dyski przed każdym dalej straty lub problemy mogą spowodować rzeczywistą utratę danych.
a CVn
@ MichaelKjörling: Odpowiedź edytowana.
Warren Young
1

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.
user121391
źródło
NFS / ESXi / sync będzie dużym zastosowaniem. Ponieważ koszty i ryzyko są na moich barkach, staram się zrozumieć ryzyko, a nie uzyskać zalecane podejście - jeśli oddzielne ZIL faila jako część przerwy w zasilaniu (niezależnie od tego, czy miało to być zbędne, czy nie, itp.), ale nic więcej ma to wpływ, 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 są sposoby, że nagła awaria ZIL + zasilania (zakładając brak innego rodzaju awarii jednocześnie) może spowodować, że pula będzie nieodwracalna?
Stilez
@Stilez Dodałem dwie ostatnie sekcje dotyczące twojego komentarza. Podsumowując: ZFS poradzi sobie z pulą bez ZIL w porządku (wersja 19 i dalsze), twoje aplikacje mogą nie.
user121391
Dzięki, najnowsze informacje pomagają. Głównym zastosowaniem będzie domowy: zwykłe filmy, mp3, dokumenty, + ESXi + migawki. Przeprowadzam migrację ze stacji roboczych VMware + udziałów plików Windows do replikacji ESXi + FreeNAS + offsite. Najgorszym przypadkiem utraty „nowych danych” w ZIL będzie zapisanie migawki lub skopiowanie nowych plików. W najgorszym razie mogę sobie poradzić, jeśli ZFS może przywrócić mnie do „5-15 sekund przed utratą zasilania”. Więc moje pytanie brzmi - czy to? Naprawdę nie chcę przywracać kilku TB replikacji w mojej linii telefonicznej lub muszę się dowiedzieć, dokąd się udałem, jeśli to możliwe :)
Stilez
@Stilez Użycie ZIL zależy od rozmiaru danych - duże dżonki bloków omijają go, zapisywane są w nim tylko małe zapisy, więc możesz skończyć z częściami plików w porządku i brakującymi częściami (trudno powiedzieć, ponieważ zależy to od sytuacja). Możesz porównać wynikową sytuację po awarii z tradycyjnymi dyskami twardymi, gdy niektóre sektory są martwe - możesz tego nie zauważyć lub może to spowodować awarię wszystkich aplikacji, w zależności od tego, gdzie to nastąpi.
user121391
@Stilez Inną możliwością może być podział puli: magazyn danych ESXi z urządzeniem SLOG jako pierwszą pulą, magazyn danych / pliki plików systemu Windows bez urządzenia SLOG jako drugiej puli.
user121391
0

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.

Jakub Juraszek
źródło