.. _resynchronisation-offre: Resynchronisation d'une offre ############################# Une offre de stockage peut être désynchronisée par rapport à une autre à la suite d'une indisponibilité plus ou moins longue voire totale de l'offre (`crash` majeur du système, panne matérielle etc.) ou bien encore à la suite d'une mise en maintenance programmée. Le mécanisme de resynchronisation d'une offre par rapport à une autre nécessite une intervention d'exploitation manuelle permettant de remédier à la perte de données dans le système. .. note:: En cas d'indisponibilité d'une offre, le processus d'entrée d'un :term:`SIP` n'étant réussi que si et seulement si toutes les offres de stockage definies dans la strategie sont accessibles, et que tous les fichiers sont bien copiés sur la totalité de ces offres, il sera nécessaire de désactiver l'offre (cf. chapitre :ref:`activation_offre`) afin de permettre à nouveau les entrées de :term:`SIP` (ingest/versement). .. caution:: Il est recommandé de procéder à un audit d’intégrité dans le cadre d’opérations techniques ciblées, telles que l’évolution de la stratégie de stockage, un changement de stockage. .. _ajout-offre: Cas de l'ajout d'une nouvelle offre =================================== .. warning:: Lors de l'ajout d'une nouvelle offre (portant un nouvel identifiant d'offre), les métadonnées des AU / GOT existants ne seront pas mis à jour avec l'information sur la nouvelle stratégie de stockage utilisée. L’ajout d’un mécanisme de mise à jour / propagation des métadonnées est prévu dans une version ultérieure. Lors de l'ajout d'une offre en remplacement d'une précédente offre, l'intégrité des métadonnées sera garantie en conservant le même identifiant d'offre. L'ajout d'une nouvelle offre de stockage requiert le déploiement des applicatifs :term:`VITAM` associés selon la procédure suivante: * Editer le fichier de configuration de l'inventaire de déploiement (généralement, fichier ``hosts``) afin d'ajouter les nouveaux serveurs portant les composants à déployer (fonction de la topologie de déploiement retenue): .. code-block:: yaml [hosts_storage_offer_default] hostname-new-storage-offer offer_conf= [hosts_mongos_offer] hostname-new-mongos-offer offer_conf= [hosts_mongoc_offer] hostname-new-mongoc-offer offer_conf= [hosts_mongod_offer] hostname-new-mongod-offer offer_conf= * Editer le fichier de configuration de la strategie de stockage ``offer_opts.yml`` afin d'ajouter la nouvelle offre: .. code-block:: yaml vitam_strategy: - name: referent: true # is the new offer - name: referent: false vitam_offers: : provider: filesystem # is the new offer : provider: filesystem Si la nouvelle offre est utilisée dans une stratégie additionnelle (``other_strategies``), la modification sera la suivante: .. code-block:: yaml other_strategies: metadata: - name: referent: false # is the new offer - name: referent: false vitam_offers: : provider: filesystem # is the new offer : provider: filesystem * Editer le fichier de déclaration des secrets généraux ``vault-vitam.yml`` afin d'y ajouter les secrets associés à la nouvelle offre: .. code-block:: yaml mongodb: : passphrase: admin: user: password: localadmin: user: password: offer: user: password: * Exécuter la commande suivante afin de déployer les nouveaux composants storage-offer, mongos-offer, mongoc-offer, mongod-offer: .. note:: On considère que les étapes de génération des `hostvars`, de génération des magasins de certificats et de mise en place des repositories :term:`VITAM` ont été réalisées au préalable pour les serveurs concernées (se référer aux sections du `DIN` correspondantes). .. code-block:: bash ansible-playbook -i environments/ -l "hostname-new-storage-offer,hostname-new-mongos-offer,hostname-new-mongoc-offer,hostname-new-mongod-offer" ansible-vitam/vitam.yml --ask-vault-pass La nouvelle offre doit ensuite être déclarée dans la stratégie de stockage par reconfiguration du moteur de stockage selon la procédure suivante: .. warning:: Cette opération provoque une indisponibilité temporaire des principaux services :term:`VITAM` (versement, gestion, recherche et consultation) * Exécuter la commande suivante afin de reconfigurer le composant storage-engine : .. code-block:: bash ansible-playbook -i environments/ -l hosts_storage_engine ansible-vitam/vitam.yml --ask-vault-pass --tags update_vitam_configuration Procédure de resynchronisation d'une offre ========================================== La resynchronisation d'une offre à partir du contenu d'une autre offre s'effectue en suivant la procédure suivante: .. note:: Cette procédure n'impacte pas les services :term:`VITAM`. 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 fonctionne de manière concurrente au mécanisme de resynchronisation. * Exécuter la commande suivante afin de resynchroniser la nouvelle offre vis-à-vis de l'offre (des offres) source(s): .. code-block:: bash curl -v -X POST -u adminUser:adminPassword --header 'content-type: application/json' --header 'accept: application/json' http://:29102/storage/v1/offerSync --data ' { "sourceOffer": ".service.consul", "targetOffer": ".service.consul", "strategyId": , "container": , "tenantId": }' * Le paramètre ``adminUser`` correspond à la valeur ``admin_basic_auth_user`` déclarée dans le fichier ``vitam_security.yml`` * Le paramètre ``adminPassword`` correspond à la valeur ``admin_basic_auth_password`` déclarée dans le fichier ``vault-vitam.yml`` * Le paramètre ``sourceOffer`` correspond à l'**id** de l'offre source utilisée pour la resynchronisation de la nouvelle offre * Le paramètre ``targetOffer`` correspond à l'**id** de l'offre à resynchroniser * Le paramètre ``strategyId`` correspond à la stratégie des offres source et cible * le paramètre ``tenantId`` correspond au tenant sur lequel appliquer la synchronisation * Le paramètre ``container`` correspond à un élément datatype de la liste suivante : .. literalinclude:: data/container_list.txt :language: text * Suivre les journaux de la resynchronisation dans les logs du composant storage offer avec la commande suivante: .. code-block:: bash tail -F /vitam/log/storage/storage_offer_sync.\*.log * Vérifier l'état d'exécution de la synchronisation via la commande (peut être scriptée) : .. code-block:: bash curl -v -X HEAD -i -u adminUser:adminPassword http://:29102/storage/v1/offerSync L'entête ``Running`` indique l'état d'exécution de processus de synchronisation. * Vérifier le détail d'exécution de la synchronisation via la commande : .. code-block:: bash curl -v -X GET -u adminUser:adminPassword http://:29102/storage/v1/offerSync * En cas de resynchronisation partielle d'une offre, il est possible d'exécuter le processus de resynchronisation à partir d'un ``offset`` : .. code-block:: bash curl -v -X POST -u adminUser:adminPassword --header 'content-type: application/json' --header 'accept: application/json' http://:29102/storage/v1/offerSync --data ' { "sourceOffer": ".", "targetOffer": ".", "strategyId": , "offset": , "container": , "tenantId": }' Où doit prendre les valeurs suivantes : .. literalinclude:: data/container_list.txt :language: text * Le paramètre ``offset`` correspond à la valeur du dernier ``offset`` observé dans les logs du composant storage offer (cas d'une reprise suite à interruption ou échec de la procédure de resynchronisation). Le paramètre ``offset`` peut également être déterminé via les enregistrements de la collection ``OfferLog`` (database ``offer``) depuis la base MongoDB associée à l'offre à resynchroniser (cas d'une panne ou d'une mise en maintenance programmée à une date précise). Procédure de resynchronisation ciblée d'une offre ================================================= La release R13 permet l'exécution d'une resynchronisation ciblée d'une offre de stockage, à partir d'une liste d'items à resynchroniser. .. code-block:: bash curl -v -X POST -u adminUser:adminPassword --header 'content-type: application/json' --header 'accept: application/json' http://:29102/storage/v1/offerPartialSync --data ' { "strategyId" : , "sourceOffer" : ".service.consul", "targetOffer" : ".service.consul", "itemsToSynchronize" : [ { "container" : "objects", "tenantId" : 0, "filenames" : [ "ObjectId0", "ObjectId1", "ObjectId2", "ObjectId3", "ObjectId4" ] },{ "container" : "units", "tenantId" : 0, "filenames" : [ "UnitId0", "UnitId1"] } ] }' * Le paramètre ``adminUser`` correspond à la valeur ``admin_basic_auth_user`` déclarée dans le fichier ``vitam_security.yml`` * Le paramètre ``adminPassword`` correspond à la valeur ``admin_basic_auth_password`` déclarée dans le fichier ``vault-vitam.yml`` * Le paramètre ``sourceOffer`` correspond à l'**id** de l'offre source utilisée pour la resynchronisation de la nouvelle offre * Le paramètre ``targetOffer`` correspond à l'**id** de l'offre à resynchroniser * Le paramètre ``strategyId`` correspond à la stratégie des offres source et cible * le paramètre ``tenantId`` correspond au tenant sur lequel appliquer la synchronisation * Le paramètre ``container`` correspond à un élément datatype de la liste suivante : .. literalinclude:: data/container_list.txt :language: text Depuis l'offre ``sourceOffer``, la procédure récupère les ``filenames`` pour le ``tenantId`` et le ``container`` concerné. * Si les fichiers sont trouvés, ils sont alors recopés sur l'offre ``targetOffer`` * Si les fichiers ne sont pas trouvés, ils seront supprimés de l'offre ``targetOffer``