Как исправить сбой VMFS datastore
Сбой VMFS datastore в среде VMware — одна из самых неприятных ситуаций, потому что проблема затрагивает не один файл и не одну виртуальную машину, а весь слой хранения, от которого одновременно зависят несколько сервисов. На практике это может выглядеть по-разному: datastore внезапно становится недоступным, VM исчезают из браузера datastore, ESXi сообщает об I/O ошибках, хост не может смонтировать хранилище, а виртуальные машины начинают выдавать ошибки lock, snapshot или inaccessible. В такой момент самое важное — не спешить. Очень многие тяжёлые случаи потери данных происходят не из-за первой ошибки, а из-за поспешных действий администратора.
Хороший процесс восстановления всегда начинается с дисциплины: сначала нужно понять, где именно проблема — в метаданных VMFS, в самом LUN, в RAID-контроллере, в multipath, на уровне iSCSI или FC, или только в том, как datastore видит конкретный хост. Лишь после этого имеет смысл решать, делать ли rescan, remount, анализировать цепочку файлов VM или восстанавливать данные из backup. Если ваша виртуальная среда обслуживает важные сервисы, полезно заранее иметь резервный сценарий: для временного переноса нагрузок подходят VPS, для больших и стабильных нагрузок — выделенные серверы, а для хранения резервных копий часто удобно использовать облачное хранилище.
Проблемы с VMFS почти никогда не возникают совсем без причины. Обычно корень в одном из слоёв: деградация контроллера или дисков, некорректный restart хоста, изменение LUN ID, path flapping, APD или PDL события, неудачная storage migration, сломанная snapshot-цепочка или проблема в самих VM-файлах. Поэтому цель этой инструкции — не дать одну “волшебную команду”, а показать безопасную последовательность действий, чтобы не уменьшить шансы на восстановление.
1) Первое правило: ничего не записывайте на проблемный datastore
Если datastore выглядит повреждённым или недоступным, не создавайте на нём новые файлы, не размещайте тестовые VM и не форматируйте его. Даже если vSphere предлагает создать новый datastore на том же устройстве, в этот момент это делать нельзя. Ваша задача — сохранить текущее состояние метаданных и файловой структуры как можно более неизменным, чтобы у вас оставалась возможность корректного анализа и восстановления.
Если виртуальные машины всё ещё работают с этого datastore, не делайте панических перезагрузок. Сначала оцените, можно ли их корректно выключить или перенести на другое хранилище. Если Storage vMotion доступен и storage-слой стабилен, миграция может быть безопасной. Но если storage уже выдаёт активные I/O ошибки, лишнее перемещение данных может ухудшить ситуацию.
2) Проверьте: проблема в хосте, в путях или в самом LUN
Первый практический вопрос: datastore не видит один хост, несколько хостов или вся среда сразу? Если проблема только на одном ESXi-хосте, есть хороший шанс, что сама VMFS не повреждена, а проблема в HBA, multipath или в состоянии discovery на этом хосте. Если datastore исчезла сразу везде, вероятнее всего проблема на стороне storage или LUN.
На ESXi проверьте список устройств, состояние путей и файловых систем. Обычно начинают с команд, которые показывают device list, path list и filesystem list. Если устройство видно, но VMFS не монтируется, то проблема часто на уровне подписи, состояния mount или метаданных. Если самого устройства не видно, нужно смотреть ниже: iSCSI sessions, FC zoning, HBA, RAID-контроллер или состояние storage-массива.
Для iSCSI критично проверить sessions и доступность target. Для FC — zoning и fabric-side ошибки. Для локальных RAID — event log контроллера, состояние cache или battery и здоровье дисков. Это важно, потому что сбой datastore очень часто является не корнем, а лишь симптомом основной проблемы.
3) Rescan, remount и resignature — только с понятной целью
Если storage-сторона уже стабилизирована и LUN снова видна, следующий шаг — контролируемый rescan. Rescan лишь заставляет хост перечитать storage-топологию; сам по себе он ничего не “чинит”. Если после rescan datastore всё равно не появляется, надо понять, видит ли ESXi её как snapshot copy, unknown signature или inactive mount candidate.
Именно здесь важно различать remount и resignature. Remount пытается смонтировать тот же datastore с его прежней идентичностью. Resignature создаёт новую VMFS-идентичность. Это полезно для клонов и намеренно скопированных LUN, но в ситуации сбоя может осложнить восстановление, потому что меняется UUID datastore и часть автоматизации или учёта больше не совпадает с исходным состоянием.
Практическое правило простое: если вы не уверены на сто процентов, что перед вами именно копия, а не исходный datastore, не спешите делать resignature. Во многих случаях безопаснее remount, стабилизация путей или откат из storage snapshot, чем присвоение новой подписи.
4) Проверьте каталоги VM, descriptor-файлы и snapshot-цепочки
Если datastore снова видна, но конкретные виртуальные машины остаются inaccessible, проблема может быть уже на уровне файлов. Проверьте, существуют ли каталоги VM, есть ли .vmx, видны ли .vmdk descriptor-файлы, и не остались ли только -flat.vmdk или -delta.vmdk. Это не означает автоматическую потерю данных, но означает необходимость очень аккуратной работы.
Descriptor-файлы особенно важны, потому что именно они описывают логическую цепочку виртуальных дисков. Если descriptor повреждён или исчез, восстановить доступ иногда можно, но только если вы точно понимаете размер диска, тип адаптера и структуру snapshot-цепочки. Неправильно восстановленный descriptor способен усложнить ситуацию сильнее, чем исходная ошибка.
Если datastore была почти заполнена, очень вероятно, что проблема связана с ростом snapshot или неудачным consolidate. После восстановления доступа не нужно сразу удалять старые delta-файлы. Сначала определите, какой диск активен, нет ли lock от другого хоста, и полностью ли видна цепочка snapshot. Только после этого планируйте consolidate или cleanup.
5) Логи и команды, которые дают максимум информации
В реальной диагностике особенно полезны vmkernel log, vobd и storage-события, где видны APD, PDL, SCSI sense codes и признаки проблем с метаданными VMFS. Если вы видите повторяющиеся APD или PDL, фокус должен быть на доступности путей и storage, а не на “ремонте” файловой системы. Если логи намекают на corruption, действовать нужно ещё осторожнее.
Команды, которые показывают VMFS extents, filesystems и SCSI device mappings, помогают понять, к какому устройству привязана datastore и в каком состоянии её видит ESXi. Это хороший диагностический старт, потому что такие команды ничего не переписывают. Во многих инцидентах реальная ошибка начинается только тогда, когда анализ прекращают слишком рано и переходят к разрушительным действиям.
Когда чинить, когда восстанавливать из backup и когда остановиться
Если проблема вызвана потерей путей, HBA, нестабильностью iSCSI или FC, либо временной недоступностью storage, то часто достаточно корректного remount, и среда возвращается без потери данных. Если проблема на уровне VM-файлов или snapshot-цепочек, возможна файловая коррекция. Но если есть подозрение на реальное повреждение метаданных VMFS или физическую деградацию диска, безопаснее остановиться и восстановить из backup, чем экспериментировать на оригинальных данных.
Профилактика здесь так же важна, как и само восстановление. Последовательная backup-политика, контроль свободного места на datastore и мониторинг storage-событий резко уменьшают риск того, что инцидент превратится в длительный простой. Не держите VMFS datastore почти заполненными, потому что snapshot и consolidate в таких условиях становятся опаснее. Полезно также документировать LUN mappings, UUID datastore и path policies, чтобы не восстанавливать картину среды уже во время аварии.
Если у вас shared storage для нескольких хостов, регулярно проверяйте, что все хосты одинаково видят устройства и что multipath везде здоров. Тонкие различия между хостами часто проявляются только после maintenance или reboot. Чем лучше наблюдаема и документирована storage-среда, тем меньше шанс, что сбой VMFS перерастёт в серьёзный простой.
Хороший администратор не пытается победить любую storage-проблему одной командой. Хороший администратор знает, когда надо остановиться. Если у вас есть свежие backup или storage snapshot, их использование часто безопаснее, чем агрессивные попытки ремонта на “живых” данных. Правильная последовательность проста: ничего не записывать, определить причину, собрать диагностику и только потом выбирать наименее рискованный путь восстановления.