Megjelent a Proxmox VE 9.0

Virtualizáció

Megjelent a Proxmox Virtual Environment 9.0, Debian 13 („Trixie”) alapokon. Az új kiadás főbb újdonságai közé tartozik:

  • snapshot támogatás thick-provisioned LVM megosztott tárolókhoz,
  • affinitási szabályok bevezetése HA klaszterekhez,
  • modernizált, mobilbarát webes felület a Proxmox rendszerek kezeléséhez.

További részletek a kiadási megjegyzésekben és az ismert problémák listájában olvashatók.

Bejelentés itt.

( x-daemon | 2025. 08. 06., sze – 17:49 )

hamarabb megjelent, mint a trixie :)

neked aztan fura humorod van...

azert jo, mert ha betateszter vagy (nosub repo), akkor mire kijon az enterspajz verzio, lesz real world tapasztalat.

amugy meg le van irva a miert:

Q: Why is Proxmox VE 9.0 released ahead of the stable Debian 13 release?
A: Debian 13 is scheduled for its stable release this Saturday, August 9. Its core components have been stabilized since it entered the "hard freeze" phase on May 15. Following extensive integration testing and valuable feedback during the Proxmox VE 9.0 beta, we are confident in the stability of this release. Since our core packages are either maintained directly by the Proxmox team or are already locked by Debian's strict freeze policy, there is no technical reason to postpone our release.

 majus kozepe ota a fu se no olyan teren debianeknal, ami akkorat valtozzek, hogy a pve reszt eltorje :) az upstream meg amugy sem az o saruk, szoval...

Én sem tudom, mert pl. a FreeBSD Release Team-et nem egyszer láttam veszekedni türelmetlen user-ekkel, hogy a kiadás nem akkor van kész, amikor tag-elik a CVS-ben (vagy annak utódjában), hanem amikor a GPG-aláírt bejelentés kimegy a levlistára. Nem egyszer volt arra példa, hogy az utolsó pillanatban találtak kiadáskritikus hibát. 

Szóval, igen. Ez a Proxmox kiadás egy nem végleges Debian kiadásra épül. Ami nem feltétlen jelenti, hogy lesz vele gond, de benne van, hogy ordas hibát is tartalmazhat. 

trey @ gépház

Hát, ezt már megírták mások, ahogy azt is említettem. Ha egy Proxmox szintű izé ezt nem érti, akkor nekem is meglesz róla a véleményem. 

 

trey @ gépház

Tévedés. Adjak erre példát? Az ISO nem jelenti a végleges változatot. A végleges, kész kiadást a GPG-aláírt bejelentés adja. Még csak nem is a HTML, amit előre megírnak.

Nyilvánvalóan, az ISO-t és a weboldalt is el kell előre készíteni, mire a bejelentés kimegy. Viszont ebben az időben még bőven találhatnak kiadást akadályozó hibát. Nem is egyszer volt ilyenre példa.

trey @ gépház

( trey | 2025. 08. 07., cs – 14:28 )

Szerkesztve: 2025. 08. 07., cs – 14:28

Valaki nézte már, hogy a Veeam támogatás milyen szinten van a Proxmox-hoz? Használható már enterprise szinten?

trey @ gépház

Ilyen kalapácsaink vannak virtualizációs oldalon:

  • HPE VM Essentials
  • Hyper-V+SCVMM
  • Nutanix AHV
  • OpenStack
  • Proxmox VE
  • VMware

Sajnos a támasztott követelményeket és egyéb ügyféloldali elvárásokat, lehetőségeket figyelembe véve az jött ki, hogy van, ahol labdába se rúg a Proxmox VE. És nekünk jó pár ilyen ügyfelünk van.

trey @ gépház

nem ez volt a kerdes, hanem, hogy tud-e proxmoxot menteni a veeam (jelen kontextusban: kalapacs). tud. en meg nem azt hasznalnam(/lom) pve mentesere, hanem a gyari sajat megoldasukat. :) ahonnan pl. live restore-t is tudsz csinalni, ahol is mar fut a szolgaltatas, mikozben vandorol vissza a hypervisorra az adat. (downtime csokkentes rulz, foleg a sok terabajtos samba/es hasonlo szemetdombok eseten tud ez nagyon jo lenni)

hogy a veeam mennyire enterspajzredi, az meg kinek mi. kersz egy demot a sales-tol, aztan eldontod tetszik-e a feature-set :)

a kerdes csak az, hogy mi nem volt ertheto ebben? :)

Használható már enterprise szinten?

Mi nem érthető? A Proxmox támogatása a tech. preview-ból éppen csak kilépett funkció. Tapasztalat mi vele?

a veeam mennyire enterspajzredi, az meg kinek mi. kersz egy demot a sales-tol, aztan eldontod tetszik-e a feature-set :)

ROTFL 10+ éve használunk Veeam-et, nem ez volt a kérdés. 

Szövegértés?

trey @ gépház

akkor most elegedett vagy vagy nem vagy...

megegyszer: fogod, felveszed a kis telefonodat, megcsorgeted a kontaktot es kersz egy demokornyezetet/prezit/whatever, oszt' majd eldontod, hogy _neked_ jo lesz-e. :)
szoftveres vilagban mindenhol csak minden szepet megigergetes lesz, ratenni senki nem fogja semmire a toket ha adatod vesz, szerintem ezt mar regota tudod, nem most kezdted az ipart. :)

es megint megegyszer: pve melle pbs. tudod, cipo a cipoboltbo', rolex a rolexboltbo'... :)

Éles tapasztalatok érdekeltek volna, nem szintetikus szarok. De tőled ilyesmit hiba lenne kérni, Honnan tudhatnád te ezt? Az ilyen "hívd fel a Jenőt" szarokkal hagyj pls. nem ezen a szinten érdeklődöm. 

pve melle pbs

ROTFL, tákolt gagyi mellé másik tákoltat

Tiszta sor. Csak ilyen nem teszünk 7/24/365 2 óra reakció / 6 óra megoldási SLA mellé 🤷‍♂️

trey @ gépház

https://www.blackrack.eu/en/uslugi/high-availability/ https://www.blackrack.eu/en/uslugi/proxmox-ve/

lehet nem 99.999999999999% mint amit irtal, de nemcsak ti vagytok faszagyereket, mas is tud rendes slat adni... \o/

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

Jaja, van egy onprem igény, erre te elkezded mutogatni a végtelen pénzből épült felhőt. Nagy kópé vagy te! 

de ahogy nezem az ugyfelek egy resze mar kezdte eldonteni...

Jaja, gatya Proxmox meg a VMware közt van még pár lépcsőfok, a kevésbé tehetősek volt, ahol pl. Nutanix-ra váltottak ügyfélkörben is. Biztosan ott sem merték felvállalni a tákolást. Vagy éppen marad a Hyper-V vonal. 

meglesz iden a 2milliard bevetel? :)

CFO kérdéskör, mi közöm hozzá? 

trey @ gépház

en semennyit. de legyen 98%, mert hasamrautottem. ettol most szar lesz? sokaknak boven eleg ez a szint. az rf-nel is "csak" 99.9% van. aztan van >10k ugyfeluk, meg annyi beveteluk mint nektek (nyeresegben 3x annyi :DD). \o/

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

ettol most szar lesz?

Az csak egy dologtól függ, hogy MI AZ ELVÁRT. 🤷‍♂️ Ha 99,99% akkor az édeskevés. 

aztan van >10k ugyfeluk, meg annyi beveteluk mint nektek (nyeresegben 3x annyi :DD). \o/

Mondjuk továbbra sem érdekelnek ezek a számok, a fizetésem az, ami érdekel, azzal meg elégedett vagyok. Arra azért figyelnék a helyükben, hogy tákolt szeméten a Prohardver is elcsalinkázott 20+ évet, de addig járt a korsó a kútra, amíg el nem tört ... ja és mivel én fix fizetésért dolgom, nem nyereségért, az sem mindegy 52 évesen, hogy milyen nyugodtam alszom éjjel ... sok-sok horror sztorit láttam már, meg idegben összeomlott rendszergazdát is ... kérdés. 

Még egy dolog ... még ha csődbe is menne a jelenlegi munkaadóm, akkor sem változtatnék a szakmai álláspontomon, az nem megvehető ... 🤷‍♂️ szóval ez a mennyi a bevétel, meg a nyereség ... hagyd meg a tulajdonosoknak meg a CFO-nak, aggódjanak rajta ők ...

trey @ gépház

én fix fizetésért dolgom, nem nyereségért

ezzel mindenki igy van. csak a nagyobb nyeresegbol lesz a nagyobb fizetes. ;)

 

viszont a csokkeno bevetelbol az latszik hogy egyre kevesbe nyilnak azok a bizonyos penztarcak. vagyis lehet nyilnak csak nem nalatok \o/

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

viszont a csokkeno bevetelbol az latszik hogy egyre kevesbe nyilnak azok a bizonyos penztarcak. vagyis lehet nyilnak csak nem nalatok \o/

Sajnos a megfigyelésed nem helytálló, ugyanis nem láthatod, hogy a mi üzletágunk évről évre felfelé halad. S mivel az az én csapatom premizálása csak a mi üzletágunk eredményéhez van kötve ... tanulnod kell még beszámolók elemzését ;) Én nem panaszkodom, sőt, a mi területünk bővülőfélben van ... 🤭

Hogy nyílnak-e a pénztárcák, az ki fog derülni, én is kíváncsi vagyok, de mint említettem, amikor a felelősség kérdése fel szokott merülni, akkor érdekes módon mindig kerül elő lóvé sublótfiókból. Ha nem lesz, akkor majd jön a B, C, D terv és ha az se, akkor a Proxmox! 

trey @ gépház

https://youtu.be/zcwqTkbaZ0o
vigyazat, hardverporno, csak felnotteknek :D
csak ugy peldaul. ranezhetsz az icipici network mapre. na, ott az egesz orchestration monitoring pve alatt megy. :)
szerintem a legviccesebb, mikor tervezesnel osszebb toltak a szekrenyeket par centivel, mert a kov. ugras az optikai halo eseten csak kabelbol + masfel milla lett volna. marmint dollarbol :)

Most is az van kb. mindenhol. Persze, olvasnak internetet, így mindenhol megy a "de mire, de mire, de drága, de ez a Pokszmoksz", amikor megkapják az összehasonlítást és kiderül, hogy mondjuk egy tákolt storage-ra tákolt Proxmox VE + PBS kinézetre kb. ugyanolyan, de ha maga alá kullant, akkor nekik kell vinni a balhét, mint döntéshozó, akkor általában elsápadás megy és kinyílik a brifkó. 

trey @ gépház

Amikor kiderül, hogy aki választ, az viszi a balhét, akkor nyílni szokott. Semmi gond, ha mást választ, az is van, csak akkor legyenek tisztázva az egyes választások erősségei, gyengeségei, mit miért választottak, meg a felelősségi körök. Aztán már pattan is be a Proxmox ISO, bootol a Debian! 

trey @ gépház

  • Response time: 2 hours* within a business day
  • Remote support (via SSH)

Minek onsite support? Ott az iDrac, vagy iLO, ha meg a vas döglik be, ahhoz majd a vas gyártója megy ki, de ez egy szoftver.

Tényleg kíváncsi vagyok. Van kolléga aki vmware támogatást ad és sokszor használta a support-ot, de nem hallattam olyat, hogy oda is kellett menniük.

Vagy az oktatásra gondolsz?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Félreértesz. Ha az a kiírás akkor kell és kész. Én arra vagyok kíváncsi, hogy szerinted van-e értelme egy virtualizáló szoftvernél. Még egyszerűbben, ha te írnád ki, akkor beleírnád-e és ha igen, miért.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

onpremet adjal te vagy a helyi level0. onnan meg engedd be a szakit ssh-n. ha mar fizetsz a supportert.
de meg mindig szoftverrol beszelgetunk... azert nem fog kimenni hozzad egy szoftveres sem, hogy megdoglott a vas.
hyperv-sek, vmware-esek adnak neked ilyet? :) csak kerdem.
broadcom szeirint nem igazan...

Method of Access Web
Response Method Telephone / Web
Remote Support Yes
Access to VMware Discussion Forums and
Knowledge Base Yes

Még mindig ott tartunk, hogy mi fogja a Proxmox alá a shared storage-ot adni megbízhatóan. Majd ha ezen túljutottunk, jöhetnek a felsőbb dolgok.  

onpremet adjal te vagy a helyi level0

Nem ettem én meszet, hogy ezt tegyem. Más szara elé álljak be? 

onnan meg engedd be a szakit ssh-n. ha mar fizetsz a supportert.

Hogy lesz abból hardveres javítás? Kinek a felelőssége lesz, ha elszar valamit? 

de meg mindig szoftverrol beszelgetunk...

Nem, nem szoftverről beszélgetünk. Ha VMware, akkor kb. az összes brand storage-dzsal van VMFS snapshot és arra épülő enterprise mentési megoldás. Ha Proxmox van és kell a snapshot (mert mondjuk Veeam-mel akarom menteni virtuális gép szinten), akkor a LUN/LVM kizárva, mert azzal nincs snapshot, olyan fájlrendszer kell, amit tudja, ez a ZFS. Melyik brand gyártó szállít neked ilyen, 2/6 óra onsite support-tal? Vagy Ceph, kibaszott nagy hw igénnyel, szintén tákolós. 

Van az iXsystems, aminek van a TrueNAS Scale-je ZFS storage appliance-szel, ami már majdnem jó. Hol van magyar hardveres hozzá? 

Mi van még, ami felér valami vendor support-tal, amit előír a megrendelő?

trey @ gépház

Elfelejtetted a részleteket leírni, ez így kutya fasza hátrálás eddig. Légy szakmai (ezt hiányoljátok mindig) és öntsd ide a tudásod, hadd tanuljon mindenki. Nehogy úgy járjon, hogy egy egyszerű single disk hiba és a Félelem és Reszketés Las Vegas-ban izé legyen :D

trey @ gépház

tenyleg nincs meg a hardver-szoftver kozti kulonseg? :) a proxmox nem ad neked vasat es nem is fog odamenni diszket cserelni benne. :) oket akkor hivod, amikor a vas el, tessek, lehet jonni konfigolni ssh-n, mert balfaszok vagyunk. :)

hogy nem tudsz egy shared storage/mentest kivitelezni pve-vel, arra inkabb nem mondok semmit. menj el oktatasra. :)

es igen, ha shared storage-en snapshotot szeretnel, elo kell venned pl. az NFS-t, gondolom jaratos vagy az itthoni vendorok teren, nem lesz nehez a hazi feladat olyat talalnod, ahol nem csak infiniband van meg SAS/FC/iscsi :)

A Prohardver esetéből kiindulva. 

Te egyébként tényleg az állítod nagy mellénnyel, hogy a szerény hw tudásod egyenértékű azzal, amikor egy brand gyártó R&D-je kifejleszt, kitesztel egy terméket? :D A teáltalad tákolt x node-os Ceph rendszer vasait élesbe fordítás előtt mennyi teszteled? 🤔 Délután meghozza a futár a Supermicro-t, összehányod. Délután már élesben muzsikál? Mi van, ha egy firmware hiba miatt az összes node egyszerre kullantja össze magát? 

trey @ gépház

Miért ne tudnék Proxmox-al LUN-t használni?
Miért ne tudnék a LUN-ra csinálni egy bármilyen filerendszert, akár ZFS-t ?

Van egy viszonylag régi Proxmoxom, üzemszerűen mentek PBS-sel VM-eket snapshot-tal.

@trey írd már le légyszi hogy milyen feature-nek nézzek utána, tényleg érdekel, kipróbálom, beszámolok.

Most van egy Synology NAS-om, arról exportálok ki LUN-okat a Proxmox felé.

zászló, zászló, szív

"Még mindig ott tartunk, hogy mi fogja a Proxmox alá a shared storage-ot adni megbízhatóan. Majd ha ezen túljutottunk, jöhetnek a felsőbb dolgok.  "

Lehet lentebb leírták már, ha duplikáció, elnézést. Saját tapasztalat:
DELL M630 VRTX 4 penge, storage a VRTX-ből jön (innen adott dual raid kontroller), feladva minden pengének. Ezt linux látja mint egy raid kártyán lévő tömb. Erre LVM-t készítve, proxmoxnak odaadva tökéletesen működik shared storage-ként. Menthető, snapshotolható, live migrálható.

Amit nem tud: ha LVM-re thin poolt csinálok, ebben lévő VM-et nem tud kezelni több pengére feladva. Szóval csak a klasszikus LVM játszik shared storage-ben, így a VM a teljes helyet befoglalja. Így stabil, jó.

Mellék szál: proxmoxnál szerintem előny, hogy klasszikus linux toolok tárháza rendelkezésre áll. Voltam több VMware tanfolyamon, de még mindig KVM/Proxmox-on bátrabban üzemeltetek, mint VMware-n. Bármi lehalás van, alacsony szinten hozzáférek korlátozás nélkül. Akár LVM diszkről vagy qcow2 fájlból. Oda-vissza exportálható, importálható. Ha akarom, felcsatolom az LVM partíciót, kinyerek belőle az információt.

VMware-rel többször jártunk úgy, hogy a gyári parancsokat kevésnek találtuk. Biztos jobb a helyzet és e téren nincs elég rutinunk, de korlátosnak, merevnek érzem a lehetőségeit.  Jártasabbaktól szívesen olvasnék jobb híreket.

Hosszabb távú tapasztalat: Proxmox első kiadásait használtam 2012 körül, de kicsit még bugos volt a felület. Kb 2018 óta használom prod környezetben, 3-5 node-on, több száz VM-mel. Ha kicsit ráérősen frissítünk, semmi meglepetés nincs. Ha meg lenne, mi baj lenne? VM-ek ott vannak a diszken _könnyen_hozzáférhetően. Át lehet tenni másik szerverre és indítani, ha épp nem elég friss a backup. De ugye teszt vagy kis priós szerverrel kezdjük a frissítést.

Ennek ugye az alapja KVM, azzal meg végképp semmi baj nincs. 2015 óta használok nativ KVM-es környezetet is prod rendszerben, kolléga még korábbról. Nincs frissítéssel járó host-vendég OS/VM verzió inkompatibilitás. Minden megy mindennel bármikor.
Abszolút nyugodtan alszom KVM alapokkal, mert úgy érzem kezemben a szabadság :)
 

Trey!
Ezt gyakorlati tapasztalat alapján állítod?!

Jelenleg 6 helyen használunk PVE-t shared storage-n, kb. semmi probléma nincsen velük. Ha esetleg HA-t is bekapcsolód mellé, akkor pedig kb. teljesen önjáró node kiesése esetén.
(Nem közös storage alapon nagyon sok PVE-t futtatunk)

Mentésre PBS tökéletesen használható, beraksz PVE mellé egy dedikált BCK hardvert PBS-el, oda szépen mennek a mentések.
Ha nagyon biztosra akarsz menni, akkor BCK-n ZFS az FS, amit akkor amikor nem mentesz snapshot-olsz. Így plusz egy lábon állsz.

Mivel PBS tudja a rajta lévő BCK pool-ban lévő VM mentéseket másik PBS-re szinkronziálni, készítesz másik helyszínen egy másik PBS-t, és oda szépen átsync-eled a mentéseidet.
Ha az elsődleges helyszínen minden összeborult (ledobták az atomot), akkor miután pl. HW-t cseréltél, szépen megmutatod az új clusternek a másodlagos BCK szervert, és onnan szépen visszaállít mindent.

Az hogy milyen időközönként, milyen módon (offline VM, snapshot, etc ...) mentesz, azt már csak erőforrás kérdése.

És ezek csak az alap PVE, PBS feature-ok.
Egy csomó más magasabb szintű feature is ott van már (HA, live replication, SDN, ceph, több szintű firewall, ..... )

Érdeme egy picit nyitottabban megközelíteni ezeket a dolgokat! :)
 

Jelenleg 6 helyen használunk PVE-t shared storage-n, kb. semmi probléma nincsen velük.

Mennyi ebből olyan, ahol emberéletek múlhatnak rajta?

Érdeme egy picit nyitottabban megközelíteni ezeket a dolgokat! :)

Nem, nem lehet megközelíteni a dolgokat nyitottabban, ahol a pályázatban egyértelműen le van írna, hogy mi az elvárás. Itt egyfajtaképpen lehet megközelíteni. Megfelelsz vagy nem. Illetve, ha megfelelsz, akkor az SLA-t tudod-e tartani, vagy ha nem, akkor esetleg a kötbérre és a PR-katasztrófára rámegy-e az egész üzletet / egzisztenciád vagy sem. 

Jók ezek a tákolt (még ki nem adott Debian Trixie alapokon) dolgok. Nem akkor van velük baj, amikor nincs baj, hanem amikor van. Lásd: Prohardver esete ... ;) Akkor kezdsz majd izzadni, amikor egy baj esetén előveszik, hogy "ki tákolta ezt össze?!?"

Egy baj van ezekkel a dolgokkal: vannak olyan helyek, ahol az auditor meglátja, már megy is a High severity finding a jegyzőkönyvbe, rosszabb esetben a not compilant. 

Hja, persze, vannak ezeknek létjogosultságai: labor, tesztelés, PoC, KKV bohóckodás stb. Oda kb. jók. Ahol minimális elvárások vannak. 

trey @ gépház

Sok mindenről beszélünk, amihez látszólag lövésed nincs. Még egyszer: Prohardver esete és a tákolás. Amíg nem volt baj, addig nem volt. Amikor lett, akkor meg kurva nagy. 🤷‍♂️ Nem kell messze menni sem térben, sem időben. 

trey @ gépház

A kettő összefügg szorosan willy. Leírtam feljebb. Milyen technológiáról beszélsz, ha már az árajánlat fázisban kibasznak mint macskát szarni, mert alapvető feltételeknek nem felelsz meg? Kinek kezdesz el ZFS-ről meg snapshotról hadoválni, amikor már ott megbuksz, hogy te vagy a tákolt storage-od vendorja és te mint storage gyártó csak egy futóbolond lehetsz a nagyok mellett? :D

trey @ gépház

Nem, nem függ össze. Mert pl. tudok olyat amit te nem tudnál megcsinálni papír hiányában, de el tudom rólad képzelni, hogy ettől függetlenül képes lennél rá. Ez nem mindegy. Tipikusan ilyen amikor emberéletre hivatkozol, tudván, hogy a fel nem ismert kockázatok miatt sok ipari hulladék üzemel olyan helyen ahol emberéletek is múlnak rajta. 

Akkor mégse lehetünk olyan kicsik, mert egy része ezek szerint nálunk van ... Nem. Ennál jóva több van. 

a tobbi 10k+ cegnek meg teljesen megfelel egy proxmox alatt kialakitott rendszer olcsoert.

Persze, főleg ha a menedzsment, aki alatt dolgozol, nem látott még az általad tákolt cuccról és a versenytársairól egy SWOT-analízist (annál technikaibbat úgysem ért meg) :D Ők majd akkor kérdeznek fel, amikor beütött a baj. Nagy igazságok 25 év tapasztalattal a hátam mögöt::

  • a szar lefele folyik ... 
  • megcsináltuk, elbasztad ... 
  • a végén az olcsóbb lett a drágább ... 
  • olcsó húsnak híg a leve ... 

Most így ennyit mára. 

trey @ gépház

Legtobb kerdesben en sem szoktam (feltetlen) egyet erteni trey-el, de ebben spec. igen. "Fiatalon" meg nekem is jo buli volt mindenfele "egzotikus" open source etc... cuccokat hakolni, de ma mindennel  tobbet er egy stabil support, nagy ceggel a hatterben... A vevonek lenyomom a torkan, ő kifizeti , nekem semmibe sem kerul, es ezerszer nyugodtabb az eletem....

en elhiszem hogy seggvedesre tokjo a vmware, melle valami jolhangzo storage hw, meg nyilvan cisco ofc! :D

lehet venni tonna szamra supportot hozza, ha bekakkant es nem ertetek hozza, akkor van kit hivni. ha nagyon nagy bajvan akkor meg van kire mutogatni! \o/

de ahogy linkeltem, ha megvan a tudas, akkor _lehet_ masbol is jo rendszert epiteni. 51 (meg kitudja mennyi nem hirdetett) cegnel lehet vannak komoly rendszerek, nemcsak a szintezis tud olyat csinalni.

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

Se nem egzotikus se nem hakolt. Ha nem ismersz valamit, akkor mond inkább azt. 10+ éve üzemeltetek a 3-as verziótól jelenleg 8 cégnél (kb 50 node) és nyugodtan alszom. Ennyi idő alatt 0 (nulla) komoly problémám volt, egyszer kellett forráskódba nyúlnom a support (mert van!) segítségével, amíg kijött az update és egyszer volt egy cluster gond, de az elektromos/szünetmentes hiba miatt történt (10 perc alatt 8 darab kiesés) viszont a gépek ott sem sérültek és javítás alatt ment minden szolgáltatás.

Tovább megyek, annyira nem "hákolt" hogy adunk mi olyan cégnek Proxmox support-ot ahol Hyperv-ről álltak át a Windows-os rendszergazdákkal együtt. Ha jól rémlik talán 4 ticket-ük volt, amiből egy sem hiba, csak konfig segítség volt. 2 év alatt szépen beletanultak.

Az OpenVZ -> LXC átállás okozott némi munkát (az se ma volt), de problémát nem.

A storage rugózást meg egyszerűen nem értem. Ezeket támogatja GUI-ról (több szinten persze): ext4, xfs, ZFS, LVM, LVM-Thin, NFS, CIFS/SMB, CephFS, GlusterFS, iSCSI, iSCSI + LVM, Ceph RBD, ZFS over iSCSI, DRBD + open API sustom storage pluginoknak - saját fejlesztésű akármi

Ez Linux, amit az tud, ez is. Na aki ebből nem tud összerakni valamit, ott nem a Proxmox a hibás.

Ahhoz, hogy nyugodt legyen az életed, egy trükk van, értened kell ahhoz amivel foglalkozol.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

10+ éve üzemeltetek a 3-as verziótól jelenleg 8 cégnél (kb 50 node) és nyugodtan alszom. Ennyi idő alatt 0 (nulla) komoly problémám volt, egyszer kellett forráskódba nyúlnom a support (mert van!) segítségével, amíg kijött az update és egyszer volt egy cluster gond, de az elektromos/szünetmentes hiba miatt történt (10 perc alatt 8 darab kiesés) viszont a gépek ott sem sérültek és javítás alatt ment minden szolgáltatás.

Jaja, a Prohardvernek 20+ évig volt szerencséje.

A storage rugózást meg egyszerűen nem értem. Ezeket támogatja GUI-ról (több szinten persze): ext4, xfs, ZFS, LVM, LVM-Thin, NFS, CIFS/SMB, CephFS, GlusterFS, iSCSI, iSCSI + LVM, Ceph RBD, ZFS over iSCSI, DRBD + open API sustom storage pluginoknak - saját fejlesztésű akármi

Magyarázd el egy auditornak, amikor éppen azt feszegeti, hogy a storage gyártója (te) milyen rendelkezésre-állást tudsz egy személyben biztosítani. Annál a résznél lennék légy a falon, amikor azt ecseteled, hogy egy szál fecskében állsz a adriai strand közepén, kezedben egy laptoppal és onnan debugolod az egzotikus HW firmware hibából fakadó rendszerösszeomlást, mit ütőképes IT team ... :D (nem röhög, láttam olyant élőben, aki ezt állította).  

Ahhoz, hogy nyugodt legyen az életed, egy trükk van, értened kell ahhoz amivel foglalkozol.

Jaja, meg nem árt, ha tudod magad klónozni, illetve van egy jókora összeg a zsebedben, ha éppen kártérítésre kerül sor. 

trey @ gépház

Az megvan, hogy Proxmox szoftver és nem hardver? A storage pl egy HP 3PAR amihez a HP ad helyszíni garanciát, de ehhez a Proxmox-nak mi köze?

Tegye fel a kezét, akihez már ment ki helyszínre Vmware mérnök hibát javítani. De tényleg, van ilyen?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Dehogy van. Ne gondolj ebbe sokat, Trey is pontosan tudja, csak a nagy lendületben benézte, hogy mire/mit commentel, és most próbálja menteni. Amúgy kb. értem mit akar mondani, én is így látom, _részben_. De hogy minek ezt ennyire túltolni, és irreleváns hülyeségekkel továbbpörgetni, azt nem értem.

értem mit akar mondani, én is így látom, _részben_.

Akkor segíts már megérteni, hátha te értelmesen el tudod mondani :) 

Az kétségtelen tény, hogy a Proxmox legerősebb support az "2 hours within a business day" ami nem 7/24. Ez lehet kizáró ok, de többit nem értem.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Más ligában játszik a két megoldás. A PVE storage mátrix oldalon (eddig!*) szépen kijött, hogy egy FC tároló/SAN esetén a taknyolásokat kivéve ebből kettőt választhatsz: block, shared, snapshot. Az on-prem piacon, már ott ahol lové is van, viszont ezek a tárolórendszerek dominálnak. Mi pl. nem azért nem vállalunk CEPH-et, zfs over iscsi-t (meg úgy egyáltalán iscsi-t), drbd-s mókákat, mert nem szeretjük, hanem egyszerűen pénzt akarunk keresni, és oda megyünk, ahol van. A tapasztalat az, hogy ezek esetén nincs, vagy nem annyi, és folyton a fillérbaszás megy. És nem, a világ másik végén levő kivételekkel nem tudunk mit kezdeni, sose lesznek az ügyfeleink.

Szóval a baj itt nem az, hogy nincs support, mert amire telepíted, vagy amit rákötsz, ahhoz pontosan olyan onsite supportot kapsz, mint amire Trey gondolt. És mint ahogy a PVE pricing oldalán látható, Hypervisor oldalon is meg tudod ezt kapni, úgy, ahogy VMware esetén (ahol szintén NINCS onsite support, ezzel ne kábítsuk már egymást plz).

Amúgy az említett ügyfelek a Vmware árát is kifizetik, ez mára már egy lejárt lemez. A baj annyi volt idén, hogy nem egy szimpla áremelés történt, hanem egy maffiamódszer szerű zsarolás, és ha "végtelen pénzzel" rendelkezik az ügyfél, az még nem jelenti azt, hogy teljesen hülye, és ne kapná fel a fejét egy nyílt rablásra (talán ezért is van végtelen pénze, mert nem teljesen hülye). De ez már több más topicban is ki lett tárgyalva, ne kezdjük újra. Nálunk egyébként jellemzően mindenki kifizette, vagy ki fogja, de a köröket azért megfutották.

*De hogy ontopic is legyek: a PVE 9-ben most megjelent snapshot-as-volume-chain alapú thick LVM funkció ezen segíthet, szerintem érdemes lenne Treynek is tesztelnie, én biztosan fogom.

Két napja könyörgöm, hogy mondjatok egy ZFS alapú brand storage-ot, ami tud NFS-t kiajánlani, hogy legyen normális és kitesztelt (évek óta gond nélkül üzemelő, nem épp' tech. preview-ből kilépett izé) funkciókínálata és ennek legyen 6 órás hibaelhárítási támogatása onsite, dedikált mérnökkel 0-24-ben, 365 napban. 

Konkrét, élő szerződéseimről beszélek, ott, ahol emberéletek múlnak rajta. 

Odáig jutottunk az anekdotás könyvek alapján, hogy még mindig nem kaptam egyetlen gyártót sem. iXsystems a legközelebbi (mondjuk ez is csak több lépés távolságból brand) és annak sincs itthoni rendes supportja. 

Javítsatok ki. 

Kb. onnan tudjuk, hogy nincs ilyen, hogy az összes ügyfeled - ahogy mondtad - kifizette végül a VMware-t. 

a PVE 9-ben most megjelent snapshot-as-volume-chain alapú thick LVM funkció ezen segíthet, szerintem érdemes lenne Treynek is tesztelnie, én biztosan fogom.

Igen, majd ki fogom. És ha működik, ahogy kell, majd 4-5 év múlva enterprise-ready-nek nyilvánítom ... 

trey @ gépház

A Proxmox csak a helyi lemezen tudja értelmezni a ZFS-t, hogy a storage mit használ az irreleváns. Esetleg hálózaton a ZFS over iSCSI ami merőszak mindkettőre szerintem, de ott is mindegy mi van a storage oldalon.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Az miért számít, hogy mi van NFS alatt?

Mi az az üzleti követelmény, ami 2 órás garanciát vár el? Őszintén kérdezem, mert nekem inkább olyannak tűnik, hogy szűkítsük a potenciális beszállítók körét.

Ha hardver probléma ellen van, akkor szerintem sokkal jobb egy tároló fürt, a legalább két tároló legalább két független adatközpontban/szerverszobába, akár automatikus failoverrel, ez így 2025-ben nem egy megugorhatatlan akadály.

Ha szoftver probléma van, akkor szerintem régen rossz és teljesen mindegy, hogy 2 óra vagy 4 óra vagy akár NBD, kis esélyt látok rá, hogy abból garantálható valamilyen visszaállás. Az ilyen ellen inkább alkalmazás szinten is kell(ene) védekezni, emiatt az alkalmazás szállítóval sem árt valami hasonló szerződés, elvégre az üzletet kevésbé az infrastruktúra, sokkal inkább a szoftver szolgáltatás érdekli.

Mi az az üzleti követelmény, ami 2 órás garanciát vár el?

Olyan, ahol emberélet múlhat rajta, 0-24-365 működés, magas politikai kockázat.

akkor szerintem sokkal jobb egy tároló fürt, a legalább két tároló legalább két független adatközpontban/szerverszobába, akár automatikus failoverrel, ez így 2025-ben nem egy megugorhatatlan akadály.

Biztos, hogy nem viszed pl. a betegadatokat a falon kívülre. Főleg nem internetre bízod az elérést. A két független szerverszoba megvan az ilyen helyeken, nem az a probléma. A reakcióidő és a nagyfokú üzembiztonság. BTW: tud már a PBS vm-et backup-ból elindítani? Nem ilyen "háát próbáltam már, volt hogy sikerült", hanem évek óta stabil szinten.

Ha szoftver probléma van, akkor szerintem régen rossz és teljesen mindegy, hogy 2 óra vagy 4 óra vagy akár NBD, kis esélyt látok rá, hogy abból garantálható valamilyen visszaállás.

Ez van a szerződésben, ezt kell teljesíteni.

Az ilyen ellen inkább alkalmazás szinten is kell(ene) védekezni, emiatt az alkalmazás szállítóval sem árt valami hasonló szerződés, elvégre az üzletet kevésbé az infrastruktúra, sokkal inkább a szoftver szolgáltatás érdekli.

Az már nem a te felelősséged, neked a vas, virtualizációs környezet, op. rendszer szintig van felelősséged, felette más - alkalmazásszállítója - üzemeltet. Viszont az op. rendszer átadási pontig atomstabil elvárás van. Ez azt jelenti, hogy ha egy RAID6 tömb (2 diszkhiba még belefér) meg van támogatva egy vagy több Global Spare-rel és csak egyetlen diszk prefail (még csak megköpködi rendszeresen futó az ellenőrző job) állapotba kerül, már menned kell cserélni, indul a 2 óra reagálás, 6 óra fizikai elhárítás. 

Lehet itt vitatkozni, hogy de minek ez, meg minek az. Ügyféligény. Intézet IT vezetőként, igazgatóként megkockáztatod, hogy tákolt rendszert tetetsz alá? Főleg, ha független elemzés készül arról, hogy melyiknek milyen kockázatai vannak és rajtad a felelősség? Egy lófaszt. 

trey @ gépház

magas politikai kockázat

Értem

Intézet IT vezetőként, igazgatóként megkockáztatod, hogy tákolt rendszert tetetsz alá?

Engem nem kell meggyőznöd semmiről, csak az érdekelt, hogy mi a 2 órás szolgáltatás hozzáadott értéke, effektíve mennyiben csökkenti a kockázatot például egy 4 óráshoz képest (ha készült független elemzés, akkor gondolom arról is készült feljegyzés, hogy miért kell/éri meg kifizetni a 2 órát a 4 óra vagy egyéb helyett minden más intézkedés mellett).

Semmiről sem szeretnélek győzködni. Ha van egy nyílt pályázati kiírás és annak nem felelsz meg a beadott pályázatoddal, mert te úgy gondolod, hogy oda az nem kell, az azért probléma, mert konkrétan kiszórnak az első körben. Ami nem probléma, ha nem akarsz pénzt keresni. 

trey @ gépház

Műszaki aspektusa az, hogy egy kritikus rendszernél minél kevesebbet van degraded állapotban, annál jobb. Sok terás tömb rebuild ideje folyamatos műszak és terhelés esetén órákig tart. Ha az alatt beszarik még két diszked (mindegy mi miatt), akkor beszoptad. Lehet, hogy pont annyi kellett volna, hogy végezzen a rebuild. Nem várunk össze több problémát. 

trey @ gépház

Pontosan. Rebuild alatt, amikor még ráadásul használják is (0-24 üzem, plusz ráfut az éjjeli mentés). Mivel a diszkek egyidősek ... Még ha rebuild low proirity-vel fut, akkor is ... ilyen környezetben már a disk prefail is azonnali csere. Még minden zöld. Nincs degraded tömb. Még a gyártó általi előírás szerint IS. Pedig, még be se szart.

Pont ez a lényege a prefail állapotnak. Nem akkor cserélsz, amikor beszart, hanem már akkor, amikor még nincs semmi probléma. Ezt hívják proaktivitásnak. Ja, a prefail-es diszk a HPE és a többi szerint is garanciális csere. Ez a különbség a pl. tákolt meg a nem tákolt közt. Hogy hol kezdődik a garancia.

trey @ gépház

Köszi az infó, ez így kerekebb válasz, bár pont lemez esetén +1 tartalék (az alap tartalékhoz képest is) jó eséllyel olcsóbb (és gyorsabb is), mint a 2 órás támogatás, más alkatrész hibája esetén pedig valószínűleg mindenképpen célszerű máshova átterhelni (pl. vezérlő hiba esetén másik tárolóra), innentől kezdve továbbra is kérdéses, hogy mennyiért mennyire csökkenti a kockázatot.

Igen és mikor fog jó eséllyel a másik diszk(ek) beszarni? Amikor mozgatod át és olvasol a degraded tömb-ről

Nem igazán vágom, hogy egy 2 óra alatt odaérő lemez miért gyorsabb, mint egy eleve tárolóban készenlétben álló tartalék lemez (vagy akár kettő, a gyártó által javasoltakon felül). Igen, lehet, hogy már a 3. tartalék lemez is zsinórban elpukkant, de ugyanez előfordulhat a 2 órással is, amit szintén 2 óra pótolni. Abban valóban jobb a 2 órás, hogy ezt a játékot a végtelenségig lehet játszani és az utolsó tartalék lemez után a 4 óra több, mint a 2 óra, de a kockázatnak van egy előfordulási valószínűsége is.

Ha szinkronban tárolt DR site-ról beszélsz, az meg már nem ez a költségszint.

Most akkor életek múlna rajta vagy sem? Ha megáll egy vezérlő, akkor mindenkinek remeg a térde és biztonság kedvéért 24 órás papi szolgálat is van, mert az olcsóbb?

Persze, mindenben lehet kérdéses dolgot találni, de abban azért elég nehéz, hogy ha egy eszközt már akkor cserélsz, amikor nemsokára be fog szarni, abból baj nem lehet. Ügyféligény. Nem firtatod, neked nem a protokoll meghatározása a feladatod, hanem szolgáltatóként a végrehajtás.

Most akkor életek múlna rajta vagy sem? Ha megáll egy vezérlő, akkor mindenkinek remeg a térde és biztonság kedvéért 24 órás papi szolgálat is van, mert az olcsóbb?

Meglevő, IT által összerakott és eddig üzemeltetett rendszert kell supportálni. Észszerű keretek és minimális kockázat mellett. Nem az a megoldás, hogy odamész és azt mondod, hogy "itt minden szar, majd minden helyett hozunk valami újat". Meglepő ha így gondolod, voltunk már terepen együtt, szerintem pontosan tudod, hogy miről beszélek. 

trey @ gépház

ha egy eszközt már akkor cserélsz, amikor nemsokára be fog szarni, abból baj nem lehet

Ez így van, nem is erre vonatkozik a kérdésem. Az üzemeltetés kockázatról és költségről szól.

Ügyféligény. Nem firtatod, neked nem a protokoll meghatározása a feladatod, hanem szolgáltatóként a végrehajtás.

Ezzel nem lehet vitatkozni, főleg ha elég okos az ügyfél.

Meglevő, IT által összerakott és eddig üzemeltetett rendszert kell supportálni. Észszerű keretek és minimális kockázat mellett. Nem az a megoldás, hogy odamész és azt mondod...

Nyilván nem gondolom így, eddig nem hangzottak el ezek az információk, próbálok tanulni. Ugyanakkor az a rendszer valamikor ki lett alakítva, valami alapján megtervezték. Persze változhattak a körülmények, változhattak az elvárások, adódhatott úgy, hogy ebben a pillanatban a 2 órás reakció idő a legolcsóbb opció a kockázatok csökkentésére, de elég nagy esélyt érzek arra, hogy ez így nem optimális.

(igen, van, amikor adott ügyfélnek egy szerver garancia gyorsabb reakció idővel messze jobban megéri, mint egy összetettebb rendszer kiépítése)

Így már értem, ez üzletpolitikai döntés, nem technikai, viszont a világ nem csak csilliárdos cégekből áll. A zfs over scsi szerintem is hülyeség, a ZFS felét bukod vele és nyersz egy jó kis overhead-et. A Proxmox szerint HA-ra a Ceph ajánlott, ahová meg nem szükséges oda külön storage nélküli ZFS és replication, ami meglepően jó megoldás.

Adatvesztés meg bárhol lehet, akármilyen SLA meg űberbiztonságos technika van alatta. Mellesleg szerintem egy jól összerakott Ceph veri a legdrágább sbrand storage megoldást is megbízhatóságban, de erről nem akarok hitvitát nyitni.

Abban viszont egyetértünk, hogy a Proxmox még nem a felső liga.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Hát kevés ilyen minőségű freemium cég van. Én is nagyon remélem, hogy nem vesznek fel egy volt vmware sales-t  :D 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Majd ha egyszer csak összeomlik a VSAN és pingvinezni kezd a Broadcom support, ne sírd tele a párnádat. 
A kulcs minden esetben a szeparált redundáns működés működő üzleti folytonosság megoldással. Hiába próbálod bemutatni, hogy a VMware megoldásának felsőbbrendűségét.  
Két kérdés van amikor ilyet veszel: kell e olyan papír a szállítótól ami korlátoz, és hova szeretnéd tenni a kompetenciát.

A multi kliens sok esetben a helyi operatív működésen spórol és kiszervezi a felelőség és operáció egy részét. 
Azonban ez törvényszerűen egy szállítói lánc csapda, mivel kötve leszel az adott beszállítóhoz. Ami el tud savanyodni (lásd VMware) és nem tudsz hirtelen váltani. 

Minden értelmes helyen menekülnek a Broadcom öleléséből. 
 

A papír kérdésen pedig sok esetben akkor sem lehet átugrani, hogyha a szállított és papíron megfelelő szolgáltatásnál sokkal jobbat vehetnél. 

Majd ha egyszer csak összeomlik a VSAN és pingvinezni kezd a Broadcom support, ne sírd tele a párnádat.

Nem fogom, mert akkor a felelősség nem az enyém. Ahogy gelei mondta, segít elkerülni a csődöt ... 

Minden értelmes helyen menekülnek a Broadcom öleléséből. 

Ez elég meredek állítás, fent a kolléga megerősítette, hogy egy csomó helyen megfutották a menekülési tervet, majd megvették a VMware-t.
 

trey @ gépház

Kicsit furcsa a minőséget felelősségben mérni...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ja, pont mint a linux a windows-hoz képest, mert ott nincs brand sla :)

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Szarkazmus volt :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Tehát, még egyszer. Sorold fel a Proxmox által támogatott brand storage-okat, amik tudnak snapshotot és van hozzájuk 26/ óra magyarországi support. Mit nem értesz? Mi a retken fog adatot tárolni? Úgy, hogy abból legyen virtulis gép szintű, snapshot alapú mentés? Amit mondjuk ebben a környezetben a már meglévő Veeam kezelni fog? 

trey @ gépház

Bármi ami iscsi képes, tehát bármi. Nem mindenkinek csípődött be a Veeam. Nem egy konkrét cég igényéről beszélek, mert úgy látom te igen. Ott igen igazad van, oda nem jó.

Mutass példát Vmaware mérnök helyi kiszállására.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Oké, nézzük távolabbról. Melyik az a fájlrendszer, amivel a legtöbb Proxmox szolgáltatást ki tudod használni, beleértve a snapshotolást is? 

Nem mindenkinek csípődött be a Veeam.

Márpedig onnan indultunk, hogy mire kéne cserélni a meglevő VMware megoldást és miért nem feltételen Proxmoxra. Azért nem - egyebek mellett - mert nem fogják kibaszni a meglevő kölöncöket, többek közt a szalagos mentést/archiválást jól kezelő, No 1. mentési megoldást, a Veeam-et. Főleg nem egy PBC-re. Egy valamit jól tud mindenki. A jó mentést nem helyettesíti semmi (megintcsak Prohardver). Ez van.

Vmaware mérnök helyi kiszállására.

Minden olyan helyen, ahol elvárt az onsite support szerződésileg. 

trey @ gépház

Tipik oldschool infra arhitect megközelítés hogy "á ehhez a régi gombhoz nem lesz jó az új kabát".
Az "enterprise support" se mond semmit a minőségről vagy a hatékonyságról.
Dolgozom egy céggel aki bankoknak szolgáltat, hú de felelősség, hú de enterprise.
Minden komponenshez kötelezően megvan az "enterprise contract" különben megb@ az audit, nyilván.
Ettől függetlenül még bőven fizetnek az ügyfélnek a különböző SLA sértések miatt, mert amúgy hülyén megtervezett összetákolt szar az egész.

zászló, zászló, szív

trey most azzal jon, hogy o mint sales hogyan tudna tovabbpaszolni egy lepapirozott SLA-t. neki nem celja, hogy ok uzemeltessenek, mindossze osszekotni szeretnek a vevot es a harmadik fel papirozott vallalasat. (igen, direkt sarkitom a kepet, de amiket itt mond az pontosan ez)
csak ugy nehez lesz modern infraban gondolkozni. :) mert a modern alapfeltetele, hogy nem a husz eve takolt megoldasokkal operal. es mindinkabb software defined, network, storage es szolgaltatas szinteken is, mintsem hw-alapu FC/infiniband meg MP iscsi... nem par darab ceges winszerver/mssql eletben tartasa a scope, ami elpatkol ha nem snapshotbol inditod vissza...
ugy kell infrat csinalni, hogy ha leall egy vas, akkor kit erdekel, csak egy sarga potty a monitoringban. majd lesz masik.

ceph szerinte overkill (de azert vmware-re van pe'z LOL) egy Pacemaker, drbd, NFS, vrrp viszont 15-20 eve biztosan van mar kontrolcekontrolve konfiggal barmilyen linux storage szerveren (es azota meg mar az nfs is multipath-kepes, szoval ezzel se lehet mar takarozni) :) jahogy azt nem valaki szallitja, hanem az uzemeltetes rakja ossze ha ert hozza <=mint egy munkanap alatt ezert nem lehet erte enterspajz arazast elkerni? haaat, ilyen ez :)

Nekem kicsit kalapács esete aki mindent szögnek néz, de már van csavar, meg ragasztó, meg csapolás is :)

Ha már ennyire brand storage, meg support: https://www.ibm.com/products/storage-ceph

