Konec trvalých licencí VMware. Nově jenom termínované licence a předplatné (diskuse)

[xkucf03]

VMWare měl svého času unikátní vlastnosti (přijatelný výkon i bez HW virtualizace, dost dobrou emulaci různého HW, aby tam šly nainstalovat a provozovat obskurní systémy jako MS Windows). Jaký je důvod k jeho použití dnes? Přijde mi, že místo něj lze použít různé nadstavby nad KVM (nemluvě o tom, že ve spoustě případů není potřeba plnohodnotná virtualizace a stačí kontejnery) a důvod k použití proprietárního hypervizoru už moc není.

BTW: Broadcom teď skrze VMWare vlastní i Spring (javovský framework).

[MP]

Ten duvod je podpora enterprise sw/hw od ostatnich firem.

[zzz]

ve spoustě případů není potřeba plnohodnotná virtualizace a stačí kontejnery

Jenze ve spouste pripadu kontejnery nestaci. A vzhledem k tomu, ze konkurence (napr. MS) do velke miry jde smer cloud, ono neni ani kam moc prejit pro firmy ktere VMWare reseni (napr. vSphere) pouzivaji.

A to je presne duvod proc Broadcom dela, to co dela. Plna virtualizace uz neni rustovy segment, ale zakaznici co to pouzivaji jsou na tom dost zavisli. Broadcom snizi R&D investice, zvysi ceny a ze zakazniku vytahne co nejvic penez.

[Max]

Proto hybridní řešení v podobě virtualizace a kontejnerizace na jedné platforma, v případě vmware tedy např. Tanzu.
Cloud je dobrý jako další možné řešení pro DR. S větším nástupem kontejnerizace a automatizace to začne být čím dál tím méně problémové. Prostě se zvolí cíl deploymentu místo lokálního k8s něco v aws, azure apod., přesměrují se dns / balancery a jede se dál. Platí samozřejmě o samotných app a službách. BigData se musí řešit průběžně.
Zdar Max

[Max]

VMWare je na tom pořád hodně dobře. Nedávno jsem nasazoval oVirt a byl jsem překvapen, jaký je to v mnoha základních věcech nedodělek. Např. silné nedostatky se správou datastore pro VM, kdy nepodporuje mixed mód a všechny storage musí být sdílené se všemi servery (obešel jsem tak, že jsem lokální storage na hypervisoru exportoval jako NFS storage) a podobných věcí je tam více. Proxmox super, ale jejich filozofie (pokud se bavíme o jejich backup serveru), že nebudou podporovat zálohování VM na úrovni storage, je hřebíček do rakve, bo jednak performance impact, ale hlavně mají v určitých případech problémy s freezováním VM při záloze a nedostupnosti - výpadku komunikace s backup stranou (a myslím, že i nejen té jedné zálohované, ale může nastat i větší freeze). Oproti oVirt také míval Proxmox nedostatečné API (proto asi slabší podpora zálohování od třetích stran apod.). To se pak vmware + veeam jeví jako něco, co prostě funguje a dává větší svobodu si dělat, co chci (i když teď řeším jeden big výjeb). Navíc vmware má celý ekosystém (ESXi + vCenter pro centrální správu + NSX pro kompletní řešení sítě, firewallu apod. + Tanzu pro kontejnerizaci / k8s + SD-WAN + milion dalších věcí se vzájemnou integrací). Je to tedy pekelně drahý, ale funkčně (a blbuvzdorně) je to úplně někde jinde.

Budoucnost je postupný přechod na hybridní řešení (takže nasazení něčeho jako OpenNebula) až nakonec člověk skončí čistě jen u kontejnerů (OpenStack atd.). Dokud ale jde čistě o virtualizaci a řeší se HA, nutnost rychlých online záloh apod., tak nevím, co bych z OSS světa nasadil. Nabízí se ten Proxmox + zálohy formou snapshotů a jejich replikací na úrovni storage bez nějakého řešení konzistence VM, nebo nějaké 3rd backup řešení (možná Vinchin? Nevím, ale to, že to je Čínský sw, může být problém), ale nevím, zda existuje nějaké, co podporuje i zálohu na úrovni storage.

Prostě dilema, ale třeba mám jen malý rozhled. Existuje tedy něco, co umí to, co Veeam? Tj. plně konzistentní backup na úrovni storage (NetApp, Nimble, HP3PAR apod.) včetně file backupu a možnosti říci službám, že byly zazálohovány (Exchange si vyčistí transakční logy, MSSQL též apod.), instant recovery, wan backup atd.
Zdar Max

[..... Izak .....]

Ano NetaApp ma metrocluster a pak neresis vubec DR a ustris za nesmyslne licence, nebo mas snapmirror a na zalohy snapvault + lokalni snapshoty - btw. i nekonsistentni snapshot je naprosto v pohode - ale umi i konsistentni s komunikaci s VC - jine reseni nez netapp neni neb mud funguji blbe, nebo se licencuje per TB - byl LeftHand, coz b ylo super levne reseni synchornni replikace do druheho DC - proto ji asi HPE zrusil, ted ma neco podbneho i NetApp - taky jen iscsi a uz jen SSD disky.

NetApp vlajkove lode s Ontapem jsou samozjme the best, ale s NFS - na Lun bych zde zapomnel i kdy blokovy storage umi dobvre, ale prichazi se o mnoho vyhod netappu.

btw. KVM je taky naprosto OK, velci zakaznici vmware maji stejne support - velke slevy a tak se pro nic nemenni, mozna se jeste zlevni - mali zakaznici nejsou duleziti, prinasi penize, ale maji nejvice problemu - nejvice vytezuji support naprosto stupidnimi dotazy - ale proto ma vmeare slevu na support, pokud si to koupi od nekoho, kdo to odfiltruje, vyresi a az pak co nevyresi posle na support.

