Configuration système requise
Avant une installation on-premises de Bob, vérifiez que votre environnement satisfait aux exigences de plateforme, d'architecture, de calcul, de stockage et de réseau.
Les valeurs dimensionnelles provisoires pour les configurations d'add-ons Z Understand sont désormais publiées. Ces valeurs sont basées sur des tests de benchmark en cours et peuvent être mises à jour à mesure que les tests sont finalisés.
Les exigences de cette section vous aident à planifier et à dimensionner votre environnement OpenShift de manière appropriée.
Versions prises en charge
Le tableau suivant répertorie les versions Bob on-premises et les versions compatibles des composants clients.
| Version Bob on-premises | Version Bob IDE | Version Bob Shell |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
Pour la compatibilité des versions des add-ons Premium Package, voir Gestion des droits.
Architecture du cluster
Une installation on-premises de Bob sur OpenShift Container Platform (OCP) prend actuellement en charge l'architecture de cluster suivante :
amd64(x86_64)
Les clusters à architecture mixte sont pris en charge lorsque les charges de travail Bob sont restreintes aux nœuds amd64 à l'aide de sélecteurs de nœuds ou de taints. Bob n'applique pas ces contraintes de planification automatiquement.
Versions OCP prises en charge
Le tableau suivant répertorie les versions OCP prises en charge.
| Version OCP | Statut | Remarques |
|---|---|---|
| 4.20 | Testé et pris en charge | Version minimale prise en charge |
| 4.21 | Testé et pris en charge | |
| 4.22 | Testé et pris en charge |
Dimensionnement du cluster
Bob s'exécute comme une charge de travail locataire sur un cluster OpenShift géré par le client. Les besoins en ressources varient en fonction de la pile Bob déployée. Chaque installation inclut les composants Bob Core, tandis que les add-ons Premium Package optionnels augmentent la capacité CPU, mémoire et stockage requise.
Les add-ons sont activés lors de l'installation par l'administrateur du cluster. L'activation d'un add-on augmente non seulement les besoins en ressources du cluster, mais détermine également si le droit au package premium correspondant peut être attribué aux utilisateurs. Pour plus d'informations, voir Gestion des droits.
Les valeurs de dimensionnement de cette section représentent les ressources agrégées requises par les charges de travail Bob. Elles sont fournies pour aider à estimer l'empreinte du locataire et ne sont pas destinées à définir l'architecture globale du cluster. Vous devez dimensionner le cluster sous-jacent en fonction de vos exigences opérationnelles, notamment la haute disponibilité, les autres charges de travail des locataires, la croissance prévue et la surcharge des services de la plateforme.
Les décisions de dimensionnement du cluster, telles que le nombre de nœuds du plan de contrôle, les nœuds d'infrastructure, les nœuds de travail, les exigences de haute disponibilité et la planification de la croissance, restent de votre responsabilité.
Configurations de pile prises en charge
Bob prend en charge plusieurs configurations de déploiement. L'empreinte totale des ressources dépend des add-ons activés.
| Configuration de pile | CPU (brut) | Mémoire (brute) | Stockage (PVs) | Statut |
|---|---|---|---|---|
| Bob Core | 38,1 vCPU | 42,1 GiB | ~50 GiB | Référence disponible |
| Bob Core + RAG | 38,1 vCPU | 69,1 GiB | ~62 GiB | Référence disponible |
| Bob Core + Z Understand | 30,1 vCPU | 79,1 GiB | ~2288 GiB | Benchmark en cours |
| Bob Core + RAG + Z Understand | 46,1 vCPU | 113,1 GiB | ~2320 GiB | Benchmark en cours |
Bob Core représente la configuration de déploiement minimale prise en charge. Les valeurs de ressources représentent les exigences agrégées du locataire Bob et excluent la surcharge de l'infrastructure de la plateforme. Les exigences en ressources des add-ons seront publiées à la fin des tests de performance.
Empreinte des ressources Bob
L'empreinte de référence suivante s'applique à un déploiement Bob Core sans add-ons optionnels activés.
| Profil de déploiement | CPU | Mémoire | Stockage (PVs) |
|---|---|---|---|
| Évaluation (brut) | 16,8 vCPU | 20,8 GiB | ~9 GiB |
| Évaluation (+25–30 % de marge) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Production (brut) | 28,1 vCPU | 41,1 GiB | ~50 GiB |
| Production (+25–30 % de marge) | ~36,5 vCPU | ~53,4 GiB | ~50 GiB |
Les valeurs recommandées incluent une marge de planification pour tenir compte de la surcharge de la plateforme, des fluctuations de charge de travail, des mises à niveau et de la croissance future. Utilisez les valeurs ajustées avec marge lors du dimensionnement de la capacité des nœuds de travail.
Cluster OpenShift à nœud unique (SNO)
OpenShift à nœud unique combine le plan de contrôle et les charges de travail sur un seul hôte. Les déploiements SNO conviennent aux environnements de preuve de concept, de développement, de test et edge où la haute disponibilité n'est pas requise.
Dimensionnement de référence
| Couche | CPU | Mémoire | Stockage |
|---|---|---|---|
| Minimum de la plateforme OpenShift | 8 vCPU | 16 GiB | 120 GiB |
| Charge de travail d'évaluation Bob (avec marge) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Total de référence du nœud | ~29 vCPU | ~42 GiB | ~130 GiB |
- OpenShift à nœud unique ne fournit pas de redondance de nœud.
- Le plan de contrôle et les charges de travail applicatives partagent le même hôte.
- Une défaillance de nœud entraîne une indisponibilité totale du service.
- SNO n'est pas recommandé pour les environnements de production nécessitant des capacités de disponibilité ou de reprise après sinistre.
Pour des conseils d'installation, consultez How to install single node OpenShift on bare metal (minimum 8 vCPU / 16 GiB RAM / 120 GiB de stockage) et Preparing to install on a single node, OCP 4.20.
Cluster OpenShift multi-nœuds
L'architecture suivante représente un déploiement de référence minimal pour Bob s'exécutant dans un cluster dédié.
Configuration de référence minimale
| Rôle du nœud | Nombre | CPU par nœud | Mémoire par nœud | Ressources agrégées |
|---|---|---|---|---|
| Plan de contrôle | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infrastructure | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Travail | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB de stockage |
| Total du cluster | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
Après prise en compte de la surcharge OpenShift, le pool de nœuds de travail fournit approximativement :
- 57 vCPU de capacité allouable
- 63 GiB de mémoire allouable
Cette capacité est suffisante pour prendre en charge l'empreinte de production Bob Core, incluant la marge de planification recommandée :
| Exigence | CPU | Mémoire |
|---|---|---|
| Exigence de production Bob Core | ~36,5 vCPU | ~53,4 GiB |
| Capacité allouable du pool de travail | ~57 vCPU | ~63 GiB |
Pour référence, consultez OpenShift Control Plane Sizing Guidelines, Control plane node sizing (maintenir l'utilisation à 60 % ou en dessous pour la marge HA et de mise à niveau), et Recommended host practices, Scalability and Performance (3 nœuds infra recommandés).
Exigences de stockage
Bob s'appuie sur un stockage persistant pour les bases de données, les services de recherche, les composants de cache, la configuration, les certificats et les données de sauvegarde. Le choix de la classe de stockage appropriée est important pour les performances et la fiabilité.
La configuration de référence alloue 200 GiB de stockage par nœud de travail, soit un total de 600 GiB sur le pool de travail. Cela prend en charge les exigences en volumes persistants de Bob (~50 GiB), les services internes OpenShift tels que le registre d'images, la surveillance et la journalisation, ainsi que la capacité de croissance future des charges de travail.
Classes de stockage prises en charge
| Classe de stockage | Type | Modes d'accès pris en charge | Statut |
|---|---|---|---|
| NFS géré | Provisionnement NFS (Network File System) | RWO, RWX | Pris en charge |
| OpenShift Data Foundation (ODF) | Stockage Ceph (RBD et CephFS) | RWO, RWX | Pris en charge |
Exigences de mode d'accès au stockage
Les différents composants Bob nécessitent différents modes d'accès au stockage.
| Composant | Mode d'accès requis | Remarques |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | Le stockage en bloc est requis. Le stockage SSD est fortement recommandé. |
| OpenSearch | RWO (ReadWriteOnce) | Le stockage en bloc haute performance est recommandé. |
| Redis | RWO (ReadWriteOnce) | Les données persistantes nécessitent un accès en lecture-écriture dédié. |
| Configuration partagée et certificats | RWX (ReadWriteMany) | Requis lorsque plusieurs pods doivent monter le même volume simultanément. |
Les performances de stockage ont un impact significatif sur la réactivité et la stabilité de Bob on-premises.
Un débit de stockage ou des performances d'E/S insuffisants, notamment pour les charges de travail PostgreSQL, peuvent entraîner des temps de réponse accrus, des opérations d'indexation plus lentes et une dégradation des performances globales du système. Lors de la sélection du stockage pour les charges de travail de base de données :
- Utilisez un stockage en bloc SSD dans la mesure du possible.
- Évitez les plateformes de stockage à latence élevée ou à IOPS limité.
- Assurez-vous d'une capacité suffisante pour la croissance prévue de la charge de travail.
- Validez les performances de stockage avant de déployer des charges de travail en production.
Pour des performances optimales, déployez les volumes de données PostgreSQL et OpenSearch sur le stockage en bloc le plus rapide disponible dans l'environnement.
Stockage de sauvegarde
Bob nécessite une cible de stockage distincte pour les opérations de sauvegarde et de restauration. L'emplacement de stockage de sauvegarde doit fournir une capacité suffisante pour stocker :
- Les sauvegardes d'application
- Les sauvegardes de bases de données
- Les snapshots d'index
- Les copies de rétention requises par les politiques organisationnelles
Le stockage de sauvegarde peut être fourni par des systèmes de stockage externes pris en charge, tels que :
- Des partages NFS (Network File System)
- Des référentiels de sauvegarde d'entreprise
- Des services de stockage objet (si pris en charge par la solution de sauvegarde)
Exigences réseau
Les composants Bob communiquent en interne au sein du cluster OpenShift et en externe avec les endpoints de modèles, les registres de conteneurs, les fournisseurs LDAP et les postes de travail client. Avant l'installation, vérifiez que la connectivité réseau et la configuration DNS requises sont disponibles.
Au minimum, assurez-vous que :
- Les nœuds OpenShift peuvent communiquer entre eux.
- Votre poste de travail peut accéder à l'API OpenShift.
- Bob peut atteindre les endpoints LLM configurés.
- Bob peut atteindre les serveurs LDAP ou Active Directory, si utilisés.
- Les postes de travail client peuvent accéder à l'endpoint d'entrée Bob.
- Les enregistrements DNS sont configurés pour l'endpoint de l'application Bob.
- Les certificats TLS peuvent être validés depuis les postes de travail client.