5.13. Eléments de dimensionnement¶

Prudence

Les abaques de dimensionnement sont étroitement liés à la nature de l’infrastructure sous-jacente et à l’usage qui est fait de la solution logicielle VITAM. Par conséquent, les indications de volumétrie qui sont présentées dans la suite de ce document sont purement indicatives et relatives au système VITAM dans sa version actuelle, installé sur les environnements de tests de la solution logicielle (qui sont opérés en environnement complètement virtualisé).

Note

Sauf mention contraire, les enveloppes de ressources ci-dessous comprennent notamment les composants associés à l’exploitation de la solution logicielle VITAM et fournis dans le cadre de la solution (traitement et stockage des logs et des métriques, gestion des bases de données, …)

Important

Les configurations de référence ci-dessous sont données pour un seul site primaire comportant une seule offre de stockage. VITAM préconise très fortement un déploiement comportant a minima 2 offres de stockage. En fonction des contraintes de disponibilité du système, il sera donc nécessaire :

Soit d’ajouter une autre offre de stockage (i.e. les composants storage-offer et mongo*-offer) dans le cas d’un déploiement mono-site ;
Soit d’ajouter un site secondaire comportant sa propre offre de stockage.

5.13.1. Compute¶

5.13.1.1. « xsmall » : développement local¶

Adapté à un poste de développement ; ce déploiement ne comprend pas les composants d’exploitation de la solution VITAM. La chaîne de traitement de logs n’est pas déployée, et le même cluster mongodb est utilisé pour l’offre de stockage et les métadonnées.

Ce déploiement n’est pas adapté pour un fonctionnement en production.

Dimensionnement XSmall¶
Zone	Composants	# instances	vCPU / instance	RAM / instance
zone_access zone_external zone_applicative zone_data zone_storage zone_admin	hosts_ihm_demo hosts_ihm_recette hosts_cerebro hosts_ingest_external hosts_access_external hosts_ingest_internal hosts_access_internal hosts_storage_engine hosts_workspace hosts_processing hosts_worker hosts_functional_administration hosts_logbook hosts_security_internal hosts_batch_report hosts_metadata hosts_mongoc_data hosts_mongos_data hosts_mongod_data hosts_elasticsearch_data hosts_storage_offer_default (file) hosts_consul_server	1	4	16 Go

TOTAL GLOBAL ENV	vitam	1	4	16 Go

Note

Pour ce type d’environnement, il est recommandé de définir un paramètre elasticsearch_memory ( pour les composants elasticsearch-log et elasticsearch-data) avec une taille faible et compatible avec les ressources disponibles, afin de ne pas rencontrer de phénomènes de OOM.

Voir aussi

Se reporter au DIN pour plus d’informations.

5.13.1.2. « small » : recette simple métier¶

Adapté à un environnement de recette simple d’application métier utilisant VITAM.

Ce déploiement n’est pas adapté pour un fonctionnement en production.

Dimensionnement Small¶
Zone	Composants	# instances	vCPU / instance	RAM / instance
zone_external zone_applicative	hosts_ingest_external hosts_access_external hosts_ingest_internal hosts_access_internal hosts_storage_engine hosts_workspace hosts_processing hosts_worker	1	6	12 Go
zone_access zone_applicative zone_data	hosts_ihm_demo hosts_ihm_recette hosts_functional_administration hosts_security_internal hosts_logbook hosts_batch_report hosts_metadata hosts_mongoc_data hosts_mongos_data hosts_mongod_data hosts_elasticsearch_data	1	6	12 Go
zone_storage zone_admin	hosts_storage_offer_default (file) hosts_mongoc_offer hosts_mongos_offer hosts_mongod_offer hosts_elasticsearch_log hosts_consul_server hosts_logstash hosts_kibana_log hosts_cerebro hosts_kibana_data	1	6	12 Go

TOTAL GLOBAL ENV	vitam	3	18	36

S’agissant d’un environnement de recette, l’utilisation de 2 offres de stockages ou de 2 sites est possible, mais non préconisée (il s’agit d’un environnement de recette métier, et non technique).

Note

Pour ce type d’environnement, il est recommandé de définir un paramètre elasticsearch_memory ( pour les composants elasticsearch-log et elasticsearch-data) avec une taille faible et compatible avec les ressources disponibles, afin de ne pas rencontrer de phénomènes de OOM.

Voir aussi

Se reporter au DIN pour plus d’informations.

5.13.1.3. « medium » : production pour volumétries moyennes¶

Adapté à un déploiement simple pour des volumétries moyennes (quelques To / an) ; seuls le worker et les composants stockant des données sont multi-instanciés (i.e. les bases de données et les offres de stockage). L’offre de stockage proposée est une offre de stockage « file », plus simple à exploiter et compatible avec une volumétrie moyenne.

