Newlord
Contributor
Contributor

миграция между двумя vcenter

Jump to solution

Есть 2 настроенных и объединенных с SSO 2 vCenter, проблема в том что между двумя разными vCenter нельзя мигрировать виртуальные машины, не в включенном не в выключенном состоянии, а данная возможность требуется. Отсюда вопрос что нужно еще установить чтобы иметь такую возможность? Снести 1 vCenter не предлагать, с радостью бы снес если б в SRM они оба не требовались...

0 Kudos
1 Solution

Accepted Solutions
moshkow
Hot Shot
Hot Shot

Виртуалку перед миграцией передвинуть на общую NFS-шару

Хост-1 с виртуалкой переподцепить к альтернативному VC-2

Сделать там vmotion на другой хост, после этого Хост-1 можно переподцепить обратно, в старый VC-1

-------------------

Либо, как вариант - без NFS-шары

Перецепляем хост в VC-сервер второго датацентра, делаем виртуалке  Extended-vmotion (с одновременной миграцией виртуальных дисков и самой виртуалки)

Затем хост возвращаем в вцентр первого датацентра.

P.S. Подразумевается, что портгруппа виртуальной машины  на хосте исходнике и итоговом одинаково называется и глядит в одну и ту же физическую сеть

View solution in original post

0 Kudos
18 Replies
EGarbuzov
VMware Employee
VMware Employee

То, что vCS связаны между собой не подразумевает, возможность миграции ВМ между ними.

У вас уже есть SRM, почему не использовать его, если речь идёт о плановых миграциях ВМ между площадками?

0 Kudos
DK5
Enthusiast
Enthusiast

живая миграция возможна только в пределах кластера (в пределах одного vCenter), вам доступна только репликация (собственно на ней SRM и работает), если вам нужна все таки живая миграция потребуется пересмотреть архитектуру вашей среды

0 Kudos
Newlord
Contributor
Contributor

В данной схеме vCloud Suite не поможет? тут замкнутый круг, есть 2 отдельные структуры в каждой свои сервера и хранилища, сетевые настройки и vlanы везде идентичны, есть общее хранилище NFS видимое со всех серверов в идеале бы иметь возможность мигрировать сервер на NFS  и потом перенести его на другой vCenter. Отказаться от 2-х vCenter не возможно так как требуется наличие зеркальной копии СХД и возможность в полуавтоматическом режиме в случае отказа 1 хранилища сразу перезапуститься на втором хранилище. Варианты какие-то есть?

SRM позволяет выполнить миграцию с выключением только это не совсем подходит.

0 Kudos
EGarbuzov
VMware Employee
VMware Employee

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

Newlord wrote:

...есть общее хранилище NFS видимое со всех серверов в идеале бы иметь возможность мигрировать сервер на NFS  и потом перенести его на другой vCenter.

Потому что например в таком случае вполне возможно после миграции на раздел с NFS сервера удалить ВМ из иерархии одного vCS и зарегистрировать в другом vCS. Простой будет примерно равен двойному времени запуска ОС и сервисов в ней.

0 Kudos
Newlord
Contributor
Contributor

Интересует именно миграция в запущенном состоянии, с выключением и удалением ВМ из vCenter с последующим добавлением в другой этот вариант не очень интересует. Возможно ли мигрировать в включенном состоянии используя какой нибудь продукт от vmware например vcloud ?

0 Kudos
EGarbuzov
VMware Employee
VMware Employee

Насколько я знаю, готового решения, удовлетворяющего всем вашим требованием нет.

Не могли бы вы более подробно описать логику вашей задачи? Необходимо одни и теже ВМ защищать SRM'ом и иметь возможность на горячуюю смигрировать в другой кластер другого vCS (расположенный на другой физической площадке)?

Если нет, почему бы не сделать для части ВМ, нуждающейся к миграции туда-сюда отдельный, растянутый кластер под управлением любого из ваших vCS?

0 Kudos
Newlord
Contributor
Contributor

Есть 2 территориально разделенные между собой площадки, на каждой из площадок есть свои сервера и свои СХД, каждая площадка управляется своим vCS, На случай сбоя целиком площадки используется SRM  с репликацией на уровне СХД, а для балансировки между площадками или на случай например запланированного полного обесточивания площадки или на случай работ на линии между площадками не хотелось бы прерывать сервисы, все возможные варианты причин для миграции не буду расписывать но их гораздо больше.... Вот отсюда и вопрос как это можно организовать?

0 Kudos
Newlord
Contributor
Contributor

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

