[Videó] Virtualizáció és storage szabad szoftver alapon workshop

Virtualizáció

Korábbi HUP hirdetés tárgya rögzített videó formájában megérkezett ☝‍️

( trey | 2024. 06. 25., k – 13:26 )

Toljuk meg egy kicsit azt a 74 views értéket ...

trey @ gépház

  • Első 16 perc átugorható
    • mi az a virtualizáció stb.
    • mi lett a gond a VMware-rel, miért jöttek képbe a FLOSS szoftverek és a Proxmox
  • Proxmox nehézségek, gondok, problémák
  • 20:50-től 21:30-ig szünet / érthetetlen mummogás
  • 31:32 Tapasztalat egy elosztott fájlrendszerrel: GlusterFS
  • 1:38:00-tól 2:13:00-ig őőőő, nem a $title a téma
  • 2:13:00 Sepsi Gábor Proxmoxos környezet bevezetésről (supermicro szerverek, HA cluster, Ceph storage)
    • Windows 2019-cel voltak problémák
  • Proxmox mentési problémák stb.

<írom tovább, ne válaszolj erre a kommentre>

trey @ gépház

Végighallgatva, nem jött meg a kedvem a Proxmox-hoz, főleg a mentésről (ahogy korábban is felvetettem) szóló problémák miatt.

Értem, hogy olcsóbb, mint kifizetni a VMware-nek a licencek árát, de ez a "fórumon megkérdezzük" meg hasonlók kurván nem működnek enterprise környezetben. Az, hogy esik-kel egy Windows verzió VMware-en ... kb. 20 év alatt nem találkoztunk ilyesmivel. Ha mégis, akkor van support.

trey @ gépház

Nem volt tiszta nekem a mentés, hogy mentenek egy "nagy" SQL szervert, akkor már mást nem nagyon tudnak teljesítmény problémák miatt ... hogy? :D

Egy VMware mentőmegoldás - mondjuk egy Barracuda backup, sima SATA diszkekből álló RAID50-re - CBT-vel 70 virtuális gépet 1-2 óra alatt lement virt. gép szinten. 8-as batch-ben, csak a megváltozott blokkokat menti. Ha még az SQL szervereket agent-tel is mentem utána, hogy legyen egy konzisztens backup-om, akkor azzal együtt is megvan az egész hóbelevanc 3 óra alatt. 1 (nem 10, nem 100) Gbites hálózaton ...

Szóval vagy félreértettem, vagy komoly problémák vannak itt még, amiket meg kellene oldani.

trey @ gépház

( Zsugabubus | 2024. 06. 25., k – 15:07 )

Ezt a glusterfst minek erőltetik, halott technológia. 1:19 környékén a hozzásszóló is megerősíti, hogy a vm imaged nincs nagy biztonságban rajta, egyszerűen fájlon belüli (imagen belüli) változtatásokra nincs felkészítve.

A glusterfs nem is való erre. Sokat gyaktam korábban ilyen-olyan célokra - meglátásom szerint arra jó, hogy nem túl nagy méretű fájlokat (pl. számla pdf-ek) egy alkalmazás cluster több tagja alá pakoljunk úgy, hogy ne kelljen dedikált "főnök node. Az igazi előnye szerintem az hogy decentralizált, illetve tapasztalataim szerint elég jól tűri a hibát (főleg, ha a self-heal is be van kapcsolva rajta).

" ne felejtsd el, honnan jöttél - életed során számtalanszor fognak elküldeni oda. "

Én egy intelligensebb rsync-nek látom, akkor működik, ha a kliens az egész fájlt újraírja, ha arra épít, hogy belül módosít benne pár bájtot, és elvárja, hogy ez ACID módon replikálódjon, akkor az esélytelen. De így igazából semmi értelme virtualizációs kontextusban beszélni róla, egyszerűen egy fájltároló.