Ott van még példának a BackBlaze. Saját "sufni" szerver + Ceph. Biztos elbénázták, mert nincs 1000% SLA meg brand support. Még nyilvános is, letöltheted a vas tervét https://www.backblaze.com/blog/open-source-data-storage-server/ és összebarkácsolhatod magadnak :)

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Mindenki olyan kockázatot vállal be, amilyet akar (ez akár ügyfelenként is eltérhet), én azt gondolom, hogy egy IBM (vagy akár BackBlaze) más liga, mint egy tipikus/átlagos hazai IT integrátor vállalkozás: jó eséllyel több fő foglalkozik csak azzal az egy termékkel, mint egy hazai vállalkozás teljes létszáma, akár a kiszervezett takarítót is beleszámolva. Megfelelő hardverek, OS-ek kiválasztása, verziónkénti tesztelése stb. BackBlaze-nek ez ráadásul kiemelten kritikus folyamat, hiszen minden azon van, ellenben lényegében csak saját magukkal kell kompatibilisnek lenniük.

Tavaly nyáron volt egy Sztaki előadás, ahol valamelyik előadótól elhangzott, hogy volt adatvesztésük Proxmox/Ceph tárolón. Nyilván akár bénázhattak is, nem emlékszem a részletekre (ha egyáltalán voltak), de nekem úgy jött át, kellő körültekintés kell, amire nincs mindig mód (értsd: senki nem fogja megfizetni).

Nyilván akár bénázhattak is, nem emlékszem a részletekre (ha egyáltalán voltak), de nekem úgy jött át, kellő körültekintés kell, amire nincs mindig mód (értsd: senki nem fogja megfizetni).

Tipikusan, amikor a végén az olcsóbb lett a drágább ... 

trey @ gépház

Ez megvolt?

nem emlékszem a részletekre

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Magam részéről a summára emlékszem: kockázat, a többi nem érdekelt annyira, de ha érdekel, talán meg tudom keresni, ki mondta.

Értsd: nem gondolom, hogy az illető társaság béna lett volna (vagy mi feltétlenül jobbak lennénk), mégis belefutottak ilyen hibába, ergo mi is belefuthatunk hasonlóba, nagyobb kockázattal, mint egy bevált tároló megoldásnál.

en tul sok bevalt brand tarolo megoldast lattam mar megdogleni. :( es ha a folotte futo infraban erre epitettek, ott nemcsak kieses, adatvesztes is volt. amire a brand gyartoja felteszi a kezet, h benne van a szerzodesben, hogy az adatra nem vallalunk semmit, vedd elo a backupodat.

no, es korbe is ertunk, mert pont ilyenkor jon jol egy PBS live restore. mikor ranyomtal mar el a szolgaltatas, aztan majd visszacsorog szepen az adat a hatterben a helyere.

Egyfelől én akkor lehet, hogy szerencsés vagyok vagy nem elég nagy a minta, másfelől még mindig ott lebeg a kérdés, hogy minek kisebb a kockázata vagy költsége adott rendelkezésre álláshoz: egy brand tároló vagy proxmox + ceph.

A kérdés az, hogy milyen a kockázatelemzés, mert ahogy egy tároló megpusztulhat, úgy sok egyéb kockázati tényező is van, amiből az jön ki, hogy egy tároló nem elegendő adott esetben. Az azért óhatatlanul benne van a pakliban minden infrastruktúra esetén (még ha kis valószínűséggel is), hogy mentésből kell mindent visszaállni, ezt is figyelembe kell venni/tervezni.

Elvesztettem a fonalat, hogy mit hasonlítunk mivel :)

Szvsz a fair:

brand tároló  <->  brand vas + open szoftver
vmware + brand vas <-> proxmox + brand vas

a 

vmware + brand vas <-> proxmox + dzsunka pc

nem fair  :D

A ceph-et az IBM/RedHat fullba támogatja sw és hw szinten is és tudtommal az OpenStack alá az ajánlott rendszer, aminek látható a részesedése.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

mikor ranyomtal mar el a szolgaltatas, aztan majd visszacsorog szepen az adat a hatterben a helyere.

Na ez látod egy érdekes kérdés, hogy egy visszacsorgó szolgáltatás mire elegendő. Van, hogy megfelelő, de mondjuk egy rendesen megtekert adatbázis esetén nem feltétlenül, nagyobb méret esetén ráadásul a visszacsorgási idő sem elhanyagolható, közben az iops-okért küzd a db és a visszaállítás.

ezzel azt mondtad, hogy barmi lehet :) tehat semmit.
ahova eleg a ceph performace, oda jo esellyel eleg lesz a live restore is, mert igyis-ugyis mozogni kell az adatoknak a gepek kozt. es igen, az ajanlas PBS-re a flash storage, redundans, 10++gpbs-en.
technikailag pedig azok a blokkok fognak visszasetalgatni on-demand, amikre eppen READ erkezett. a tobbi meg "ahogy odaer".

Nem, azt állítottam, hogy a marketing brosúrán jól hangzik, de általánosan nem lehet rá számítani, tervezni kell. Nyilván lehet optimalizálni, lehet SSD-re is tenni, de ha minden VM-et egyszerre akarsz visszaállítani, akkor azért előfordulhat IOps szűkösség, illetve kérdés, hogy az "ahogy odaér" az valójában mennyi (elég gyors vagy sem). Nyilván a mentés alá is lehet "tetszőleges" teljesítményű tárolót tenni, csak az a kérdés, hogy hol van az észszerűségi határ (intézkedés/kockázat), előfordulhat, hogy nem normál produktív szolgáltatás lesz belőle.

ez nagyon egyszeru, le kell irni, hogy mennyi ido az elvart disaster recovery. ha a ceg nem allhat napokig, akkor flash-re kell tenni a backupot is (legalabb az elso parat, utana mehet ki a prorgo rozsdara az archiv). es akkor olyan teljesitmennyel fog futni live-restore-kor, mintha egy halozati storage-en lenne (mert technikailag azon van).
de normal esetben backuphoz mar csak a legvegso esetben nyulunk, ott mar altalaban nem az a szitu, hogy egy HW esett el, hanem pl. felnyomtak a datastore-t ransomware-rel. ott meg nem a restore gyorsasaga lesz a szuk keresztmetszet, hanem mire a klienseket legyaluljak/megszabaditjak a kartevoktol. neadjisten felepitik az AD-t 0-rol.

Ismerem a technológiát, nem kell bemutatni, köszönöm, mindössze arra próbáltam reflektálni, hogy ez a "live" visszaállítási technológia papíron olyan szép és egyszerű, a való élet kicsit más lehet, még akkor is, ha maga a funkció nagyon hasznos, tudni kell, mire mikor használható (mint sok minden más esetén). Maga a mentő szoftver réteg is ront a teljesítményen, szerintem nem olyan egyszerű (és olcsó) produktív teljesítményt kihozni belőle nagy IO igényű alkalmazások esetén.

Kérdés, hogy az "utana mehet ki a prorgo rozsdara az archiv)" megfogalmazásból mennyi idő az "utána". Ha nem "sok", akkor tároló oldali pillanatkép olcsóbb lehet, ráadásul (sokkal) gyorsabb visszaállással, ha "sok", akkor pedig úgyis várni kell (akár mentő tárolóra - legyen az HDD vagy SSD -, szalagra, felhőre, ...).

Ha a mentés korlátozottan használható (pl mert AD is kuka), akkor eleve nem nagyon játszik a "live" visszaállítás: gyorsabb álló állapotban visszaállítani a VM-et.

hat, ha kuka az ad nem allitunk vissza. install 0-rol es konfig.
tudni kell, mire mikor használható > es akkor el is mondtad a lenyeget :) teszem hozza par10-100 gigas db visszamegy hamar a 25-40-100g-s (akar direkt)linkeken flashrol. nem kell annyira felni tole. ugyanaz a helyzet, mint mikor rebuildel a raided egy diszkcsere utan...
ha pedig eredetileg is halozati storage-rol ment, nincs mirol beszelni kb.

Azt megköszönöm, ha megkeresnéd, tényleg érdekel.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ez volt a rendezvény: https://www.iszt.hu/virtualizacio-es-storage-szabad-szoftver-alapon/

GlusterFS esetén biztosan volt adatvesztés, VM-ben ext4 RO-ra vált, továbbír valamint, ez fólián is szerepelt.

Ceph:

  • kevés szerver esetén nagyon lassú lehet (4-et említett, ők 9-en futtatták), minél több van, annál gyorsabb; mentésből teljes visszaállítás nagyon lassú, de teljes mentés se gyors
  • "20-25 node esetén már képes megborulni magától ha aktívan dolgoznak rajta userek (vm konfig módosítás, klónozás, stb), aminek az eredménye az hogy corosync képes túlterhelni 10G-s hálózatot is"

Azt nem találom, hogy Ceph adatvesztést ki mondta (szerintem valaki mondta).

Az Alpha-Vet akkor 8 hónapja használt Proxmox+Ceph-et, elégedetten. Pillanatképet nem használnak. Főleg Windows Servereket futtatni, 2019 esetén voltak gondjai, 2022-vel nem.

A legérdekesebb a beszélgetős rész volt, talán felvétel is készült, esetleg írj a szervezőknek.

Köszi, írok nekik hátha.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Az SLA elmélet és van a gyakorlat. Én részese voltam olyan 200 milliós (akkor, sok éve) HP EVA (3PAR elődje) storage összeomlásnak, ahol bérelt repülőn küldött a HP ultra specialistát, de game over lett mindennek. Minden redundáns volt! A probléma egy firmware hiba volt, ami olyan kaszkád összeomlást okozott, hogy mire kiderült, már minden diszken összeomlott az fs. 2 óra SLA 4-5 nap állás mire minden visszaállt mentésből.

A HP mérnök a "móka" utáni közös vacsin azt mondta, hogy nem ajánlja a nagyon nagy űber storage megoldásokat, inkább az EVA helyett MSA, mert az közép kategória ugyan, de eladnak több milliót, a csoda rendszerükből meg 10e-t. A nagy tömegnél jobban előjönnek a hibák és kisebb az esélyed a szívásra.

Ez gyakorlat. A pírtologató menedzserek meg csak SLA-t meg seggvédés látnak. Ez van.

Szóval minden el tud romlani, csoda megoldás nincs, de fikázni valamit egy pírhalom mögül, mert azt nem ismerjük, hát... Én megértem a felelősség, meg a gazdasági érveket is, de én nem így vagyok bekötve, ráadásul KKV területem van jelen a cégem, hol sokkal nagyobb az árérzékenység, de fikázni az ilyen megoldásokat az nekem visszatetsző, úgy hogy rendszeres a gigacégeknél is szopás .  
 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Mondjuk pont HP(E) alatt a leggyakoribb a lila képernyő is, legalábbis saját tapasztalat alapján.

A kérdés, hogy mit értesz "minden redundáns" alatt, illetve nyilván vannak kivédhetetlen dolgok, néha nehéz észrevenni vagy akár megkerülni (drága) bizonyos kockázatokat.

Valóban, minden el tud romlani, csoda megoldás valóban nincs, de a kockázat mértéke változó.

Ez gyakorlat. A pírtologató menedzserek meg csak SLA-t meg seggvédés látnak. Ez van.

Nem az üzlet van az informatikáért, hanem fordítva, innen közelítve ez teljesen érthető. Én azt gondolom, ha jó a kapcsolat, akkor megértés is van, üzletileg is érdeke a cégnek. Egy probléma után hiába rúgnak ki egy egyébként megbízható beszállítót, ha helyébe egy kevésbé kompetens kerül (nyilván mindenre van példa, de kár idealizálni a világot vagy az elvárást).

ráadásul KKV területem van jelen a cégem, hol sokkal nagyobb az árérzékenység

A fikázással én sem értek egyet, de abban azért nagy igazság van, hogy az olcsóbb drágább tud lenni. Még annyit tennék hozzá, hogy ez tipikusan fel nem ismert kockázatokkal párosul. Jó neked, ha olyan csapat vagytok, ahol szabadságok stb mellett is mindig garantáltan rendelkezésre áll olyan szakember, aki adott esetben a legnagyobb problémát is meg tudja oldani, ezzel akkor piaci előnyötök van.

Magából a storage-ból is kettő volt replikálva. Csak hát a hiba is replikálva lett.

Igen az olcsó tud drágább lenni, de létezik agyatlan pénzköltés is :) Volt egy estünk ahol a következő ajánlat a miénktől 8x drágább volt. Azt mondták nem hiszik el, hogy működik amit állítunk. Vittünk egy rendszert amit kértek és demóztuk. Erre azt mondták ezt a megoldást nem elég ismert, jelentsen ez bármit, pedig brand eszközök és open megoldások voltak, nulla saját fejlesztéssel és inkább fizettek jó sokat. Ő dolguk. Szvsz trey haverja döntött :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ki beszél itt tákolt rendszerről. Vagy szerinted ez is az?

https://www.ibm.com/products/storage-ceph

Ha korrekt lennél akkor brand storage vs. brand ceph összehasonlítással hozakodnál elő.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Tudnál adni egy indikatív árajánlatot, hogy mennyiért tákolnád össze az általad ideírt buzzword-öket és üzemeltetnéd 2 óra / 6 óra SLA mellett? 

Szép és jó a duma, kár hogy megint kihagytál belőle önkényesen egy csomó kívánalmat a megbízó oldalról, amit nem lehet figyelmen kívül hagyni. Látszik, hogy ilyen géptermi goblin vagy, aki életében nem vett részt még pályázatíráson. Azok tipik ilyenek, hogy összedrótozzák a perpetuum mobile-t, ami sosem fog leállni a fejükben, majd amikor meg igen, akkor megy a pingvinezés. 

trey @ gépház

"trey most azzal jon, hogy o mint sales hogyan tudna tovabbpaszolni egy lepapirozott SLA-t. neki nem celja, hogy ok uzemeltessenek, mindossze osszekotni szeretnek a vevot es a harmadik fel papirozott vallalasat. (igen, direkt sarkitom a kepet, de amiket itt mond az pontosan ez)"

ha a mas faszaval csalanveres helyett dolgoznatok is azt az uzemeltetest meg rendelkezesre allasotok volna, emberekkel, talan ertened a fenti buzzwordoket is :)

lasd meg:
"ugy kell infrat csinalni, hogy ha leall egy vas, akkor kit erdekel, csak egy sarga potty a monitoringban. majd lesz masik."

a pingvinezes pont az, mikor varod a kulsos szagembert, hogy nezegesse az egyebkent 7/24/365-kent eladott megpusztult brand storage-edet.

bocs, de ha a "lelegeztetogeped", amin tenylegesen embereletek mulnak all le 2/6/X orara, akkor van baj.
egy jol megtervezett redundans infra egy eszkozenek csereje meg pont raer NBD vagy egy het mulva is.

Semmilyen ellentmondás nincs itt, szokásos világtalanságod van csak.

Mondasz egy vállalási árat vagy engedjük el azzal, hogy senki sem tudja mennyibe kerül egy ilyen? 

A forumtopikok és hozzászólások alapján a PC ABC jellegű izékből összekukázott Supermicro alaplapotok a "hát, elindult, tehát jó lesz" RAM modullal, a ki tudja milyen tápegységgel + ilyen-olyan vezérlővel + "ezt mondták a fórumban" diszkkel összeáll, mint advanced storage, majd esik-kel, mert egy komponens mégsem volt fasza, rossz esetben összebaszódnak az adatok mert a ZFS háklis erre vagy arra, akkor hogyan fogsz magyarázkodni? 

Tiéd a felelősség, mert te találtad ki, te építetted meg. 

trey @ gépház

kevered a szezont a fazonnal. miert akarsz pc abc-s vasra rakni proxmoxot? :) kicst el vagy tevedve, ugy latom. es meg mindig nem nagyon erted a szoftver es hardver kozti kulonbseget. :)

en olyan infrat rakok neked ossze, ami N db eszkoz kieseset tuleli. utana meg az eszkozre vallal cseregarit a hw beszallito. ha megjott a csere, NBD mehet vissza az infraba, majd felkonfigolom.

nem kell tutujgatni, nem kell 2 oran belul odaszaladni, ossze kell rakni rendesen.

Proxmox clustert össze tudsz rakni "cattle" típusú eszközökből is, szerződésszerűen - azaz a support nem fog elhajtani.
VMWare clustert "pet" típusú (supported, enterprise) eszközökből tudsz szerződésszerűen (supportáltan) összerakni. Ráteszed a dzsunkapc-re, elhajtanak izibe.

CEPH nagyon jó fokmérője az oldschool vs newschool hozzáállásnak. Amelyik cég enterprise vasra teszi a CEPH-et az nem értette meg a lényegét. 

zászló, zászló, szív

Másról beszélünk. Nyilván én se szeretnék (cattle szinten se) közvetlen a vassal foglalkozni.
Arra van a "brand" beszállító. Neki is vannak "entry level" cuccai ami jól szerelhető de nem tud különösebb redundanciát, nem csak a bolti pc-nek.

zászló, zászló, szív

miert ne lehetne redundans/rendes hardver a ceph/zfs/nfs/iscsi/whatever

Én meg azt nem, hogy ha nem tákolt izé van alatta, hanem mondjuk egy HPE DLxxx, akkor miért kellene nekem ez az összes lófasz, amikor van szintén a HPE-től egy MSA2040 vagy akármi mondjuk és viszlát. Minden is támogatja, full feature set-tel. Ja, kivéve a Proxmox  :D :D :D Mert az nem képes (ja, de már majdnem tud) puszta LUN-on snaphot-olni. 

Mi ez a rettegésed brand storage-tól? Akarsz róla beszélni? Vagy azzal próbálod feljebb pozicionálni magad, hogy te SSH-n keresztül ki tudsz adni linuxon 5 ZFS parancsot? Huhh! Ezt akarod plusz tudásnak elsütni nekem, 25 év Linuxszal a hátam mögött? :D

trey @ gépház

Persze, mert még sosem láttam ilyen szoftveresen tákolt adattároló megoldásokat bekullantani. Se nem láttam split brain-es DRBD-t (ja, de, nagyvállalatnál én vakartam ki, amikor a helyi IT, aki telepítette megcsüngött rajta), se nem hallottam maga alá szart Lefthand-ről (ja, de HP tanfolyamon cégnévvel emlegették, hogy hol szarta össze magát), meg összerohadt egyébről ... Minél bonyolultabb, annál több a hibalehetőség. 

trey @ gépház

Neked is az lehet, mert nem nagyon kaptam választ olyan fontos kérdésekre, hogy adott esetben mennyi idő alatt talicskázol le egy ilyen rendszert és mennyiért, valamint mibe fog fájni ez. Nem forintra, hanem mondjuk egy MSA storage, 3 compute node, VMware, Veeam konfiggal összehasonlítva, ami kb. egy minium hasonló környezetben. Ja és ha elindult, utána mennyi lesz a havi ráfordítási igény rendszermérnöki órában.

trey @ gépház

utána mennyi lesz a havi ráfordítási igény rendszermérnöki órában. > 0, amig ki nem doglik a vas. pont ugyanugy, mint az enterspajz szto'ridzsednel. de a diszkcsere nem rendszermernoki feladat...

mennyi idő alatt talicskázol le egy ilyen rendszert > rendszermernokkent en megmondom mi kell hozza, a beszallito talicskazik... a konfigolasat eladhatod 1 napnak, a teszteleset megegynek. de a valosagban semmivel sem tobb, mint bekonfigolni egy vmware-t. halozat meg igyis-ugyis kell...

VMware, Veeam konfiggal összehasonlítva > fogalmam sincs, arrol neked kene prezentalni a szamokat :) te vagy az ugyfeluk.

Jaja, frissíteni az egészet meg a manók fogják. 

a konfigolasat eladhatod 1 napnak, a teszteleset megegynek. de a valosagban semmivel sem tobb, mint bekonfigolni egy vmware-t. halozat meg igyis-ugyis kell...

Jaja, hiszen a Ceph izé pont arról ismert, hogy csak úgy pikk-pakk előáll, pont úgy, mint egy VMFS egy brand storage-on. Túl sok azt ellentmondás ebben a sikersztoriban.

trey @ gépház

Nem, tévedsz. Az a bajom, hogy van egy kulcsrakész, világszinten No.1. rendszer, ami lop, szop, bakot ugrik, ami minden gyártóval elsőosztályú kompatibilitással bír, van HCL-je (lövésed nincs mi az szerintem), support mátrixa, első osztályú dokumentációja, tudástára stb. Ami 2 évtizeden át bizonyított és amivel a mai napig futnak azok, akiknek a kényelem, megbízhatóság és a profizmus kell. Meg van egy több másik, amiben számtalan kérdőjel van. Fele annyi sikeres évvel a háta mögött. 

trey @ gépház

jajaja, de csak valahogy megsem vmware-t rakosgatnak a high performance datacenterbe se. hogy meirt? mert amin elmegy egy linux, oda fel tudod tenni a proxmoxot. a legkisebb kkv-tol kezdve a szazmillio dollaros datacenterig skalazhato. es senkit nem erdekel, ha a 100 node-nol megdoglik kozben 10, bele van kalkulalva, hogy a vas megdogolhet. jahogy erteni kell hozza? :) hat, sajnalom, hogy ujat kell tanulnod oreg fejjel, tenyleg! :)

Ócska duma. Lejjebb leírta az ember, hogy on premise mindenhol megvették a VMware-t miután végigmentek ezeken a validációkon. Megint jössz a süket dumával, a hosting/felhő bohóckodással, ahol a Microsoft is tud 48 órás Exchange Online leállásokat produkálni. Kérlek hagyj a faszságaiddal ... ezekben a környezetekben nem 48 órás, hanem 4 órás leállást sem tűrnek el. Hogy te nem dolgozol ilyen környezetben? Skálázd fel magad, tanulj (főleg felelősség oldalt) és majd lehet, hogy egyszer ilyen közelébe is engednek.

trey @ gépház

jajaja, de csak valahogy megsem vmware-t rakosgatnak a high performance datacenterbe se. hogy meirt? mert amin elmegy egy linux, oda fel tudod tenni a proxmoxot

Szerintem a "high performance" DC-ben nemcsak VMware nincs, de Proxmox sem. 

a legkisebb kkv-tol kezdve a szazmillio dollaros datacenterig skalazhato

Na, kezd érdekes lenni a téma, nálunk pont van ilyen (vagy hát nem ennyire kicsi, ennél valamivel nagyobb), van erre valami esettanulmány Proxmox-ügyben, amit meg lehetne nézni? 

Kíváncsian várom a tapasztalatokat, lehet, hogy 8-ról kellett volna kezdened, hogy a frissítést is ki tudd próbálni, az is az izgalmasabb tevékenységek közé tartozik + az időfaktor sem másodlagos.

A magam részéről a 9.0 most lendületet adott ahhoz, hogy a második otthoni szerveremet is átmigráljam Proxmoxra ingyenes ESXi-ről, ez kevésbé érdekes, mint a Te teszted, az idő nagy része adatcsorgás.

Respect, le a kalappal :)

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

ha a hogyanbol nem tudsz orabecslest csinalni, akkor ott valami problema van. de nem a hogyannal. :)
ha hasznaltal mar barmilyen virtualizaciot, tudod hogy kell kiuriteni egy node-ot. :) ez proxmoxnal is detto ugy megy, mint barhol mashol.
ha van HA, akkor meg annyi sem.
az apt update azert, ugye megy meg? :) (nyugi, van ra gomb is a webfeluleten)

ha a vasat kell poccsolni, ahhoz meg leszel szives megvenni az idrac/ilo/ipmi licenszt. es akkor nem kell odaballagnod a pendra'jjal :)

ha hasznaltal mar barmilyen virtualizaciot, tudod hogy kell kiuriteni egy node-ot. :) ez proxmoxnal is detto ugy megy, mint barhol mashol.

Hja, csak ez egy Lifecycle Manager-nél a clusterben levő összes hostra AUTOMATIKUS :D Kb. egy kattintásra a a cluster-ben levő összes hostot megcsinálja a következők szerint:

  • vm költöztetés másik hostra
  • patch
  • reboot
  • check 
  • visszaköltöztetés

