VMware Cloud Foundation 5.2/5.2.1.0 – Part 1

A csomagok kialakítása után a VMware Cloud Foundation maradt a legfelső polcán a gyártónak, nyilvánvalóan továbbra sem lesz túl ejterjedt. Ennek ellenére azért biztosan vannak olyan esetek, akkora rendszerek ahová ez kell és pontosan ez is illik oda. Korábban én is írtam a VMware Cloud Foundation-ről és akkor nem volt a kedvencem – most sem az – főleg azért mert túl sok kötöttséget jelent és ezáltal rengetek kompromisszumot kell meghozni a vele való tervezéskor és telepítéskor.

A VMware bejelentette a VMware Cloud Foundation 9-es változatát, amiről azonban lényegi részleteket igazából alig ismerni, ezért az éppen kurrens és nem mellesleg kapható verzióját nézem meg.

A VMware Cloud Foundation csomag természetesen core alapon licenszelhető, előfizetéses modellben. Az alábbi kép – William Lam-tól – szerintem többet mond ezer szónál, mivel könnyen áttekinthető a csomag tartalma. A sötétebb háttérrel rendelkező komponensek a csomagban alapértelmezetten és elválaszthatatlanul kötelezően vele járó részei, a sárgák a támogatást jelentik, a fehér háttér – a kép alsó része – pedig az opcionális elemeket mutatja.

Mag alapú, azaz az számít, hogy a fizikai szerverben hány foglalat és abban mennyi fizikai – HT nem számít – core van. Erről is írtam már korábban, de akkor a legfőbb szabály álljon itt is: foglalatonként legalább 16 magot kell vásárolni – akkor is ha 8 mag van a foglalatban!

A VCF sosem volt egyéb, mint egy sima VMware környezet – kötötten megépítve – az SDDC Manager tudásával vegyítve. Része volt a VMware NSX is, ami immáron csak részben van benne, ugyanis kikerültek a tűzfalazási képességek az alapcsomagból, csak opcionálisan lehet hozzá megvenni – borsos díjért.

A követelmények eddig is azonosak voltak, azaz legalább négy darab vSAN HCL-en szereplő node kell hozzá, mivel a rendszer alapja egy vSAN klaszter, ami továbbra is – legalább – a management cluster céljára kerül felhasználásra. Adott tehát egy BOM a szoftverekkel és igazából két médiát kell hozzá beszerezni:

  • a Cloud Builder-hez.
  • az ESXi-k alaptelepítéséhez.

Innentől kezve ha a szokásos táblázatot kitöltjük az IP-kkel, FQDN-ekkel és jelszavakkal, akkor a telepítés automatizáltan lemegy és a végeredménye egy SDDC Manager, egy vCenter, egy – három VM – NSX Manager telepítés lesz – legalább.

Dashboard

A nézetben sok minden használhatót nem mutat, szóval a hibakeresést nem biztos hogy pont itt kell kezdeni, de az SDDC Manager nem is erről szól. Sokkal inkább az egész rendszer kapacitásával, bizonyos funkcióival kapcsolatos és életciklussal összefüggő témákról. A fentieken látszik, hogy nulla „Solution” van telepítve, ami az alapesetben a „Kubernetes – Workload Management”-et jelenti. Mutatja továbbá, hogy 1 Workload Domain van, ami a management domain. Alatta a „Host Type and Usage” résznél, hogy mennyi ESXi hoszt van a rendszerben, azokból hány darab van már felhasználva valamelyik domain-ben és mennyi szabad még.

Mutatja továbbá nagy elnagyoltság mellett a CPU/RAM és diszk-felhasználást is, illetve a folyamatban lévő és már megtörtént frissítéseket is listázná, ahogyan az SDDC Manager-ben végrehajtott akcíókat is jegyi.

Hosts

Mielőtt egyetlen ESXi kiszolgálót is használni kezdenénk VCF-ben, előtte az SDDC Manager kezeibe kell adni azokat és pont arra van ez a „Hosts” menü. Alább látható, hogy a felső négy darab ESXi alkotja a vcf-m01 domain-t és felvettem még három olyan ESXi-t, ami még nincs egyetlen vCenter-hez sem adva, nem fut rajtuk semmi, csak és kizárólag az SDDC Manager gondjaira bíztam őket.

Felvenni őket egyébként végtelenül egyszerű, csak a Comission Hosts gombot kell megnyomni a jobb felső sarokban. Ekkor fel is dobja azt, hogy mi mindennek kell megfelelnie egy ilyen hosztnak, ami majdnem azonos mint mikor a management domain-hez keres valaki szervert. A különbség az, hogy nem kell feltétlen vSAN HCL-en szereplő kiszolgáló, hiszen a management domain-en kívül minden más használhat bármilyen tárolót, nem kötelező a vSAN.