Igen, fájltároló - ez a pontos megfogalmazás. Amikor tranzakciós adatbázis alá raktam, nem is okozott meglepetést hogy azonnal összerosálta magát (a glusterfs fejlesztői sem javasolják ilyesmire). Lehet, hogy az előadónak úgy kellett volna kezdeni, hogy NE használjuk virtuális diszkek tárolására, így kevésbé lett volna megtévesztő a témakör :)

" ne felejtsd el, honnan jöttél - életed során számtalanszor fognak elküldeni oda. "

( ggallo | 2024. 06. 25., k – 23:03 )

Szerkesztve: 2024. 06. 25., k – 23:05

Köszi, hogy feltetted, és megnézve örülök, hogy nem élőben ültem végig a gép előtt, hanem most, amikor át tudom tekergetni a javát.

Nekem az jött le az egészből, mintha a Proxmox egy kiforratlan tesztrendszer lenne, amivel van, akinek szerencsére nincs gondja, másnak meg akadnak. Pedig nem az, sok éve teljesen megbízható, production ready a tapasztalataim szerint.

A Proxmox előfizetésből a legolcsóbb 110 USD/fizikai CPU foglalat/év, és nem 510 USD az alapár (ez utóbbi a második legdrágább csomag). Az áremelés pedig 90 USD-ről volt 110 USD-re, és jóval a VMware események előtt...

Valódi support is van, a Community előfizetés felett mindben van benne foglalt ticket, nem csak a neten lehet megoldást keresni, és akár 4 vagy 2 órás reagálási időt is vállalnak a magasabb díjú csomagoknál. Az mondjuk tény, hogy a netre nagyjából azonnal, nagyjából mindenre felkerül a megoldás. Azon kevés problémába, amibe eddig belefutottam, eddig mindig kész megoldást találtam, nem csak a kérdezgetést válasz nélkül. Ráadásul a "fórumban" a Proxmox csapat tagjai is aktívan segítenek folyamatosan, hibát keresnek ottani bejelentés alapján. Szóval nem csak a fizetős ügyfelek kapnak minőségi támogatást, mindössze a community-nek nincs prioritása, nincs vállalt határidő a "hivatalos" segítségre.

A Proxmox mentés jelen állapota: már a Proxmox 6.4-ben lévő Qemu is támogatja a CBT-t (dirty block tracking-nak hívja), és a Proxmox Backup Server ezt aktívan használja is az 1.0 verzió óta, egy teljes mentés után forever incremental, csak változott blokkokat ment, deduplikál, tömörít, üres blokkokat nem visz át a hálózaton, stb. Nincs viszonyítási alapom ilyen mentésben, nem használtam a Veeam vagy a Barracuda megoldásait, de szerintem a valóságban nagyon nem csalódik a PBS-ben az sem, aki ezeket használta eddig. Tény, hogy kell alá aránylag gyors tároló (a mentő szerverben), mert rengeteg kis (~ 4MB) állományban (chunk) tárolja a mentett, deduplikált adatot, ami nagy IOPS-t igényel, hogy gyors legyen. 

Szerintem kis rendszerekre (szóló host, 5-10 gépes cluster) mindenképp versenyképes műszakilag és árban a Proxmox akár ingyen, akár előfizetve. Lehet, hogy 100 vagy 1000 host-os parkot nem jó vele menedzselni, de szerintem egyelőre nem is ilyen volumenre tervezték (ami a VMware fejlemények tükrében változhat szerintem).

Ez így jobban hangzik, bár további kérdéseket vet fel:

  • milyen storage-dzsal?
  • a videóban elhangzanak a snapshotok miatti lassulások
  • ha van CBT, akkor végképp nem értem a folyamatos panaszt a videóban a lassú backup-ra, főleg, hogy az is elhangzott, hogy SSD-kre mentenek
  • vannak-e a Proxmox Backup-ban van-e olyan funkció
    • hogy MSSQL-t, Exchange-et stb. tud menet közben alkalmazás szinten, konzisztensen menteni
    • tud-e LiveBoot-ot (magát a deduplikált mentést elindítani virtuális gépként)
    • kvázi folyamatos mentést a kritikus szerverekről
    • offsite vaulting-ot
    • replikációt földrajzilag máshol levő Proxmox Backup Serverre (mintha ez lett volna kérdés és a válasz az volt, hogy tudja), Proxmox által kínált saját felhőszolgáltatásba (fizetősben nyilván), publikus felhőszolgáltatókhoz (AWS stb.)

