Synology VMM Pro: Dimensionamento ottimale di una macchina virtuale di produzione con l'intelligenza artificiale (2026)

La macchina virtuale che gestisce questo negozio ha trascorso mesi a gestire il doppio dell'hardware necessario. Otto CPU virtuali, sedici gigabyte di memoria e un carico di lavoro reale che non ha mai superato un quarto di entrambi. Non è una cosa insolita. Si dimensiona una macchina virtuale in modo generoso il primo giorno perché non si ha idea di cosa avrà bisogno, il sito funziona e nessuno ci torna più indietro. Questo articolo è il resoconto di quel ritorno. Abbiamo ridotto la macchina virtuale a quattro vCPU e otto gigabyte utilizzando Synology. VMM Pro, con un assistente IA che gestiva la shell, e il negozio è rimasto irraggiungibile per due minuti e sette secondi. Il ridimensionamento in sé è la parte noiosa: si tratta di due campi in una finestra di dialogo. Le parti interessanti sono la misurazione che ha dimostrato che otto gigabyte erano sufficienti, l'ordine delle operazioni che impedisce al sistema guest di esaurire la memoria al primo avvio e lo snapshot che ha reso il tutto reversibile. VMM Pro rende ognuna di queste operazioni economica, e questo è il vero argomento a suo favore.

Punto SynoPower Club:Il ridimensionamento è l'operazione meno appariscente nell'hosting autonomo, ma anche quella con il miglior ritorno sull'investimento. Nessuno scrive un post sul blog riguardo agli otto gigabyte di memoria recuperati. Eppure, la memoria inutilizzata all'interno di una macchina virtuale sovradimensionata non fa risparmiare nulla: su un Synology, ad esempio, è bloccata e non può essere utilizzata da nessun altro sistema. Abbiamo recuperato otto gigabyte su un host che cominciava a sentirsi saturo, il che significa due macchine virtuali in più per le quali non dovremo più acquistare hardware. A rendere l'operazione sicura, anziché preoccupante, è stato il VMM Pro sottostante: uno snapshot bloccato prima del primo comando e una macchina che avrei potuto ripristinare in novanta secondi in caso di problemi. Non ci sono stati problemi. Ma non avrei mai iniziato senza di esso.

Che cos'è Synology VMM Pro?

Virtual Machine Manager è il pacchetto hypervisor di Synology. Si installa tramite Package Center, è gratuito e su un singolo NAS può eseguire senza problemi Linux, Windows e sistemi operativi guest Virtual DSM con snapshot locali. VMM Pro è l'aggiornamento a pagamento che trasforma quell'hypervisor a singolo dispositivo in un piccolo cluster: diverse unità NAS gestite come un unico pool, macchine virtuali che possono spostarsi tra di esse, alta disponibilità e replica degli snapshot da un host all'altro.

La distinzione è importante per questo articolo perché il dimensionamento ottimale è una decisione di capacità, e la capacità diventa rilevante solo quando si ha più di una macchina nel cluster. Su un singolo NAS, la memoria liberata è memoria inutilizzata su quel NAS. In un cluster VMM Pro, si tratta di memoria che un altro host può utilizzare durante un failover, oppure che può essere utilizzata per installare una nuova macchina virtuale senza dover acquistare nulla.

A Virtual DSM guest — un'installazione completa di DSM in esecuzione come macchina virtuale — è il carico di lavoro che abbiamo ridimensionato qui. Esegue Container Manager, che a sua volta esegue i due container Docker dietro questo negozio. Questa stratificazione è intenzionale ed è ciò che ha reso il lavoro sicuro. Abbiamo trattato lo spostamento di uno stack Docker tra guest in La nostra guida dettagliata alla migrazione di VDSM con Docker.; questo articolo riguarda come rendere l'ospite sottostante della giusta dimensione.

VMM Pro contro la versione gratuita: cosa include realmente l'aggiornamento

