Straszna sytuacja - systemy plików montowane jednocześnie przez wiele niezależnych instancji systemu operacyjnego

Jak bezpiecznie wyjść z tej sytuacji?

Szczegóły są następujące:

Serwer Xen ma przypisane urządzenia blokowe do maszyn wirtualnych. Ale te urządzenia zostały również zamontowane w Xen.

W rzeczywistości 44 z tych urządzeń blokowych zostało zamontowanych w ten sposób. Co gorsza, każde urządzenie fizyczne jest widoczne przez 4 ścieżki i każde z nich jest zamontowane na osobnym punkcie montowania. Innymi słowy, urządzenia są faktycznie montowane 5 razy.

System operacyjny gościa VM widzi ścieżkę za pośrednictwem pseudo urządzenia PowerPath (przydzielonego jako urządzenie phy: block do domU)

Niektóre urządzenia są sformatowane jako ext2 i reiserfs.

Nie muszę wyjaśniać ryzyka związanego z uszkodzeniem systemu plików.

Obawiam się, że nawet samo odmontowanie systemu plików może spowodować uszkodzenie i uważam, że w tym momencie odłączenie zasilania od hosta jest najbezpieczniejszą opcją .

Należy pamiętać, że aplikacje, w większości bazy danych Oracle, na wszystkich maszynach wirtualnych są nadal uruchomione i używane.

Odkryłem to podczas badania wysokiego zużycia procesora na dom0. Istnieje niemożliwy do zabrania proces „znajdowania”, w którym cwd -> / media / disk-12 jest montowany z / dev / sdf1, który należy do / dev / emcpowerr

Zanim ktokolwiek zapyta, raz widziałem, że procesy nie mogą zostać zabite i nadal używają procesora i pamięci RAM (w przeciwieństwie do nieistniejącego procesu / zombie), kiedy występują zaległe operacje we / wy, np. Synchronizacja zwrócona, ale jeszcze fizycznie na dysku . Częściej występuje to na taśmach I / O.

Propozycje!?

PS Oczekiwałbym, że urządzenia zostaną „zarezerwowane” po zamontowaniu, aby zapobiec tego typu rzeczom? Czy to nie jest możliwe w Linuksie?

EDYCJA: Po pierwsze jestem przekonany, że winowajcą jest KDE w hiperwizorze). Wygląda na to, że KDE montuje urządzenia, które może zalogować podczas tworzenia ikon pulpitu. To samo nie dzieje się jednak na innych serwerach Xen, ale na wszystkich pozostałych serwerach działa znacznie starsza wersja SLES, a KDE ... V4 wydaje się być winny, a 3.4 zachowuje się lepiej.

Ponadto zawieszono dwie niekrytyczne maszyny wirtualne. Po ich zamknięciu nie uruchomią się ponownie z powodu uszkodzenia systemu plików. Główna / produkcyjna maszyna wirtualna nadal działa, a baza danych nadal działa, ale najwyraźniej jest to bomba zegarowa. Klient próbuje odbudować środowisko na innej maszynie wirtualnej na innym serwerze, ale utknął na problemach z konfiguracją niektórych składników, dlatego czekamy ...

W każdym razie uważam, że jak dotąd żadna z odpowiedzi nie była czymś więcej niż „najlepsza praktyka jest zawsze zamykana z wdziękiem” I mam nadzieję, że uda mi się uzyskać coś bardziej konkretnego… W każdym razie uważam, że ta sytuacja może wymagać większej ostrożności myślący. Czy zamknięcie spowoduje zsynchronizowanie zaległych operacji we / wy, w szczególności aktualizacji metadanych systemu plików z hiperwizora, i może spowodować potencjalnie poważne uszkodzenie systemu plików?

