[Перевод] Подготовка к миграции vCenter Server в vSphere 6.0 Update 2m. Часть 111.10.2016 11:03

Недавно VMware объявили о выходе vSphere 6.0 Update 2m, неофициально поддерживающего инструмент миграции. Под катом чеклист, как подготовится к миграции (важные точки проверки), какие модели миграции есть, и на что обратить внимание при миграции с 5.5 Windows vCenter на версию 6.0

vSphere домен
Модели развертывания
Правила внешней модели миграции версии 5.5

Миграция автоматически включена в новый vCenter Server Appliance 6.0 Update 2, уже доступна конфигурация миграции, и включена по умолчанию функция сохранения критических данных из Windows vCenter Server 5.5.

Если в вашей среде vSphere используются VDS (virtual distributed switch), то они мигрируют автоматически без дополнительных действий. Если вы хотите сохранить свою историю конфигураций и данные о производительности (статистику, события, задачи) с конфигурациями, есть опция которая позволяет перенести и эти данные. Только нужно помнить — это увеличит время вашей миграции и объем данных в вашей БД в vCenter Server.

Очень рекомендую использовать статью из вики KB 214620, которая поможет оценить и показать каким будет процесс миграции (как долго, какие ресурсы задействует и т.д.). В этом посте есть чек-лист того что нужно учитывать при подготовке к миграции, это имеет отношение к vSphere Single Sign-On домену и модели развертывания vCenter Server. Есть два самых главных момента, о инструменте миграции, которые я бы хотел особо подчеркнуть.

Первое. Будет выполнена не только ваша миграция, но и обновление версии 5.5 (с любыми апдейтами) до версии 6.0 (Update 2). Перед миграцией проверьте все ли части VMware и все решения сторонних вендоров поддерживают vSphere 6.0. Процедура миграции и апдейта не изменилась с прошлой версии, но сейчас есть механизм, который значительно упростил этот процесс.

Второй важный момент — нужно удостоверится что все конфигурации Windows vCenter Server уже сохранены. Сюда входят такие (но не только) данные и настройки: IP адреса, FQDN, UUID, сертификаты и MoRef IDs. Это делает процесс миграции намного проще, так как все части структуры общаются с vCenter Server через стандарт идентификации UUID, и они будут задействованы уже после миграции, как было и в старой версии. Этот список пунктов проверки очень важная часть подготовки процесса безболезненной миграции.

Давайте вначале разберемся с SSO доменом. В vSphere 5.5 у вас должна быть возможность объединить vSphere SSO домен, если вам это необходимо. Единственная ваша возможность сделать такое объединение — это в версии 5.5, потому что в версии 6.0 это сделать будет невозможно.

На примере ниже, два разных домена vSphere SSO (vSphere.local -1 и vSphere.local -2). Первоначальной целью было объединить эти 2 домена в один — vSphere.local, вместе со всеми конфигурациями из 2 доменов. Это удалось сделать, потому что эта опция выбора существующего домена SSO не была применена во время развертывания на втором сервере SSO.

Если у вас есть желание объединить домены vSphere SSO, необходимо до миграции сделать следующее:
• Разверните новый внешний SSO сервер
• Укажите vCenter Inventory Service, Web Client, и vCenter Server Service на новом SSO сервере
• Если вы идете от внутренней модели развертывания к внешней, должен быть установлен внутренний SSO компонент

После того, как процесс завершен, ваш SSO домен будет объединен, как показано на диаграмме справа, и вы можете приступать к процессу миграции. Во время этого объединительного процесса, обратите внимание, что есть — vSphere 6.0 SSO maximums. В этом гайде — детали, которые важны при объединении vSphere SSO домена в версии 5.5. Если вас устраивают ваша существующая топология vSphere SSO, тогда вы можете спланировать развертывание vCenter Server.

