Подготовка к миграции vCenter Server в vSphere 6.0 Update 2m. Часть 1

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

Миграция автоматически включена в новый 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, и они будут задействованы уже после миграции, как было и в старой версии. Этот список пунктов проверки очень важная часть подготовки процесса безболезненной миграции.

vSphere домен

Золотое правило подготовки к любой миграции и апдейтам: «нужно хорошо знать свою ИТ-инфраструктуру». Есть две сферы, на которых также нужно сфокусироваться — это модели развертывания vSphere Single Sign-On домен (SSO) и vCenter Server.

Давайте вначале разберемся с 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. Windows vCenter Server 5.5 имеет две модели развертывания: простая и пользовательская.

Простая модель включена во все службы 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. Это ничем не отличается от процесса обновления.

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

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

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

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

Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка

Установка vCenter 6.7

Привет. Сегодня поставим vCenter 6.7. Если конкретнее, то будем ставить VCSA (VMware vCenter Server Appliance). По пути пару раз наступим на грабли. С четвёртой попытки vCenter наконец-то поставится.

Подготовка к установке VCSA

Виртуалку c VCSA будем называть «vcenter«.

Скачиваем дистрибутив VCSA. VMware-VCSA-all-6.7.0-11726888.iso.

Компьютер для установки

Устанавливать будем с компьютера на Windows 10. Обычная рабочая машина. Пусть называется «wks«.

Хост ESXi

VCSA нужно куда-то устанавливать. Для этого нужно подготовить хост ESXi. Назовём его «hv«. Я развернул на hv операционную систему ESXi 6.7 Update 1 (Build 10302608).

IP адрес PS: 10.10.52.10
hostname: hv

На hv создадим Port Group, назовём «HV«. Настраиваю там VLAN — 52. Примечательно, что Management Network у нас в том же VLAN, но в него не удастся засунуть vcenter при установке.

Это грабли №1, на которые я наступил.
Создайте заранее Port Group для vcenter и hv.

Как оказалось, для установки vCenter 6.7 нужен DNS. IP адреса DNS серверов: 10.10.47.10, 10.10.47.11.

Нужно прописать домен для hv и vcenter. Для hv — не обязательно, но IP должны быть в одной подсети, у меня один VLAN — 52.

Это грабли №2, на которые я наступил.
Создайте доменное имя для vcenter.

Доступы

С wks, hv, vcenter должен быть доступ по TCP 53 к DNS.

С wks должен быть доступ по TCP 80 (HTTP) и TCP 443 (HTTPS) к vcenter и hv.

С wks должен быть доступ по TCP 5480 к vcenter.

Это грабли №3, на которые я наступил.
Прописывайте заранее доступы.

Итого

VCSA — vcenter.ps.local 10.10.52.50
ESXi — hv.ps.local 10.10.52.10
DNS — 10.10.47.10, 10.10.47.11.

Установка VCSA

Монтируем скачанный образ VMware-VCSA-all-6.7.0-11726888.iso.

Так как устанавливать будем с Windows 10, то нам потребуется папка vca-ui-installer. В ней win32.

Запускаем installer.exe. Открывается мастер установки.

Наша задача — развернуть новый vCenter, нажимаем Install. Открывается вкладка Introduction.

На этой странице показывается этап установки. Мы на первом этапе Stage 1 — Deploy appliance. Нажимаем NEXT. Открывается вкладка End user license agreement.

Принимаем лицензионное соглашение. Нажимаем NEXT. Открывается вкладка Select deployment type.

Нам предлагается выбрать тип установки. Первые вариант: Embedded Platform Services Controller — vCenter и Platform Services Controller на одной виртуалке. Второй вариант: External Platform Services Controller — vCenter и Platform Services Controller на разных виртуалках. Я буду разворачивать всё на одной машине. поэтому выбираю Embedded Platform Services Controller. Нажимаем NEXT. Открывается вкладка Appliance deployment target.

Здесь нужно выбрать хост, на котором будем создавать виртуалку VCSA. В поле ESXi host or vCenter Server указываем доменное имя или IP адрес нашего хоста hv — 10.10.52.10. Именно поэтому я говорил, что доменное имя для хоста не обязательно, IP адрес прекрасно подходит. HTTPS порт у меня по умолчанию — 443. User name — root, это пользователь ESXi. Password — пароль от него, задавали при установке гипервизора. Нажимаем NEXT.

На хосте у меня самоподписанный сертификат, нажимаю в окне предупреждения YES.

Ждём. Открывается вкладка Set up appliance VM.

Заполняем информацию о виртуалке VCSA. В поле VM name можно указать название виртуалки. Пишу vcenter. Set root password — указываем пароль от пользователя root будущего vCenter. Под этим пользователем можно входить в админку и SSH.

Пароль должен быть достаточно сложным. Повторяем пароль в поле Confirm root password.

Нажимаем NEXT. Открывается вкладка Select deployment size.

Здесь нам предлагается выбрать Deployment size и Storage size. Основным критерием служит количество гипервизоров и виртуалок, которые будет обслуживать vCenter. Есть 5 вариантов:

1. Tiny
   — 2 процессора
   — 10 Гб оперативки
   — диск 300 Гб
   — количество хостов до 10
   — количество виртуалок до 100
2. Small
   — 4 процессора
   — 16 Гб оперативки
   — диск 340 Гб
   — количество хостов до 100
   — количество виртуалок до 1000
