Synology VMM Pro : Dimensionnement optimal d’une machine virtuelle de production grâce à l’IA (2026)

La machine virtuelle qui héberge ce site a fonctionné pendant des mois avec deux fois plus de ressources matérielles que nécessaire : huit processeurs virtuels, seize gigaoctets de mémoire et une charge de travail réelle qui n’a jamais utilisé plus du quart de ces ressources. Ce n’est pas inhabituel. On dimensionne généreusement une machine virtuelle le premier jour, car on ignore ses besoins futurs ; le site fonctionne et personne n’y revient. Cet article relate notre retour en arrière. Nous avons réduit cette machine virtuelle à quatre processeurs virtuels et huit gigaoctets de mémoire à l’aide de la plateforme Synology. VMM Pro, Avec un assistant IA pilotant l'interface, le magasin était inaccessible pendant deux minutes et sept secondes. Le redimensionnement en lui-même est la partie la plus fastidieuse : il s'agit simplement de deux champs dans une boîte de dialogue. Les aspects intéressants résident dans la mesure qui a prouvé que huit gigaoctets suffisaient, l'ordre des opérations qui empêche le système invité de manquer de mémoire au premier démarrage, et la capture instantanée qui rend tout cela réversible. Le VMM Pro rend chacun de ces éléments peu coûteux, et c'est là son véritable atout.

Point SynoPower Club :L'optimisation de la taille des machines virtuelles est la tâche la moins glamour de l'auto-hébergement, mais aussi la plus rentable. Personne ne publie d'article de blog sur les huit gigaoctets récupérés. Pourtant, la mémoire inutilisée d'une machine virtuelle surdimensionnée ne vous fait économiser rien : sur un Synology, elle est réservée et donc inutilisable par les autres applications. Nous avons récupéré huit gigaoctets sur un hôte qui commençait à être saturé, ce qui nous permet de libérer deux machines virtuelles supplémentaires pour lesquelles nous n'aurons plus besoin d'acheter de matériel. Ce qui a permis d'éviter toute inquiétude, c'est la présence d'un VMM Pro sous-jacent : un instantané verrouillé avant la première commande et une machine que je pouvais restaurer en une minute et demie en cas de problème. Tout s'est bien passé. Mais je n'aurais pas pu commencer sans cette solution.

Qu'est-ce que Synology VMM Pro ?

Virtual Machine Manager est le paquet hyperviseur de Synology. Il s'installe depuis le Centre de paquets, est gratuit et, sur un seul NAS, il peut exécuter sans problème des systèmes invités Linux, Windows et Virtual DSM avec des instantanés locaux. VMM Pro Il s'agit de la mise à niveau payante qui transforme cet hyperviseur monoposte en un petit cluster : plusieurs unités NAS gérées comme un seul pool, des invités pouvant se déplacer entre elles, une haute disponibilité et la réplication des instantanés d'un hôte à un autre.

Cette distinction est importante pour cet article, car le dimensionnement optimal est une décision relative à la capacité, et cette dernière ne devient pertinente que lorsqu'on dispose de plusieurs machines. Sur un NAS unique, la mémoire libérée est de la mémoire inutilisée sur ce NAS. Dans un cluster VMM Pro, il s'agit de mémoire qu'un autre hôte peut emprunter lors d'un basculement, ou dans laquelle une nouvelle machine virtuelle peut être déployée sans achat supplémentaire.

A DSM virtuel La machine virtuelle invitée (une installation DSM complète exécutée en tant que machine virtuelle) est la charge de travail que nous avons redimensionnée. Elle exécute Container Manager, qui gère les deux conteneurs Docker sous-jacents. Cette architecture en couches est intentionnelle et a permis de garantir la sécurité de l'opération. Nous avons abordé le déplacement d'une pile Docker entre machines virtuelles invitées dans [référence manquante]. Notre guide de migration Docker VDSM; Cet article explique comment dimensionner correctement l'invité situé en dessous.

