Az árakról továbbra sem lehet beszélni, de és a csomagok sincsenek teljesen biztosan kőtáblára vésve, de attól még fel lehet készülni pusztán a gondolati síkon a szükséges döntések előkészítésére. Így, hogy mára kiderült hogy nincs mód az érvényes SnS-el rendelkező licenszeket átváltani a subscription modell-re, lényegében mindenki új ügyfél. Ez egy nagyon fájdalmas tény, mivel ha az új csomagok árát az SnS megújítása ellen nézzük meg, akkor sokkal drágább lesz az új előfizetéses modell. Nyilvánvalóan ahol érdemes hasonlítgatni az pont az olyan ügyfél, ahol a VMware eddig egyáltalán nem volt használt vagy teljesen új beszerzéssel operál, például bővítést vesz vagy új rendszert. Azonban a meglévő licenszek mellé történő SnS megújítást állítjuk szembe, akkor 100% előfordulással drágább lesz az előfizetéses modell.
A marketing majd megoldja és olyan mondások születnek, hogy ez miért jobb, de én immunis vagyok az ilyenekre. Mérnök vagyok és innen nézve nem mondanám egyértelműen jobbnak a változást. Amint a listaárak publikussá válnak, mindenképpen lesznek konkrét számolások is egy új bejegyzésben. Addig oszlassunk el pár ilyen mondást.
A mag alapú licenszelés – VVF és VCF esetén
Alig négy éve történt, hogy a fizikai CPU foglalat alapú vSphere licenszelése meghatározta, hogy egy foglalatban 32 mag lehet maximum, azt fedte le egyetlen licensz. Ennél magasabb magszám esetén újabb socket licenszt kellett vásárolni. Ez persze azt jelentette, hogy amennyire csak lehetett érdemes volt kevesebb, de nagyobb magszámú processzorral rendelkező szervert vásárolni, mivel ha 32 mag van az „árban”, akkor azt ki kell használni.
Az új csomagokban – mindkettőben – most legalább 16 magot kell vásárolni egy CPU foglalatra.
Ebből két dolog következik:
- a fizikai processzorban kevesebb mint 16 fizikai mag van – feleslegesen kell fizetni a magokért a VMware-nek, pedig nem lehet használni, mert fizikailag nincs benne mondjuk 8 mag.
Teljesen mindegy, hogy egy foglalatban miért nincs legalább 16 magos processzor. Az oka lehet az, hogy nem kell annyi compute erő, mert Oracle-t licenszelnek rá (elég gyakori), Windows-t licenszelnek rá (szintén). Az ilyen rendszereken égetésre kerül a pénz. Lehet mondani, hogy ezeket a CPU-kat vagy éppen a teljes hardvert bővíteni kell 16 magra és konszolidálni, de mondjuk egy Oracle esetén ennek elképesztő költsége van. Könnyen lehet inkább a VMware licenszeket érdemesebb elégetni, mint az Oracle-nek többet fizetni. - a fizikai processzorban legalább 16 fizikai mag van.
Azt, hogy az optimum a 16 magos processzor lenne, el kell engedni. Az a marketing BS nem állja meg a helyét, hogy most 16 magra kell törkedni. Egy darab 32 magos kiszolgáló olcsóbb mint két darab 16 magos szerver. Ugyanis egy szerver nem csak CPU-ból áll, hanem alaplapból, memóriából(bár ez itt irreleváns), tápegységekből, NIC/CNA/HBA kártyákból, BOSS eszközökből, RAID vezérlőkből és a házból. Ehhez támogatást is kell venni és persze ha minimálisan számolom, akkor be kell kötni az ethernet hálózatba két porton, a SAN-ba szintén két porton és az OOB portját egy porton. Az egy szerver ezáltal fele annyi portot igényel a méreg drága SAN switch-eken, a szintén drága ethernet switch-eken.
Teljesen érthető törekvés a kevesebb, de erősebb konfigurációjú szerver vásárlása minden szempontból, azaz a felfelé skálázás. A több szerver, több vasat, több portot, több hűtést és áramot és magasabb támogatási összeget jelent. Tegyük fel, hogy megpróbálok olyan szervereket vásárolni, amelyekben 16 magos CPU van és én a zöld üres téglalap gyártótól akarok venni egy DL380 Gen11-es szervert. Itt nem gyártót, sem az Intelt akarom savazni, de akkor válasszunk ki egy 16 magos processzort.
A Platinum vonal kiesett nincs belőle 16 magos, de az amúgy sem jellemző itthon. Gold esetén egyetlen egy ilyen processzor van, méghozzá a 6526Y. Ennyi (Silver szinten is van még egy 16 magos.)
AMD oldalon sem sokkal jobb a helyzet, bár itt legalább három CPU jöhet szóba, de az X-es széria az elég speciális és drága, szóval inkább csak kettő.
Reális optimalizációs lehetőség-e a 16 magos CPU-k használata? Teljesen kizárt, mert teljes költségben biztosan drágább lesz a járulékos költségek miatt még akkor is ha amúgy bárki boldog lenne a 6526Y Gold processzorral.
Való igaz tehát hogy a VMware licensz a VVS,VVF és VCF esetén is 50%-al drágább egy 24 magos CPU, mint egy 16 magos CPU, de ez még mindig nem akkora növekmény, mint ami egy teljesen új kiszolgáló ára – és vonatkozó költsége – lenne.
Teljesen mindegy a VMware licenszek költsége szempontjából hogy a képlet 10 szerver x 2 processzor x 16 mag vagy 5 szerver x 2 processzor x 32 mag, a szorzat végeredménye azonos, 320 mag.
A vSAN licenszelése – VVF és VCF esetén
A vSAN egy jó termék, de önmagában az, hogy mindkét csomagban jár valamennyi kapacitás per processzor mag az egy dolog. Attól még a kiszolgálókban nem fog kinőni a szükséges HBA kártya/kártyák – a SAS/SATA/NVMe kezelésére – nem jelennek meg a médiák (HDD/SSD) és a hálózat sem fejlődik fel hipp-hopp legalább 10, de inkább 25Gbit-re. A vSAN nyilván a fizikai processzort használja, úgy körülbelól laza 5-7%-ot. Aki akart vSAN-t, az már megvette. Aki nem akart, az pedig nem vett, utóbbiaknak teljesen irreleváns hogy most hány TiB van benne „ingyen”.
A licenszelés alapja az új modell szerint a kapacitás. Azaz az a hely, ami a vSAN segítségével összesen előáll. Ez a lényeg és szerintem a probléma gyökere. Ha van egy tíz szerveres környezetem és csak 10 Gbit-re képes hálózatom, akkor mondjuk a vSAN OSA marad mint opció. Tegyük fel, hogy minden szerverben van 8 darab 2 TB-os SSD-m – a cache irreleváns. Egy ilyen rendszerben – most eltekintek a formázási és átváltási konverziótól – 10 x 8 x 2TB kapacitásom lesz. 160TB-ra kell kalkulálni a szükséges vSAN licenszeket.
Direkt számoltam úgy, hogy a VMware Cloud Foundation esetén fedje a benne foglalt 1TiB/core licensz a kapacitást. VVF esetén pedig nyilván kell hozzá 160 TiB licensz, mert abban nem kumulálódik a benne foglalt 100GiB/core plusz a bővítés (a benne foglalt kapacitás elveszik). Van tehát 160TB helyem és ezt kell licenszelni. Még nem tettem rá semmit, de mennyi valamit tudok tenni rá? A vSAN egy házirend alapú „tároló”, a storage policy-k segítségével tudom megadni, hogy én milyen és mekkora hibatűréssel tárolok valamit. All flash esetén persze lehet RAID5 és RAID6-ot is használni és deduplikálni+tömöríteni illetve csak tömöríteni is lehet. Utóbbiak globális beállítások, azaz minden VM-re vonatkoznak majd, míg a RAID szintek per object alapúak.
A 160TB-ból 30%-ot illik szabadon hagyni, így 48TB már el is „ment” – de fizetni kell a licenszekben. A maradék 102TB-ot az általánosan javasolt dupla hibatűréssel akarom használni, azaz RAID1 marad és a RAID6. Utóbbinak szintén van CPU igénye, szóval maradok a RAID1-nél és az FTT=2-nél. Azaz a kisarkítva – mert igazából nem ilyen egyszerű – tízből két kiszolgálót veszthetek el és még nem lesz kiesés. 51TB marad de még ez sem az igazán használható mert vannak egyéb overhead-ek, szóval legyen inkább 46TB amit a ténylegesen rátehető adatot jelenti. A perpetual időkben a VSAN szintén a fizikai processzor foglalatra volt licenszelve így ha valaki túltette magát a szükséges plusz kapacitáson – azaz hogy azt a hardver gyártójának fizette ki – akkor nem volt más költsége. Most van, hiszen a holt kapacitást is licenszelni kell.
46TB redundáns tárolásához kell 160TB kapacitás. Utóbbit kell licenszelni.
Nem vitatom a vSAN előnyeit, de:
- kell hozzá elég jó ethernet hálózat - min 10Gbit de inkább 25Gbit
- kell hozzá a vSAN kapacitását adó hosztokba média – SSD/HDD
- kell hozzá kompatibilis kiszolgáló
- jócskán túl kell vásárolni a kapacitást
Egy sima központi tárolót támadni azzal, hogy a vSAN rack helyet, áramot és hűtést spórol meg, nem érdemes. Bármilyen Dell Powerstore befér 2U-ba és ezt a 46TB tényleges kapacitást simán hozza 60TB fizikai kapacitással – itt sem számolok DECO-val – hiszen itt nem teljes kiszolgálók kiesésével kell számolni (nem viszi magával a diszkeket ha egy szerver megáll) hanem csak egy egy média elhullásával. Ha a licenszelés alapja nem a használható kapacitás, hanem a használt kapacitás lenne, akkor lenne értelme az egésznek.
A VMware Cloud Foundation a csillaghajó
Élesben egyszer telepítettem VMware Cloud Foundation-t, olyat, ami nem csak a licenszben volt az. Ez egy remek termék azoknak, akik skálázhatóságot és egységes felépítést keresnek. Korábban írtam már arról, milyen megkötések vannak benne, ezeket el kell fogani, mert másképp nem nagyon lehet támogatott módon használni.
A VMware Cloud Foundation cikkeim: https://newman.cloud/category/vmware/vcf/
A VCF úgy kezdődik, hogy van négy darab VSAN ready szervere valakinek és köztük legalább 10Gbit-es hálózata. Ez az induló kiépítés. Önmagában ez a négy szerver alkot majd egy domain-t és végső soron képes kiszolgálni nem a VCF menedzsmentjére használt virtuális gépeket, konténereket is – consolidated design. De ha valaki nem keverné, akkor kellenek újabb szerverek, amelyek majd egy vagy több workload domaint alkotnak. Utóbbi esetben legalább hat kiszolgálóról beszélünk már, abból négy kötelezően vSAN ready, a másik kettő – workload domain – nem kötelezően kell az legyen, az használhat elsődlegesen külső tárolót is.
Az összes NSX ügyfél VCF-et kell vásároljon, mert csak ebben van benne az NSX – az overlay része a csomagban foglaltatik, a tűzfalazási képesség pedig vásárolható add-on hozzá. Akinek már van NSX-e, az tehát megveszi a VCF-et és fel sem kell telepítse – lehet nem is kell neki, nincs felesleges X darab szervere stb – de az NSX csak úgy lesz licenszelhető, hogy megveszi a VCF-et.
Kell-e bárkinek ténylegesen feltelepített VCF? A giga ügyfeleknél elképzelhető, de van olyan méretes ügyfél, ahol pontosan a kötöttségek miatt technológiailag nincs helye. A VCF maga egy folyamatosan változó környezetet jelent, ahol a workload domain-ek jönnek és mennek, ahol a frissítések egymással kéz a kézben járnak minden rendszeren. A magját képző SDDC Manager egy nem változó rendszerben csak ballaszt, lényegében csak a frissítésekre korlátozódik a szerepe és nem az automatizációra ami az megjelenő workload domain-ek létehozását, klaszterek kreálását jelenti. Persze az az optimáis, ha minden mindig a legfrissebb, azonban ez még egy tökéletes ügyfélnél sincs így.
VMware vSphere Foundation az új meta
Ha nem kell NSX, akkor ez a go to csomag. Arra számítok, hogy nagy túlsúllyal erre fognak menni az ügyfelek. Nincs VCF féle megkötés és olyan sallang, amire nincs szükség. vRealize/Aria csomag benne van, ami nyilván annak előny aki eddig is használta, aki meg nem, annak a meglévő Veeam One, Nagios, Zabbix, Solarwinds mellé egy redundáns eszköz. Még úgy is el tudom képzelni a váltást erre, hogy az ügyfél használ NSX-et mondjuk security képességekre – a néhai security only design – viszont annak megtartásához a VCF+Firewall add-on kell neki, ami kb magonként háromszoros ár a VVF és a VCF között.
VMware vSphere Standard
Beszéltem olyan ügyfelekkel, ahol egészen egyszerű volt a vSphere Enterprise Plus képességek elengedése. Akinek nem kell feltétlen DRS vagy distributed vSwitch és nem igényel 100GiB/core VSAN-t, meg Aria Suite-ot, annak tökéletes lesz.
Mit lehet tenni?
Ha éppen új kiszolgálói hardver beszerzése van folyamatban/tervben, akkor érdemes átszámolni azt, hogy melyik a költséghatékonyabb:
- kevesebb de magasabb magszámú szerver vásárlása
- több, de mondjuk 16 magos szerver választása
Ha ez nem aktuális, akkor optimalizálni a virtuális gépeket, a sok nem használt vCPU-t és RAM-ot visszavenni. Ha fizikai szervert lehet kikapcsolni, mert alig van terhelve és az is áttehető más klaszterbe, akkor az tényleges megtakarítást jelent. Át kell gondolni azt is, hogy mondjuk egy meglévő NSX telepítés megéri-e a VCF csomag vásárlását. Szintén hasonló az is, hogy a DRS, a distributed switch megéri-e a VVF vásárlását. Ha nem, akkor VVS-t kell vásárolni. Alapvetően a mix and match újra megjelenik, egy klaszterbe lehet nem kell DRS, akkor oda VVS mehet, a másikba pedig nagyon kell a vDS, oda VVF való.
Ajánlom a döntési ábrámat:
