Synology VMM Pro: Optimalizace velikosti produkčního virtuálního počítače pomocí umělé inteligence (2026)

Virtuální stroj, na kterém běží tento obchod, strávil měsíce s dvojnásobným hardwarem, který potřeboval. Osm virtuálních CPU, šestnáct gigabajtů paměti a skutečná zátěž, která se nikdy nedotkla více než čtvrtiny ani jednoho z nich. To není neobvyklé. Hosta hned první den velkoryse dimenzujete, protože nemáte tušení, co bude potřebovat, web funguje a nikdo se už nikdy nevrací. Tento článek je záznamem návratu. Pomocí Synology jsme tohoto hosta zkrátili na čtyři virtuální CPU a osm gigabajtů. VMM Pro, s asistentem umělé inteligence řídicím shell a úložiště bylo nedostupné dvě minuty a sedm sekund. Samotná změna velikosti je nudná část – jsou to dvě pole v dialogu. Zajímavé jsou měření, které dokázalo, že osm gigabajtů stačí, pořadí operací, které zabrání hostovi v tom, aby při prvním spuštění došlo dostatek paměti, a snapshot, který to celé učinil vratným. VMM Pro dělá všechny tyto věci levnými a to je čestný argument pro něj.

Bod SynoPower Club：Správné dimenzování je v self-hostingu nejméně okouzlující práce a zároveň ta s nejlepší návratností. Nikdo nepíše blogový příspěvek o osmi gigabajtech, které vrátili. Ale paměť ležící nečinně uvnitř nadměrně velkého hosta vám nic neušetří – na Synology je zafixovaná, takže ji nemůže použít nic jiného na serveru. Získali jsme zpět osm gigabajtů na hostiteli, který se začínal zdát plný, což jsou další dva hosty, pro které už nemusíme kupovat hardware. Co to spíše dělalo bezpečným než děsivým, byl VMM Pro pod ním: uzamčený snapshot před prvním příkazem a stroj, který bych mohl vrátit do původního stavu za devadesát sekund, kdyby se něco z toho pokazilo. Nepokazilo se. Ale bez něj bych do toho nezačal.

Co je Synology VMM Pro?

Virtual Machine Manager je hypervizorový balíček od Synology. Instaluje se z Centra balíčků, je zdarma a na jednom NAS serveru bez problémů spustí Linux, Windows a hostované systémy Virtual DSM s lokálními snapshoty. VMM Pro je placený upgrade, který promění hypervizor s jedním zařízením v malý cluster: několik jednotek NAS spravovaných jako jeden pool, hostující servery, které se mezi nimi mohou pohybovat, vysoká dostupnost a replikace snímků z jednoho hostitele na druhý.

Toto rozlišení je pro tento článek důležité, protože správné dimenzování je rozhodnutí o kapacitě a kapacita se stává zajímavou pouze tehdy, když máte v serveru více než jeden počítač. Na jednom NASu se uvolňuje paměť, která je na tomto NASu nevyužitá. V clusteru VMM Pro se jedná o paměť, kterou si jiný host může vypůjčit během failoveru nebo do které lze zabudovat nového hosta, aniž by se musel cokoli kupovat.

A Virtual DSM Host – plná instalace DSM běžící jako virtuální stroj – je úloha, kterou jsme zde upravili. Na něm běží Container Manager, který spouští dva kontejnery Docker za tímto úložištěm. Toto vrstvení je záměrné a právě díky němu je práce bezpečná. Přesun Docker stacku mezi hosty jsme probrali v Náš návod na migraci Dockeru na VDSM; Tento článek pojednává o tom, jak přizpůsobit velikost hosta pod ním.

VMM Pro vs. bezplatná edice: Co upgrade skutečně nabízí

Bezplatná edice není jen omezená demoverze. Spouští produkční hosty, pořizuje snímky a pro jeden NAS je to skutečně vše, co většina lidí potřebuje. S čím si kupujete. VMM Pro Nejde o funkce na hostu, ale o funkce napříč hostiteli.

Schopnost	Bezplatná edice	VMM Pro
Spouštění hostů na jednom NAS serveru	Ano	Ano
Lokální snímky	Ano	Ano
Několik jednotek NAS jako jeden cluster	Žádný	Ano
Přesun hosta mezi hostiteli	Žádný	Ano
Failover s vysokou dostupností	Žádný	Ano
Replikace snímků na jiného hostitele	Žádný	Ano

Před nákupem si prohlédněte oficiální stránku s funkcemi, na kterou odkazuje odkaz v referencích, protože Synology skutečně reviduje rozdělení edic mezi verzemi DSM. Praktický test je jednodušší než tabulka: pokud vlastníte jeden NAS a jste spokojeni s ruční obnovou ze snapshotu, bezplatná edice je v pořádku. V okamžiku, kdy vlastníte druhý NAS a chcete, aby hosté z prvního přežili jeho zánik, chcete... Licence VMM Pro.

