Eléments de dimensionnement ########################### .. caution:: 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 :term:`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 :term:`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é). .. caution:: Réaliser un benchmarking sur un environnement de test de charge (avec des jeux de données et une infrastructure similaires à celle de production) est fortement recommandé pour valider le bon dimensionnement de la plateforme. .. note:: Sauf mention contraire, les enveloppes de ressources ci-dessous comprennent notamment les composants associés à l'exploitation de la solution logicielle :term:`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. :term:`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. .. Important:: Un monitoring régulier de la plateforme (via prometheus par exemple) est nécessaire. En plus de permettre la vérification du bon fonctionnement de la solution, il permet également de valider son dimensionnement, et de le réadapter si besoin. .. Important:: Les composants ``workspace`` et ``processing`` sont mono-instantiables uniquement. De même, pour les composants ``storage-offer`` de type "Système de fichier" ou "Bandes magnétiques" (offre froide), une seule instance peut être déployée par offre. Les composants ``storage-offer`` de type "S3" ou "Swift" sont multi-instantiables. Compute ======= "xsmall" : développement local ------------------------------ Adapté à un poste de développement ; ce déploiement ne comprend pas les composants d'exploitation de la solution :term:`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. .. csv-table:: Dimensionnement XSmall :header-rows: 1 :file: data/sizing-XS.csv :delim: , .. 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 :term:`OOM`. .. seealso:: Se reporter au :term:`DIN` pour plus d'informations. "small" : recette simple métier ------------------------------- Adapté à un environnement de recette simple d'application métier utilisant :term:`VITAM`. Ce déploiement n'est pas adapté pour un fonctionnement en production. .. csv-table:: Dimensionnement Small :header-rows: 1 :file: data/sizing-S.csv :delim: , 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 :term:`OOM`. .. seealso:: Se reporter au :term:`DIN` pour plus d'informations. "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). .. csv-table:: Dimensionnement Medium :header-rows: 1 :file: data/sizing-M.csv :delim: , 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). "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). .. csv-table:: Dimensionnement Large :header-rows: 1 :file: data/sizing-L.csv :delim: , 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``. "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. .. csv-table:: Dimensionnement XLarge :header-rows: 1 :file: data/sizing-XL.csv :delim: , 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). 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 :term:`SIP` en cours d'analyse antivirus avant leur dépôt dans workspace ; sa taille dépend donc de la taille maximale des :term:`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 :term:`SIP` en cours d'ingest, des objets binaires en cours de préservation, ainsi que les exports de données :term:`DIP` en cours...) ; sa taille dépend donc de la taille maximale des :term:`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 :term:`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 (:term:`GOT` et :term:`AU`) ainsi que les journaux d'opération. Pour ces éléments : - La taille et la quantité des :term:`AU` et des :term:`GOT` dépend des données entrées dans :term:`VITAM` (facteur métier) ; - Le nombre d'opérations dépend de l'usage du système (et notamment de la granularité des :term:`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 (:term:`GOT`, :term:`AU` et :term:`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 :term:`LFC` associés à une :term:`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 :term:`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 (:term:`AU` & :term:`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 : :term:`AU`, :term:`GOT`, :term:`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). * Espace de stockage du composant ``storage-offer`` pour le stockage pérenne des données conservées dans :term:`VITAM`, qui comprend notamment : - les :term:`AU`, :term:`GOT` et :term:`BDO` ; - les journaux d'opération, de cycle de vie, d'écritures et d'accès ; - les autres données techniques persistées par Vitam (sécurisations des journaux, ATRs, rapports d'opérations...) Cette capacité doit être allouée selon le type de l'offre de cible : - Système de fichiers : Répertoire "data" du composant ``storage-offer`` ; - Object store S3 ou Swift : Capacité de stockage dans l'object store "S3" ou "Swift" cible ; - Archivage sur bandes magnétiques : Capacité de stockage sur bibliothèque de bandes * 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 (:term:`AU`, :term:`GOT`, :term:`BDO`) entré dans le système. .. note:: Pour le stockage sur bandes magnétiques (offre froide), il est à noter que : * L'offre froide de Vitam ne supporte actuellement PAS l'élimination physique des données (seule une élimination logique est réalisée). De ce fait, la capacité de stockage allouée sur bandes & cache disque doit contenir **toutes les versions des données écrites** (écritures + MAJ), et sur la **totalité de la durée de vie** de la solution déployée. * En plus du stockage sur bande, le répertoire "data" du composant ``storage-offer`` est également utilisé : - Comme espace "tampon" pour le stockage temporaire des objets à archiver. Il doit disposer de suffisamment d'espace pour contenir les données en cours d'archivage à l'instant T, le temps qu'elles soient écrites sur bande sur bande. - Comme espace "cache" pour le stockage des données à lire. Il doit disposer suffisamment d'espace pour contenir sur la **durée de vie** de la solution déployée : + l'ensemble des métadonnées et leur journaux de cycle de vie (environs 10 Ko par :term:`AU` ou :term:`GOT`, pour chaque version écrite) + l'ensemble des données techniques (journaux de sécurisation, ATRs, rapports...) + suffisamment d'espace pour la mise à disposition des binaires en cours de lecture (binaires en cours d'export de données DIP ou de transfert, en cours de préservation...) Pour une plateforme large de production, prévoir *à minima* 10 To de stockage disque pour le répertoire "data" du composant ``storage-offer``. Réseau : inter-site =================== Un lien réseau :term:`IP` doit exister entre les deux sites et respecter les flux décrits dans la matrice de flux externes (se reporter à :doc:`90-flux-all`). 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 :term:`IP` :term:`WAN` visible depuis le site 1 différente de son adresse :term:`IP` :term:`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 :term:`VITAM`, ce dernier peut se calculer à partir de la somme des débits d'ingest des :term:`AU` + :term:`GOT` + :term:`BDO` + journaux. Scalabilité =========== De manière générale, la consommation en ressources (CPU/RAM/réseau/stockage) de :term:`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 :term:`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.