L'edizione gratuita non è una demo limitata. Esegue macchine virtuali di produzione, crea snapshot e, per un singolo NAS, è davvero tutto ciò di cui la maggior parte delle persone ha bisogno. Ciò che stai acquistando con VMM Pro Non si tratta di funzionalità specifiche di una singola macchina virtuale, bensì di funzionalità comuni a tutti gli host.

Capacità	Edizione gratuita	VMM Pro
Eseguire le macchine virtuali su un NAS	SÌ	SÌ
Istantanee locali	SÌ	SÌ
Diverse unità NAS raggruppate in un unico cluster	NO	SÌ
Spostare un ospite tra host	NO	SÌ
Failover ad alta disponibilità	NO	SÌ
Replicare gli snapshot su un altro host	NO	SÌ

Controlla la pagina ufficiale delle funzionalità collegata nei riferimenti prima dell'acquisto, perché Synology rivede la suddivisione dell'edizione tra le release di DSM. Il test pratico è più semplice della tabella: se possiedi un NAS e ti accontenti di ripristinare da uno snapshot manualmente, l'edizione gratuita va bene. Nel momento in cui possiedi un secondo NAS e vuoi che le guest del primo sopravvivano al suo guasto, ti serve un Licenza VMM Pro.

Il nostro cluster è composto da tre nodi, e solo due di essi sono accesi per la maggior parte del tempo. Il terzo è in modalità cold standby, si attiva a intervalli programmati per ricevere snapshot replicati e poi torna in modalità di sospensione. Questo schema – pagare l'elettricità solo quando è necessaria la ridondanza – è un modello VMM Pro ed è il motivo per cui la console mostra un avviso permanente relativo a un host irraggiungibile. L'avviso indica che il sistema sta funzionando correttamente, non che si tratta di un guasto.

Come un ospite di una produzione finisce per avere il doppio delle dimensioni necessarie

Tre fattori spingono gli ospiti ad aumentare lo spazio disponibile e nulla li frena. Il primo è che la dimensione iniziale è una stima, e una stima generosa non costa nulla il primo giorno. Il secondo è che ogni inconveniente si conclude con qualcuno che alza il limite. Nel nostro caso, ci sono stati due episodi di sovraccarico di memoria in una settimana; entrambi sono stati risolti aumentando lo spazio disponibile, e nessuno dei due è stato più oggetto di discussione. Il terzo è che un pannello di controllo che mostra un utilizzo della memoria dell'ottanta per cento sembra allarmante, quindi nessuno si offre volontario per ridurlo. Nessuno di questi problemi è imputabile a VMM Pro. È un problema umano, ed è per questo che gli ospiti di dimensioni eccessive sono la norma.

Quest'ultimo è il tranello, ed è bene dirlo chiaramente: il numero che la maggior parte delle persone considera per decidere se un container ha spazio sufficiente è sbagliato. Il nostro indicava che il container del database aveva raggiunto l'81% del suo limite. Non era vero. La quinta sezione spiega interamente il perché e la misurazione che ha trasformato il ridimensionamento VMM Pro in una decisione sicura anziché in una semplice speranza.

Dimensionamento ottimale di un ospite in diretta con VMM Pro in 4 passaggi

L'intera procedura si articola in quattro fasi, e solo la terza comporta la disconnessione del sito. Il tempo di inattività totale per noi è stato di due minuti e sette secondi, misurato dal momento in cui i container si sono arrestati fino al primo codice HTTP 200 ricevuto dopo il riavvio del server. VMM Pro è coinvolto nelle fasi uno e tre; la fase centrale si svolge all'interno dell'ospite.

Perché le statistiche di Docker potrebbero dissuaderti dal trovare la risposta giusta

Prima del ridimensionamento, la dashboard del contenitore sembrava una macchina senza spazio di manovra:

docker stats WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- sembra quasi pieno

