Configuration système requise
Avant une installation auto-hébergée de Bob, vérifiez que votre environnement satisfait aux exigences de plateforme, d'architecture, de calcul, de stockage et de réseau.
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 validées des composants prises en charge pour cette version de Bob auto-hébergé. Assure-toi que ton déploiement utilise des versions prises en charge de Bob IDE, Bob Shell, Premium Package et OpenShift Container Platform (OCP) pour maintenir la compatibilité et bénéficier d'une prise en charge complète du produit.
| Version Bob auto-hébergé | Version Bob IDE | Version Bob Shell | Version Premium Package |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Architecture du cluster
Le backend Bob auto-hébergé nécessite un cluster OCP amd64 (x86_64). Tous les nœuds de travail qui planifient les charges de travail Bob doivent fonctionner sur du matériel amd64.
| Architecture | Prise en charge du cluster backend |
|---|---|
amd64 (x86_64) | Pris en charge |
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 |
|---|---|
| 4.20 | Pris en charge |
| 4.21 | Pris en charge |
| 4.22 | Pris en charge |
Empreinte et dimensionnement du déploiement
Bob auto-hébergé est déployé comme une charge de travail locataire sur un cluster OpenShift Container Platform (OCP) géré par le client. Les besoins en ressources varient en fonction des composants Bob que tu déploies et ne sont pas fixes pour toutes les installations.
Chaque déploiement inclut Bob Core, qui fournit les services de plateforme fondamentaux. Les composants optionnels, tels que Z Context tool, Z Proxy et Z Understand, nécessitent des ressources de calcul, de mémoire et de stockage supplémentaires et doivent être pris en compte lors du dimensionnement du cluster.
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.
Ces chiffres représentent la somme des demandes de ressources des pods configurés pour tous les composants Bob aux nombres de réplicas spécifiés. Il s'agit de la quantité de CPU et de mémoire que le scheduler Kubernetes réserve sur les nœuds du cluster.
Ces valeurs sont destinées uniquement à la planification de capacité et au dimensionnement. Elles ne représentent pas l'utilisation réelle des ressources au moment de l'exécution et ne doivent pas être interprétées comme une consommation de ressources garantie sous charge.
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é.
Le service de modèles (inférence) n'est pas inclus. Les estimations de ressources de cette section n'incluent pas les nœuds GPU, l'infrastructure de service de modèles ou les autres ressources nécessaires pour héberger et servir les modèles IA. Si tu exécutes l'inférence de modèles via Red Hat OpenShift AI ou une plateforme de service de modèles distincte, planifie et dimensionne ces environnements indépendamment du déploiement Bob.
Configurations de pile prises en charge
Consulte la configuration qui correspond le mieux à ton déploiement prévu lors du dimensionnement de ton cluster OpenShift.
| Configuration de pile | CPU (brut) | Mémoire (brute) | Stockage (PVs) |
|---|---|---|---|
| Bob Core | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Bob Core + Z Context tool | 27,8 vCPU | 45,8 GiB | ~55 GiB |
| Bob Core + Z Understand | 18,8 vCPU | 49,8 GiB | ~24 GiB |
| Bob Core + Z Context tool + Z Understand | 35,8 vCPU | 84,8 GiB | ~55 GiB |
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.
Empreinte des ressources Bob
L'empreinte de référence suivante s'applique à un déploiement Bob Core sans add-ons optionnels activés.
Lors du dimensionnement des nœuds de travail, utilise les valeurs de la ligne +25 % de marge de planification. Ces valeurs fournissent une capacité supplémentaire au-delà des demandes de ressources des pods configurés pour tenir compte des exigences de planification Kubernetes et de la surcharge au niveau des nœuds.
| Profil de déploiement | CPU | Mémoire | Stockage (PVs) |
|---|---|---|---|
| Production (ressources demandées) | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Production (incluant 25 % de marge de planification) | ~13,5 vCPU | ~13,5 GiB | ~24 GiB |
La consommation de stockage varie en fonction du volume de charge de travail, des données conservées et des services activés. Les valeurs indiquées représentent l'empreinte de base pour un déploiement Bob Core.
Topologie du cluster OpenShift
Le tableau suivant présente une configuration de référence minimale prête pour la production pour un cluster OpenShift à neuf nœuds exécutant un déploiement Bob Core. Si tu déploies des composants Bob supplémentaires, tu dois provisionner une capacité de nœuds de travail supplémentaire.
Configuration de référence minimale
| Rôle du nœud | Nombre | CPU par nœud | Mémoire par nœud | Capacité agrégée |
|---|---|---|---|---|
| Plan de contrôle | 3 | 4 vCPU (minimum) | 16 GiB (minimum) | 12 vCPU / 48 GiB |
| Nœuds d'infrastructure | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Nœuds de travail | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB de stockage |
| Total du cluster | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB de stockage |
Après prise en compte de la surcharge du cluster OpenShift et des ressources réservées au système, la configuration à trois nœuds de travail fournit une capacité CPU et mémoire allouable suffisante pour prendre en charge le déploiement de production Bob Core.
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 |
|---|---|---|
| NFS géré | Provisionnement NFS (Network File System) | RWO, RWX |
| OpenShift Data Foundation (ODF) | Stockage Ceph (RBD et CephFS) | RWO, RWX |
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 auto-hébergé.
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.