Tervezitek-e a VMware ESXi kivezetését az új árazás miatt saját és ügyfélparkot is belevéve?

Virtualizáció

Tavalyi évben a Broadcom felvásárolta a DellEMC-től a VMware-t. A felvásárlás összege elképesztő volt, aminek eredményeként idén be is jelentette az új tulajdonos, hogy a teljes termékértékesítési struktúrát átalakítja. Ennek következtében a termékek jelentős része megszűnik és minden előfizetéses konstrukcióban lesz elérhető csak. Sok egyéb terméket értekesített és leválasztott a vállalatról pl. Horizon stb. A tempó sosem látott és az okára csak tippem van.

A helyzet legnagyobb vesztesei azok, akik alapvetően hypervisor-ra és host cluster-re használták a termékeiket, mivel ezentúl csak a vCloud Foundation lesz elérhető, előfizetéses formában a következő listaáron:

  • 38 USD / hó / CPU mag kizárólag 16 magos csomagokban. Vagyis évente egy 16 magos processzor 7 296 USD lesz.

Ha a szavazás témájában egyes vagy az összes információ pontatlan, kérlek jelezzétek. Sajnos túl sok publikus információ nem érhető el a szomorú számokról.

Igen, mindennel váltunk.
23% (123 szavazat)
Igen, váltunk, de részlegesen.
6% (32 szavazat)
Még nem tudjuk.
11% (58 szavazat)
Nem váltunk, de feltehetően fogunk.
7% (36 szavazat)
Nem váltunk.
6% (35 szavazat)
Inkább leírom...
0% (1 szavazat)
Csak az eredmény érdekel.
48% (261 szavazat)
Összes szavazat: 546

( trey | 2024. 06. 18., k – 15:56 )

Nem váltunk. Majd meglátjuk mit mutat a kép, ha minden letisztult.

trey @ gépház

( gelei v | 2024. 06. 18., k – 16:16 )

Altalaban nem listaaron szokas ilyesmit venni, de

(x) meg nem tudom.

( mauzi v | 2024. 06. 18., k – 16:32 )

Az összes VMware-t használó ügyfelünknél előkészítés alatt van a váltás. (és tegyük hozzá, mindannyian nagyon sajnálják, mert kifejezetten elégedettek voltak a termékkel)

A PBS-sel - ha nem is fancy beépített, készen rendelkezésre álló módon - de megvalósítható legtöbb esetben az app-aware backup. Ugyanis a QEMU a guest agent-en keresztül fagyasztja/oldja az FS-t (buffer ürítés, stb.), és erre rá lehet fűzni tetszőleges műveletet fagyasztás/feloldás alkalmával egyaránt. Pl. DB page cache kiírás, read lock a snaphot idejére, vagy bármi más app memória tartalom ürítése, hogy a mentéshez készített snapshot diszken is konzisztens legyen, ne csak a memóriatartalommal együtt indítva legyen épp a rendszer (merthogy memória tartalmas élő gépes mentés is kérhető).

De kérhető olyan automatizált mentés, ami leállítja a VM-et, snapshot-olja, újra elindítja, majd lementi. Ahol ez belefér ez az "újraindulás", ott biztosan konzisztens lesz a mentés minden alkalommal.

A PBS mentési módszere nem is igazán konfigurálható, mert elsőre full, majd forever incremental módon működik, mindenképp tömörítéssel és deduplikálással. A megőrzési időket lehet konfigolni igazából.

kkv szinten teljesen jo (nagyobb szinten nem tudom): nyilvan a nagyok tudnak mindent is, de pbs-nek sem kell szegyenkeznie: dedup van, quick backup van (csak a valtozott blockokat menti), offsite sync van, tape van, live recovery van, stb.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Valóban. Viszont az a #1. A Barracuda Backup sem ismeri, nincs is roadmap-en. Ezeket a több 10-100 ezer eurós szoftvereket, appliance-okat nem fogják a szemétre dobni. Annál olcsóbb lesz a VMware-t továbblicencelni.

