.. _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 définies dans la stratégie 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: * Éditer 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= * Éditer le fichier de configuration de la stratégie de stockage ``deployment/environments/group_vars/all/offer_opts.yml`` afin d'ajouter la nouvelle offre: .. code-block:: yaml vitam_strategy: - name: referent: true rank: 0 # is the new offer - name: referent: false rank: 10 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 rank: 0 # is the new offer - name: referent: false rank: 10 vitam_offers: : provider: filesystem # is the new offer : provider: filesystem * Éditer le fichier de déclaration des secrets généraux ``deployment/environments/group_vars/all/main/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 ansible-vitam/vitam.yml -i environments/hosts. --ask-vault-pass --limit "hostname-new-storage-offer,hostname-new-mongos-offer,hostname-new-mongoc-offer,hostname-new-mongod-offer" 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 ansible-vitam/vitam.yml -i environments/hosts. --ask-vault-pass --limit hosts_storage_engine --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 ``deployment/environments/group_vars/all/advanced/vitam_security.yml`` * Le paramètre ``adminPassword`` correspond à la valeur ``admin_basic_auth_password`` déclarée dans le fichier ``deployment/environments/group_vars/all/main/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 * Exemple de script shell permettant de faire une resynchronisation complète de l'ensemble des containers d'une offre à une autre. Ce script est à exécuter à partir d'une vm du groupe `hosts_storage_engine`. Il est recommandé de l'exécuter à l'intérieur d'un `screen` car l'exécution peut-être longue en fonction de la volumétrie à transférer. .. code-block:: bash #!/bin/bash # Script permettant de lancer la synchronisation de l'ensemble des containers d'une offre de stockage à une autre. # /!\ Ce script est à exécuter à partir d'une vm du groupe hosts_storage_engine ################################################################################ ## TODO: Paramètres à personnaliser # cat environments/group_vars/all/advanced/vitam_security.yml | grep admin_basic_auth_user admin_basic_auth_user='adminUser' # ansible-vault view environments/group_vars/all/main/vault-vitam.yml --vault-password-file vault_pass.txt | grep admin_basic_auth_password admin_basic_auth_password='adminPassword' # cat environments/group_vars/all/advanced/vitam_vars.yml | grep consul_domain: ## consul_domain: consul # cat environments/group_vars/all/main/offers_opts.yml ## vitam_strategy.{name,vitam_site_name} # cat environments/hosts.env | grep ^vitam_site_name ## vitam_site_name=dc1 ## {{ vitam_strategy.name }}.service.{{ vitam_strategy.vitam_site_name }}.{{ consul_domain }} # ou l'id de l'offre à synchroniser tel que définit dans environments/group_vars/all/main/offers_opts.yml. sourceOffer="offer-fs-1.service.dc1.consul" targetOffer="offer-fs-2.service.dc1.consul" # cat environments/group_vars/all/advanced/tenants_vars.yml | grep vitam_tenant_ids declare -a tenants="0 1 2" ################################################################################ ## Récupération de l'ip:port du processus storage-engine local service_storage=`netstat -ln | awk -F" " '{print $4}' | grep 29102` if [ -z "$service_storage" ]; then echo "ERROR: Could not find service vitam-storage running on port 29102." exit 1 fi ## Liste des containers declare -a containers="units objects objectgroups logbooks reports manifests profiles storagelog storageaccesslog storagetraceability rules dip agencies backup backupoperations unitgraph objectgroupgraph distributionreports accessionregistersdetail accessionregisterssymbolic tmp archivaltransferreply" ## Confirmation du lancement de la synchro echo "Synchronisation de $sourceOffer => $targetOffer" read -p "Étes-vous sûr de vouloir lancer la synchronisation ? YES/[NO]" GO if [[ "$GO" != "YES" ]] then echo "Arrêt de la procédure de synchronisation." exit 0 fi echo "# Lancement de la procédure de synchronisation de la nouvelle offre" for tenant in $tenants; do echo "********************************************************************************" echo "# Synchronisation du tenant $tenant" for container in $containers; do echo "## Synchronisation ${tenant}_${container}" curl -X POST -u $admin_basic_auth_user:$admin_basic_auth_password --header 'accept: application/json' --header 'content-type: application/json' http://$service_storage/storage/v1/offerSync \ --data "{ \"sourceOffer\": \"${sourceOffer}\", \"targetOffer\": \"${targetOffer}\", \"strategyId\": \"default\", \"container\": \"${container}\", \"tenantId\": ${tenant} }'" while curl --silent -X HEAD -i -u $admin_basic_auth_user:$admin_basic_auth_password http://$service_storage/storage/v1/offerSync | grep 'Running: true'; do curl -X GET -u $admin_basic_auth_user:$admin_basic_auth_password http://$service_storage/storage/v1/offerSync echo "" sleep 5 done echo "## Fin de la synchronisation du tenant ${tenant}_${container}" curl -X GET -u $admin_basic_auth_user:$admin_basic_auth_password http://$service_storage/storage/v1/offerSync echo "" done done .. Procédure de resynchronisation partielle d'une offre ==================================================== * 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 ``deployment/environments/group_vars/all/advanced/vitam_security.yml`` * Le paramètre ``adminPassword`` correspond à la valeur ``admin_basic_auth_password`` déclarée dans le fichier ``deployment/environments/group_vars/all/main/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 recopiés sur l'offre ``targetOffer`` * Si les fichiers ne sont pas trouvés, ils seront supprimés de l'offre ``targetOffer``