Kb. ezek lennének az elvárt funkciók:

https://www.barracuda.com/products/data-protection/backup/features

trey @ gépház

Nem tudok minden kérdésre hiteles választ adni, de ami részét ismerem arra vonatkozólag:

  • milyen storage-dzsal?

Ha a kérdés Proxmox host-ra vonatkozik, akkor az összes támogatottal, mert a Qemu kezeli a dirty bitmap-et, a választott starege-től és tárolási formátumtól függetlenül. Én ZFS-t, Ceph-et (ezek natív blokk tárolók, zvol és rbd) és NFS-t (qcow2 fájlokkal) használok különböző rendszereken, mindegyiken kifogástalanul működik a Qemu CBT funkciója, így a különbözeti mentés.

  • a videóban elhangzanak a snapshotok miatti lassulások

Proxmox-ban is a tárolóra jellemző snapshot jellegzetességek élnek, azokon nem ront vagy javít. Aki snapshot-okra épít, válasszon olyan tároló megoldást a sok támogatott közül, ami ehhez igazodik. ZFS-en, Ceph-en natív, lassulást nem okozó snapshot van a CoW működés miatt. File tárolásnál (pl. lokális FS vagy NFS) az ilyenkor default qcow2 formátumnál natív, lassulást nem okozó snapshot funkció érhető el. LVM esetén az LVM snapshot működéséből adódóan tapasztalható lassulás, az nem javasolt tartós snapshot megőrzésre, csak átmenti (pl. backup) snapshot-hoz.

  • ha van CBT, akkor végképp nem értem a folyamatos panaszt a videóban a lassú backup-ra, főleg, hogy az is elhangzott, hogy SSD-kre mentenek

Ez én sem értettem a videóban. A mentés kifejezetten gyors, pláne, ha a normál üzemi inkrementális mentést nézzük, nem az első teljeset. Egy átlag szerver átlag napi változását 1-10 perc alatt menti az általam látott rendszereken. Az tény, hogy egy host-ról egyidőben egy VM mentése történik. Párhuzamosság csak több host esetén van - pontosan a teljesítmény problémák elkerülésére.

  • hogy MSSQL-t, Exchange-et stb. tud menet közben alkalmazás szinten, konzisztensen menteni

Ez gyári képességként, konkrét alkalmazásokra deklaráltan, pontosan így nem szerepel. Az a lehetőség adott, hogy a Qemu agent-tel a snapshot készítés előtt és után tetszőleges művelet végeztethető, így oda be lehet fűzni bármi műveletet, ami az ilyen alkalmazások diszken lévő adatait konzinsztenssé teszi a snapshot-ban. MySQL-re van is példa (memória flush, read lock a táblákra a snapshot idejére), annak analógiájára nagyjából minden appra lehet valami megoldást találni. Nyilván ez plusz munka ahhoz képest, mintha ez teljesen automatikusan történne. De a lehetőség legalább adott.

  • tud-e LiveBoot-ot (magát a deduplikált mentést elindítani virtuális gépként)

Van live restore funkció. A VM azonnal elindul mentésből közvetlen felcsatolt meghajtókkal, a háttérben pedig folyik a szekvenciális visszaállítás, majd átvált a visszaállított diszkekre a rendszer automatikusan. Nyilván a restore alatt korlátozott az IO teljesítmény.

  • kvázi folyamatos mentést a kritikus szerverekről

