Tâche #37304
Scénario #37182: Upgrade-Auto Hâpy 2.9 → 2.10
Étude
100%
Historique
#1 Mis à jour par Benjamin Bohard il y a environ 2 mois
- Statut changé de Nouveau à En cours
#2 Mis à jour par Benjamin Bohard il y a environ 2 mois
Le paquet contenant les migrations est accessible à l’adresse : https://downloads.opennebula.io/repo/7.0/Ubuntu/24.04/pool/opennebula/opennebula-migration_7.0.1-1_all.deb.
Il ne peut pas être installé directement puisqu’il déclare une dépendance sur la version 7 de OpenNebula et que la version installée sur EOLE 2.10 est la 6.10.
Pour passer de la 2.9 à la 2.10, seuls les fichiers de migration 6.6.0_to_6.8.0.rb et 6.8.0_to_6.10.0.rb sont nécessaires. Ça représente 4 fichiers au plus : 2 dans /usr/lib/one/ruby/onedb/local et 2 dans /usr/lib/one/ruby/onedb/shared). À vérifier si les deux sont nécessaires dans le contexte d’Upgrade-Auto.
À l’instance, après Upgrade-Auto, le script /usr/share/eole/posttemplate/90-one-db fonctionne comme attendu.
#3 Mis à jour par Benjamin Bohard il y a environ 2 mois
Le service openvswitch-switch ne démarre pas.
Le démarrage à la main renvoie
Failed to start openvswitch-switch.service: Unit netplan-apply.service is masked.
Le service netplan-apply.service ne semble pas disponible mais ne semble pas non plus être une dépendance directe du service openvswitch-switch.service
# /usr/lib/systemd/system/openvswitch-switch.service [Unit] Description=Open vSwitch Before=network.target After=network-pre.target ovsdb-server.service ovs-vswitchd.service PartOf=network.target Requires=ovsdb-server.service Requires=ovs-vswitchd.service [Service] Type=oneshot ExecStart=/bin/true ExecReload=/usr/share/openvswitch/scripts/ovs-systemd-reload ExecStop=/bin/true RemainAfterExit=yes [Install] WantedBy=multi-user.target Also=ovs-record-hostname.service
#4 Mis à jour par Benjamin Bohard il y a environ 2 mois
Le démarrage du service ovs-vswitchd.service débloque l’instance (blocage à l’étape /usr/share/eole/postservice/29-ovs-mng comme indiqué dans le commentaire du scénario).
#5 Mis à jour par Benjamin Bohard il y a environ un mois
Pour le cas simple de montée de version d’un nœud isolé, les trois observations ont été effectuées :
- les fichiers de migration sont fonctionnels (4 fichiers nécessaires, mode de distribution non décidé encore) ;
- le service ovs-vswitchd peut-être déclaré dans le dictionnaire 29_one-master.xml en 2.10 (ce service doit être démarré dans le cadre de reconfigure pour que ce dernier ne soit pas bloqué) ;
- les services opennebula-gate et opennebula-flow posent problème (systemd abandonne leur démarrage pour des raisons encore inconnues).
- un script en pre_upgrade qui effectue les tâches suivantes :
- vérification de l’état des VM (certains états sont incompatibles avec la migration de la base) ;
- vérification du rôle du nœud (la procédure de opennebula impose de migrer le leader (base de référence) et EOLE fait l’amalgame entre leader et index 0 dans le cluster) ;
- désactivation des nœuds et de la zone pour ne plus permettre d’éditer la base de données.
- un script en post_upgrade qui effectue les tâches suivantes lorsqu’exécuté sur le serveur d’index 0 :
- montée de version de la base de données (originellement effectuée lors de l’instance suivant l’Upgrade-Auto) ;
- sauvegarde de la base de données ;
- envoi de la base de données sur les autres nœuds du cluster en attente de mise à jour.
- le même script qui effectue les tâches suivantes lorsqu’exécuté sur les autres nœuds du cluster :
- utilisation de la sauvegarde envoyée par le serveur d’index 0 pour écraser sa propre base.
- tous les nœuds devraient disposer de la même base au moment de redémarrer les services ;
- dans l’étape de création du cluster, le nœud d’index 0 initie le cluster alors que les autres serveurs sont disponibles (configuration et services opérationnels) ;
- dans l’étape d’Upgrade-Auto, le nœud d’index 0 devrait également attendre que les autres nœuds soient disponibles avant de démarrer les services ;
- il faut découpler la propagation de la base du redémarrage des services et des opérations de synchronisation pour se laisser le temps de préparer les nœuds follower (d’où le déplacement de certains traitements en post-upgrade).
- conditionner les opérations de synchronisation des nœuds pour permettre l’instance des nœuds indépendamment les uns des autres ;
- casser le lien entre index du serveur et rôle dans le cluster (ce rôle n’est pas attribuable manuellement et la conjonction rôle de leader / index 0 n’est pas garantie).
#6 Mis à jour par Benjamin Bohard il y a environ un mois
- Fichier 99-hapy-ha ajouté
- Fichier 00-hapy-ha ajouté
#7 Mis à jour par Benjamin Bohard il y a 15 jours
- Statut changé de En cours à À valider
#8 Mis à jour par Ludwig Seys il y a 14 jours
- Statut changé de À valider à Résolu
#9 Mis à jour par Joël Cuissinat il y a 13 jours
- Statut changé de Résolu à Fermé
- % réalisé changé de 0 à 100
- Restant à faire (heures) mis à 0.0