Sur les 3 serveurs mongod et mongoc pour l’offre de stockage, l’un d’eux est déployé en tant qu’arbitre (participe au quorum du replica set, mais ne stocke pas de données).

Dimensionnement Medium¶
Zone	Composants	# instances	vCPU / instance	RAM / instance
zone_access	hosts_ihm_demo	1	1	2 Go
zone_external	hosts_ingest_external hosts_access_external	1	1	2 Go
zone_applicative	hosts_ingest_internal hosts_access_internal hosts_functional_administration hosts_logbook hosts_security_internal hosts_metadata	1	4	4 Go
zone_applicative	hosts_storage_engine hosts_workspace hosts_batch_report hosts_processing	1	4	4 Go
zone_applicative	hosts_worker	2	4	4 Go
zone_storage	hosts_storage_offer_default (file) hosts_mongoc_offer (arbitre) hosts_mongod_offer (arbitre)	1	4	4 Go
zone_storage	hosts_mongoc_offer hosts_mongos_offer hosts_mongod_offer	2	2	4 Go
zone_data	hosts_mongoc_data hosts_mongos_data hosts_mongod_data hosts_elasticsearch_data	3	4	8 Go
zone_admin	hosts_elasticsearch_log hosts_consul_server hosts_logstash hosts_kibana_log (x1 uniquement) hosts_cerebro (x1 uniquement) hosts_kibana_data (x1 uniquement)	3	4	8 Go

TOTAL GLOBAL ENV	vitam	15	50	80

Comme précisé précédemment, ce dimensionnement ne contient qu’une seule offre de stockage ; il devra être complété de préférence par un deuxième site (avec le même dimensionnement), ou bien par une offre de stockage supplémentaire sur le site principal (en doublant les ressources allouées à la zone storage).

5.13.1.4. « large » : production pour volumétries moyennes avec besoin de résilience¶

Adapté à un déploiement résilient pour des volumétries plus importantes (10 à 20 To / an) ; ce déploiement comprend au moins deux instances pour tous les composants le supportant, et passe à une offre de stockage objet Swift ou S3 (pour une meilleure scalabilité de l’offre).

Dimensionnement Large¶
Zone	Composants	# instances	vCPU / instance	RAM / instance
zone_access	hosts_ihm_demo	1	2	4 Go
zone_external	hosts_ingest_external hosts_access_external	2	1	4 Go
zone_applicative	hosts_ingest_internal hosts_access_internal hosts_functional_administration	2	1	4 Go
zone_applicative	hosts_logbook hosts_batch_report hosts_security_internal hosts_metadata hosts_storage_engine	2	4	4 Go
zone_applicative	hosts_worker	3	4	4 Go
zone_applicative	hosts_workspace hosts_batch_report hosts_processing	1	4	6 Go
zone_storage	hosts_storage_offer_default (swift/s3) hosts_mongoc_offer hosts_mongos_offer hosts_mongod_offer	3	4	8 Go
zone_data	hosts_elasticsearch_data	3	4	6 Go
zone_data	hosts_mongoc_data hosts_mongos_data	3	2	4 Go
zone_data	hosts_mongod_data	3	4	12 Go
zone_admin	hosts_logstash hosts_kibana_log (x1 uniquement) hosts_cerebro (x1 uniquement) hosts_kibana_data (x1 uniquement)	2	2	4 Go
zone_admin	hosts_elasticsearch_log hosts_consul_server	3	4	8 Go

TOTAL GLOBAL ENV	vitam	28	88	168

Comme précisé précédemment, ce dimensionnement ne contient qu’une seule offre de stockage ; il devra être complété de préférence par un deuxième site (avec le même dimensionnement), ou bien par une offre de stockage supplémentaire sur le site principal (en doublant les ressources allouées à la zone storage).

Note

Le composant batch-report est multi-instanciable et peut donc être colocalisé avec les composants mono-instanciables suivants : workspace et processing. L’alternative est de colocaliser avec la zone applicative comprenant logbook, security-internal, metadata et storage-engine.

5.13.1.5. « xlarge » : production pour fortes volumétries¶

Adapté à un déploiement pour de fortes volumétries (ordre de grandeur des capacités d’ingest : > 50 To / an, > 100.10^6 objets / an). Ce déploiement implique la multi-instanciation de tous les composants le supportant et l’usage d’un stockage objet Swift ou S3.