Leggendo quel codice, si potrebbe concludere che il database necessita di quattro gigabyte e che la macchina virtuale non può scendere sotto i dodici. Entrambe le conclusioni sono errate, perché l'utilizzo della memoria riportato da questi strumenti include la cache di pagina, che viene recuperata automaticamente non appena qualcos'altro necessita di memoria. Il valore che determina se si verifica un errore di memoria insufficiente è la memoria anonima. Leggetelo direttamente:

docker exec 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

Ora la situazione si ribalta. Il contenitore dell'applicazione utilizza effettivamente 1,3 GB, non 2,5 GB. E di questi 1,3 GB, 768 MB sono costituiti da una singola cache di opcode condivisa che ogni processo worker mappa anziché copiare: quindi venti processi worker consumavano circa ventisette megabyte ciascuno, non i duecentocinquanta megabyte che una semplice somma della memoria di processo potrebbe suggerire. I 2,5 GB del database erano quasi interamente occupati da un buffer pool di tre gigabyte per un database di 663 MB.

Un'altra trappola della stessa famiglia: il contatore storico dei picchi mostrerà senza problemi un contenitore che ha raggiunto il suo limite massimo, perché quel contatore include anche la cache di pagina. Entrambi i nostri l'avevano fatto. Nessuno dei due era mai stato terminato per esaurimento della memoria. Controllate il contatore per esaurimento della memoria, non il limite massimo raggiunto.

Con questi due elementi a disposizione, otto gigabyte hanno smesso di rappresentare un numero rischioso. Riducendo il buffer pool a un gigabyte – ancora comodamente superiore all'intero database – si è liberata più memoria reale di quanta ne sarebbe servita per il ridimensionamento. Il valore che alla fine abbiamo inserito in VMM Pro era già stato verificato prima dello spegnimento della macchina virtuale.

Come un piccolo team utilizza VMM Pro per recuperare un intero server

La memoria in una macchina virtuale Synology è bloccata. L'hypervisor la blocca e la prealloca, il che significa che non è possibile sovrascriverla come si può fare su altre piattaforme. Sedici gigabyte assegnati a una macchina virtuale sono sedici gigabyte che nessun'altra macchina virtuale può avere, indipendentemente dal fatto che la macchina virtuale sia occupata o inattiva. Questo vincolo è ciò che rende utile l'ottimizzazione delle risorse. VMM Pro Nello specifico: liberare memoria è l'unico modo per creare capacità senza acquistare un NAS.

Otto gigabyte sono stati recuperati su un host con un totale di 46,83 GB. La memoria disponibile è passata da circa ventidue gigabyte a 30,29 GB. In termini pratici, ciò equivale a due guest aggiuntivi delle dimensioni effettivamente utilizzate, creati dal nulla semplicemente tramite misurazioni. Su un cluster a tre nodi, questo significa anche che gli host rimanenti hanno maggiore margine per assorbire i guest di un nodo guasto, che è poi il motivo principale per cui si paga per VMM Pro.

Il lato CPU ha confermato la stessa situazione in modo più diretto. La macchina virtuale disponeva di otto CPU virtuali e utilizzava circa un sesto di un singolo core a riposo. Quattro non rappresentavano un compromesso; quattro sono ancora un valore generoso e VMM Pro lo ha applicato in un unico campo. Dopo il ridimensionamento, la macchina virtuale ha un carico medio di 1,36 su quattro vCPU, che corrisponde a circa un terzo dell'utilizzo effettivo durante le ore di punta.

L'ordine delle operazioni che impedisce un ciclo di esaurimento della memoria all'avvio

Questa è la parte in cui è facile sbagliare e, se sbagliata, può costare cara. I limiti di memoria dei container e la memoria guest che si imposta in VMM Pro sono due limiti massimi separati e, se la somma dei limiti dei container supera la memoria guest, si sta comunicando ai container che possono utilizzare più memoria di quanta ne abbia la macchina. Sotto carico, il kernel risolve questa discrepanza terminando un processo.

