Platforma wirtualizacji VMware vSphere jest znana ze swojej stabilności i oferuje wbudowane opcje, takie jak wysoka dostępność, by zapewnić minimalizację wpływu awarii sprzętowych na pracę aplikacji. Nie wszyscy jednak kupują licencje na te opcje, ponadto problemy mogą zdarzyć się z każdą wykorzystywaną technologią.

Pierwszym działaniem jest zawsze zebranie informacji: co dokładnie uległo awarii? Czy to jest serwer? Czy maszyna vCenter się załamała? Czy tylko procesy się zatrzymały? Czy przełącznik sieciowy działa? Czy sieć SAN ma zasilanie? Czy wyłączone są wszystkie maszyny wirtualne, czy tylko ta jedna?

Ponieważ na pracę wirtualizowanej infrastruktury składa się wiele czynników, niezbędne jest standardowe, systematyczne podejście rozwiązywania problemów wykonywane zawsze w taki sam sposób i w tej samej kolejności.

Działać w standardowy sposób

Można wybrać na przykład metodologię bazującą na modelu OSI i zaczynać od warstwy fizycznej, a kończyć na aplikacji lub vice versa. Oto przykład:

Za pomocą polecenia ping sprawdzić połączenia sieciowe do vCenter, by sprawdzić zasilanie i połączenie do serwerów. Jeśli próba się nie powiedzie, sprawdzić zasilanie, połączenia sieciowe oraz fizyczne serwery (czy mają zasilanie, czy można dostać się do nich z konsoli), w przeciwnym przypadku przejść dalej.

Spróbować zalogować się do vCenter za pomocą klienta vSphere. Jeśli się nie udało, spróbować połączenia do hostów ESX/ESXi indywidualnie. Jeśli nie udało się, wykorzystać informacje przedstawiane przez klienta vSphere. Czy storage jest dostępny? Czy host działa? Czy maszyna, która obsługuje vCenter, przerwała pracę?

Sprawdzić procesy vCenter. Jeśli vCenter nie działa, ale maszyna wirtualna pracuje, sprawdzić procesy, restartując je, jeśli potrzeba.

Jest to oczywiście przykład, ale odzwierciedla działania podejmowane przy diagnostyce. Należy ostrożnie podejmować decyzje o przyczynach awarii, gdyż czasami mogą one leżeć gdzie indziej - zamiast pojedynczego serwera, winna może być cała sieć lokalna.