Plan de Reprise d'Activité (:term:`PRA`) ######################################### Le :term:`PRA` consiste à passer un site :term:`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 :term:`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 (:ref:`resynchronisation-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 (:ref:`reconstruction`) Déclenchement ============= Avant le déclenchement de la procédure de :term:`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 :term:`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 (:ref:`activation_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. :ref:`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 : .. code-block:: bash 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. 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 .. warning:: 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) Déclenchement -------------- Avant déclenchement de la procédure de :term:`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 :term:`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 :ref:`resynchronisation-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: .. warning:: Cette opération provoque une indisponibilité temporaire des principaux services :term:`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.