:D

trey @ gépház

"In a real cluster, shared storage or ZFS replication is used, so the VMs can be migrated during operation. This also happens automatically with activated and correctly configured HA.

VMs can also be migrated without shared storage, but then the disks are always copied to the other node via the network."
Hogy egy proxmoxost idezzek szamodra. :)

LOL

Még mindig várom a brand ZFS storage típusát a megadott rendelkezésre-állással. Erre jött, hogy miért nem én építek. Erre most kitáncolsz a a szedett-vedett lófasz mögül :D

en olyan infrat rakok neked ossze, ami N db eszkoz kieseset tuleli.

Még mindig várom ennek a TCO-ját, üzemeltetéssel együtt a fenti SLA paraméterek mellett. De nehogy többe kerüljön a végén mint egy brand storage+VMwarre+3rd party hw support :D :D :D

nem kell tutujgatni, nem kell 2 oran belul odaszaladni, ossze kell rakni rendesen

De. Kell. Ez a megadott feladat, amire megoldást kell szállítanod. 

trey @ gépház

Még mindig várom a brand ZFS storage típusát a megadott rendelkezésre-állással. > nem tudsz a sajat hw-beszallitoid kozul olyat mondani, aki NBD cserel eszkozt? :) meg mindig ott tartunk, h egy vas nem vas...

Még mindig várom ennek a TCO-ját, üzemeltetéssel együtt a fenti SLA paraméterek mellett. De nehogy többe kerüljön a végén mint egy brand storage+VMwarre+3rd party hw support :D :D :D > milyen parameterek? mint mondtam: N db eszkoz kieses. ezt tudom vallalni. N-t majd meghatarozza az ugyfel(igeny), N novekmenye pedig a hw-koltseg novekmenyevel fog jarni. az N-re pedig a hw-beszallito adja a garanciat. ha 2 orat, ket orat, ha X-et, X-et. VMP.

De. Kell. Ez a megadott feladat, amire megoldást kell szállítanod. > latod, itt a problema. rossz helyen keresed a feladatot. ugy kell megepiteni az infrat, hogy ne ezt kelljen csinalni. abbol lesz a rendelkezesre allas. nem a humaneroforrase, aki odaszalad vasat simogatni, hanem az infrastrukturae.

Ásít. Akkor itt válasz nem lesz. Nem lepődök meg. 

ugy kell megepiteni az infrat, hogy ne ezt kelljen csinalni. abbol lesz a rendelkezesre allas. nem a humaneroforrase, aki odaszalad vasat simogatni, hanem az infrastrukturae.

Ez lennél te, de még mindig nem tudjuk, hogy mennyi az annyi. LOL

trey @ gépház

N! :) mit nem ertesz rajta? a hw-beszallito MTBF-jebol egy kis valoszinusegszamitassal kiszamolgathatod, ha nagyon szeretned. de semmi szukseg ra, hiszen egyebkent is olyanra probalod ratenni a tokodet (hwhiba), amire 0 rahatasod van. a beszallito sara, az o dolga, az o vallalasa, a csere is tole jon.
az en dolgom megtervezni es osszerakni, hogy az N. eszkoz kieseseig mukodjon.

tovabbra is azt erzem, hogy te csak a beszallitoid SLA-jat akarod tovabbertekesiteni haszonnal. :) ugy nehez lesz szamodra elmagyarazni, hogyan kellene redundans rendszert tervezni, mert nem az a fokuszod. :)

Jaja, az a magyarázatod (immár a sokadik), hogy tákolt eszközökből építsünk komplett felhőt a megrendelő telephelyén a klasszik IT igényére. LOL 

tovabbra is azt erzem, hogy te csak a beszallitoid SLA-jat akarod tovabbertekesiteni haszonnal. :)

Semmit sem akarok továbbértékesíteni, a te bold állításaid challenge-elem. Eddig sikerrel. :)

trey @ gépház

csak te beszelsz takolt eszkozokrol. :) mert tovabbra sem erted akarod erteni mi a kulonbseg szoftver es hardver kozott. es nem celod a value-add, csak a gyarto SLA-janak tovabbadasa. :)

amit tolsz, a tipikus esete annak, hogy irhatok en barmilyen SLA-t barmire, ha elment az aram, kifogyott az akksi es mar nincs nafta a generatorban sem, es kozben ferobbant az atombomba is a szomszed utcaban. :)

amit en rakok ossze, az de facto jobb, mint a beszallitoi SLA lesz, mert N db eszkoz megdoglese ellen ved. ennyi. ezt kene megertsd vegre.

hogy aztan ezt sales-eskent te hogy nem tudod eladni az ugyfeleidnek, az a te szoc. problemad. :)

akarod erteni mi a kulonbseg szoftver es hardver kozott

LOL, sok gyenge próbálkozással találkoztam itt már, de ilyennel ... :D

amit en rakok ossze, az de facto jobb, mint a beszallitoi SLA lesz, mert N db eszkoz megdoglese ellen ved. ennyi. ezt kene megertsd vegre.

Jaja, épített storage-ra :D :D :D Ceph meg minden izével. 

hogy aztan ezt sales-eskent

Életemben nem voltam IT sales. Ellenben két megyei könyvtárnyi certificate-em van szerver, storage, blade, clustering stb. témákban.

trey @ gépház

ahhoz kepest nem nagyon vagy kepes addresszalni semmit, amit szakmailag irok, kiveve mikor azt mondod, hogy buzzword meg dzsunka (amirol csak te beszelsz itt), meg beszallitoi SLA. :)

ha mar megertetted miert nagyobb az SLA-ja egy redundans clusternek, mint a vasaknak, amikbol epitem, kerlek, akkor gyere vissza. :) mert addig kitorolheted a papirjaiddal. :)

Nem, én a kettős mércéd nem értem. Legyen brand vas a szarod alatt, de ne ugyanattól a gyártótól származó storage, amiben az utolsó csavarig validált és évekig tervezett komponens van, beleértve a firmware-eket is, ahol az utolsó diszk firmware-éi van update és együttműködik a nagy gyártók pl. VMware olyan funkcióival mint a VAAMI, VASA és egyéb ... LOL

ha mar megertetted miert nagyobb az SLA-ja egy redundans clusternek,

Amit te tákoltál össze. Stimmt.

trey @ gépház

nem, tolem ilyet sehol nem lattal leirva :) csak szolok.
szoval mehetsz a kovetkezo papirodert, mert a 30 evesekkel nem rugsz labdaba sajnos.
aztan ha lesz support szerzodesed, a proxmoxos sracok, hidd el, akar ajanlanak majd rendes vasat is hozza, ha szepen kered oket ticketben es magadtol nem megy :)

proxmoxos sracok

Na pont erről tartok. A "proxmoxos srácok" vs. IT nagyvállalat közti különbségtől. Az ilyen megfoghatatlan proxmoxos srácoktól. Ticketing rendszerük van? Vagy ez is ilyen küldj egy levelet, aztán ha el nem kallódik majd foglalkozunk vele, ha pedig a szar beüt a ventilátorba, akkor majd lesz ami lesz ... 

trey @ gépház

Semmi ilyen állítás nem volt. A dzsunka a Supermicro, teletömve ilyen-olyan diszkkel, ilyen-olyan vezérlővel, ZFS-sel, NFS mounttal, hogy legyen egy messziről nézve virt. gép szintű snapshot-olás Proxmoxon, hogy legalább távolról úgy nézzen ki, mint egy VMware. Nem fog, de legalább hunyorítva. 

trey @ gépház

tehat ha dell adja a proxmox infra ala a vasat (amirol pofazok regota, hogy nem csak supermicrobol lehet am azt epiteni), akkor mar jo? :) vagy tovabbra is trollmodban ragadtal? :)
ha a hp-t elo tudod venni jogilag, felteszem a dell-t is elo tudod. innentol nem nagyon maradt masod, azt latom. :)

LUN/LVM-mel? Nem lesz jó. Pont ez a baj, ezt pofázom 2 napja. VMware-nek meg kurva jó. 

Kibaszott Proxmox nem tud LUN/LVM-en snapshotolni. ZFS-sel, NFS-en tud. Min tud még atombiztosan, amit brand szállít és benne van gyári támogatással? 

trey @ gépház

rossz doksit olvasgatsz :) a dellest, tudod, amit mar ketszer linkeltem feled. engedd el a lun/lvm-et ha nem jon be a snapshot-as-volume-chain :) nem arra valo.
ha ez a matrix nem elegit ki, akkor ott problemak vannak. meghozza azzal, hogy nem tudod elengedni az egyetlen altalad ismert megoldast :)

Elolvastam. Mindegyiknek van valami nyűgje. Kis betű, apróbetű, megjegyzés. ZFS fájlrendszer valamin keresztül, mondjuk NFS-en vagy iSCSI-n a legjobb. Mondj egy gyártót, ami ezt neked szállítja. iXsystems (itt tartottam tegnapelőtt). Itthon kb. nincs jelen. Ezt ne hasonlítsd már egy HP-vel :D

trey @ gépház

Te meg nem válaszolsz. Nem olvasod el az általad adott linket. Olvasd el, értsd meg, ha megvan, keress nekem egy brand gyártót, ami hazai support-tal rendelkezik, és ZFS-alapú storage-ot ad.

Nincs ilyen. Erre jött, hogy akkor Elbandi tákol Supermicro alapon. Azon meg én röhögtem. 

Remélhetőleg most már neked is tiszta a kép.

Főleg úgy, hogy egy VMware meglát egy LUN-t, rápetézi a VMFS-t aztán el is felejtetted, hogy ezzel neked dolgod van. Nem 30 féle félig kész/fél feature complete storage type :D Egy, ami működik. Ami stabil. Ami bizonyított. És az összes valamire való vendor eszközét támogatja. Csont nélkül. Na, ez kerül pénzbe.

trey @ gépház

de nem is kell ilyen. olvasd el a dell doksit :) vagy vergodj meg par kort :) nekem ugyan mindegy.

amugy pedig zfs-t nem storage-en, hanem localban szokas hasznalni, replikaval. de majd ha edukaltad magad proxmox infrabol, akkor majd te is rajossz vegre :)
HTH.

Jaja, ez lenne a support is, mi? RTFM Havi 1000 USD-ért.

LOL

Írd le, hogy melyik setup az, ami xxxx brand storage-on, xxxx storgae type-pal hozza ugyanazt a feature set-et és performanciát, amit a VMFS. 

Kettő dolgot kell beírnod.

trey @ gépház

Ja értem. Nem lesz válasz. Pontosan tudom, hogy miért. Mert nem tud ilyen. Tudogat. Ilyeneket. Hunyorítva. Ez nem enterprise, ez KKV. 

Saját dokumentációjuk szerint sem tudnak mindent, nem véletlen a sok megjegyzés ... tanfolyamon elmesélik, hogy mi a megjegyzés?

trey @ gépház

Nem egy vállalati tároló megoldás van, mely NFS-t is tud.

Jó kiindulás konkrét reklám nélkül: https://compatibilityguide.broadcom.com/search?program=san&persona=live…

Ezek közül több is van hazai jelenléttel. Lehet, hogy nem 2 órás reakció idővel, de lásd másik diszkurzust: egyfelől szerintem kérdéses az értelme, másfelől nem mindenki fizeti ki. Valamiből ezek is megélnek itthon.

Nem egy vállalati tároló megoldás van, mely NFS-t is tud.

Csak olyan kéne, ami mögött snapshot képes fájrendszer van. Na itt kezdődnek a problémák. Synology? Btrfs van alatta. Nem az igazi. Qnap? Nem. Netapp WAFL-lal? Alakul csak ágyúval verébre. ZFS? Ja az jó lenne. Nem nagyon van olyan storage, ami ZFS fájlrendszert ad NFS-en keresztül. Az olyan bohóckodások meg, hogy egy virtuális gépnek adom a LUN-t, az meg majd kiajánlja NFS-en ... pls. :D

trey @ gépház

A btrfs-sel mi a baj? Kevesebb overheaddel működik, mint a zfs. Lásd, synology is milyen csekély hardver erőforrással képes hatékony működésre bírni. A zfs alapú ön-snapshotolo backup szervert pont btrfs-re tervezem lecserélni, mert a zfs mohó. Oke butább a btrfs, de a zfs extra szolgáltasait amúgy sem használjuk ki. Pl tavoli replika.

forditva ulsz a lovon. #facepalm

a zfs max a blokkeszkoz a storage-en (de rohadt mindegy, lehet az hwraid is, btrfs, de akar meg dmraid is), az nfs a file alapu shared network storage a proxmox fele... aholis tudsz snapshotolni, de ezt mar a vergodesed elott is leirtam, hogy engedd el az lvm/iscsi lun-t. csak nem nagyon olvasol meg sose' lattal meg ilyet. :)

az egyetlen caveat, hogy nfs-multipath(4.1=<) az igen ritka (hacsak nem te epited a storage-ed), szoval redundans halozati aggregalt linkeket neked kell hozza konfigolnod, amit ha eszkoz-redundansan szeretnel, akkor MLAG-kepes switch is kell.

ezek azok az alapveto infok, amiket a semmirekello proxmoxos sracok is jopenzert elmondanak/bemutatnak neked egy kepzes alkalmaval...

Miért kell olyan fájlrendszer, ami tud pillanatképet (zsarolóvírusok ellen stb nem márt, de amúgy)? NetApp miért ágyúval verébre? Vállalati kell vagy sem?

Ha már bohóckodást említesz, nem is értem, miért írtad le egyáltalán a Qnapot és Synology-t ilyen kontextusban :-)

A performancia összehasonlításban nem tudok nyilatkozni. 

De kár, mert ha megvan az atomstabil tároló, az a kérdéskör jönne ... :D :D :D VMware vs. Proxmox, ahol itt linkelt előadást megnézve hónapokig nyomozták, hogy miért lassú a Windows Server :D :D :D 

Biztos a PokszMoksz srácok nem voltak a toppon a 1000 eur / hós SSH support-tal :D

trey @ gépház

"De kár, mert ha megvan az atomstabil tároló, az a kérdéskör jönne"

Tervben van. Ha van preferált teszt programod, paramétered, add közre, kipróbálom vmware VMFS és proxmox különféle storage megoldásokon futtatott linux VM-en.

"VMware vs. Proxmox, ahol itt linkelt előadást megnézve hónapokig nyomozták, hogy miért lassú a Windows Server"

A konkrét link érdekelne. Mi lett a vége? Általában máshol van a kutya elásva. Annyira nem szar egyik sem, hogy látványos lassulás legyen.

Hát, ha van rá 2 órád, akkor itt a full link, én vettem a fáradságot és anno végignéztem:

Virtualizáció és storage szabad szoftver alapon workshop

A konkrét nyomozgatás, hogy milyen Windows build-del mi nem működik vagy éppen fagy szarrá, mit kell állíthatni stb. az innen:

https://youtu.be/jZb-zR-jZDQ?si=HoWVb-imB3ccAd__&t=8408

Az, hogy "vállalati környezetben, Windows környezetben is el lehet boldogulni ..." az ne legyen már enterprise működés ... a Microsoft támogatást valakinek meg kell oldani (meglepett Pika-arc) ... a Proxmox fórum segít ... 😂

További érdekességek:
 

Proxmox nehézségek, gondok, problémák

 

De, ezeket egyszer már leírtam:

https://hup.hu/cikkek/20240625/video_virtualizacio_es_storage_szabad_sz…

Kommenteltem is egy éve:

https://hup.hu/comment/3076106#comment-3076106

Értelmes válaszok nem jöttek akkor. Most, egy év múlva megint írjam le ugyanezeket? 

trey @ gépház

NetApp miért ágyúval verébre? Vállalati kell vagy sem?

Mert olcsóbb kifizetni a VMware licencet és akkor nem kell semmit sem változtatni a jelenlegin. 

Ha már bohóckodást említesz, nem is értem, miért írtad le egyáltalán a Qnapot és Synology-t ilyen kontextusban :-)

Mert szeretem az összes lehetőséget számba venni. Az itt említett, tákolt ZFS storage mellett egy lépcsővel feljebb van. 

trey @ gépház

Mert olcsóbb kifizetni a VMware licencet és akkor nem kell semmit sem változtatni a jelenlegin.

Igen, ez adott helyzetben nyomós érv, de ez most megint egy új szempont és nem általános technológiai megkötés.

Synology/Qnap több szempontból sem jöhet szóba vállalati környezetbe VM-ek alá. Ellenben - mint azt látjuk - van, aki Ceph-et bevállalja, például mert rendelkezik kellő szakmai kompetenciával, humán erőforrással az elvárt üzemeltetést biztosítani (nyilván biztos olyan is van, aki csak hiszi magáról, de ez technológia független).

Igen és elfogadja, hogy lassabb és adott esetben majd orbitális szopások nála csapódnak le:

Surviving a Ceph cluster outage: the hard way

A másik meg az, hogy belépési küszöbe lehet, hogy drágább, mint egy brand storage-nak ... ja, hogy felette majd olcsóbb lesz? Hol a váltópont?

trey @ gépház

Az egy érdekes kérdés, hogy HCI esetén hol van a bekerülési fordulópont (mikor melyik irányba egyáltalán). Nekem nem annyira szimpatikus, mivel a tárolást és számítást összemosva növeli a tervezési és üzemeltetési komplexitást.

( Elbandi v | 2025. 08. 11., h – 12:25 )

hat ezek szerint ez eeszt nem vmwaren futott, pedig embereletek multak rajta! hat ennyit a konnyen nyilo penztarcakrol... \o/

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

( gyuri23 | 2025. 08. 12., k – 08:26 )

Szerkesztve: 2025. 08. 12., k – 08:31

Mivel szóba kerül kicsit keresgéltem, hogy a Ceph mennyire "sufni" megoldás és mennyire veheti fel a versenyt a "brand" menő stoarage gyártókkal.

Az nyilván két filozófia, hogy kevés prémium vas kontra sok olcsó és nem gondolom, hogy pálcát lehetne törni bármelyik felett, már csak azért sem, mert a gyakorlatban mindkettő működik, ráadásul világ legnagyobb tech cégei inkább a másodikat preferálják.

Szóval ezt találtam:

https://ceph.io/en/community/events/2025/ceph-days-almaden

Két igen érdekes előadás lehetett, sajnos csak a slide-ok vannak fent.

Ceph Operations at scale

In this presentation we will go over DigitalOcean's journey with Ceph as the primary storage backend for Block and Object workloads and how we automate, monitor, alert, and operate

250+ PB, 30.000 OSD (aki nem ismeri a Ceph-et ez 30.000 fizikai disk-et jelent), 1.700 node-on. 

Ez magárt beszél. Azt azért megkérdezném tőlük, hogy van-e backup erre? :) Meg azt is, hogy melyik brand gyártó adna ilyen storage-ra ajánlatot...

A másik:

    9 years of Ceph at Walmart

This talk covers the humble beginnings of Ceph at Walmart aimed to provide reliable, flexible, future-proof storage for our on-premises cloud, and how it has evolved in supporting Walmart's triplet cloud model, challenges that were uncovered operating Ceph at large scale supporting variety of use-cases ranging from latency sensitive databases, eCommerce applications, backups and others.

A Walmart öbb mint 2 millió alkalmazottal és mintegy 680 milliárd dolláros éves bevétellel rendelkezik, tehát vélhetőleg van pénzük bármilyen storage megoldásra.

Szóval mindenki döntse el maga, gagyi-e, hogy a Proxmox a Ceph-et preferálja storage megoldásnak.

Az IT-ben sincs kizárólagos szent igaz út...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Proxmox+Ceph azt egy cégnél 5 node-on 5+ éve 0 eseménnyel. Egy gép megy a Ceph-ről a többi helyi ZFS-ről, a mentés PBS.

A legtöbb helyen nincs még storage sem, szvsz egy átlag KKV-nek a ZFS replika bőven elég. Egyszerűbb, olcsóbb, megbízhatóbb.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Addig állj fél lábon. ;) Csináld te, hozd a számaid. Rosszul ülsz a lovon. A VMware a No.1., a kihívónak kell ezt megkérdőjeleznie. LOL, mintha azt szeretnéd, hogy a profi nehézsúlyú vitathatatlan bajnok a legutolsó putrikat járná kihívókat keresve :D :D :D

trey @ gépház

nalad a no1, mashol meg nem az. ha nem hozol szamokat, akkor csak trollkodsz. :) ugy is lehet. csak minek.
a vmware sanlofasz tud olyan elosztott storage-et adni, olyan redundanciaval mint egy ceph? mert tudod, akkor lesz relevans a performance. :)
en kivancsi vagyok vmware mennyivel jobbabb/gyorsabb ugyanolyan vason, de ahogy latom ezt toled nem fogjuk megtudni :)

nalad a no1

Nem nálam, a világon. 

ha nem hozol szamokat, akkor csak trollkodsz. :)

Mivel ez nem egy tákolt szar, millió egy whitepaper, esettanulmány érhető el, keresztbe-kasba vannak tesztelve a brand eszközökkel. Tudod, ez nem sufnituning. 

a vmware sanlofasz

VMware vSAN-ra gondolsz? Olyan is van.

en kivancsi vagyok vmware mennyivel jobbabb/gyorsabb ugyanolyan vason,

Goto eleje, a te számaid hiányoznak innen.

trey @ gépház

A válasz, hogy nem kell Ferrari a közérbe járáshoz. Szerinted tényleg mindenkinek csak a világ leggyorsabb, legnagyobb, legdrágább rendszere a megfelelő!?

A linkelt videón fingom sincs miről anekdotázik a faszi. Nekem sosem volt gondom a 2019 szerverrel. A KVM Virtio drivert maga a Microsot írja. Igen volt egy pont, ahol az virtio kontroller helyett a sima scsi-t kellet használni, mert már nem volt támogatott a virtio tovább és az scsi-t fejlesztették tovább. Ez le volt dokumentálva, aki nem tud olvasni annak volt gondja.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Te értesz hozzá, mert rá tudtál bootolni egy Proxmox telepítőre, meg ki tudtál adni 4 tákolt debian node-on egy marék Ceph összeállító parancsot. Mindjárt az enterprise-ban is találtad magad! :D :D :D

Amikor szabadságra mész (tudom, te sose) akkor majd másik beugrik a SSH-ba és adjusztálja :D Vagy te, az Adria közepéről egy laptopról :D

trey @ gépház

Ez nyilván jó dolog csak nem számottevő nagyságrend. A "nulla eseménnyel"-nél számomra sokkal többet mondana az hogy x-y disasterből helyreálltunk ennyi-meg-annyi idő alatt nulla (közeli) adatvesztéssel.

Otthon nekem is van Proxmoxom, mentem PBS-sel is meg egy részét restic-kel is. 
Volt már egy-két "esemény" amiből helyre kellett állni, sikerült is, de igazi disaster nem volt.

Az otthoni PBS-em nem is DR-képes (és egyelőre nem is tudom hogyan kéne azzá tenni), de a restic igen.

zászló, zászló, szív

"Sima" Proxmox-al eddig 5 disaster-em volt 12 év alatt (asszem azóta használom). Egyszer sem szoftver hiba, 4 vas eldurranás és egy WannaCry. Sehol nem volt semmilyen probléma a recovery-vel, tök nyugisan ment. Adatvesztés nem volt, amit úgy kell érteni, hogy az ügyfél tisztában volt vele, hogy egy-két óra adatot bukhat. Igazi adatvesztés nem volt, mert ami kiesett, azt pl az ügyfélszolgálat "fejből" újra csinálta, meg a titkárság is a pár cellát az excel-ben. A Ceph-es eddig nem problémázott.

A Proxmox backup eddig nekem 100%-os, pedig összesen nem tudom, mennyiszer kellett élesbe használni, saccra 30-40 gépet kellet disater után visszaraknom. Amióta van PBS szerver még jobb a helyzet, mert a mentés néhány perc, simán mehet a kritikus gépeken naponta többször. A ZFS replica szintén zenész, az is működött mindig.
Egyszer sem kellett a tartalék mentési eljáráshoz nyúlni, pl b2 off-site restic (azt nagyon bírom én is).