Nem a vSphere önmagában a drága, hanem minden kölönc, amit megvettél hozzá.

trey @ gépház

Ez most esett be:

BDRSuite v7.1.0 is now live!!

  • Agentless Backup for Proxmox VE: Protect your Proxmox VE critical data effortlessly without installing agents on each VM
  • Agentless Backup for oVirt: Ensure complete data protection and business continuity for your oVirt environments with our agentless solution
  • Remote Backup for VMware & Hyper-V: Seamlessly perform remote backups for VMware and Hyper-V VMs across distributed and geographically dispersed virtual infrastructures
  • Simplified Bare Metal Recovery (BMR): Stream backup data directly from BDRSuite to the target bare-metal host, reducing manual tasks and downtime
  • Teams Backup - Chat & Conversation: Safeguard Microsoft Teams chat and conversation data, ensuring important discussions, files, and information are securely backed up

[...]

Használja valaki?

trey @ gépház

A kommunikáció mindig ilyen ott. Ennek a párját olvastam én is. Az elmúlt 12 évben volt idő megtanulni a működést a cseheknél.

Az "változott" a témában, hogy figyeljük a VeeamON rendezvényt, sok érdekes és fontos bejelentés lesz. Időközben (elmúlt hetek) szépen csendben bővítették a mentett rendszerek körét Nutanix (gyanús, hogy ez már régebben beépült - nem célterületem), Redhat/Oracle virtualizáció mentéssel (ez biztosan mostanában - pluginként). Ami a saját problémám, hogy a teljes natív linux port 3-4 éve készül ugyanígy - várhatóan  a "következő fő verzió" jelzéssel. Szépen lassan faragják, de nem CA és társaik jelleggel dolgoznak, hogy bejelentjük, hogy 2024.09.31-én megjelenik és olyan amilyen, de majd javítjuk. (Volt ami hamarabb jött - mert elég masszív igény volt rá.)
 

Abba az irányba, hogy 3 hónappal ezelőtt még marketinges vállvonogatás volt, most meg már vannak nyomok. :D

A labor környezet folyamatosan adaptálódik - nincs elég agyam hozzá (nem ez a fő működési területem), hogy kövessem. Így vezették be az o365 mentést is pár éve. Az elmúlt pár rendezvény és tréning ki maradt sajnos. Ehhez még a proxmox-t is kellene tanulni picit - de arra már végképp nincs időm.

Nekem azért nincs bajom az ilyen csúszással - mert nem b@sznak piacra félkész terméket.

Proxmoxnál nekem a shared storage-el van bajom. Az, ami blokk alapú, snapshotolható, és shared, azt hiszem csak a Ceph (rbd-vel), és a zfs over iscsi. Egyiket sem üzemeltetném/támogatnám szívesen. Ti mit fogtok használni? Vagy standalone hostok lesznek?

Amúgy a GFS2-őn kívül van manapság a Linux világban erre valami megoldás (cluster fs)? Értem én, hogy szemléletmódot kell váltani, konténerekre és microservicékre meg SDN-re átálláni, node ahol van, és lesz is egy halom compute node + SAN + klasszikus alkalmazások vm-ekben, ott mi a válasz? (Már azon kívül, hogy perkálják ki a VMware, MS, Nutanix(?) licencek árát).

Tudom, láttam már párszor. Ha jobban megnézed, akkor 2db sor felel meg annak a feature setnek amit a vSphere úgy 20 éve default tud, (block, shared, snapshot, stable), ezeket írtam fent. Az LVM amúgy nem shared, a zfs meg nem való egy SAN-ra (pontosabban fogalmazva: enterprise tárolóra), ezért is jön képbe a zfs+iscsi a listában (a sima zfs-t meg ezért írja local only-nak), mert annak építhetsz egy zfs-nek megfelelő boxot (direkt elérésű diskek hba-kon keresztül, stb..), amit aztán iscsi-val bedrótozol a PVE hostokra. Nekem ilyen stressz biztosan nem kellene már, és ahol érdemben van lóvé, oda be se engedik. Persze akkor legyen lóvé VMware-re is, szóval a kör bezárult. Nem annyire hülye ez a Broadcom.