3. Medium
   — 8 процессоров
   — 24 Гб оперативки
   — диск 525 Гб
   — количество хостов до 400
   — количество виртуалок до 4000
4. Large
   — 16 процессоров
   — 32 Гб оперативки
   — диск 740 Гб
   — количество хостов до 1000
   — количество виртуалок до 10000
5. X-Large
   — 24 процессора
   — 48 Гб оперативки
   — диск 1180 Гб
   — количество хостов до 2000
   — количество виртуалок до 35000

Я выбираю для себя Small. Нажимаем NEXT. Открывается вкладка Select Datastore.

Выбираем хранилище, на котором будет обитать виртуалка VCSA. Можно сделать диск тонким, выбрав галку Enable Thin Disk Mode. Я не ставлю галку — предпочитаю использовать толстые диски. На Install on a new vSAN cluster containing the target host — не смотрю, нет у меня vSAN. Нажимаем NEXT. Открывается вкладка Configure network settings.

Вот здесь нужно быть внимательнее. Настраиваем сеть. На этой вкладке можно накосячить и VCSA придётся устанавливать заново. Я накосячил и переустанавливал 🙂 Проблема в том, что на форме присутствует ошибка. Поле FQDN — необязательное, не верьте! В FQDN можно использовать IP адрес — не верьте!

Это грабли №4, на которые я наступил. Критичные.
В поле FQDN обязательно указывайте доменное имя vCenter!

Данное доменное имя должно быть прописано в DNS, которые укажем в поле DNS servers. Прописываем в прямой и обратной зоне.

Итак, заполняем форму:

Network — указываем HV — созданный нами Port Group в 52 VLAN.

IP version — мы пока живём по-старому, указываем IPv4.

IP assignment — выбираю static, у меня статичный IP адрес 10.10.52.50.

Subnet mask or prefix length — указываю маску 255.255.255.0.

Default gateway — шлюз 10.10.52.1.

DNS servers — DNS сервера через запятую 10.10.47.10, 10.10.47.11.

Common ports — оставляю по умолчанию. HTTP — 80, HTTPS — 443.

Нажимаем NEXT. Открывается вкладка Ready to complete stage 1.

Проверяем всё и жмём FINISH. Начинается деплой виртуалки на хост.

Первый этап завершён. Обратите внимание на ссылку https://vcenter.ps.local:5480, если вместо доменного имени в ней вы видите IP адрес, то есть большой шанс на то, что установка завершится ошибкой. Нажимаем CONTINUE. Открывается вкладка Introduction.

Теперь нам показывают, что мы попали на второй этап установки — Set up vCenter Server Appliance. Нажимаем NEXT. Открывается вкладка Appliance configuration.

Time synchronization mode — выбираем способ синхронизации времени. Можно настроить NTP, я же синхронизирую время vCenter с хостом.

SSH access — мне не нужен доступ по SSH в данный момент, Disabled.

Нажимаем NEXT. Открывается вкладка SSO configuration.

Оставляю Create a new SSO domain.

В поле Single Sign-On domain name пишем «vsphere.local».

В поле Single Sign-On user name пишем «administrator».

В поле Single Sign-On password задаём пароль пользователю administrator@vsphere.local.

В поле Confirm password повторяем пароль. Нажимаем NEXT. Открывается вкладка Configure CEIP.

Снимаем галку с Join. Нажимаем NEXT. Открывается вкладка Ready to complete.

Всё проверяем. Если у вас вместо доменного имени «vcenter.ps.local» написано «photon-machine», то есть большой шанс на то, что установка завершится ошибкой. Нажимаем FINISH. Начинается установка.

И дальше. В процессе установки могут возникнуть ошибки, ниже я привёл несколько примеров.

И наконец — конец.

Нажимаем CLOSE. Проверяем работу админки: https://vcenter.ps.local:5480 — всё работает. Для входа в админку логин root и заданный при установке пароль.

Проверяем работу vCenter: https://vcenter.ps.local. Для входа логин administrator@vsphere.local и заданный при установке пароль.

Всё работает, установка завершена.

Ошибки при установке

Второй этап Stage 2 не запускается в инсталляторе

The installer is unable to connect to the vCenter Appliance Management Interface.

Нет доступа с wks на https://vcenter.ps.local:5480. Либо firewall, либо неверно создана Port Group. После исправления можно зайти на https://vcenter.ps.local:5480 и продолжить установку по web.

IP адрес в ссылке после первого этапа

Если после первого этапа вы вместо ссылки https://vcenter.ps.local:5480 видите https://10.10.52.50:5480, то есть большой шанс на то, что установка завершится ошибкой. Вы не указали FQDN для vCenter.

Тут я переустанавливал заново.

photon-machine

На втором этапе на вкладке Ready to complete видим, что host name у нас photon-machine, есть большой шанс на то, что установка завершится ошибкой. Вы не указали FQDN для vCenter.

Тут я переустанавливал заново.

An error occurred while starting service ‘cm’

Ошибка во втором этапе. Вы не указали FQDN для vCenter.

Тут я переустанавливал заново.

This application cannot be used or repaired because a failure was encountered

Обычно это окно показывается после других ошибок. Можно скачать логи по ссылке и посмотреть где затык. У меня даже логи не качались из-за того, что я не казал FQDN для vCenter.