Awaria macierzy Dell EMC VNX: jak bezpiecznie odtworzyć dane i usługi

Koniec wsparcia: w jakiej sytuacji jesteś

Dell nie świadczy już standardowego wsparcia dla żadnego modelu z rodziny VNX. Oznacza to brak nowych wersji oprogramowania, brak oryginalnych części w ramach serwisu producenta i brak analizy przyczyn awarii. Ostatnie wydania oprogramowania VNX2 pochodzą z 2022 r.

Według zestawień końca wsparcia sprzętu i oprogramowania publikowanych przez Dell.

W praktyce macierz utrzymuje się dziś dzięki firmom serwisowym i częściom z rynku wtórnego. Da się na tym bezpiecznie przetrwać kilka miesięcy, ale nie da się planować na lata. Do tego macierz często przechowuje dane systemów, które muszą być dostępne bez przerwy, a w urzędach i podmiotach objętych ustawą o KSC sprzęt bez poprawek bezpieczeństwa to także problem formalny.

Pierwsza godzina: zabezpiecz to, co działa

Większość danych traconych przy awariach macierzy ginie nie przez samą awarię, tylko przez pospieszne działania naprawcze. Dlatego zaczynamy od zabezpieczenia stanu:

1. Wstrzymaj zmianyNikt nie wyjmuje dysków, nie restartuje procesorów i nie zmienia konfiguracji, dopóki nie wiadomo, co się stało. Jedna osoba koordynuje prace i zapisuje każdy krok.
2. Oceń skutkiKtóre serwery i systemy straciły dostęp do danych, a które działają, choćby wolniej. Czy hosty mają ścieżki do obu procesorów (SPA i SPB).
3. Zbierz logiSP Collect z obu procesorów (każdy trwa 10 do 15 minut i może chwilowo spowolnić macierz). W macierzach plikowych (Unified) dodatkowo nas_checkup i zbieranie materiałów diagnostycznych na Control Station.
4. Zapisz konfiguracjęPełny zrzut konfiguracji fizycznej i logicznej: grupy RAID, pule, LUN-y, grupy hostów. Przy odtwarzaniu po najgorszym scenariuszu to jedyna mapa, która pokaże, co gdzie było.
5. Ratuj dane, które są dostępneJeśli macierz działa w stanie zdegradowanym, najważniejsze maszyny wirtualne i bazy warto od razu przenieść albo skopiować na inny magazyn. Sprawdź też, kiedy była ostatnia udana kopia zapasowa każdego systemu.

Diagnoza z naviseccli

Unisphere, czyli graficzna konsola VNX, działa jako aplet Javy. Nowoczesne przeglądarki i nowe wersje Javy już go nie uruchamiają, więc w czasie awarii łatwo stracić czas na walkę z konsolą. Dell udostępnia aplikację VNX Launcher (Unisphere Client dla Windows) z wbudowaną Javą, ale najpewniejszym narzędziem jest wiersz poleceń naviseccli.

# plik z poświadczeniami, żeby nie podawać hasła w każdym poleceniu
naviseccli -AddUserSecurity -scope 0 -user admin

# lista usterek: dyski, półki, zasilacze, procesory, baterie
naviseccli -h 10.0.0.10 faults -list

# stan podzespołów: procesory, zasilanie awaryjne (SPS lub BBU), karty LCC
naviseccli -h 10.0.0.10 getcrus -all

# stan pul i grup RAID
naviseccli -h 10.0.0.10 storagepool -list -state -status -prcntFull
naviseccli -h 10.0.0.10 getrg 0 -state -disks -lunlist

# stan konkretnego dysku, np. dysku systemowego 0_0_0
naviseccli -h 10.0.0.10 getdisk 0_0_0 -state

# właściciel LUN-u z grupy RAID: bieżący i domyślny procesor
naviseccli -h 10.0.0.10 getlun 12 -owner -default -trespass -state

# stan pamięci podręcznej zapisu (VNX2)
naviseccli -h 10.0.0.10 cache -sp -info -state

# ostatnie wpisy dziennika zdarzeń danego procesora
naviseccli -h 10.0.0.10 getlog -100

Logi zbieramy z obu procesorów, a potem pobieramy je z macierzy i zapisujemy konfigurację:

naviseccli -h 10.0.0.10 spcollect
naviseccli -h 10.0.0.11 spcollect
# po kilkunastu minutach
naviseccli -h 10.0.0.10 managefiles -list
naviseccli -h 10.0.0.10 managefiles -retrieve

naviseccli -h 10.0.0.10 arrayconfig -capture -output vnx-konfiguracja.xml