De ott meg nincs snapshot, az pedig egy rohadt nagy dealbreaker. Ha az LVM-thin-el elő lehetne adni ugyanezt, akkor menne a snapshot is, és valami egészen hasonló megoldás lenne mint vmware-nél a vvol, ráadásul a tároló oldalon nem is kellene extra támogatás hozzá. De szép is lenne.

Valójában ez egy technical dept lesz, ami be lesz árazva (üzemeltetési költség a megemelt licenszdíjakkal) és akkor majd kell hozni egy döntést: megéri-e ezeket az alkalmazásokat átalakítani vagy leváltani, vagy pedig maradjon így, és szépen perkálja a cég az emelt licensz díjat. Lehet, hogy egyébként megéri fizetni, mert olyan drága lenne a fejlesztési költség.

Ha valaki nem ért hozzá tényleg önveszélyes fegyver. Nálunk vagy 20 éve elég sok HA clusterben teszi a dolgát. Persze HA-nál nem lehet kispórolni semmit belőle, kell a rendesen felkonfigolt Pacemaker, STONITH, a redundáns linkek, ECC RAM, stb.

Akinek a fenti dolgok túl macerásak voltak, azok mindig dual primary módba konfigolták GFS2-vel. A végén mindig rosszabb lett a hibatürése mintha simán 1 stabil szervert használt volna. :)

Kb 10 évig használtuk, aztán 2018 nyár körül egy kernel upgrade olyan bugot hozott, hogy random split-brain állapotba került. Upgrade után pár napra jelentkezett és 3-7 naponta. Nem találtunk okot. Előző kernellel bootolva hibátlan volt ismét, ahogy előtte is.
Ez azt hiszem még egyszer megtörtént, na akkor dobtuk.

Volt olyan is, RAID-1-ben lévő hibás diszk megfogta az mdadm raid tömböt. Erről ment a DRBD és hibára kiállította a DRBD-t. Szétesett itt is a szinkron a párjával.
2 aktív-aktív host volt így összekötve. Akkor még nem engedett többet. Ez persze megágyazta a problémák alapját. Ezeket leszámítva, stabilan ment, de ezek után már időzített bombának éreztük. Egy darabig master-slave módon vittük tovább, majd inkább elbontottuk, mert ahogy mondtad, egy standalone szerver hosszú távon stabilabb, mint az ezzel járó random szívás. A 10+ évenkénti komoly HW meghibásodás pedig belefér az SLA-ba. A többi ellen a redundáns diszk, táp, net véd.

Ezt a végigszámolást bemutatnád kérlek? Kíváncsi vagyok rá. :D (no offense)

Szerk.: Ha az ügyfélnek szüksége van Windows Serverekre, akkor eleve kell valamilyen Windows Servert venni. Ezt akkor is meg kell vennie, ha Vmware alapú a virtualizáció - a Windows licencelése miatt. Akkor miért fizessen pluszban a Vmware-ért? Feltételezve, hogy az elvárt technikai képességeket a HyperV is tudja.

HyperV

https://idpr.dkuzrt.hu/web/#/products/search

cikkszám: AAA-90053-Commercial-MPSA-3 Yr(s) Remaining-3 Year(s)-A
név: Win Server Datcr Core 16 LSA
ÁR (Nettó átlag): 4,000,000 Ft 

​

 

Vmware

https://dach.tdsynnex.com/blog/at/premiumcontent/240202_vmware_broadcom_portfolio-2

