5.20. 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 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 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.20.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:

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

    [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>

  • É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:

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

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
        rank: 0
    # <offer-z> is the new offer
    - name: <offer-z>
        referent: false
        rank: 10
vitam_offers:
    <offer-x>:
        provider: filesystem
    # <offer-z> is the new offer
    <offer-z>:
        provider: filesystem

  • Éditer le fichier de déclaration des secrets généraux deployment/environments/group_vars/all/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 ansible-vitam/vitam.yml -i environments/hosts.<environnement> --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:

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 ansible-vitam/vitam.yml -i environments/hosts.<environnement> --ask-vault-pass --limit hosts_storage_engine --tags update_vitam_configuration

5.20.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 deployment/environments/group_vars/all/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/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

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

    #!/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/vitam_security.yml | grep admin_basic_auth_user
admin_basic_auth_user='adminUser'
# ansible-vault view environments/group_vars/all/vault-vitam.yml --vault-password-file vault_pass.txt | grep admin_basic_auth_password
admin_basic_auth_password='adminPassword'

# cat environments/group_vars/all/vitam_vars.yml | grep consul_domain:
## consul_domain: consul
# cat environments/group_vars/all/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/offers_opts.yml.
sourceOffer="offer-fs-1.service.dc1.consul"
targetOffer="offer-fs-2.service.dc1.consul"

# cat environments/group_vars/all/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

5.20.3. 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 :

    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.20.4. 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 deployment/environments/group_vars/all/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/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 recopiés sur l’offre targetOffer * Si les fichiers ne sont pas trouvés, ils seront supprimés de l’offre targetOffer