Prima della modifica, i nostri limiti erano di sette gigabyte per il container dell'applicazione e quattro per il database: undici gigabyte su una macchina virtuale da sedici gigabyte, il che andava bene. Su una macchina virtuale da otto gigabyte, sarebbe stato un problema in agguato al primo picco di traffico. Quindi, i container dovevano essere arrestati per primi.

Collocamento	Prima	Dopo
Ospite	8 vCPU / 16 GB	4 vCPU / 8 GB
Limite del contenitore dell'applicazione	7168 MB	4096 MB
limite del contenitore del database	4096 MB	2048 MB
pool di buffer dell'archivio	3 GB	1 GB
numero massimo di connessioni del database	300	100
limite massimo per i lavoratori Apache	50	35

In quella tabella si cela una regola di secondo ordine. Non è possibile ridurre il limite di memoria di un container al di sotto del valore attualmente utilizzato e aspettarsi che il kernel lo gestisca correttamente. Il container dell'applicazione utilizzava meno memoria del nuovo limite, quindi è stato limitato in tempo reale senza riavvio e senza tempi di inattività. Il container del database utilizzava più memoria, quindi è stato necessario riconfigurare il suo buffer pool e riavviare il container; solo successivamente è stato possibile applicare il limite inferiore. Nessuno di questi passaggi avviene in VMM Pro: entrambi devono essere completati prima di aprire la finestra di dialogo per il ridimensionamento.

Il limite massimo di worker è l'unico vero costo dell'intera operazione, ed è giusto che venga esplicitato piuttosto che nascosto. Ridurre il contenitore dell'applicazione da sette gigabyte a quattro significa che possono essere gestite meno richieste simultanee: da cinquanta a trentacinque, con una riduzione del trenta per cento del picco di concorrenza. Quotidianamente il sito utilizza undici worker, quindi non è cambiato nulla. Durante un picco di traffico pubblicitario, potrebbe succedere. Si tratta di una scelta consapevole, che abbiamo messo per iscritto affinché chi verrà dopo non se ne accorga durante un'interruzione del servizio.

Cosa ha fatto realmente l'assistente IA e dove ha sbagliato

L'assistente si è occupato delle parti che premiano la pazienza: ha scattato l'istantanea VMM Pro prima di toccare qualsiasi altra cosa, ha letto le statistiche del cgroup invece di affidarsi alla dashboard, ha calcolato il vincolo di ordinamento sui limiti del container e ha verificato il risultato recuperando pagine reali e controllando che i prezzi fossero ancora visualizzati nella valuta corretta. Si tratta di circa quaranta minuti di lavoro accurato compressi in pochi minuti, e il risultato è davvero utile.

Inoltre, ha sbagliato tre volte in una sola sessione, e questa è la parte più utile della storia.

• Il sistema ha consigliato dieci gigabyte quando il proprietario ne aveva richiesti otto. Il proprietario aveva ragione, ma solo perché il buffer pool sovradimensionato era stato corretto contemporaneamente. L'assistente aveva la misurazione sotto gli occhi e ha comunque optato per il numero più sicuro.
• Ha rinominato l'ospite, leggi successo: vero dall'API, e ha segnalato la ridenominazione come completata. In realtà non era stata rinominata. Il campo di ridenominazione utilizzato era quello che identifica l'ospite, non quello che ne modifica il nome, e l'API restituisce comunque un esito positivo.
• Il sistema ha rilevato un avviso del cluster VMM Pro relativo a un host irraggiungibile e lo ha segnalato come percorso di failover degradato. L'host era un server di standby a freddo, spento intenzionalmente. L'avviso era presente da mesi, come previsto dal sistema.

