A vForum Budapest 2019 rendezvényen én a VMware Cloud Foundation-ről, NSX-T-ről és AppDefense-el átfűzött megoldásról adtam elő. Korábban volt már egy podcast és egy bejegyzés is itt nálam a VCF-ről, de azt kell mondjam, hogy a 3.9 megjelentésével egy új lendületet kaphat a termék és legalább egy-két ilyen implementáció lesz Magyarországon.
VMware Cloud Foundation
Ez nem egy termék, illetve nem egyetlen termék, hanem több komponens összessége és meghatározott módon történő felhasználása. A gyártó immáron a 3.9-es verziónál tart és véleményem szerint egy óriási előrelépés mindenképpen tetten érhető ebben a verzióban. Ki is térek rá annál a résznél majd, amire ez vonatkozik.
Alább látható minden termék amire épül és épülhet egy VCF telepítés. Vannak elengedhetetlen rétegek és vannak teljesen opcionálisak is.
Kötelező elemek:
- vSphere – vCenter + ESXi – mint compute virtualizáció
- SDDC Manager – a VCF és a workload domain-ek mindenféle menedzsmentjére
- vRealize Suite Lifecycle Manager – a vRealize komponensek day 0 és 2 kezelésére
- VSAN – a management domain-ben kötelezően kell használni, a workload domain-ekben opcionális.
- vRealize Log Insight – egységes log management
- NSX-T/NSX-V. A management domain-ben csak NSX-V lehet – egyelőre – a workload domain-ekben pedig NSX-T.
Opcionális elemek:
- vRealize Operations
- vRealize Automation
- Horizon
- PKS
Hogy épül ez fel?
Mikor VCF-ről beszélek egy ügyféllel, általában kihangsúlyozom, hogy lényegében a kötelező komponensek 70%-át már használja. Miért nem teszi ezt úgy, hogy azt egy VCF konform módon és annak keretében alakítja ki?
Remélem mindenki ismeri a VVD-ket – VMware Validated Design – amelyek minden tervezés alapjául kell szolgáljanak. Nagyon jól előkészítik a döntési pontokat és erős támaszt adnak a VMware termékek együttes kialakításának legjobb módjának megtalálásában. A VCF is erre a VVD-re épül, melynek alapvető előnye, hogy minden körülmények között megismételhető és aki egyet látott, az mindet látta.
Ezt egyébként elképesztő, hogy hazánkban mennyire nem tartják fontosnak. Az EDS/HP/HPE-s időkben, minden rendszerre volt egy gold image, amely elsődleges célja nem az automatizáció volt, hanem a megismételhetőség biztosítása, illetve az hogy egy bemenetre, MINDIG ugyanaz legyen a kimenet. Szóval ha feltelepít valaki 36 szervert, akkor az a 36 ugyanúgy legyen beállítva. Itthon 10 ügyfélből 1-nél sincs ilyen.
A VCF majdnem minden komponense szoftveres, ezért a „Full stack approach” annyit jelent, hogy ezek minden menedzsmentje, létrehozása teljes mértékben egységes, egy felületről többé-kevésbé elvégezhető. Amennyiben van a VCF-ben vRealize Automation telepítés is, akkor katalógusból fogyasztható minden a VCF-ben.
A „Built in security” részt nézzük meg részletesebben. Minden részt átsző, minden rétegben található olyan funkció, ami legalább azon a szinten képes emelt biztonságot nyújtani. Így például az NSX-T mentén lehetséges a mikroszegmentáció, a site-2-site IPsec és SSL VPN-re – kliens VPN-re is – akár identity based tűzfalazásra is. A VSAN mentén lehetséges SED lemezeken tárolni – mondjuk ez pont nem VSAN specifikus képesség – vagy titkosítottan tárolni a VM-eket a VSAN-on – ehhez külső KMS kell. Az ESXi adja amit tud, így ha TPM felhasználásával mindent – secure boot stb – titkosított VMotion akár.
Mi a minimális indulási méret?
Négy hoszt, négy VSAN ready szerver vagy 4 DellEMC VXrail. Előbbi szabadabb, mert 15 gyártótól választhatunk olyan kiszolgálót, amely támogatott. Utóbbi pedig azért érdekes, mert a VXrail Manager képes az SDDC Manager-rel úgy integrálódni, hogy igazából a fizikai kiszolgálókat érintő életciklus-menedzsment feladatok is elvégezhetőek onnak. Utóbbi előnye, hogy kulcsrakész, nem kell ESXi-t telepítgetni, mint a VSAN ready node-ok esetén, varázslóból készül el a rendszer.
Minden VCF-ben szükségesek a következő VM-ek a menedzsment miatt:
- vCenter Server – a menedzsment domain részére
- SDDC Manager
- vRealize Log Insight
- PSC
- NSX-V Manager + 3 controller
Konszolidált kiépítés
Legalább négy node és maximum hat. Ebben a modellben a management és a compute virtuális gépek egy domain-ben vannak.
Minden VCF telepítés így indul, ez nem választható, csupán később, akár rögvest a telepítés után, létrehozható egy/több workload domain. Fontos, hogy itt NEM lehet NSX-T telepítés, a konszolidált verzióban csak NSX-V lehet. Ez management domain-ben ez marad is így, akkor is ha standard modelre váltunk – azaz létrehozunk legalább egy workload domain-t.
Standard kiépítés
A konszolidált modell kibővítése, azaz ha van hét hosztunk, akkor abból 4 mindenképpen a menedzsment domain része lesz és a maradék 3 hosztból létrehozható egy workload domain. Na ebben a már, használható NSX-T, de a management domain-ben mindig csak NSX-V lesz – ebben a VCF verzióban biztosan.
Itt az NSX-T három converged appliance VM entitása a management domain-be kerül és minden NSX-T-vel telepített workload domain ezt az NSX-T manager cluster-et fogja majd használni. Fontos, hogy az észak/déli forgalmat és – sok egyéb szolgáltatást – intéző Edge VM-eket manuálisan kell még létrehozni, a varázsló ezt nem teszi meg.
A standard kiépítés határa 15 workload domain, domain-enként 64 hoszt lehet.
Tárolási réteg
Először tisztázzuk milyen tárolókat különböztet meg a VCF.
A „principal storage”, ahogy a neve is mondja, az elsődleges és fő tároló. Egy workload/management domain-ben a virtuális gépek tárolási helye. Ilyen tároló mindig kell és a management domain-ben ez kötelezően VSAN.
A „supplemental storage” pedig akkor hasznos, ha VSAN-ban nem akarunk/tudunk bővíteni, de szükség van több kapacitásra vagy például a VCF-re történő migráció miatt így nem shared nothing a vMotion. Ezek életciklusa – egyelőre – nem integrált a VMware Lifecycle Manager-be.
A 3.9-es VCF végre meghozta a változást, amiről korábban is beszéltem. Hiszem, hogy a VSAN bár jó termék és megtalálható a helye, de nem fogja és nem képes leváltani a világ összes rendszerében, az összes fizikai tárolót. Ebben a verzióban már lehet FC/NFS külső tárolókat behozni a workload domain-ek számára mint elsődleges tároló. Ehhez persze szükség van arra, hogy egyelőre manuálisan adjunk ki a szükséges LUN-okat az adott WLD (workload domain) alatt majd szolgáló hosztoknak és a szükséges zónázást is nekünk kell megtenni. Ennek ellenére én nagyon üdvözítőnek tartom a nyitást. Mondanám, hogy a VVol-ok használata a legjobb, de kevés helyen látom a VVol-t aktuálisan használni.
Számítási réteg
Említettem, hogy VSAN ready node vagy VXrail kell a management domain számára. Ha a standard model-t választjuk és nem VSAN-t használunk mint principal storage, akkor abban már lehet nem VSAN ready szerver is. És itt a lényeg. Hogy lehet ezt előállítani úgy, hogy az SDDC Manager-ből legyen fogyasztható a fizikai szerver entitás is az újonnan létrehozandó WLD-k számára.
Meglepő de legelőször ezt a HPE Synergy tudta. Ott a Oneview integrálódik Redfish API-n keresztül az SDDC Manager-rel. Azóta a DellEMC is összeszedte megát és megjelentek a PowerEdge MX vonallal. A Cisco pedig amolyan ignoráns módon nem vesz tudomást az egészről és amúgy is a 5108 chassis és a FI/FEX különböző verziói tökéletes elegyet alkotnak a big bang óta és ki is tart amíg a Nap fekete lyukká nem válik. Nekik nem kell VCF integráció.
Akit a VCF és HPE Synergy kombinációja van az keresse bátran Zeisel Tamást (HPE), ő megépítette ezt fizikai valójában.
Miért érdemes akkor VCF-ben gondolkodni?
Egészen egyszerűen azért mert minden nagyobb környezetben manapság a silós kiépítés a jellemző. Van egy office, egy test/dev, egy Oracle, egy Horizon, egy termelési/gyártási klaszter stb és ezek életciklusa több helyről menedzselt. Egy hoszttal való bővítés is attól függően hajtandó végre, hogy melyik klaszterbe kerül majd be, nem beszélve a teljesen új klaszterek létrehozásáról. Aztán még nem is beszéltem a frissítésekről – legyen ez akár hardveres, akár szoftveres – amelyek ezekben nem egyszerűek.
A következő feladatokat egyszerűen végre lehet hajtani egy VCF környezetben (nem sorolom fel mindet, nagyon hosszú a lista):
- Új workload domain létrehozása
- Meglévő WLD bővítése hoszttal/hosztokkal
- WLD megszüntetése
- Hoszt/hosztok eltávolítása egy WLD-ből
- Új klaszter létrehozása egy WLD-ben
- VMware szoftverek frissítése – ESXi, vCenter, vRealize termékek – VXrail esetén még FW is.
- VMware PKS környezet telepítése (link)
- VMware Horizon környezet telepítése
Az utolsó kettő érdemel némi magyarázatot. Ennél egyszerűbben nem lehet elkezdeni a PKS-sel való ismerkedést és a Horizon telepítését.
Képes feltelepíteni a Horizon-hoz szükséges Connection Server-eket, Composer-t, Load Balancert az NSX-T-ben, Appvolumes és UEM – ha van – és még az SQL-t is konfigurálja stb.
Mindezt varázslóból elindítva.
Ezeken a lépéseken megy végig, nagyon bonyolult feladatot vesz le a vállunkról.
Az is igaz, hogy bármennyire is ellenzik sok helyen a publikus felhő használatát, azért mindenki el-elvárja hogy legalább picit hasonlítson az on premises infrastruktúra rá, legalább a gyors komponálhatóság tekintetében, a szolgáltatások fogyaszthatóságáról nem is beszélve.
Ez a kép sokat elmond a VMware stratégiájáról.
Bár nem itthoni felmérés, de látszik, hogy bizony a hibrid felhő az amerre ebben az évtizedben tartunk és ez a lendület lehet kitart a következőben is. A tízes helyiértéken álló számokat mozgassuk át jobbra, azaz a „publikus felhő” 1%, a hibrid 21% a privát felhő 74% legyen. Ebbe értik amúgy a SaaS-t is, szóval ha valaki használ O365-öt akkor az máris hibrid felhő felhasználó. Nem mondom, hogy ez nem teljesíti a kitételt és nem tartozhat a kategóriába, de szívesebben néznék meg egy IaaS-re értett felmérést.
Ezekben az IaaS szintű hibrid megoldásokban a felhő is csak egy siló. Bármennyire is tekerjük a design-t és a szükséges prezentációkat a C szintű vezetők számára, ez sziget lesz csak a publikus felhőben található környezetünk. A VMware Cloud Foundation itt úgy képes segíteni, hogy várásolható VCF a felhőben is és akkor az on premises és a publikus felhős VCF lényegében azonos üzemeltetést igényel. Ismerős felület, minden folymat pontosan olyan mint saját adatközpontban. Ma már kapható ilyen az Azure-ban, Amazon Web Services-ben, Google Cloud Platform-on, IBM Cloud-nál – és Alibaba stb, amit EU-ban kb senki sem használ. Ezeket lehetőség van összekapcsolni például a saját adazközpontot és a felhőt, akkor akár kiesés nélkül lehetséges mozgatni VM-et saját adatközpont és a felhő köztött. HCX-el még érdekesebb funckiókat lehet használni (link).
