Na trhu s virtualizací je v poslední době živo. Broadcom po odkupu hlavní síly v oboru v podobě firmy VMware (transakce za 69 miliard dolarů) řadě zákazníků výrazně zvedl ceny a nyní se specializuje hlavně na ty největší. Trh se začal dívat po alternativách. Někdo vzal na milost Hyper-V od Microsoftu, když už je zdarma jako součást Windows Serveru, někdo rozjel testování nových VM Essentials od Hewlett Packard Enterprise (HPE), a zbytek zaregistroval 17 let fungující open source nástroj Proxmox.
Proxmox jakožto virtualizační platforma zažívá rozkvět. Někteří zákazníci dlouho odkládali upgrade na novější verze VMwaru a nyní raději volí otevřenou alternativu. Další várka zákazníku je kvůli zdražování a změně licencování naštvaná na VMware, respektive Broadcom. Proxmox je ve správný čas na správném místě.
Díky tomu, že je Proxmox open source, se může zajímavě a někdy velmi rychle rozvíjet, a to nejenom skrze rakouskou firmu Proxmox Server Solutions, jejíž zakladatelé Proxmox rozjeli. Ukázkovým příkladem jsou čeští odborníci, kteří upravili zdrojový kód, násobně zrychlili obnovu zálohy z Proxmox Backup Serveru (jedna ze součástí Proxmoxu, určena je pro zálohování) a následně tuto inovaci poskytli celé komunitě.
Obnova dat za týden?
Toto výrazné zrychlení obnovu zálohy řešila pražská konzultační společnost NOT NULL Makers společně s cloudovým poskytovatelem ČMIS. Právě ČMIS patří mezi ty, kdo po změně licencování začali místo VMwaru nasazovat Proxmox, a to i pro enterprise zákazníky. ČMIS používá několik zálohovacích systémů a například skrze Veeam dokáže obnovovat data rychlostí až 3 GB/s. Oproti tomu Proxmox Backup Server zvládal jen 200 až 300 MB/s. Pro splnění garantované doby obnovy (RTO) ale bylo nutné výkon dostat minimálně na 1 GB/s.
“Z počátku jsem nevěřil, že jsme jediní na světě, kdo takový problém řeší. Jak ostatní garantují RTO? Obnova 10 TB dat za 14 hodin? A to jako někdo dokáže na 100TB obnovu čekat šest dní? Byl jsem přesvědčený, že chyba musí být u nás,” řekl Lupě Václav Svátek, ředitel ČMIS.
ČMIS provedla desítky testů a koupila hardware za několik milionů. Šlo o nejvýkonnější konfigurace, které se pro dané řešení dají pořídit, tedy čistě na NVMe discích postavená enterprise storage s propustností 20 GB/s a 100Gb síťovkou. Ale i tak se výkon zvedl asi o 10 procent.
“Na technické podpoře Proxmoxu nechápali, co po nich chceme. Žádali jsme referenční architekturu, díky níž bychom mohli obnovovat data rychlostí 1 GB/s. Opakovaně nám přišla odpověď, že si máme koupit enterprise SSD disky a 10G síťové karty. Nakonec nám došlo, že v našem enterprise prostředí na výkonu hardwaru prakticky v uvozovkách nezáleží a že je chyba v samotné konektivitě Proxmox Backup Serveru,” navázal Svátek.
Zrychlení pro všechny
Problém debatovaný na LinkedInu zaregistroval Adam Kalisz, jeden ze dvou společníků NOT NULL Makers. Jeho tým po navázání kontaktu s ČMIS během dvou týdnů přišel s optimalizací kódů zálohovacího serveru Proxmoxu.
A o co šlo? Zjednodušeně řečeno, původní kód nebyl paralelizován a nedocházelo k plnému využití hardwaru, na němž nástroje Proxmox a Proxmox Backup Server běžely. Češi upravili knihovnu obstarávající obnovu virtuálních disků, vlivem čehož došlo ke čtyřnásobnému zrychlení obnovy. Z původních 200 až 300 MB/s to najednou bylo požadovaných 1 až 1,2 GB/s. Úprava změnila průběh obnovy (paralelizace) a přidala možnost pomocí proměnných upravit výkon pro obnovu. V základním nastavení je nárůst výkonu trojnásobný a úpravou počtu vláken je možné výkon zvýšit. Technické detaily naleznete níže.
Jedna z reakcí uživatelů na změny, které Češi přinesli do Proxmoxu
Toto vylepšení obdržela nejenom ČMIS jakožto zákazník, ale také komunita. Vývojáři Proxmoxu změnu v upravené podobě začlenili do hlavního projektu. K dispozici bude všem zájemcům od verze 9 a jako běžný update v aktuálně stabilní verzi 8.4. Změna je dostupná v balíčku libproxmox-backup-qemu0 ve verzi 1.5.2. Nemá žádné další závislosti, takže jí lze nainstalovat běžným updatem.
“Jsme rádi, že jsme mohli přispět komunitě a skvělému projektu Proxmox. Cesta to byla dlouhá a drahá, ale z děkovných příspěvků v diskusních fórech je vidět, že náš příspěvek byl více než vítaný,” doplnil Svátek.
Adam Kalisz proces pro Lupu popsal podrobněji:
Pro testování jsem nainstaloval prostředí složené z dvou stanic Hetzner AX52 (osmijádrový AMD Ryzen 7 7700, 64 GB RAM a dvě 1TB NVMe SSD) rozšířené o přímý 10Gb síťový spoj. Na jedné straně Proxmox Virtual Environment, na druhé Proxmox Backup Server. Testování mohlo začít nad souborovým systémem ZFS.
Vytvořil jsem jednoduchý virtuální stroj s 50GB diskem. Kromě instalačních dat jsem zajistil, aby byl plný náhodných dat. Dokud nedošlo místo na disku, zapisoval jsem 1GB soubory ze speciálního souboru /dev/urandom, který v Linuxu poskytuje nekonečný zdroj náhodných dat. Po zapsání jsem udělal zálohu, poté jsem tyto soubory smazal a vygeneroval znovu, zase se zálohou. Celé jsem to opakoval asi čtrnáctkrát, abych simuloval v podstatě nejhorší možný scénář pro zálohy.
U normálních záloh jsou míra duplicit a komprimovatelnost typicky dost vysoké. Na zmíněných stanicích Hetzner jsem se při obnově dat dostával na něco přes 400 MB/s. Díky 10Gb spoji byla dostupná propustnost sítě až lehce nad 1,2 GB/s.
Klasický monitoring neodhalil žádné vyloženě úzké hrdlo. Běžný přenos přes Netcat (což je vlastně hloupé TCP spojení) ukázal, že jedním spojením bez jakýchkoliv optimalizací přenesu 1,1 GB/s, a to včetně čtení náhodných dat z SSD a zápisu těchto dat na straně druhé. Všechen ostatní hardware byl výrazně rychlejší, takže tam úzké hrdlo nebylo.
Vše jsme velmi zevrubně otestovali, aby nebyl problém například s konfigurací. Tím jsem se probojoval někdy kolem 29. a 30. května. I Mathias Rumbold z komunity kolem Proxmoxu se mnou na své testovací infrastruktuře vyzkoušel snad všechno. Dobrali jsme se (stejně jako Václav Svátek se svým týmem) k výsledku, že problém je přímo v Proxmoxu.
Benchmark na stroji s AMD Ryzenem 7 7700
Následně jsem začal hledat v kódu Proxmoxu, jak vlastně dochází ke spouštění obnovy zálohy. Dělal jsem různé flamegraphy, měřil TCP a propustnost jednotlivých TCP spojení, a to pomocí nástrojů z balíčku jako bpfcc-tools.
Nástroj qmrestore, což je skript v Perlu, který volá mně ne zcela zřejmým způsobem pbs-restore (ten je poměrně neintuitivně zahrnutý v tomto patchi). To bylo vidět při běhu obnovy ve výpisu v aplikaci htop.
Takže jsem dál hledal v repozitářích a v proxmox-backup-qemu jsem našel toto. Bohužel byl kód napsán v jazyce Rust, kterému jsem se nikdy detailně nevěnoval. Známí, kteří jazyk umí, neměli čas. Vzal jsem to jako příležitost. Podíval jsem se tutoriál Dereka Banase a začal se orientovat v kódu.
Zálohy mezi Proxmox Virtual Environment a Proxmox Backup Server fungují tak, že se data rozsekají do takzvaných chunků, tedy relativně malých kusů dat o velikosti do 4 MB. Ty se následně dají deduplikovat, komprimovat a šifrovat. Pro informace o tom, kam který chunk patří, aby vznikl virtuální disk pro virtuální stroj (VM), je potřeba index, v němž je vše zaznamenané.
Zjistil jsem, že kritická smyčka ve funkci restore_image byla jednovláknová. Ze zálohovacího serveru se stáhnul index, připravil se RemoteChunkReader a následně se pomocí něho index za indexem chunky stahovaly a obnovovaly na blokové zařízení/do souboru, který reprezentoval disk virtuálního stroje. Pokud je chunk nulový, třeba protože reprezentuje prázdné místo na disku, tak se nic nestahuje a tento kus dat se vytvoří, což je dost rychlé. Pokud však bylo potřeba chunk stáhnout, tak smyčka pokračovala až když se chunk stáhnul a zapsal.
Další benchmark
V tomto případě jsem 8. června drobnou úpravou kódu identifikoval, že zápis na NVMe SSD má osminu latence sítě, i když mám přímý kabel mezi servery. A celkově to vypadalo, že se čeká na síť. Což bylo štěstí, protože funkce write_zero_callback a write_data_callback byly obaly nad funkcemi v jazyce C. Ty nebyly dobře připraveny na to, aby byl zápis dat snadno paralelizovatelný, aniž by si kompilátor stěžoval, že chceme přistupovat (z jeho pohledu) na stejná data, a to s nutností ošetření tak, aby se nemohla stát nějaká nepřístojnost s pamětí. Tím by mohl vzniknout například prostor pro bezpečnostní díru, nějaký souběh, který by třeba sporadicky a náhodně přepisoval data, což by se špatně debuggovalo. A tak dále.
Devátého června jsem věc detailně nad kódem konzultoval s kolegou Danielem Škardou. Náš původní záměr prostě vytvořit druhé spojení na Proxmox Backup Server a stahovat dvojnásobné množství chunků se ukázalo být zbytečně krkolomné. Stačí se dotazovat RemoteChunkReaderu, který sice pracuje s jedním, ale v té chvíli málo vytíženým spojením přes HTTP/2 na Proxmox Backup Server.
Během několika hodin jsme se dostali do stavu, že jsme s pomocí detailních instrukcí přesvědčili Gemini 2.5 Pro, které máme v rámci Google Workspace Business Standard zaplacené, aby upravilo kód tak, že vznikne thread pool blokujících threadů, které budou souběžně žádat RemoteChunkReader o stažení chunků, a že zápis na disk prozatím může být v jednom vláknu a tedy bez výhrad kompilátoru Rustu. OpenAI o3 ani různé jiné varianty ChatGPT moc nápomocné nebyly, obecně kód takto vyprodukovaný ani nekompiloval.
Ve výsledku toto řešení prosviští všechny indexy, odbaví rovnou chunky, které jsou nulové a datové chunky přidá jako takzvané futures do streamu, který poté zkonzumuje právě funkce zapisující datové bloky hned, jak se některá z futures realizuje. Vlastně se tedy naplní předpokládaná budoucnost dopředu stanoveným způsobem.
Třetí benchmark
Tento přístup vede k vysokému výkonu, hlavně s vhodnými parametry. Ale ne každý člověk, co používá Proxmox, má obrovské stroje s více procesory. ČMIS nám k testování poskytl servery s 1 TB RAM, dvanácti a více NVMe SSD a 2×100Gb síťovými spoji. Nevýhoda je vyšší paměťová náročnost a to, že se chunky vlastně nezapisují striktně po sobě, jak byly na disku. Nejdříve se zapíšou všechny nulové chunky a až potom se zapisují data.
S těmito výsledky jsme si s ČMIS schválili, že uděláme testování i na jejich infrastruktuře a kód poskytneme do Proxmoxu k začlenění. Z diskuse s Dominikem Csapakem z Proxmoxu poměrně rychle vyplynulo, že vidí řešení, které by jim vyhovovalo více. Všechny chunky řeší popořadě tak, jak jsou v indexu. Asynchronně řeší volitelný počet chunků, standardně 16 v až čtyřech vláknech, obojí je nastavitelné pomocí proměnných prostředí.
S Dominikem jsme udělali tři kolečka zlepšení. Poprvé nedopatřením použil buffer_unordered, který v této podobě pracoval v podstatě pouze, když čekal na nový chunk. V druhé verzi už Dominik startoval úlohy na pozadí pomocí knihovny tokio, která se ve světě Rust a Proxmoxu hojně využívá, takže úlohy běží i během zápisu. Jsou to takové libůstky, ale mají poměrně velký dopad na výkon.
Nakonec jsem prosil i o nastavitelnost pomocí proměnných prostředí: PBS_RESTORE_FETCH_CONCURRENCY=16 PBS_RESTORE_MAX_THREADS=4.
Další možnosti zvýšení výkonu se diskutují, například zde. Tato možnost by se týkala Proxmox Backup Serveru a pomohla by na straně serveru dodávat chunky rychleji. Výhrada Thomase Lamprechta byla, že na straně serveru by tímto mohlo dojít k vyčerpání prostředků (CPU) a potlačení jiných úloh. Podle něj by tedy měl alespoň existovat přepínač umožňující vrátit chování bližší tomu původnímu. Výhledově by mělo být možné lépe řídit alokaci prostředků, například propustnosti, ale to je mnohem víc práce.
Další úpravy jsem od této diskuse neviděl. Zdá se, že se prioritně upravují věci kolem možnosti ukládat chunky do S3 kompatibilního úložiště, což má být funkce nová v Proxmoxu 9.
- Chcete mít Lupu bez bannerů?
- Chcete dostávat speciální týdenní newsletter o zákulisí českého internetu?
- Chcete mít k dispozici strojové přepisy podcastů?
- Chcete získat slevu 1 000 Kč na jednu z našich konferencí?
Staňte se naším podporovatelem
ČLÁNKY DO MAILU