Az előző részben addig jutottam el, hogy feltelepült a management domain és egy workload domain is. A management domain által használt SSO domain-be, csatlakoztatásra kerül a workload domain is – nem kötelező – így emiatt egyetlen vCenter ablakból látszik a másik is.
Idáig eljutni a varázslók használata miatt nem igényel sok időt, ugyanakkor feltételezi azt, hogy az ESXi-k alaptelepítése, a kábelezés, a hálózati eszközök konfigurációja, a DNS bejegyzések, az NTP, mind-mind tökéletesen el lett végezve. Ellenkező esetben már az alaptelepítés sem megy le rendesen és szó szerint napokat lehet elégetni a hibakereséssel.
Az SDDC Manager oldaláról az egész rendszer így néz ki.
Maradjunk is itt és konfiguráljuk fel az SDDC Manager-t rendesen.
SDDC Manager authenikáció
Feltűnő lehet, hogy az SDDC manager megnyitásakor a böngésző sávjában redirect-el a management domain vCenter Server-ére és tulajdonképpen ott történik az authentikáció és végső soron az SSO adminnal lépünk be az SDDC Manager felületére. Ezt bizonyítja a fenti képen, a jobb felső sarok is, látható az administrator@vsphere.local. Nyilvánvalóan jobb lenne valamilyen IdP, ahonnan nem ilyen generic felhasználókkal léphetnek be az adminisztrátorok.
A Single Sign On menü segít ebben, azaz lehetőséget ad external (Microsoft ADFS, OKTA és Entra ID) és embedded provider (AD over LDAP és OpenLDAP) használatára.
A rendszerben én az AD over LDAP-ot választom és megadom a bind user-t. Éles rendszerben LDAPS-ot használjatok én a laborban megelégszem az LDAP-pal.
Sikeres beállítás után azonnal lehet is jogot adni felhasználónak/csoportnak is a domain-ből. A háttérben amúgy a management domain vCenter-ét konfigurálja fel és oda veszi fel a fentebb megadott adatok mentén az IdP-t.
Adjunk is jogot a DEMO\VCF_Admins AD csoportnak, méghozzá ADMIN role-t az SDDC Manager-ben.
Lépjünk be hát egy felhasználóval, aki tagja a VCF-Admins csoportnak. Az SDDC Manager be is enged – igazából a vCenter enged be – és validálhatjuk is a jobb felső sarokban azt.
Az SDDC Manager és vCenter-be így automatikusan fel lett konfigurálva az AD, mint authentikációs forrás, de miért nem képes arra a rendszer, hogy az NSX-eket is beállítsa hasonló módon? Azoknál nem csinál semmit a varázsló és így lehet manuálisan ott is felvenni az AD-t. Alább látszik, hogy tényleg nem csinált semmit.
Depot settings / Proxy Settings
A VMware Cloud Foundation életciklusa nyilván rendszeres frissítést is igényel, amihez pedig a csomagot alkotó komponensekhez szükséges frissítések kellenek. Ezt az SDDC Manager képes egyenesen az internetről közvetlenül – vagy proxy szerveren keresztül – vagy ha air gapped a telepítés, akkor közvetett módon valamilyen általunk szolgáltatott webszerver segítségével letölteni. Utóbbinál a jól ismert Offline Bundle Transfer Utility használandó, ami a webszerverre szükséges állományokat le tudja tölteni a Broadcom oldaláról. (Részletes beállítása itt található: https://blogs.vmware.com/cloud-foundation/2024/07/24/vmware-cloud-foundation-offline-depot-introduction/)
Ha viszont egyenesen az internetről szeretnénk beszereztetni a szükségeseket, akkor a proxy esetén adott a http/https proxy – auth van – vagy ha proxy nélkül mehet, akkor elegendő a megfelelő user beadása a Broadcom portálhoz.
Backup
Az SDDC Manager és a letelepített NSX instanciák mentését alapesetben magára az SDDC Manager-en lévő célra menti a rendszer, ami persze teljesen rossz, mivel önmagára ment az SDDC Manager. Szükséges tehát valamilyen külső cél használata, ami mindenképpen csak SFTP lehet.
Itt azt a véleményem, hogy nagyon nehéz lenne azt szkriptelnie a VMware-nek, hogy a vCenter instanciák is oda mentsenek és ne kézzel kelljen őket beállítgatni? Itt tehát pont fordítva van, mint az authentikációs forrásnál, mivel ott az NSX-et nem bírja konfigurálni, itt meg a vCenter-t nem tudja.
Ha a beállítás megvan, akkor ütemezhető automatikus mentés is ütemezetten és – az NSX-hez hasonlóan – változás esetére is.
Nagyon fontos tehát a vCenter(ek) mentéseinek kézzel történő beállítása, mivel az SDDC Manager nem teszi azt meg helyettünk.
Security
Amiben mindenképpen nagy segítség az SDDC Manager az a jelszavak és a certificate-ek kezelése. Pontosan ez a kettő menü elérhető a szekció alatt és magukért beszélnek. Egy nagyobb rendszerben nagy munka a rengeteg built-in felhasználó jelszavainak megváltoztatása és időszakos rotációja. Nem kevés ilyen felhasználó van, vCenter-enként ott az SSO admin, a root, NSX-enként ott van az admin, az auditor és a root csak hogy párat említsek. Az SDDC Manager, ezek változtatását kényszeríti ki és majdnem minden esetben automatikusan is képes rotálni azokat – manuálisan pedig minden esetben.
Lényeg a lényeg, hogy az ESXi-k root felhasználóit nem tudja automatikusan és ütemezetten rotálni, de manuálisan, az SDDC Managerből kivitelezhető. (Forrás:https://docs.vmware.com/en/VMware-Cloud-Foundation/5.2/com.vmware.vcf.vxrail.doc/GUID-28D29FFA-2D81-4781-AD79-85697497D45B.html)
A certificate-ek kezelése hasonlóan körülményes, ha ennyi rendszeren manuálisan kell signing request-tet generálni, aláíratni majd beadni az aláírt tanúsítványt a komponensnek. Ennek automatizációja tényleg napokat spórolhat évente/kétévente.
Az SDDC Manager-nek tehát tudnia kell azt, hogy hol érhető el a certificate authority (CA) és milyen template-ből kell kérni a cert-et. Ahhoz a template-hez szüksége lesz autoenroll jogra, annak a felhasználónak, amit szintén be kell adni neki.
Lifecycle Manager
Bármilyen módon megoldottuk a depot elérését, akkor az SDDC Manager képes lesz értesülni az újabb VMware Cloud Foundation verziókról, azok BOM-járól, release node-jairól és ténylegesen behúzni a fissítéshez szükséges image-eket.
A Release Versions alatt egy full read only felület elérhető, amin az látszik, hogy 5.2.0.0 verzión van maga a telepítés, látszik az a két workload domain, amiben ez a verzió van. Látszik továbbá, hogy elérhető már egy 5.2.1.0 verzió is.
Az 5.2.1.0 verzió kritikus hibákat javít a bal oldalon piros jelölésben és a jobb oldalon látszik, hogy milyen új build-eket használ majd.
Viszont a frissítés első lépése az SDDC Manager frissítése. Ezt kell megtenni az SDDC Manager szekcióban, szóval le kell tölteni a pár GB-os csomagot és frissíteni az appliance-t.
Maga a frissítés egészen jól követhető, nem csak vakon történik.
Ha lefrissült az SDDC Manager, akkor le kell tölteni azon csomagokat is, amelyek a VCF-et alkotjó elemeket frissítik, így a:
- vCenter Server frissítését
- az NSX frissítését
- az ESXi-k frissítését
Amint ez megtörtént, akkor a folyamatot meg is mutatja, ha mondjuk a mangement domain-en kiválasztjuk az update tab-ot.
Összefoglaló
Az életciklussal kapcsolatos feladatok egy részét simán képes ellátni az SDDC Manager és a belé épített automatizáció, különösképp a frissítési feladatokat. Persze van még mit csiszolni rajta, de ha valaki egyszer tényleg adja a fejét, hogy megvásárolja és fel is telepíti azt egy VCF-be – azaz nem csak a komponenseket használja önmagukban és az SDDC Manager nélkül – akkor tud adni pluszt, főleg nagyobb rendszerek esetén – ami véleményem szerint úgy 20 ESXi hoszt környékén kezdődik.