Jeśli dyski są zapisywane z jednego punktu podłączenia, nie wyrządza to żadnej szkody. Wykonaj czyste zamknięcie (w razie potrzeby wykonaj kopię zapasową ze stanu zawieszonego) napraw mocowania. Nie uruchamiaj niczego poza niezbędnymi aplikacjami na Dom0. Jeśli, OTOH, partycje są zapisywane z wielu ścieżek, jest to ZŁE i pogarsza się z każdą sekundą. Wyciągnąć wtyczkę.

Nie mam konkretnego powodu, ale moje przeczucie mówi mi, że najlepszym podejściem może być:

1. Zamknij aplikacje.
2. Skopiuj wszystkie dane z maszyny wirtualnej przez sieć do lokalizacji kopii zapasowej.
3. Odinstaluj systemy plików z poziomu maszyny wirtualnej.
4. Zamknij maszynę wirtualną. (Na tym hoście działa teraz tylko jedna maszyna wirtualna).
5. Upewnij się, że żadne domU nie są ustawione na automatyczne uruchamianie.
6. Wyciągnij moc z hosta, aby uniemożliwić hiperwizorowi wykonywanie jakichkolwiek działań „zamykających”, synchronizację zaległych operacji we / wy itp.
7. Uruchom maszynę wirtualną, mając nadzieję, że sam hiperwizor przeżył szarpnięcie mocy.
8. Jeśli to się nie powiedzie, odbuduj środowisko. (Dyski rozruchowe maszyn wirtualnych są oparte na plikach, ale punkty podłączenia danych znajdują się na dysku zewnętrznym przydzielonym jako urządzenia blokowe)
9. Sprawdź, czy hiperwizor nie instaluje systemów plików należących do domU. Odinstaluj je przed uruchomieniem jakichkolwiek domen
10. Wyłącz automatyczne montowanie KDE.
11. Uruchom maszynę wirtualną i wymuś pełne sprawdzenie FS.

Alternatywa dla 11: Uruchom maszynę wirtualną i podłącz systemy plików bez pełnego fsck.

Powodem jest to, że nie chcę, aby hiperwizor Xen miał jakąkolwiek szansę absolutnie niezbędną do spowodowania uszkodzenia w systemach plików domU.

Nie jestem ekspertem od Xen i nie miałem jeszcze z tym doświadczenia. Ale moim podejściem, gdybym był na twoim miejscu, byłoby: po pierwsze wiem, że mogę stracić dane (może nawet wszystkie); po drugie, spróbuję utworzyć migawki, a następnie zawiesić maszyny wirtualne, przywracając je w bezpiecznym innym środowisku.
Nie chcę dawać wam fałszywych nadziei, ale myślę, że będziecie mieli szczęście, jeśli uda wam się cokolwiek odzyskać.

Ostrzeżenie : przestrzeganie tych wskazówek może spowodować utratę wszystkich danych. Od Ciebie zależy, czy warto ryzykować, czy nie.

Przy odrobinie szczęścia Twoje aplikacje nadal działają, ponieważ dane, których używają, znajdują się w pamięci ulotnej. Powinieneś spróbować skorzystać z tej sytuacji (spróbuj ocenić, czy może tak być w przypadku poszczególnych aplikacji) i wyeksportować dane na żywo do udziału sieciowego, jeśli aplikacje oferują taką funkcję. Jeśli jakieś dane znajdują się na dysku, ta funkcja eksportu może zostać „zablokowana” podobnie jak findpolecenie lub zawieszenie się (i awaria aplikacji lub systemu operacyjnego) z powodu zmienionych / uszkodzonych danych na dysku.

Następnie możesz spróbować wykonać migawkę na żywo, instrukcje w następującym artykule: Tworzenie migawek w Xen . Wybrałbym migawkę bajt po bajcie, chociaż mogłaby utknąć tak jak twoje findpolecenie ... Jednak nie dałbym tyle nadziei.

Przed wykonaniem poprzedniego polecenia powinieneś przeczytać ten dokument z Citrix, który pomaga zrozumieć migawki w Xen (PDF) .

Życzę Ci powodzenia.