Ja és legtöbb helyen no subscription Proxmox van.

PBS-em nem is DR-képes

Ezt, hogy érted?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Áruld el, hogyan befolyásold a vasat, hogy ne romoljon el? Ja és nálad mit jelent a disaster? Még nem romlott el gép a kezed alatt? Te tényleg üzemeltetsz?

Leírtam, egyik sem Proxmox szoftver hiba volt! Vagy a Vmware megvédte a guest gépet a Wannacry-tól?

Valami küldetés nálad, hogy megpróbáld bebizonyítani, minden szar amit nem te mondasz? 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Rendes vas lett volna, akkor downtime még elképzelhető, de adatvesztés? Na ne viccelj ... Egy rendes storage-ban az atyaúristen is redundáns. Milyen adatvesztés? Tipikusan az olyan tákolt szarokon szokott lenni, ahol az össze nem passzoló alkatrészekből hákolt, instabil szar nagyfokú hozzá nem értéssel (emberi hiba) párosul.

trey @ gépház

Ezekkel a terelésekkel nálam semmire sem mész. Majd ha lesznek válaszaid, gyere vissza. Addig meg üzemeltessetek 1-2 óra adatveszéssel, ha az megfelel az ügyfélkörötöknek. Majd egyszer talán felnőtök oda, hogy ez lehet, hogy kevés lesz :D

Adatvesztés nem volt, amit úgy kell érteni, hogy az ügyfél tisztában volt vele, hogy egy-két óra adatot bukhat.

🤷‍♂️

trey @ gépház

Na most akkor dönts el mit kell szidni. Ha Proxmox-ot, akkor logikai hiba amit mondasz, mert nincs köze az az alatta futó vas hibájához. Ez érvelési hiba, ettől a Proxmox nem szar.

Ha meg azt állítod, hogy létezik olyan vas ami garantáltan nem romlik el, akkor vagy trollkodsz, vagy komoly gondok vannak a szellemi képességeiddel.

Mellesleg ezek voltak:

4x HP DL380Gx
1x DELL PowerEdge R730xd

Tudod amikor több száz géphez van közöd 20+ évig akkor bizony előfordul hiba. Ezek szerint rád a gépszám nem vonatkozik, mert azt állítod régóta vagy a szakmában.

Ja és ha tényleg üzemeltetsz, akkor érthetetlen miért nem ismered ezt: https://hu.wikipedia.org/wiki/WannaCry 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Van olyan "disaster" ami elmulasztott karbantartás miatt történik - és persze nálad ilyen nem történHET, ezt tudjuk.
De van olyan disaster is ami abszolút rajtad kívül áll. Betörés, tűz, árvíz, bármi.

Az "igazság pillanata" ekkor jön el: megtörtént a disaster, vajon működik-e a recovery?

A nulla disaster az pont nulla bizonyítékot jelent arra nézve hogy működik a recovery.
Ha volt 5 disaster és mindből felállt komolyabb probléma nélkül - na az már nekem bizonyíték.

Oké, vannak kötelező DR tesztek, bankban dolgozom x éve, pontosan tudom mit érnek ezek a megrendezett tesztek.

zászló, zászló, szív

olyan vmware infraban meg sosevo't, ugye, hogy megdoglott az egesz vas a francba (nem hypervisor fuggo, HTH) es az utso mentest kellett visszaallitani? :)
errol meselj, pls! :)

ugyanis meg mindig ott tartunk, hogy _szerinted_ proxmoxot csak dzsunkaPC-re teszunk, mig vmware-t meg csak atombiztos redundans infrara... :)

olyan vmware infraban meg sosevo't, ugye, hogy megdoglott az egesz vas a francba (nem hypervisor fuggo, HTH) es az utso mentest kellett visszaallitani? :)

Volt ilyenetek? Mesélj! Mi volt?

ugyanis meg mindig ott tartunk, hogy _szerinted_ proxmoxot csak dzsunkaPC-re teszunk, mig vmware-t meg csak atombiztos redundans infrara... :)

Erre vertétek feljebb. Ettől olcsó. 🤷‍♂️ Persze, amikor kiröhögtem, akkor jött a szépítés, hogy de hát fel lehet imádkozni brand vasra is ... hol a HCL? Mire? Hol van mögötte a gyártói support? Ja, az ablakban ... :D

trey @ gépház

A kelleténél több diszk hibára kiáll, szétesik a tömb, mert nem figyeltek a pre-fail jelzésekre. Akkor veszik észre, amikor eltűnik a tömb a VM-ek alól.
Ez több emberi mulasztás, akár spórolás következménye. Ilyen megtörtént a környezetemben.

Itt nem játszik a virtualizációs réteg.

Volt elviselhető adatvesztés, backupból visszaálltak. A diffet meg pótolták újramelóval.

A kelleténél több diszk hibára kiáll, szétesik a tömb, mert nem figyeltek a pre-fail jelzésekre.

Ja, itt a rendes storage játszik, ami előre szól. Szombati:

Event: An error was reported by a disk drive. (disk: channel: x, ID: x, SN: x, enclosure: x, slot: x) (Key,Code,Qual,UEC:x) (CDB:Rd x)(CmdSpc:x, FRU:x, SnsKeySpc:x)(Medium Error, unrecovered read error)

[...]

Additional Information: A disk drive detected a serious error, such as a parity error or disk hardware failure.

Recommended Action: - Replace the disk with one of the same type (SAS SSD, enterprise SAS, or midline SAS) and the same or greater capacity. For continued optimum I/O performance, the replacement disk should have performance that is the same as or better than the one it is replacing.

Mit nem lehet ezen észrevenni? SLA időn belül cserélve lett. 

trey @ gépház

Rendes cucc volt ez is, VRTX, de a mail küldés része ki lett tűzfalazva, rendszeres ellenőrzés nem volt. Monitoring rendszerbe még nem lett bekötve SNMP-n.
Szóval emberi mulasztás, hiába rendes storage. Ezt azért mondom, hogy ahol baj felüti a fejét, nem feltétlen a HW/SW a hibás. Biztos te is látod, mennyi helyen hiányoznak a kontroll folyamatok. Aztán ahogy sikerül. Hát ez így sikerült :)

Ez nem csak rendes storage hanem rendesen bekonfigurált storage, mert elküldi a mailt, te meg megkapod.
Én is csináltam hasonlót itthonra, a sufni-storage-omnak a minden bajáról is szól, ha éppen van.

librenms küldi a mailt és a telegram üzenetet is a telefonomra ha bármi van.
Technológia szempontból ez nem kunszt, az üzemeltetés hozzáállásán tud elbukni.

zászló, zászló, szív

Én is csináltam hasonlót itthonra, a sufni-storage-omnak a minden bajáról is szól, ha éppen van.

Ezek szoktak pont akkor nem működni, amikor éppen kellett volna. 

Ez nem csak rendes storage hanem rendesen bekonfigurált storage, mert elküldi a mailt, te meg megkapod.

Bare minimum, aki nem így üzemeltet, az egy kókler. Az is, aki ilyen levelek vagy egyéb üzenetek helyett ssh-n keresztül nyálazgatja át, hogy megdöglött-e valami vagy sem. Ha éppen el nem felejti. Az nem üzemeltetés, hanem kóklerkedés. Márpedig tákolt eszközöknél ezek mennek. Igen, az is tákolás, ha brand szerverre nem támogatott OS-t teszel és azon alakítasz ki magad által kitalált storage-ot. A nem tákolt az ilyenekről lesz nem tákolt. 

Meg az ilyenektől:

EVENT (12-Aug-2025 16:51): High rate of corrected memory errors, performance may be degraded (Processor 2, DIMM 8).
ACTION: Re-seat the DIMM. If the errors persist, contact support.

Integrated Management Log Severity:CAUTION

Ilyen mélységben te nem monitorozol tákolt szarokon.

trey @ gépház

Értem hogy neked ez a vallásod, nincs ebben semmi meglepő hiszen ebből élsz. Furcsa is lenne ha nem ez lenne.
Nekem nem ez a vallásom, per pillanat csak otthon üzemeltetek, amit otthonra megcsináltam az bőven hozza a SME színvonalat és eddig sosem hagyott cserben.

Ilyen hibát még nem láttam: "re-seat the DIMM" - az én brand szerverem _rendesen_ össze van rakva!

/csak hogy hozzam a trey színvonalat/

zászló, zászló, szív

Sajnos a "tákoltam egy marék szkriptet, ami az első apt-get upgrade után eltört és ezért nem jött levél a disk prefail hibáról, ezért nem reagáltunk, én istenbizony' be szoktam SSH-zni, ha el nem felejtem és végignyálazom a diszkeket, de sajnos szabin voltam, a kolléga meg elfelejtette" bohóckodást nem lehet eladni a piacon. Vagyis el lehet, de én az ügyfél átbaszásából nem kérek. 

Ilyen hibát még nem láttam: "re-seat the DIMM" - az én brand szerverem _rendesen_ össze van rakva!

Ilyet még mi sem, ebből is látszik, hogy ügyfél rendszerén bármi előfordulhat és az a lényeg, ha átvettük üzemeltetésre, akkor mi értesüljünk róla 🤷‍♂️ Lehetett ez akár sugárzás (napkitörés, akármi) hatása is. 

trey @ gépház

A tákolt szaromon az ECC error ugyanúgy SNMP trapet váltana ki mint itt, csakhogy nincsen error.

A tákolt szaromra viszont tudtam az NVME drive-omra plusz két temperature sensor monitoringot tákolni ami gyönyörűen riasztott amikor a szokásosnál két fokkal jobban felmelegedett - mert éppen a szokásosnál több dolga volt.

Aztán emeltem is kézzel a tákolt szar által önállóan megtanult hőmérséklet limiteken.

zászló, zászló, szív

SNMP alapú a megoldás, ami egy uszkve 40 éve tákolt szar (a.k.a. open standard). 
Az már hardverfüggő hogy melyik SNMP MIB-en adja fel az adott vas az adott infót.
Vannak linuxos standard mib-ek de pl. a dell omsa-nak van saját mib-je.

Amelyik éppen van, azt fogja feldolgozni. 

Ha egy "apt-get upgrade" elbaszná - eddig nem baszta el - akkor a hiányzó mib miatt jönne a rinya azonnal és viszonylag egyszerű észrevenni hogy downgradelni kéne.

NVME monitoringra csináltam custom mib-et, apt-get upgrade maximum az nvme-cli -t tudná elbaszni, na ha ez megtörténik arra ugyanúgy jön a rinya. Fejlesztés közben kipróbáltam ezt is.

zászló, zászló, szív

Jaja, tehát te időt basztál el (magyarul: pénzt) arra, hogy kifejleszd kisipari kókány körülmények közt azt, amit meg lehet venni a boltban készen, kitesztelve, támogatva. Itt a támogatás te vagy (meg a SPoF), arra kell vigyázni, hogy az autó el ne üssön.

trey @ gépház

Majd én regélek, mert szemmel láthatóan sosem dolgoztál még KKV céggel. 

Esettanulmány.

30 fős cég szűk 1mrd éves forgalom, relatíve szűk marzs. Bigyókat gyártanak, külföldi forgalommal is. Van gyártás, marketing, backoffice és külker. Őskövület IT lecserélése (1 db SBS szerver + USD disk mentés, SMC router, valami gagyi unmanaged switchek és AP-k!!!).
A keret amit rá tudnak szánni max 10 millió. A váltás után 8-10 helyi szolgáltatásnak kellene hely. A lehető legnagyobb rendelkezésre állást kell kihozni ebből. Nincsenek irreális elvárasaik. A cég 2-3 nap IT szüntet kibír és fél nap bukás nagyjából 10 óra munka nekik (itt végezhetsz egy HA stoarge, kontra 10 munkaóra megtérülési számítást).

Parancsolj, fejből adj egy ajánlatot (csak nagyságrend, természetesen nem kell fillérre), Vmware, meg storage, meg tűzfal, meg hálózat, windows licencek és végpontvédelem. Utána megbeszéljük, hogy a megoldásod mekkora adatvesztést tesz lehetővé. (Én simán adok)

Képzeld el van olyan, hogy az SLA engedélyez adatvesztést. Amik nálam voltak, azok mind a tervezett intervallumon belül voltak. Azért volt annyi, mert erre méreteztük a rendszert.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Nem tudom, hogy ezek hogyan jönnek a példába, amikről itt napok óta beszélgetünk, de ilyen helyeken VMware elő sem fordul. Ezeknek bőven elég egy Hyper-V, úgyis Windowst futtatnak. Minek bonyolítod ezt egy Windowszal nem teljesen problémamentes Proxmoxszal? Tudod, azzal kezdtem, hogy ilyen kalapácsaink vannak ...

LOL

trey @ gépház

Nekem a Proxmox probléma menetes, eddig zéró gondom volt windows guest gépekkel. Talán érteni kell hozzá az a trükk. 

Alapból nem a hyber-v technológiájával van a baj, de a hyper-v sokkal rosszabb választás. Eleve kell AD a működéséhez, meg a kezeléshez kell egy gép. Ezen kívül agyon kell védeni, meg szeparálni, mert a security az a szokásos MS. Na meg mindenhol van linux is, arra meg a Proxmox LXC kb agyonveri a hyper-v-t.
 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Aha, értem. Én B2-re mentek restic-el, szvsz nagyon király cucc, még Windows-on is használom :) Néha "éles tesztelés" miatt onnan állítok vissza, ha ráér amit kérnek. Még sosem volt gondom vele.

Az ügyfeleknek meg van egy saját PBS-em a Victor Hugo utcába pull offsite replikának, amit bérelnek tőlem.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ezt láttad a PBS 4-ről?

Support for S3-compatible object storage

This version introduces native support for S3-compatible object storage as backend for backups. By supporting the S3 API, Proxmox Backup Server enables users to access highly scalable and cost-effective public and private cloud environments for storing backup data. To improve performance and reduce cost, Proxmox Backup Server leverages a local cache and minimizes API calls to the S3 backend by internally retaining frequently used backup metadata and data chunks. While each S3 datastore is exclusively managed by a single Proxmox Backup Server instance, the underlying object storage’s contents remain reusable if the original instance goes offline, ensuring robust disaster recovery capabilities.

Most kezdem tesztelni B2-vel.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

nah. ez jo hir hogy itthon is lehet jol uzemeltetni. ugyfel elegedett, es fizet.

azt a nehany 10-et meg akinek embereleteken mulo rendszer kell, es hajlando kinyitni a penztarcat (pl eeszt nemilyen volt \o/), en szivbaj nelkul atengedem treyeknek, az a 2 milliardot a tobbi mas ezerbol is ossze lehet hozni ;)

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

Szvsz régen rossz ha valaki élete egy számítógépen múlik :D

A legbüszkébb arra vagyok, hogy még sosem mondott fel ügyfél, sőt több barátság is alakult. Viszont váltottunk már prémium üzletházat, giga SLA-val, ultraspecialistával mindenre :) Olyanok is voltak, nagyképű pöcsök :) Emberi oldalon buktak el.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

"Azt azért megkérdezném tőlük, hogy van-e backup erre?"

Ezt a storage-t a DO eladja az ügyfeleinek. Redundancia van, SLA van.
Az az ügyfél dolga hogy legyen backup.

Lehet persze backupot venni a DO-tól is - na itt jön a kérdés hogy a backup az vajon ugyanezen az infrán van vagy másikon? :)
 

zászló, zászló, szív

Ezt írja:

57 Production clusters
8 Staging clusters

Gondolom a mentés is ceph-re megy. Már ha van.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ezt nem mondja így, de szvsz is ez a helyzet.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

250+ PB, 30.000 OSD (aki nem ismeri a Ceph-et ez 30.000 fizikai disk-et jelent), 1.700 node-on. 

Ez magárt beszél. Azt azért megkérdezném tőlük, hogy van-e backup erre? :) Meg azt is, hogy melyik brand gyártó adna ilyen storage-ra ajánlatot...

Erre reagálnék (nem kötözködésként):

  • NetApp AFF C80: Maximum effective capacity 707PB
  • 30.000 lemez: HCI esetén sokkal több lemez kell, mint "egyszerű" dobozban, hiszen akár telephelyen belül is többszörösen kell tükrözni az adatokat, nem elég dobozon belüli paritás X lemezenként (említett NetApp: max 2880 SSD)

A Walmart öbb mint 2 millió alkalmazottal és mintegy 680 milliárd dolláros éves bevétellel rendelkezik, tehát vélhetőleg van pénzük bármilyen storage megoldásra.

Szóval mindenki döntse el maga, gagyi-e, hogy a Proxmox a Ceph-et preferálja storage megoldásnak.

Igen, ebből kifolyólag pedig arra is van valószínűleg pénzük, hogy megfelelő csapatot tartsanak fent 24x7-ben a problémák kezelésére. Ami az ő esetükben simán lehet olcsóbb, mint VMware + bármilyen tároló.

Számos olyan környezet lehet, ahol megfelelő csapat fenntartása sokkal drágább lehet, mint megvenni a VMware-t és hozzá tárolót. Proxmox + tároló is jelentős megtakarítás lehet ehhez képest, a Ceph-et kivesszük a képletből, szerintem jelentősen csökken a komplexitás és kockázat a Proxmox + Ceph-hez képest.

Az IT-ben sincs kizárólagos szent igaz út...

Teljesen egyetértek.

A Ceph is egy technológia mihez érteni kell, nem nagyobb kockázat mint ha nem értesz a Vmware, vagy az adott storage megoldáshoz. A szakértelem  szükségessége szvsz nem lehet a számításban különbség, hogy az egyikhez kell a másikhoz nem.

Tudsz esetleg NetApp árat 30.000 lemezhez? Tényleg kíváncsi lennék.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Hozzátenném, hogy a VMware inkább azért lehet veszélyes, mert látszólag egyszerű és könnyen kezelhető, de emiatt könnyű hülyeséget csinálni (konfigurálni). De ha egyszer beállítod normálisan, onnantól kezdve azért nem egy nagyon bonyolult dolog, főleg alapműveletekre. Napi szinten pedig általában nincs szükség extrém dolgokra.

Ha már NetAppnál vagyunk pont ma jött elő egy egyeztetésen: bizonyos műveletet nem lehet akárkire rábízni. Ellenben egy egyszerűbb kezelésű másik tárolón nincsen ilyen probléma. Persze mindenhez kell valamennyi szakértelem, csak kérdés mennyi és az mennyire elérhető (akár "készen", akár képzéssel).

Másik példa a kicsit korábban Trey által küldött https://blog.noc.grnet.gr/2016/10/18/surviving-a-ceph-cluster-outage-th… eset. Értem én, hogy közel 9 éves és azóta fejlődött a technológia, de például a "we used GDB to step through the crashed OSD boot process" lépésre azért nem alkalmas bármikor bárki. Én azért érzek olyat a levegőben, hogy hasonlóra most is lehet szükség. ProxmoX esetén a Premium támogatás: "Response time: 2 hours*
within a business day". Az osztrákok péntek délután sem szeretnek dolgozni, tehát pont akkor, amikor mondjuk karbantartanál valamit és leginkább problémába futhatsz nem lesz senki a vonal túlsó végén.

30k lemez: remélem te is tudod, hogy ennek a kérdésnek abszolút semmi értelme nincs. 1) 30k lemezt nem árlistából adnak, hanem projekt áron, 2) ugyanarra a kapacitásra NetApp esetén jó eséllyel nincs szükség 30k lemezre, 3) két infrastruktúrát nem lemez ár alapján kell összehasonlítani. Persze könnyen lehet, hogy a 250 PB Ceph infrastruktúra olcsóbb úgy, ahogy van, mint NetApp alapon, elvégre jó eséllyel számoltak is. Abba az irányba ne is menjünk el, hogy a NetApp adott esetben milyen funkciókat biztosít (már csak azért sem, mert az is előfordulhat, hogy a 250PB esetén nincs is rá szükség).

Hát én még olyan technológiát nem láttam, ami hibátlan lenne. A NetApp-nál természetesen nem lemezekkel együtt gondoltam az árat, hanem üresen. A DigitalOcan példánál maradva, ha számolgatunk, egy node-ra durván 18 lemez jön ki. Erre jellemzően a 24-es (disk keret) szerverek jók, pont tegnap kellet egy szerver árat kérnem, poénból megkérdeztem a distrit, hogy ilyen 1700 gépre milyen árat adna :) Nem érné el 7 számjegyet, de számoljunk az egyszerűség kedvéért 1 millióval. Ezt beszorzod 1700-al és kész is vagy :) Dolgoztam olyan webes helyen is, ahol tényleg fontos volt a rendelkezésre állás és gyakorlatilag nem volt pénzügyi plafon. Saját szoftver intézte a load balance-ot. Ott a policy előírta, hogy nem lehet minden gép ugyan olyan, kötelező x gépenként brand-et váltani, elkerülendő egy esetleges firmware hibát. Ott a szerver fogyóeszköz volt, egy vicceskedés után kuka, nem volt hw debug.
Visszatérve a példára, az egyik kedvenc cégem a BackBlaze, magának épít szerver, ami opensource :) letöltheted a terveit annyira, hogy elmehetsz egy lakatos üzembe és megcsináltathatod a keretet :) Szóval ekkora mennyiségnél még ezzel is lehet spórolni. Szvsz el lehetne érni az 500.000-et is egy 1700 node-os rendszernél. A Ceph egyik előnye, hogy nincs vendor lock-in, ami Vmware ominózus áremelős mutatványát látva, nem is kicsi előny.

A hibára visszatérve, amit már írtam, ahol ott voltam, a HP storage (300 disk volt) "megsemmisülés" után, hol kuka lett az összes adat, HA rendunciástól, duplikált atyaúristenestől és 2 órás SLA-stól. Nincs SPOF, haha na persze és a firmware? Ez a Ceph-re is igaz! ? Maga az sw az SPOF. De ott vannak a nagy repcsik, ahol előírás a vezérlésre a 3 számítógép, legalább két gyártótól és legalább 2-féle programnyelv alkalmazása, pont a firmware hibák elkerülésére. Na mégis lezuhannak néha... Utána keresgéltem ilyen esteket, de a brand gyártók nem fogják ezeket az orrodra kötni. Azt is írtam, hogy a bepiált HP mérnök :) nem ajánlotta a a prémium cuccaik :D Az open megoldások viszont a közösség miatt sokkal átláthatóbbak ilyen téren is, sokkal több problémáról fogsz leírást találni. Megjegyzem, hogy ez is előny.

Ne érts félre, nem lehúzom a brand storage megoldásokat, csak nem bírom az arrogáns nagyképű, egy megoldást ismerő és istenítő, minden mást fikázó hittérítőket. Az ilyenek ha az iszlám világba születnek, kiváló öngyilkos merénylő lesz belőlük :D
A világ létszerveződése arra tanít minket, hogy a homogén rendszerek sebezhetőek. A nagy és egyforma, egy hiba, változás, betegség esetén gigantikus károkat szenved. Én biogazdálkodom hobbiból, aminek a lényege a sokszínűség, az, hogy heterogén. Addig jó nekünk amíg választhatunk, mert azt már ismerjük, hogy mi történik hegylakó effektus után :) ahol csak egy maradhat :) tudjuk mi lesz a vége, 10x áremelés :D

Ja és a Proxmox szerintem sincs egy szinten a Vmware-vel, ezt sosem mondtam, de ez nem egy minőség jelző. Maga a gyártó 7/24 support-ra 3party cégeket ajánl, amik vannak is, de nem kevés hely van, ahol ez nem igény.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Közel 30 éve Linuxozom, alapvetően technológiai embernek gondolom magamat, szeretem az érdekes megoldásokat, ugyanakkor jó ideje vállalkozom is, aminek része egy papír vállalásokkal, amit alá kell írni. Ez egy üzlet, az ügyfél is pénzt keres, nem pedig a világot szeretné megváltani.

