Альтернативы vMotion для перемещения виртуальных машин в другое хранилище данных

Компания, в которой я работаю, использует небольшую виртуальную среду и имеет несколько виртуальных серверов на 2 разных хостах ESXi, управляемых vCenter, по причинам, связанным с проверкой резервного копирования, мне нужно освободить место в одном из хранилищ данных хостов ESXi. На хосте установлено хранилище данных NAS, на котором еще осталось достаточно места, поэтому я подумал, что было бы неплохо переместить туда несколько более крупных виртуальных машин. Проблема в том, что наши хосты ESXi лицензированы с лицензией Essentials, поэтому у меня нет доступа к хранилищу vMotion или даже расширенному vMotion для этой задачи. В качестве альтернативы я подумал об использовании нашего решения для резервного копирования (nakivo), чтобы сделать полную резервную копию машин и восстановить их в нужном хранилище данных, или клонировать виртуальные машины в нужное хранилище данных, или просто отключить машины и перенести их. ни один из этих вариантов не так удобен, как просто использование vMotion, но я хотел бы знать, какой из этих методов будет лучшим с точки зрения риска и времени простоя. Очевидно, что если у кого-то есть лучшее представление о том, как я могу добиться этого с минимальным риском и минимальным временем простоя, я всегда открыт для новых идей. Хосты работают под управлением ESXi версии 7.0.2.

Простите меня, если то, что я предлагаю, невозможно из-за ваших вариантов лицензирования, но, хотя StorageVMotion может не работать, как насчет просто выключения виртуальных машин, просмотра хранилища данных, в котором они находятся, и перемещения файлов вручную из старого в новое хранилище данных - почти уверен, что это «бесплатно», но не во время работы виртуальных машин. Возможно, вам придется удалить виртуальные машины из инвентаризации VC, а затем повторно добавить их из файла .vmx, но это можно сделать быстро.

Оцените стоимость пары вариантов и попросите организацию — кто бы ни оплачивал счета — помочь принять решение. Как время простоя, так и его минимизация требуют затрат. Включите стоимость простоя и ваше время, а также все, что вы приобрели.

Восстановление резервной копии использует технологию, которая у вас уже есть, поэтому, возможно, без затрат на программное обеспечение. Вы уже должны делать резервные копии и время от времени проводить тесты восстановления, поэтому у вас должно быть представление о том, сколько времени это займет. Если вы никогда не выполняли восстановление, это отличный повод сделать это. Простое выключение и восстановление легко выполнить правильно, сохраняя целостность данных, но это может привести к многочасовому простою. Время восстановления и точка восстановления, вероятно, могут быть улучшены за счет более разумного подхода к восстановлению.

Минимизация времени простоя системы требует определенного проектирования и инфраструктуры. Можно ли сделать приложения высокодоступными за счет балансировки нагрузки между несколькими вычислительными виртуальными машинами? Тогда вариант может заключаться в том, чтобы запустить новый экземпляр, подержать оба за балансировщиком нагрузки в течение некоторого времени, а затем слить и удалить старый экземпляр.Высокая стоимость инфраструктуры, проектирования и времени обслуживания, но небольшое время простоя сервиса. Кроме того, может быть полезно поддерживать отдельные вычислительные экземпляры, например, при обновлении ОС.

И вариант живой миграции. Почти наверняка за vMotion Storage придется заплатить VMware, пусть продажи скажут вам, сколько. Кроме того, миграция оперативного хранилища имеет значительные требования к сети. За эти инвестиции можно купить команду для перемещения виртуальной машины практически с нулевым временем простоя. Несмотря на то, что это не влияет на ваше восстановление, оно не считается резервным копированием в плане обеспечения непрерывности бизнеса.

Вы могли бы использовать Автономный конвертер VMWare - бесплатный инструмент, предлагаемый самой VMWare для виртуализации аппаратных систем или миграции с других платформ виртуализации на VMWare. Здесь вы можете использовать функцию «Virtual2Virtual», где вы можете подключиться к одной системе виртуализации, а конвертер мигрирует систему в другую. Или вы можете использовать функцию «Physical2Virtual» — здесь вы управляете своей исходной виртуальной машиной, как если бы это был физический сервер, который необходимо виртуализировать.

Это также можно сделать как "горячую миграцию" без отключения исходной машины - по крайней мере, если это не что-то вроде контроллера домена MS, а также очень с очень загруженными базами данных, я бы не стал использовать "горячую миграцию".