Dimensionnement XLarge¶
Zone	Composants	# instances	vCPU / instance	RAM / instance
zone_access	hosts_ihm_demo	1	2	4 Go
zone_external	hosts_ingest_external hosts_access_external	2	2	4 Go
zone_applicative	hosts_ingest_internal hosts_access_internal	2	2	4 Go
zone_applicative	hosts_logbook hosts_security_internal	3	4	4 Go
zone_applicative	hosts_metadata hosts_functional_administration	3	4	4 Go
zone_applicative	hosts_processing	1	2	4 Go
zone_applicative	hosts_worker	10	4	6 Go
zone_applicative	hosts_workspace	1	8	8 Go
zone_applicative	hosts_batch_report	2	8	4 Go
zone_applicative	hosts_storage_engine	4	4	4 Go
zone_storage	hosts_storage_offer_default (swift/s3)	2	4	4 Go
zone_storage	hosts_mongoc_offer hosts_mongos_offer	3	2	4 Go
zone_storage	hosts_mongod_offer	3	2	4 Go
zone_data	hosts_elasticsearch_data	6	6	12 Go
zone_data	hosts_mongoc_data hosts_mongos_data	3	4	8 Go
zone_data	hosts_mongod_data	6	6	24 Go
zone_admin	hosts_logstash hosts_kibana_log (x1 uniquement) hosts_cerebro (x1 uniquement) hosts_kibana_data (x1 uniquement)	2	4	4 Go
zone_admin	hosts_elasticsearch_log hosts_consul_server	3	4	8 Go

TOTAL GLOBAL ENV	vitam	57	236	448

Comme précisé précédemment, ce dimensionnement ne contient qu’une seule offre de stockage ; il devra être complété de préférence par un deuxième site (avec le même dimensionnement), ou bien par une offre de stockage supplémentaire sur le site principal (en doublant les ressources allouées à la zone storage).

5.13.2. Stockage¶

Plus que tout autre, le calcul du dimensionnement du stockage dépend étroitement de la nature des archives qui doivent être conservées dans la solution logicielle.

Les drivers principaux de dimensionnement des différents emplacements de stockage sont les suivants :

Répertoire « tmp » du composant ingest-external : ce répertoire doit pouvoir stocker les SIP en cours d’analyse antivirus avant leur dépôt dans workspace ; sa taille dépend donc de la taille maximale des SIP présents en entrée et du nombre d’ingest initiés en parallèle.
Répertoire « data » du composant workspace : ce répertoire doit pouvoir stocker les données en cours de traitement (contenu décompressé des SIP en cours d’ingest, des objets binaires en cours de préservation, ainsi que les exports de données DIP en cours…) ; sa taille dépend donc de la taille maximale des SIP présents en entrée et du nombre d’ingest et de préservation simultanés (en attente ou en cours de traitement) ainsi que du volume et de la durée de rétention des DIP (par défault 7 jours, paramétrables dans la configuration du module metadata).
Répertoire « tmp » du composant worker : ce répertoire doit pouvoir stocker les objets binaires en cours de traitement par le worker ; il s’agit généralement du produit "capacité du worker" x "taille maximale d'un objet binaire".
Répertoire « data » du composant elasticsearch-data : ce cluster stocke les métadonnées associées aux archives (GOT et AU) ainsi que les journaux d’opération. Pour ces éléments :
- La taille et la quantité des AU et des GOT dépend des données entrées dans VITAM (facteur métier) ;
- Le nombre d’opérations dépend de l’usage du système (et notamment de la granularité des SIP en entrée). En ordre de grandeur, le journal d’une opération d’ingest a une taille brute de 50 Ko ; le journal d’une opération d’update, 5 Ko (d’après des mesures effectuées sur des environnements de tests de la solution logicielle) ;
- Au niveau global du cluster, le rapport entre la donnée brute (entrée dans elasticsearch) et la donnée persistée est le produit "facteur de réplication" x 2 (le facteur 2 provient du champ _source qui contient le document original conservé par elasticsearch à côté des index) ;
- La taille unitaire d’un répertoire « data » sur une instance se calcule ensuite en fonction du nombre de noeuds disponibles dans le cluster (l’hypothèse d’une répartition uniforme peut être retenue).
Répertoire « data » du composant mongod-data : ce cluster stocke les métadonnées associées aux archives (GOT, AU et LFC associé) ainsi que les journaux d’opération. Pour ces éléments :
- La taille et la quantité des AU et des GOT dépend du métier ;
- Les LFC associés à une AU sont estimés à un peu moins de 5 Ko (d’après des mesures effectuées sur des environnements de tests de la solution logicielle) ;
- Le nombre d’opérations dépend de l’usage du système (et notamment de la granularité des SIP en entrée). En ordre de grandeur, le journal d’une opération d’ingest a une taille moyenne brute de 50 Ko ; le journal d’une opération d’update ou audit, 5 Ko (d’après des mesures effectuées sur des environnements de tests de la solution logicielle) ;
- Au niveau global du cluster, le rapport entre la donnée brute (entrée dans MongoDB) et la donnée persistée est le produit "facteur de réplication" x "facteur d'expansion". Le facteur d’expansion dépend de la base de données impactée, et il est fonction du taux d’indexation et de sa capacité de compression. D’après des mesures effectuées sur des environnements de tests de la solution logicielle, ce facteur prend les valeurs suivantes :
  - 1,2 pour la base de données des métadonnées d’archive (AU & GOT)
  - 0,4 pour les journaux d’opération