Ilyent tudtommal nem tud deklaráltan. Nagyon gyakori mentésre képes a blokk-változás követés miatt, de egy kvázi szinkron shadow VM-re sem a Proxmox, sem a hozzá tartozó backup nem képes. A roadmap-en fent van a shadow VM funkcionalitás, nyilván erre építeni még nem lehet, de várható a megvalósulása.

  • offsite vaulting-ot

Ha ezalatt azt értjük, hogy egy offsite backup szerverre konszolidálható-e több (akár különböző helyen lévő) onsite backup szerver másolata, akkor igen. Támogat namespace felosztást a Backup Server, így bármennyi másik, akár azonos VMID-t használó backup szerver átszinkronizálható egyetlen távoli backup szerverre.

  • replikációt földrajzilag máshol levő Proxmox Backup Serverre (mintha ez lett volna kérdés és a válasz az volt, hogy tudja), Proxmox által kínált saját felhőszolgáltatásba (fizetősben nyilván), publikus felhőszolgáltatókhoz (AWS stb.)

Igen, van benne sync job, ami egyelőre csak pull módon tud működni (roadmap alapján tervben van a push sync lehetőség, mert igény lenne rá). Természetesen ez is különbözeti, hatékony, gyors.

 

Felhős tárolókat natívan nem támogat, és az egész mentési adat kezelési módja alapján nem is javasolják csak gyors, fájl szintű elérést adó tárolón használni. Ellenben szalagos mentést beépítetten támogat az offline mentés megvalósítására. Nyilván ha fel-mount-olok FUSE-val egy S3-at, B2-t vagy bármi mást, ami fájl szinű hozzáférést ad, akkor működni fog vele, csak csapnivaló teljesítménnyel.

Kösz.

Aki snapshot-okra épít, válasszon olyan tároló megoldást a sok támogatott közül, ami ehhez igazodik. ZFS-en, Ceph-en natív, lassulást nem okozó snapshot van a CoW működés miatt. File tárolásnál (pl. lokális FS vagy NFS) az ilyenkor default qcow2 formátumnál natív, lassulást nem okozó snapshot funkció érhető el. LVM esetén az LVM snapshot működéséből adódóan tapasztalható lassulás

Érdekes, hogy a videóban pont a ZFS-re és a Ceph-re panaszkodtak snapshotok miatt és az LVM-et dicsérték.

Ez én sem értettem a videóban. A mentés kifejezetten gyors, pláne, ha a normál üzemi inkrementális mentést nézzük, nem az első teljeset.

Igen, CBT-szerű funkció megléte esetén ennek nem kéne gondnak lennie. Mondom, én egy SATA RAID50-re mentek, 1Gbites hálózaton, a mentések a legtöbb szerveren nem tartanak perceknél tovább.

Egy átlag szerver átlag napi változását 1-10 perc alatt menti az általam látott rendszereken. Az tény, hogy egy host-ról egyidőben egy VM mentése történik.

Itt akár 8 konkurens mentés is mehet, ráadásul a mentett eszközök sem local SSD-k, hanem FC és iSCSI SAN-okon levő SCSI és néhol SATA diszkekből álló RAID tömbök, vagyis nem száguldó paripák és mégis megvannak gyorsan.

Amiket írtál, az alapján lehet összerakok valamikor egy laborkörnyezetet, ha nagyon ráérek. Hogy mi lesz a VMware-rel, az kérdéses, nem árt, ha van B, C és D terv.

trey @ gépház

Pont azért írtam le amit tudok róla tapasztalatból, hogy felkeltsem az érdeklődést a kipróbálásra.

Nem szeretnék senkit megtéríteni, nem gondolom, hogy a Proxmox rendszer a világ legjobb megoldása virtualizációra, de annyira bőven-bőven jó, hogy mindenki számításba vegye kis-közepes rendszer esetén.

Nekünk, akik kis rendszereket készítenek (szóló hosztok és pár gépes klaszterek), üzemeltetnek, nagyon nagy javulást hozott minden téren a jellemzően free ESXi és hulladék Hyper-V után.