VMM Pro contre l'édition gratuite : que procure réellement la mise à niveau ?

L'édition gratuite n'est pas une version de démonstration bridée. Elle permet d'exécuter des machines virtuelles de production, de prendre des instantanés et, pour un seul NAS, elle répond parfaitement aux besoins de la plupart des utilisateurs. Ce que vous achetez avec VMM Pro Il ne s'agit pas des fonctionnalités propres à un invité, mais des fonctionnalités communes à tous les hôtes.

Capacité	Édition gratuite	VMM Pro
Exécutez des machines virtuelles sur un NAS.	Oui	Oui
Instantanés locaux	Oui	Oui
Plusieurs unités NAS en un seul cluster	Non	Oui
Déplacer un invité entre hôtes	Non	Oui
Basculement haute disponibilité	Non	Oui
Répliquez les instantanés sur un autre hôte	Non	Oui

Consultez la page des fonctionnalités officielles (lien dans les références) avant d'acheter, car Synology modifie régulièrement l'édition, la divisant entre les versions de DSM. En pratique, c'est plus simple : si vous possédez un seul NAS et que la restauration manuelle à partir d'un instantané ne vous dérange pas, l'édition gratuite vous convient. Dès que vous possédez un deuxième NAS et que vous souhaitez que les données invitées du premier survivent à sa panne, il vous faut l'édition payante. Licence VMM Pro.

Notre cluster comprend trois nœuds, dont deux seulement sont alimentés en permanence. Le troisième est en veille prolongée : il se réveille périodiquement pour recevoir les snapshots répliqués, puis se remet en veille. Ce modèle – ne payer l’électricité que lorsque la redondance est nécessaire – correspond à un modèle VMM Pro et explique l’avertissement permanent affiché par la console concernant un hôte inaccessible. Cet avertissement est normal et ne constitue pas un défaut.

Comment un invité de production finit par prendre deux fois la taille nécessaire

Trois facteurs incitent les clients à augmenter la capacité de stockage, sans les freiner. Premièrement, la taille initiale est une estimation, et une estimation généreuse ne coûte rien le premier jour. Deuxièmement, chaque incident se termine par une augmentation de la limite. Notre service a connu deux incidents de mémoire en une semaine ; les deux ont été résolus en augmentant la capacité, et aucun n'a été réexaminé. Troisièmement, un tableau de bord affichant 80 % d'utilisation de la mémoire est alarmant, ce qui dissuade quiconque de réduire la capacité. Ce n'est pas un problème lié à VMM Pro, mais à l'humain, et c'est pourquoi les clients ayant une capacité de stockage importante sont la norme.

Ce dernier point est un piège, et il est important de le préciser : le chiffre que la plupart des gens consultent pour déterminer si un conteneur a suffisamment d’espace est erroné. Le nôtre indiquait que le conteneur de base de données était occupé à 81 % de sa limite. Ce qui était faux. La section cinq explique entièrement pourquoi, et détaille la mesure qui a permis de prendre une décision sûre lors du redimensionnement du conteneur VMM Pro, au lieu de se fier à l’espoir.

Adapter la taille d'un invité en direct avec VMM Pro en 4 étapes

L'opération se déroule en quatre étapes, et seule la troisième entraîne l'indisponibilité du site. La durée totale d'indisponibilité a été de deux minutes et sept secondes, mesurée entre l'arrêt des conteneurs et la première réponse HTTP 200 après le retour du serveur invité. VMM Pro elle intervient dans les étapes un et trois ; l'étape intermédiaire se déroule à l'intérieur de l'invité.

Pourquoi les statistiques Docker peuvent vous induire en erreur et vous empêcher de trouver la bonne réponse

Avant le redimensionnement, le tableau de bord conteneur ressemblait à une machine saturée :

Statistiques Docker : WordPress 2,51 Gio / 7 Gio (35,9%) WordPress-DB 3,25 Gio / 4 Gio (81,1%) <-- semble presque plein