-vSphere Essentials Plus Bundle - 1year - 96 core pack - VSP-ESPL-TD-TL-1P-C - 4,505 EUR
-vSphere Essentials Plus Bundle - 2year - 96 core pack - VSP-ESPL-TD-TL-3P-C - 9,460 EUR
-vSphere Essentials Plus Bundle - 3year - 96 core pack - VSP-ESPL-TD-TL-5P-C - 15,750 EUR
#
-vSphere Standard - 1year sub - 1 core - VS8-STD-SK-TLSS-1Y-C - 65,70 EUR          (16 core: 1051,2 EUR )
-vSphere Standard - 3year sub - 1 core - VS8-STD-SK-TLSS-3Y-C - 141 EUR            (16 core: 2256 EUR )
-vSphere Standard - 5year sub - 1 core - VS8-STD-SK-TLSS-5Y-C - 235 EUR            (16 core: 3760 EUR )
#
-vSphere Foundation - 1year sub - 1 core - VSP-PL-TD-TL-1P-C - 177 EUR          (16 core: 2832 EUR )
-vSphere Foundation - 3year sub - 1 core - VSP-PL-TD-TL-3P-C - 380 EUR          (16 core: 6080 EUR )
-vSphere Foundation - 5year sub - 1 core - VSP-PL-TD-TL-5P-C - 634 EUR          (16 core: 10144 EUR )

 

Most te jössz :)

Na de varjunk csak, a WS DC licenc az a VM-ekre is ervenyes, vagyis ebben a 4 milkaban mar a guest Windows Serverek is benne vannak. VmWare alatt azt meg kulon meg kell venni.

Ha max. 2 db Windows VM (+ barmennyi mas, ami free, vagy mashogy licencelt) van, akkor eleg a Standard is. 

Egyrészt tök jó árakat hoztál (nem). DKÜ Zrt. Közbeszerzés. Mintha az olyan olcsó lenne.... (nem olcsó)

Másrészt szerver OS-t nem biztos, hogy megéri megvenni SA-val. Egyszerűen drágábbra jön ki bizonyos feltételek mellett.

A példa kedvéért legyen az ügyfél neve GipszJakabZrt. (röviden: GJZrt.).
GJZrt.-nek van 3 fizikai hostja, dual socket, 16 core/socket, 32 core/server. A guestek vegyesen Windowsok és Linuxok is. Legyen mondjuk 100 db Windows guest és 300 db Linux guest.

HyperV: Mindenképp kell vennie 3 db WS Datacententert. Ez a te áraddal számolva - nem belemenve az MS licencelésbe, mert lehet okosabban is csinálni - 3 x (2 x 10000 €) = 60000 €. Ez lefedi a hostokat és a guesteket is bőven.

Vmware: Maradjunk a kedvező Essentials Plus Bundle mellett 3 évre. Ez csak a hostokat fedi le, ezen kívül meg kell vennie a sok Windows guest miatt is a licenceket. Nem vehet Standardot, mert ebben a méretben már sokkal olcsóbbra jön ki Datacenterrel. Ekkor a matek (kerekítve): 16000 € + (3 x (2 x 10000 €)) = 76000 €

60e € versus 76e €

Annyi részigazságod van, hogy a HyperV normális használatához kell az System Center (SCCM, SCVMM, DPM, SCOM, SM stb.). És ennek is van egy szép ára. Viszont ezt amúgy is megvenné GJZrt., mert van MS infrája. Szóval nézőpont kérdése, hogy a SC-t hová könyveled.

( hassan | 2024. 06. 18., k – 16:38 )

A csomagok: Essentials, Standard, Foundation és Cloud Foundation. 16 core a minimum licence/socket, de felette úgy tudom nem csak 16-os packot lehet venni, hanem kisebbet is.

Mi részben optimalizálunk, részben migrálunk.

A tempó sosem látott és az okára csak tippem van

Nem kell tippelni: profit.

( gee v | 2024. 06. 18., k – 23:17 )

Fogalmam sincs, hogy használunk-e ilyen termékeket.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( kruska v | 2024. 06. 19., sze – 06:44 )

Két nagyobb ügyfélnél is az általános IT infra VMWare alapú, viszont a nonprod SAP rendszereket javaslatunkra LXC/LXD konténerekbe pakoltuk már évekkel ezelőtt, a prod rendszerek bare metal-on futnak. Most nagyon hálásak.

