На днях мне подвернулась интересная задачка: потребовалось развернуть VMware vSphere vCenter Appliance 6 на хосте ESXi6, расположенном в ЦОДе хостера OVH.
Задачка нетривиальна тем, что у OVH свои отношения с маршрутизацией. Можете составить свое представление тут.
Лично у меня случился разрыв шаблона после настроек сети вида:
ip:10.1.1.1
mask:255.255.255.255
gateway:20.1.1.254
0. Стало ясно, что главный косяк случается на этапе развертывания: нужно поменять MAC, сетевые настройки и маршрутизацию апплайнсу, чтобы инсталлятор мог до него достучаться и дальше настроить.
- Ок, vCVA был развернут в моей инфраструктуре, экспортирован в OVA и перемещен туда. Тут-то меня и ждал первый “сюрприз”: при экспорте vCVA из vCenter в OVF добавляется много “неподдерживаемых” полей. Импортировать такой шаблон на ESXi (без vCenter) не получится. Отредактировать руками OVF – достаточно непросто.
В ходе экспериментов выяснилось, что в OVF-файле в двух местах хранятся размеры жестких дисков виртуальной машины. Поле size с точностью до байта должно отражать текущий размер vmdk в шаблоне, поле propagetedsize – видимо, количество секторов по 512 байт.
Есть файл “manifest”, содержащий SHA-1 хэш всех файлов. Если решили править руками ovf-файл, избавьтесь от манифеста.
2. После импортирования, запуска и смены ip-адреса в VCVA доступ извне появился. Однако, службы не запускаются, точнее, служба vpxd запустилась, но https://vcenter выдавал ошибку. Зайти на PSC (https://vcenter/psc) также не получалось. Логи vpxd.log показали, что в ряде мест используется старый “локальный” адрес, использованный для развертывания апплайнса.
3. В ходе этих мучений была найдена работающая последовательность, ею я и хочу поделиться:
- поднять в локальной сети ESXi;
- создать на локальном DNS-сервере зону domain.com и A-запись vc.domain.com, ссылающуюся на локальный адрес. Поменять FQDN-имя сервера после установки не получится;
- запустить установку апплайнса на сервер с адресом из локальной сети;
- после развертывания проверить, что службы запустились (открывается <https://vc/psc> и <https://vc/sphere-client> windows-клиент может подключиться);
- ВАЖНО: после этого необходимо подключиться windows-клиентом к хосту ESXi, на котором запущен апплайнс, выключить апплайнс и экспортировать его. Экспортировать лучше в OVA – это zip-архив с OVF и VMDK-файлами;
- полученный шаблон импортируется на хост в OVH. В настройках ВМ MAC-адрес меняется на тот, который предоставлен провайдером;
- включается vcva, производятся изменения в сетевые настройки (ifcfg-eth0 и routes), вносится правильный адрес в файл /etc/hosts;
- полученный сервер перезагружается
Можно пользоваться, хотя что будет с этим vCenter server после обновления – надо проверять!
КМК, вместо экспорта в OVF может помочь инструкция по установке VCSA на Workstation:
http://www.virten.net/2015/04/how-to-install-vcenter-server-appliance-vcsa6-in-vmware-workstation/
Ничего удивительного в маске – просто указываем что весь трафик идет бродкастом. Обычное дело когда весь трафик нужно завернуть через шлюз.
Не понял в чем траблы с установкой сразу на месте. Тогда единственном нюансом будет на этапе powering on выключить виртуалку, заменить mac на нужный и включить.
По смене fqdn – да, много мест где используется. Простой вариант – после смены добавить в hosts старое имя.
Саша, помимо MAC еще надо будет роутинг поколбасить и сетевые настройки. “Визарду” не нравится маска 32 бита и шлюз из “левой” подсети.
Я не пробовал “вмешаться” в процесс powerOn, но есть подозрение, что инсталляция просто зафейлится, если машинка не включится в течение недолгого времени.
Андрей, визард на этом этапе терпеливо ждет. 5 минут точно, дольше не проверял 🙂
По роутингу, действительно, забыл что у suse скрипт роутинга не позволяет корректно задать роут для данного случая – надо добавлять скрипт POST_UP
Ну тогда да, варианта 2:
– брать голую ova с диска, развернуть, подсунуть настроенный vmx и доделать через консоль.
– настроить все “дома” на esxi, экспортировать и импортировать уже настроенную виртуалку.
Bridged networking для VCSA???
Коллеги, “вы почто зверушку тираните”?
Александр, пишите мне – расскажу как правильно private clouds развертывать в OVH, Hertzner и у других провайдеров. Опыт 4 года.
Нельзя, никак, никогда, ни при каких условиях VCSA под реальный ip выставлять.
Это же дуршлаг, решето с точки зрения безопасности.
Прикрываем все pfsense, например и за ним все аккуратно строим. Для сетей провайдеров knort абсолютно обязателен!!! Там кетайские боты пол полосы сканами сжирают. Я смотрел логи и ужасался!
Можно esxi выставить через NAT с заменой портов, но лучше ходить внутрь уютного облачка через VPN, который на виртуалке пашет.
А уж если вам надо VCSA unattended поставить, то читаем тут – http://www.virtuallyghetto.com/2015/02/ultimate-automation-guide-to-deploying-vcsa-6-0-part-1-embedded-node.html
В принципе согласен.
Ситуацию немного выправляет то, что у VCSA и ESXi есть свои брандмауэры, так что можно ограничить подключения только определенными сетями.
Андрей, брандмауеры есть, но там портов с кривыми и дырявыми сервисами жуть сколько работает.
Реально, лучше не рисковать.
Самый простой вариант это поставить pfsense раскорячив его WAN-LAN между двумя vSwitch (для LAN даже vmnic не нужен)
Убираем ip с vmk0, но не трогаем его.
Поднимаем VPN и ходим в LAN через него.
Это для 1 esxi.
Если полноценно строить кластер, то для OVH нужен vRack, a для Hetzner – заказывать свитч аппаратный.
Ну, а дальше там масса нюансов как не потерять управление 🙂