A VMware egyik legkomolyabb termékéről van szó, ami az átlagnál – hazai átlagnál picit – nagyobb vagy szabványosításra hajlandó vállalatok számára egy opció lehet. Nem állítom, hogy nélküle, az általa kezelt folyamatok és széleskörü rendszerszintű beállítások megvalósítása nem lehetséges, de azt állítom, hogy azt megtenni humán erőforrásban – órák százaiban – és egyéb termékek beszerzésében mérhető.
A VMware Cloud Foundation egy bundle, amiben egyetlen egyedi szoftver van. Minden más a VMware adatközponti portfóliójából származik és sokan alkalmazzák már őket.
Balra a Tanzuval megbolondított opciók, jobbra a Tanzu gyomlált kiadások vannak. Mint látható a közös elemek minden esetben – termék szinten – azonosak és ezek:
- vSphere – vCenter és ESXi
- VSAN
- NSX
- SDDC Manager
Utóbbiban koncentrálódik a VMware Cloud Foundation – továbbiakban VCF – tudása. Minden, amivel megkönnyíteni tudja az üzemeltetés életét, karbantartás/bővítés/új elemek beillesztése – azt ez a termék végzi. A VCF kialakítása erős és nem áthágható szabályokat betartását igényli. Ebben a sorozatban, ezeket fogom ismertetni és összehasonlítom, hogy adott komponensnél milyen más opciók lehetnének – nem termékre értve, hanem design szempontjából és hogy az úgy miért lenne jobb vagy rosszabb.
Hardver kiválasztása
Nem VCF esetén kis túlzással bármi használható, ami a vSphere HCL – komatibilitási lista – szerepel az adott verzió mellett. VCF esetében a kérdés két részre bontható, mivel magának a VCF-nek is két fő része van.
- Management domain
- Workload domain(ek)
Egy speciális esetben, amit consolidated architecture-nek neveznek, a kettő egy és ugyanaz, de ettől tekintsünk el, nagyon erősen korlátoz a későbbiekben. Tehát a management domain mindenképp kell és egy VCF telepítésben egy és csakis egy lehet. Utóbbiból pedig egy vagy egy telepítésben maximálisan 14 darab. A „domain” maga egy SDDC construct, ezt sehol máshol nem látjuk mint az SDDC Manager-ben. A domain-ekben egy vagy több vSphere klaszter lehet.
Máris világossá válik, hogy elég magasra skálázható már egy telepítés is, ráadásul több telepítést bizonyos módon lehet federálni is.
Management domain
A hardver fajtája a management domain esetén a legkorlátozottabb. Mindenképpen képes kell lennie a VSAN futtatására – tehát VSAN ready node vagy DellEMC VXrail kell legyen. Nincs kibúvó, kötelező a VSAN használata a management domainben. A kiszolgálók száma is kötelező minimumot ír elő, négy darabot.
Miért VSAN?
A management rendszerek futtatása független kell legyen a menedzselt rendszerek állapotától – bár ezt bármilyen ügyfél nem VCF-es rendszerében is javasolni szoktam. Tehát mondjuk a vCenter, a monitoring, az adminisztrátori RDS farm ne ott fusson amit monitoroz vagy segítségével üzemeltetnek, hiszen legrosszabb esetben nem lehet egyszerűen megjavítani, ha a mód ahogy meg kell javítani is elérhetetlen. Emiatt került bele a VSAN, ami egy csapásra függetleníti SAN-tól, központi tárolóktól az egészet.
Ettől eltekintve, ezzel a tétellel biztosított, hogy a számítási és tárolási réteg is támogatott és egymással az elérhető legmagasabb mértékben kompatibilis legyen.
A management domain méretezését követően illik kiválasztani azt a legalább négy hosztot, ami azt ki fogja szolgálni.
Milyen virtuális gépek futnak majd itt?
Attól függ, hány workload domain lesz és milyen izolációt kívánunk megvalósítani vagy éppen elkerülni azok között.
Alapértelmezetten itt fut az:
- SDDC Manager
- 3 x NSX Controller/Manager (a management domain számára)
- 1 x vCenter Server (a management domain számára)
- (opcionális) 2 x NSX Edge VM (a management domain számára)
- vCLS gépek – amik a HA/DRS kiszervezett funkciói miatt vannak – bár ezek szükséglete lényegében nulla
A VCF kiadásától függően még futhat itt:
- vRealize Lifecycle Manager
- vRealize Operations Manager (egy vagy több)
- vRealize Log Insight (egy vagy több)
- Workspace One Access (egy vagy több)
- Site Recovery Manager
- vSphere Replication
Minden fenti méretezése függ ermészetesen az elérni kívánt maximális kiépítettségétő, de a fenti öt alapértelmezett komponens legalább cirka 30 vCPU, 108GB RAM és 2200 GB igénnyel bír. Erre jön még rá a workload domain-enként egy vCenter Server, 3 x NSX Manager (erről később lesz szó, mert nem feltétlen kell majd).
Minden egyes workload domain erre legalább 1 x vCenter Server (medium), 3 x NSX Manager/Controller-el (large) emeli a szükséges kapacitást. Szóval 1 x 8vCPU, 28 GB RAM és 700 GB tárkapacitás, illetve 3 x 12 vCPU, 48 GB RAM és 300 GB tárkapacitással. Ez azt jelenti, hogy egy workload domain összesen 44 vCPU, 172 GB RAM és 1600 GB igényt generál(hat).
Ezért már a tervezési fázisban fontos a kívánt maximális méret felderítése vagy később szükségessé válhat vagy már meglévő négy hoszt bővítése vagy újabb hosztok bevonása a management domainbe.
Miért minimum négy hoszt?
Tudom, három is elég lenne, mivel annyi kell egy normális VSAN klaszterhez – hagyjuk a 2 node-osat. Ebben FTT=1 elérhető RAID1 mellett. Ha egy hoszt kiesik, akkor a redundancia veszik maximum el, de második hibát sosem bír lekezelni. A negyedik hoszt pont ezért van itt, méghozzá, hogy ha karbantartás van és egy hoszt emiatt üzemen kívül van, akkor közben legyen redundancia is. Vagy ha például megborul egy hoszt, akkor van hely az redundancia újraépítésére és akkor egy újabb kiesést is tolerálni lesz képes.
Workload domain
Ha a gyártót kérdezitek, akkor ide is csak VSAN-t kell tenni, ha engem akkor VSAN-t vagy akármilyen tárolót. Itt szabadabb az ember keze, tehát lehet VSAN,NFS,VMFS on FC, VVol on iSCSI, VVol on NFS, VVol on iSCSI – keressen meg aki VVol-ozik 🙂
A workload domain az, amiért a VCF épült, azaz itt történik az alkalmazások futtatása. Egyetlen feladata ez, nincs benne semmi mellékes sallang, minden erőforrása a nem management célú virtuális gépek – és konténerek – futtatása. Ez annyiban nem igaz, hogy az NSX Edge VM-ek is itt futnak.
Közös igények
Hardverrel kapcsolatos igények:
- Minden kiszolgáló szerepeljen a VMware HCL-ben. (Management domain esetén még a VSAN-oson is).
- Magától értetődik, hogy amennyire lehetséges, azonos modellekből/kiépítésű modellekből épüljenek a klaszterek. EVC-re van mód és illik is használni, a későbbi frissítések megkönnyítése érdekében.
- Legalább kettő hálózati interfész redundáns elérhetősége .(Erről egy külön részt fogok írni).
Egyéb konfigurációval kapcsolatos igények:
- Egyetlen egy fizikai NIC van beállítva a Standard Switch-en minden hoszton.
- Hibáktól mentes állapot.
- A VCF verziójával érkező build telepítettsége vSphere ESXi tekintetében a hosztokon.
- Az alapértelmezett „VM Network” és a „Management network” esetén is ugyanaz a tag-elt hálózat.
- SSH engedélyezett és fut – együtt indul a hoszttal.
- NTP fel van konfigurálva, időforrás elérhető – együtt indul a hosszttal.
- Minden hoszt be van jegyezve a DNS-be, forward és reverse zónába.
- Minden hoszton be van állítva azok neve és az FQDN is. Self signed cert újra is van generálva, hogy ezt tükrözze.
Hálózati igények
Itt vannak a legkomolyabb igények. A management domain számára szükséges több VLAN, magasabb MTU és routing is. Fontos kiemelni, hogy az NSX instancia (3 x NSX Manager és a hosztokon az NSX VIB-ek, TEP interfészek telepítése) a management domain számára mindenképpen megtörténik, ha akarjuk használni, ha nem.
Összegezve:
- Semmiféle LAG/VPC/LACP nem megengedett)
- IP-címek, subnet mask-ok és gateway-ek minden VLAN estén.
- Javasolt a 9000 byte-os MTU minden VLAN-ban, de ha máshol nem akkor legalább az overlay VLAN-ban az 1600 byte követelmény.
- A Managment, a vMotion, a vSAN és NSX host overlay VLAN-ok tag-elve legyen a trunk-ben. Én ide venném még az uplink VLAN-okat is, mert az is kellhet és kell is majd.
- Felkonfigurált és elérhető management vmkernel minden hoszton. (vMotion és vSAN számára a vmkernel-eket majd a folyamat hozza létre).
- DHCP javasolt a host overlay számára, bár lehet statikus, SDDC Manager-ben is deiniált pool, de akkor később ha több telephelyesítenénk a management domaint, majd probléma lesz).
A követelmények olvasása után tapasztalhatóak a korlátok is, mivel nincs és nem is lesz LACP – én személy szerint is ellenzem ezek használatát. Minden szolgáltatás számára kell egy saját VLAN, tehát nem lesz itt vMotion engedélyezve a management VMkernel-en vagy bármilyen más kombináció. Szintén nem szoktunk nem VCF esetén például a vMotion hálózatba gw-t tenni, mert ha minden hoszt ilyen interfésze egy L2-ben van, akkor kb minek kellene ugye. Na itt kell. Ami viszont nagyon fáj, az az hogy a hosztok TEP interfészei – több lesz – és az opcionális Edge VM-ek TEP interfészei külön VLAN-ban kell legyenek és ezeket egymás között route-olni kell.
Ez az utóbbi volt azt hiszem az NSX nem oly régi nagy újítása, hogy ha az Edge VM olyan hoszton fut, ami rendelkezik TEP interfésszel, akkor is lehet az Edge TEP és a Host TEP is azonos VLAN-ban. Most nyilván arra gondoltok, hogy ennek hiánya nekem miért fáj. Azért, mert ha például egy T1-et reprezentálunk egy Edge VM-ben, akkor bizony a forgalma – ami nem szegmensen belüli – megjárja az host-Edge VM-host útvonalat, ha kell ha nem – hairpin. Igaz ez az észak déli forgalomra is.
Tehát ha az host TEP és az Edge TEP nem lehet azonos VLAN, akkor közöttünk külső routing kell, ami már azt jelenti, hogy az ESXi hosztot elhagyja a forgalom és könnyen lehet kimenő és bejövő irányban is azonos fizikai interfészt jár meg, ráadásul bekerül még egy – két – hop a kommunikációba. Tehát ha a gateway az Edge és host TEP VLAN-ok esetén nem a TOR-on vagy az első switch-en van a host irányából, akkor még innen is pöröghet tovább a forgalom.
Na pont ezt oldotta meg az NSX-ben az az újítás, hogy lehet azonos VLAN-ban a két dolog, így routing helyett, switching van. De a VCF ezt nem engedi meg. Tehát ha nincs VCF, akkor mindig egy VLAN-ban javaslom és implementálom a host és Edge TEP-ek elhelyezését.
A telepítés kezdete
A VMware Cloud Foundation telepítése a Management Domain telepítésével kezdődik, ez az úgynevezett bringup folyamat. Ehhez szükség van egy Cloud Builder nevű virtuális gépre. Ebbe kerül betöltésre egy fájl, ami a management domain építése során a szkriptek bemenetét képzi. Ebbe a fájlba kell a hosztok nevétől kezdve a management vmkernel IP-ken át a VSAN VLAN ID, licenszek és jelszavak hosszú sorát megadni. Ezt a Cloud Builder szintakszis szintjén ellenőrzi, majd komolyabban validálja is. Ha a validáció sikeres, akkor indítható a Management Domain telepítése, ami durván egy óra. Ezen a ponton még nincs workload domain, sem NSX Edge. Ez a pont egy ideiglenes állapot viszont mindent ami innen következik, azt már az SDDC Manager-ből kell végrehajtanunk.
Erről is lesz szó a későbbiekben!
