VMware Cloud Foundation 3.9

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