Modernisez OpenStack sans risque pour la production
Nous évaluons l'écart de versions, le stockage et les workloads, puis choisissons la trajectoire la plus sûre : plateforme parallèle, export/import contrôlé ou mise à niveau séquentielle. Chaque scénario inclut tests, critères de retour arrière et stabilisation de production.
- 1Audit et inventaireVersions, stockage, réseaux, workloads et fenêtres d'interruption acceptables.
- 2Plateforme cible parallèleConstruite avec Kolla-Ansible à côté de l'ancien cloud, en partageant le cluster Ceph quand c'est possible.
- 3Groupe piloteValide la procédure, les critères de recette et le retour arrière avant de toucher aux workloads critiques.
- 4Vagues contrôlées et basculeVolumes adoptés par le nouveau Cinder sans copie de données ; ancien cloud conservé comme retour arrière jusqu'à la recette.
Trois chemins pour migrer un environnement OpenStack ancien
Option A : Cluster Ceph partagé
Le pool Ceph est connecté aux deux déploiements OpenStack. Les volumes sont détachés de l'ancien Cinder et réimportés dans le nouveau service Cinder sans copie réseau.
Option B : Snapshot, export et import
Pour les baies de stockage isolées, nous créons des snapshots, exportons les images vers Glance/S3, les déplaçons et recréons l'environnement sur le cluster OpenStack cible.
Option C : Mise à niveau sur place (kolla-ansible upgrade)
Le cluster existant est mis à niveau sur place selon un chemin supporté par Kolla-Ansible et chaque service déployé, sans déployer d'environnement parallèle. Plus rapide et moins coûteux, mais avec un risque réel pour les workloads hébergés.
Les options A et B sont documentées commande par commande dans notre guide technique : Migrer des volumes Cinder entre deux OpenStack →
Mise à niveau sur place avec kolla-ansible
kolla-ansible upgrade déploie des images de conteneurs plus récentes sur le cluster multi-AZ existant sans construire de cible parallèle. Utilisez des releases adjacentes, ou un saut entre deux releases SLURP consécutives uniquement lorsque Kolla-Ansible et chaque service déployé le supportent. Une source ancienne peut donc imposer plusieurs fenêtres de maintenance qualifiées.
Guide technique : procédure de montée de version release par release →Nous ne conseillons pas cette méthode par défaut
Une mise à niveau sur place avec Kolla-Ansible modifie le control plane et les services de calcul en production. Un échec peut prolonger la fenêtre de maintenance ou perturber les API et les workloads. Nous ne retenons cette trajectoire qu'après validation des sauvegardes, du retour arrière, de la résilience applicative, des compatibilités entre chaque version et de l'acceptation explicite des risques.
Audit et inventaire
Nous cartographions les services, le stockage, le réseau et les versions OpenStack avant de proposer le chemin de migration.
Déploiement parallèle
Nous construisons la plateforme cible en parallèle de l'existant pour limiter l'impact sur les activités métier.
Bascule et contrôle
Nous validons les workloads, sécurisons la haute disponibilité et stabilisons la production avant la bascule finale.
Ce que vos équipes reçoivent
Un inventaire des versions et dépendances, des runbooks testés, un rapport de pilote, des plans de bascule et de retour arrière par vague, les preuves de recette, la documentation d'architecture mise à jour et le transfert de compétences.
Évaluer ma migration OpenStack