Gdy twoje vCD Cell nie chcą zmienić nazwy

Co zrobić gdy próbujesz zainstalować najnowszą wersję vCloud Director 10, a podczas deployment maszyn wirtualnych vCD Cell nie dochodzi do zmiany nazwy (hostname) w systemie gościa? Gdy, mimo wielu prób, nazwa systemu pozostawała w formie „photon-machine”. Powoduje to, że nie zmieniała się również nazwa instancji w klastrze PostgreSQL. Natomiast brak zmiany nazwy klastra uniemożliwia dodanie kolejnego węzła do klastra PostgreSQL, a co za tym idzie blokuje uruchomienie infrastruktury vCloud Director w modelu redundantnym (czyli więcej niż dwie Cell z aktywną bazą danych).

Infrastruktura maszyn wirtualnych została skonfigurowana w następującej architekturze:

Ze względu na kluczowość tej informacji serwery DNS zostały oparte o system PhotonOS oraz oprogramowanie Unbound.

Szarpaliśmy się trochę z tym i przeprowadziliśmy szereg prac diagnostycznych. Między innymi uruchomiliśmy serwery vCD z interfejsami eth0 i eth1 w sieci net-internal, aby uniknąć problemu z FW. Niestety operacje te nie przyniosły żadnego rezultatu. Przed każdą próbą instalacji wykonywane było czyszczenie zasobów NFS. Uprawnienia NFS w czasie instalacji były ustawiane na 777. Oprogramowanie vCD było instalowane zarówno przez interfejs HTML5, Flex, jak również przy użyciu następującej komendy ovftool:

ovftool 
  --noSSLVerify 
  --acceptAllEulas 
  --datastore="VMFS_Datastore" 
  --allowAllExtraConfig 
  --net:"eth0 Network"="net-internal" 
  --net:"eth1 Network"="net-internal" 
  --name=vcd01 
  --diskMode=thick 
  --prop:"vami.ip0.VMware_vCloud_Director"="X.X.X.X" 
  --prop:"vami.ip1.VMware_vCloud_Director"="X.X.X.X" 
  --prop:"vami.DNS.VMware_vCloud_Director"=" X.X.X.X " 
  --prop:"vami.domain.VMware_vCloud_Director"="local.cmentarnapolka.pl" 
  --prop:"vami.gateway.VMware_vCloud_Director"="X.X.X.X" 
  --prop:"vami.netmask0.VMware_vCloud_Director"="X.X.X.X" 
  --prop:"vami.netmask1.VMware_vCloud_Director"="X.X.X.X" 
  --prop:"vami.searchpath.VMware_vCloud_Director"="local.cmentarnapolka.pl" 
  --prop:"vcloudapp.enable_ssh.VMware_vCloud_Director"="True" 
  --prop:"vcloudapp.expire_root_password.VMware_vCloud_Director"="False" 
  --prop:"vcloudapp.nfs_mount.VMware_vCloud_Director"="X.X.X.X:/var/nfsshare" 
  --prop:"vcloudapp.ntp-server.VMware_vCloud_Director"="X.X.X.X" 
  --prop:"vcloudapp.varoot-password.VMware_vCloud_Director"="xxx" 
  --prop:"vcloudconf.db_pwd.VMware_vCloud_Director"="xxxx" 
  --prop:"vcloudconf.admin_email.VMware_vCloud_Director"="vcdadmin@cemntarnapolka.pl" 
  --prop:"vcloudconf.admin_fname.VMware_vCloud_Director"="Admin" 
  --prop:"vcloudconf.admin_pwd.VMware_vCloud_Director"="xxx" 
  --prop:"vcloudconf.admin_uname.VMware_vCloud_Director"="administrator" 
  --prop:"vcloudconf.inst_id.VMware_vCloud_Director"="1" 
  --prop:"vcloudconf.sys_name.VMware_vCloud_Director"="vcd01" 
  --prop:"vcloudnet.routes1.VMware_vCloud_Director"=" X.X.X.X X.X.X.0/24" 
  --deploymentOption="primary-large" 
  --powerOn "D:/Install/VMware_vCloud_Director-10.0.0.4471-14638910_OVF10.ova" 
