Gestion responsables des ressources de vos VMs
Nous sollicitons votre collaboration pour optimiser l'utilisation de notre Cloud privé Openstack.
> La demande en ressources de calcul (RAM) ne cesse de croître.
Pour garantir une expérience fluide à l'ensemble de la communauté (étudiants, chercheurs et enseignants), il est crucial d'adopter des réflexes de gestion responsable de vos VM.
Constat : Pourquoi libérer la mémoire ?
Contrairement au processeur (vCPU), qui peuvent être partagé de manière dynamique, la mémoire vive (RAM) est une ressource rigide.
Lorsqu'une instance est créé, la RAM lui est allouée de manière exclusive sur l'hyperviseur physique.
Le problème: Une VM, même éteinte, "verrouille" sa RAM.
Cela empêche la création de nouveaux projets ou le déploiement de nouvelles instances pour d'autres utilisateurs.
Les bonnes pratiques à adopter
1. Créér ses VMs avec un volume comme root disk et utiliser "Shelve/Mise en retrait" pour les longues pauses
Si vous n'avez pas besoin de votre VM pendant plusieurs jours, utilisez la fonction "Shelve/Mise en retrait" (Instances > Menu Actions > Shelve/Mise en retrait Instance).
> Cela retire la VM de l'hyperviseur et libère donc toutes les ressources de calculs associés (RAM et CPU).
Cette fonction Shelve fonctionne beaucoup mieux si la VM est créé à partir d'un volume. Pour cela :

Note : La taille du volume devrait s'ajuster automatiquement selon l'image et la flaveur sélectionée.
2. Ajustez la "Flaveur" à vos besoins rééls
Ne demandez pas une instance m1.xlarge (16Go de RAM) pour faire du script Python basique ou de l'édition de texte.
- Evaluez vos besoins rééls en RAM. Demandez à votre enseignant si besoin.
- La flaveur peut être changer selon le besoin après la création de la VM.
- Attention : La taille du disque ne peut pas être réduite.
En résumé
Une gestion rigoureuse de vos VMs permet d'éviter la saturation des noeuds de calcul.
| Etat de la VM | RAM réservé | CPU consommé | Stockage consommé |
|---|---|---|---|
| Active | 100% Flavor | Variable | Oui |
| Stopped | 100% Flavor | 0% | Oui |
| Shelved | 0% | 0% | Oui (volume) |
Bonnes pratique pour que ma VM redémarre correctement
1. La méthode standard : Systemd (Recommandé)
Sur la quasi-totalité des distributions modernes (Ubuntu, Debian, CentOS), systemd est le gestionnaire de services par excellence.
Il permet de surveiller un processus et de le relancer en cas de crash ou après un reboot.
Comment créer un service systemd ?
Créez un fichier de configuration (en tant que root) :
/etc/systemd/system/mon-service.service
[Unit]
Description=Mon application de recherche
After=network.target
[Service]
ExecStart=/usr/bin/python3 /home/ubuntu/mon_projet/main.py
Restart=always
RestartSec=5
User=ubuntu
WorkingDirectory=/home/ubuntu/mon_projet
[Install]
WantedBy=multi-user.target
- Activer au démarrage : sudo systemctl enable mon-service
- Lancer immédiatement : sudo systemctl start mon-service
- Vérifier le statut : sudo systemctl status mon-service
2. Pour les utilisateurs de Docker : Restart Policies
Si vous utilisez Docker pour vos services, n'utilisez pas de scripts manuels. Docker intègre nativement la gestion du redémarrage.
A la place, utilisez l'option --restart lors du lancement de votre conteneur :
- always : Redémarre toujours le conteneur s'il s'arrête.
- unless-stopped : Redémarre sauf si vous l'avez arrêté manuellement.
docker run -d --name mon-web --restart unless-stopped nginx
services:
app:
image: mon-app:latest
restart: always
3. La méthode simple : La Crontab (@reboot)
Pour des scripts très simples ou si vous n'êtes pas à l'aise avec systemd, vous pouvez utiliser l'utilitaire cron.
Editer le fichier cron avec "crontab -e" et ajoutez simplement la ligne "@reboot/chemin/absolu/vers/mon_script.sh" à la fin du fichier.
Note : Cette méthode est mons robuste car elle ne relance pas le service si celui-ci plante pendant que la VM est allumée. Elle ne fonctionne qu'au boot.
Conseil de l'administrateur
Un service qui redémarre en boucle sans que vous le sachiez peut saturer les processeurs de la plateforme.- Testez manuellement avant d'automatiser. Le script doit fonctionner sans interventions humaine (mot de passes, chemin d'accès absolus, etc)
- Assurez vous que les logs soient écris dans un fichier (ex : /var/log/mon-app.log)