Na co patrzymy w wynikach: które dyski są w stanie Faulted, Removed albo w trakcie odbudowy, czy pule i grupy RAID są zdegradowane czy niedostępne, czy pamięć podręczna zapisu jest włączona, czy zasilanie awaryjne jest sprawne i czy LUN-y pracują na swoim domyślnym procesorze. LUN-y przeniesione na drugi procesor (trespass) zwykle oznaczają problem ze ścieżkami albo z jednym z procesorów.

Typowe awarie i co z nimi robić

Awaria pojedynczego dysku

To najczęstszy i najmniej groźny przypadek: grupa RAID działa dalej, a macierz zaczyna odbudowę na dysku zapasowym. W VNX1 zapasowe są dyski wyznaczone do tej roli. W VNX2 (architektura MCx) zapasowym może zostać każdy wolny, niezwiązany z żadną grupą dysk zgodnego typu. Po wyjęciu dysku macierz czeka 5 minut i notuje zmiany: jeśli ten sam dysk wróci w tym czasie, wystarczy szybka, częściowa odbudowa. Po 5 minutach zaczyna się pełna odbudowa na innym dysku.

Po wymianie uszkodzonego dysku VNX2 nie przenosi danych z powrotem automatycznie: nowy dysk staje się wolnym dyskiem zapasowym. Jeśli zależy nam na pierwotnym układzie, służy do tego polecenie copytodisk, ale operacji nie da się przerwać i może trwać długo, więc planujemy ją poza godzinami pracy. Dell zaleca jeden dysk zapasowy na 30 dysków; politykę sprawdza hotsparepolicy -list.

Dwa dyski w jednej grupie RAID 5

Grupa RAID 5 przetrwa awarię jednego dysku, dwóch już nie. W puli dane są rozłożone na wiele prywatnych grup RAID, więc awaria jednej z nich zwykle odbiera dostęp do LUN-ów całej puli. To moment, w którym najłatwiej pogorszyć sytuację: nie wyjmujemy kolejnych dysków, nie usuwamy ani nie tworzymy od nowa grup i LUN-ów (unbind niszczy dane) i nie aktualizujemy oprogramowania. Najpierw ustalamy, czy drugi dysk naprawdę uległ awarii, czy tylko zgubił połączenie, na przykład przez kartę LCC albo kabel. Jeśli dane są ważne, a kopii brak, przed jakąkolwiek ingerencją warto zaangażować firmę specjalizującą się w odzyskiwaniu danych z macierzy. Równolegle uruchamiamy odtwarzanie z kopii zapasowych na inny magazyn.

Dyski systemowe (vault)

W VNX2 dyskami systemowymi są pierwsze cztery dyski macierzy, od 0_0_0 do 0_0_3. Każdy z nich ma około 300 GB zarezerwowanych na oprogramowanie macierzy i dane systemowe, a przy zaniku zasilania trafia na nie zawartość pamięci podręcznej. Awaria jednego dysku systemowego nie zatrzymuje macierzy, ale przy kilku jednocześnie macierz wyłącza pamięć podręczną zapisu, co odczuwalnie spowalnia wszystkie systemy. Dyski systemowe wymieniamy pojedynczo, według procedury Dell, i nie wyjmujemy ich „na próbę”.

Awaria procesora albo zasilania awaryjnego

Gdy jeden procesor (SP) przestaje działać, jego LUN-y przejmuje drugi, pod warunkiem że hosty mają skonfigurowane ścieżki do obu procesorów i właściwy tryb przełączania. Macierz działa wolniej, ale działa. Najgorsze, co można wtedy zrobić, to zrestartować procesor, który został. Awaria zasilania awaryjnego (SPS albo wbudowanej baterii BBU) może wyłączyć pamięć podręczną zapisu: dane są bezpieczne, ale wydajność spada.

Po naprawie procesora LUN-y można przenieść z powrotem na domyślnego właściciela poleceniem trespass mine. Dokumentacja Dell ostrzega jednak, że przeniesienie przy aktywnym ruchu może wywołać błędy wejścia i wyjścia, więc robimy to w oknie serwisowym.

Macierze plikowe (Unified)

W modelach z obsługą plików (NFS, SMB) dochodzą Data Movery i Control Station. Control Station musi działać, żeby Data Mover mógł przełączyć się na zapasowy. W systemie z jedną Control Station jej awaria oznacza, że przy kolejnej usterce udziały plikowe nie przełączą się same.

Czego nie robić

