5.19. Plan de Reprise d’Activité (PRA)

Le PRA consiste à passer un site VITAM secondaire en site primaire après incident majeur survenu sur le site primaire (cas de l’indisponibilité complète du site primaire).

Note

Les actions en cours sur le site primaire sont perdues (versements non terminés, batchs etc.). L’incohérence des données sera traitée dans une version ultérieure de VITAM..

Cette section décrit des actions qui ne peuvent donc s’effectuer que si une installation multi-sites a été effectuée au préalable.

Cette section s’appuie sur les procédures décrites dans les chapitres suivants:

  • Resynchronisation d’une offre à partir d’une autre offre (Resynchronisation d’une offre)
  • Reconstruction des bases de données (MongoDB-data, Elasticsearch-data) en cas de perte de l’une ou l’autre, à partir des informations présentes dans les offres (Reconstruction)

5.19.1. Déclenchement

Avant le déclenchement de la procédure de PRA, le système fonctionne en mode multi-sites (primaire/secondaire). Le service est indisponible à la suite de la perte du site primaire.

Le déclenchement du PRA s’effectue selon la procédure suivante:

  1. Vérifier que le site primaire est bien complètement arrêté

    • Il est indispensable de valider que tous les services VITAM (y compris les timers systemd) sont bien arrêtés

  2. Attendre la fin de la reconstruction au fil de l’eau sur le site secondaire

    • Le suivi de la reconstruction se fait en observant l’évolution de l’offset de reconstruction stocké dans MongoDB-data.

  3. Reconfigurer le site secondaire en site primaire:

    • Attention à adapter la stratégie de stockage en fonction du mode d’utilisation choisi pour le site de secours:

      • Mode « lecture/écriture » : la stratégie de stockage doit être modifiée afin de limiter les écritures aux seules offres encore disponibles sur le site de secours (Activation/désactivation d’une offre)
      • Mode « lecture seule » (recherche et consultation avec profil de droits dédié): la stratégie de stockage ne change pas. Seule une reconfiguration du site primaire initial en mode secondaire permettra le retour à un fonctionnement nominal (cf. ci-dessous)

    • Paramétrer la variable primary_site à true dans le fichier d’inventaire puis jouer le playbook ansible-vitam/vitam.yml

    • Si le site secondaire était partiellement déployé, ne pas oublier de rajouter tous les composants requis pour un fonctionnement en site primaire.

  4. En lien avec le processus de reconstruction (cf. Reconstruction), en cas de bascule sur le site secondaire, il sera préférable de purger les documents des Unit et ObjectGroup reconstruits mais ne contenant potentiellement que des données de graphe (cas de l’éliminitaion par exemple). Cette opération s’effectue avec la commande suivante :

curl -s -X DELETE -H "X-Tenant-Id: {{ vitam_tenant_admin }}" -H "Accept: application/json" -H "Content-Type: application/json" --user "{{ admin_basic_auth_user }}:{{ admin_basic_auth_password }}" http://{{ ip_admin }}:{{ vitam.metadata.port_admin }}/metadata/v1/purgeGraphOnlyDocuments/[UNIT | OBJECTGROUP | UNIT_OBJECTGROUP]

Après modification des accès pour les applications versantes (action infra. de type modification DNS, routage, conf etc.), le site secondaire peut alors être ouvert au service en tant que site primaire.

Le système fonctionne désormais en mode mono-site (primaire). Le service est de nouveau disponible sur le site de secours.

5.19.2. Retour en situation nominale

Le retour à la solution nominale s’effectue en deux étapes:

  • Rétablissement du contenu du site primaire initial par reconfiguration temporaire en tant que site secondaire
  • Retour à la configuration multi-sites initiale

Avertissement

Dans cette version, la resynchronisation partielle d’une offre de stockage n’étant pas supportée, le retour à la configuration multi-sites initiale nécessite de repartir d’offres vierges de toutes données sur le site à resynchroniser (on parle ici d’offre de remplacement)

5.19.2.1. Déclenchement

Avant déclenchement de la procédure de PRA inverse (retour en situation nominale), le système fonctionne en mode mono-site (primaire). Le service est disponible sur le site de secours.

Le déclenchement du PRA inverse s’effectue selon la procédure suivante:

  • Vérifier que le site primaire initial est bien complètement arrêté

    • Il est indispensable de valider que tous les services VITAM (y compris les timers systemd) sont bien arrêtés

  • Purger les données (le cas échéant) stockées dans MongoDB-data, excepté les bases identity, config et admin

  • Purger les données (le cas échéant) stockées dans Elasticsearch-data

  • Reconfigurer et démarrer le site primaire initial en tant que site secondaire:

    • Paramétrer la variable primary_site à false dans le fichier d’inventaire puis jouer le playbook ansible-vitam/vitam.yml
    • Le mécanisme de reconstruction du contenu des bases de données (MongoDB-data, Elasticsearch-data) à partir des informations présentes dans les offres de stockage est actif (aucune donnée à resynchroniser à cette étape)

  • Resynchroniser les offres de stockage à partir des offres du site de secours en se référant à la procédure suivante Resynchronisation d’une offre

    • En fonction du mode d’utilisation choisi pour le site de secours:

      • Mode lecture/écriture: la stratégie de stockage du site de secours doit auparavant être modifiée afin de référencer de nouveau les offres du site primaire initial
      • Mode lecture seule: la stratégie de stockage ne change pas. Les offres du site primaire initial sont toujours connues du site de secours

  • Le mécanisme de reconstruction au fil de l’eau reconstruit progressivement le contenu des bases de données

    • Le suivi de la reconstruction se fait en observant l’évolution de l’offset de reconstruction stocké dans MongoDB data
    • Pour la release 7 (version 1.4.x) il faut lancer le service dédié vitam-metadata-graph-builder.service sur le composant metadata pour recalculer les données graphe des unités archivistiques et des groupes d’objets techniques n’ayant pas encore reconstruit leurs données graphe

  • Une fois la reconstruction terminée, reconfiguration en tant que site primaire et démarrage:

    • Paramétrer la variable primary_site à true dans le fichier d’inventaire puis jouer le playbook ansible-vitam/vitam.yml

  • Reconfiguration et démarrage en tant que site secondaire du site de secours:

    Avertissement

    Cette opération provoque une indisponibilité temporaire des principaux services VITAM (versement, gestion, recherche et consultation)

    • Paramétrer la variable primary_site à false dans le fichier d’inventaire puis jouer le playbook ansible-vitam/vitam.yml

Après modification des accès pour les applications versantes (action infra. de type modification DNS, routage, conf etc.), le site primaire initial peut alors être de nouveau ouvert au service en tant que site primaire.

Le système fonctionne désormais de nouveau en mode multi-sites (primaire/secondaire). Le service est de nouveau disponible sur le site primaire initial.