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

Le mécanisme de resynchronisation d’une offre par rapport à une autre nécessite une intervention manuelle permettant de remédier à la perte de données dans le système en proposant différentes stratégies de resynchronisation:

• La resynchronisation totale d’une offre de stockage (cas de la perte totale et définitive d’une offre)
• La resynchronisation partielle d’une offre de stockage (cas de l’indisponibilité sur un temps plus ou moins long 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écommissionner l’offre afin de permettre à nouveau les entrées de SIP (ingest/versement).

Note

Dans cette version, la resynchronisation partielle d’une offre de stockage n’est pas supportée.

5.12.1. Décommissionnement d’une offre

Lors de la détection de la perte d’une offre de stockage, afin de permettre à nouveau les versements, l’offre pourra être décommisionnée en fonction du mode d’utilisation choisi:

• Mode « lecture/écriture »: la stratégie de stockage doit être modifiée
• Mode « lecture seule » (recherche et consultation avec profil de droits dédié): la stratégie de stockage ne change pas

Le décommissionnement d’une offre s’effectue selon la procédure suivante:

• Editer le fichier de configuration de la strategie de stockage offer_opts.yml afin de retirer l’offre posant problème (commenter les lignes correspondantes):

  vitam_strategy:
  - name: <offer-x>
      referent: true
  # <offer-y> is down
  #- name: <offer-y>
  #    referent: false
  
  vitam_offers:
      <offer-x>:
          provider: filesystem
      # <offer-y> is down
      #<offer-y>:
      #    provider: filesystem
  

• 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
  

Avertissement

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

5.12.2. Ajout d’une 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
  

• 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 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 stokage 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.12.3. Resynchronisation totale d’une offre

Suite à l’ajout d’une offre de stockage, celle-ci doit être resynchronisée vis-à-vis d’une offre source selon 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  http://<offer-x.hosts-storage-offer-default>:29102/storage/v1/offerSync < query
  {
      "offerSource": "<offer-x>.service.consul",
      "offerDestination": "<offer-z>.service.consul"
  }
  

  • 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 offerSource correspond à l’id de l’offre source utilisée pour la resynchronisation de la nouvelle offre
  • Le paramètre offerDestination correspond à l’id de l’offre à resynchroniser

• Suivre le déroulement de la resynchronisation dans les logs du composant storage offer avec la commande suivante:

  tail -F /vitam/log/storage/storage_offer_sync.\*.log
  

  • Les différents messages « [OfferSync]: successful synchronization of category : <container>, tenant : <tenantId>, offset : <offset> » indiquent la fin de resynchronisation de la categorie <container>, pour le tenant <tenantId>, avec l’offset de resynchronisation <offset>
  • Le message « The offers” synchronization is completed » indique la fin du processus de resynchronisation

• En cas d’interruption ou d’échec de la resynchronisation (le message indiquant la fin du processus de resynchronisation n’est pas affiché), il est possible de relancer le processus de la manière suivante:

  curl -v -X POST -u adminUser:adminPassword  http://<hosts-storage-offer-default>:29102/storage/v1/offerSync < query
  {
      "offerSource": "<offer-x>.<consul_domain>",
      "offerDestination": "<offer-z>.<consul_domain>",
      "offset": <offset>,
      "containerToSync": <container>,
      "tenantIdToSync": <tenantId>
  }
  

  Dans le log de la dernière exécution du processus de resynchronisation : « [OfferSync]: successful synchronization of category : <container>, tenant : <tenantId>, offset : <offset> »

  • Le paramètre offset correspond à la valeur <offset> observée
  • Le paramètre containerToSync correspond à la valeur <container> observée
  • Le paramètre tenantIdToSync correspond à la valeur <tenantId> observée