Na tento článek se těším. V minulosti jsem používal jak ještě původní Xenserver, tak Proxmox VE. Obě měly svoje nevýhody, porodní bolesti.

Zatím budu hodnotit po teoretické rovině Features a dole v článku se možná podělím i s autentickou instalací na domácí testovací síti.

Lifecycle, doba Long Term Support verze?

Výsledek tedy 1:1

zdroj Proxmox zdroj XCP-NG

Umí HA?

Ano, oba.
Výsledek 1:1

A co Upgrady?

XCP-NG je doporučen stroj po stroji master release version (např. z verze 7.5 na 8.2 ) upgrade „ručně“ pomocí .ISO instalačního image a zvolit možnost upgrade. (budu to tu nazývat VMwarovská cesta). Minor-release update lze dělat příkazy za provozu.
(Minor-release update myšleno např. mezi verzemi 8.0 – 8.2)

Proxmox-VE má stejný upgrade jako Debian, což je sympatičtější cesta, než v případě XCP-NG.
Tady dávám vítězství 1:0 Proxmox nad XCP-NG.

Podpora distribuovaných filesystémů?

NFS a něco dalšího? GlusterFS? Ceph?

Začnu XCP-NG, mají na webu pěknou tabulku. Pro vysvětlení Thin Provisioned: používáte jen to zabrané místo, které vaše VMka zabraly. Thick provisioned: používáte „předrezervovanou“ velikost VM, ačkoliv třeba drtivá většina VM má 80% prázdného místa, to místo bude alokované a zabrané.

Proxmox-VE má taky tabulku na webu:

Tady prakticky nemohu hodnotit, protože každý z vás to bude patrně provozovat v jiné storage konfiguraci. Čímž se dostáváme k tomu, že bych toto review zabil tím, že bych třeba upřednostnil ZFS, GlusterFS, nebo Ceph či ZFS over iSCSI, přičemž někdo, kdo bude mít use case s BTRFS by zde automaticky sáhl po Proxmoxu, někdo, kdo zase chce MooseFS, nemá na výběr a musí sáhnout po XCP-NG protože Proxmox ho vůbec nezmiňuje, o nativních typech storage (Proxmox Backup vs. XosanV2) se rovněz nemůžeme bavit, protože se jedná o proprietární záležitost každého řešení.

Současně obě tabulky jsou ve finále rozhodující a limitující pro obě technologie.

Podpora HCI (Hyper-Converged Infrastructure)

Co je to Hyper-Converged Infrastructure?
Oba. Tedy zase s výsledkem 1:1. Jak Proxmox, tak XCP-NG. U Proxmoxu musíte mít pro Hyper-Converged Infrastructure (dále jen HCI) buď Ceph, nebo ZFS. HCI podporuje samozřejmě i XCP-NG, jen byste měli mít Ceph a XCP-NG Storage Manager Plugin For Ceph.

Ceph vs. GlusterFS?

Oba dva jsou distribuované souborové systémy. A oba dva jsou podporované oběma porovnávanými virtualizačními platformami.

Dejme si malou nalejvárnu zde:

A odložím si tento odkaz. Za mě se budu článkům o Cephu a Glusteru věnovat ještě v příštích článcích, nicméně obě technologie podporují jak Gluster tak Ceph, což je dobrá zpráva.

Odložím si tu odkaz i na některé diskuse na téma Ceph vs. ZFS. Poběží Ceph na 1Gbps lince? Ano, ale časy pro zrekonstruování/rebuild pole bude delší. GlusterFS mám na 1Gbps linkách otestovaný a běželo to v pohodě.

Instalace XCP-NG vs. Proxmox

U obou z nich dojdete na web výrobce, stáhnete instalační image, nainstalujete. U XCP-NG vidím v návodu i sekci, kde si můžete rozběhat vlastní pxe boot server pro hromadné zprovozňování mašin na síti.
Narozdíl od XCP-NG však Proxmox můžete začít po instalaci hned používat, už se můžete vrhnout na namapovávání storagů, zatímco u XCP-NG musíte teprve řešit rozběh XenOrchestra pro web UI.

Instalace jednotlivých nodů

Samotná instalace jednotlivých nodů je na obou technologiích stejně jednoduchá. Tedy zase 1:1. Stáhnete instalační .iso image, nabootujete instalátor, vyplníte instalační formuláře, odkliknete nějakou instalační licenci, doplníte jméno a heslo, dokončíte instalaci, rebootnete, nabootujete a běží vám noda připravená pro další využití.

Rozběh clusteru