À la lecture de ces informations, vous pourriez conclure que la base de données a besoin de ses quatre gigaoctets et que la machine virtuelle ne peut pas descendre en dessous de douze. Ces deux conclusions sont erronées, car l'utilisation de la mémoire indiquée par ces outils inclut le cache de pages, qui est automatiquement libéré dès qu'un autre processus a besoin de mémoire. Le facteur déterminant en cas d'arrêt pour insuffisance de mémoire est la mémoire anonyme. Voici la réponse :

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

La situation s'inverse désormais. Le conteneur d'application utilise bien 1,3 Go, et non 2,5 Go. Sur ces 1,3 Go, 768 Mo constituent un cache d'opcode partagé que chaque processus de travail mappe au lieu de le copier. Ainsi, vingt processus de travail consommaient environ 27 mégaoctets chacun, et non les 250 mégaoctets que suggérerait une simple somme de la mémoire allouée aux processus. Les 2,5 Go de la base de données étaient presque entièrement occupés par un pool de mémoire tampon de 3 gigaoctets pour une base de données de 663 Mo.

Encore un piège du même genre : le compteur de pics historiques affichera sans hésiter un conteneur ayant atteint sa limite, car il inclut également le cache de pages. Nos deux conteneurs avaient atteint cette limite. Aucun n'avait jamais été interrompu par une erreur de mémoire insuffisante. Vérifiez le compteur d'erreurs de mémoire insuffisante, et non le pic de fréquentation.

Forts de ces deux informations, huit gigaoctets ne représentaient plus un risque. Réduire la taille du pool de mémoire tampon à un gigaoctet — toujours largement supérieure à celle de la base de données entière — a libéré plus de mémoire vive que nécessaire pour le redimensionnement. La valeur que nous avons finalement saisie dans VMM Pro était déjà validée avant l'arrêt de la machine virtuelle.

Comment une petite équipe utilise VMM Pro pour récupérer un serveur entier

La mémoire d'une machine virtuelle Synology est réservée. L'hyperviseur la verrouille et la pré-alloue, ce qui signifie qu'il est impossible de la surdimensionner comme sur certaines autres plateformes. Seize gigaoctets alloués à une machine virtuelle sont seize gigaoctets qu'aucune autre machine virtuelle ne peut utiliser, qu'elle soit occupée ou inactive. C'est cette contrainte qui justifie le dimensionnement correct de la mémoire sur cette plateforme. VMM Pro Plus précisément : libérer de la mémoire est le seul moyen de créer de la capacité sans avoir à acheter un NAS.

Huit gigaoctets ont été récupérés sur un hôte disposant d'une mémoire totale de 46,83 Go. La mémoire disponible est passée d'environ 22 gigaoctets à 30,29 Go. Concrètement, cela représente l'équivalent de deux machines virtuelles supplémentaires de la taille de celles que nous utilisons habituellement, créées uniquement grâce à cette mesure. Sur un cluster à trois nœuds, cela signifie également que les hôtes restants ont une plus grande marge de manœuvre pour absorber les machines virtuelles d'un nœud défaillant, ce qui est la raison même du choix de l'offre VMM Pro.

Du côté du processeur, le constat était similaire, mais plus direct. La machine virtuelle disposait de huit processeurs virtuels et utilisait environ un sixième d'un cœur au repos. Quatre processeurs virtuels n'étaient pas un compromis ; c'est même une quantité généreuse, et VMM Pro l'a appliquée dans un seul champ. Depuis le redimensionnement, la machine virtuelle affiche une charge moyenne de 1,36 pour quatre processeurs virtuels, soit environ un tiers d'utilisation aux heures de pointe.

L'ordre des opérations qui empêche une boucle de mémoire insuffisante au démarrage

C'est ici qu'il est facile de se tromper, et cela peut coûter cher. Les limites de mémoire des conteneurs et la mémoire invitée que vous définissez dans VMM Pro sont deux plafonds distincts. Si la somme des limites des conteneurs dépasse la mémoire invitée, vous autorisez les conteneurs à utiliser plus de mémoire que la machine ne peut en fournir. En cas de forte charge, le noyau résout ce conflit en interrompant un processus.

