VMware – csak bundle van, termékek külön nincsenek

Tekintve, hogy egyre több és több információ szivárog ki arról, hogy a Broadcom miképpen gondolja a VMware termékek jövőjét, nem sok tisztázatlan kérdés marad…..mennyi lesz az annyi és hogy a perpetual licenszeket, amelyekhez még van élő SnS, hogyan számítja majd be az előfizetésbe a VMware.

Az átalakulás előtt nyilvánvalóan a licenszelés elég bonyolult volt, hiszen akár egy terméken belül is volt eltérés abban vagy éppen több verzió arra vonatkozóan, mi a licenszelés alapja. Viszont mindenki csak azt vett, amit akart. Ennek nyilvánvalóan vége van és most igazából három bundle van és ezeket kell mindenkinek megvizsgálni melyikbe fér bele.

Személyesen én kíváncsian várom, hogy az NSX-el mi lesz, mivel a két fő képességéből pontosan a security – distributed firewall főleg – volt a lényeges. Nem hiába jöttek ki annó a NSX Security only opcióval, ami a vCenter Server-be integrálva tette lehetővé a mikroszegmentációt, mindenféle TEP meg nyilván overlay hálózat nélkül. Ahogyan a fullos NSX, úgy a security focused is vásárolható volt „bármire” ami vSphere. És akkor itt vagyunk 2024-ben és ez már nem is létezik, helyette pont az ellentéte van, azaz NSX Overlay – tűzfalazási képességek nélkül – és pont a security része az ami feláras.

Korábban:

  • security only – distributed firewall – mikroszegmentáció
  • security + overlay

Most meg:

  • overlay only
  • security + overlay

Ráadásul mostantól ez nem vásárolható bármire, csak bundle-ben van benne, de már a bundle-ben is csak az overlay képessége elérhető, a security az feláras.

Mr. Lam publikálta a bubdle részeit itt alább, szóval annyira már nem titkos, beszélek is róla akkor.

Döntési fa

Végtelenül egyszerűvé vált annak meghatározása, melyik bundle-be/re illik egy környezet. Több szempontból vizsgálható, de én itt most az NSX és Automation forrásút mutatom meg.

Ha tehát kell NSX, akkor VMware Cloud Foundation-t kell venni és az az NSX tűzfalak is kellenek, akkor hozzá a VMware Firewall nevű add-on is szükséges.

Ha nem kell NSX, akkor az a kérdés, kell-e Aria Monitoring és/vagy VSAN. Ha bármelyik kell, akkor VMware vSphere Foundation kell. Aztán kell-e VMware DRS (distributed resource scheduler) de feltehetem úgy is a kérdést, hogy kell-e bármi a vSphere Enterprise Plus-ból? Distributed switch például….ha a válasz igen, akkor szintén VMware vSphere Foundation a bundle. Ha ezekre nem a válasz, akkor a VMware vSphere Standard bundle a megfelelő.

Ha a vRealize/Aria csomagból kell az Automation is, akkor a döntési fa igen egyszerű.

Melyik csomagban akkor mi is van?

William Lam nagyszerűen lerajzolta és le is írta a blogján mi van benne, nálam is volt szó róla korábban. Most nem azt a nézetet szeretném tárgyalni. A mainstream termékeket nézem meg, tehát a Tanzu-t, a HCX-et, a VCDR-t nem veszem ide, nem hinném sokan használják – de nem látom a hazai piacot nyilvánvalóan.

Szubjektív véleményem az, hogy az ügyfelek nagy része bele kell férjen a VVF oszlopba, bár vannak kivételek. Olyan kivételek, amelyek korábban nyitottak az NSX felé például, tehát vagy overlay+security-ben vagy security only módon de használták azt. Egy kezemen nem tudom megszámolni azokat a rendszereket, amelyekhez közöm volt és akkor még a kollégáimról nem is beszéltem. Nekik két opciójuk marad: VCF vagy VCF + VMware Firewall add-on. Illetve három, mert ki is lehet vezetni az NSX-et. Biztonsági szempontból természetesen sokkal kevesebb lesz egy akármilyen rendszer NSX nélkül.

Az Automation már egy sokkal alacsonyabb számú ügyfelet érintő tényező. Ha az kell, akkor nincs kérdés, irány a VCF csomag.

