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 du système 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 resources ci-dessous comprennent notamment les composants associés à l’exploitation de la solution 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.
| Zone | Composants | # instances | vCPU / instance | RAM / instance |
|---|---|---|---|---|
|
|
1 | 4 | 16 Go |
| TOTAL | vitam | 1 | 4 | 16 Go |
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.
| Zone | Composants | # instances | vCPU / instance | RAM / instance |
|---|---|---|---|---|
|
|
1 | 6 | 12 Go |
|
|
1 | 6 | 12 Go |
|
|
1 | 6 | 12 Go |
| TOTAL | 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).
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).
| Zone | Composants | # instances | vCPU / instance | RAM / instance |
|---|---|---|---|---|
| zone-access |
|
1 | 1 | 2 Go |
| zone-external |
|
1 | 1 | 2 Go |
| zone-applicative |
|
1 | 4 | 4 Go |
| zone-applicative |
|
1 | 4 | 4 Go |
| zone-applicative |
|
2 | 4 | 4 Go |
| zone-storage |
|
1 | 4 | 4 Go |
| zone-storage |
|
2 | 2 | 4 Go |
| zone-data |
|
3 | 4 | 8 Go |
| zone-admin |
|
3 | 4 | 8 Go |
| TOTAL | 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 resources 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 de type swift (pour une meilleure scalabilité de l’offre).
| Zone | Composants | # instances | vCPU / instance | RAM / instance |
|---|---|---|---|---|
| zone-access |
|
1 | 2 | 4 Go |
| zone-external |
|
2 | 1 | 4 Go |
| zone-applicative |
|
2 | 1 | 4 Go |
| zone-applicative |
|
2 | 4 | 4 Go |
| zone-applicative |
|
3 | 4 | 4 Go |
| zone-applicative |
|
1 | 4 | 6 Go |
| zone-storage |
|
3 | 4 | 8 Go |
| zone-data |
|
3 | 4 | 6 Go |
| zone-data |
|
3 | 2 | 4 Go |
| zone-data |
|
3 | 4 | 12 Go |
| zone-admin |
|
2 | 2 | 4 Go |
| zone-admin |
|
3 | 4 | 8 Go |
| TOTAL | 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 resources allouées à la zone storage).
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.
| Zone | Composants | # instances | vCPU / instance | RAM / instance |
|---|---|---|---|---|
| zone-access |
|
1 | 2 | 4 Go |
| zone-external |
|
2 | 2 | 4 Go |
| zone-applicative |
|
2 | 2 | 4 Go |
| zone-applicative |
|
3 | 4 | 4 Go |
| zone-applicative |
|
3 | 4 | 4 Go |
| zone-applicative |
|
1 | 2 | 4 Go |
| zone-applicative |
|
10 | 4 | 6 Go |
| zone-applicative |
|
1 | 8 | 8 Go |
| zone-applicative |
|
4 | 4 | 4 Go |
| zone-storage |
|
2 | 4 | 4 Go |
| zone-storage |
|
3 | 2 | 4 Go |
| zone-storage |
|
3 | 2 | 4 Go |
| zone-data |
|
6 | 6 | 12 Go |
| zone-data |
|
3 | 4 | 8 Go |
| zone-data |
|
6 | 6 | 24 Go |
| zone-admin |
|
2 | 4 | 4 Go |
| zone-admin |
|
3 | 4 | 8 Go |
| TOTAL | vitam | 58 | 224 | 436 |
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 resources 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 le contenu décompressé des SIP en cours d’ingest ; sa taille dépend donc de la taille maximale des SIP présents en entrée et du nombre d’ingest simultanés (en attente ou en cours de traitement) ;
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_sourcequi 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 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 “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 (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 resources (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 resources disponibles pour les composants actifs lors d’un ingest : ingest-external, ingest-internal, processing, worker, workspace, storage, storage-offer, logbook, metadata, 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 : elasticsearch-data, mongodb, storage, storage-offer ;
- La quantité d’archives consultées (access) : supporter plus de requêtes concurrentes nécessite de renforcer les resources disponibles pour les composants actifs lors d’une consultation : access-external, access-internal, 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 scénarii 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é.