« Un groupe de contrôle limite, contraint et isole l’utilisation des ressources d’un ensemble de processus. » La documentation du noyau Linux sur les cgroups résume en une phrase le problème que rencontre un club nautique qui partage un unique VPS avec deux autres associations locales : sans cette isolation, rien n’empêche un site de consommer toute la mémoire et tout le CPU disponibles, au détriment des deux autres, précisément le jour où l’un d’eux en a le plus besoin.
Le cas concret : trois associations se partagent un serveur privé virtuel unique pour réduire les coûts. Deux d’entre elles gèrent des sites vitrines à trafic modeste, la troisième héberge la billetterie de régates du club, dont le trafic explose ponctuellement les jours de compétition, quand des centaines de spectateurs et de familles de coureurs consultent les résultats en direct.
Le problème d’un VPS non isolé
Sur un VPS classique sans isolation par site, tous les processus PHP-FPM des trois associations partagent le même pool de mémoire disponible et la même file d’attente CPU. Un pic de trafic sur la billetterie pendant une régate consomme alors toute la mémoire disponible, ce qui provoque des erreurs 502 sur les deux autres sites hébergés, sans qu’aucun administrateur des sites vitrines n’ait rien changé de son côté.
Isoler par cgroups plutôt que par convention
La solution durable ne repose pas sur un accord informel entre associations pour limiter leur trafic aux heures creuses, mais sur une isolation technique réelle via les groupes de contrôle (cgroups v2), déjà présents dans le noyau de toute distribution Linux récente. Chaque pool PHP-FPM peut être rattaché à sa propre tranche de ressources :
[club-billetterie]
listen = /run/php/billetterie.sock
pm = dynamic
pm.max_children = 20
; limite via systemd (unité slice dédiée)
En s’appuyant sur les tranches systemd, chaque pool PHP-FPM peut être placé dans son propre slice, avec une limite de mémoire et une part de CPU garantie :
systemctl set-property php-fpm-billetterie.service \
MemoryMax=1G CPUQuota=50%
Le jour de la régate : anticiper plutôt que subir
Une fois l’isolation en place, le pic de trafic de la billetterie reste contenu dans son enveloppe de ressources allouée, sans déborder sur les deux autres sites. Cela ne dispense pas de préparer spécifiquement les journées de compétition, où le trafic peut être dix fois supérieur à la normale sur quelques heures :
- Activer un cache de page complet sur la billetterie plusieurs jours avant l’événement, pas la veille ;
- Vérifier que
pm.max_childrendu pool billetterie est dimensionné pour le pic attendu, pas pour le trafic moyen ; - Surveiller la mémoire allouée en temps réel pendant l’événement via
systemctl status php-fpm-billetterie.service.
Répartir équitablement le coût du VPS
Une fois l’isolation technique posée, la répartition du coût du VPS entre les trois associations devient plus simple à justifier : chacune paie en proportion de l’enveloppe de ressources qui lui est réservée, et non plus au prorata approximatif du nombre de pages publiées sur son site.
Surveiller sans dépendre d’un outil commercial
Trois associations qui se partagent un VPS n’ont généralement pas le budget pour un abonnement à un outil de supervision payant. Un tableau de bord minimal, construit avec les outils déjà présents sur le serveur, suffit largement à suivre l’état de chaque tranche de ressources :
systemd-cgtop --order=memory | grep php-fpm
Cette commande unique affiche en direct la consommation mémoire de chaque tranche systemd, ce qui permet à un bénévole technique du club de vérifier en quelques secondes, le jour de la régate, que la billetterie reste bien dans son enveloppe allouée sans empiéter sur les deux autres sites.
Anticiper la montée en charge du réseau, pas seulement du CPU
Un point souvent négligé lors de ce type de mutualisation : la bande passante réseau du VPS reste, elle, partagée sans isolation possible par les cgroups, qui ne portent que sur le CPU, la mémoire et les entrées-sorties disque. Si la billetterie diffuse aussi des photos ou des vidéos des régates en direct, il est préférable de les servir depuis un CDN externe plutôt que depuis le VPS lui-même, pour ne jamais saturer la connexion réseau partagée par les trois associations au moment le plus critique de l’année.
Un conseil qui a évité une brouille entre associations sur ce projet : documenter les limites de ressources de chaque site dans un fichier partagé, visible par tous les responsables, avant même le premier incident.
Notre verdict
Mutualiser un VPS entre plusieurs associations reste une solution économique viable, à condition de remplacer la confiance mutuelle par une isolation technique réelle. Les cgroups et les tranches systemd suffisent, sans nécessiter de conteneurs ni de virtualisation supplémentaire, à garantir qu’un pic de billetterie de régate ne mette jamais en péril le site vitrine du club voisin.
