ec4eae3744
Jitsi (docker-jitsi-meet, version figée) derrière Nginx sur meet.syllabuslab.fr, accès par jeton JWT signé par le portail, modération du micro, mains levées synchronisées avec l'application. Pare-feu : UDP 10000 et pont interne br-visio (accords d'Adam). Jicofo n'authentifie plus lui-même : il donnait le rôle de propriétaire aux élèves. Capacité ramenée à 20 VM. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
103 lines
4.5 KiB
Markdown
103 lines
4.5 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 : 20 VM `eleve.petit` en même temps
|
||
|
||
Ramenée de 22 à 20 le 2026-10-12 pour la visio (Jitsi) : après une visio à
|
||
trois, Jitsi occupe ≈ 710 Mo (JVB 459, Jicofo 206, Prosody 28, web 16) ; JVB est
|
||
plafonné à 1 Go et Jicofo à 512 Mo, soit 1,5 Go réservés en plus
|
||
(`reserved_host_memory_mb` 15000 → 16500 ; (31993 − 16500) / 768 = 20).
|
||
|
||
### Historique : 22 VM (étape 13)
|
||
|
||
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 (20 VM) : une classe de 20 sur un lab à 1 VM ; 6 é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.
|