VMware Cloud Foundation 4 – második bejegyzés – telepítés

(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.