Автор Алексей ITBro 
Миграция хранилища без простоя! Задача, где мелочей не бывает
Перенос виртуальных машин между хранилищами обычно воспринимается как стандартная операция: подключили новый NFS, переместили диски, отключили старый ресурс.
На практике такой сценарий требует гораздо большей осторожности. Если кластер активно используется, на виртуальных машинах работают базы данных, сервисы и пользовательские приложения, любая ошибка может привести к остановке систем или повреждению данных.
Главная сложность заключается в том, что виртуальная машина продолжает работать в момент переноса.
Гипервизор постоянно читает и записывает данные на виртуальный диск, а значит, смена хранилища должна происходить согласованно. Нельзя просто удалить старый datastore из конфигурации и надеяться, что кластер сам разберется с последствиями.
Безопасная миграция строится вокруг трех принципов: заранее подготовить новое хранилище, обеспечить доступ к нему со всех узлов и перемещать данные штатными средствами платформы виртуализации. Чем меньше ручных действий и резких изменений, тем ниже риск простоя и непредвиденных сбоев.
Почему перенос "на живую" требует подготовки
Перед началом работ нужно точно понимать, какие виртуальные машины используют старый NFS, где находятся их конфигурационные файлы, снапшоты, шаблоны и дополнительные виртуальные диски. Нередко сама машина размещена на одном datastore, а отдельный диск подключен с другого ресурса.
Если проверить только основной путь, часть зависимостей легко упустить. Также важно оценить свободное место на новом хранилище.
Оно должно вместить не только текущий объем виртуальных дисков, но и возможный рост данных, временные файлы, снапшоты и служебные операции во время переноса.
Работа "впритык" повышает вероятность того, что миграция остановится в самый неподходящий момент. До начала процедуры желательно проверить состояние кластера, доступность хостов, сетевые маршруты до NFS-сервера и корректность разрешений. Если новый ресурс виден одному узлу, но недоступен другому, после миграции виртуальная машина может потерять возможность запуска или автоматического перемещения.
Подключаем новый NFS и проверяем кластер
Первый практический этап - подготовка нового NFS-ресурса. На сервере хранения создается отдельный экспорт, назначаются права доступа для всех гипервизоров, а также проверяются параметры сети.
Для стабильной работы важно, чтобы каждый узел кластера обращался к ресурсу одинаковым способом и использовал согласованные настройки.
На стороне виртуализационной платформы новый datastore добавляется на один из хостов, после чего выполняется проверка видимости.
Если система поддерживает автоматическое распространение конфигурации, ресурс можно подключить ко всем узлам через единый интерфейс.
Но даже в этом случае полезно вручную убедиться, что каждый хост действительно видит хранилище и может выполнять операции чтения и записи.
Может быть интересно: Что делать если курсы по IT дорогие, а учиться очень хочется: бесплатные курсы, обучение, чаты
Особое внимание следует уделить именованию. Не стоит давать новому datastore название, похожее на старое, особенно если в кластере уже есть автоматизация, скрипты или резервное копирование, ориентированные на имена ресурсов. Понятные обозначения упрощают контроль и снижают вероятность ошибочного выбора во время миграции.
Что проверить до переноса виртуальных машин
После подключения нового ресурса необходимо проверить не только его наличие в списке, но и реальную работоспособность. На datastore можно создать тестовую папку или небольшую виртуальную машину, выполнить операции копирования, удаления и переименования.
Это помогает выявить проблемы с правами, сетевой доступностью или режимом монтирования до того, как в процедуру будут вовлечены рабочие системы. Следующий шаг - проверка сетевой инфраструктуры.
NFS чувствителен к задержкам, потерям пакетов и неправильным настройкам MTU. Если для хранилища используется отдельная сеть, нужно убедиться, что VLAN, маршрутизация, DNS и правила межсетевого экрана настроены одинаково для всех узлов кластера.
Полезно также проверить производительность.
Даже если новый ресурс открывается без ошибок, он может оказаться значительно медленнее старого.
В результате миграция пройдет успешно, но после нее пользователи заметят задержки, а виртуальные машины начнут испытывать повышенную нагрузку на дисковую подсистему. Лучше обнаружить это на тестовой операции, а не после переноса критичных сервисов.
Перемещаем виртуальные машины без остановки
Когда новый datastore подготовлен, можно переходить к переносу виртуальных машин. Оптимальный вариант - использовать штатную функцию миграции хранилища, например Storage vMotion или аналогичный механизм конкретной платформы.
Такой подход позволяет скопировать виртуальные диски и конфигурационные файлы в фоновом режиме, пока машина продолжает обслуживать пользователей. Во время операции гипервизор отслеживает изменения, которые происходят на исходном диске.
Сначала данные переносятся на новое место, затем повторно копируются изменившиеся блоки.
В финальной фазе система выполняет короткое переключение на новый путь. При корректной работе этот момент занимает минимальное время и обычно не воспринимается пользователями как полноценный простой.
Перед запуском важно выбрать правильный целевой datastore. В окне миграции следует проверить, куда будут перемещены все виртуальные диски, конфигурация и связанные файлы.
Если перенести только один диск, а остальные оставить на старом ресурсе, задача не будет завершена: виртуальная машина продолжит зависеть от прежнего NFS.
Порядок переноса и контроль результата
Не рекомендуется переносить весь кластер одним большим заданием.
Гораздо безопаснее начать с одной некритичной виртуальной машины и проверить полный цикл: запуск миграции, работу приложений, состояние дисков, доступность сетевых сервисов и возможность повторного перемещения между узлами.
Если тестовая операция завершилась успешно, можно переходить к небольшим группам машин. Сначала лучше переносить системы с умеренной дисковой активностью, а уже затем - базы данных, файловые серверы и другие ресурсы с интенсивной записью.
Для особо важных сервисов стоит заранее согласовать окно наблюдения и подготовить план возврата.
После каждого переноса нужно проверить не только статус задачи в интерфейсе гипервизора. Следует убедиться, что виртуальная машина действительно использует новый datastore, старых подключений не осталось, снапшоты не потерялись, а приложения работают штатно. Важно также посмотреть журналы событий и показатели задержек дисковой подсистемы.
Если в инфраструктуре используется резервное копирование, после миграции необходимо проверить его задания.
Многие системы backup привязаны к конкретным путям, datastore или группам виртуальных машин. После изменения расположения виртуальных дисков резервное копирование может продолжиться формально, но работать некорректно из-за изменившейся структуры.
Отключаем старый ресурс только после финальной проверки
Самая распространенная ошибка - отключить старый NFS сразу после завершения основной части миграции. Даже если все видимые виртуальные машины уже перенесены, на ресурсе могут оставаться шаблоны, ISO-образы, снапшоты, конфигурационные файлы, резервные копии или диски, подключенные к другой машине.
Поэтому старое хранилище сначала переводят в режим наблюдения.
В течение некоторого времени нужно отслеживать обращения к нему, проверять списки файлов и анализировать журналы гипервизоров. Если платформа позволяет перевести datastore в режим только для чтения или ограничить его использование, это помогает обнаружить скрытые зависимости без немедленного удаления ресурса.
Отдельно следует проверить функции высокой доступности, балансировки нагрузки и автоматического перезапуска виртуальных машин.
Все узлы кластера должны одинаково видеть новое хранилище. Иначе при отказе одного хоста система может попытаться запустить виртуальную машину на другом узле, который не имеет нужного доступа к ее файлам.
План отката и типичные ошибки
Даже хорошо подготовленная миграция должна иметь сценарий возврата.
Пока старое хранилище не отключено и данные не удалены, оно остается потенциальной точкой восстановления. Если после переноса обнаружились проблемы с производительностью, разрешениями или совместимостью, виртуальную машину можно вернуть на прежний datastore штатными средствами.
Нельзя считать резервной копией простое наличие старого NFS.
Если во время миграции данные были повреждены или удалены, сам факт сохранения подключения к ресурсу не гарантирует восстановление. Перед работами нужно убедиться, что существуют актуальные резервные копии, а процедура восстановления действительно проверялась заранее.
К наиболее частым ошибкам относятся перенос без проверки свободного места, подключение NFS только к части узлов, игнорирование дополнительных дисков и снапшотов, а также ручное перемещение файлов через файловый менеджер.
Последний вариант особенно опасен: гипервизор может потерять сведения о расположении диска или получить несогласованную конфигурацию виртуальной машины. Еще одна проблема - одновременная миграция слишком большого числа систем.
Даже если сеть и NFS-сервер обладают достаточной пропускной способностью, массовые операции создают нагрузку на контроллеры хранения, CPU гипервизоров и каналы управления. Последствия проявляются в виде резкого роста задержек и замедления рабочих приложений.
Безопасный перенос NFS в работающем кластере не разовая команда, а последовательная процедура. Сначала нужно подготовить и проверить новый ресурс, затем переносить виртуальные машины небольшими группами, после каждой операции контролировать результат и только в конце выводить старое хранилище из эксплуатации.
Главный ориентир здесь - не скорость выполнения, а управляемость процесса.
Если каждый этап можно проверить, а при необходимости отменить, риск для виртуальных машин остается минимальным. В результате кластер получает новое хранилище без остановки сервисов, а администратор сохраняет контроль над данными, зависимостями и возможным откатом.