5.1.5. Déploiement de la solution

5.1.5.1. Principes de déploiement

Les principes généraux de déploiement sont les suivants :

• Les packages d’installation (rpm / deb) sont identiques pour tous les environnements ; seule leur configuration change.
• La configuration des services est externalisée et gérée par l’outillage de déploiement.
• Le déploiement est décrit intégralement dans un fichier de définition du déploiement. En dehors des pré-requis, le déploiement initial est automatisé en totalité (sauf exception).
• Les services sont configurés par défaut pour permettre leur colocalisation (dans le sens de la colocalisation de deux instances de deux moteurs différents) (ex: dossiers d’installation / de fonctionnement différents, ports d’écoute différents, …).

Le déploiement s’effectue à partir d’un point central ; les commmandes passées sur chaque serveur à partir de ce point central utilisent le protocole SSH.

Voir aussi

Pour plus d’informations sur l’outillage de déploiement, se reporter à la section sur l’outillage de déploiement

5.1.5.2. Contraintes et vue d’ensemble

Les zones logiques présentées dans la section sur l’architecture applicative VITAM correspondent également aux zones de sécurité préconisées pour le déploiement de VITAM :

Déploiement VITAM : zones & principes de communication ; les utilisateurs métier archivistes sont présentés à gauche, et les exploitants technique à droite.

Voir aussi

Ce découpage est repris dans la présentation de l’architecture technique détaillée.

Chaque zone héberge des clusters de services ; un cluster doit être présent en entier dans une zone, et ne peut par conséquent pas être réparti dans deux zones différentes. Chaque noeud d’un cluster applicatif doit être installé sur un hôte (OS) distinct (la colocalisation de deux instances d’un même service n’étant pas supportée) ; dans le cas de l’utilisation d’un système de virtualisation d’OS (type hyperviseur), il est recommandé de placer deux noeuds d’un même cluster applicatif sur deux serveurs physiques différents.

Le découpage en zones suit un découpage classique de système « n-tiers » ; par conséquent, il est prévu pour respecter les contraintes de flux inter-zones suivants :

• les systèmes externes utilisateurs de VITAM peuvent uniquement communiquer avec les services de la zone accès ;
• les services déployés dans la zone accès peuvent communiquer avec les services de la zone applicative ;
• les services déployés dans la zone applicative peuvent communiquer avec les services des zones stockage et données ;
• les services déployés dans les zones accès, applicative, stockage et données peuvent communiquer avec les services déployés dans la zone exploitation et administration ;
• les exploitants techniques peuvent accéder aux services déployés dans la zone exploitation et administration.

Voir aussi

Un complément plus fin sur la problématique de colocalisation de composants est disponible dans l’architecture technique détaillée.

Prudence

Globalement, les connexions réseau associées aux flux métier se font dans le sens externe vers interne. Une exception à cette règle existe cependant au niveau des flux elasticsearch ; en effet, le fonctionnement des clients natifs elasticsearch (utilisés notamment dans metadata et functional-administration) impose des flux bidirectionnels entre les membres du cluster elasticsearch et ses clients natifs, donc entre la zone applicative et la zone données.

VITAM supporte l’installation sur une infrastructure dont les serveurs possèdent 2 interfaces réseau disjointes pour le réseau de service (sur lequel transitent les flux métier, représentés en noir dans les schémas) et le réseau d’administration/exploitation (sur lequel transitent les flux transverses à toutes les zones et la zone d’administration/exploitation, représentés en violet dans les schémas).

5.1.5.3. Installation initiale

Le processus de déploiement a les responsabilités suivantes :

• Effectuer une mise en conformité des OS des serveurs cibles pour certains pré-requis à l’installation de VITAM, notamment :
  • les utilisateurs, groupes et dossiers propres à VITAM ;
  • certains services système utilisés par VITAM (ex: rsyslog).
• Déployer, installer et configurer les composants logiciels VITAM ;
• Déployer certaines configurations de tuning système (ex: sysctl.conf, limits.conf).

Note

La portée des modifications appliquées au système sera décrite de manière plus précise dans la documentation d’installation livrée avec chaque version.

La portée de la configuration applicative est décrite dans le schéma présenté au paragraphe Contraintes et vue d’ensemble.

Voir aussi

Plus de détails sur l’installation sont disponibles dans le DIN.

5.1.5.4. Principes de mise à jour à chaud

La mise à jour à chaud depuis une version précédente du système VITAM n’est pas supportée dans cette version de la solution VITAM.

5.1.5.5. Multi-site

Les principes de déploiement de VITAM sur plusieurs sites sont décrits dans la section Architecture des données & multisite.

5.1.5.6. Support de l’élasticité

Un déploiement de VITAM sur une infrastructure élastique (ex: AWS Auto Scaling, Azure AutoScaling, GCE managed instance groups , Openstack Heat AutoScalingGroup, …) n’est pas supporté dans cette version de la solution VITAM.

5.1.5.7. Validation du déploiement

La validation du déploiement peut être réalisée à partir d’un ensemble de tests techniques et métier fournis par VITAM et permettant de valider le bon fonctionnement du système. A terme, ces tests seront exécutables même sur des environnements de production, dans un tenant dédié pour ne pas impacter les autres utilisateurs du système.

En particulier, les autotests des composants permettent d’avoir une première validation technique d’un déploiement.