4.2.2. Cas particulier d’une installation multi-sites

4.2.2.1. Procédure d’installation

Dans le cadre d’une installation multi-sites, il est nécessaire de déployer la solution logicielle VITAM sur le site secondaire dans un premier temps, puis déployer le site production.

Il faut paramétrer correctement un certain nombre de variables ansible pour chaque site:

4.2.2.1.1. vitam_site_name

Fichier: deployment/environments/hosts.<environnement>

Cette variable sert à définir le nom du site. Elle doit être différente sur chaque site.

4.2.2.1.2. primary_site

Fichier: deployment/environments/hosts.<environnement>

Cette variable sert à définir si le site est primaire ou non. Sur VITAM installé en mode multi site, un seul des sites doit avoir la valeur primary_site à true. Sur les sites secondaires (primary_site: false), certains composants ne seront pas démarrés et apparaitront donc en orange sur l”IHM de consul. Certains timers systemd seront en revanche démarrés pour mettre en place la reconstruction au fil de l’eau, par exemple.

4.2.2.1.3. consul_remote_sites

Fichier: deployment/environments/group_vars/all/main/main.yml

Cette variable sert à référencer la liste des Consul Server des sites distants, à celui que l’on configure.

Exemple de configuration pour une installation avec 3 sites.

Site 1:

consul_remote_sites:
    - dc2:
      wan: ["dc2-host-1","dc2-host-2","dc2-host-3"]
    - dc3:
      wan: ["dc3-host-1","dc3-host-2","dc3-host-3"]

Site 2:

consul_remote_sites:
    - dc1:
      wan: ["dc1-host-1","dc1-host-2","dc1-host-3"]
    - dc3:
      wan: ["dc3-host-1","dc3-host-2","dc3-host-3"]

Site 3:

consul_remote_sites:
    - dc1:
      wan: ["dc1-host-1","dc1-host-2","dc1-host-3"]
    - dc2:
      wan: ["dc2-host-1","dc2-host-2","dc2-host-3"]

Il faut également prévoir de déclarer, lors de l’installation de chaque site distant, la variable ip_wan pour les partitions hébergeant les serveurs Consul (groupe ansible hosts_consul_server) et les offres de stockage (groupe ansible hosts_storage_offer_default, considérées distantes par le site primaire). Ces ajouts sont à faire dans environments/host_vars/<nom partition>.

Exemple:

ip_service: 172.17.0.10 ip_admin: 172.19.0.10 ip_wan: 10.2.64.3

Ainsi, à l’usage, le composant storage va appeler les services offer. Si le service est « hors domaine » (déclaration explicite <service>.<datacenterdistant>.service.<domaineconsul>), un échange d’information entre « datacenters » Consul est réalisé et la valeur de ip_wan est fournie pour l’appel au service distant.

4.2.2.1.4. vitam_offers

Fichier: deployment/environments/group_vars/all/offer_opts.yml

Cette variable référence toutes les offres disponibles sur la totalité des sites VITAM. Sur les sites secondaires, il suffit de référencer les offres disponible localement.

Exemple:

vitam_offers:
    offer-fs-1:
        provider: filesystem-hash
    offer-fs-2:
        provider: filesystem-hash
    offer-fs-3:
        provider: filesystem-hash

4.2.2.1.5. vitam_strategy

Fichier: deployment/environments/group_vars/all/offer_opts.yml

Cette variable référence la stratégie de stockage de plateforme default sur le site courant.

Si l’offre se situe sur un site distant, il est nécessaire de préciser le nom du site, via la variable vitam_site_name, sur lequel elle se trouve comme dans l’exemple ci-dessous.

Il est fortement conseillé de prendre comme offre référente une des offres locale au site. Les sites secondaires doivent uniquement écrire sur leur(s) offre(s) locale(s).

Exemple pour le site 1 (site primaire):

vitam_strategy:
    - name: offer-fs-1
      referent: true
      rank: 0
    - name: offer-fs-2
      referent: false
      distant: true
      vitam_site_name: site2
      rank: 1
    - name: offer-fs-3
      referent: false
      distant: true
      vitam_site_name: site3
      rank: 2
# Optional params for each offers in vitam_strategy. If not set, the default values are applied.
#    referent: false              # true / false (default), only one per site must be referent
#    status: ACTIVE               # ACTIVE (default) / INACTIVE
#    vitam_site_name: distant-dc2 # default is the value of vitam_site_name defined in your local inventory file, should be specified with the vitam_site_name defined for the distant offer
#    distant: false               # true / false (default). If set to true, it will not check if the provider for this offer is correctly set
#    id: idoffre                  # OPTIONAL, but IF ACTIVATED, MUST BE UNIQUE & SAME if on another site
#    asyncRead: false             # true / false (default). Should be set to true for tape offer only
#    rank: 0                      # Integer that indicates in ascending order the priority of the offer in the strategy

Exemple pour le site 2 (site secondaire):

vitam_strategy:
    - name: offer-fs-2
      referent: true

Exemple pour le site 3 (site secondaire):

vitam_strategy:
    - name: offer-fs-3
      referent: true

4.2.2.1.6. other_strategies

