Dimensionnement (capacity planning)
Cette page indique la VM à prévoir (vCPU, RAM, disque) selon le nombre d'hôtes suivis par InfraRiver, comment partitionner le disque, et quoi ajouter pour l'IA locale et pour InfraRiver Collector.
Valeurs indicatives
Les chiffres ci-dessous sont des valeurs de départ, calculées à partir de l'architecture d'InfraRiver et des hypothèses du paragraphe suivant. Ils seront affinés par des mesures de charge, et cette page sera mise à jour. Prévoyez de la marge et surveillez votre installation (voir Mesurer votre installation) : une VM se redimensionne facilement, une partition pleine arrête la base.
Ce qui fait grossir une installation
Le nombre d'hôtes (serveurs physiques, VM, instances cloud) est le premier facteur, mais pas le seul : chaque hôte apporte avec lui des éléments, et c'est leur nombre qui remplit la base.
| Élément | Ordre de grandeur par hôte | Ce qui le fait varier |
|---|---|---|
| Logiciels installés | 300 à 1 500 lignes (Linux), 100 à 400 (Windows) | module software du Collector, lecture des logiciels par SUSE Manager (1 000 à 3 000 lignes par système) |
| Vulnérabilités (constats CVE) | 10 à 100 | scanner connecté (Rapid7…), âge du parc |
| Comptes et groupes locaux | 20 à 60 | Collector (Linux/Unix) |
| Ports en écoute, chemins d'administration | 20 à 100 | modules du Collector, connecteurs d'annuaire |
| Constats d'analyse (posture, AWS, Azure, AD…) | 5 à 50 | connecteurs activés |
| Historique (états successifs, journal d'audit) | proportionnel à la durée de conservation | durée de conservation |
À cela s'ajoute un socle fixe, indépendant du nombre d'hôtes : le référentiel de vulnérabilités (NVD, CISA KEV, EPSS), les dates de fin de support, les objets des annuaires (comptes et groupes AD, Entra ID) et ceux des clouds.
Hypothèses de calcul
Les tableaux de cette page supposent :
- en moyenne 800 logiciels, 30 vulnérabilités et 40 comptes par hôte ;
- 3 Mo par hôte en base (données, index et 12 mois d'historique), plus un socle de 8 Go ;
- un annuaire d'au plus 50 000 objets ;
- au plus 20 utilisateurs connectés en même temps à l'interface ;
- les connecteurs aux fréquences par défaut (voir Administration → Scheduler).
Adaptez les chiffres à votre cas : un parc surtout Windows ou sans module software sera plus léger ; un annuaire
de plusieurs centaines de milliers d'objets ou une conservation longue demandera plus de disque et de mémoire.
Serveur InfraRiver
Tout-en-un (portail, passerelle et MariaDB sur la même VM).
| Élément | Valeur |
|---|---|
| vCPU | 4 |
| RAM | 8 Go |
Mémoire MariaDB (innodb_buffer_pool_size) |
2 Go |
| Volume (LVM) | Point de montage | Contenu | Taille |
|---|---|---|---|
| — | /boot |
démarrage | 1 Go |
| vg_root | / |
système et application (/opt/infrariver) |
20 Go |
| vg_root | swap | 4 Go | |
| vg_root | /var/log |
journaux (/var/log/infrariver, MariaDB) |
10 Go |
| vg_data | /var/lib/mysql |
base de données | 20 Go |
| vg_data | /var/lib/infrariver |
état, cache, sauvegardes de la base | 25 Go |
| vg_data | (non alloué) | marge pour agrandir | 10 Go |
Tout-en-un.
| Élément | Valeur |
|---|---|
| vCPU | 4 |
| RAM | 8 Go |
Mémoire MariaDB (innodb_buffer_pool_size) |
3 Go |
| Volume (LVM) | Point de montage | Contenu | Taille |
|---|---|---|---|
| — | /boot |
démarrage | 1 Go |
| vg_root | / |
système et application | 20 Go |
| vg_root | swap | 4 Go | |
| vg_root | /var/log |
journaux | 10 Go |
| vg_data | /var/lib/mysql |
base de données | 20 Go |
| vg_data | /var/lib/infrariver |
état, cache, sauvegardes de la base | 30 Go |
| vg_data | (non alloué) | marge | 10 Go |
Tout-en-un.
| Élément | Valeur |
|---|---|
| vCPU | 4 |
| RAM | 12 Go |
Mémoire MariaDB (innodb_buffer_pool_size) |
5 Go |
| Volume (LVM) | Point de montage | Contenu | Taille |
|---|---|---|---|
| — | /boot |
démarrage | 1 Go |
| vg_root | / |
système et application | 20 Go |
| vg_root | swap | 4 Go | |
| vg_root | /var/log |
journaux | 15 Go |
| vg_data | /var/lib/mysql |
base de données | 30 Go |
| vg_data | /var/lib/infrariver |
état, cache, sauvegardes de la base | 35 Go |
| vg_data | (non alloué) | marge | 15 Go |
Tout-en-un (ou base séparée si vous préférez la mutualiser avec un cluster MariaDB existant).
| Élément | Valeur |
|---|---|
| vCPU | 6 |
| RAM | 16 Go |
Mémoire MariaDB (innodb_buffer_pool_size) |
8 Go |
| Volume (LVM) | Point de montage | Contenu | Taille |
|---|---|---|---|
| — | /boot |
démarrage | 1 Go |
| vg_root | / |
système et application | 20 Go |
| vg_root | swap | 4 Go | |
| vg_root | /var/log |
journaux | 20 Go |
| vg_data | /var/lib/mysql |
base de données | 40 Go |
| vg_data | /var/lib/infrariver |
état, cache, sauvegardes de la base | 45 Go |
| vg_data | (non alloué) | marge | 20 Go |
Base séparée recommandée.
Serveur InfraRiver (portail et passerelle)
| Élément | Valeur |
|---|---|
| vCPU | 4 |
| RAM | 8 Go |
| Disque | / 20 Go, /var/log 20 Go, /var/lib/infrariver 70 Go (dont sauvegardes) |
Serveur de base de données
| Élément | Valeur |
|---|---|
| vCPU | 6 |
| RAM | 24 Go |
Mémoire MariaDB (innodb_buffer_pool_size) |
16 Go |
/var/lib/mysql |
60 Go, sur disque rapide (SSD) |
En tout-en-un, prévoir 8 vCPU et 32 Go de RAM, et additionner les disques.
Base séparée.
Serveur InfraRiver (portail et passerelle)
| Élément | Valeur |
|---|---|
| vCPU | 6 |
| RAM | 12 Go |
| Disque | / 20 Go, /var/log 30 Go, /var/lib/infrariver 110 Go (dont sauvegardes) |
Serveur de base de données
| Élément | Valeur |
|---|---|
| vCPU | 8 |
| RAM | 48 Go |
Mémoire MariaDB (innodb_buffer_pool_size) |
32 Go |
/var/lib/mysql |
110 Go, sur disque rapide (SSD) |
Nous dimensionnons l'installation avec vous, à partir d'un échantillon de vos données (nombre d'objets de l'annuaire, connecteurs activés, durée de conservation). Écrivez-nous à contact@infrariver.com.
Pourquoi la base compte plus que les vCPU
Le portail est un processus unique : ajouter des cœurs au-delà de 6 l'accélère peu. La base profite, elle,
de chaque gigaoctet de mémoire : quand innodb_buffer_pool_size contient les données utilisées tous les jours,
les pages s'affichent sans lecture disque. Si l'interface ralentit, augmentez d'abord la mémoire de MariaDB.
Évaluation et maquette
Pour une maquette de quelques dizaines d'hôtes, 2 vCPU et 4 Go suffisent (sans IA locale), avec un disque de 40 Go.
Sauvegardes
La commande infrariver-admin backup écrit une sauvegarde compressée de la base dans
/var/lib/infrariver/backups/. Une sauvegarde compressée pèse en général 20 à 25 % de la taille de la base.
Les tailles de /var/lib/infrariver ci-dessus prévoient 7 sauvegardes quotidiennes ; adaptez-les à votre durée
de conservation, ou envoyez les sauvegardes vers votre solution de sauvegarde (voir
Sauvegarde et restauration).
IA locale
L'IA est optionnelle. Trois choix possibles :
| Choix | Ressources sur le serveur InfraRiver |
|---|---|
| Sans IA | aucune |
| IA de votre organisation (service compatible OpenAI : passerelle interne, Azure OpenAI, Mistral…) | aucune : seul un flux HTTPS sortant vers ce service |
IA locale (paquet infrariver-ai, Ollama) |
voir ci-dessous |
Le modèle livré (Ministral 8B) occupe 6 Go sur le disque et en mémoire. Par défaut, l'IA locale est
bridée pour ne jamais gêner le portail : tranche systemd infrariver-ai.slice, 2 cœurs et 8 Go au
maximum.
| Matériel | À ajouter | Ce qu'il faut attendre |
|---|---|---|
| Sans carte graphique (sur la VM InfraRiver) | + 4 vCPU, + 10 Go de RAM, + 20 Go de disque (/usr/share/ollama) |
fonctionne, mais lentement : de l'ordre de plusieurs dizaines de secondes par réponse. Convient à un usage ponctuel. |
| Carte graphique (VM ou serveur dédié) | 1 GPU avec 16 Go de mémoire vidéo au moins (24 Go conseillés : NVIDIA L4, A10, L40S…), 8 vCPU, 32 Go de RAM, 50 Go de disque | réponses de quelques secondes ; plusieurs utilisateurs en même temps. |
| Modèle plus gros (au-delà de 8B) | GPU de 48 à 80 Go de mémoire vidéo (L40S, H100) selon le modèle | à étudier avec nous |
Pour donner plus de ressources à l'IA locale, ne modifiez pas l'unité livrée : ajoutez un fichier
/etc/systemd/system/infrariver-ai.slice.d/ressources.conf, par exemple :
puis systemctl daemon-reload. Voir aussi AIRiver.
InfraRiver Collector
Le Collector peut tourner sur le serveur InfraRiver (petits parcs, une seule zone réseau) ou sur une machine dédiée par zone réseau.
| Cibles lues par un Collector | vCPU | RAM | Disque |
|---|---|---|---|
| Jusqu'à 500 | 2 | 4 Go | 20 Go |
| Jusqu'à 2 000 | 4 | 8 Go | 40 Go |
| Au-delà de 2 000 | un Collector de plus par tranche de 2 000 cibles, ou par zone réseau |
Sur le serveur InfraRiver, ajoutez ces ressources à celles du palier choisi.
Mesurer votre installation
Taille de la base, et ses dix plus grosses tables :
SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS taille_go
FROM information_schema.tables WHERE table_schema = 'infrariver';
SELECT table_name, table_rows,
ROUND((data_length + index_length) / 1024 / 1024) AS taille_mo
FROM information_schema.tables WHERE table_schema = 'infrariver'
ORDER BY data_length + index_length DESC LIMIT 10;
Espace disque et mémoire :
df -h /var/lib/mysql /var/lib/infrariver /var/log
systemctl status infrariver infrariver-ingest mariadb --no-pager | grep -E "Memory|CPU"
Quand agrandir ? Quand une partition dépasse 75 %, quand la base dépasse deux fois
innodb_buffer_pool_size, ou quand l'affichage des pages ralentit aux heures de synchronisation.