vi://administrator@vsphere.local:xxx@X.X.X.X/?ip=X.X.X.X

Podczas wywoływania tego skryptu instalacja wykonywała się, ale nie było wciąż możliwe uzyskanie zmiany nazwy. Zanim producent podjął się działań, postanowiliśmy wziąć sprawy w swoje ręce i wykonać ręczną zmianę nazwy serwera poprzez komendę:

hostnamectl set-hostname nowa_nazwa_hosta

Następnie restart oraz zmiana w pliku /etc/hosts/:

vi /etc/hosts/

Chwilę po tym wykonano re-inicjalizację bazy danych:

/opt/vmware/vcloud-director/bin/configure 
  --unattended-installation 
  --database-type postgres --database-user vcloud 
  --database-password XXXXXXX 
  --database-host X.X.X.X 
  --database-port 5432 
  --database-name vcloud 
  --database-instance vcd01 
  --database-ssl true 
  --uuid 
  --keystore /opt/vmware/vcloud-director/certificates.ks 
  --keystore-password XXXXXXX 
  --primary-ip X.X.X.X 
  --console-proxy-ip X.X.X.X 
  --console-proxy-port-https 8443

Kolejnym krokiem było wykonanie zmiany w bazie danych, dokładnie w ustawieniach klastra. Na początku pobraliśmy pierwotną nazwę klastra, oraz jego ID:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/repmgr -f /opt/vmware/vpostgres/10/etc/repmgr.conf cluster
 show

Połączono się z PostgreSQL poprzez komendę:

sudo -i -u postgres /opt/vmware/vpostgres/10/bin/psql

Wylistowaliśmy wszystkie bazy danych:

l 

Połączyliśmy się do bazy danych odpowiedzialnej za Replication Manager:

c repmgr

… i wywołaliśmy zapytanie aby wyświetlić tabele:

SELECT * FROM pg_catalog.pg_tables;

Zaktualizowano pole z nową nazwą zgodnie z ID klastra pobranym wcześniej:

UPDATE repmgr.nodes SET node_name='nowa_nazwa' WHERE node_id=ID_KLASTRA;

Restarcik vCD Cell… i po ich ponownym uruchomieniu nazwa maszyny, jak i również węzła w klastrze ukazała nam się w swojej pełnej i poprawnej krasie. Po zainstalowaniu drugiego serwera vCD i wykonaniu powyższych operacji nastąpiło połączenie baz danych w klaster.  Jednak w tzw. międzyczasie odezwał się support VMware i wskazał, że zastosowany serwer DNS – Unbound na platformie PhotonOS nie jest wskazany :/ Zatem wykonaliśmy testy jeszcze raz przy zastosowaniu serwera DNS w oparciu o Windows 2016. Niestety sytuacja się nie zmieniła, dalej nazwa hosta, a co za tym idzie i klastra, pozostała niezmieniona.

Kolejna próba diagnostyki wymierzona została w serwer DNS (oparty o Windows 2016). Serwer ten był dostępny poprzez interfejsy eth0 vCD Cell. Naprowadziło nas to na rozwiązanie problemu.

VMware vCloud Cell ma dwa interfejsy sieciowe – eth0 (net-external) i eth1 (net-internal). Komunikacja podczas działania z DNS/NFS i np.RabbitMQ odbywa się po eth1, natomiast podczas instalacji okazuje  się, że wymagana jest również komunikacja z DNS na eth0. Dzieje się to dlatego, że podczas pierwszego uruchomienia VM z Cell vCD aktywowany jest jedynie interfejs eth0, odpytywany jest DNS (i to w naszym przypadku nie działało), a następnie odpalany jest eth1 i instalacja postępuje dalej, ale już nie ma nazwy DNS więc się nie udaje.

Zatem w przypadku tego problemu należy dokonać następujących zmian aby deploy się udał:

1. Otworzyć dostęp z sieci net-internal do serwerów DNS na porcie 53 dla protokołów UDP/TCP.
2. Zmienić serwery DNS oparte o Unbound na oprogramowanie Bind, lub uruchomić w oparciu o serwery MS Windows.

Ps. Znaleźliśmy również rozwiązanie dostępne TUTAJ.