Avant la modification, nos limites étaient de sept gigaoctets pour le conteneur de l'application et de quatre pour la base de données, soit onze gigaoctets sur une machine virtuelle de seize gigaoctets, ce qui était acceptable. Sur une machine virtuelle de huit gigaoctets, cela aurait constitué un incident dès le premier pic de trafic. Il a donc fallu arrêter les conteneurs en premier.

Paramètre	Avant	Après
Invité	8 vCPU / 16 Go	4 vCPU / 8 Go
Limite du conteneur d'application	7168 Mo	4096 Mo
limite du conteneur de base de données	4096 Mo	2048 Mo
pool de mémoire tampon de base de données	3 Go	1 Go
Nombre maximal de connexions à la base de données	300	100
plafond des travailleurs Apache	50	35

Il existe une règle de second ordre cachée dans ce tableau. Vous ne pouvez pas abaisser la limite de mémoire d'un conteneur en dessous de sa consommation actuelle et espérer que le noyau tolère correctement cette situation. Le conteneur d'application utilisait moins de mémoire que sa nouvelle limite ; il a donc été limité à chaud, sans redémarrage ni interruption de service. Le conteneur de base de données, quant à lui, utilisait davantage de mémoire ; son pool de mémoire tampon a donc dû être reconfiguré et le conteneur redémarré au préalable ; ce n'est qu'ensuite que la limite inférieure a pu être appliquée. Aucune de ces étapes n'est effectuée dans la version VMM Pro ; les deux doivent être terminées avant d'ouvrir la boîte de dialogue de redimensionnement.

Le plafond de ressources allouées représente le seul véritable coût de l'opération et mérite d'être clairement indiqué. Réduire la taille du conteneur d'application de sept à quatre gigaoctets signifie une diminution du nombre de requêtes simultanées : de cinquante à trente-cinq, soit une réduction de 30 % du pic de charge. Au quotidien, le site utilise onze ressources, donc rien n'a changé. Cela pourrait toutefois changer lors d'un pic publicitaire. Il s'agit d'un compromis que nous avons fait en toute connaissance de cause et qui est consigné par écrit afin que personne ne le découvre par hasard en cas de panne.

Ce que l'assistant IA a réellement fait, et où il a eu tort

L'assistant s'est chargé des tâches qui exigent de la patience : il a pris l'instantané VMM Pro avant toute autre intervention, a consulté les statistiques cgroup au lieu de se fier au tableau de bord, a calculé la contrainte d'ordre sur les limites du conteneur et a vérifié le résultat en récupérant des pages réelles et en s'assurant que les prix s'affichaient toujours dans la bonne devise. Cela représente peut-être quarante minutes de travail minutieux condensées en quelques minutes, et c'est vraiment utile.

Elle s'est également trompée trois fois au cours d'une même session, ce qui constitue la partie la plus utile de l'histoire.

• Il recommandait dix gigaoctets alors que le propriétaire en avait demandé huit. Le propriétaire avait raison, mais uniquement parce que la taille du pool de mémoire tampon avait été fixée simultanément. L'assistant avait la mesure sous les yeux et s'en tenait toujours à la valeur la plus sûre.
• Cela a renommé l'invité, lire succès : vrai L'API a signalé que le renommage avait été effectué, alors que le nom n'avait pas été modifié. Le champ utilisé pour le renommage était celui qui identifie l'invité, et non celui qui modifie son nom ; l'API renvoie d'ailleurs un succès dans les deux cas.
• Le système a détecté une alerte du cluster VMM Pro concernant un hôte inaccessible et l'a signalé comme chemin de basculement dégradé. L'hôte était un serveur de secours à froid, volontairement mis hors tension. L'alerte était présente depuis plusieurs mois, conformément à sa conception.