Ha sorra kerül a teszt valamikor, majd érdekelne a tapasztalatod, ami a téma másik (fizetős, enterprise) oldaláról közelít, nem az ingyenesség felől.

Önmagában a Proxmox-szal szemben semmi ellenérzésem nincs, nekem az adat biztonságos tárolása és mentése (mivel 95%-ban Windows, MSSQL, Exchange és társai vannak a látókörben, nem árt, ha ezeket érti a mentőszoftver app-aware szinten) a kérdéses. Eddig a VMware-nél teljesen beváltak a brand storage gyártók FC/iSCSI storage-ai, általában RAID6+spare redundancia megfelelő adatbiztonságot hozott, az FC elegendő sebességet, a kiajánlott LUN-ra ment VMFS, aztán jól van. Minden full támogatott.

Legnagyobb "izgalom" a 15+ év alatt néha egy-egy diszk elpatkolása volt, de RAID6 + spare + full vSphere környezet mentése esetén ez az ingerküszöböt sem érte el.

Ehhez képest ez a Ceph nekem a hírhedt HP Lefthand-re hajaz, ami meg minden volt, csak a stabilitás büszke jelképe nem. Nekem szerencsére nem kellett sosem élesben üzemeltetnem (csak laborban), de hallottam egy-két nagyobb magyar cégnél komoly adatvesztésekről vele kapcsolatban.

Szóval érdekel, de csak alapos tesztelés után tennék rá valami éles szolgáltatást.

trey @ gépház

Abszolute egyetértek, én hasonló cipőben járok.

 

Ami a VMware-nél pöcc-röff megbízhatón működik, az másnál nincs meg - és/vagy csak nekem nincs elég tapasztalatom vele.

 

Amit szeretnék látni és megvalósítani más (open-source) virtualizációval:

(közös) Storage - FC - ESXi - VMFS

Ez az architektúra husszú éveken át bizonyított megbízhatóságban és sebességben is.

Van ezzel versenyezni tudó alternatíva VMware-en kívül?!

 

Mert amit én (egyelőre) látok/olvasok az NFS.

Ami sajnos egyátalán nincs pariban a fent vázolt architektúrával sem sebességben sem megbízhatóságban.

2x10Gb Etherneten a sebesség talán közelít, de latency-ben már biztosan nem...

a megbízhatóség meg... hát. izé.

zrubi.hu

Kb. az a konszenzus, hogy legyen külön a Ceph, labor/teszteléshez minimum 5 node-dal (éleshez 9-et is írtak). 100G hálózat, nyilván redundánsan. Ez 9 vas, enterprise NVME SSD-kel, hogy ne legyen lassú.

Ezzel még csak ott vagyok, hogy van egy valamirevaló, működő storage-om. Unsupported. Mert ugye, ha támogatottat akarsz, akkor azért is csengetni kell.

Nem látom ez hol lesz olcsóbb elsőre, de neki kéne állni számolgatni.

Ezek a "majd a Ceph belemegy a Proxmox node-ba jól" izék nekem felejtősnek tűnnek ...

trey @ gépház

Nem látom ez hol lesz olcsóbb elsőre, de neki kéne állni számolgatni.

Egyre inkabb ugy latom, hogy ~sehogy.

Most vagy az van, hogy a Broadcomnal fogyatekosok dolgoznak, vagy eppen hogy nem, es pont jol tudjak, hogy mennyit er a vmware stack. Lehet, hogy az alternativa picit olcsobb, na de, mondjuk ha 10%-ot faraghatnal a TCO-n valami barkacs megoldassal, akkor lecsereled a szakembergardat, es ramesz a 10%-kal olcsobb, de ismeretlen megoldasra? 

Nyilvan elsosorban penztermelo kornyezetrol beszelek, nem lab rendszerekrol. 

Hát igen ... Sajnos a TCO-ba beleszámít a 10 doboz által fogyasztott villany, a szar összereszelése, laborozás, a bekerülési ár, a az üzemeltetők kiképzése és oktatása stb., a nem létező support hiányában az problémák megoldásának keresésére fordított idő stb.

