VMware ESXi nie widzi datastore po restarcie – odzysk LUN [Korporacyjny case]

Restart serwera VMware po awarii zasilania potrafi skończyć się brakiem dostępu do datastore i całej grupy maszyn wirtualnych. To scenariusz krytyczny, bo jedno pochopne działanie po starcie — re-scan, rebuild albo zapis w złym miejscu — może pogorszyć stan metadanych.

W tym materiale omawiamy typowe przyczyny znikającego datastore po restarcie oraz bezpieczną kolejność działań przy problemach z VMFS, LUN i macierzą.

Pokazujemy też rzeczywisty case, w którym po awarii udało się przywrócić 40 maszyn wirtualnych. Najważniejszy wniosek nie dotyczy tempa, lecz metody: najpierw zabezpieczenie stanu, potem diagnoza i dopiero na końcu naprawa logiczna. W przypadku macierzy i NAS najbezpieczniej jest przejść do odzyskiwania danych z RAID bez rebuildów wykonywanych „na ślepo”.

Dlaczego datastore znika po restarcie serwera VMware? Przyczyny i objawy

Restart serwera VMware po awarii zasilania może prowadzić do sytuacji, w której datastore znika lub staje się nieosiągalny. Przyczyny tego problemu mogą być różnorodne, a najczęstsze to uszkodzenie wskaźnika LUN na macierzy SAN, błędy multipath, a także awarie kontrolera RAID. W przypadku uszkodzenia tablicy partycji VMFS, która przechowuje informacje o partycjach, serwer nie jest w stanie poprawnie załadować danych.

Takie błędy mogą powodować, że w vSphere datastore pojawia się jako nieznany lub wcale, a w przypadku wirtualnych maszyn, ich ikony stają się szare, uniemożliwiając ich uruchomienie.

Objawy utraty datastore po restarcie

Objawy problemów z datastore są często wyraźne — administratorzy mogą zauważyć ostrzeżenia w logach ESXi, takie jak Lost access to volume/vmfs/volumes/[UUID]. Choć LUN może być widoczny i online na macierzy SAN, to serwer ESXi może go nie montować, co skutkuje brakiem dostępu do maszyn wirtualnych i ich plików VMDK. W takiej sytuacji kluczowe jest, aby administratorzy nie podejmowali pochopnych działań, takich jak re-skanowanie HBA czy usuwanie LUN, gdyż mogą one zdestabilizować metadane i pogorszyć sytuację.

Krok po kroku do odzysku LUN: Nasza sprawdzona procedura. W takich przypadkach odtwarzanie macierzy RAID/NAS opiera się na rekonstrukcji układu i parametrów macierzy, a nie na zgadywaniu.

Krok po kroku: odzyskiwanie datastore

Aby skutecznie odzyskać utracony datastore, należy działać metodycznie i z rozwagą. Pierwszym krokiem jest analiza i zabezpieczenie stanu infrastruktury. Ważne jest, aby natychmiast zaprzestać wszelkich prób naprawy, ponieważ przypadkowe działania mogą prowadzić do dalszego uszkodzenia systemu. Następnie sprawdzamy stan macierzy SAN, upewniając się, że LUN znajduje się w optymalnym stanie. Zaleca się wykonanie pełnego backupu konfiguracji ESXi z użyciem vSphere CLI oraz, jeśli to możliwe, zrobienie snapshotu LUN na macierzy.

Kolejnym krokiem jest przeprowadzenie głębokiej diagnostyki, która obejmuje obrazowanie dysków oraz analizę struktury RAID. Dzięki temu możemy zrekonstruować macierz w wirtualnym środowisku i lokalizować początek partycji VMFS. W przypadku, gdy wykryjemy jakiekolwiek uszkodzenia w tablicy partycji, korzystamy ze specjalistycznych narzędzi, aby naprawić VMFS zgodnie z jego wersją.

Bardzo istotne jest, aby podchodzić do tych działań z rozwagą, aby zminimalizować ryzyko utraty danych w procesie odzyskiwania. W przypadku poważnych uszkodzeń, wykorzystujemy nasze sprawdzone metody, które pozwalały nam na efektywne przywrócenie maszyn wirtualnych do stanu operacyjnego.

Studium przypadku: Jak odzyskaliśmy 40 maszyn wirtualnych w 48 godzin

W obliczu kryzysu firma finansowa znalazła się w sytuacji, która mogła zrujnować jej operacje. Po planowanym restarcie serwera VMware zniknęły dwa z pięciu datastore'ów, co uniemożliwiło uruchomienie czterdziestu maszyn wirtualnych. Zespół administracyjny, w pośpiechu próbując ratować sytuację, zdecydował się na re-skanowanie adaptera storage, co niestety doprowadziło do uszkodzenia tablicy partycji. Wiedząc, jak kluczowe jest szybkie działanie w takich sytuacjach, nasza ekipa rozpoczęła natychmiastowe działania ratunkowe.

Pierwsze cztery godziny po zgłoszeniu to czas na odbiór dysków z siedziby klienta w Warszawie. Następnie skupiliśmy się na obrazowaniu 24 dysków o pojemności 2 TB każdy. Kolejną fazą było wirtualne zrekonstruowanie macierzy RAID 10 oraz naprawa VMFS, co zajęło kolejne osiem godzin.

Cały proces podzieliliśmy na etapowe zadania, aby zmaksymalizować efektywność. Ostatecznie, po 48 godzinach, udało nam się przywrócić do działania wszystkie 40 maszyn wirtualnych, co zminimalizowało czas przestoju do zaledwie ośmiu godzin, oszczędzając firmie około 500 000 zł strat.