Déployer et mettre à niveau un cluster OpenStack HA avec Kolla-Ansible

1. Inventaire multinode et zones de disponibilité

Kolla-Ansible regroupe les hôtes par rôle. Le control plane tourne sur trois contrôleurs ; les nœuds de calcul sont répartis en deux groupes qui correspondront ensuite à deux zones de disponibilité Nova. Rendre l'appartenance aux AZ visible dans l'inventaire rend la correspondance avec les host aggregates explicite et reproductible.

./multinode (simplified excerpt)

[control]
control-01
control-02
control-03

[network:children]
control

[compute:children]
az1-computes
az2-computes

[az1-computes]
az1-node-[01:10]

[az2-computes]
az2-node-[01:10]

# Nova availability zones are mapped to host aggregates after deployment (see section 4)

2. Mots de passe et globals.yml

Générez les mots de passe des services une seule fois et protégez strictement /etc/kolla/passwords.yml. Un premier déploiement doit définir explicitement au minimum la distribution de base, le VIP interne, les interfaces de gestion et externe, les backends de stockage et le plugin Neutron. Épinglez le paquet Kolla-Ansible sur la branche stable cible ; ne surchargez openstack_release que pour une politique volontaire de versionnement personnalisé des images.

# 2.1 Generate the cluster passwords
kolla-genpwd

# 2.2 Key settings in /etc/kolla/globals.yml
kolla_internal_vip_address: "10.0.0.254"
kolla_base_distro: "ubuntu"
network_interface: "bond0"
neutron_external_interface: "bond1"
enable_haproxy: "yes"
enable_cinder: "yes"
cinder_backend_ceph: "yes"
glance_backend_ceph: "yes"
nova_backend_ceph: "yes"
neutron_plugin_agent: "ovn"

# 2.3 Pre-deployment checks on the target hosts
kolla-ansible -i ./multinode prechecks

Ceph externe s'active séparément pour Cinder, Glance et Nova. Respectez l'arborescence Kolla-Ansible propre à chaque service sous /etc/kolla/config : fichiers ceph.conf et keyrings dédiés pour glance, cinder-volume, cinder-backup et nova. Le cluster Ceph lui-même est déployé et exploité séparément, généralement avec cephadm.

3. Bootstrap, prechecks et deploy

bootstrap-servers prépare les hôtes (Docker ou Podman, utilisateurs, réglages noyau). prechecks doit passer sur chaque hôte avant deploy : un precheck en échec coûte bien moins cher qu'un control plane à moitié déployé.

# First deployment
kolla-ansible -i ./multinode bootstrap-servers
kolla-ansible -i ./multinode prechecks
kolla-ansible -i ./multinode deploy

4. Validation post-déploiement

post-deploy génère les identifiants administrateur. Vérifiez que chaque agent est up et enabled avant de déclarer la plateforme prête, puis créez les host aggregates qui transforment les deux groupes de calcul en zones de disponibilité Nova.

# Generate and load the admin environment variables
kolla-ansible -i ./multinode post-deploy
source /etc/kolla/admin-openrc.sh

# Check OpenStack agent health
openstack compute service list
openstack network agent list
openstack volume service list

# Map compute groups to Nova availability zones
openstack aggregate create --zone AZ1 az1
openstack aggregate create --zone AZ2 az2
for i in $(seq -w 1 10); do openstack aggregate add host az1 az1-node-$i; done
for i in $(seq -w 1 10); do openstack aggregate add host az2 az2-node-$i; done
openstack availability zone list --compute

5. Chemin de mise à niveau sur place supporté

kolla-ansible upgrade déploie des images de conteneurs plus récentes sur le cluster existant sans construire d'environnement parallèle. Utilisez des releases adjacentes, ou un saut entre deux releases SLURP consécutives uniquement lorsque Kolla-Ansible et chaque service déployé supportent ce chemin. Un passage de Rocky à 2024.1 n'est pas une mise à niveau supportée en une seule étape. Chaque saut impose de suivre ses notes de version et les préparations propres aux services, notamment celle de RabbitMQ pour un saut supporté.

# In-place upgrade through a path supported by the target release notes
cd /etc/kolla

# 0. Back up the control plane database before touching anything
kolla-ansible -i ./multinode mariadb_backup

# 1. Upgrade the kolla-ansible package to the next release and refresh its dependencies
pip install --upgrade 'git+https://opendev.org/openstack/kolla-ansible@stable/<NEXT_RELEASE>'
kolla-ansible install-deps

# 2. Update the target release in globals.yml
# openstack_release: "<NEXT_RELEASE>"

# 3. Pull the new container images, then re-run the prechecks
kolla-ansible -i ./multinode pull
kolla-ansible -i ./multinode prechecks

# 4. Roll out the upgrade across control plane and compute nodes
kolla-ansible -i ./multinode upgrade

# 5. Validate before moving to the next release
source /etc/kolla/admin-openrc.sh
openstack compute service list
openstack network agent list

6. Points de vigilance

• ■Lisez les notes de version de chaque release intermédiaire : des options dépréciées dans globals.yml font échouer les prechecks, et certaines releases changent le runtime de conteneurs ou la version de base de données par défaut.
• ■Épinglez le paquet kolla-ansible sur la branche stable correspondant à openstack_release ; un décalage produit des images inexistantes ou tire silencieusement une release plus récente.
• ■Conservez les VIP interne et externe, les keyrings Ceph et passwords.yml sous contrôle de version chiffré (Ansible Vault par exemple) ; perdre passwords.yml revient à perdre le cluster.
• ■Validez la live migration entre les deux groupes d'AZ après le déploiement : le stockage Ceph partagé la rend possible, mais le scheduler Nova a toujours besoin de modèles CPU cohérents entre les hôtes.
• ■Branchez l'observabilité avant d'ouvrir la plateforme aux tenants : exporters, règles d'alerte et tableaux de bord font partie du déploiement, pas d'une phase ultérieure.