V případě XCP-NG, tady přichází buď subjektivita, nebo nějaký bug, se kterým jsem se ale setkal i na diskusních forech na XCP-NG.
Měl jsem 50 GB virtuálky, tedy mělo by tam být opravdu hodně místa. Při deploymentu XOA (xcp-ng Orchestra Agent) do hlavní nody mi to zařvalo VDI_ERROR. Tady jsem chvíli googlil, pak jsem se dozvěděl, že z nějakého důvodu je na nodě asi jen 2GB volného místa a na XOA agenta je potřeba 20GB, ačkoliv jsem tam měl 50GB místa. Kam se všechno místo ztratilo, netuším. Proto jsem poučen z této chyby zkusil proxmox, ale raději už se 100GB nody, aby se situace neopakovala z podobných důvodů.

XCP-NG jsem na první dobrou nedal. Proxmox jsem na první dobrou dal bez jakéhokoliv šmejdení v dokumentaci. Smekám klobouk. Tedy 0:1 ve prospěch Proxmoxu. Rozběhat cluster na proxmoxu zvládne i slepice s rozsypaným zrním kolem levého tlačítka myši. V případě XCP-NG si s tím možná ještě někdy zase pohraju, ale dneškem zvítězil Proxmox.

Videoukázky implementace

Protože mi XCP-NG dělal problémy, tak jsem sem nakonec hodil úspěšnou implementaci na verzi 8.1. někoho jiného.

Časem zde možná doplním instalace obou ve virtuálce. Mám to natočené, jen nenastříhané.

Praktické používání vítěze

I proxmox má své chyby, ať tu tento článek nevyzní, že proxmox je dokonalý a xcp-ng je odpad, což tak rozhodně není.
Jedna ze 7 nod na proxmoxu mi po startu odmítá naběhnout, upgrade trvá nesmyslně dlouho, když mi tato noda vypadne, tak z nějakého důvodu nejdou přidat další nody, protože to hlásí, že zrovna tato noda je nedostupná a nemohu kliknout na join cluster pro získání informace pro připojení ke clusteru. (Ano, lze to řešit jak příkazy, tak uložením bokem někam fingerprintu pro připojení další nody do clusteru, ale obtěžuje to).
Dále CEPH je sice na můj vkus již docela odladěný a dobře integrovaný v Proxmoxu, takže nemusíte chodit nikam do terminálu a všechno si intuitivně naklikáte, což je určitě fajn. Jen kdyby to na testované gigabitové síti se 7200 otáčkovými disky nebylo tak příšerně pomalé. Na testovací virtuálce s Windows 11 jsem se dostal na 109MB/s čtení (zhruba kapacita 1Gbps sítě, zkusím přidat 2x1Gbps na zkoušku, jestli se to zrychlí) a jen cca 20 – 22MB/s zápis (což byl asi největší zádrhel), když jsem přidal 9 OSD datových nod, kam proxmox ukládal své data napříč 4 fyzickými stroji (3 stroje x 2 disky, 1 stroj x 3 disky) za stejným gigabitovým rackovým switchem. Nicméně nezkoušel jsem Ceph s SSD disky, kde bych mohl rozhodně dojít k lepším výsledkům (asi bych stejně narážel na rychlost 1Gbps sítě). Předběžné výsledky 1x1Gbps připojení na 7 mašin, z toho 4 z nich jsou fyzické, jsem naměřil tyto výsledky. Čtení by šlo, zápis mi připadá jako mizérie. Nechám proto na zvážení, zda-li se někomu nevyplatí mít 3 možné modely fungování.

Jedna z věcí, které mi vadí je, že stejně pro produkci budete potřebovat enterprise repozitáře, ačkoliv můžete použít pve-no-subscription a no-subscription Ceph repozitáře, které jsou testované komunitou, tak nikdy nebudete mít záruku, že všechny updaty budou bez problémů. Nicméně i přesto je to stále řešitelné např. tím, že budete mít dev cluster, ten upgradujete jako první a když vše proběhne v pořádku, tak dáte upgrade produkčního clusteru. Ale ta šance, že se něco rozbije tam bude asi pořád, dokud si nepřiplatíte za enterprise repozitáře, což nejsem schopen zařadit jasně mezi plusy, nebo mínusy. Plus je, že pro používání proxmoxu nemusíte nikomu platit. Pokud jste firma, tak je naopak velké plus, že můžete ušetřit za neprodukční mašiny pve-no-subscription repozitáři zdarma, zatímco na produkční stroje dáte pve-subscription repozitáře, každou produkční mašinu opatříte subscription kódem za $105/CPU socket ročně a získáváte tak updaty připravené a testované pro produkční clustery, což se vám jakožto firmě může rozhodně hodit.