Náš cluster se skládá ze tří uzlů a pouze dva z nich jsou většinu času zapnuté. Třetí je studená záložní jednotka, která se podle plánu probouzí, aby přijala replikované snímky, a poté se vrací do režimu spánku. Tento vzorec – plaťte za elektřinu pouze tehdy, když potřebujete redundanci – je vzorec VMM Pro a je důvodem, proč konzole zobrazuje trvalé varování o hostiteli, ke kterému se nemůže dostat. Varování je způsobeno fungováním návrhu, nikoli chybou.

Jak hostující produkční člen nakonec dvakrát tolik potřebuje

Tři věci tlačí hosty nahoru a nic je netlačí zpět dolů. První je, že počáteční velikost je odhad a velkorysý odhad hned první den nic nestojí. Druhou je, že každý incident končí tím, že někdo zvýší limit. V našem případě došlo k dvěma incidentům s pamětí během jednoho týdne; oba byly opraveny přidáním většího prostoru a ani jeden z nich nebyl nikdy znovu řešen. Třetí je, že dashboard ukazující osmdesátiprocentní využití paměti vypadá alarmujícím způsobem, takže se nikdo dobrovolně nehlásí k odebrání paměti. Nic z toho není problém VMM Pro. Je to lidský problém a proto jsou nadměrně velcí hosté normou.

To poslední je past a stojí za to říct přímo: číslo, na které se většina lidí dívá, aby rozhodla, zda má kontejner místo, je špatné číslo. Náš výzkum ukázal, že databázový kontejner byl na osmdesáti jedna procentech svého limitu. Nebyl. Pátá část se celá zabývá proč a měřením, které změnilo změnu velikosti VMM Pro na bezpečné rozhodnutí spíše než nadějné.

Správné dimenzování živého hosta s VMM Pro ve 4 krocích

Celá práce se skládá ze čtyř kroků a teprve třetí z nich odstaví web offline. Celková doba výpadku pro nás byla dvě minuty a sedm sekund, měřeno od okamžiku, kdy se kontejnery zastavily, do prvního HTTP 200 po návratu hosta. VMM Pro je zapojen do kroků jedna a tři; prostřední krok se odehrává uvnitř hosta.

Proč vás statistiky Dockeru odradí od správné odpovědi

Před změnou velikosti vypadal dashboard kontejneru jako stroj, který neměl kam ustoupit:

Statistiky Dockeru WordPress 2,51 GiB / 7 GiB (35,9%) WordPress-DB 3,25 GiB / 4 GiB (81,1%) <-- vypadá téměř plno

Přečtete si to a dojdete k závěru, že databáze potřebuje své čtyři gigabajty a host nemůže klesnout pod dvanáct. Oba závěry jsou chybné, protože využití paměti, které tyto nástroje hlásí, zahrnuje mezipaměť stránek a mezipaměť stránek se automaticky uvolní v okamžiku, kdy cokoli jiného paměť potřebuje. Číslo, které rozhoduje o tom, zda dojde k zabití z důvodu nedostatku paměti, je anonymní paměť. Přečtěte si to přímo:

výkonný pracovník Dockeru sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress rss 1305 MB cache 1609 MB WordPress-DB rss 2553 MB cache 1543 MB

Nyní se obrázek obrátí. Aplikační kontejner skutečně používá 1,3 GB, ne 2,5 GB. A z těchto 1,3 GB je 768 MB jediné sdílené mezipaměti operačního kódu, kterou každý pracovní proces mapuje, nikoli kopíruje – takže dvacet pracovních procesů stálo zhruba dvacet sedm megabajtů každý, ne dvě stě padesát megabajtů, jak naznačuje naivní součet paměti procesů. 2,5 GB databáze bylo téměř výhradně vyrovnávací pamětí o velikosti tří gigabajtů pro databázi o velikosti 663 MB.

Ještě jedna past ve stejné rodině: počítadlo historických vrcholů rádo ukáže kontejner, který se dotkl svého maxima, protože toto počítadlo zahrnuje i mezipaměť stránek. U nás to udělali oba. Ani jeden z nich nebyl nikdy ukončen z důvodu nedostatku paměti. Sledujte počítadlo nedostatku paměti, ne maximum.

S těmito dvěma fakty v ruce přestalo být osm gigabajtů riskantním číslem. Zmenšením vyrovnávací paměti na jeden gigabajt – stále pohodlně větší než celá databáze – se uvolnilo více reálné paměti, než bylo potřeba k úpravě velikosti. Číslo, které jsme nakonec zadali do VMM Pro, bylo již před vypnutím hosta ověřeno.