Fichier: deployment/environments/group_vars/all/offer_opts.yml

Cette variable référence les stratégies de stockage additionnelles sur le site courant. Elles ne sont déclarées et utilisées que dans le cas du multi-stratégies. Si l’offre se situe sur un site distant, il est nécessaire de préciser le nom du site sur lequel elle se trouve comme dans l’exemple ci-dessous. Les sites secondaires doivent uniquement écrire sur leur(s) offre(s) locale(s).

Les offres correspondant à l’exemple other_strategies sont les suivantes:

vitam_offers:
    offer-fs-1:
        provider: filesystem-hash
    offer-fs-2:
        provider: filesystem-hash
    offer-fs-3:
        provider: filesystem-hash
    offer-s3-1:
        provider: amazon-s3-v1
    offer-s3-2:
        provider: amazon-s3-v1
    offer-s3-3:
        provider: amazon-s3-v1

Exemple pour le site 1 (site primaire):

other_strategies:
    metadata:
        - name: offer-fs-1
          referent: true
          rank: 0
        - name: offer-fs-2
          referent: false
          distant: true
          vitam_site_name: site2
          rank: 1
        - name: offer-fs-3
          referent: false
          distant: true
          vitam_site_name: site3
          rank: 2
        - name: offer-s3-1
          referent: false
          rank: 3
        - name: offer-s3-2
          referent: false
          distant: true
          vitam_site_name: site2
          rank: 4
        - name: offer-s3-3
          referent: false
          distant: true
          vitam_site_name: site3
          rank: 5
    binary:
        - name: offer-s3-1
          referent: false
          rank: 0
        - name: offer-s3-2
          referent: false
          distant: true
          vitam_site_name: site2
          rank: 1
        - name: offer-s3-3
          referent: false
          distant: true
          vitam_site_name: site3
          rank: 2

Exemple pour le site 2 (site secondaire):

other_strategies:
    metadata:
        - name: offer-fs-2
          referent: true
          rank: 0
        - name: offer-s3-2
          referent: false
          rank: 1
    binary:
        - name: offer-s3-2
          referent: false
          rank: 0

Exemple pour le site 3 (site secondaire):

other_strategies:
    metadata:
        - name: offer-fs-3
          referent: true
          rank: 0
        - name: offer-s3-3
          referent: false
          rank: 1
    binary:
        - name: offer-s3-3
          referent: false
          rank: 0

4.2.2.1.7. plateforme_secret

Fichier: deployment/environments/group_vars/all/main/vault-vitam.yml

Cette variable stocke le secret de plateforme qui doit être commun à tous les composants de la solution logicielle VITAM de tous les sites. La valeur doit donc être identique pour chaque site.

4.2.2.1.8. consul_encrypt

Fichier: deployment/environments/group_vars/all/main/vault-vitam.yml

Cette variable stocke le secret de plateforme qui doit être commun à tous les Consul de tous les sites. La valeur doit donc être identique pour chaque site.

4.2.2.2. Procédure de réinstallation

En prérequis, il est nécessaire d’attendre que tous les workflows et reconstructions (sites secondaires) en cours soient terminés.

Ensuite:

  • Arrêter vitam sur le site primaire.
  • Arrêter les sites secondaires.
  • Redéployer vitam sur les sites secondaires.
  • Redéployer vitam sur le site primaire

4.2.2.3. Flux entre Storage et Offer

Dans le cas d’appel en https entre les composants Storage et Offer, il faut modifier deployment/environments/group_vars/all/advanced/vitam_vars.yml et indiquer https_enabled: true dans storageofferdefault.

Il convient également également d’ajouter:

  • Sur le site primaire
    • Dans le truststore de Storage: la CA ayant signé le certificat de l’Offer du site secondaire
  • Sur le site secondaire
    • Dans le truststore de Offer: la CA ayant signé le certificat du Storage du site primaire
    • Dans le grantedstore de Offer: le certificat du storage du site primaire
../_images/certificats-multisite.png

Vue détaillée des certificats entre le storage et l’offre en multi-site

Il est possible de procéder de 2 manières différentes:

4.2.2.3.1. Avant la génération des keystores

Avertissement

Pour toutes les copies de certificats indiquées ci-dessous, il est important de ne jamais les écraser, il faut donc renommer les fichiers si nécessaire.

Déposer les CA du client storage du site 1 environments/certs/client-storage/ca/* dans le client storage du site 2 environments/certs/client-storage/ca/.

Déposer le certificat du client storage du site 1 environments/certs/client-storage/clients/storage/*.crt dans le client storage du site 2 environments/certs/client-storage/clients/storage/.

Déposer les CA du serveur offer du site 2 environments/certs/server/ca/* dans le répertoire des CA serveur du site 1 environments/certs/server/ca/*

4.2.2.3.2. Après la génération des keystores

Via le script deployment/generate_stores.sh, il convient donc d’ajouter les CA et certificats indiqués sur le schéma ci-dessus.

Ajout d’un certificat : keytool -import -keystore -file <certificat.crt> -alias <alias_certificat>

Ajout d’une CA: keytool -import -trustcacerts -keystore -file <ca.crt> -alias <alias_certificat>