1. Proxmox + Ceph + 10Gbps síťové karty + SSD disky
2. Proxmox s lokálním úložištěm a odlévat zálohy jinam (to může být problém, pokud není dostatek kapacity.
3. Proxmox s jakýmkoliv SANem/NASem, kam to ukládá všechna data virtuálek (ideálně aby NASka jela na SSD discích) a pravidelně odlévat zálohy či replikovat na jiné stroje, takže v případě pádu NASky by se díky HA (High Availability) jelo dál.

Z těch pozitivních věcí, které za posledních 10 let proxmox odladil, je live migrace virtuálek napříč fyzickými stroji. A skutečně jsem byl schopen prvně live přemigrovat virtuálky ze strojů, které budou přestěhovány fyzicky a následně po live migraci vypnout a přestěhovat fyzické stroje z místnosti do místnosti a skutečně mi nespadl rdesktop na testovací VMko, ani nepropadl jediný ping. Smekám klobouk.

Screenshoty Proxmox Clusteru

Závěr

Nelze to vidět černobíle a nelze házet XCP-NG ze skály za to, že jsem měl problém při rozběhu clusteru a že na můj use case, mi nevyhovuje používání major verze upgradů řešení. Stále je to řešitelné iPXE boot serverem, kde server, který má web management (nebo nějaké IPMI/IMM/iDrac/iLOM atd…) lze ovládat přes vzdálenou správu, během toho server rebootnout, provést ruční upgrade přes nabootované .iso z pxe boot serveru ze sítě a takto to provést server po serveru. Bude to patrně náročnější na celkovou správu, když budete mít třeba 500 serverů, tak každý jeden po druhém upgradovat. Nicméně i tak jsem přesvědčen, že si to svůj use case najde.

Za mě jsem XCP-NG opustil z následujících důvodů:

1. Běží to na něčem blízkem RHEL 8.x kernelu (4.19 kernel) (neumí DNF, ale yum) (Proxmox 8.x má debian 12 s novějším kernelem 6.2)
2. XenOrchestra je pro managování základní věc a není v základu, musí se to tam doinstalovávat. (Zatímco Proxmox má v sobě integrovaný web management a nemusím nikde nic instalovat. Pricing je pořešený přístupy do enterprise repozitářů, které nemusím používat)
3. Mašiny musí mít přístup do internetu, aby si tu xenOrchestru stáhly a nainstalovaly. Když přístup nemají a běží v separované vlaně, tak je problém. (Proxmox lze stáhnout a rozběhat i někde v izolované síti bez internetu, anebo si zkopírovat repozitáře a poskytnout je proxmoxím strojům. Domnívám se, že podobně by to asi šlo s repozitáři i pro XCP-NG, ale s XOA agentem bez internetu nic neudělám a jsem tím pádem závislý na vývojářích a třetí straně)
4. Neumí to deploynout stroj už od začátku, aby uměl vícero VLAN. Ale dejme tomu, na některé provozy to může stačit. (proxmox též ne, ale po doinstalování, jsem schopen další VLANy přidat buď přes web management, anebo přes terminál. Domnívám se, že XCP-NG to bude taky umět přes příkazy, když mi to nejelo, už jsem po tom dál nepátral a pro testovací síť to ani nebylo potřeba)
5. Upgrade major release pouze přes reboot a deploy přes .iso image (řešitelné to je pomocí PXE bootu přes pxe-server), ale i tak se tu bavíme o deploymentu pro velká prostředí, jinak XCP-NG prostě nemá v tomto pro můj use case vůbec smysl. (Zatímco Proxmox provedu update/upgrade minor i major release přes internet více méně bez problémů a pak už jen řeším reboot, nemusím kvůli tomu lozit na web management/IPMI/iLOM/iDrac/IMM mašiny)
6. Na management se dostanete přes Windowsího klienta, nebo přes webovou administraci, ale tu musíte mít přes ten deploynutý xenOrchestra, který je přístupný jen z webu, jestli jsem pochopil správně. Takže jste stejně závislí na webu třetí strany, anebo to stejně budete ovládat přes xe commandy „nouzově“. (Tady jednoznačně vítězí za mě Proxmox. Jednotný web management, není závislý na nikom, cluster lze spravovat z kterékoliv mašiny, tady už je to za těch cca 10 let velmi odladěné)
7. Deployment Xen Orchestra mi skončil erorrem DEVICE I/O Error na nejnovější verzi. Tady to řeší v nějakých diskusích a je to častý error u různých operací na XCP-NG.
   https://xcp-ng.org/forum/topic/2991/vdi_io_error-device-i-o-errors-when-you-run-scheduled-backup/42 (Proxmox měl více méně jen jednu drobnost, na kterou napíšu samostatný článek, ale řešení bylo velmi snadné)
   https://xcp-ng.org/forum/topic/4275/xoa-web-deploy-stuck-at-deploying-xoa-no-error/23
   
   Závěr pro mě je: odmítám s XCP-NG dál ztrácet čas, drawbacků už je pro mě na XCP-NG tolik, že to nemá smysl se tím dál zabývat.