Máshol is az új infrát már LXD-re tesszük, a régi VM alapú folyamatos leépítésével.

( asch v | 2024. 06. 19., sze – 07:41 )

Szerkesztve: 2024. 06. 19., sze – 07:44

Brutál ár. Szerencsére nem üzemeltetek, úgyhogy csak az eredmény érdekel. Fejlesztéssel foglalkozom, van néhány build szerverünk, de azok csak dockerrel meg talán VirtualBox-szal vannak megvalósítva. Nagyon nem szeretek olyan technológiát használni, ami nem FOSS, mert bármikor így járhatok, hogy nem-technikai ok miatt kell migrálni.

Rémlik mikor elkezdték a szervereket virtualizálni mondván, hogy mennyire megéri, mert sokat lehet spórolni vele azáltal, hogy sok dolgot futtatunk egy vason. Ezen az áron már lehet, hogy hirtelen nem fogja megérni virtualizálni, még szétköltöztetni több szolgáltatást is olcsóbb lehet. Nagyjából egyből megjött a vicc is, hogy a virtuális gép azokat a funkciókat valósítja meg, amit az oprendszernek kellene, de sajnos oprendszer szinten nem sikerült rendesen megcsinálni.

Mi az, amihez mindenképpen VMware kell?

A tech debt futtatásához. A VMware az egyetlen, aki felismerte, hogy a fizetőképes ügyfelek nagyrésze képtelen a szoftvereit modernizálni, és adott egy megoldást, hogy legalább az infrát tudja. Plusz a tech csapat eladhatta, hogy "felhőben van" (=virtualizált), managgák örültek, nyugi lett. 

Broadcom meg felismerte ezt, és mivel csak és kizárólag a befektetés rövid távú busás megtérülésében érdekelt, meglépte a mostanit. A kicsik elmennek, de a nagyoknak nincs választásuk, fizetnek mint a katonatiszt amíg végre le tudnak lépni (kb. 5 fájdalmas év és baromi sok befektetés, így lehet inkább beszámolják költségnek és beépítik a szolgáltatásaik árába. Ne felejtsük, hogy ezek ugyanazok, akik simán használtak mainframe gépeket vagy ma exadata-t, amit millió dollárokban mérnek)

Olyan kornyezetek ahol tobb ezer szerver van es fontos a mikroszegmentacio. Gondolj bele milyem suruseget lehet elerni blade szerverekkel.

10U meretu keret, benne 12 penge

650+ mag, 1300+ szall

Ha jol emlekszem 72Tb RAM,

gondolj bele, hany szervert, alkalmzas, adatbazis, stb telepitheto egy ilyenre.

Na ebbol javasolt berakni egy masikat is, ha vmi miatt ez leallna.

(Igen ezt magyar vallalatok is használjak)

6TB RAM/bladet hihetetlennek tartom, meg 256GB-os modulokkal is 24 kene per blade, es 100%-ig biztos vagyok benne, hogy 256GB-os modulokkal nem vesznek ilyen gepeket otthon (konkretan olcsobb megvenni mindent meg1x csak azert, hogy ne 256GB-os ram modulokat hasznalj, annyiba kerulnek jelenleg).

Nagyvállalati szolgáltatási környezetben, ahol százas tételben mérik az ügyfeleket, nem nagyon merül fel más. Az egy dolog, hogy ügyfélszintű elkülöníthetőség, de van olyan kitétel is, hogy auditálhatóság, és a VROPS ezt jelentősen megkönnyíti, például. Vannak, akik ragaszkodnak (akár egy xy jogi szabályozás miatt) a classic, vagyis hát, virtual-classic kiépítéshez, ilyenkor nemigen lehet felhőbe lőni az ügyfelet, barematal meg kevésbé költséghatékony. Aztán, vannak olyan VMware termékek, amik lássuk be, hogy nem rosszak, NSX-T, de akár egy Converter is eszembe jut.