Üzleti alapon is van HCI, nekem az sem szimpatikus, de mindenki azt használ, amit akar, jónak lát a céljai teljesítéséhez.

Remélem nem engem gondolsz arrogáns nagyképűnek, akkor igyekszem a jövőben másként fogalmazni, Debian Linuxot is használunk adott esetben, amihez nincs gyártói támogatás, de üzletileg a Ceph-et jelenleg kockázatosnak érzem: túl sok minden múlik rajta. Olvastam a Proxmox ajánlását, hogy keress partnert, aki megfelelő támogatást tud adni, de azért lássuk be, ez nem annyira egyszerű feladat és egy ilyen cég jó eséllyel nem lesz olcsó. Az sem segít különösebben, ha jó pénzért más szív napokat a helyreállítással (egy ponton nyilván felmerülhet, hogy vesszen az adat, mert RTO is van, és akkor újratelepít, de akkor ezt is számolni/tervezni kell).

Jelenleg csak lightosan Proxmoxozunk, valószínűleg változni fog a jövőben, de akkor sem Ceph-fel, hanem lokális lemezen vagy normál tárolóval, ha olyan rendelkezésre állásra van igény (lokálisan tárolt VM-ekkel is bőven lehet olyan szolgáltatást nyújtani, ami azért nagyon sok cégnek bőven elegendő). A helyi fájlrendszerben kis kockázatot érzek, a virtuális lemezek kezelési is kisebb kockázat + adott esetben jó eséllyel 1-1 VM-re korlátozódik, nem pedig teljes infrastruktúrára. De akár nagyobb/kisebb felhőbe is lehet vinni szolgáltatásokat, előfordulhat, hogy az a legracionálisabb, főleg ha kis cégnek kell nagy rendelkezésre állás és erőforrást is nehéz tervezni.

Erre írtam korábban, ha Te bevállalod a Ceph-t és olcsóbb leszel ugyanarra az elvárásra, akkor piaci előnyöd van. De az is benne van, hogy rosszul méred fel és belefutsz a falba, akkor kőkemény szívás van. Elvégre a vállalkozás is kockázatról is szól, nemcsak az üzemeltetés... :-)

Dehogy téged gondollak, ne viccelj már :) Majd aki akarja magára veszi :) 

Én sem vagyok Ceph specialista és csak egy helyen használunk, ott is egy darab gépre és a Proxmox integrált megoldásával, amire elvileg van support. Ha gond lenne vele, akkor azonnal mehet a helyi lemezre. Jeleztük az ügyfélnek, hogy mi is kockázat vagyunk, elfogadta. Egészen értelmes vezetők vannak, belement, mert nem adtunk magas árat, cserébe, hogy beletanuljunk. Valahol el kell kezdeni :) Sajnos a teszt környezet sosem olyan mint az éles. Ja és ezt sokan csinálják ezt úgy, hogy nem szólnak...
Azon kívül az összes helyen a ZFS replikát használjuk aminek a 15 perces ideje már egy egészen korrekt "védelem". Ugyan nem automata és a reakcióval együtt lehet egy óra is míg átállsz, de lespórolod a teljes HA infrát árastól és üzemeltetési szívásostól.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Pont azért, mert nem bonyolult. A Proxmox kinyalja a seggem, feltolja a kliensekre, bekonfigurálja és ad egy integrált GUI-t.

Kapsz egy 5 node-os HA cluster-t, ahol a storage és host vm szerverek ugyan azok. Ja és több éve gond nélkül megy és a vas is elég alá.

Az egész olcsóbb mint egy brand storage megoldás. Szóval fikázódhatsz, de nekem az inkább sárga irigységnek tűnik :D

Ja tudom, te majom vagy, aki csak banánt fogad el, mint ahogy már kifejtetted párszor :) és ha hiba van, csinálja meg más, mert érteni is kéne hozzá amit csinálsz, de az már sok egy banánért :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Úgy vélem rajtad kívül mindenki megértette, hogy mit írtam...

:) 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Még valami: ha megnézed a HP(E)-t, elég nagy változások voltak a tároló termékeiben az elmúlt 10-15 évben, valószínűleg nem hiába, kérdés melyik felvásárlásuk lesz tartós. Ennek pont ellenkező példája a NetApp, a DATA ONTAP-ot 1992 óta "hegesztik". Nyilván ennek is megvan a maga hátránya akár 30+ éves koncok cipelésével, lehet is vele szembesülni, nem tagadom. Érdekességként BSD alapú.

Nyilván vannak más régebbi motorosok, nemcsak a HPE vásárol, újabbak is vannak, csak pont érdekes a kontraszt a két említett cég között.

Egyébként kár, hogy redundáns tárolót nem igazán lehet nyílt forrás alapon csinálni, mivel hardver is kell hozzá.

Illetve Walmart esetén az a 8 staging cluster valószínűleg a Ceph tesztelésére is van, a költségekbe azt is bele kell számolni (nyilván máshol is kell tesztrendszer, amit szintén bele kell számolni). Gondolom hazai üzleti környezetben hasonlóra (Ceph teszt környezet) korlátozottan van lehetőség, pláne éleshez minél hasonlóbb hardvereken.

amiket mondasz az brand hw/sw stackre is ugyanigy igaz.
az van, hogy ahol nagyban jatszanak (lasd megborulos linked, ahol BTW nem volt adatvesztes sem), ott van ra szaki. sot, van kulsos szaki is, akinek szolsz ha bajod van (akar ceph fejleszto).
ott is a sztori lenyege az volt (szamomra), hogy volt valami halozati gebaszuk, meg egy csomo diszk hibajuk, abbol jott az egesz. kidebugoltak, eldobtak par ures journalt es viola, helyrejott.
igen, gdb-ben kell megnezni mihez nyulkal a sw amikor elhal. nem raketatudomany az sem, aki komolyabban uzemeltetett mar szoftvert linuoxn, ilyeneken nem lepodik meg.
ha mindez egy brand storage-en tortenik, akkor meg megy a pingvinezes, kijon egy szaki X ido utan es a vege sokszor az, hogy hol a backup... latott mar sokmindenki ilyet az elmult 20 evben, akar itt a hupon is. :)

akkor uzemeltetsz jol, ha betartod az alapszabalyt, hogy nem az a kerdes megdoglik-e a vas meg a szoftver, hanem, hogy mikor. :) akkor is, ha dell/hp/ibm(najo, toluk tudsz venni foldrenges-allo megoldast is, de a hupperek ugyfelei - jellemzoen - nem az a liga, es nem oda keresunk proxmoxot alternativakent :))

en azt is megertem, hogy valakinel az az SLA, hogy szombaton ket ora alatt odaszaladok a diszkkel, de nalam az SLA ott kezdodik, hogy kit erdekel, hogy kidoglott, majd lesz csere, nem all meg a vilag. :) (es nem, nem vallalunk tul, ha az upstream hetvenketorat mond [netszolgaltatok, szevasztok], akkor en sem mondok huszonnegyet... minden masra ott a biztositas intezmenye, mert a kiesett termelesert sem fog a szolgaltato karteriteni senkit... akarmennyire is buzog trey az "eloveszem jogilag"-gal, sot, van az a szitu amire mar a biztosito is csak felteszi a kezet.)

a proxmoxos sracoknal is azert NBD van, mert ok nem tudnak (akarnak/fognak) azzal mit kezdeni, hogy neked pentek ejszaka ledoglott az egyszem storage-ed. ok akkor tudnak segiteni, ha van vas, amire bemennek SSH-n, mert olyan hiba jott elo a hypervisoron/clusteren, amivel te mar nem boldogulsz/nem ertesz annyira hozza. :)

ott van ra szaki. sot, van kulsos szaki is, akinek szolsz ha bajod van (akar ceph fejleszto).
ott is a sztori lenyege az volt (szamomra), hogy volt valami halozati gebaszuk, meg egy csomo diszk hibajuk, abbol jott az egesz. kidebugoltak, eldobtak par ures journalt es viola, helyrejott.
igen, gdb-ben kell megnezni mihez nyulkal a sw amikor elhal. nem raketatudomany

:D :D :D 

Majdnem beszartam a röhögéstől ... :D 

trey @ gépház

Hoztam másikat, Duke Egyetem tákolgatta a Ceph szarát, adatkorrupció és egy hetes kiesés lett a vége:

Ceph Outage on /cwork

[...]

but due to a bug in Ceph we were able to add it. [...] This has led to a catastrophic metadata pool corruption of the /cwork volume resulting from fragmenting the root directory fragmentation on /cwork. The /cwork directory will be unavailable until a full rebuild of all of the metadata is completed – which could last for more than a week.

[...]

The Ceph development team will be putting out a patch to prevent this issue

Enterspájz tekinolódzsíá!

(szóljatok, ha jöhet a következő!) 

trey @ gépház

es? volt backup? :) ha egy het kellett, hogy eszrevegyek, hol volt a monitoring? :) lehet barmit szarul csinalni. :)
jabocs, nem egy het az adatvesztes - ha volt egyaltalan, nekem nem ugy tunik, csak sok a fos es annyi ido a rebuild. hat, istenem. :)

ugye, nem szoktal brand storage-et frissiteni? nem szokott lenni bugfix benne? ugye? :)

amugymeg elbasztak, nem vedte meg oket a hulyesegtol a rendszer? haaat, szarugy :) udv a #power of root vilagaban
tenyleg, unfortunately? :D LOL
"Unfortunately, we did so on the root file system / we had not created a subvolume for that mount point" - " We should not have been able to enable directory fragmentation on the root file system"

step 1 : read the documentation

Nekem magyarázhatod a bizonyítványt napestig, egy profi cucc az emberi hibát is minimalizálja. 

ugye, nem szoktal brand storage-et frissiteni? nem szokott lenni bugfix benne? ugye? :)

Hát, adatvesztéses, egy hétre leállásos nem nagyon. Arra van a support, hogy ezt megoldja időre. Meg is jöttünk. 

trey @ gépház

egy profi cucc az emberi hibát is minimalizálja. > be is lett kuldve a bugreport/lett patch, miutan kokanymesterek elkurtak...

Hát, adatvesztéses, egy hétre leállásos nem nagyon. > ? mikoze ennek ahhoz, hogy szokott jonni bugfix vagy sem /o\

Arra van a support, hogy ezt megoldja időre. > ok is megoldottak, a supporton az nem mulik, hogy a rebuild egy hetig tart. ott mar csak progress bar nezegetesrol beszelunk.

"We did that but were too impatient and did not let it finish before we started using the filesystem again." > gratulalok! :D

"My memory of events and what we did gets a bit hazy here." > nem bebaszva kene uzemeltetni a storage-et? :D idaig olvastam.

vedd eszre, hogy ezek a sztorik balfasz uzemeltetes eredmenyei. mehetnek a szakis szegyenfalra...

nem.
le van irva, hogy olyat nem csinalunk.
ok meg megcsinaltak.
ezek utan kerult be a patch.

ahogy mar a Linux se a regi, es nem tudsz eltolni rendesen egy rf -r /-t se :(

root@dorsy:~# rm -r /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

igy akkor mar a linux is enterspajz? :D 

Ilyet bármire lehet, 20 sec google:

https://blocksandfiles.com/2020/10/26/israel-time-change-knocks-out-loc…

Enterspájz tekinolódzsíá!

https://www.reddit.com/r/sysadmin/comments/vrzgio/struggling_with_3par_…

Enterspájz tekinolódzsíá!

Szánalmas

https://a.te.ervelesi.hibad.hu/mazsolazgatas

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Oké, csak akkor ne mond, hogy értesz hozzá. Ha a pénzkereséshez értenél, akkor meg magával a pénzzel foglalkoznál.

Mit is csinálsz te valójában?

:D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Akkor mesélj Andersen, mi hová való :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

A gyakorlati részeknél vagy kapitulálsz, vagy hülyeségeket beszélsz. Érv zéró. Ki is itt a troll?

Ja és kihagytam, hogy mindent fikázol és személyeskedsz. Tipikus értelmiségi viselkedés :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

A gyakorlati részek lejjebb vannak, ahol csillogtattál volna, tudod, ahol az összeborult Ceph szarok vannak, de sunnyatottál. Volt egy csomó kérdésem, amit kikerültetek, válaszok azóta sincsenek. 

Tipikus értelmiségi viselkedés :D

Kikérem magamnak. 

trey @ gépház

Tán ideget szúrtam?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

https://forums.veeam.com/vmware-vsphere-f24/data-loss-bug-instant-vm-re…

de a viiiiimmindentolmegviiiiid!!!!11 :D

ha mar mazsolazgatsz, pls, mazsolazgass a tuloldalrol is. :) merthogy boven van mibol.

felkeszul: az enterspajz hwraidbol helyi majmok altal kihuzott rossz lemezek esetei.

az a baj, hogy emberi mulasztasokbol meg hozzanemertesbol mazsolazgatsz es utana probalod XY megoldas szarsagakent beallitani. :) de mindenki mas helikopter! :) es a vmware-hez meg NetaAPP-hoz mindenki IS ert. :)

Huh, mert meséld már el, hogy milyen nagy szakértelem kell a Proxmox meg a Ceph-hez? Mi ez a magic, amit csak te tudsz? LOL. 

Csávó a tanyán megugorja a szintet LOL 

Válaszok még nem jöttek, hogy amíg túrod a Ceph bugot, azt ki fizeti, hiszen te vagy a szállító. Ha én Veeam bugot túrok, azt én pontosan tudom, hogy ki fizeti. 

felkeszul: az enterspajz hwraidbol helyi majmok altal kihuzott rossz lemezek esetei.

Hát, ezért nem majmokat kell tartani a hiedelmeitekkel ellentétben :D

trey @ gépház

itt csak te nem ertesz. hozza. ahogy azt sem erted mi vezetett oda, hogy gdb-vel kellett turkaljak a cephet, hogy lassak melyik ures mappak miatt allt meg.

es a supportod lehet idaig sem fog eljutni, mert adatra nincsen gari.
hany ilyet lattunk/hallotunk mar brand storage eseten, hogy kiment a szaki es azt monda, hogy ja, ez a firmware bugos, akkor hol a mentes? itt a hupon is.

en progress bar nezegetesrol beszeltem. egyiknel sem kell nezegetni. ebben semmi kulonbseg nincsen.

Jaja, annyira nem értek én hozzá, hogy összeborult kétszer Európa legnagyobb kutatóintézetében kétszer, meg két egyetemen. Mert én nem értek hozzá. :D :D :D Egyre kínosabb ez itt, de az én hibám, minek állok le tesztpilótákkal beszélgetni enterprise megoldásokról ... 

trey @ gépház

nem vallalok be. masik musort nezel. ahogyan dzsunkaPC-bol sem kezdek SLA-t takolni. meg mindig a sajat fejedben levo kepzelgeseket tolod... akar fel is tunhetne vegre :) csakhat mit var az ember egy bigott trolltol :)
hint:  itt te vagy az, aki proxmoxot meg ceph-et probal megszakerteni/fikazni, pl. ugy, hogy a dokumentacio elso kiemelt pontjaba utkozo elkurassal peldalozik :D