Itt fenti részben csak be kell pipálni az összeset, mert különben nem enged tovább, ugyanakkor tényleg teljesíteni kell az összes feltételt. A megejelnő ablakban kell felvenni – vagy importálni – az ESXi-ket és megadni azt, hogy ezek akkor most vSAN-nal, NFS-el, normál VMFS (FC) vagy vVol tárolót használnak majd mint principal – elsődleges – tároló. Ez azért is lényeges, mert a Network Pool résznél olyat kell kiválasztani, ami akkor tartalmaz olyan hálózatot, amelyet például a vSAN használhat a vSAN vmkernel-ek számára. Abból a szempontból is fontos a network pool, mert itt választható el két domain már a VLAN-ok szintjén is.

Workload Domains

A lényeg….szóval egy biztosan van és lesz is. Az alábbi képen ezt hívják „vcf-m01”-nek, bár ezt azért át lehet nevezni. Ebből lehet több is és körülbelül nyolcféle rendezési elv is elképzelhető arra, hogy mikor kell valaminek egy új workload domain-be kerülnie. Ilyen lehet például az adott rendszer produktív,teszt mivolta, de akár az is hogy mi a DMZ és mi a belsőbb rendszer.

Rákattintva nyílik pár részlet is, de a lényegesebb az az SSO domain, a workload domain verziója és innen kattintva már léphetünk is az NSX felületére. Azonban sokkal fontosabb az a sok tab, amin a workload domain-nel kapcsolatos összes feladatot létre lehet hajtani.

A services-re kattintva szintén kiírja, hogy mi a workload domain vCenter Server-e és NSX Manager-e.

Az alábbi esetben van egy cluster is a workload domain-ben, amit szintén át lehet nevezni később, esetemben ezt „vcf-m01-cl01”-nek hívják. A „Hosts” tab-on pedig a benne szolgáló ESXi kiszolgálók láthatóak.

Amivel viszont tényleg elképesztően sok munkát spórol meg, az a certificate kezelés. Szóval nem termékeknént kell a adott módszer mentén legenerálgatni a CSR-t, majd importálni a chain-t és egyéb dolgokat végrehajtani, hanem erről az egyetlen felületről meg lehet tenni az egészet.

A többi részletet a sorozat további részeiben majd kifejtem, például az „Updates” és az „Edge Clusters”.

Új workload domain létrehozása

Azzal a három, jelenleg csak comissioned státuszban lévő ESXi kiszolgálóból hozzunk létre egy új workload domain-t és benne egy vSphere klasztert.

Következő lépésben megkérdezi, hogy milyen principal storage lesz a workload domain-ben. Négy – igazából öt – lehetőség van:

  • vSAN OSA
  • vSAN ESA
  • NFS
  • VMFS on FC
  • vVol

iSCSI tehát még mindig nem használható elsődleges tárolóként. Esetemben a vSAN-t választom. Ezen a ponton ha kiválasztok valamit, akkor csak olyan comissioned ESXi-ket mutat majd, amelyeket a hozzáadáskor szintén azonos módon jelöltük.

Meg kell adni a workload domain nevét és egy organizációt is. Illetve a kiemelten fontos kérdést is meg kell válaszolni, azaz hogy már egy meglévő SSO domain-be vagy egy újat létrehozva kívánjuk kialakítani a kért workload domain-t. Szóval nyilvánvalóan az is lehetséges, hogy a management domain, SSO domain-jébe join-olom be.

Bekéri a klaszter nevét és hogy image alapon szeretnénk-e őket a jövőben kezelni.

Bekéri a vCenter FQDN-jét és látható módon az IP-t és egyéb vele kapcsolatos részleteket nem is kérdez. A DNS-ből lekérdezi az FQDN-hez tartozó IP-t, a másik két adatot pedig a már a management domain telepítésekor bevéstük a rendszerbe. Tehát ez a vCenter is ott lesz, ahol a többi.

És akkor itt az első meglepetés! Nem kényszerít már az NSX használatára, hanem maradhatunk nélküle is. Amennyiben NSX-et választ valaki, akkor értelemszerűen – és itt még – bekéri az NSX Manager-ek telepítéséhez szükséges IP részleteket, appliance méreteket.

Mivel én vSAN-t választottam így megkérdezi, hogy milyen FTT szeretnék és hogy akarok-e DECO-t.

Ki kell választani, hogy akkor pontosan melyek azok a hosztok, amelyeket ebbe a klaszterbe és ebbe a workload domain-be akarok tenni.

A következő pedig megint egy megváltoztatott lépés. mert mivel vSAN-t választottam, így lényeges az, hogy a vSAN,vMotion,Management és a VM-ek forgalma milyen és mely interfészeken osztozik.

Az opciók itt láthatóak:

  • default: na ide két NIC is elegendő, minden azon a két NIC-en megy majd keresztül
  • Storage Traffic Separation: a vSAN saját vDS-t és két uplink-et kap.
  • Custom: itt pedig bármit össze lehet rakni.

Aztán végső lépésben bekéri a licenszeket vagy éppen kiválasztható, hogy települjön eval-ba.

El is indul a kívánt folyamat és feltelepítve kapunk egy vCenter-t – egy új workload domain-ben – benne egy klasztert, három ESXi-vel – NSX nélkül.

És való igaz! A management domain-ben el is kezd telepítődni az általunk kért vCenter Server appliance.

Innen folytatjuk!