Ezekre lehet írni, hogy nem teljesen fedi a "mindenképpen" kategóriát, és ki lehet váltani másik n+1 ilyen-olyan termékkel, és ha egy Kkv-méretű munkahelyen kellene ezen agyalni, nem is lenne gond. Nade ahol sok ezren dolgoznak, az üzemeltető csoportok specializálódtak, és szar ezt leírni, de az üzemeltetők technikai felkészültsége optimális esetben is csak normál eloszlást mutat... sajnos a kupleráj csak tovább rontja a helyzetet. És a VMware KB jó; nagyjából bármilyen problémára van tucatnyi gugu-találat; az ESXi ismerősen unixos-linuxos; hálózat, storage nagyjából klikk-klikk és pöcc-röff megy (kivéve, ha nagyon kretén a network admin). A support is jobb egy körrel, mint a Veritas-féle, pl.

Mindegy, kár érte. Bár legalább a Fusion/Workstation Pro ingyenes lett.

Mi az, amihez mindenképpen VMware kell?

Erre nem lehet röviden válaszolni,  Fasterk1cker nagyjából le is írta: sok helyen elég mélyen beépült az infrastruktúrába/üzemeltetésbe, rengeteg funkciót nagyon hatékonyan valósít meg a többihez képest ("just works"). A nehézség leginkább az, hogy a technológia is üzleti kérdés, a VMware hatékony üzemeltethetősége és mély beágyazottsága miatt sok esetben nehéz kiszámolni, hogy mibe is kerülne kiváltani. Valószínűleg ezért meri ezt meglépni a Broadcom, mert ha fogcsikorgatva is, de az ügyfelek perkálni fognak (legalábbis a nagyobbak, kisebbeknek nincs opciójuk). Ráadásul ha most kifizetnek 3 évet (tipikusan 1 éven belül kell dönteni), akkor 3 évig már nem fognak váltani, és valószínűleg utána is maradnak, mert addigra beárazódik.

Mi is gondolkodunk, mit mondjuk az ügyfeleknek, például Hyper-V esetén olyan kockázatot is érzek, hogy pl. 2-3 év múlva a Microsoft is gondolhat egy hasonló konstrukció váltást - és akkor történt egy nagy kínlódás a semmiért.

Miért lenne hiba?

Azért vezetsz be valamit, mert számodra előnnyel jár, költséget spórolsz. Ha (jelentősen) változik a költségviszony, újratervezel.

Egy vállalatirányítási rendszert sem úgy használsz/vezetsz be, hogy bármikor ki tudd váltani. Ha már bevezeted, igyekszel minden lehetőségét kihasználni.

A Windows (akár szerver, akár munkaállomás) is hasonló, tipikusan elég mélyen beépült az infrastruktúrákba. Lehet hibának nevezni, de ettől még ott van és nem biztos, hogy megéri kiváltani.

Miért lenne hiba?

Azért vezetsz be valamit, mert számodra előnnyel jár, költséget spórolsz. Ha (jelentősen) változik a költségviszony, újratervezel.

Azért mert ilyenkor ez egy vendor lock in. Én nem szívesen dolgoznék olyannal aki bevállal egy ilyen állapotot. Ez elveszi az alkupozíciót és az igénybevétel adó lesz. Fejleszthető olyan környezet is ami nincs kihegyezve az adott szállítóra és lehet használni azokat az egyes megoldásokból amit azok támogatnak. Ez nem kerül 2x annyi integrációba, és a végén meg lehet vele spórolni ami most történik. 

 

A Windows (akár szerver, akár munkaállomás) is hasonló, tipikusan elég mélyen beépült az infrastruktúrákba.

Szerver tekintetében ha ez generikus (azaz mindenre is azt választják) akkor ugyanez a nagy szakmai hiba. A desktop pedig egy költséganalízis kérdése, sok helyet láttam, ahol opex költséget indokoltak vele, majd a második mondatban megindokolták miért kell új hardvert venni és miért kell most több ember (új Windows  desktop verzió amit integrálni kell) kb 0 valós windows desktop igény mellett. Szóval esetenként ez is egy szakmai hiba.

 

 