0 Kudos
Dmitry_G
Hot Shot
Hot Shot

Как уже было сказано решения без перерыва сервиса пока нет. Для ваших задач подошел бы vSphere Stretched Cluster http://www.vmware.com/files/pdf/techpaper/Stretched_Clusters_and_VMware_vCenter_Site_Recovery_Manage...

VCAP-DCD, VCAP-DCA, VCP-Cloud, VCP-DCV, CCNA
Newlord
Contributor
Contributor

Спасибо за информацию, но реализация vSphere Stretched Cluster требует достаточно больших вложений и изменений. И в нашем случае вряд ли имеет смысл отказываться от того что существует и успешно работает ради возможности переносить ВМ на горячую, и пары еще сомнительных плюсов. Если вариантов больше нет спасибо за ответы.

0 Kudos
moshkow
Hot Shot
Hot Shot

Виртуалку перед миграцией передвинуть на общую NFS-шару

Хост-1 с виртуалкой переподцепить к альтернативному VC-2

Сделать там vmotion на другой хост, после этого Хост-1 можно переподцепить обратно, в старый VC-1

-------------------

Либо, как вариант - без NFS-шары

Перецепляем хост в VC-сервер второго датацентра, делаем виртуалке  Extended-vmotion (с одновременной миграцией виртуальных дисков и самой виртуалки)

Затем хост возвращаем в вцентр первого датацентра.

P.S. Подразумевается, что портгруппа виртуальной машины  на хосте исходнике и итоговом одинаково называется и глядит в одну и ту же физическую сеть

View solution in original post

0 Kudos
Newlord
Contributor
Contributor

Да, такой вариант имеет право на жизнь но с ним много проблем и нюансов надо учитывать например что на текущий момент все хосты подцеплены в распределенный виртуальный свич значит 1 интерфейс должен не быть подключен к нему, нужно сначала виртуалку переключить на него потом переподцепить хост на другой vCS подключить распределенный виртуальный свич от второго vCS переключить интерфейс виртуалки на него и только потом смигрировать. тогда время простоя сведется к паре мс. большинство сервисов даже не почувствует. Если на хосте 3 сетевых интерфейса 1 подключен в виртуальный распределенный свич от первого vCS второй в стандартный свич потом хост переключить на другой vCS и попробовать подключить третий интерфейс в второй vCS, vCS это позволит ? если такой вариант сработает можно выделить 1 хост под такие задачи на случай острой необходимости.

0 Kudos
moshkow
Hot Shot
Hot Shot

VDS добавят геммороя.

Он, в принципе, преодолим, просто нужна предельная аккуратность и точная последовательность действий.

И предварительные тренировки для отладки процесса.

Но если все равно резервировать аплинк, то советую обойтись без заморочки с VDS'ами.

На хосте-1 и хосте-2  делаем одинаковые "транспортные" _стандартные_ свитчи.

Перед началом переезда перетыкаем на хосте-1 один из аплинков в "транспортный" свитч, и пересаживаем на него виртуалку.

Затем запускаем процедуру ухода в соседский VC и миграцию.

Когда хост-1 вернется в VC-1, аплинк из "транспортного" свитча можно вернуть обратно в VDS

0 Kudos
Newlord
Contributor
Contributor

Такой вариант имеет недостаток в момент когда будете мигрировать с стандартного свича на распределенный уже на втором vCS миграция запустится но как только машина мигрирует она окажется вообще без сетевого линка. чтобы этого избежать нужно ее еще до миграции переключить на правильный распределенный свич и vlan.

0 Kudos
moshkow
Hot Shot
Hot Shot

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

ее в VDS-2 переключаем, и можно аплинк из "транспортного" свитча-2 тоже вынуть и вернуть VDS'у-2

0 Kudos
Newlord
Contributor
Contributor

Этот вариант требует настройки трех хостов и при каждой миграции менять настройки, гораздо проще настроить 1 хост по моему варианту если он сработает и тогда придется только переключать его между vCS не настраивая хост. Мне кажется так проще.

0 Kudos
moshkow
Hot Shot
Hot Shot

Не 3 а 2 хостов. Можно один раз настроить, и больше не перестраивать.

Вариант с VDS работоспособен, хотя и требует особой аккуратности.

Вариант с транспортным стандартным свитчом заведомо имеет меньше потенциальных граблей.

В любом случае сгодится тот вариант, который будет работать Smiley Happy - в конце концов хозяин - барин.

0 Kudos
Newlord
Contributor
Contributor

Спасибо за помощь.

0 Kudos