Ehhez képest egy vSphere stack + brand storage egy turnkey megoldás.

trey @ gépház

Amit szeretnék látni és megvalósítani más (open-source) virtualizációval:

(közös) Storage - FC - ESXi - VMFS

Ez az architektúra husszú éveken át bizonyított megbízhatóságban és sebességben is.

Van ezzel versenyezni tudó alternatíva VMware-en kívül?!

Openstackkel is lehet próbálkozni, kismillió FC-s storage-t támogat (illetve konfigurál, támogatni a Linux/KVM-nek kell). Mivel gyakorlatilag egy KVM frontend, ezért a megbízhatósággal nincs baj.

most szolok. ha azt varod hogy a 30 node-os vmware clustert (+benne elerheto osszes vmware ficsorrel) akarod atrakni pve ala, akkor csalodni fogsz! nem fogja tudni.

ellemben ha egyeni (solo esxi) vagy kis (2-3...6) clustereket (ahol nincs kihasznalva az osszes vmware ficsor) kell atmigralni, azt a szintet megugorja.

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

Rendszer kérdése.

Egy példa: fut 114 hypervisoron ~5200 gép az egyik helyen, mentve is van, kevés gond van vele 4 éve lett migrálva (vmware -> proxmox). A trükk abban van, hogy előre definiálni kell mi a szolgáltatás, ebben az esetben itt a virtuális gépek container backendek és a valódi fronted szolgáltatások kubernetes alól vannak menedzselve, és esetenként még külső erőforrás (compute) is be van vonva a cloud-ból). A megoldás akkor lehetővé tette a rendszer teljes frissítését (network, hypervisorok) abból a spórolt pénzből amit nem kellett kifizetni a vmware upgrade miatt (plusz ami eredetileg volt rá). Az addigi rendszer helyett 130% nagyobb kapacitást kapott a felhasználó. Mivel a migrálást úgy kellett kezdeni, hogy leválasztottunk a vmware-ről elemeket és ott lett kiépítve az alternatíva (pilot) elmondható, hogy maga a termékváltás akkor kb 15-20% kapacitás előnyt hozott azonnal (ezért is bólintottak rá). 
Azóta két nagyobb rolling update volt a virt rendszeren és 1 a kubernetes orchestatoron. A rendszer támogatja a hypervisorok on demand leállítását (izoláció) és kapacitás igény esetén automatikus elindítását a  költséghatékony működés okán, valamint az egyes igények költséghelyéhez rendezését. Az átállás 4 hónapot vett igénybe, ennek része volt az, hogy in place kellett cserélni. Leállás egyszer volt 10 órára amikor a hálózati elemek cseréje történt, és így lehetett megszervezni. 

( zrubi v | 2024. 06. 26., sze – 16:25 )

Szerkesztve: 2024. 06. 26., sze – 16:26

Én mondjuk a belső lab körnezetünkben most xcp-ng az ami tesztelek.

Ez Xen hypervisorra épít, és architekturálisan sokkal közelebb van a 'megszokott' VMware megoldásaihoz.

A hypervisor részével nincs is gond, hiszen már nem mai gyerek ;) - és nem utolsó sorban évek óta használom desktopon a Qubes OS által.

 

A kérdéses részei inkább a:

- központi management, itt Xen Orchestra Appliance (XOA), ami elsőre jónak tűnik...

- központis storage, ami úgy néz ki csak NFS :(

- virtuális hálózatkezelés, amiről még lövésem sincs, de rajta vagyok :) 

zrubi.hu

