Dlaczego macierz RAID staje się nieaktywna po utracie zasilania?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Po utracie zasilania tablica RAID może pozostać nieaktywna, ponieważ wykryto jej metadane, ale system nie mógł bezpiecznie jej uruchomić z dostępnymi członkami i stanem.

Termin „nieaktywny” najczęściej odnosi się do tablic md w Linuksie, chociaż inne stosy pamięci masowej mają podobne problemy z importem lub aktywacją. Przed próbą wymuszonego uruchomienia sprawdź wykrywanie urządzeń, metadane członków, stan brudny lub zdegradowany, konfigurację startową oraz błędy ścieżki zasilania.

Zrozum, co oznacza nieaktywny stan w Linux RAID

Nieaktywna tablica md może mieć podłączone urządzenia i pewną konfigurację, ale odmawia normalnych operacji I/O. Nie jest to to samo co zdrowa tablica, która jest po prostu odmontowana, a polecenia montowania nie naprawią brakującego kroku aktywacji.

Stan nieaktywnej tablicy oznacza, że jest skonfigurowana, ale nieaktywna, a operacje I/O zwracają błędy. Ten stan pozwala systemowi kontynuować wykrywanie lub rekonfigurację członków bez udawania, że tablica jest gotowa.

Sprawdź /proc/mdstat, szczegóły tablicy oraz superbloki każdego członka przed zmianą stanu. Celem jest zrozumienie, dlaczego aktywacja została zatrzymana, a nie zmiana „nieaktywnego” na „aktywne” bez potwierdzenia zestawu członków.

Jeden lub więcej członków może się nie pojawić ponownie

Nagła awaria może ujawnić problem z kablem zasilającym, płytą tylnią, kablem SATA, portem kontrolera lub dyskiem, który nie inicjalizuje się przy kolejnym uruchomieniu. Tablica widzi wtedy mniej członków niż wskazują metadane.

mdadm zwykle porównuje dostępne urządzenia niebędące zapasowymi z oczekiwaną liczbą aktywnych przed uruchomieniem. Tablica może pozostać częściowo złożona, gdy brakuje oczekiwanych urządzeń, mimo że istnieje wystarczająca ilość metadanych do utworzenia wpisu urządzenia md.

Bezpiecznie wyłącz zasilanie, jeśli wymagana jest inspekcja sprzętu, a następnie sprawdź złącza, rozruch dysków, wykrywanie kontrolera, numery seryjne i dane SMART. Przywróć brakujące połączenia przed wyborem uruchomienia w stanie zdegradowanym, ponieważ przejściowa usterka ścieżki może być łatwiejsza i bezpieczniejsza do naprawy niż rekonstrukcja tablicy.

Nieczyste zamknięcie może pozostawić tablicę w stanie brudnym

Utrata zasilania może przerwać zapisy zanim każdy członek i blok parzystości osiągną spójny stan. Metadane tablicy wtedy zapisują, że przy następnym uruchomieniu wymagana jest resynchronizacja, odtworzenie bitmapy, odtworzenie dziennika lub inna akcja zapewniająca spójność.

Linux md obsługuje różne polityki spójności po nieoczekiwanym zamknięciu, w tym pełną resynchronizację, bitmapę intencji zapisu, dziennik i częściowy log parzystości. Polityka spójności określa, ile pracy jest potrzebne, zanim można ponownie zaufać nadmiarowości.

Brudna, ale kompletna tablica może się normalnie uruchomić i zsynchronizować. Brudna tablica, która jest również zdegradowana, wymaga znacznie większej ostrożności, ponieważ brakujące dane i niepewna parzystość mogą usunąć informacje potrzebne do niezawodnej rekonstrukcji.

Brudna i zdegradowana parzystość może wywołać odmowę uruchomienia

RAID 5 lub RAID 6 może zostać odrzucony przy starcie, gdy jest zarówno brudny, jak i brakuje mu członka. Odmowa chroni przed stanem, w którym parzystość może być nieaktualna, a brakujące dane nie mogą być sprawdzone względem innej kopii.

Ochrona przed uruchomieniem w stanie brudno-zdegradowanym istnieje, ponieważ wymuszenie takiej kombinacji może spowodować niewykrywalną korupcję. Dlatego wymuszone uruchomienie w stanie zdegradowanym jest decyzją administratora, a nie normalnym zachowaniem podczas startu.

