fixe la capacité à 22 VM d'après le test de capacité
Réserve mémoire de Nova alignée sur l'usage réel de l'hôte (15 Go) : Nova refuse proprement au-delà de 22 VM eleve.petit, au lieu d'en accepter ~41 et de saturer la mémoire. Le plafond du portail suit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
3f0b565e1e
commit
42884597a9
3 changed files with 39 additions and 4 deletions
|
|
@ -9,7 +9,7 @@ déclenche `sauvegarde-dedibackup.service`, qui exécute
|
||||||
|
|
||||||
Le script :
|
Le script :
|
||||||
|
|
||||||
1. Archive `/etc`, `/home`, `/root` en `tar.zst` (streaming, sans fichier intermédiaire en clair).
|
1. Archive `/etc`, `/home`, `/root` en `tar.zst` (streaming, sans fichier intermédiaire en clair), plus, depuis l'étape 13, le **portail** : export `mariadb-dump --single-transaction` de sa base (`portail.sql`, à la racine de l'archive), `/var/www/portail/.env` (APP_KEY) et `/var/www/portail/storage/app`. Avant le 2026-10-09, la base du portail n'était **pas** sauvegardée.
|
||||||
2. Chiffre le flux avec **age**, avec la clé publique du serveur (`/root/.age/cle-sauvegardes.txt`).
|
2. Chiffre le flux avec **age**, avec la clé publique du serveur (`/root/.age/cle-sauvegardes.txt`).
|
||||||
3. Envoie l'archive chiffrée en FTP vers Dedibackup (`dedibackup-dc3.online.net`, joignable uniquement depuis ce serveur).
|
3. Envoie l'archive chiffrée en FTP vers Dedibackup (`dedibackup-dc3.online.net`, joignable uniquement depuis ce serveur).
|
||||||
4. Le dimanche (jour 7), duplique aussi l'archive du jour comme hebdomadaire.
|
4. Le dimanche (jour 7), duplique aussi l'archive du jour comme hebdomadaire.
|
||||||
|
|
@ -64,6 +64,32 @@ lftp -u "$DEDIBACKUP_USER,$DEDIBACKUP_PASS" "$DEDIBACKUP_HOST" \
|
||||||
'
|
'
|
||||||
```
|
```
|
||||||
|
|
||||||
|
## Test de restauration du portail (automatique, chaque lundi 04:30)
|
||||||
|
|
||||||
|
`/usr/local/sbin/syllabus-test-restauration` (rôle `sauvegardes`, minuteur
|
||||||
|
`syllabus-test-restauration.timer`) télécharge la dernière quotidienne, la
|
||||||
|
déchiffre, restaure la base dans un conteneur MariaDB jetable (réseau
|
||||||
|
`portail_default`, aucun port publié), fait tourner le code du portail contre
|
||||||
|
cette copie (`migrate:status`, comptage), compare chaque table à la
|
||||||
|
production, puis publie `syllabus_derniere_restauration_reussie_timestamp`.
|
||||||
|
Alerte `RestaurationNonTestee` au-delà de 8 jours. Rien n'est écrit en
|
||||||
|
production ; le conteneur et les fichiers temporaires sont supprimés à la fin.
|
||||||
|
|
||||||
|
```
|
||||||
|
ssh paillasse "sudo /usr/local/sbin/syllabus-test-restauration" # à la demande
|
||||||
|
ssh paillasse "journalctl -u syllabus-test-restauration --no-pager | tail -40"
|
||||||
|
```
|
||||||
|
|
||||||
|
Des écarts de comptage sont normaux si la production a changé depuis la
|
||||||
|
sauvegarde ; une table absente de la copie fait échouer le test.
|
||||||
|
|
||||||
|
## Restaurer réellement le portail (sinistre)
|
||||||
|
|
||||||
|
1. Extraire l'archive dans un dossier temporaire (voir plus bas), puis `portail.sql` et `var/www/portail/.env`.
|
||||||
|
2. Redéployer le portail (`ansible-playbook portail.yml`) sur le serveur reconstruit ; remettre le `.env` restauré **avant** (APP_KEY identique, sinon sessions et données chiffrées perdues).
|
||||||
|
3. Importer la base : `docker exec -i portail_mariadb sh -c 'MYSQL_PWD="$MARIADB_ROOT_PASSWORD" exec mariadb -uroot' < portail.sql` (écrase la base `portail`).
|
||||||
|
4. `php artisan migrate --force`, puis vérifier une connexion prof.
|
||||||
|
|
||||||
## Restaurer un fichier (procédure testée le 2026-10-07)
|
## Restaurer un fichier (procédure testée le 2026-10-07)
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -5,3 +5,11 @@
|
||||||
# Défaut : false. Après un redémarrage de l'hôte, les VM restaient éteintes :
|
# Défaut : false. Après un redémarrage de l'hôte, les VM restaient éteintes :
|
||||||
# le stock chaud aurait contenu des stacks « prêtes » aux VM arrêtées.
|
# le stock chaud aurait contenu des stacks « prêtes » aux VM arrêtées.
|
||||||
resume_guests_state_on_host_boot = true
|
resume_guests_state_on_host_boot = true
|
||||||
|
|
||||||
|
# Défaut : 512. Nova se croyait libre de distribuer 31,5 Go alors que Kolla et
|
||||||
|
# le portail en occupent ~15,5 : il aurait accepté ~41 VM et l'hôte aurait
|
||||||
|
# manqué de mémoire bien avant qu'il refuse. (31993 - 15000) / 768 = 22 VM
|
||||||
|
# eleve.petit au plus : capacité retenue par Adam le 2026-10-09 d'après le
|
||||||
|
# test de capacité (docs/capacite.md). Au-delà, Nova refuse proprement
|
||||||
|
# (« No valid host ») et la session passe en échec, visible du prof.
|
||||||
|
reserved_host_memory_mb = 15000
|
||||||
|
|
|
||||||
|
|
@ -7,9 +7,10 @@ return [
|
||||||
'dossier' => env('LABS_DOSSIER', dirname(base_path()).'/labs'),
|
'dossier' => env('LABS_DOSSIER', dirname(base_path()).'/labs'),
|
||||||
|
|
||||||
// Nombre de VM eleve.petit (768 Mo) que le serveur peut faire tourner en
|
// Nombre de VM eleve.petit (768 Mo) que le serveur peut faire tourner en
|
||||||
// même temps, sessions d'élèves et stock compris. Calcul et mesures :
|
// même temps, sessions d'élèves et stock compris : mesuré à l'étape 13
|
||||||
// docs/journal.md, étape 11. Le stock chaud ne dépasse jamais ce plafond.
|
// (docs/capacite.md). Doit rester aligné sur la réserve mémoire de Nova
|
||||||
'capacite_vm' => (int) env('LABS_CAPACITE_VM', 15),
|
// (kolla/config/nova/nova-compute.conf), qui refuse au-delà.
|
||||||
|
'capacite_vm' => (int) env('LABS_CAPACITE_VM', 22),
|
||||||
|
|
||||||
'stock' => [
|
'stock' => [
|
||||||
// Stacks prêtes gardées en permanence pour chaque lab du catalogue,
|
// Stacks prêtes gardées en permanence pour chaque lab du catalogue,
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue