VMware Cloud Foundation – Hol ad és hol korlátoz? – második rész – alaptelepítés

Az első részben ott fejeztük be, hogy már tudjuk legalább négy fizikai kiszolgálóra van szükség és ezeknek VSAN ready node-oknak vagy VXrail-nek kell lenniük. A négy node alkotja a management domain-t, egy klaszterbe szervezve. A követelményeknek megfelelően kész van a hét darab VLAN, be van állítva a magas MTU is.

Ha a Cloud Builder VM fut, akkor belőle – amúgy a My VMware-ről is – letölthető a bemeneti fájl, ami a management domain-t telepíti. Úgy kell ezt érteni, hogy a végeredmény egy vCenter Server lesz, ami a négy ESXi-t menedzseli, VSAN/HA/DRS enabled lesz és elérhető lesz benne a három darab NSX Manager is egy VIP – közös IP-vel. A Cloud Builder más nem csinál, nem is tud csinálni.

Nézzük meg a fájlt!

Négy tab-ja van:

  • Introduction
  • Credentials
  • Hosts and Networks
  • Deploy Parameters

A credentials szekcióban várja az ESXi root jelszavát – minden hosztnak azonos kell legyen – a vCenter SSO és root jelszavát, az NSX Manager root,admin és audit jelszavát és az SDDC Manager felhasználóinak jelszavát.

A Hosts and Networks már sokkal érdekesebb.

A bal felső táblázatban kell neki három darab VLAN, a kívánt port group nevek, a CIDR, a gateway és az MTU.

A jobb felső táblázatban az ezen a ponton már a beadott hosztnevek mentén elérhető négy ESXi kiszgolálót kell beadni, illetve azt, hogy a vMotion és VSAN hálózatokban az SDDC Manager-ben kialakításra kerülő IP pool-ok mennyi IP-vel és milyen tartományban gazdálkodhatnak. Ez nagyon lényeges rész, mert ha lesz egy ötödik, tizenhatodik ESXi a management domain-ben, akkor azok KÖTELEZŐEN ebben a management VLAN-ban, vMotion VLAN-ban és VSAN VLAN-ban kell legyenek. Nincs átcímzés meg subnet maszk módosítgatás – amúgy sem értem ilyet miért tenne bárki…..

A Virtual Networking tábla a legérdekesebb. Három lehetőséget ad, amelyek közül ha egyik sem jó, akkor JSON-t kell tekergetnünk és ezt a táblát el is lehet felejteni akkor.

A három opció:

  • Profile-1: két/négy NIC felhasználásával egy Distributed vSwitch lesz, amin a Management, a VSAN, a vMotion és az NSX overlay is megvalósul
  • Profile-2: két vDS lesz, két-két port felhasználásával, a második vDS-t csak a VSAN fogja használni, minden más marad az első vDS-en
  • Profile-3: két vDS lesz, két-két port felhasználásával, a második vDS-t csak a NSX overlay fogja használni

Ha itt nem állítjuk be a kívántat és feltelepült a VCF, akkor utólag nem szabad módosítani. Olyat sem szabad, hogy mondjuk az alaplapi 4 rezes portra felhúzunk egy vDS-t csak úgy. Erről a VCF nem fog tudni és ha bekerül egy ötödik ESXi a klaszterbe, akkor nyilván azt nem is fogja hozzá csatolni automatikusan. Nem támogatott, kész.

A Security Thumbprints résznél be lehetne adni a négy ESXi kiszolgáló SSL certjének fingerprint-jét és még a telepítés előtt validálná, hogy tényleg azokra telepítünk, amikre telepíteni akarunk.

Az “NSX-T Host Overlay Network” kimeleten fontos. Az egy dolog, hogy kell neki egy VLAN, de ha statikus címzést választunk, akkor ezt az IP pool-t is az SDDC Manager fogja kezelni. Az pedig kicsit buta, tehát ha stretched cluster-ré szeretnénk varázsolni a management domain-t később, akkor nem fogja tudni, hogy a másik telephelyen hogy kezelje a TEP IP-ket. Leginkább azért, mert az NSX nem is igényel azonos layer 2-t a TEP hálózat számára, elég ha 1600 byte-os MTU-val van köztük routing. A másik opció a DHCP, de akkor a rendszeren kívül kell DHCP-t megvalósítani. Fontos, hogy telepítés után a DHCP-s megoldásból lehet static IP pool-ost csinálni, de másik irányba nem!

Ismételjük meg még egyszer…..ha valaha szeretnénk stretched klaszterré tenni bármelyik workload domaint – a management az első lesz amit azzá kell tenni – azaz a VMware HA-ra bízni az automatikus átállást a másik telephelyre, akkor DHCP-kell a TEP interfészek esetén.

Mit nem lehet?

Olyat hogy a maradék NIC-eket egy másik /vSS/vDS-ben felhasználjuk Hogy bármit a telepítés után a hoszt oldali hálózatban állítgatunk. Nem akadályozza meg semmi, de megtöri az automatizációt.

Deploy Parameters tab

Bármi amit itt beállítunk – a licenszek, a klaszter és a management domain neve kivételével – kőbe lesz vésve. Ezeket nem szabad módosítani még akkor sem, ha amúgy simán átnevezhető egy resource pool.

A fenti az alapállapot, ami standard telepítést végez. A standard és a consolidated között annyi a különbség, hogy utóbbi resource pool-okat hoz létre.

Amint ez a fájl elkészült, akkor a Cloud Builder-be betölthető, ami szintaktikailag ellenőrzi és megkezdi a telepítést. A végeredmény általában 1,5-2 óra múlva a management domain maga. Annyit azért érdemes tudni, hogy a VMware valamilyen ismeretlen oknál fogva benne hagyott egy telepítést megakadályozó bugot, mégpedig, hogy a validáció során hibára fut. Erre van KB cikk, le kell tölteni egy jar fájlt és feljuttatni a Cloud Builder VM-re.