A licenszelés alapja mindhárom bundle-nél mag alapú, de azért vannak szabályok:

  • egy foglalatra legalább 16 magot kell vásárolni. Ez az Oracle specializált CPU-k esetén VMware alatt rengeteg felesleges licenszelt magot jelent persze, de innentől kezdve ha nem köt semmiféle licenszelési szabály a workload oldalon, akkor 16 magos processzornál alacsonyabbat nem szabad venni, mert az pazarlás.
  • VMware Cloud Foundation vásárlása esetén az Site Reliability Engineering(SRE) Essential támogatáshoz tényleg fel kell telepíteni a VCF-et. Tehát a VCF-ben lévő licenszek és termékek használhatóak nem VCF-ként telepített rendszerben is – ahogyan eddig is így volt – de, akkor a fenti linken elérhető szolgáltatás nem lesz elérhető. Támogatás persze lesz rá, de nem mint egy VCF, hanem mint külön termékek.
  • A VSAN licenszelése core alapú, de nyers kapacitásra kell számolni (nem foglalásra). Ha tehát egy 100GB-os VM-et tárolok rajta mondjuk RAID1-ben, akkor az 200GB-ot – plusz witness komponens stb – eszik a VSAN datastore-on. Szóval a VVF-ben a 100 GiB/core egy négy hosztos környezetben (2 x 16 magos CPU-val) – 4 x 2 x 16 x 100 = 12 800 GiB-ot jelent, de ennek a felét – igazából annál is kevesebbet (ops reserve pl) – lehet majd ténylegesen használni. Ha ez kevés, akkor lehet vásárolni kapacitást, de legalább 8 TiB-et kell vásárolni per CPU. (UPDATE: Meggondolták magukat, nem kell annyit venni, lehet 1 TiB-et is venni per socket!)

    Érthetőbben ez azt jelenti, hogy VVF esetén ha nem elég a példában hozott 12 800 GiB, akkor a CPU-k számával egyenlő mennyiségben kell venni 8 TiB licenszet per folgalat. (link). Ha tehát nekem 40 TiB kell a klaszteremben, akkor bizony erősen túl kell vásárolni, mivel van 8 CPU a klaszterben és mivel 8 TiB a minimum amit egy CPU-ra venni kell, végül 4 x 2 x 8 TiB = 64 TiB lesz a licenszelt kapacitás – hiába kellett csak 40 TiB.
    Ez számomra azt jelenti, hogy innentől kezdve a sweet spot az pont az, ha VSAN hoszt pontosan a magok számával arányosan tartalmaz kapacitást. 16 mag tehát VSS esetén 1,6 TiB-et, VCF esetén 16 TiB-et. Ha kevesebbet tartalmaz, akkor égetem a pénzt. Ha több kapacitás kell, akkor pedig per TiB alapon lehet pluszban vásárolni kapacitást, ha amúgy teljesült a 8 TiB per CPU.

    VCF esetén más a dolog, ott a magonként járó 1 TiB és az azon felül add-on módon vásárolt vSAN kapacitás összeadódik, VVF esetén nem.

A VMware Cloud Foundation-ről már én is írtam korábban és az nem változott, hogy miért nem jó az mindenhová. A legfontosabb, hogy consolidated kiépítésben is legalább négy vSAN képes kiszolgálót igényel, ráadásul elegendő tárkapacitással, mivel a vSAN kötelező eleme, az elsődleges tárolója, amin mindennek lennie kell – SDDC Manager, vCenter Server, Aria Suite kompletten, NSX Manager-ek. Opció tehát e minden ügyfélnek az hogy VCF alá vennie kell lehet szervereket és meg kell tanulnia a vSAN-t? Egy VCF-et építettem életemben idehaza, ugyanakkor van VCF több helyen, csak nem VCF-ként használják, hanem csak a licenszeket belőle. Ezt abszolút megértem, mert pusztán NSX szempontból is iszonyatosan kötött a VCF – egy workload domain-ben a szegmensek közösek például a klaszterek között.

Összefoglaló

A VMware kedvenc terméke nálam az NSX és csak remélni tudom, hogy elérhetővé teszik záros határidőn belül a VMware vSphere Foundation-hoz is mint vásárolható add-on (egy hétre bekerült, majd kivették), ha az overlay képességét nem is, de legalább a security részét igen. Az is jó lenne, ha a VMware Cloud Foundation csomagban nem az overlay lenne alapból benne, hanem a security. Ez utóbbi kivitelezhetetlen, mert a VCF az overlay hálózatra nagyon erősen támaszkodik – elég csak a lokális és X-region szegmensekre gondolni.

A karrieremben az elmúlt 8 év másról sem szól mint VMware-ről és ez az a pont, ahol most erősen megingott az, hogy ezzel az ismerettel én továbbra is meg tudok-e élni. Lehet jó lesz ez az irány, de ahhoz az kellene, hogy kicsit átalakítsák a bundle-öket – vagy adják értelmes áron.

FY24Q1-re én a következő projekteket indítanám:

  • rightsizing! Azaz minden VM annyit és csak annyi CPU/RAM-ot kapjon, amennyit kér. A lehető legmagasabb vCPU:pCPU konszolidációs arány most fontosabb mint valaha. Ha több VM, kevesebb hoszton fér el, akkor könnyen kiszámolható, hogy lehet egy darab két CPU-s, 24 magos szerver jobban megéri, mint két darab két CPU-s de 16 magos szerver (2×24 versus 2x2x16). Volt pár ilyen projektem és az ügyfelek nem igazán vágták vissza a VM-ek méretét, holott annak technológiai előnye volt, immáron már pénzügyi is van, direktben.
  • ha licenszelési okok nem zárják ki, akkor az összes kevesebb, mint 16 magos processzorral rendelkező szerver kivezetése.
  • annak felmérése, hogy kell-e distributed vSwitch, DRS – és bármi amit az ENT+ tud. Ha nem, akkor VSS.
  • ha VCF az irány, akkor jól megtervezni az infrastruktúrát – nagyon sok múlik a szerverek kiépítésén (SSD-k mennyisége, mérete, NIC-ek száma stb.). Érdemes olyat keresni, aki látott már VCF-et a hands on lab-on kívül.