# 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-v2
        offer-s3-2:
            provider: amazon-s3-v2
        offer-s3-3:
            provider: amazon-s3-v2

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

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