VMware ESXi не бачить datastore після перезавантаження – відновлення LUN [корпоративний кейс]

Перезавантаження сервера VMware після аварії живлення може завершитися втратою доступу до datastore та всієї групи віртуальних машин. Це критичний сценарій, оскільки одне необачне діяння після старту — перезчитування, відновлення або запис у неправильне місце — може погіршити стан метаданих.

У цьому матеріалі ми обговорюємо типові причини зникнення datastore після перезавантаження та безпечну послідовність дій при проблемах із VMFS, LUN та масивом.

Ми також показуємо реальний випадок, коли після аварії вдалося відновити 40 віртуальних машин. Найважливіший висновок стосується не швидкості, а методу: спершу забезпечити стан, потім діагностика і лише наприкінці логічний ремонт. У випадку масивів і NAS найнадійніше переходити до Відновлення даних через RAID без виконання rebuild-ів «наосліп».

Чому datastore зникає після перезавантаження сервера VMware? Причини та симптоми

Перезавантаження сервера VMware після відключення живлення може призвести до ситуації, коли datastore зникає або стає недоступним. Причини цієї проблеми можуть бути різноманітними, а найпоширеніші — пошкодження індексу LUN на SAN-масиві, помилки multipath, а також відмови RAID-контролера. У випадку пошкодження таблиці розділів VMFS, яка зберігає інформацію про розділи, сервер не зможе правильно завантажити дані.

Такі помилки можуть призводити до того, що в vSphere datastore з'являється як невідомий або зовсім зникає, а у випадку віртуальних машин їхні іконки стають сірими, що унеможливлює їх запуск.

Симптоми втрати datastore після перезавантаження

Симптоми проблем з datastore часто є явними — адміністратори можуть помітити попередження в логах ESXi, такі як Lost access to volume/vmfs/volumes/[UUID]. Хоча LUN може бути видимим та в онлайн-стані на масиві SAN, сервер ESXi може його не монтувати, що призводить до відсутності доступу до віртуальних машин та їхніх файлів VMDK. У такій ситуації ключовим є, щоб адміністратори не вдавалися до поспішних дій, таких як повторне сканування HBA або видалення LUN, оскільки це може дестабілізувати метадані та погіршити ситуацію.

Крок за кроком до відновлення LUN: Наша перевірена процедура. У таких випадках відновлення RAID/NAS спираються на реконструкцію схеми та параметрів масиву, а не на здогади.

Крок за кроком: відновлення сховища даних

Щоб успішно відновити втрачене сховище даних, потрібно діяти методично та обачно. Перший крок — це аналіз і забезпечення безпеки стану інфраструктури. Важливо негайно припинити будь-які спроби ремонту, оскільки випадкові дії можуть призвести до подальших пошкоджень вашої системи. Потім ми перевіряємо стан масиву SAN, переконуючись, що LUN знаходиться в оптимальному стані. Рекомендується виконати повне резервне копіювання конфігурації ESXi за допомогою vSphere CLI і, якщо можливо, зробити знімок LUN на масиві.

Наступний крок — провести глибоку діагностику, яка включає візуалізацію дисків і аналіз RAID. Це дозволяє нам реконструювати масив у віртуальному середовищі та знаходити джерело розділу VMFS. Якщо ми виявляємо пошкодження таблиці розділів, ми використовуємо спеціалізовані інструменти для відновлення VMFS відповідно до її версії.

Дуже важливо підходити до цих дій обережно, щоб мінімізувати ризик втрати даних у процесі відновлення. У разі серйозних пошкоджень ми використовуємо перевірені методи, які дозволили ефективно відновити віртуальні машини до робочого стану.

Кейс: Як відновити 40 віртуальних машин за 48 годин

Перед обличчям кризи фінансова компанія опинилася в ситуації, яка могла зруйнувати її операції. Після планованого перезапуску сервера VMware зникли два з п'яти datastore, що унеможливило запуск сорока віртуальних машин. Адміністративна команда, поспішно намагаючись врятувати ситуацію, вирішила повторно сканувати адаптер сховища, що на жаль призвело до пошкодження таблиці розділів. Усвідомлюючи, наскільки важливим є швидке реагування в таких ситуаціях, наша команда розпочала негайні рятувальні заходи.

Перші чотири години після повідомлення були витрачені на отримання дисків з офісу клієнта у Варшаві. Далі ми зосередилися на створенні образів 24 дисків по 2 ТБ кожен. Наступною фазою було віртуальне відновлення масиву RAID 10 та ремонт VMFS, що зайняло ще вісім годин.

Весь процес ми розділили на етапні завдання, щоб максимізувати ефективність. Врешті-решт, через 48 годин нам вдалося відновити роботу всіх 40 віртуальних машин, що мінімізувало час простою до всього восьми годин, заощадивши компанії близько 500 000 злотих збитків.

Що підготувати перед контактом щодо середовища VMware або LUN

У випадку корпоративних середовищ найважливішими є: топологія масиву, кількість хостів, порядок дисків, останні адміністративні операції та точний момент втрати datastore. Варто одразу зібрати логи, знімки повідомлень з ESXi та інформацію про те, чи виконувалися після перезапуску rescan, remount або будь-які спроби відновлення VMFS. Завдяки цьому швидше можна визначити, чи проблема стосується логічного шару, масиву чи самого LUN. Корисними можуть бути також записи про відновлення даних з VMware, Hyper-V та SAN та аварії RAID у компанії.

Коли більше не варто імпровізувати після перезапуску хоста

Якщо datastore продовжує зникати, частина віртуальних машин не бачить файлів, а панель зберігання показує помилки або стан degraded, кожен наступний перезапуск та кожна спроба ремонту «на продукції» збільшують ризик простою. У таких ситуаціях краще призупинити подальші операції, зберегти інформацію про конфігурацію та перейти до впорядкованої діагностики. Коли середовище обслуговує бухгалтерські системи, ERP або резервне копіювання, розумним кроком також є швидке подання справи до лабораторії, перед тим як проблема перейде з логічного рівня у багатошаровий збій всієї інфраструктури.

Як закрити інцидент без додавання нового бізнес-ризику

Якщо середовище VMware обслуговує продукцію, бухгалтерську систему, ERP або ключові віртуальні машини, важливими є не лише сам відновлення, а й темп та порядок дій. Найкраще тоді одразу передати повний опис інциденту до лабораторії, перевірити Яка ціна на відновлення даних і перейти до послуги відновлення даних з VMware / Hyper-V / SAN. Це безпечніше, ніж наступні перезапуски, повторне сканування або імпровізована реконструкція на живому середовищі.