Projet

Général

Profil

Tâche #37304

Scénario #37182: Upgrade-Auto Hâpy 2.9 → 2.10

Étude

Ajouté par Benjamin Bohard il y a environ 2 mois. Mis à jour il y a 12 jours.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Début:
01/10/2022
Echéance:
% réalisé:

100%

Restant à faire (heures):
0.0

99-hapy-ha (631 octets) Benjamin Bohard, 09/02/2026 11:32

00-hapy-ha (2,55 ko) Benjamin Bohard, 09/02/2026 11:32

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).

Pour le cas plus complexe de montée de version d’un cluster, il semble manquer une procédure (et les scripts qui permettraient de la mettre en œuvre). Voici ce qui a été réalisé (mais non complété) dans le cadre de ce scénario :
  • 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.
Cette procédure n’est pas validée. Voici les observations effectuées à ce stade :
  • 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).
Quelques pistes qui n’ont pas été approfondies :
  • 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

#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

Formats disponibles : Atom PDF