• Nie wyjmuj kilku dysków ani dysków z grupy, która już jest zdegradowana. Każdy wyjęty dysk to mniejsza nadmiarowość.
• Nie restartuj obu procesorów, a pojedynczego tylko wtedy, gdy zasilanie awaryjne drugiego działa poprawnie. Polecenie rebootSP -both odmawia działania przy włączonej pamięci podręcznej zapisu i ma to swój powód.
• Nie przekładaj karty LCC ani kabla SAS pierwszej półki dyskowej przy działającym procesorze. W modelach z osobną obudową procesorów (VNX5700, VNX7500, VNX8000) procesor traci wtedy dostęp do dysków systemowych i się restartuje, a według Dell może to doprowadzić do restartu obu procesorów naraz i utraty dostępu do danych. Najpierw wyłączamy dany procesor.
• Nie używaj unbind i nie twórz od nowa grup RAID ani pul. To nie jest naprawa, tylko kasowanie danych.
• Nie zmieniaj trybu przełączania (failover mode) hostów bez planu. Zła wartość odcina dostęp całej grupie hostów.
• Nie aktualizuj oprogramowania macierzy w trakcie awarii i nie zaczynaj napraw bez SP Collect z obu procesorów.

Odtworzenie usług i danych

Gdy macierz jest stabilna, usługi przywracamy w ustalonej kolejności, od fundamentów do aplikacji:

1. Macierz: dyski odbudowane albo w trakcie odbudowy, pule i grupy RAID dostępne, pamięć podręczna zapisu włączona.
2. Ścieżki: LUN-y na domyślnych procesorach, hosty widzą wszystkie ścieżki (ponowne skanowanie w VMware, Hyper-V albo na serwerach fizycznych).
3. Wirtualizacja: magazyny danych zamontowane, maszyny wirtualne uruchamiane od kontrolerów domeny i DNS, przez bazy danych, po aplikacje.
4. Spójność: kontrola systemów plików i spójności baz danych, porównanie z ostatnimi kopiami.
5. Kopie zapasowe: wznowienie zadań i natychmiastowa, pełna kopia tego, co udało się uratować.

Jeśli części danych nie da się odzyskać z macierzy, nie czekamy na naprawę sprzętu: odtwarzamy je z kopii zapasowych na inny magazyn. Na koniec spisujemy przyczynę, przebieg i wnioski. Bez tego ta sama awaria wróci przy następnej okazji.

Plan wymiany macierzy

Awaria to dobry moment, żeby zamknąć temat macierzy bez wsparcia. Do wyboru są trzy drogi:

• Nowa macierz Dell. PowerStore potrafi zaimportować LUN-y bezpośrednio z VNX2, bez przestoju (z wtyczką na hostach i wielościeżkowością) albo bez instalowania czegokolwiek na hostach. Import plików obsługuje serwery wirtualne (VDM) z VNX2 z udziałami NFS albo SMB. Dla VNX1 import wymaga sprawdzenia w matrycy zgodności.
• Inna macierz albo magazyn wbudowany w klaster wirtualizacji (na przykład Ceph w Proxmox VE albo Storage Spaces Direct). Dane przenosimy wtedy narzędziami wirtualizacji albo przez odtworzenie z kopii zapasowej.
• Migracja razem ze zmianą wirtualizacji. Jeśli i tak trwa wyjście z VMware, oba projekty warto połączyć. Opisujemy to w poradniku Proxmox VE czy Hyper-V.

• Spis LUN-ów, udziałów i hostów z pojemnością, wydajnością i właścicielem.
• Pomiar rzeczywistego obciążenia (operacje na sekundę, przepustowość, opóźnienia) przed doborem nowego sprzętu.
• Kopie zapasowe wszystkich systemów z macierzy i test ich odtworzenia przed migracją.
• Wybrana metoda migracji dla każdego systemu i okna serwisowe.
• Plan powrotu: VNX zostaje podłączona i nietknięta do czasu potwierdzenia, że wszystko działa na nowej platformie.
• Bezpieczne usunięcie danych z dysków starej macierzy przed jej utylizacją.

Najczęstsze pytania

Źródła

• Dell: dokumenty o końcu sprzedaży i wsparcia produktów
• EMC VNX Series 5.33: CLI Reference for Block (naviseccli)
• Dell KB 000029126: wymiana dysku systemowego w VNX2, dyski zapasowe i odbudowa
• Dell KB 000065874: restart procesora przy wymianie karty LCC
• Dell KB 000019534: zbieranie SP Collect
• Dell KB 000019852: VNX Launcher (Unisphere Client)
• Dell PowerStore: import danych z zewnętrznych macierzy

Stan na 6 listopada 2026 r. Procedury dotyczą typowych przypadków; przy konkretnej awarii decydują logi macierzy i dokumentacja danego modelu.