mi a kovetkezo? az rm -rf /* megette a gepemet? :D

N

ha figyeltel volna... :) en - veled ellentetben - nem vallalok mas helyett semmit es nem verem mas faszaval sem a csalant.

azt vallalom, hogy ha epitek egy infrat, ott X diszk/node/halozati eszkoz kiesese sem fatalis.
ha vissza kell allni, azonnal indul a szolgaltatas.
ha megkotlik a switch, az eger elragja az optikat, nem tortent semmi se.
minden megvan tobb helyen, par perces replika idovel.

olyat nem vallalok, hogy menni fog, ha nincs aram, leesik az atom, vagy, hogy egy vas soha nem megy tonkre. mert nem rajtam mulik. majd a hw gyartoja/beszallito (including UPS, aggregator, internet...) vallal amit tud/akar. VMP.

ennyike.

mit szeretnel tudni, hogy hany milliard az ugyfelkor eves adozott eredmenye? ket szamjegyu

azt szeretned tudni osszvissz hany vm ala terveztem mar infrat? negy szamjegyu

es nem kell lovoldoznod, hiszen amit en csinalok, miszerint tobbek kozt redundans VM infrat tervezek, az szamodra csak bohockodas meg dzsunkaPC az ABC-bol. :) te maradj csak a szombaton diszkcsere vonalon. :)

te maradj csak a szombaton diszkcsere vonalon. :)

Ja, vagy ha a kolléga elmesélné, hogy a hozzád hasonló nagyarcú felpakolt egyszer egy Proxmox környezetet az egyik adatközpontban a HP c7000 blade-einkre, azon elindította a szolgáltatást, majd hajnalban jött a telefon, hogy összeomlott az egész, a kolléga, akinek semmi köze se volt hozzá, fusson gyorsan, mert a csávó távolról nem éri el a szarát és segíteni kellene neki ... azóta is megy anekdota szinten nálunk. Cégnév is van, persze :D :D :D

Volt ez vagy 10 éve is már ... :D :D :D

trey @ gépház

Itt azért bőven kevered a dolgokat. Egy lemezhiba és Ceph összeborulás között én sok lényegi különbséget érzek.

Az, hogy a konkrét esetben nem volt adatvesztés, az nem egy determinisztikus kimenet volt, ha elolvasod, azért átjött, hogy vettek pelenkát.

Gdb: nem mindegy, hogy gebasz esetén van kellő Linuxos szakértelmed a háznál, akár szombat éjjel 2-kor vagy csak olyan van, aki távkapcsolaton be tudja engedni a gyártót. Utóbbi olcsóbb, könnyebben elérhető. Hozzátéve, hogy a tapasztalat korral jön, az éjjeli munkakedv korral megy.

A Proxmoxos srácoknál valószínűleg azért olyan támogatás van, mert ezt tudják bevállalni. Ebből is látszik, hogy nem egyszerű műfaj. Nyilván akkor tudnak segíteni, ha be tudnak menni SSH-val, ez nem is volt kérdés, ebből is látszik, hogy összemosod a dolgokat. Nyilván egy gyártó is akkor tud távolról segíteni, ha eléri a vasat (például VMware).

olyan hiba jott elo a hypervisoron/clusteren, amivel te mar nem boldogulsz/nem ertesz annyira hozza.

Vagy ők gyorsabban megoldják/megmondják, elvégre ezért vannak.

Itt azért bőven kevered a dolgokat. Egy lemezhiba és Ceph összeborulás között én sok lényegi különbséget érzek. > akkor bizony nem olvastad el eleg figyelmesen a sztorit. (es nemcsak lemezhiba volt/derult ki) :)

Az, hogy a konkrét esetben nem volt adatvesztés > az csak egy teny, haladjunk tovabb.

Gdb: nem mindegy, hogy gebasz esetén van kellő Linuxos szakértelmed a háznál > errol beszelunk, igen.

akár szombat éjjel 2-kor > vanazapenz.

vagy csak olyan van, aki távkapcsolaton be tudja engedni a gyártót. > leirtam, aki nagyban csinalja, ott lesz szaki is. vagy valamit szarul csinal es hagyja abba.

A Proxmoxos srácoknál valószínűleg azért olyan támogatás van, mert ezt tudják bevállalni. > bocs, de fentebb is ideztem, hogy a kedves vmware (broadcom) is csak NBD-t vallal. ha ennel tobb kell, akkor van sajat embered. :) #udvazenterpriseban

elvégre ezért vannak. > pontosan. nem dolguk eletben tartani a vasakat. treynek sem a netapp vitte ki a diszket szombaton ket oran belul. ertjuk itt mindannyian szerintem, hogy mi a dorges. :)

"vanazapenz": csak kérdés, hogy ki fizeti meg, érdemes-e egyáltalán kifizetni, van-e egyszerűbb/olcsóbb megoldás.

"aki nagyban csinalja": igen, ezt is írtam, de van egy olyan érzésem, hogy nem mindenki csinálja nagyban, mégis bevállalja; például az itt látott esetek sem feltétlenül olyanok, amik tervezet szerint mentek (néhány napos állás ritkán az a kategória).

VMware Production Support: https://docs.broadcom.com/doc/vmware-production-support-datasheet: Severity 1 within 30 minutes, 24 hrs/day, 7 days/week

No Document Found :)
en csak NBD web/phone supportot talaltam.

de ugye trey alma az on-prem, vajon ki ki is jonnek? mert ha nem, akkor... goto 10 :)

de a legjobb, hogy itt:
https://docs.broadcom.com/doc/vmware-production-support-datasheet

A linkek ide: Please refer to VMware Severity Definitions and Response Times
es ide: Support by Product Matrix

a nagy budos 404-be visznek. gondolom mert enterprise :)

pedig errol pofaztal. :)
az en szintemen/megoldasaimmal, lasd mit vallalok fentebb, a szombaton ket oran belul diszkekkel szaladgalas, ne haragudj, de bohockodas kategoria... es nem azon mulik az SLA.
amig ezen a szinten nem tudsz tullendulni, addig kar a gozert.

Jaja, szupi, tehát akkor vegyük meg a Proxmox-ot (általam linkelt videóban szintén szerepel, hogy szépen emelgetik az árát), vagyis akkor brand vas, fizetős proxmox ... foglalkozós-tákolgatós storage, ilyen-olyan backup szoftver (idő = pénz) és lassan ki is jött a VMware ára :D

trey @ gépház

Szerintem beszélj valakivel, aki érti az üzleti oldalt is, hogy melyik lesz olcsóbb a végén, ha fel kell venned egy plusz mérnököt, annak egy évre vetített szuperbruttója, vagy kifizettetni a különbséget az ügyféllel :D :D :D

Hagyjad már ezt az "érteni hozzá"' balfaszságot, most tényleg nekem akarod elmagyarázni, hogy mennyi egy Proxmox-ot telepíteni? Lehet, hogy előbb láttunk élesben (nem)működni Proxmox-ot, mint te :D

trey @ gépház

az, hogy valamit lattal mar, meg elolvastad a hirt, hogy van uj verzio, az nem hozzaertes. a hozzaertes az, amikor tudsz belole teljes erteku infrat tervezni, uzemeltetni.

en nem ertek a vmware-hez es sajsnos/halistennek nem is kell ertsek hozza. nem is villogok vele, hogy lattam mar olyat. pedig volt, hogy muszajbol nekem kellett megnyomkodni meg felkonfigolni. /o\

Olyan szépen kerülgeted a számodra kellemetlen aspektusokat. :D

a hozzaertes az, amikor tudsz belole teljes erteku infrat tervezni, uzemeltetni

Kemény dió lehet ez, belátom. 25 év Linux tapasztalattal meg aztán biztos, hogy megugorhatatlan. Ugyanaz az elv, mint a VMware, csak gagyiban.

trey @ gépház

Jaja, rohanok, meghozta a kedvem az, hogy összedőlt a Ceph a

  • CERN-nél (kétszer)
  • a Duke Egyetemen
  • az Edinburgh Egyetemen
  • ...

ennyi tanult ember nem értett hozzá, hát én hogy tudnám ésszel felérni azt a nagy csodát, hogy akár 4 hoston is futhat! Ne zavarjon, hogy már 14 éve annak, hogy ilyen koncepciókkal dolgoztam, majd tanítsd pls. :D :D :D

https://hup.hu/cikkek/20111109/ebben_is_van_linux_hp_lefthand_p4000_vir…

(Az meg egy másik sztori lesz, amikor éppen a Terminator x részt néztem egy vasárnap a moziban és felhívtak, hogy menjek segíteni egy ilyenhez, mert egy komplett céghálózat áll és ki kell vakarni a szarból. Azóta is jön nekem valaki egy jeggyel a filmre, mert az utolsó 15 percet nem láttam emiatt. Mint kiderült, annyi történt csak, hogy a x napja nem volt újraindítva a rendszer és az összes node-on futott az fsck ... még jó, hogy én már láttam Linuxot ... Muha ... )

trey @ gépház

ha nem akarsz ceph-elni, nem kell. :)
ha vasarnap is akarsz filmezes helyett dolgozni, akkor pedig ne epits redundans infrat, meg inditsd ujra te is az osszes node-od egyszerre... mint szokas mondani, hulyeseg ellen nincs orvossag. csak epp ennek megint semmi koze a proxmoxhoz vagy annak minosegehez...

nem. inkabb te vagy az, hogy azt feltetelezed rolam, hogy en azt feltetelezem, hogy te valamit meg tudsz/nem tudsz oldalni linux alatt... lofaszt, baratom, azt. itt te vagy, aki kepzelegsz. azzal kene vitazz, amit irok, nem azzal, amit gondolsz a kis fejedben. :)

arrol viszont tettel a threadben mar tanubizonysagot, hogy tapasztalatod az nicsen a proxmox storage alrendszererol vagy hogy hogyan kellene belole reziliens infrat epiteni...
az ilyenekbol lesz az, hogy vasarnap filmezes helyett, meg szombaton ket oran belul... :)

Kicsit kezdesz belezavarodni, biztos az ideg vagy nem tudom ... 

Azt sem értetted meg mit írtam. Vasárnap én szívességet tettem másnak, akinek szakértelmemre volt szüksége. Semmi közöm nem volt a rendszerhez. Segíteni mentem. Hja, biztos tudták, hogy hol keressék a hozzáértőt :D 

trey @ gépház

Azért No Document Found, mert a portál a ":"-ot hozzátette az URL-hez. Elég rosszak a kilátások egy probléma esetén, ha csak vakon kattintgatsz és elsiklasz a lényeges apróságok felett... Ebből nem áll helyre egy Ceph cluster.

404-be visznek: mióta Broadcom a VMware, vannak hasonló jellegű problémák (és egyebek is, nem vitatom). Mindenesetre a lényeget nem sikerült megértened, a 404 ellenére én azért jó esélyt látok arra, hogy probléma esetén lesz, aki segít, nem NBD.

en nem barmit elhiszek, csak a dokument 404...
mióta Broadcom a VMware, vannak hasonló jellegű problémák > haat, ha mar itt elbuknak, akkor mit gondoljon a "messzirol jott ember"? :)

csak ne egy kiszervezett only indiai dialektussal beszelo "angol" legyen egy telefonvegen, azokat nem szeretem. nehez veluk megertetni magad. :) (nem, nem rasszizmus, csak a kommunikacios nehezsegek...)

jahogy az a jobb, hogy a vmware nem rejti veka ala, hanem kiteszi a frontvonalra, hogy balfasz? vagy mi is a mondando?

en nem tudok olyanrol, aki sosem balfasz, incuding myself. csak lehet nem a nyito support doksit kene elbalfaszkodni, amit a leendo ugyfel elso guglizasra talal meg... :)

az viszont marhara nem mindegy hol es mikor vagy balfasz. vagy mit teszel az ellen, hogy balfaszsag(meg hwhiba...)vedett  legyen amit csinalsz. akar sajatod ellen is. ha mar a hardverhibat deklaraltuk, hogy lesz. csak a mikor a kerdes.

A mondandó még mindig az, hogy ki viseli a kockázatot és költséget.

Kíváncsi lennék, hányan döntenek a VMware ellenében valami más mellett azért, mert ott 404 van. Úgy előttem van, mikor a döntéshozónak tekernek a kerekei: 500k USD csak a licencekre, fasza, de az a 404 ne lenne... Na jó, Proxmox.

regen rossz, ha eloszor azt dontik el mennyit koltsenek licenszre. :)
ugy megy az inkabb, hogy megkeresnek 2-3 rendszerintegratort, aki mond ra arat. abban meg lesz valamilyen licensz. ha vmware, akkor az. ha hyperv, akkor az, ha proxmox, akkor meg az. az ugyfel ezt a reszt egyreszt nem erti, masreszt le se... :)

viszont ha valasztani kell egy olyan ceg kozt, akinel rendben van a licenszinfo, atlathato a weblap, meg nincs kodosites, nincs 404, meg egy olyan kozt, akinel ez van, te melyiket valasztod? :)

tudod, ertem en a jo bornak nem kell ceger-t, de azert no. erezzuk, hogy nem veletlen kapalozik a sok rendszerintegrator, hogy merre is menjen tovabb a vmware utan, es a kerdes, hogy van-e barkinel elesben a proxmoxhoz veeam backup tapasztalat. :)

erezzuk

De kik vagytok ez a misztikus ti? Mert folyamat többes számban beszélsz. Kik vagytok "ti"? 

hogy nem veletlen kapalozik a sok rendszerintegrator,

A rendszerintegrátornak tök mindegy merre megy tovább, az ügyfél van szar helyzetben: pénzért Bentley-t, vagy kompromisszumokkal Duster-t

A rendszerintegrátor leszállítja bármelyiket, szépen azokkal a megjegyzésekkel, hogy a Duster is szép autó, de nem Bentley.

trey @ gépház

csak nehogy a vege az legyen, hogy ti is bealltok a dzsunkaPC az ABC-bol sorba?
ajjaj! :D mive lesz igy a vilag!? ;)

tudom, hogy szamodra ez a proxmoxozas egy ismeretlen tema, csak kevesebb magas lo, meg kevesebb sztereotipikus eloitelet kell. aztan meg az is lehet, hogy felzarkoztok azok koze, akiknel elesben hatulrol jol muzsikal.

Olyan nincs hogy tökmindegy. Valamelyiken többet fog keresni a rendszerintegrátor. Azzal minden ügyfél jobb ha tisztában van hogy a rendszerintegrátort aztán kurvára nem érdekli hogy a garanciaidőn túl mi történik a rendszerrel. Sőt, minél nagyobb a baj annál valószínűbb hogy további pénz lesz belőle.

Most eladni VMWare-t igen jó üzlet, több a haszon mert magasabbak az árak, és egyre közelebb van az az idő amikor el fog kelleni migrálni róla mert becsukják a boltot.

A világ nagyon egyszerűen működik, mindenki a kisebb efforttal több pénz irányába hajt.

zászló, zászló, szív

az ugyfel ezt a reszt egyreszt nem erti, masreszt le se... :)

Ez ügyfele válogatja. Ahol van technikai csapat, ott tipikusan nagyon nem, főleg ha láttak már VMware-t.

Ha valaki a honlap alapján döntene a VMware ellen vagy mellett, akkor azt átrázták.

Igen, sokan keresik az utat, miként tudják a bevált megbízhatóságot biztosítani, ebben csak azt nem értem, mi nem nyilvánvaló.

hat, minden valtas nehez. es teljesen megertem, hogy egyeseknek futhatnekjuk van. a 404 viszont szamomra ezt csak megerositi es nem elleniranyba tolja a szekeret.

es ezt, bizony a proxmoxosok is tudjak, igeny volt/van ra https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Automatic_ESXi_Impor…

ha tippelnem kene, az van, hogy linux-szal egyre nehezebb mar type1 hypervisor oldalon is versenyezni, igy a sok closed megoldas kozul a vmware is kiszorul a piacrol hosszu tavon. amik mostansag a hazuk tajan tortentek, az sokakban kongatta meg a kiscsengot. nemcsak arazas, de a vendor lock-in miatt is.

sok helyt tenyleges elony opensource-t hasznalni. mar csak 3rd-party support vegett is - lasd proxmox is listazza, kihez ajanljla, hogy menj, ha infrat akarsz epittetni, es ott sokan a sajat vasaikon SLA-t is vallalnak melle. a tobb helyrol upstreambe visszacsorgo javitasok miatt is, meg ha megsem valik be az a proxmox, onnan valtani is.

Ez a 404 nagyon becsípődött nálad. Igen, a felszín tükrözhet mélyebben levő problémákat, de annak, akinek döntenie kell - főleg meglévő VMware infrastruktúra esetén -, ez kb annyira érdekes, minthogy a szomszéd mit evett reggelire. A vSphere ketyeg, stabil, könnyen üzemeltethető, megbízható.

Az ESX 9 kapcsán kiderül, hogy technikailag is romba döntik-e az eddigieket, de jelenleg a legtöbb infrastruktúra esetén ennek korlátozott a jelentősége, mert a 8-as még elketyeg egy ideig.

Nemcsak a Proxmosok tudják, hogy sokan mennek el (és egyre többen) VMware-ről, minden más gyártó is kiválóan tisztában van ezzel és tárt karokkal várják az ügyfeleket. Nincs ebben semmi csoda.

ha tippelnem kene, az van, hogy linux-szal egyre nehezebb mar type1 hypervisor oldalon is versenyezni

Ez kb mutatja is, hogy fogalmad sincs, miért lett jelentős a VMware, mi a valódi előnye, eddig is miért vették a cégek és miért is okoz akkora fejfájást a változás.

a vendor lock-in miatt is

Annyira érdekelte a cégeket, mint amennyire például Microsoft esetén érdekli, hosszan lehetne sorolni a hasonló rendszereket (lényegében minden ügyviteli vagy szakmai rendszer: minél nagyobb a cég, annál jobban függ tőle).

sok helyt tenyleges elony opensource-t hasznalni. mar csak 3rd-party support vegett is

Tájékoztatásul: pont az adja a VMware egyik erejét, hogy meglehetősen komoly ökoszisztéma van körülötte. Nem github szkriptek, hanem termékek (nagyon jó github szkriptek is vannak). Tény, hogy sok ilyen gyártó most valószínűleg szívja a fogát, nyitnak másfelé (értsd: be kell ruháznia, fejleszteni, ez időt igényel), lásd Veeam for Proxmox. Hosszú távon ezzel majd nyilván a felhasználók nyernek, de kell néhány év, mire funkcionalitásban megfelelő alternatívák kinőnek. Addig van és lesz némi szívás, illetve valakinek meg kell fizetnie az átmenetet, Ceph cluster üzemeltetést, összeomlásokat, fejlesztést.

teljesen el vagy tevedve timeline ugyileg. meg technologia ugyileg is. 10 eves ceph malor/bug vs. kurrens vmware-rol menekules. :) a ceph nem kotelezo eleme egy proxmox infranak (sot, idealis esetben nem is resze, nem rakod a hypervisorra, hacsak nem direkt hci-t epitesz). csak ezt talatatok, amirol lehet csamcsogni, hogy sokaig tart a csillio adaton egy rebuild, ha az uzemeltetes elszabta... :) terjunk is vissza a virtualizaciohoz...

az, hogy mi van vmware-hez teljesen lenyegtelen amikor elmesz onnan. ez nagyban kb. ugyanaz, mint amikor valaki linuxrol windowsra vagy forditva all at. a vmware nem xen es egyik sem qemu/kvm. mas toolok, mas skillset. hasonlo vegeredmeny. mindnek megvannak a haklijai: megszoksz vagy megszoksz. az is tiszta sor, h nem fog kontrolcekontrolvevel proxmox szakiva valni valaki tizenX ev vmware tapasztalattal, de aki tudja egy infraban mi micsoda, meg latott mar linuxot is parszor, hidd el, ha akar, el fog boldogulni par honap labor utan.
de qemu/kvm-hez talalsz jopar orchestrationt, a libvirttol az openstackig, amik kozt az atmenet kb. trivialis. nincs fejvakargatas. (nem mondtam, h mind jo, sot, es itt nem is ez a lenyeg)
a proxmox ezek kozul azzal tunik ki, hogy a legjobb feature-set-et adja, openstackes "pilotavizsga"/verziovaltaskori szivasok nelkul (annak is megvan a helye), eleg regota, integralva + igen szepen fejlodik kb. kiadasrol kiadasra. (pl. legutobbi par jelentos, ami igy beugrik: SDN support, live migrate clusterk kozt, vmware-rol, live restore [nem kell hozza veeam-et venni...], ilyenek)
nem mellesleg "made in EU" termek, ha valakinek ez fontos.

akinek eddig is volt egyszem storage-a meg 1-2 node-ja, annak egyebkent is marhara mindegy a megszokason kivul (meg, h mivel hozta telepitve a beszallito), hogy mi a type1.

veeam for proxmox... ertem en. azt is, h aki eddig nem proxmoxozott, nem tudja mi fan terem a pbs. persze, megszokasbol is lehet "jatszani", csak minek...

detto ugyanez a kore farigcsalt egyeb toolokra. es pont ez a vendor lock-in, amitol menekul, aki valtana vmware-rol. es most el van tevedve, hogy nem talalja a helyet es probalja a proxmoxot vmware-esiteni, meg nem erti miert nem iscsi-zunk ha snapshot kell... ez a learining curve eleje :)

az olyan aprosagokrol ne is tegyunk emlitest, hogy amin linux elfut es van rajta x64 virt. support, arra felmegy egy proxmox is. es itt nem a dzsunkaPC-re gondolunk, hanem akar a legmodernebb infrakra, ahova hivatalos vmware support majd egyszer lesz. ha lesz egyaltalan.

Ha visszaolvasod, miket írtam, nekem nem általánosan a Proxmoxszal van bajom, hanem a Ceph-et tartom kockázatnak. Mégpedig azért, mert azon vannak az adatok és ha megborul, akkor minden adat borul. És nemcsak 10 éves problémákról hallani/olvasni. Ha ezek nem lennének, netán a Proxmox tudna rá normális támogatást adni, akkor már megfontolás tárgya lenne/lehetne. De én nem akarok szívni, ilyen kockázatot bevállalni, ezt finanszírozni.

Valamilyen szinten minden termék/szoftver/szolgáltatás "vendor lock-in", nem világos, mi vele a probléma. Ügyviteli rendszert miként választasz? Olyat keresel, aminek van alternatívája azonos adatbázis sémával vagy van hozzá dobozos elmigráló eszköz?

Saját magad írtad le, hogy nem értesz a VMware-hez, ez alapján nincs is üzemeltetési tapasztalatod, valószínűleg nem is érted, miért jó/egyszerű a VMware. "set and forget" kategória, nem kell matatni. Ilyen esetben nyilván valami hasonlót keres az ember, nem akar több nyűgöt (ami idő), mint korábban. Nyilván van az a munka, ami bőven megéri a VMware licencárához képest, erről szól a sztori, Broadcom részről is.

A Proxmox európaisága kétségen kívül erős érv, könnyen lehet, hogy az elkövetkezendő években ez még fel fog értékelődni. Igen, nálam szempont lehet, sajnos szinte minden amerikai.

A magam részéről egyébként nem ragaszkodom a Veeamhez, sajnos érzékelek némi minőségromlást a drágulás mellett. A Linux-only verzió pedig kb olyan, mint a Linux Desktop és Hurd.

de meirt kevered bele a ceph-et? ezzel az erovel azt is mondogathatnad, hogy a debian szar, mert ceph. ugyanis a proxmoxnak nem resze a ceph, by default fent sincs, sot, a csomagtarolo is kulso.
fel lehet venni, mint storage backend, meg fel lehet tenni a hypervisorra, mert az egy koszos debian.
pont ugyanazt a [insert random brand here] storage-et is alacsattinthatod, mint vmware ala.
valószínűleg nem is érted, miért jó/egyszerű a VMware > es akkor mivan? ettol lesz szar a proxmox, amit meg te nem ismersz? mi a logika? :) vmware-t meddig tanultad? eloszor proxmoxozz ugyanannyit, uzemeltesd elesben ugyanannyit, te is aztan hasonlits :)
en a partvonalrol azt latom, hogy a vmware-bol eppen van egy "menjunkinnen" trend par eve, mert cost/function-ben sokaig versenykepes volt, mostmeg elszaladt veluk - es a kapcsolodo vendorokkal - a lo, a minoseg meg max stagnal. es aki nem tud konnyen valtani (mert a valtas mindig szivas), az belatja, hogy ugy huzzak le egyik naprol a masikra, ahogy akarjak. plusz valogatni kell hozza a supportalt hardvert. ha ugyanezt egy proxmox jatsza el, akkor kb. "felveszed a free repot, oszt' keszen vagy", megy tovabb az elet, mivel opensource, te meg nem nyitogathatsz ticketet.
érzékelek némi minőségromlást a drágulás mellett > pbs/proxmox ingye' (is) van... cserebe lasd fentebb, inkabb fejlodik, mint nem, stabil, pont annyira, mint barmelyik linux(debian)szerver, es ahogy terjed, ebbol az upstream is erost profital.

Azért - és ez neked napok alatt nem esett le, de nem is fog - mert VMware alatt olyanokhoz szoktak hozzá az ügyfelek, hogy vMotion, Storage vMotion stb. az ilyenek, ennek meg feltétele a bizonyos storage, ugyanis ezek snapshotolásra építenek. Tehát nem jó minden fiszfasz lófasz, ami távolról diszknek látszik. 

trey @ gépház

proxmoxon meg nem kell hozza vmotion, mert a hypervisor snapshotol, mozgat adatot, tartja szamon a dirty blocks-t, nem a storage. csak errol meg te nem tudsz semmit. :) es innen jonnek a mindenfele hiedelmek, meg szognek nezesek. mas az architektura.

Ez a példa kiválóan mutatja, hogy egy egyszerű művelet mennyivel egyszerűbb ESXi alatt: minden VM-hez tartozó információ egy helyen van, nem kell ID-kel foglalkozni (eleve az, hogy neked kell kitalálni az ID-t meglehetősen fapados, nagyobb infrastruktúrában kész öröm lehet néhány száz VM esetén). Nem azt mondom, hogy nem lehet ezzel együtt élni, de sok ilyen kis apróság sokat jelent hosszú távon.

he? :D
ez konkretan a VM HW feluleten van.
semmilyen id-t nem kell talalgatnod.
komolyan behalok, hogy ugy fikazodtok, hogy eletetekben nem lattatok PVE feluletet. vagy ceph-et mukodni. :D szanalmas :(
es igy mar ertheto hol a problema...

Ja, amikor valaki olyanokat mond, hogy a hypervisor csinál olyan funkciókat, amiket komolyabb storage-ok maguk hardverből és mindezt eladja előnynek :D A hypervisor elsődleges feladata nem belső taszkok alá lapátolni az erőforrást, hanem kurva jó sebességgel és minél kevesebb overhead-del futtatni a produktion virtuális gépeket. 

Ez tipikusan ilyen púró ízé, mint amikor valaki nem értette, hogy miért cigány dolog ESXi-n Ghetto scripttel menteni :D

trey @ gépház

Mikor megnyomom, hogy új VM, ott van az ID. Bead egy ID-t, ami elvileg egyedi, de akár módosítani is tudom. Több, különálló, de mégis valamilyen kapcsolatban levő környezetek között izgalmas lehet ez a játék. Vagy be lehet állítani, hogy milyen tartományból vegyen ID-t? Ennél van jobb? https://forum.proxmox.com/threads/modify-vm-ids-range.67663/

A VM listában mi az első, amit látok? ID, utána van zárójelben a név, mint valami másodlagos attribútum (mert az is).

Én sehol nem állítottam, hogy értenék hozzá, jelenleg csak kóstolgatjuk és jönnek szembe az ilyen apróságok, amikkel VMware esetén egyáltalán nem kell foglalkozni.

Mindenesetre köszi, akkor ezt már nem kell megkeresni. Ettől függetlenül az ID alapú működés tartogathat még benézéseket.

Azt meg lehet csinálni, hogy a PVE alatt ne ID, hanem név szerint legyenek rendezve a VM-ek?

Nyilván semmi nem ott van, nem is vártam, hogy ott legyen (igazából de, mert az baromi logikus), pont a sok kis apróság nagyban segíti az üzemeltetést. Például VMware esetén is nyilván van azonosítója egy VM-ek (több is), de nagyon-nagyon ritkán kell vele foglalkozni. Mondanám, hogy kezdj el vele foglalkozni, de nem biztos, hogy ez a megfelelő időpont beszállni :-)

A két API URL-t külön nagyon köszönöm, integrációhoz erre nagyon szükség lehet a jövőben, jó előre is tudni, hogy van ilyen.

VMware alatt, ha valakinek érdekes lenne: $URL/mob

Nézd meg a "Tag" funkciót és úgy rendezed és színezed a gépeket, ahogy kedved tartja. A gép felett beállítások felett van egy kis ceruza.

Meg ez is érdemes hozzá:

Datacenter -> Options -> Tag Style Override 

Itt még tovább tudod állítgatni és úgy fog kinézni a management felület mint egy karácsonyfa :D

Én szeretem :) Tényleg hasznos.

Bal legfelül "Tag View"

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

"Bead egy ID-t, ami elvileg egyedi, de akár módosítani is tudom. Több, különálló, de mégis valamilyen kapcsolatban levő környezetek között izgalmas lehet ez a játék. "

A VM ID egy egyedi szám. Ezen ID alatt jönnek létre a VM diszkek. Akár LVM lv-name szinten is. Ha adott VM-nek több diszkje van, kap -1, -2, -3 elnevezést.
Egy klaszteren belül nem lehet ugyanaz a szám 2x. Automatikusan nagyobbra lépteti, ha felülbírálod és ugyanolyan ID-t akarsz beírni, piros lesz a mező, nem engedi. A backup fájlok nevei is ezt az ID-t hordozzák.
Az utána lévő zárójelben a VM név szabadon választható. Ez menet közben változhat, de az ID mindig fix abban a klaszter környezetben. 

Én használok VMware-t és Proxmoxot is. A VMware-nél kifejezetten rühellem, amikor a kolléga létrehoz egy VM-et "A" néven, később "B" nevre kereszteli, de a datastore-ban "A" nevű mappában vannak a cuccai. Néhány ilyen mutatvány és szép káosz lesz a datastore-ban. Pl. amikor elárvult mappákat akarunk kitörölni, mert VM törléskor nem merte a kolléga még letörölni a VM diszkjét, lehet visszakövetni, hogy ki kivel van...vagy kivel nincs senki.
Igen, erre azt a megoldást szoktam alkalmazni név változtatáskor, hogy leklónozom új névvel, a régit meg törlöm. Macerás. 

Az ID ezzel szemben senkit nem zavar, senki nem akarja átírni. Arra ott van a VM név mező. Így a VM teljes életútja alatt vele marad. Nekem a proxmoxos megoldás jobban bejön.

Ha van esetleg valami trükk, bevált szokás erre az zavaró dologra. Jöhet. Azon túl, hogy gondold át előre :)

Nyilván mindennek megvan a maga hátránya, de egy idő után kialakul egy fajta fegyelmezettség és név alapján tipikusan megtalálni a mappát, még ha nem is teljesen ugyanaz, mint a név.

Klónozás helyett inkább migráld másik adattárra (majd vissza), az is rendbe teszi a mappa nevet, a VM így nem változik (moref, teljesítmény adatok).

ID-nél hátrány, hogy alul a folyamatban levő műveleteknél csak ID-t látni. Ha sok VM van, sok művelettel, akkor elég nehéz lehet visszanézni, hogy melyik mire vonatkozik, olyankor esetleg célszerű nézetet váltani és ID szerint rendezni. Ez azért gyakoribb, mint a mappákban való turkálás. Na mindegy, kénytelen lesz megszokni az ember.

 legtobb logba bekerul a nev is. pl:

INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2025-08-15 07:30:29
INFO: status = running
INFO: VM Name: vmneve
INFO: include disk 'virtio0' 'taroloneve:vm-101-disk-2' 40G
INFO: include disk 'efidisk0' 'taroloneve:vm-101-disk-1' 1M
INFO: include disk 'tpmstate0' 'taroloneve:vm-101-disk-0' 4M
INFO: backup mode: snapshot
INFO: ionice priority: 7

Ilyenek proxmox alatt is mennek.

- Közös storage-ről 2 node között live migration, úgylehet 1 ping sem esik ki.

- Akár 2 külön node között is, amiknek 1-1 helyi diszken fut a VM. Utóbbit rendszeresen alkalmazom. Eddig, amit mozgatnom kellett live-ba, legnagyobb VM 2TB volt, aminek volt egy nagy 1.5TB diszkje és kb 12GB RAM.

Diszkeket áttolta egyesével, aztán 1-1 diszk végén a diffet, ami élő szerver miatt (500 apache vhost, MySQL, 1200 mail cím) generált változást a több órás művelet alatt.
Miután a diszkek átmentek, a RAM-t lapátolta át, aztán annak a diffjét. Műszakilag belegondolva, a kiszolgálás ekkor már a cél host diszkjéről ment, de még a forrás host RAM-jából. Amikor átért a RAM diff is, átregisztrálta az új hostra és 1 ping esett csak ki.
1GBit/s hálón ment minden. (Azóta 10G optika van a node-ok között.)

Ezt többször megcsináltam kisebb vagy ekkora VM-ekkel az elmúlt években, stabilan tudja. 

- Tud 1 hoston belül storage-t váltani futó VM alatt. Nálam van minden node-ban local HDD, local SSD és "távoli" NFS. Ezek között ping kiesés mentesen tudom pakolgatni a futó VM-et. Ezt is rendszeresen használom évek óta.

Tehát egy időben tudsz váltani úgy hostot (költözik a virtuális gép), plusz a virtuális gép egyik távoli storage-ról tud költözni a másik távoli storage-ra, futás közben, kb. 1-2 sec kieséssel, miközben dolgoznak raja. Ja, ez az elvárt. 

Mindezt milyen storage-ok közt? Mi van az NFS mögött, milyen fájlrendszer?

trey @ gépház

Nem, te mindenkinek így válaszolsz, annyira, hogy panasz is érkezett rád legutóbb egy olyan őrjöngésed kapcsán, aminek én nem voltam része. Van egy bohóc stílusod, ezzel nincs semmi baj. Baj azzal van, hogy életedben nem láttál komolyabb cégeket belülről.

hol a huphu 25 evnyi availability statja? :) nem publikus?

A fejedben. Majd szólj, hogy mikor emlékszel olyanra, hogy órákat állt. LOL Ebbe akarsz beleállni? 

trey @ gépház

Ebbe akarsz beleállni? > #fogadjisten
Van egy bohóc stílusod, ezzel nincs semmi baj. > akkor most baj vagy nem baj, hogy trollokkal trollkent beszelek? :D
Baj azzal van, hogy életedben nem láttál komolyabb cégeket belülről. > de. sot, konkretan par eve a legnagyobb itthoni otkilencet vallalo IT ceget is. ugy hat even at. de legyen igazad, hisz trey nagyur megmondta: fingom sincs! :D

ha nem volnanak kenyszerkepzetes eloiteleteid mind human, mint technologiai kerdesekben, akkor talan lehetne veled is ertelmesen beszelgetni. de csak a magaslorol elmultharmincevezes megy, meg a tovabbpasszolt SLA-ra mellveres, kozben meg szombaton diszkkel szaladgalas...
ezzel nalam nem leszel nagy ember, sry. :)

ROTFL

Nem hát, mert az valami naaaagy csoda :D

BTW: te ilyen tervező (tanár) vagy, más meg üzemelteti (aki tudja?) :D

Leszállított rendszer érdekelne. Tokkal/vonóval. SLA-val, support-tal. Jaaaaa, hogy valami helyre betedd a lábad, oda valami komolyabb bankgarancia meg felelősségbiztosítás is kellene ... tudod, nem LUG-szakkör. Neked ilyenek vannak, Dzsoni?

trey @ gépház

ilyen szepen szeretnel tanacsot kerni, hogy kell infrat tervezni? :) elmondtam mit csinalok. azt is, hogy mit nem vallalok. szerintem nem nehez a megertese.

miert vallalnek SLA-t mas helyett? nem igazan ertem. :)

nem vagyok tervezo tanar. uzemeltetek is. mert ertek hozza. azert. nem verem mas faszaval a csalant.

Szerintem 2 távoli storage között még nem költöztettem VM-et, hosttal együtt főleg nem. De jó próba. Eddigiek alapján nem látom technikai akadályát. A "miközben dolgoznak rajta" hanyas loadot vagy iopsot jelentsen? Kipróbálom valami stress testes processzel egy teszt VM-en. A távoli storage perpill néhány SATA WD RE diszkes RAID5 és RAID6 alapokon nyugvó 2 NFS lesz.

pedig nem scifi, hiszen api-n/ssh-n vandorol at, ha itt a clusterek kozti migralasra gondolsz. (qm export/import)

hogy a diszk local vagy remote, ebbol a szempontbol mindegy.

ha siman egy hoston futo VM diszkjet tolsz at a-bol b-be, akkor meg a hatterben a kvm elintezi. klonoz, atall ra, majd ha kered torli a source-t is. nem szamit a storage tipusa.

clusteren beluli node-ok kozt pedig attol fugg, de memoriastul detto, ha shared a storage, akkor pedig az adat marad ahol van.

Volt/van egy téma, Ceph-et többen használják tárolónak Proxmox alá, én leírtam a véleményemet, miszerint a Ceph-et nem tartom kellően megbízhatónak, üzemeltetésileg kockázatot hordoz, nem feltétlenül olyan olcsó, mint aminek látszik. Egy Walmart és hasonlóknak van/lehet arra szakember gárdájuk, hogy akár 24x7 üzemeltessék, van arra erőforrásuk, hogy legyen "staging cluster".

pont ugyanazt a [insert random brand here] storage-et is alacsattinthatod, mint vmware ala.

Azért nem teljesen, mert shared + block + snapshot trióból kettőt tudsz választani (talán a 9-cel lassan 3-at is). De ezt írtam is, hogy szerintem ez a járható út, ha nagyobb rendelkezésre állás kell.

valószínűleg nem is érted, miért jó/egyszerű a VMware > es akkor mivan?

Az van, hogy olyanról osztod az észt, amiről fogalmad sincs. Például a VMware-nek van normális támogatása még akkor is, ha 404-es oldal van most éppen. A VMware olyan név a szakmában, amit nem úgy választ ki az ember, mint Proxmox Gold partnert, akikről kb akkor hall először az ember, mikor megnézi a listát (ettől még nyilván lehetnek nagyon jók). Igen, ott van jelentősége a 404-nek.

Egyébként nem találtam olyan Gold Partnert - bár nem néztem végig a listát -, aki általánosan nyújtana támogatást, innentől kezdve jó eséllyel kellően drága is lehet és még mindig reménykedhetsz, hogy valóban ért is hozzá kellő mélységben (értsd: kellő számú olyan szakembere van, aki mindig rendelkezésre is áll), nem napok alatt próbálja visszavarázsolni az adatokat vagy a végén kijelenti, hogy teljes visszaállítás. A Trey által küldött esetek esetén sem hülye gyerekek próbálkoztak sejtésem szerint. Ahogy ott is volt adott esetben hiba, más is elkövethet hibát. Minél több helyen lehet hibát elkövetni, annál nagyobb eséllyel fordul elő.

Kértem már hasonló ajánlatot német cégtől (nem Proxmox), meglehetősen brutális szám volt, pedig stabil szoftverre kellett. Amit nyilván megértek, mert ő sem akar kockáztatni, a kockázatot valakinek fizetnie kell.

IBM vagy hasonlótól részemről akár szóba is jöhetne a Ceph, ha amúgy az teljesíti jól a feladatot, ott is kérdés, hogy mennyi lenne az annyi.

en a partvonalrol azt latom, hogy a vmware-bol eppen van egy "menjunkinnen" trend par eve, mert cost/function-ben sokaig versenykepes volt, mostmeg elszaladt veluk - es a kapcsolodo vendorokkal - a lo, a minoseg meg max stagnal.

Sokan nem ismerték valami miatt az Essentials csomagot, ami potom pénzért megfelelő platformot biztosított. Továbbá fejlődnek a Linux alapú megoldások és az eddigi barkácsolók számára (akik nem ismerték az Essentials-t) több lehetőség adódott, nem csak Hyper-V. Én erősen kétlem, hogy a vSphere Essentials-nél érdemileg olcsóbban lehetett volna megbízható és könnyen üzemeltethető infrastruktúrát építeni (ez ott kezdődik, hogy normális szerver kerül alá).

A kis szegmens marketing teljesen hiányzott a VMware-nél, valószínűleg pont azért, mert nem érte volna meg. Most sajnos még feljebb tolják a lécet.

plusz valogatni kell hozza a supportalt hardvert.

Szerintem nem sok olyan vállalható szerver van, amint nem fut el az ESXi. Ha valaki barkácsol, lelke rajta, nem az én problémám. Érzékeltetésként azt sem értem, mikor egy cégnél egy szem szerver fut NBD garanciával, egy USB kábelen lóg a mentés stb.

Az informatika tipikusan addig könnyű, amíg nem üt be valami.

hat, hogy te mit tartasz megbizhatonak, azt elso korben tapasztalat alapjan kene eldonteni. nem bemondasra meg anekdotakra. szerintem :) minden technologia kapcsan tudsz elcseszesbol meg hardverhibabol adodo horrorsztorikat talalni, csak keresni kell.
amiket hoztatok peldakat, ott mind uzemeltetoi elkurasbol (van ahol a doksi elso bekezdes, ezt ne csinald pontjat leptek meg, nemar...) halozati elcseszesbol/nem vartuk meg, mig lemegy X task, ranyomtunk, hogy johettek irni fakadt a gond. hogy utana meg kell kalapalni? az egy ilyen bicikli. minden masra ott a backupbol visszaallunk.

senki nem mondta, hogy egy jol mukodo infra olcso. ezt a dolgot nem tudom honnan vetted. nincs ingyenebed. ha ertesz hozza es tudod uzemeltetni, az a te value-add-od es penzt fogsz erte kerni. ha nem, akkor meg fizetsz annak, aki megcsinalja helyetted. azert ez nem olyan bonyolult es nem technologia-dependens.

a partnerek jellemzoen ugy vallalnak neked SLA-t, hogy sajat vasaikon sajat halozaton, sajat datacenterukben adnak neked egy infrat, hogy tessek. a polcon/rackben meg fent van a tartalek, ha elpatkol valamelyik vas. ezt magyaraztam en trey baratunknak is, en nem datacentert uzemeltetek, semmi rahatasom, h a hw vendor mit ad vagy nem ad, milyen garit vallal. teljesen masik role/szint. ezert nem is tesszuk ra a tokunket ilyenre, vagy #vanazapenz, amit kifizetsz a vendornak erte

üzemeltethető infrastruktúrát építeni (ez ott kezdődik, hogy normális szerver kerül alá) > ez minden infrara igaz, tovabbra sem ertem a kettos mercet.

Szerintem nem sok olyan vállalható szerver van, amint nem fut el az ESXi. > erre en nem tudok es nem is akarok mit mondani, nincs elottem az osszes "szerinted vallalhato" szerver/esxi-compatible aranyszam. :)

mikor egy cégnél egy szem szerver fut NBD garanciával, egy USB kábelen lóg a mentés > akkor ott nem vallalsz SLA-t. :) max azt, hogy szoljanak, ha megjott a csere es elkezded a szart lapatolni oradijban, vagy jo lesz vagy nem vallalassal.

Az informatika tipikusan addig könnyű, amíg nem üt be valami. > mintpl, hogy a vmware elkezdi szivatni a vendor-locked ugyfeleit? :) egyetertek!

Valójában, amiket te írsz, már nem is olvasom, redundáns faszság. 

csak a te stilusodban. #fogadjisten

Jaja:

https://hup.hu/comment/3210408#comment-3210408

akinek csak kalapácsa van

Felütéseddel kezdődött, azóta csak azt kapod, amit érdemelsz. De, látom nem csak velem szemben vagy egy bohóc, olvasom ám a szálaidat, még ha nem is veszek mindben részt ... 

Arra kérdésre azóta se válaszoltál. Szerinted a Veeam mi a szarért csinálta meg hosszas könyörgésre a Veeam for Proxmox-ot, ha egyébként olyan fasza lenne a PBS? 🤔

trey @ gépház

Kurván mellélőttél, mert én Veeam-et saját döntésből egyáltalán nem használok. Kényszerből igen. 

onnan kezdunk, hogy meg sem ertetted amit leirtam

Ahogy te se érted még mindig, hogy mi mit írunk: pincében a család Proxmox szerverének üzemeltetése nem egyenlő az enterprise-zal

trey @ gépház

es en mit kene kezdjek a kenyszereddel? a lenyegen nem valtoztat, kaptal kalapacsot, kalapacsos ember vagy: "akinek kalapacsa van"

te se érted > sajnalom, kepzelegsz. es ha olvasnad amit irogatok, akkor... dehat onbevallottan vagy write-only troll. szoval /o\

🤭 😂> kezdesz szetesni. azt kell hasznalnod vagy nem kell azt hasznalnod kenyszerbol? ha igen, akkor kalapacsod van... :) nem bonyolult ez.
ha valaszthatsz, akkor te se valasztanad... :D
szoval nem teljesen vilagos mi a problema, azon kivul, hogy megint bedobtad a fellengzos troll-t. :) (nem, nem csak egy fele virtualizaciot uzemeltetek, es nem tartozik a proxmox release temaba, felvagni megugye felesleges offtopik... ;)

ennyire futja? :) fikazodsz, ha mar nem sikerult fogast talalni? "nyanyanya, mi otfele fost tartunk eletben, az jobb!"
ertem. :)

en rendszert tervezek ugyfeligeny alapjan. egyertelmu, hogy nem vmware-re, mert azt nem ismerem. feluletet elnyomkodom, ha nagyon muszaj. oszt' csok.

aki mar eldontotte mit szeretne, annak meg ugyis mindegy mit mondasz. abbol fozol, ami van.

De mit adsz erre az igényre, ha már eldöntötte, hogy VMware kell neki, mert eddig is az volt, ezután se szeretne semmiféle homályos supportos monkey business-t? Ticketing rendszerük van már?

Szerkesztetted: ja értem, tehát, ha VMware lesz az igény akkor azt adsz. Különösebb hozzáértés nélkül. Hát jó ... te tényleg különb vagy :D

trey @ gépház

De mit adsz erre az igényre, ha már eldöntötte, hogy VMware kell neki, mert eddig is az volt > o nem hozzam jon infrat terveztetni.

hal'istennek ebben megvan a szabad kez.

Ticketing rendszerük van már? > support szerzodesed van mar? :)

egyebkent biztos nehez megtalalni, persze en nem ketlem, hogy nem akarod... https://bugzilla.proxmox.com/describecomponents.cgi?product=pve

Szerintem valamirevaló szerződéskötést fontolgatónak ez lesz az első 5 kérdése közül az egyik. Bejelentési csatornák, SLA-k mérése, mi az alapja.

egyebkent biztos nehez megtalalni, persze en nem ketlem, hogy nem akarod... https://bugzilla.proxmox.com/describecomponents.cgi?product=pve

Szeretnélek tájékoztatni, hogy fejlesztői bugtracker meg a szolgáltatásmenedzsmenthez/IT service desk ticketing rendszer az nem ugyanaz. 

trey @ gépház

es support szerzodesed van mar? :) nem nagyon tudsz valaszolni a kerdesekre. az a baj.
en infrastrukturat epitek igenyek alapjan.
leszarom a sales mit targyal az ugyfellel. jeleztem mar, ha te ezt sales-kent nem tudod ertekesiteni, az nem az en problemam :)
visszakanyarodtunk napokkal ezelottig, aholis elmondtam, h a te celod mas SLA-janak tovabbertekesitese. :)

ROTFL, akkor nem fog kiderülni, hogy a csak hétköznapokon dolgozó Kft-nek van-e 0-24 ticketing rendszere. Ez is egy válasz.

visszakanyarodtunk napokkal ezelottig, aholis elmondtam, h a te celod mas SLA-janak tovabbertekesitese. :)

Mondjuk az se lenne ördögtől való Dzsoni, hogy valaki bevisz olyan helyre a saját sapkájában, ahova be se engednének. Nem az lenne a lényeg, hogy a te pénzed meglegyen?

trey @ gépház

Arcserve volt (már kivezettem, pedig nagyon jó volt a tape támogatása, egy kurva drága) és Barracuda Backup fizikai appliance. De van, ahol költséghatékonyság miatt Altaro futott. Barracuda még megvan, de semmit sem fejlesztenek kb. így az a tervem, hogy az is le lesz cserével Veeam-re a következő előfizetés fordulókor. Nagyjából a Veeam fut már mindenhol.

trey @ gépház

Megbízható az, amire lehet támaszkodni. Ha VMware becsinál, akkor tudok a támogatásra támaszkodni. Ha tároló becsinál, akkor tudok a támogatásra támaszkodni. Amíg a támogatás keresi és csinálja a megoldást, addig én mással is tudok foglalkozni, kevesebb a lekötetlen, tartalék munkaerő. Ha Ceph becsinál, akkor vakarhatom én, jó eséllyel saját kontóra, ráadásul esetleg más projekt kárára.

amiket hoztatok peldakat, ott mind uzemeltetoi elkurasbol

Nekem az egyiknél rémlik csak ilyen, másik esetekben talán hardver probléma sem volt szükséges a leálláshoz.

De megint csak ismételni tudom magamat: minél több a hibalehetősége az üzemeltetésnek, annál nagyobb eséllyel lesz hiba. Végeredmény szempontjából teljesen mindegy, hogy hülye volt valaki vagy a Ceph volt bugos. Az emberi faktor mindig ott van. Egyelőre az AI sem tűnik bombabiztosnak.

Én még soha nem jártam úgy, hogy egy kiválasztott hardver ne lett volna ESXi kompatibilis/támogatott. Legfeljebb mikor notebookra akartam feltenni tesztelés céljából, de akár notebookon is el tud futni.

mintpl, hogy a vmware elkezdi szivatni a vendor-locked ugyfeleit? :) egyetertek!

Erre a vendor-locked témára válaszolhatnál végre, hogy mit is értesz alatta, mitől vendor-locked vagy sem, mikortól, mikortól nem. Ha apache-ot használsz Linuxon, akkor az vendor-locked vagy sem? Redhat Linux?

Ha Proxmon futsz, akkor onnan átmigrálni is erőforrást igényel (például ESXi-re). De ha azt veszem, hogy ESXi VM beimportálható Proxmoxra, akkor mitől vendor-locked?

Megbízható az, amire lehet támaszkodni. > most ez a mr. obvious ora? :D

Ha VMware becsinál, akkor tudok a támogatásra támaszkodni. > proxmox support? :) szerintem ezen mar tul vagyunk egy ideje...
Ha tároló becsinál, akkor tudok a támogatásra támaszkodni. > ennek nincs koze a hypervisorhoz.

ha nem lenne vendor locked, nem kene agyalogni, hogy kell kimenekulni.

a proxmox open source termek. nem vagy financialisan kotve semmihez es senkihez, nem tudnak egy tollvonassal arat emelni, ha meg igen, lasd fentebb: ha nem akarsz, nem fizetsz.

proxmox support? :) szerintem ezen mar tul vagyunk egy ideje...

Én is azt hittem, ezen már túl vagyunk: Proxmox esetén legjobb esetben is osztrák munkaidőben (ráadásul karbantartás tipikusan azon kívül van, probléma nagyobb eséllyel akkor lesz). Ez is csak akkor, ha perkálsz € 1060/year & CPU socket. Ennyiért majdnem VMware is van (tényleg nem sok hiányzik), 24x7-es támogatással.

ha nem lenne vendor locked, nem kene agyalogni, hogy kell kimenekulni.

a proxmox open source termek. nem vagy financialisan kotve semmihez es senkihez, nem tudnak egy tollvonassal arat emelni, ha meg igen, lasd fentebb: ha nem akarsz, nem fizetsz.

Ennek így nem sok értelme van, esetleg ingyen dolgozol?

És péntek délután nem dolgoznak, jó eséllyel a fekete övesek már elindultak valamelyik tóra vitorlázni vagy síelni, egy újonc pedig tartja a frontot és válaszol, tartva a 2 órás válaszidőt, netán még naplót is gyűjt, hogy hétfő reggel neki lehessen látni a munkának.

Kíváncsi vagyok, mikor jutnak el oda, hogy jobb támogatást tudnak adni.

https://proxmox.com/en/about/about-us/careers: Technical Support Engineer (m/f/d), no phone support, no 24/7

Fejlesztésre többet is keresnek, holott szint lépéshez lehet, hogy a támogatáson sem ártana fejleszteni, elképzelhető, hogy jobban megteremne a fejlesztésre is, de biztos ők látják jobban a saját számaikat, csak gondolkodom.

mert meg mindig az van, hogy ilyet partnertol tudsz. SLA-val akar. csak ott keszulj fel, hogy infrat is kell vegyel, mert marineni ceges sufniszerverere az nem lesz :)

vagy mire gondoltatok, elugrik a nemet mernok Mosonpusztara szervert simogatni szombat ejjel, mikor a helyi szakertok megboritottak az infrat? :)

Lesz válasz? 300 kommentet ne kelljen fejben tartanom, te csak egy vagy a napi 30 flame-emből. Szorozd fel. Lehetetlent ne akarj. Szóval? Te mint Proxmox partner, hogy adod a Proxmox kilóját?

Ha nem vagy az, tudsz ajánlani egy megbízhatót Poxmox partnert?

trey @ gépház

Nem állítom, hogy nem pislogok néha, miket írsz ide a fórumba (bármilyen témában), de ez a portál szempontjából akár kifejezetten hasznos is lehet :-), ugyanakkor abban is biztos vagyok, ha ismét együtt dolgoznánk, most sem lenne nézeteltérés sem szakmai dolgok, sem kommunikáció terén. Egyébként pont 15 éve volt.

Én is biztos vagyok benne, engem kenyérrel lehet kenni, csak hozzáállás kérdése. 

BTW: ott van pl. zwei, akivel szintén együtt dolgoztunk, én mint megbízó, ők mint alvállalkozók. Amerikai ügyfél elégedett volt, én elégedett voltam, ők megkapták az általuk kért díjat. 

A végén mindenki elégedett volt. 🤷‍♂️

trey @ gépház

Megbízható az, amire lehet támaszkodni. Ha VMware becsinál, akkor tudok a támogatásra támaszkodni. Ha tároló becsinál, akkor tudok a támogatásra támaszkodni. Amíg a támogatás keresi és csinálja a megoldást, addig én mással is tudok foglalkozni, kevesebb a lekötetlen, tartalék munkaerő. Ha Ceph becsinál, akkor vakarhatom én, jó eséllyel saját kontóra, ráadásul esetleg más projekt kárára.

Huh, ezt tegnap egész nap magyaráztam nekik, de csak nem ment át. :) A végén kijött, hogy pénzügyekhez se értek :D

trey @ gépház

Én még soha nem jártam úgy, hogy egy kiválasztott hardver ne lett volna ESXi kompatibilis/támogatott. Legfeljebb mikor notebookra akartam feltenni tesztelés céljából, de akár notebookon is el tud futni.

Nem mindegyik ESXi verzió alkalmas minden vason való használatra, CPU limitáció miatt, talán 7-s verziótól jött be ez a korlátozás, de ebben nem vagyok biztos. Proxmox ilyenben "igénytelenebb". 

CPU korlátot vezettek be, ezt így el is felejtettem (ettől függetlenül volt, ami működött elvileg nem támogatottal is emlékeim szerint), de adott ESX verzió azért jó sok évre visszamenőleg kiadott szerverrel működik. Akinek pedig annál régebbi kell, valószínűleg régebbi ESX-szel is boldog lesz.

( gabrielakos v | 2025. 08. 25., h – 17:15 )

most upgradeltem 7.4-ről 8.4-re, problémamentesen. Érdemes rögtön felpiszkálni 9-re vagy még inkább várjak?

zászló, zászló, szív

+sok

Nálam a nagyobb update 3 hónap a verzióváltás meg EOL vége felé, ha nem indokolja előbb valami, ami ritka.

Még kezdőként mondta nekem egy Microsoft support mérnök, aki akkor még félistennek tűnt :) ezt:

Ami működik azt nem kell megjavítani!

Na ehhez azóta is tartom magam, ezzel rengeteg problémától megszabadulva :) Sajnos a security helyzet ezt erősen rontja, de azért még gyakran lehet várni. Az először szívjon vele más, jó technika...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.