Le schéma est identique dans les trois cas : un résultat fiable issu d’une vérification plausible. Les garde-fous essentiels sont donc souvent peu attrayants. Prenez systématiquement une capture d’écran avant la première commande, et non avant une commande risquée. Ne considérez jamais une valeur de retour comme une preuve : relisez l’état du système et examinez le champ que vous souhaitiez modifier. Et vérifiez le comportement, pas les paramètres : une page qui se charge et un prix correct valent mieux que de nombreuses confirmations qu’une commande a renvoyé zéro.

Rien de tout cela n'est spécifique à l'IA. C'est la même rigueur que l'on attend d'un nouveau collègue disposant d'un accès root, rapide, infatigable et parfois persuadé de choses erronées.

Où trouver plus de ressources officielles

Trois vidéos à visionner absolument avant de redimensionner quoi que ce soit avec VMM Pro. La première offre une excellente vue d'ensemble du logiciel ; les deux autres expliquent comment créer et gérer les invités, une étape qui pose souvent problème lors de la première utilisation.

Limites à connaître avant de confier la production au VMM Pro

La mémoire ne peut pas être surdimensionnée. Chaque gigaoctet alloué est totalement indépendant du reste du NAS, qu'il soit utilisé ou non. C'est cette contrainte qui rend le dimensionnement précis si important, et c'est aussi pourquoi une estimation généreuse dès le départ est plus coûteuse ici que sur les plateformes autorisant le surdimensionnement.

Une réduction de la mémoire nécessite un redémarrage, car VMM Pro ne libère pas de mémoire pour une machine virtuelle en cours d'exécution. L'extension d'un disque virtuel et l'augmentation de certaines ressources s'effectuent à chaud, mais la réduction de la mémoire implique l'arrêt de la machine virtuelle. Prévoyez une courte interruption de service et planifiez-la ; deux minutes sont envisageables, mais pas une interruption nulle.

Les disques virtuels s'agrandissent et ne diminuent jamais. Si vous avez surdimensionné l'espace de stockage plutôt que la mémoire, VMM Pro Je ne vous le rendrai pas. La seule solution est de créer une nouvelle machine virtuelle et d'y migrer les données, ce qui prendra beaucoup plus d'heures que celle-ci.

Les limites de CPU à l'intérieur des conteneurs peuvent être totalement inopérantes. Sur cette machine virtuelle, le noyau ne gère pas la bande passante CFS ; par conséquent, les quotas de CPU des conteneurs sont rejetés d'emblée. Pire encore, toute tentative de définition d'un quota en même temps qu'une limite de mémoire entraîne l'échec silencieux de la commande. Seules les limites de mémoire et le plafond de workers propre à l'application constituent la protection CPU disponible.

Un instantané n'est pas une sauvegarde. Il réside sur le même hôte et dans le même espace de stockage que la machine virtuelle qu'il protège. VMM Pro peut répliquer les instantanés sur un autre hôte, ce qui est plus pratique, mais seule une sauvegarde externe des données est préservée en cas d'incendie.

Enfin, vérifiez ce qu'affiche la console. Les pages de détails des conteneurs affichent les variables d'environnement en clair, y compris les mots de passe des bases de données. Il s'agit d'une mesure de sécurité de Docker et non d'un défaut du package, mais cela signifie qu'une simple capture d'écran de la mauvaise page suffit à divulguer des informations d'identification. Si cela vous pose problème (et c'est normal), déplacez vos secrets dans un fichier que le conteneur lit au lieu de les transmettre comme variables.

Références

• SynoPower Club, nos guides NAS Synology et nos tests de caméras
• Synology — Virtual Machine Manager, le comparatif officiel des fonctionnalités et des éditions
• Centre de connaissances Synology — Aide Virtual Machine Manager, paramètres invités et configuration du cluster
• Docker — mise à jour des conteneurs Docker, en modifiant la limite de mémoire d'un conteneur en cours d'exécution
• Apache — MaxRequestWorkers, le plafond de main-d'œuvre évoqué dans la section sept

Questions fréquemment posées