Egy vállalatirányítási rendszert sem úgy használsz/vezetsz be, hogy bármikor ki tudd váltani. 

Ez egy rossz példa, mert itt az integráció teljesen más jellegű, ha nem nagyon hülye aki a szerződést köti látja mekkora a költsége egy váltásnak, és már eleve úgy intézi, hogy az adatok úgy álljanak elő, hogy a lehetősége a váltásnak meglegyen és minél kevesebb egyedi modul legyen. Emellett normális helyeken nem az a bevett szokás, hogy két vállalat irányítási rendszert használnak, és azért a vmware által kínált funkciókra igenis van alternatíva amit sok esetben párhuzamosan használnak. 

Ha azt veszed, hogy ugyanolyan OS fut egyik hipervizoron, mint a másikon, akkor nincs vendor lock in. Ez nagyon sok területen így van (nemcsak informatikában): ha ráállsz egy gyártóra, akkor arra ki kell képezni az embereket, a termék/szolgáltatási kör meghatározza a funkcionalitást. Ha áttérsz másik gyártóra, akkor átképzés szükséges, nincs ebben semmi különös. Minden technológia választáskor mérlegelni kell ezeket a szempontokat és nyilván a menekülő utakat is fel kell kockázat arányosan térképezni.

Ami itt fájdalmas, az a váratlanság és a kiadás tervezetlen mértéke. Egyik VMware felhasználó sem járt volna jobban, ha például 10+ évig csak azért marad ingyenes ESXi-n, mert akkor könnyebb kiváltani. Vagy hol húzod meg a határt?

VIR: "minél kevesebb modul" - na látod, leírtad a lényeget : "minél kevesebb". A határt nyilván adott körülmények határozzák meg. Leírásod alapján egy ilyen sem lehetne, holott már egy modul is "lock in" (valójában nem lock in, mert biztos másik cég is lefejleszti, csak pénz és idő kérdése).

Ha mindig mindent csereszabatosan csinálnál, akkor nem lenne technológiai újítás, hiszen az újításnak az a lényege, hogy olyat nyújtsál/használj, ami máshol nincs és előnyt jelent a versenytárssal szemben. A kockázatot nyilván mérlegelni kell, de az üzlet úgy általában erről szól.

Akkor most visszamehetnél az eredeti témára abból a sületlenségből, hogy generikus véleményt fogalmazol meg. Ráépíteni az infrát vmware-re mekkora vendor lock in, arról beszélünk vagy nem? Mindegyik cég _integrálja_ a terméket amiről beszélünk, a kérdés itt a hogyan. Ha valaki úgy csinálja ezt, hogy közel lehetetlen váltani azzal nagy gondok vannak. Ennyi. 

Hol itt a generikus velemeny? Tfh van egy QEMU alapu, teljesen custom, hazon belul felepitett virtualizacio+backup megoldasod. Szerinted onnan nagysagrendekkel konnyebb mondjuk Hyper-V-re migralni, mint pl. vmware-rol?

Mondjuk ha kijon, hogy az egyik 12 honap + 1 millio dollar, a masik meg 11 honap + 0.8 millio dollar, akkor mondhatjuk, hogy gyakorlatilag ugyanaz, nem?

( bognarattila | 2024. 06. 19., sze – 09:23 )

Mint Hassan írta, egyéb csomagok is "vannak", nem ennyire drágák is, de jelenlegi információ alapján legalább 3 évre elő kell fizetni. Itthon is USD alapú az árazás.

( n.balazs v | 2024. 06. 19., sze – 13:49 )

Egy ehhez kapcsolódó vicces sztori (NDA miatt konkrét neveket nem írhatok):
Adott XY nagy cég (nem Magyarországon) több tízezer fizikai szerverrel. Hol bare metal, hol HyperV, hol Vmware. Pár éve kitalálták, hogy beszántják a teljes HyperV-t, mert a Vmware jobb. Ez óriási migrációt jelent (bőven 10k+ VM).
Kíváncsi vagyok, hogy mikor fog csörögni a telefonom, hogy a projekt leállít, vissza a HyperV-re. Ehhez természetesen HyperV szaki is kelleni fog majd nekik. ;)