- központis storage, ami úgy néz ki csak NFS :(

VMFS után ez úgy hangzik mint lézerkard vs. fakard :D Persze, lehet, hogy csak prekoncepció. :D Én NFS-t sose használtam semmire élesben, mert annyit olvastam arról, hogy egy lassú fos, hogy nem is volt kedvem sose azzal szopni.

trey @ gépház

még a Netapp-os időkben használtuk/tettük ki ügyfélhez VMware-t NFS-es közös storage-val, de nyilván csak az occsósága miatt, hiszen ahhoz nem kellett FC, és a vele járó licenc költségek. 10Gb Ethernet szintén csak álom volt ;)

 

De nyilván VMFS-hez képest elég gagyi... de azért használható élesben is.

(de ennél persze még mindig sokkal jobb az iSCSI LUN-on VMFS)

 

xcp-ng is támogat egyébként Ceph storage-et, de ugye az megint egy külön állatfaj. + üzemeltetési költségekkel.

block device-ként ott van persze az FC, iSCSI mint lehetőség, de az ugye local storage-ként jelenik meg a hypervisorban, szemben a jól bevált közös VMFS partícióval...

zrubi.hu

Én is xcp+XOA-t tesztelgettem. Az OVMM-es XEN implementáció után kellemes csalódás volt. Viszont vannak vele olyan apróságok hogy például vm konzolt csak beágyazott van. Valamint vannak nem olyan nagyon apróságok, hogy ilyen elcseszett user kezelést a világ még nem látott, ha épp AD vagy LDAP-ba próbálod bekötni. Plusz a VM-eket és objektumokat tudod taggelni, de ACL-t már tagre nem tudsz tenni, minden ACL-be bele kell külön tenni a gépeket.

Ez utóbbi kettő elég fájó pont ha sok üzemeltetői osztály van. Amúgy tényleg jó cuccnak tűnik, de ez a kettő elég deal-breaker.

Plusz airgapped telepítés nem egy kéjmámor, sok hekkelés van vele, de ez a 6-osnál már elméletileg változik.

FC SAN-t úgy tudom kezel, odáig nem jutottam el. Hálózatkezelés meg ugyanaz mint a többi XEN: bonding, vlanok és tud valami SDN-szerűséget is.

"- központis storage, ami úgy néz ki csak NFS :("

 

Mióta megjelent azóta használom iscsi-val és FC-vel. Az XCP-NG a Citrix xen szerver forkja. Akkor váltottam rá Citrix Cen szerverről amikor  a Citrix változtatott a játékszabályokon, és forkolták belőle az XCP-NG-t.
Kisebb igényekre elég stabil, nekem most egy 4 node-os clusterem van, Storwize v5000+iscsi-val , de  nagy vmware farmok kiváltására szerintem felejtős.

Teljesen stabil, iSCSI és FC multipath is teljesen jól működik (gyakorlatban is teszteltem - simán lekezelt egy storage controller halált).

Korábban az IO teljesítménnyel kapcsolatban voltak  fenntartásaim (egy vdi IO kezelése single threaded volt, ami egy adott VM-en belül bottleneck volt), de utóbbi időben mintha ezen is javítottak volna.

Ami igazán problémás szerintem az, hogy az  iscsi és FC blokk storage-ot csak thick provisionnal tud. A blokk storage-et CLVM -el kezeli. (Clustered LVM). Az egyes virtuális diszkeknek külön LVM volume-okat allokál.
Emiatt a snapshotolás zabálja a helyet. A dokumentációban ezt ki is emelik, és ezt célszerű komolyan venni. Snapshot létrehozásakor beallokál neki ugyanannyi helyet mint a teljes volume. Olyan környezetbe totál alkalmatlan, ahol nagy tételben folyamatosan megy a snapshotolás. (Vagy kell alá rakni 5 szörös storage kapacitást.)
Ha valami nagyon fáj ebben a történetben, akkor szerintem ez az.

A xen orchestra nem rossz elég gyorsan fejlődik, úgy látom már árat is emeltek - korábban volt free verzió, most már nincs, kíváncsi vagyok, hogy a githubból összerakott verzióban benne van -e minden feature. (Nekem egy viszonylag régi, forrásból összerakott verzió van -kizárólag a mentések/visszatöltések miatt, az a része már N+1 éve is elég jól működött.)