Jak malý tým využívá VMM Pro k získání celého serveru zpět

Paměť v hostovaném systému Synology je zafixována. Hypervizor ji uzamkne a předalokuje, což znamená, že ji nelze přepsat, jako je to možné na některých jiných platformách. Šestnáct gigabajtů přidělených hostovi je šestnáct gigabajtů, které žádný jiný host nemůže mít, ať už je zaneprázdněn nebo nečinný. Toto omezení je důvodem, proč se vyplatí provádět správné dimenzování. VMM Pro konkrétně: uvolnění paměti je jediný způsob, jak vytvořit kapacitu, kromě koupě NAS serveru.

Na hostiteli s celkovou velikostí 46,83 GB se vrátilo osm gigabajtů. Dostupná paměť se zvýšila z přibližně dvaceti dvou gigabajtů na 30,29 GB. V praxi se jedná o dva hosty větší velikosti, než jakou skutečně provozujeme, vytvořené z ničeho jiného než měřením. Na clusteru se třemi uzly to také znamená, že přeživší hostitelé mají větší prostor pro absorpci hostů z uzlu, který selže, což je v první řadě smysl placení za VMM Pro.

Strana CPU vyprávěla stejný příběh bez obalu. Host měl osm virtuálních CPU a v klidu využíval asi šestinu jednoho jádra. Čtyři nebyly kompromisem; čtyři jsou stále velkorysé a VMM Pro je použil v jednom poli. Od změny velikosti dosahuje host průměrného zatížení 1,36 proti čtyřem vCPU, což je zhruba třetina využití v nejrušnější části dne.

Pořadí operací, které zabraňuje smyčce nedostatečné paměti při spouštění

V této části se snadno a draho mýlíte. Limity paměti kontejneru a paměť hosta, které nastavíte v VMM Pro, jsou dva oddělené limity a pokud součet limitů kontejneru překročí paměť hosta, sdělili jste kontejnerům, že mohou používat více paměti, než má počítač k dispozici. Při zátěži jádro tento nesoulad vyřeší ukončením něčeho.

Naše limity před změnou byly sedm gigabajtů pro kontejner aplikace a čtyři pro databázi – jedenáct gigabajtů na šestnáctigigabajtovém hostu, což bylo v pořádku. Na osmigigabajtovém hostu by to byl incident čekající na první nárůst provozu. Kontejnery se tedy musely nejdříve vypnout:

Nastavení	Před	Po
Host	8 vCPU / 16 GB	4 vCPU / 8 GB
Limit kontejneru aplikace	7168 MB	4096 MB
Limit kontejneru databáze	4096 MB	2048 MB
Vyrovnávací paměť databáze	3 GB	1 GB
Maximální počet připojení k databázi	300	100
Strop pro pracovníky Apache	50	35

V této tabulce se skrývá pravidlo druhého řádu. Nemůžete snížit limit paměti kontejneru pod hodnotu, kterou aktuálně využívá, a očekávat, že se k tomu jádro bude chovat zdvořile. Aplikační kontejner využíval méně, než byl jeho nový limit, takže byl omezen na aktivní provoz bez restartu a prostojů. Databázový kontejner využíval více, takže jeho vyrovnávací paměť musela být překonfigurována a kontejner nejprve restartován; teprve poté bylo možné použít spodní limit. Ani jeden z těchto kroků se v VMM Pro neprovádí – oba je nutné dokončit před otevřením dialogového okna pro změnu velikosti.

Strop počtu pracovníků je jedinou skutečnou cenou celého procesu a zaslouží si být uveden, spíše než zamlčen. Snížení velikosti kontejneru aplikace ze sedmi gigabajtů na čtyři znamená, že může být spuštěno méně souběžných požadavků: z padesáti na třicet pět, což je třicetiprocentní snížení maximální souběžnosti. Denně web provozuje jedenáct pracovníků, takže se nic nezměnilo. Během reklamního návalu se to mohlo stát. Tuto dohodu jsme udělali vědomě a je zapsána, aby ji další člověk během výpadku znovu neobjevil.

Co vlastně AI asistent udělal a kde udělal chybu

Asistent udělal části, které odměňují trpělivost: pořídil snímek VMM Pro předtím, než se čehokoli dotkl, přečetl statistiky cgroup, místo aby důvěřoval dashboardu, vypočítal omezení řazení na limity kontejneru a ověřil výsledek načtením skutečných stránek a kontrolou, zda se ceny stále zobrazují ve správné měně. To je asi čtyřicet minut pečlivé práce vměstnaných do několika minut a je to skutečně užitečné.

Také se to během jedné relace třikrát mýlilo, což je ta užitečnější polovina příběhu.

