Capacité mesurée sur 20 VM (docs/capacite.md), restauration complète du portail réussie, retour automatique de tous les services après redémarrage. Retire l'unité systemd orpheline de ProxySQL, rend fidèle au navigateur la mesure du temps d'ouverture d'un lab (2,8 s), et regroupe la dette révélée. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
96 lines
4.1 KiB
Markdown
96 lines
4.1 KiB
Markdown
# Capacité du serveur Syllabus
|
||
|
||
Mesuré le 2026-10-09 (étape 13) sur le serveur de production : Scaleway
|
||
Dedibox Start-2-L, Xeon D-1531 (6 cœurs, 12 fils), 32 Go de RAM, OpenStack
|
||
Kolla 2025.2 tout-en-un. Script : `openstack/tests/capacite.py` ; données
|
||
brutes sur le serveur : `/root/capacite-20261009/` (`hote.csv` toutes les
|
||
2 s, `demarrage.csv`, `resume.json`).
|
||
|
||
## Capacité retenue : 22 VM `eleve.petit` en même temps
|
||
|
||
Sessions d'élèves et stock chaud compris. Choisie par Adam d'après les
|
||
mesures ci-dessous. Elle est appliquée à deux endroits, à garder alignés :
|
||
|
||
| Où | Réglage |
|
||
|---|---|
|
||
| Nova (refus au-delà, propre : « No valid host » → session en échec visible du prof) | `reserved_host_memory_mb = 15000` dans `kolla/config/nova/nova-compute.conf` → Placement : (31993 − 15000) Mo / 768 Mo = **22 VM** |
|
||
| Portail (plafond du stock chaud) | `LABS_CAPACITE_VM`, défaut 22 (`portail/config/labs.php`) |
|
||
| Quota du projet (filet de sécurité, au-dessus) | 40 instances, 40 vCPU, 30 Go (rôle `openstack-projet`) |
|
||
|
||
Ce que ça permet : une classe de 22 sur un lab à 1 VM ; 7 élèves sur le
|
||
lab 08 (3 VM chacun). Moins le stock en attente (1 stack par lab hors séance).
|
||
|
||
## Mesures
|
||
|
||
### Mémoire
|
||
|
||
| Situation | Mémoire disponible sur l'hôte |
|
||
|---|---|
|
||
| Sans VM (Kolla, portail, supervision) | ≈ 16,5 Go (Kolla seul occupe ≈ 15,5 Go) |
|
||
| 3 VM du stock au repos | 15,1 Go |
|
||
| + 20 VM démarrées, au repos | 10,1 Go → **≈ 250 Mo par VM** (RSS moyen 269 Mo) |
|
||
| + 350 Mo occupés dans chacune des 20 VM | 3,4 Go → **+332 Mo par VM**, soit **≈ 600 Mo par VM active** ; swap utilisé : 264 Mo |
|
||
|
||
Coût d'une VM `eleve.petit` (768 Mo) sur l'hôte :
|
||
|
||
| Usage | Coût réel | VM possibles (16,3 Go − 2 Go de marge) |
|
||
|---|---|---|
|
||
| Au repos | ≈ 250 Mo | ≈ 57 |
|
||
| Élève actif (mesuré ci-dessus) | ≈ 600 Mo | **≈ 23** |
|
||
| Pire cas (VM pleine + QEMU) | ≈ 870 Mo | ≈ 16 |
|
||
|
||
À 22 VM, si toutes remplissaient entièrement leur mémoire en même temps
|
||
(cas improbable dans un lab réseau ou système), l'hôte dépasserait sa
|
||
mémoire d'environ 2 Go et puiserait dans le swap (4 Go) : ralentissement
|
||
plutôt que panne. Le test n'a pas cherché à le provoquer.
|
||
|
||
### Démarrage de 20 VM lancées en même temps
|
||
|
||
20 sur 20, aucune erreur.
|
||
|
||
| | min | médiane | p95 | max |
|
||
|---|---|---|---|---|
|
||
| Passage à ACTIVE | 23,7 s | 48,8 s | 67,6 s | 71,1 s |
|
||
| Système démarré (agent invité qui répond) | 27,8 s | 53,2 s | 74,7 s | 78,2 s |
|
||
|
||
Pendant la rafale : CPU de l'hôte jusqu'à 86 %. D'où l'intérêt du stock
|
||
chaud et du pré-remplissage 10 minutes avant une séance : une classe
|
||
entière qui démarre à froid attendrait plus d'une minute.
|
||
|
||
### CPU
|
||
|
||
20 VM avec un cœur à 100 % chacune pendant 60 s (20 vCPU pour 12 fils) :
|
||
CPU de l'hôte à 89 % en moyenne, charge 14,5 au maximum. Une commande de
|
||
correction par l'agent invité répond tout de même en **0,6 s**. Le CPU n'est
|
||
pas la limite : la mémoire l'est. (Ratio par défaut de Nova : 4 vCPU par fil,
|
||
soit 48 vCPU.)
|
||
|
||
### Ouverture d'un lab pris dans le stock (critère < 5 s)
|
||
|
||
Mesurée de bout en bout par `https://syllabuslab.fr` comme un navigateur
|
||
(`portail/tests/Reels/parcours-lab.py`) : **2,80 s, 2,85 s, 2,85 s**.
|
||
|
||
Décomposition (`portail/tests/Reels/decomposer-ouverture.py`) :
|
||
|
||
| Morceau | Durée |
|
||
|---|---|
|
||
| La page élève voit l'état « actif » (interrogation chaque seconde) | 0 à 1 s |
|
||
| Rechargement de la page | 0,03 s |
|
||
| Jetons des consoles (appel Nova `remote-consoles`, ≈ 1,1 s chacun, demandés en parallèle) | 1,1 s |
|
||
| WebSocket jusqu'à l'invite `login:` | 1,0 s |
|
||
|
||
Le poste le plus coûteux est l'appel Nova pour obtenir l'adresse de la
|
||
console : piste d'optimisation si besoin (préparer ces jetons à
|
||
l'attribution plutôt qu'à l'affichage).
|
||
|
||
## Quand refaire ces mesures
|
||
|
||
Après une montée de version de Kolla, un changement d'image ou de gabarit,
|
||
l'ajout d'un service lourd, ou un changement de serveur. Commande :
|
||
|
||
```
|
||
sudo python3 /root/capacite.py --vm 20 --sortie /root/capacite-AAAAMMJJ
|
||
```
|
||
|
||
Le script s'arrête de lui-même si la mémoire disponible passe sous 3 Go. Il
|
||
crée un réseau `capacite-test` et des VM `capacite-N` à supprimer ensuite.
|