Lo schema in tutti e tre i casi è lo stesso: un output affidabile da una verifica plausibile. Le misure di sicurezza che contano davvero sono quindi poco appariscenti. Scattate sempre un'istantanea prima del primo comando, piuttosto che prima di quello rischioso. Non accettate mai un valore di ritorno come prova: leggete lo stato e controllate il campo che intendevate modificare. E verificate il comportamento, non le impostazioni: una pagina che si carica e un prezzo corretto valgono più di qualsiasi numero di conferme che un comando sia terminato con un valore zero.

Niente di tutto ciò è specifico dell'IA. Si tratta della stessa disciplina che ci si aspetterebbe da un nuovo collega con accesso root: veloce, instancabile e a volte sicuro di qualcosa che non è vero.

Dove trovare ulteriori risorse ufficiali

Prima di ridimensionare qualsiasi elemento con VMM Pro, ecco tre video che vale la pena guardare. Il primo offre una panoramica completa del pacchetto; gli altri due trattano la creazione e la gestione delle licenze degli oggetti guest, ovvero la fase in cui la maggior parte degli utenti incontra difficoltà al primo tentativo.

Limiti da conoscere prima di affidare la produzione a VMM Pro

Non è possibile sovrascrivere la memoria. Ogni gigabyte assegnato è isolato da qualsiasi altro dispositivo presente sul NAS, occupato o meno. Questo è il vincolo che rende fondamentale un dimensionamento ottimale, ed è anche il motivo per cui una stima generosa iniziale risulta più costosa rispetto a piattaforme che consentono l'over-status.

La riduzione della memoria richiede un riavvio, perché VMM Pro non sottrae memoria a una macchina virtuale in esecuzione. L'espansione di un disco virtuale avviene in tempo reale, così come l'aumento di alcune risorse, ma la riduzione della memoria implica l'arresto della macchina virtuale. Prevedete una breve interruzione e pianificatela; due minuti sono fattibili, ma non è un'interruzione pari a zero.

I dischi virtuali crescono e non si riducono mai. Se hai allocato più spazio di archiviazione che memoria, VMM Pro Non lo restituirò. L'unica soluzione è creare un nuovo ospite e migrare al suo interno, il che richiederà un pomeriggio molto più lungo di questo.

I limiti della CPU all'interno dei container potrebbero non funzionare affatto. Su questa macchina virtuale, il kernel non ha alcun controllo sulla larghezza di banda CFS, quindi le quote CPU dei container vengono rifiutate senza indugio; peggio ancora, il tentativo di impostarne una nello stesso comando di un limite di memoria fa sì che l'intero comando fallisca silenziosamente. I limiti di memoria e il limite massimo di worker dell'applicazione stessa sono le uniche protezioni della CPU disponibili.

Uno snapshot non è un backup. Risiede sullo stesso host e nello stesso pool di storage della macchina virtuale che protegge. VMM Pro può replicare gli snapshot su un altro host più vicino, ma ciò che sopravvive a un incendio in un edificio rimane comunque un backup remoto dei dati stessi.

Infine, osservate cosa mostra la console. Le pagine dei dettagli del container mostrano le variabili d'ambiente in chiaro, incluse le password del database. Questo dimostra la correttezza di Docker, non si tratta di un difetto del pacchetto, ma significa che una singola schermata della pagina sbagliata può pubblicare una credenziale. Se questo vi preoccupa (e dovrebbe), spostate i segreti in un file letto dal container invece di passarli come variabili.

Riferimenti

• SynoPower Club, le nostre guide al NAS Synology e le recensioni delle telecamere
• Synology — Virtual Machine Manager, il confronto ufficiale tra funzionalità ed edizione
• Centro informazioni Synology — Assistenza Virtual Machine Manager, impostazioni guest e configurazione cluster
• Docker — aggiornamento del container Docker, modificando il limite di memoria di un container in esecuzione
• Apache — MaxRequestWorkers, il limite massimo di lavoratori discusso nella sezione sette

Domande frequenti