Простая модель включена во все службы vCenter Server, на одной виртуальной машине. С другой стороны, пользовательская модель позволяет разделить службы vCenter Server (SSO, Inventory Service, Web Client и vCenter Server) на разные виртуальные машины. В vSphere 6.0 упрощена модель развертывания благодаря внедренному компоненту Platform Services Controller (PSC). Теперь мы можем управлять разными службами, которые распределены по единичному домену vSphere SSO. В такие службы входят: Single Sign-On (SSO), управление сертификатами, лицензирование, роли, тегирование и категоризацию, управление общим доступом).

В vSphere 6.0 у нас также две модели развертывания, только теперь они называются «внутренняя» и «внешняя». Внутренняя модель развертывания vSphere 6.0 соответствует простой модели в версии 5.5. Это значит, что все сервисы vCenter Server и компонент PSC остаются на той же виртуальной машине. Во внешнем развертывании vSphere 6.0 на виртуальных машинах уже есть PSC компонент и vCenter. Сейчас каждый компонент отвечает и управляет службами. Список рекомендованных топологий для версии 6.0 здесь.

Среди преимуществ внешней модели внедрения Enhanced Linked Mode может делать автоматические масштабирование через добавление Enhanced Linked Mode и vCenter Server.

Важно! vSphere 6.0 Update 2m — НЕ позволяет менять топологию развертывания по время процесса миграции.

Правила внешней модели миграции версии 5.5:
• Не держите vCenter Inventory Service на той же виртуальной машине, что и внешний SSO Server. Внутренний SSO Server выключится после того как vSphere SSO Service мигрирует, сделав vCenter Inventory Service недоступным.
• Когда все службы разделены (SSO, vCenter Inventory Service, Web Client и vCenter Server, есть отдельно на каждой виртуальной машине) вам нужно всего лишь запустить ассистент миграции
• Ассистент миграции сделает блокировку, когда все расширения с сохранными настройками будут установлены на vSphere SSO Server. Расширение с сохранением настроек — это может быть один из сервисов, таких как vCenter Inventory Service, Auto Deploy, и vSphere Authentication Proxy
• Ассистент миграции просигнализирует, когда расширения без сохранения настроек будут установлены на vSphere SSO Server. Расширение без сохранения настроек, которые используют данные, но не хранят их — vSphere Web Client и Dump Collector.
• Доступна миграция vSphere SSO Servers в обход балансировщика загрузки.

VMware получили много вопросов о том, стоит или нет менять модель разворачивания vCenter Server из внутренней на внешнюю, и когда стоит менять модель внедрения — до или после процесса миграции. Если вам не нужно объединять домены SSO — тогда вначале используйте встроенную модель. После этого используйте cmsso-команду, чтобы пересобрать и заново сконфигурировать вашу внутреннюю модель на внешнюю. Больше информации по использованию cmsso для изменения своей топологии доступно здесь. Если вам нужно объединить SSO домены, тогда ваша внутренняя модель станет внешней как часть процесса объединения доменов. Когда процесс объединения завершен, вы можете начать процесс миграции. В миграции внешних моделей сначала идет миграция всех vSphere SSO серверов в рамках vSphere домена, а затем миграция всех серверов vCenter. Это ничем не отличается от процесса обновления.

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

Хороший ресурс, который поможет вам мигрировать, Migrating vCenter Server 5.5 to vCenter Server Appliance Update 2 FAQ.

И дайте нам знать, у вас получилось мигрировать или нет, можете отписаться в комментариях или в Твиттере через тег #migrate2vcsa так что техподдержка VMware может это отследить и ответить.

Сейчас мы разобрались с разными моделями миграции, внутренней, внешней для SSO доменов и серверов vCenter, в следующем посте в этой серии мы узнаем больше насчет Windows vCenter Server.

Мы разобрали чеклист, на что стоит обратить внимание при миграции, в версии 5.5 Windows vCenter.

• Распродажа выделенных серверов, в октябре от 75€
Бесплатная установка, быстрая активация в день заказа, бесплатное место для хранения бэкапов и многое другое.

Комментарии (0)