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