Ha vannak a cégnél architectek, akkor az ő feladatuk a piac követése. Nem szabad leragadni egy gyártónál, egy megoldásnál. Nyilván a teljes stacket kell nézni, hogy mi mit támogat, ki mire vállal felelősséget.

KKV az más.

( x-daemon | 2024. 06. 20., cs – 02:51 )

ebben az osszegben benne van a gep is, vagy azt kulon kell megvenni?

az eredmeny sem erdekel, de az igen, hogy akkor glusterfs helyett mit egyek a jovoben.

neked aztan fura humorod van...

ezt most melyik mondatomra irtad? az elsore ami szarkazmus, es nem igenyel valaszt, vagy a masodikra amire fent tenyleg leirtad, hogy a glusterfs halott, majd az erre adott valaszra mintha hanyos emojit tettel volna, de engem az erdekelne, hogy mit hasznaljak helyette?

masodik mondatomra tenyleg erdekelne a valasz. koszi!

neked aztan fura humorod van...

( msandor v | 2024. 06. 25., k – 13:25 )

Ha rajtam múlna, már rég KVM-et használnék.

Agyfaszt kapok a vmware bugjaitól. Persze a Linuxok se hibátlanok, de van lehetőségem kikalapálni.

Konkrétan mivel szarta össze magát a vCenter? Mert eddig olyant láttam, hogy elfelejtettek tanúsítványokat megújítani (üzemeltetési hiba), megtelt a logpartíció (üzemeltetési hiba) stb. Mindegyikről jön figyelmeztető levél már akkor, amikor warning állapotba kerülnek ezek a telemetria mutatók. 

Lassan 15 éve üzemeltetek vSphere környezeteket, de maguktól sosem kullantottak maguk alá.

trey @ gépház

Így van, én is énekeltem meg sokszor VMware bugot, viszont azt is mindig hozzátettem, hogy a VMware szarai messze a legstabilabbak napjaik szoftvereinek hígfos tengerében. Ha minden szoftver csak annyira lenne szar, mint a VMware vSphere komponensei és kölöncei, még boldogabb ember lennék.

trey @ gépház

elfelejtettek tanúsítványokat megújítani (üzemeltetési hiba), megtelt a logpartíció (üzemeltetési hiba)

ezek nem álltak fent

 

Kis helyi infránk van, 3 vas, 1 storage, essential plus licenc. Nagyon ritkán van dolgom a vcenterrel, kedden jött az sms, hogy áramszünet van az irodában. A biztonság kedvéért beléptem, az egyik vasról átmigráltam a gépeket a másik kettőre, majd nyomtam az üres vasnak egy karbantartási módot. Amit 1 óra múlva sem tudott elvégezni. Jobb ötlet híján rebootoltam az üres vasat, semmi változás, majd rebootoltam a vcentert, na azóta is bootol. Szerencsére konzolon be tudtam lépni, de kézi indítással sem indulnak el a vackai. Végül egy régebbi mentésből visszatöltöttem.

Szóval engedtessék meg, hogy pipa legyek a világ 1. számú virt. szoftverére. Én látom az előnyeit, de rohadtul frusztrálnak a hasonló dobásai.

Tudom, hogy egy proxmox, vagy egy mezei Linux szerver KVM-el ehhez képest fapados, de van esélyem megjavítani. Persze ez csak elméleti kérdés, mert ezt kell használnunk és kész :-)

Mindegyikről jön figyelmeztető levél már akkor, amikor warning állapotba kerülnek ezek a telemetria mutatók. 

Mutatok erre egy példát:

Subject: [VMware vCenter - Alarm alarm.HealthStatusChangedAlarm] vmware-syslog status changed from green to yellow

Target: Datacenters 
Stateless event alarm 
 
Alarm Definition: 
([Event alarm expression: Status change]) 
 
Event details: 
vmware-syslog status changed from green to yellow

trey @ gépház