4.2.2.3. Montée de version 1.4.5 vers 1.10.0¶

La montée de version 1.4.5 (« R7.5 ») vers 1.10.0 (« R8 ») est réalisée par réinstallation de la solution logicielle VITAM grâce aux playbooks ansible fournis, et selon la procédure d’installation classique décrite dans le Document d’INstallation (DIN).

Prudence

La migration doit être réalisée en partant de la version la plus récente de la version « R7 » (1.4.5).

4.2.2.3.1. Prérequis à l’installation¶

4.2.2.3.1.1. Arrêt des timers systemd¶

Les commandes sont à lancer depuis le répertoire deployment sur les différents sites hébergeant la solution logicielle VITAM :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/stop_vitam_timers.yml --vault-password-file vault_pass.txt

ou, si vault_pass.txt n’a pas été renseigné :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/stop_vitam_timers.yml --ask-vault-pass

A l’issue de ce playbook, les timers systemD ont été arrêtés, afin de ne pas perturber la migration.

Il est également recommandé de ne lancer la procédure de migration qu’une fois s’être assuré qu’aucun workflow n’est actuellement en cours de traitement.

4.2.2.3.1.2. Upgrade Mongodb 3.4 vers 4.0¶

La montée de version 1.4.5 (« R7.5 ») vers 1.10.0 (« R8 ») comprend une montée de version de MongoDB de la version 3.4 à la version 4.0.

Les commandes sont à lancer depuis le répertoire deployment sur les différents sites hébergeant la solution logicielle VITAM :

Stopper Vitam (playbook ansible-vitam-exploitation/stop_vitam.yml)
Démarrer les différents cluster mongodb (playbook ansible-vitam-exploitation/start_mongodb.yml)
Upgrader mongodb en 3.6 (playbook ansible-vitam-exploitation/migration_mongodb_36.yml)
Upgrader mongodb en 4.0 (playbook ansible-vitam-exploitation/migration_mongodb_40.yml)
Démarrer Vitam (playbook ansible-vitam-exploitation/start_vitam.yml)

4.2.2.3.1.3. Reprise des données de certificats¶

La version 1.10.0 (« R8 ») apporte une nouvelle fonctionnalité permettant la révocation des certificats SIA et Personae afin d’empecher des accès non autorisés aux API Vitam (vérification dans la couche https des CRL). Cette fonctionnalité impose d’effectuer une reprise des données des certificats (base MongoDB identity, collections Certificate et PersonalCertificate).

Les commandes sont à lancer depuis le répertoire deployment sur les différents sites hébergeant la solution logicielle VITAM :

ansible-playbook ansible-vitam-exploitation/migration_r7_certificates.yml --ask-vault-pass

4.2.2.3.2. Etapes post-installation¶

Dans le cadre d’une montée de version 1.4.5 (« R7.5 ») vers 1.10.0 (« R8 »), il est nécessaire d’appliquer un playbook de migration de données à l’issue de réinstallation de la solution logicielle VITAM.

Prudence

Dans le cadre d’une installation multi-sites, il faut d’abord lancer la migration des données sur le site secondaire afin de purger les registres des fonds, ensuite lancer la migration sur le site primaire puis enfin lancer la reconstruction des registres des fonds sur le site secondaire.

4.2.2.3.2.1. Procédure de migration des données¶

Lancer les commandes ci-après dans l’ordre suivant :

D’abord sur le site secondaire pour purger les registres des fonds

Ensuite sur le site primaire pour la migration des registres des fonds.

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/migration_r7_r8.yml --vault-password-file vault_pass.txt

ou, si vault_pass.txt n’a pas été renseigné :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/migration_r7_r8.yml --ask-vault-pass

Avertissement

Selon la volumétrie des données précédement chargées, le playbook peut durer jusqu’à plusieurs heures.

Note

Durant le temps des migrations, il est fortement recommandé de ne pas procéder à des injections de données. Le playbook se charge d’arrêter les composants « ingest-external » et « access-external », de réaliser les opérations de migration des données, puis de redémarrer les composants « ingest-external » et « access-external ».

Les changements apportés par la migration R7 vers R8 sont :

Les registres des fonds (Accession Registers)

Diff AccessionRegisterDetail:

Suppression du champs Identifier, remplacé par Opc (Opération courante)

Suppression du champs OperationGroup, remplacé par Opi (Opération d’ingest)

Suppression du champs Symbolic

Suppression des champs attached, detached, symbolicRemained des sous objets (« TotalUnits », « TotalObjectGroups », « TotalObjects », « ObjectSize »)

Ajout d’un sous objet Events

Diff AccessionRegisterSummary:

Suppression des champs attached, detached, symbolicRemained des sous objets (« TotalUnits », « TotalObjectGroups », « TotalObjects », « ObjectSize »)

Le journal des opérations

On n’aura que les données du registre des fonds selon le nouveau modèle dans le evDetData du journal de l’opération d”ingest.

Note

Se reporter à la documentation du nouveau modèle de données de la R8.

Avertissement

En cas de souci, contacter l’équipe support.

4.2.2.3.2.2. Après la migration des données¶

A l’issue de la bonne exécution du playbook, il faut lancer la commande suivante pour réactiver les timers systemD sur les différents sites hébergeant la solution logicielle VITAM :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/start_vitam_timers.yml --vault-password-file vault_pass.txt

ou, si vault_pass.txt n’a pas été renseigné :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/start_vitam_timers.yml --ask-vault-pass

4.2.2.3.2.3. Une fois le site secondaire up¶

Sur le site secondaire, vérifier que le processus de reconstruction des registres des fonds s’est bien démarré, sur les machines hébergeant le composant « functional-administration ».

La commande à passer en tant que root est la suivante :

systemctl status vitam-functional-administration-accession-register-reconstruction.service

4.2.2.3.2.4. Vérification de la bonne migration des données¶

A l’issue de la migration, il est fortement conseillé de lancer un « Audit de cohérence » sur les différents tenants.