(az alább látható képek egy része laborban készült, nem egy ügyfélnél végrehajtott telepítés során. Ennek biztonsági és bizalmassági okai vannak. A magyarázathoz a labor forrású képek is megfelelőek. Eddig senki sem támogatott meg hét darab fizikai szerverrel, hogy saját adatközpontban építhessek VCF-et.)
Az előző részben ott fejeztem be, hogy elindítottam a telepítést megelőző ellenőrzéseket. Annak során a Cloud Builder VM megpróbája ellenőrizni az XLS – vagy JSON – formában beadott adatok alapján, hogy a telepítés elkezdhető, ugyanakkor nem győződik – nem is tud – meg arról, hogy sikeres is lesz.
Nem csinál mást mint:
- ellenőrzi a DNS-ben a szükséges A és PTR rekordokat.
- az management domain-be bevonni kívánt ESXi kiszolgálók elérhetőségét és a megadott root/jelszó párosát.
- hogy egy és csak egy vSwitch van, egy vmnic-el.
- a kulcsok helyesek.
- a jelszavak komplexitása megfelelő.
- a megadott hálózatok átjárói pingelhetők.
- az NTP elérhető
- a VSAN-ba bevonni kívánt SSD/HDD-k üresek.
Utóbbi igen fontos, mivel nem lehet megadni pontosan melyiket használja fel VSAN-ra, tehát mindet fel fogja használni. Minden VSAN telepítésben fontos, hogy tökéletesen tisztára törölt meghajtókkal operáljunk. Ha ez nincs így, akkor el sem indul a telepítés.
Ennek ellenőzrésére nyugodtan használható a „vdq -q” parancs. Ha valamelyik médián van partíció, akkor azt az eszközt nem használhatóként írja ki.
Az ilyet törölni kell vagy a Host UI-ról, vagy partedUtil-al.
Másik probléma az is lehet, hogy egy HDD, SSD-nek vagy egy SSD, HDD-nek hazudja magát. Ezeket lehet javítani, egész egyszerűen át kell váltani a SATP claim rule-t és másképp jelölni a médiát. (Tapasztaltam olyat már, hogy 24 darab teljesen egyforma HDD-ből egyetlen egy, SSD-nek képzelte magát 😀 ) Mivel a telepítés elején még nincs vCenter, ezért onnan a „Mark as HDD”-t nem lehet megtenni, a Host UI-n pedig nincs ilyen. Parancssorból kell tehát megtenni.
A „vdq -q” fentebb írja azt hogy „IsSSD” vagy sem. Ha az egy lemeznél tévesen írja, de az „esxcli storage core device list – d mpx.vmhba2:C0:T0:L0” is bővebben infót ad tóla.
A következő parancsal le kell venni az SATP rule-t róla, majd újra hozzárendelni de HDD/SSD-ként.
esxcli storage nmp satp rule remove -s VMW_SATP_LOCAL –device mpx.vmhba2:C0:T0:L0
esxcli storage nmp satp rule add -s VMW_SATP_LOCAL –device mpx.vmhba2:C0:T0:L0 –option „enable_hdd” – vagy „enable_ssd”
Ezek után javaslom újraindítani az adott hosztot és már a beállított médiát látja majd azon a lemezen. VMware KB: https://kb.vmware.com/s/article/2013188
Ha minden teszt sikeresen lefutott, azaz nincs „Failed” csak „Warning” legrosszabb esetben, akkor ténylegesen elkezdődhet a telepítés. Az iparági pletykák alapján az ötödik telepítés lesze sikeres, de amennyiben a felkészülés becsületes volt, akkor biztosan sikeres telepítés lesz a végeredmény. Az előző cikkben már leírtam, pontosan mik az igények.
Nagyon sok lépést hajt végre:
- Létrehoz egy VSAN datastore-et – bootstrap – amire felteszi a VCSA-t.
- Létrehozza a datecenter-t, klaszter-t a vCenter-ben, majd hozzáadja a többi hosztot.
- VDS-eket hoz létre, amikhez hozzárendeli a hosztokat.
- VSAN-t állít be, ezúttal már a négy hosztra működően.
- vMotion interfészeket konfigurál.
- Migrálja a Standard Switch-ről a vmkernel-t a vDS-re.
- SDDC Manager-t telepít.
- NSX Manager-eket telepít.
- Felkonfigurálja a hosztokat egy overlay transport zónába, két IP-vel hosztonként mint TEP. Ezeket egyénként egy szintén vDS-re teszi – viszont látásra NVDS.
- Ha van AVN, akkor Edge VM-eket is telepít, majd T0/T1-et állít be. (opcionális).
- személyes kedvencem, hogy a vCenter UI-ján belépéskor figyelmeztet, hogy SDDC manager által van kezelve 😀
Ez utóbbit egyébként nagyon komolyan kell venni, tehát nincs vCSA frissítés magán a vCenter VAMI-n, nem szabad csak úgy vDS-eket, vmkernel portokat létrehozogatni. Az SDDC Manager egy frissítés során ha ilyen inkonzisztenciát észlel, akkor nem engedi meg az automatizált frissítést. Bővíteni sem lehet majd egy új hossztal például a management domain-t – később pedig a workload domaint sen.
A sikeres telepítés végén az SDDC Manager-re vezet.
A sárga jelzi, hogy az NSX mentése az SDDC Manager appliance-ra van irányítva, de javasolt külső területre tenni – csak SFTP támogatott – mivel mind az SDDC Manager, mind a három NSX Manager is azonosan a VSAN-on van, tehát egy fészekben van minden tojás.
Ebben a fázisban a management domain van kész, a Cloud Builder a feladatát ellátta, tehát a továbbiakban nincs rá szükség, maximum akkor ha egy újabb VCF-et szeretnénk telepíteni vagy például a VIA-n keresztül nagy számban és automatizáltan ESXi-t telepíteni.
Vegyük észre, hogy a telepítés előtt kitöltött XLS-ben megadott adatok alapján állított be mindent, így például a management domain neve is ismerős lehet.
Ha megnézzük a management domain vCenter Server-ét, akkor a datacenter neve, a klaszter neve, a resource pool-ok – mivel DRS van, a vDS(ek) neve(i), akár a vSAN datastore neve mind azok, amiket mi adtunk meg.
A vDS – ebben a példában csak egy van – és a port group-ok szintén ismerősek lehetnek.
Innen jön egyébként a hét VLAN követelmény, mert fentebb látszik – két VLAN az EDGE uplink miatt az SDDC-VDS01-edge PG-be és az overlay TEP-ek, management – amiben a hosztok management vmkernel portja, az SDDC Manager, a vCenter Server és az NSX Manager-ek és az Edge VM-ek management portjai is vannak – az SDDC-VDS01-mgmt esetén, a vMotion vmkernel-ek az SDDC-VDS01-vmotion PG-ben és a VSAN vmkernel-ek az SDDC-VDS01-vsan PG-ben.
Az NSX Manager-ben megnézve multi TEP-et telepít, minden hoszt két TEP IP-vel rendelkezik és ez az ötödik kért VLAN.
Szóval faltól falig mindent beállított, létre lehet hozni az első workload domain-t és/vagy VM-eket telepíteni a management domain-be, legyenek azok ténylegesen menedzsment célú vagy végfelhasználói produktív rendszer – utóbbi eset a konszolidált telepítés.
A management domain-ben mit látszik akkor is van NSX – három manager – és a hosztok rendelkeznek TEP interfészekkel, mikor az AVN-t nem akarjuk, azaz NSX-et jelen domain-ben egyáltalán nem akarunk használni, ugyanakkor semmi sem akadályoz meg abban, hogy elkezdjük használni itt is később – előrelátó a VMware ebben.
Csak annyit kell tenni, hogy telepítünk egy Edge Cluster-t.
Ennek semmi meglepő igénye nincs, ami eddig ne lett volna világos.
Ismerős adatokat vár tőlünk, Edge Cluster neve, MTU, ASN, T0 és T1 nevek, jelszavak.
A második lapon el kell dönteni, hogy mire akarjuk használni az Edge Cluster-t. A „workload management” az lényegében a Kubernetes on vSphere-t jeletni, a Custom pedig minden mást, pont azt ami nekünk kell. Méretezni kell az Edge VM-et, kiválasztani hogy Active/standby lesz a T0 vagy AA – ECMP. Az útválasztásnál pedig, hogy statikusan szeretnénk vagy BGP-vel megvalósítani.
Ezeknek megelelően kér be mindent a következő ablakban:
- Edge Node FQDN
- Management IP
- Management átjáró
- TEP1 IP
- TEP2 IP
- TEP átrjáró
- Edge TEP VLAN
- L2 uniform vagy L3 – ezt a választást nem is értem, mert a követelményeknél megköveteli hogy L2 uniforml legyen – teljesen értelmetlen ez a választási lehetőség.
- Uplink VLAN-ok – két uplink lesz
- Uplink IP
- A peer ASN-je, jelszava, IP-je
Ha minden kész, akkor deploy-ol két darab Edge VM-et a kiválasztott méretben és felkofigurálja NSX-ben a kívánt módon. Innentől kezdve elkészíthetkük a szükséges szegmenseket és/vagy LB/NAT szabályokat, tűzfalazhatunk azon gépek számára, amelyeket az AVN-be be kívánunk vonni.
A következő részben innen folytatom workload domain létrehozással és az életciklus menedzsmenttel.
