# 4.2.2. Notes et procédures spécifiques R16

## 4.2.2.1. Procédures à exécuter AVANT la montée de version

### 4.2.2.1.1. Supprimer les indexes de configuration kibana

Prudence

Cette opération doit être effectuée avant la montée de version si vous disposez d’une instance R16.4 ou inférieur (4.0.4-), vers une version R16.5 ou supérieur (4.0.5+).

Prudence

Sans cette opération, l’installation kibana est bloquée et arrête l’installation de Vitam

Lors de la montée de version ELK, les indices de configuration kibana : .kibana et .kibana_task_manager persistent avec une version et des informations incorrectes (celles de la version d’avant). Il est nécessaire des les effacer; autrement la montée de version est bloquée.

Exécutez le playbook suivant:

    ansible-playbook -i environments/<inventaire> ansible-vitam-migration/remove_old_kibana_indexes.yml --ask-vault-pass

Ce playbook clone les indices de configuration (.kibana et .kibana_task_manager) et efface les originaux. Les clones d’indice sont conservés.

La montée de version va recréer ces indices avec les nouvelles configurations relatives au nouvel ELK.

### 4.2.2.1.2. Réinitialisation de la reconstruction des registres de fond des sites secondaires

Prudence

Cette procédure doit être exécutée uniquement en cas de migration depuis une version R16.6- (4.0.6 ou inférieure) vers une version R16.7+ (4.0.7 ou supérieure). Elle permet la réinitialisation de la reconstruction des registre de fonds sur les sites secondaires.

La procédure est à réaliser sur tous les sites secondaires de Vitam AVANT l’installation de la nouvelle version :

- S’assurer que les timers de Vitam aient bien été préalablement arrêtés (via le playbook `ansible-vitam-exploitation/stop_vitam_timers.yml`)

- Exécuter le playbook :

      ansible-playbook ansible-vitam-migration/migration_accession_register_reconstruction.yml -i environments/hosts.{env} --ask-vault-pass

### 4.2.2.1.3. Contrôle et nettoyage de journaux du storage engine des sites secondaires

Prudence

Cette procédure doit être exécutée uniquement en cas de migration depuis une version R16.6- (4.0.6 ou inférieure) vers une version R16.7+ (4.0.7 ou supérieure). Elle permet le contrôle et la purge des journaux d’accès et des journaux d’écriture du storage engine des sites secondaires.

La procédure est à réaliser sur tous les sites secondaires de Vitam AVANT l’installation de la nouvelle version :

- S’assurer que Vitam soit bien préalablement arrêté (via le playbook `ansible-vitam-exploitation/stop_vitam.yml`)

- Exécuter le playbook :

      ansible-playbook ansible-vitam-migration/migration_purge_storage_logs_secondary_sites.yml -i environments/hosts.{env} --ask-vault-pass

## 4.2.2.2. Procédures à exécuter APRÈS la montée de version

### 4.2.2.2.1. Arrêt des timers et des accès externes à Vitam

Les timers et les externals de Vitam doivent être arrêtés sur tous les sites :

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

### 4.2.2.2.2. Migrations offres Swift V2 & V3 en cas de présence d’objets très volumineux (4Go+)

Note

Cette procédure doit être lancée une seule fois, et pour chaque offre Swift V2/V3, APRES upgrade Vitam, et uniquement depuis le site primaire.

Si vous disposez d’une instance R16.3 ou inférieur (4.0.3-), vers une version R16.4+ (4.0.4+), et que vous utilisez des offres Swift V2/V3 (providers openstack-swift-v2 et/ou openstack-swift-v3), il est nécessaire de procéder à une migration des données :

    $ ansible-playbook ansible-vitam-migration/migration_swift_v2_and_v3.yml -i environments/hosts.{env} --ask-vault-pass

    # Confirm playbook execution
    # Enter swift offer id (ex offer-swift-1)
    # Select migration mode
    # > Enter '0' for analysis only mode : This mode will only log anomalies (in offer technical logs), no update will be proceeded
    # > Enter '1' to fix inconsistencies : This mode will update swift objects to fix inconsistencies. However, this does not prune objects (delete partially written or eliminated objects segments to free space).
    # > Enter '2' to fix inconsistencies and purge all deleted objects segments to free storage space.
    # Reconfirm playbook execution

Il est recommandé de lancé la procédure en mode 0 (analyse seule) et de vérifier les erreurs de cohérence dans les logs Seules les offres Swift V2/V3 avec des objets volumineux (>= 4Go) nécessitent migration. Un exemple d’incohérences journalisées dans les logs (/vitam/log/offers) est donnée ici :

    INCONSISTENCY FOUND : Object env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq has old segment names [aeaaaaaaaagbcaacaamboal2tk643jqaaaaq/2, aeaaaaaaaagbcaacaamboal2tk643jqaaaaq/1]. Run migration script with fix inconsistencies mode to prune container.
    INCONSISTENCY FOUND : Object env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq has missing metadata. Run migration script with fix inconsistencies mode enabled to set object metadata.

Si la détection des anomalies est terminée en succès, et que des anomalies sont trouvées, il est recommandé de lancer le mode 1 (correction des anomalies). Les migrations de données sont également journalisées dans les logs (/vitam/log/offers) :

    Renaming segment env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq/2 to env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq/00000002
    Renaming segment env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq/1 to env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq/00000001
    Object env_2_object/aeaaaaaaaagbcaacaamboal2tk643jqaaaaq migrated successfully. Digest: 8959ea1290aa064a3c64d332f31e049bd4f9d4e95bebe0b46d38613bb079761d52c865dce64c88fd7e02313d340f9a2f8c0c6b5dbf8909a3cbda071d26ce21d4

Si des problèmes de cohérence de type « Orphan large object segments » persistent

    INCONSISTENCY FOUND : Orphan large object segments [...] without parent object manifest: env_2_object/aeaaaaaaaagbcaacaamboal2tk7dzmiaaaaq. Eliminated object? Incomplete write? Run migration script with delete mode to prune container.

Dans ce cas, il est recommandé de vérifier préalablement que les objets concernés n’existent pas sur les autres offres (mêmes container & objectName). Si les objets n’existent pas dans les autres offres, il s’agit alors de reliquats d’objets non complètement éliminés. Le lancement du mode 2 (correction des anomalies + purge des objets) est à réaliser. Dans le cas contraire (cas où l’objet existe dans les autres offres), il faudra envisager la « Procédure de resynchronisation ciblée d’une offre » décrite dans la Documentation d’EXploitation (DEX) de Vitam pour synchroniser l’offre Swift pour les éléments concernés.

### 4.2.2.2.3. Recalcul du graph des métadonnées des sites secondaires

Prudence

Cette procédure doit être exécutée uniquement en cas de migration depuis une version R16.6- (4.0.6 ou inférieure) vers une version R16.7+ (4.0.7 ou supérieure). Elle permet le recalcul du graphe des métadonnées sur les sites secondaires

La procédure est à réaliser sur tous les sites secondaires de Vitam APRÈS l’installation de la nouvelle version :

- S’assurer que Vitam soit bien préalablement arrêté (via le playbook `ansible-vitam-exploitation/stop_vitam_timers.yml`)

- Exécuter le playbook :

      ansible-playbook ansible-vitam-migration/migration_metadata_graph_reconstruction.yml -i environments/hosts.{env} --ask-vault-pass

### 4.2.2.2.4. Redémarrage des timers et des accès externes à Vitam

La montée de version est maintenant terminée, vous pouvez réactiver les services externals ainsi que les timers sur tous les sites :

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