- La taille unitaire d’un répertoire « data » sur une instance se calcule ensuite en fonction du nombre de noeuds disponibles dans le cluster (l’hypothèse d’une répartition uniforme peut être retenue, MongoDB opérant un rééquilibrage progressif des shards).
Répertoire « log » du composant storage : chaque écriture vers le stockage implique la création d’une entrée dans le journal des écritures du composant storage. Ainsi :
- La taille de ce répertoire dépend du nombre d’éléments écrits, et notamment : AU, GOT, BDO, journaux d’opérations ;
- Pour les journaux d’opération : chaque journal implique au moins deux écritures à cause de sa sécurisation ;
- Chaque entrée du journal des écritures a une taille moyenne de 500 octets (d’après des mesures effectuées sur des environnements de tests de la solution logicielle).
Répertoire « data » du composant storage-offer (en configuration « file »), ou taille de l’object storage swift utilisé (pour un storage-offer en configuration « swift ») : il s’agit du stockage pérenne des données conservées dans VITAM, qui comprend notamment :
- les AU, GOT et BDO ;
- les journaux d’opération ;
- les journaux sécurisés.
Répertoire « tmp » du composant storage-offer : ce répertoire doit pouvoir stocker les rapports liés à l’audit comparatif des offres ; sa taille dépends du nombre de fichiers présents dans les conteneurs à comparer. Pour un conteneur contenant plus de 1 million de fichiers, prévoir environs 300 Mo d’espace disque.
Répertoire « data » du composant mongod-offer : chaque écriture dans une offre de stockage implique la journalisation de cette écriture dans l’archivelog d’écriture. Le nombre d’entrées est le nombre de données écrites via storage (cf. point précédent) ; la taille unitaire d’une entrée dans ce log est 260 octets (d’après des mesures effectuées sur des environnements de tests de la solution logicielle).
Répertoire « data » du composant elasticsearch-log : ce cluster stocke les logs techniques issus de l’application. Il est assez difficile de donner un dimensionnement analytique réaliste de ce composant (trop d’éléments entrant en jeu). Pour donner un ordre de grandeur purement indicatif, pour un système en ingest pur (i.e. sans accès), il a été observé une moyenne de 20 Ko de log brut par triplet (AU, GOT, BDO) entré dans le système.

5.13.3. Réseau : inter-site¶

Un lien réseau IP doit exister entre les deux sites et respecter les flux décrits dans la matrice de flux externes (se reporter à Matrice des flux).

Le routage niveau 3 est permis sur ce lien, par translation d’adresse, mais pas par translation de port (i.e. chaque serveur devant être exposé sur le site 2 au site 1 peut exposer une adresse IP WAN visible depuis le site 1 différente de son adresse IP LAN locale).

Concernant ce lien intersite, les éléments permettant son dimensionnement sont les suivants :

La latence est peu critique (elle joue principalement sur la performance des batchs, et pas des accès utilisateurs ; l’optimisation des performances se fera dans ce cas par l’augmentation des pools de threads de storage et l’augmentation de la capacité des workers) ;
Par contre, un débit adapté est requis ; dans cette version de VITAM, ce dernier peut se calculer à partir de la somme des débits d’ingest des AU + GOT + BDO + journaux.

5.13.4. Scalabilité¶

De manière générale, la consommation en ressources (CPU/RAM/réseau/stockage) de VITAM dépend de 3 grands cas d’utilisation :

La quantité d’archives versées (ingest) : supporter plus d’ingest nécessite de renforcer les ressources disponibles pour les composants actifs lors d’un ingest : ingest-external, ingest-internal, processing, worker, workspace, logbook, metadata, storage, storage-offer, elasticsearch-data, mongodb ;
La quantité d’archives gérées (audit & pérennisation) : dans cette version de VITAM, les fonctions liées à ces deux domaines sont limitées ; par conséquent, la quantité de données gérées a uniquement une influence sur les dépôts de données : storage, storage-offer, elasticsearch-data, mongodb ;
La quantité d’archives consultées (access) : supporter plus de requêtes concurrentes nécessite de renforcer les ressources disponibles pour les composants actifs lors d’une consultation : access-external, access-internal, logbook, metadata, storage, storage-offer, elasticsearch-data, mongodb.

Note

Les composants de référentiels (functional-administration, security-internal), même s’ils sont utilisés dans la plupart des scenarii métier, bénéficient d’un fort effet de cache du côté des clients de ces services ; par conséquent, ils sont moins sensibles que les autres à l’augmentation de capacité.