Takze vmware ani tak nevadi, ze nmekdo s 4 servery prejde na KVM a jeho varianty, pokud neprejde, protoze to neumi, tak hold zaplati vice - ti co umi mozna prejdou na KVM, imho KVM je mnohem lepsi, jen to neni takove korporatni a maloktery manager si neco takoveho poridi - pardoxne nema krity support na problemy, ktere ale s KVM nikdy nevzniknou - nebot tam se nic neskryva, ve vmware se skryva kde co - a jen support to umi opravit.

Nic neni dokonale a vmware ma kupu chyb ne ze ne, zase kdyz toho mate hodne, tak vam zase plno veci resi, bohuzel neni moc navodu na linux API, zato kupa na powershell ... takze se pise v nem, zase na nejake cykly atd. zapomente, vlastne se zadny powershell nepouziva, ale jen vmware api a prikazy, kdy neco najdete, vyberete a modidikujete - takze je to vlastne princip databaze.

Potreboval jsem treba tisice LUN zemnit multipath politiku, zas neco, co se vam s KVM nestane - nebot Linux resi multipath defauilt dobre, vmware jej deafult udela zcela spatne - teda nevyzuiva vsechny cesty a moc se nepta - to linux se zepta pres ALUA a nastavi vetsinou round robin na preferovane cesty - zase vmware pocita s nejakym smejdem, co pres ALUA rekne nejsou blbost, tak se drzi jedne cesty - nakonec se to stejne rozhodi pri vetsim pocte ESX - jen kazdy pouziva jinou cestu - no ale v vmware jeden scrip, celkem kratky, reknu vyber vsechny zarizeni s identifikatorem tim a tim (at nemenim lokalni zarizeni atd.) co nemaji round robin - najde je, muzu je vysat, ale to nresim, a reknu a ty cos nasel zmen atributy na tyhle - tedy round-robin - a udela to napric konktinenty na stovkach ESX - delam to jeden po druhem, je mi jedno, kolik hodin to pojede - dnes uz spise minuty, nebot samotny vyber je rychly - jen provest to chvili trva + v tom jde psat nejaka automatizace a tak - ne ze by v KVM nesla, mozna i snadno, ale spise stylem ansible, nebo seznam linuxu a ssh v cyklu s ssh klici

[Max]

Dřív jsem si také myslel, že je Netapp the best, ale jen do chvíle, než jsem poznal Nimble. Takže v práci máme jeden starší NetApp, který po 6 letech chcípnul. Exportoval jsem z něj volume přes NFS4.1 do ESXi 6.7. Archivačně na jedné volume běžela jedna VM. To, že se NFS4.1 server odporoučel mělo za následek, že se brejknuly všechny ESXi servery. Brejknuly se tak, že ztratily komunikaci s vCenter a přestalo fungovat i jejich vlastní vSphere web ui. Na všech ESXi se brejknul hostd, který nejde stopnout, killnout, restartovat. Všech několik stovek VM tedy nešlo zálohovat. Očekával jsem nějaký timeout, tak jsem to pár dní nechal, ale ani ťuk. VMware support nešlo kontaktovat, protože ač se platí nemalé prachy, tak dodavatelem licencí bylo HPE, tj. support se musí řešit přes ně. Celkově tedy big pain. Jediné, co reálně pomohlo, bylo stopnutí všech VM na konkrétním hostu, restart celého serveru, následně když naběhl, tak sice viděl nedostupné datastore, ale ty už šly odstranit. Prostě mega výjeb, který jednou blbostí sundal všechny ESXi servery.
NetApp jsme měli v režimu Async s druhou lokalitou. Když šel tedy první Netapp kompletně dolu (jeden řadič se odporoučel a druhý prostě nic nepřevzal a odmlčel se také), tak jsem nahodil v druhé lokalitě replikované SVM se všemi volume. Na Linuxu jsem to normálně namapoval, pod stejnou IP, stejnou path atd., ale ty ESXi ani hovno.

Jinak Nimble byl koupen HPE, ale díky tomu, že to nebylo HPE, tak jsme to od HPE koupili. Podobně jako s NetAppem jedeme async v intervalech v řádu minut. Async proto, protože zatím nemáme třetí lokalitu a split brain je riziko. Každopádně Nimble je fakt vyladěný storage (nepodporuje ale NFS, takže jedeme iSCSI přes 4x10Gbit). Co mě překvapilo, tak jsou v něm SATA SSD od Samsungu, tj., nejsou tam SAS disky. Práce se snapshoty a jiné věci jsou na parádní úrovni (pár kliků myší a běží mi VM ze snapshotu v testovacím prostředí atd.), narozdíl od toho, co má NetApp, který je ještě brutálně licenčně komplikovaný.
Nimble také neřeší spare disky, využívá všechny disky v poli a řeší spare místo. Využívají se tedy vždy všechny disky a v případě selhání jednoho dojde k rychlejšímu resyncu. U Netappu mi většinou odcházely dva disky po sobě, fakt žůžo. Buď to zvládly za jednu noc, nebo v rozmezí pár dní.
Zdar Max

[Max]

No, nás se snažil vmware i veeam uvrtat do jiného licenčního modelu už před delší dobou, ale nenechal jsem se. Všechno to vychází sakra dráž. Takže dokud budou podporovat prodlužování supportu u současných licencí, tak v obou případech setrváváme u per socker licence. Kdybychom např. s Veeamem přesšli na per VM, tak je cena licencí 2x větší, než teď. A tím, jak narůstal výkon hw v posledních letech, jsme schopni stále držet stejný počet socketů a navyšovat počet VM.
Zdar Max