Aller au contenu principal

Mise à jour de version majeure de BlueMind : passer de v4 en v5

Le changement de version majeure de BlueMind requiert une attention toute particulière sur un certain nombre de points en complément de la validation des prérequis d'une mise à jour habituelle.

Points de vigilance​

Données non migrées​

Lors de la reprise des données, les mails contenus dans le double fond de la corbeille et les brouillons marqués pour suppression (anciennes versions de brouillons) ne sont pas migrés.

Configuration CAS​

Dans BlueMind 5 la configuration CAS s'effectue par domaine et non plus pour l'ensemble du serveur comme en v4. La configuration CAS du serveur n'est donc pas migrée.

Prérequis à la mise à jour vers BlueMind 5​

Version de BlueMind​

Afin de pouvoir passer en BlueMind 5, la version 4 doit être installée et à jour de la dernière version disponible.

Système​

En vue de la montée de version de PostgreSQL de 14 en 16, la partition /var/lib/postgresql doit avoir un taux d'occupation inférieur à 50%.

Test d'éligibilité​

Exécution obligatoire

Ce test d'éligibilité doit impérativement être réalisé avant de mettre à jour BlueMind de v4 en v5.

Un test d'éligibilité check-upgrade-v5 a été ajouté au client CLI afin d'éviter toute perte de données et assurer une mise à jour en v5 maîtrisée et sécurisée.

Ce test vérifie ces 5 points majeurs :

  • Checking custom settings
  • Checking hotupgrades
  • Checking elasticsearch cluster status
  • Checking cyrus replication
  • Cyrus email checks

Lancer le test en exécutant la commande suivante :

bm-cli setup check-upgrade-5 --sampling-percentage=100
Durée du test et Consommation de ressources

Selon le dimensionnement, la commande chek-upgrade-5 peut durer plus d'une heure. Il est recommandé de l'exécuter dans une session screen ou tmux.

Le test et les opérations de maintenance qui suivent peuvent être gourmandes en ressources.
Il est donc recommandé de les exécuter pendant des créneaux de faible activité assez longs, par exemple en fin de journée.

Des commandes de réparation à exécuter sont ensuite proposées, selon les défauts identifiés.
La liste de commandes se présente comme suit (exemple) :

Recommended repair commands to run: 
bm-cli hotupgrade start --no-delay --scheduled
bm-cli index coherency --all --run-consolidate --workers=1 all
bm-cli maintenance repair --ops replication.parentUid 1518B471-729C-4C99-AEC0-86D4D87DCB12@734ea413.internal
bm-cli maintenance repair --ops replication.parentUid,message_bodies B9584543-273B-43F0-A450-09FCB38526A6@734ea413.internal

Lancer une nouvelle vérification une fois les réparations recommandées effectuées. Cela permet de rafraîchir la liste des erreurs et de potentiellement remonter celles qui n'ont pas été reportées ou réparées précédemment.

Transmission des résultats

Il est fortement recommandé de transmettre, via la création d'un ticket Jira, le résultat des exécutions successives de ces commandes de test.

Souscription​

La souscription doit être mise à jour uniquement lorsque le test d'éligibilité est validé.

La mise à jour de BlueMind lors d'un changement de version majeure nécessite un changement des adresses des dépôts logiciels. Le fichier de souscription doit donc être mis à jour afin de pouvoir réaliser le changement de version.

Mise à jour​

Une fois les prérequis et le test d'éligibilité validés, suivre la procédure de mise à jour de BlueMind.

Nettoyage des sauvegardes v4

Une fois la mise à jour terminée, il est recommandé de purger les sauvegardes de BlueMind 4.

En effet, BlueMind 5 sauvegarde les e-mails selon une nouvelle méthode dans /var/backups/bluemind/sds-spool. La première sauvegarde reprend tous les e-mails, ce qui peut déclencher une alerte de saturation du disque si l'espace disponible est < 50%.

Les sauvegardes v4 ne sont plus compatibles. Les supprimer permet de regagner de l'espace.

Opérations post-mise à jour​

Des opérations en arrière-plan sont exécutées suite à la mise à jour. Elles ont été prévues pour tourner sans impacter le service en production.

Certaines fonctionnalités sont débloquées au fil de l'eau suite à ces opérations post-ugrade. Il s'agit en particulier des tris avancés sur les e-mails et le paramétrage des conversations de messages.

Pour contrôler le bon avancement des opérations post-upgrade, lancer la commande :

bm-cli hotupgrade progress --details --filterSuccess

Si ces opérations sont en échec, un bandeau s'affiche dans la console d'administration et l'indique aux administrateurs. Dans ce cas, créer un ticket (ou mettre à jour celui concernant le test d'éligibilité - voir ci-dessus) sur notre outil de suivi de tickets.

Dernière mise à jour le