Nie omijaj tej ochrony, dopóki nie zrozumiesz brakującego członka, statusu kopii zapasowej i historii zapisu. Najpierw przywróć ścieżkę urządzenia lub sklonuj uszkodzone członki; jeśli konieczna jest dalsza naprawa, minimalizuj zapisy i niezależnie weryfikuj odzyskane pliki.

Odkrywanie i konfiguracja podczas startu mogą być niekompletne

Dyski mogą być wszystkie sprawne, a mimo to tablica nie zostanie wykryta podczas startu, ponieważ wykrywanie urządzeń kończy się po próbie złożenia, konfiguracja nie zawiera tożsamości tablicy lub initramfs zawiera przestarzałe ustawienia RAID.

Plik konfiguracyjny RAID może opisywać urządzenia i tablice, aby narzędzia startowe wiedziały, co skanować i składać. Dokładne rekordy konfiguracji tablicy są szczególnie ważne, gdy automatyczne wykrywanie nie może wiarygodnie wywnioskować zamierzonego zestawu.

Porównaj żywe UUID członków z zainstalowaną konfiguracją i środowiskiem startowym. Popraw przestarzałą konfigurację dopiero po potwierdzeniu rzeczywistej tożsamości tablicy; wygenerowanie nowej konfiguracji z niekompletnego zestawu członków może spowodować, że następne uruchomienie będzie konsekwentnie błędne.

Metadane zewnętrzne mogą wymagać menedżera w przestrzeni użytkownika

Niektóre tablice używają zewnętrznych formatów metadanych zarządzanych przez przestrzeń użytkownika, a nie całkowicie przez jądro. Po nagłej awarii proces kontenera lub monitorujący może nie zakończyć potwierdzeń potrzebnych do zmian stanu członków.

Zewnętrznie zarządzane metadane mogą wstrzymać aktywność, dopóki przestrzeń użytkownika nie potwierdzi zdarzenia. Nieaktywny zestaw komponentów może więc odzwierciedlać brakujący krok zarządzania, a nie awarię dysków danych.

Zidentyfikuj format metadanych przed zastosowaniem ogólnych poleceń md. Format wspierany przez oprogramowanie sprzętowe lub kontenery może wymagać odpowiedniego monitora, narzędzia kontrolera lub procedury odzyskiwania NAS, aby aktualizacje metadanych następowały we właściwej kolejności.

Odzyskuj w kolejności o najniższym ryzyku

Zacznij od dowodów tylko do odczytu: wypisz urządzenia blokowe według stabilnego ID, przypisz numery seryjne do slotów, zbadaj metadane członków, przejrzyj logi z poprzedniego uruchomienia i sprawdź, czy każdy oczekiwany dysk jest obecny. Nie twórz nowej tablicy ani nie zeruj superbloków.

Spróbuj normalnego składania platformy po poprawieniu łączności i konfiguracji. Używaj trybów tylko do odczytu lub automatycznego odczytu, jeśli są obsługiwane, a opcje uruchomienia w stanie zdegradowanym lub wymuszonego używaj tylko wtedy, gdy dokładnie rozumiesz brakującego członka i ryzyko spójności.

Po odzyskaniu zakończ wszelką resynchronizację lub czyszczenie, potwierdź kopie zapasowe i zbadaj przyczynę awarii. Zasilacz UPS, niezawodne zasilanie i okablowanie, aktualna konfiguracja RAID, stabilne ID urządzeń i system powiadomień zmniejszają ryzyko, że kolejna awaria zasilania spowoduje ten sam nieaktywny stan.

Wskazówka o stanie nieaktywnym Prawdopodobne wyjaśnienie Pierwsza kontrola
Brak oczekiwanego członka Dysk lub ścieżka nie zainicjowały się Numery seryjne, zasilanie, kabel, wykrywanie kontrolera
Wszyscy członkowie obecni; tablica brudna Przerwane zapisy wymagają pracy nad spójnością Status tablicy i polityka spójności
Brudna i zdegradowana parzystość Automatyczne uruchomienie zablokowane dla bezpieczeństwa Przywróć członka lub sklonuj przed wymuszeniem
Członkowie widoczni dopiero po starcie Problem z czasem wykrywania lub konfiguracji Stan mdadm.conf i initramfs

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.