CBT-t elvileg tud a Xenserver, gyakorlatilag nem látom, hogy XCP-ng bárhol használná.  CBT támogatás jelenleg a "mikor lesz? - nincs szükség rá" témáju fórum topicok szintjén tart.

Ami egyébként nekem nagyon bejött, hogy teljesen jól működik a "nothing shared" migráció. Amikor mondjuk a komplett infra cserélve van (szerverek és storage) akkor a régi clusterből akár egy SSH tunnelen keresztül is át lehet migrálni a vm-eket az új alá - akár futás közben is.

korábban volt free verzió, most már nincs

De, továbbra is van free verzió, csak nem reklámozzák... sőt eléggé erőltetik a regisztrációt (csak így kapsz frissítéseket) és nyilván hogy vegyél előfizetést, amiért meg support-ot kapsz.

 

A telepítése változott: most (a 8.2) xcp-ng hypervisor web felületéről online lehet telepíteni az XOA appliance-ot. (ingyen és reg nélkül)

 

Emellett fordíthatod magadnak is forrásból, de azt nem ajánlják :D - csak annak aki tudja mit csinál.

És - elvileg - minden (ingyenes) fícsör ugyan úgy benne van:

https://xen-orchestra.com/#!/featuresmatrix

zrubi.hu

A forrásból felpakoltban korábban benne volt az is, ami a free-ben nem.  Gondolkoztam, egy starter előfizetésen de a "Smart backup" nevű feature-t még abba sem rakták bele, a githubból forgatott verziómban meg benne van. (Ez konkrétan azt tudja, hogy beállíthat az ember szabályokat, mik alapján alapból ment minden újonnan létrehozott VM-et, nem kell külön nevesíteni a mentendő VM-eket...)

A forrásból felpakoltban korábban benne volt az is, ami a free-ben nem

Ezt sem reklámozzák - de azt ígérik - hogy a technikai fícsörök mind benne vannal a publikus forrásban.

Szóval, aki 'megugorja' a forrásból fordítást és a VM image csomagolást, az használhatja is az összes fícsört.

ebből adódik az is, hogy nekik/neked biztosan nincs is szükségük technikai segítségre sem :)

Persze 'lepapírozás' célból kellhet a support egy céges/produktív felhasználásnál

Szerencsére, nekem árakkal nem kell foglalkoznom, így nem is tudom/akarom ezeket összehasonlítani.

De az egyelőre körvonalazódni látszik, hogy amit a VMware letett az asztalra, azt - technikailag - más nem nagyon tudja kiváltani - occóért/ingyen legalábbis biztosan nem.

 

viszont  az open source hozzáállásuk mindenképp tetszik - de kétlem, hogy ezzel a modellell egyátalán életképesek tudnak maradni hosszú távon :(

zrubi.hu

Ok, értem, köszi. Utóbbi években mem nagyon foglalkoztam vele, elketyegett a gépterem sarkában, de lassan érik a komplett infra csere... én meg leginkább azért vagyok hajlandó fizetni, amit nem tudok/nincs kedvem/nem akarok/nincs időm  magam megcsinálni.

Dolgozom vmware-el is, enterprise környezetben 30+ node-os clusterekkel, úgyhogy pontosan tudom, hogy feature-ok tekintetében saját ligájában egyedül focizik.

A Broadcom pontosan tudja ezt, amikor tavaly megvették, pontosan lehetett tudni, hogy ez lesz a vége.  Megvették drágán, és most kifacsarnak belőle mindent amit csak tudnak. A target ügyfelek a Top500 cégek, aki ha akarnak sem tudnak váltani 1-2 éven belül. pont. Most megy a vendor lock-in monetizálása. Legtöbb esetben nem arról van szó, hogy ingyen kell valami, hanem az egyik évről a márikra brutálisan megemelkedett licensz költség helyett kell valami ami kevésbé drága.