5.17. 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 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 Activation/désactivation d’une offre) afin de permettre à nouveau les entrées de SIP (ingest/versement).

Prudence

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.

5.17.1. Cas de l’ajout d’une nouvelle offre

Avertissement

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 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):

    [hosts_storage_offer_default]
hostname-new-storage-offer      offer_conf=<offer-z>

[hosts_mongos_offer]
hostname-new-mongos-offer       offer_conf=<offer-z>

[hosts_mongoc_offer]
hostname-new-mongoc-offer       offer_conf=<offer-z>

[hosts_mongod_offer]
hostname-new-mongod-offer       offer_conf=<offer-z>

  • Editer le fichier de configuration de la strategie de stockage offer_opts.yml afin d’ajouter la nouvelle offre:

    vitam_strategy:
- name: <offer-x>
    referent: true
# <offer-z> is the new offer
- name: <offer-z>
    referent: false

vitam_offers:
    <offer-x>:
        provider: filesystem
    # <offer-z> is the new offer
    <offer-z>:
        provider: filesystem

    Si la nouvelle offre est utilisée dans une stratégie additionnelle (other_strategies), la modification sera la suivante:

    other_strategies:
    metadata:
    - name: <offer-x>
        referent: false
    # <offer-z> is the new offer
    - name: <offer-z>
        referent: false

vitam_offers:
    <offer-x>:
        provider: filesystem
    # <offer-z> is the new offer
    <offer-z>:
        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:

    mongodb:
    <offer-z>:
        passphrase: <passphrase>
        admin:
          user: <admin-user>
          password: <admin-password>
        localadmin:
          user: <localadmin-user>
          password: <localadmin-password>
        offer:
          user: <offer-user>
          password: <offer-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 VITAM ont été réalisées au préalable pour les serveurs concernées (se référer aux sections du DIN correspondantes).

ansible-playbook -i environments/<hosts> -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:

Avertissement

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

  • Exécuter la commande suivante afin de reconfigurer le composant storage-engine :

    ansible-playbook -i environments/<hosts> -l hosts_storage_engine ansible-vitam/vitam.yml --ask-vault-pass --tags update_vitam_configuration

5.17.2. 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 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):

    curl -v -X POST -u adminUser:adminPassword --header 'content-type: application/json' --header 'accept: application/json' http://<storageengine>:29102/storage/v1/offerSync --data '
{
    "sourceOffer": "<offer-x>.service.consul",
    "targetOffer": "<offer-z>.service.consul",
    "strategyId": <strategyId>,
    "container": <datatype>,
    "tenantId": <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 :
"units"
"objects"
"objectgroups"
"logbooks"
"reports"
"manifests"
"profiles"
"storagelog"
"storageaccesslog"
"storagetraceability"
"rules"
"dip"
"agencies"
"backup"
"backupoperations"
"unitgraph"
"objectgroupgraph"
"distributionreports"
"accessionregistersdetail"
"accessionregisterssymbolic"
"tmp"
"archivaltransferreply"

  • Suivre les journaux de la resynchronisation dans les logs du composant storage offer avec la commande suivante:

    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) :

    curl -v -X HEAD -i -u adminUser:adminPassword http://<storageengine>: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 :

    curl -v -X GET -u adminUser:adminPassword http://<storageengine>: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 :

    curl -v -X POST -u adminUser:adminPassword --header 'content-type: application/json' --header 'accept: application/json' http://<storageengine>:29102/storage/v1/offerSync --data '
{
    "sourceOffer": "<offer-x>.<consul_domain>",
    "targetOffer": "<offer-z>.<consul_domain>",
    "strategyId": <strategyId>,
    "offset": <offset>,
    "container": <datatype>,
    "tenantId": <tenantId>
}'

    Où <datatype> doit prendre les valeurs suivantes :

    "units"
"objects"
"objectgroups"
"logbooks"
"reports"
"manifests"
"profiles"
"storagelog"
"storageaccesslog"
"storagetraceability"
"rules"
"dip"
"agencies"
"backup"
"backupoperations"
"unitgraph"
"objectgroupgraph"
"distributionreports"
"accessionregistersdetail"
"accessionregisterssymbolic"
"tmp"
"archivaltransferreply"
    • 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).

5.17.3. 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.

curl -v -X POST -u adminUser:adminPassword --header 'content-type: application/json' --header 'accept: application/json' http://<storageengine>:29102/storage/v1/offerPartialSync --data '
{
    "strategyId" : <strategyId>,
    "sourceOffer" : "<offer-x>.service.consul",
    "targetOffer" : "<offer-z>.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 :
"units"
"objects"
"objectgroups"
"logbooks"
"reports"
"manifests"
"profiles"
"storagelog"
"storageaccesslog"
"storagetraceability"
"rules"
"dip"
"agencies"
"backup"
"backupoperations"
"unitgraph"
"objectgroupgraph"
"distributionreports"
"accessionregistersdetail"
"accessionregisterssymbolic"
"tmp"
"archivaltransferreply"

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