• Doporučil deset gigabajtů, když majitel požadoval osm. Majitel měl pravdu – ale jen proto, že nadměrně velký bufferový fond byl opraven ve stejnou dobu. Asistent měl měření před sebou a stále se držel bezpečnějšího čísla.
• Přejmenovalo to hosta, čtete úspěch: pravda z API a nahlásil přejmenování jako hotové. Nebylo přejmenováno. Použité pole pro přejmenování bylo to, které identifikuje hosta, nikoli to, které mění jeho název, a API v obou případech vrací úspěch.
• V clusteru VMM Pro se objevilo varování o nedostupném hostiteli a byl označen jako degradovaná cesta pro přepnutí služeb při selhání. Hostitel byl studeným pohotovostním úložištěm, které bylo záměrně vypnuto. Varování bylo záměrně přítomno měsíce.

Vzor ve všech třech případech je stejný: sebevědomý výstup z věrohodné kontroly. Zábrany, na kterých skutečně záleží, jsou proto nenápadné. Pokaždé pořiďte snímek obrazovky před prvním příkazem, nikoli před tím riskantním. Nikdy nepřijímejte návratovou hodnotu jako důkaz – přečtěte si stav zpět a podívejte se na pole, které jste chtěli změnit. A ověřujte chování, ne nastavení: stránka, která se načte, a cena, která je správná, překoná jakýkoli počet potvrzení, že příkaz skončil nulou.

Nic z toho není specifické pro umělou inteligenci. Je to stejná disciplína, jakou byste očekávali od nového kolegy s root přístupem, který je rychlý, neúnavný a občas si je jistý něčím, co není pravda.

Kde najít další oficiální zdroje

Tři videa, která stojí za to si je prostudovat, než se pustíte do změny velikosti čehokoli pomocí VMM Pro. První z nich je nejlepším přehledem samotného balíčku; další dvě se zabývají vytvářením a licencováním hostovaných verzí, což je právě oblast, kde se většina lidí při prvním pokusu zasekne.

Meze, které je třeba znát, než svěříte produkci VMM Pro

Paměť nelze překročit. Každý gigabajt, který přidělíte, je oddělen od všeho ostatního na NAS, ať už je zaneprázdněný nebo ne. Toto je omezení, které dělá správné dimenzování cenným, a je to také důvod, proč je velkorysý odhad v první den zde dražší než na platformách, které umožňují překročení limitu.

Zmenšení paměti vyžaduje restart, protože VMM Pro neodebere paměť spuštěnému hostovanému systému. Zvětšení virtuálního disku probíhá za provozu, stejně jako zvětšení některých zdrojů, ale odebrání paměti znamená vypnutí hostovaného systému. Naplánujte si krátkodobý výpadek; dvě minuty jsou dosažitelné, ale ne nula.

Virtuální disky rostou a nikdy se nezmenšují. Pokud jste přealokovali úložiště místo paměti, VMM Pro Nevrátím to. Jediná cesta je vytvořit nového hosta a migrovat do něj, což je mnohem delší odpoledne než tohle.

Limity CPU uvnitř kontejnerů nemusí vůbec fungovat. Na tomto hostovaném systému nemá jádro žádnou kontrolu šířky pásma CFS, takže kvóty CPU kontejneru jsou rovnou odmítnuty – a co je horší, pokus o nastavení jedné kvóty ve stejném příkazu jako limitu paměti způsobí tiché selhání celého příkazu. Jedinou dostupnou ochranou CPU jsou limity paměti a vlastní limit pracovních sil aplikace.

Snímek není záloha. Je uložen na stejném hostiteli a ve stejném úložném fondu jako hostovaný systém, kterého chrání. VMM Pro dokáže replikovat snímky na jiný hostitel, který je blíže, ale to, co přežije požár budovy, je stále záloha samotných dat mimo pracoviště.

Nakonec se podívejte, co ukazuje konzole. Stránky s podrobnostmi o kontejneru zobrazují proměnné prostředí v prostém textu, včetně hesel k databázi. To je spíše upřímnost Dockeru než chyba v balíčku, ale znamená to, že jediný snímek obrazovky nesprávné stránky publikuje přihlašovací údaje. Pokud vám to vadí – a mělo by – přesuňte tajné údaje do souboru, který kontejner čte, místo abyste je předávali jako proměnné.

Reference

• SynoPower Club, naše průvodce a recenze kamer Synology NAS
• Synology — Virtual Machine Manager, oficiální srovnání funkcí a edic
• Centrum znalostí Synology — Nápověda Virtual Machine Manager, nastavení hosta a nastavení clusteru
• Docker — aktualizace kontejneru Docker, změna limitu paměti spuštěného kontejneru
• Apache — MaxRequestWorkers, strop počtu pracovníků je popsán v sedmé části

Často kladené otázky