Миграция VMware Cloud Director Linux Deployment на Appliance Deployment с Database HA
По аналогии с vCenter Server компания VMware переносит свой продукт Vmware Cloud Director (далее VCD) в формат Virtual Appliance, т.е. готовый шаблон ВМ содержащий все необходимые компоненты для функционирования продукта, многие администраторы компаний-провадеров, использующих VCD начинают задумываться о миграции с Linux версии продукта (которая пока еще поддерживается) на Virtual Appliance.
Я произвел в этом году 4 таких операции, в процессе которых выявил некоторые неточности в плане миграции из документации.
Начальные условия и конечный результат
Предполагается что у вас развернута классическое приложение состоящее из собственно самого приложения VCD, его сервера БД и Load Balancer (у вас ведь больше 1 cell, да?).
Результатом проделанной работы будет VCD развернутый на базе 3 (минимум) Virtual Appliance в конфигурации Database HA.
В рамках данного мануала не входит описание настройки LB, так как для балансировки приложения каждый использует разные LB. В моем случае используется NSX-v Edge LB.
Подготовка
Первым этапом будет развертывание "рядом" с имеющимся инстансом, нового greenfield инстанса в виде Database HA конфигурации. Данная конфигурация состоит из 3х аплайнсов VCD (Primary Cell и двух Standby Cell с репликами БД VCD). После миграции, при необходимости, можно развернуть несколько Application Cells (аплайнсов с отключеным postgresql) если необходимо отмасштабировать ваш инстанс.
Важно!
Версия аплайнсов нового инстанса должна совпадать с исходным инстансом вплоть до билда. При необходимости, можно обновить либо исходный инстанс, либо использовать аплайнсы с текущей версией, и после миграции уже обновиться до последней версии.
Развертывать новый инстанс удобнее всего через ovftool.
Из нюансов тут можно отметить следующее - ваша NFS Transfer Share должна быть другой, нежели та, что используется для текущего инстанса, так как GID/UID старого инстанса будут отличаться от GID/UID нового инстанса.
Важно!
Аплайнс будет менять в данной шаре права для всех вложенных папок. Важно что бы он мог это сделать, иначе firstboot script при невозможности данной операции остановит свое выполнение и корректное развертывание аплайнса не произойдет. В качестве примера могу привести собственный опыт – мы используем в качестве nfs сервера – СХД NetApp, для volume по умолчанию включены снэпшоты и при экспорте nfs в корне шары существует папка .snapshots, права на которую сменить нельзя.
ovftool --noSSLVerify --acceptAllEulas \ --X:enableHiddenProperties \ --datastore="<datastore>" --allowAllExtraConfig \ --net:"eth0 Network"="<network1>" --net:"eth1 Network"="<network2>" \ --name=<appliance name> --diskMode=thin \ --prop:"vami.ip0.VMware_vCloud_Director"="<primary ip>" \ --prop:"vami.ip1.VMware_vCloud_Director"="<secondary ip>" \ --prop:"vami.DNS.VMware_vCloud_Director"="<dns ip>" \ --prop:"vami.domain.VMware_vCloud_Director"="<domain>" \ --prop:"vami.gateway.VMware_vCloud_Director"="<gateway>" \ --prop:"vami.netmask0.VMware_vCloud_Director"="<primary ip netmask>" \ --prop:"vami.netmask1.VMware_vCloud_Director"="<secondary ip netmask>" \ --prop:"vami.searchpath.VMware_vCloud_Director"="<dns search path>" \ --prop:"vcloudapp.enable_ssh.VMware_vCloud_Director"="True" \ --prop:"vcloudapp.expire_root_password.VMware_vCloud_Director"="False" \ --prop:"vcloudapp.nfs_mount.VMware_vCloud_Director"="<nfs transfer share path>" \ --prop:"vcloudapp.ntp-server.VMware_vCloud_Director"="<ntp server>" \ --prop:"vcloudapp.varoot-password.VMware_vCloud_Director"="<appliance root password>" \ --prop:"vcloudconf.db_pwd.VMware_vCloud_Director"="<db password>" \ --prop:"vcloudconf.admin_email.VMware_vCloud_Director"="<administrator email>" \ --prop:"vcloudconf.admin_fname.VMware_vCloud_Director"="<vcd admin full name>" \ --prop:"vcloudconf.admin_pwd.VMware_vCloud_Director"="<administrator password>" \ --prop:"vcloudconf.admin_uname.VMware_vCloud_Director"="administrator" \ --prop:"vcloudconf.inst_id.VMware_vCloud_Director"="<instance id>" \ --prop:"vcloudconf.sys_name.VMware_vCloud_Director"="<system name>" \ --deploymentOption="primary-large" --powerOn \ .\VMware_Cloud_Director-10.2.0.5190-17029810_OVF10.ova \ vi://<username>@<vcsa-fqdn>/<Datacenter>/host/<custer|hostname>
ovftool --noSSLVerify --acceptAllEulas \ --X:enableHiddenProperties \ --datastore="<datasore>" --allowAllExtraConfig \ --net:"eth0 Network"="<network1>" --net:"eth1 Network"="<network2>" \ --name=<appliance name> --diskMode=thin \ --prop:"vami.ip0.VMware_vCloud_Director"="<primary ip>" \ --prop:"vami.ip1.VMware_vCloud_Director"="<secondary ip>" \ --prop:"vami.DNS.VMware_vCloud_Director"="<dns ip>" \ --prop:"vami.domain.VMware_vCloud_Director"="<domain>" \ --prop:"vami.gateway.VMware_vCloud_Director"="<gateway>" \ --prop:"vami.netmask0.VMware_vCloud_Director"="<primary ip netmask>" \ --prop:"vami.netmask1.VMware_vCloud_Director"="<secondary ip netmask>" \ --prop:"vami.searchpath.VMware_vCloud_Director"="<dns search path>" \ --prop:"vcloudapp.enable_ssh.VMware_vCloud_Director"="True" \ --prop:"vcloudapp.expire_root_password.VMware_vCloud_Director"="False" \ --prop:"vcloudapp.nfs_mount.VMware_vCloud_Director"="<nfs transfer share path>" \ --prop:"vcloudapp.ntp-server.VMware_vCloud_Director"="<ntp server>" \ --prop:"vcloudapp.varoot-password.VMware_vCloud_Director"="<appliance root password>" \ --prop:"vcloudconf.sys_name.VMware_vCloud_Director"="<system name>" \ --deploymentOption="standby-large" --powerOn \ .\VMware_Cloud_Director-10.2.0.5190-17029810_OVF10.ova \ vi://<username>@<vcsa-fqdn>/<Datacenter>/host/<custer|hostname>
Описание всех параметров для деплоя OVA есть тут.
Важно!
Если вы хотите развернуть новые cells с теми же IP адресами что у имеющейся инсталляции, то вам придется предварительно остановить старый инстанс, скопировать с одного cell файлы:
/opt/vmware/vcloud-director/etc/global.properties
/opt/vmware/vcloud-director/etc/responses.properties
/opt/vmware/vcloud-director/etc/certificates
/opt/vmware/vcloud-director/etc/proxycertificates
/opt/vmware/vcloud-director/etc/truststore
Результатом данных действий будет новый чистый инстанс VCD состоящий из 3х аплайнсов. Его работу можно (и нужно) проверить залогинившись в каждый из них по primary ip с учетной записью administrator и паролем, указанным в скрипте деплоя Primary Cell. Если что то пошло не так - внимательно изучаем /opt/vmware/var/log/firstboot файл.
Перенос БД и настроек
На старом инстансе останавливаем приложение на всех cell.
service vmware-vcd stop
На этом этапе можно выключить все три аплайнса новой инсталляции и сделать для них снэпшоты. В случае неудачи - можно будет откатить их вместо развертывания новых.
Подключаемся к серверу БД и делаем дамп БД "vcloud" в файл
sudo -u postgres <path to pg_dump> -Fc vcloud > /tmp/vcloud.bak
Важно!
Если ваша БД VCD отличается названием от 'vcloud', а также используется имя пользователя отличное от 'vcloud', вам нужно будет создать этого пользователя в postgersql Primary Cell для восстановления вашей БД и после восстановления переименовать БД в 'vcloud' а так же сменить БД владельца на пользователя 'vcloud'. Детально об этом пишется в документации.
На новом инстансе выключаем приложение на каждом аплайнсе
service vmware-vcd stop
На Primary Cell копируем дамп БД в /tmp (напирмер) и меняем для него права
chmod a+r /tmp/vcloud.bak
Удаляем на новом инстансе старую БД (это делается только на Primary Cell)
sudo -i -u postgres /opt/vmware/vpostgres/current/bin/psql -c 'DROP DATABASE vcloud;'
sudo -u postgres /opt/vmware/vpostgres/current/bin/pg_restore -C -d postgres /tmp/vcloud.bak
Заменяем на всех аплайнсах файлы global.properties, responses.properties, certificates, proxycertificates, truststore скопированные ранее с одного из cell старого инстанса
Реконфигурируем службу VCD на каждом cell
Важно!
Обратите внимание на следующую команду. Она отличается primary ip адресами, но должна указывать на secondary ip нашего Primary Cell - именно на нем находится продуктивная БД.
/opt/vmware/vcloud-director/bin/configure --unattended-installation --database-type postgres --database-user vcloud \ --database-password db_password_new_primary --database-host eth1_ip_new_primary --database-port 5432 \ --database-name vcloud --database-ssl true --uuid --keystore /opt/vmware/vcloud-director/certificates.ks \ --keystore-password root_password_new_primary --primary-ip appliance_eth0_ip \ --console-proxy-ip appliance_eth0_ip --console-proxy-port-https 8443
Копируем наш кейстор с сертификатами в трансфер шару
scp ./certificates.ks root@<primary cell>:/opt/vmware/vcloud-director/data/transfer/certificates.ks
Не забываем сменить ему владельца
chown vcloud:vcloud /opt/vmware/vcloud-director/data/transfer/certificates.ks
Меняем текущий кейстор на новый (на самом деле старый) на каждом аплайнсе
/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j -p --keystore /opt/vmware/vcloud-director/data/transfer/certificates.ks \ --keystore-password 'keystore_password'
:-)
Вы ведь не забыли сохранить пароль от кейстора, правда?
Включаем приложение (сначала на Primary Cell, и если успешно запустилось - на остальных)
service vmware-vcd start
И внимательно изучаем /opt/vmware/vcloud-director/logs/cell.log - как минимум приложение сругнется на отсутствие старых cell, что однако не мешает ему успешно стартануть.
После миграции
Есть некоторое количество операций которые требуется не забыть проделать после проведенных работ
- Модифицировать вашу конфигурацию LB, что бы пулы для HTTP, HTTPS и TCP трафика ссылались на новые IP и порты.
- Удалить старые cells из БД (идем в раздел Cloud Resources и нажимаем Unregister для каждого Inactive Cell)
- Проверьте что ваш VCD подключился ко всем vCenter и NSX (возмолжно понадобится добавить сертификаты этих продуктов в trusted - через UI или /opt/vmware/vcloud-director/bin/cell-management-tool trust-infra-certs --vsphere --unattended)
Откат
Если вдруг что-то пошло не так - самый простой вариант отката, это выключить новые cells и включить обратно старые.