Systemanforderungen
Stelle vor einer Self-Hosted-Installation von Bob sicher, dass deine Umgebung die unterstützten Plattform-, Architektur-, Compute-, Storage- und Netzwerkanforderungen erfüllt.
Die Anforderungen in diesem Abschnitt helfen dir, deine OpenShift-Umgebung entsprechend zu planen und zu dimensionieren.
Unterstützte Versionen
Die folgende Tabelle listet die validierten Komponentenversionen auf, die für dieses Release von Bob Self-Hosted unterstützt werden. Stelle sicher, dass dein Deployment unterstützte Versionen von Bob IDE, Bob Shell, Premium Package und OpenShift Container Platform (OCP) verwendet, um Kompatibilität zu gewährleisten und vollständigen Produkt-Support zu erhalten.
| Bob-Self-Hosted-Version | Bob-IDE-Version | Bob-Shell-Version | Premium-Package-Version |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Cluster-Architektur
Der Bob-Self-Hosted-Backend erfordert einen amd64 (x86_64) OCP-Cluster. Alle Worker-Nodes, auf denen Bob-Workloads ausgeführt werden, müssen auf amd64-Hardware laufen.
| Architektur | Backend-Cluster-Unterstützung |
|---|---|
amd64 (x86_64) | Unterstützt |
Gemischte Architektur-Cluster werden unterstützt, wenn Bob-Workloads durch Node-Selektoren oder Taints auf amd64-Nodes beschränkt werden. Bob wendet diese Scheduling-Einschränkungen nicht automatisch an.
Unterstützte OCP-Versionen
Die folgende Tabelle listet die unterstützten OCP-Versionen auf.
| OCP-Version | Status |
|---|---|
| 4.20 | Unterstützt |
| 4.21 | Unterstützt |
| 4.22 | Unterstützt |
Deployment-Footprint und Dimensionierung
Bob Self-Hosted wird als Tenant-Workload auf einem kundenverwalteten OpenShift Container Platform (OCP)-Cluster deployed. Der Ressourcenbedarf variiert je nach den deployten Bob-Komponenten und ist nicht für alle Installationen festgelegt.
Jedes Deployment enthält Bob Core, das die grundlegenden Plattformdienste bereitstellt. Optionale Komponenten wie Z Context tool, Z Proxy und Z Understand erfordern zusätzliche Compute-, Memory- und Storage-Ressourcen und müssen bei der Cluster-Dimensionierung berücksichtigt werden.
Add-ons werden während der Installation vom Cluster-Administrator aktiviert. Das Aktivieren eines Add-ons erhöht nicht nur den Cluster-Ressourcenbedarf, sondern bestimmt auch, ob die entsprechende Premium-Paket-Berechtigung Benutzern zugewiesen werden kann. Weitere Informationen findest du unter Berechtigungsverwaltung.
Die Dimensionierungswerte in diesem Abschnitt stellen die aggregierten Ressourcen dar, die von Bob-Workloads benötigt werden. Sie sollen bei der Schätzung des Tenant-Footprints helfen und sind nicht dazu gedacht, die gesamte Cluster-Architektur zu definieren. Du musst den zugrunde liegenden Cluster basierend auf deinen betrieblichen Anforderungen dimensionieren, einschließlich Hochverfügbarkeit, anderer Tenant-Workloads, erwartetem Wachstum und Plattform-Service-Overhead.
Diese Werte stellen die Summe der konfigurierten Pod-Ressourcenanforderungen über alle Bob-Komponenten bei den angegebenen Replikatanzahlen dar. Dies ist die Menge an CPU und Memory, die der Kubernetes-Scheduler auf Cluster-Nodes reserviert.
Diese Werte dienen ausschließlich der Kapazitätsplanung und Dimensionierung. Sie stellen nicht die beobachtete Laufzeit-Ressourcennutzung dar und sollten nicht als garantierter Ressourcenverbrauch unter Last interpretiert werden.
Cluster-Dimensionierungsentscheidungen wie die Anzahl der Control-Plane-Nodes, Infrastruktur-Nodes, Worker-Nodes, Hochverfügbarkeitsanforderungen und Wachstumsplanung bleiben deine Verantwortung.
Model Serving (Inferenz) ist nicht enthalten. Die Ressourcenschätzungen in diesem Abschnitt schließen GPU-Nodes, Modell-Serving-Infrastruktur oder andere Ressourcen, die zum Hosten und Bereitstellen von KI-Modellen erforderlich sind, nicht ein. Wenn du Modell-Inferenz mit Red Hat OpenShift AI oder einer separaten Modell-Serving-Plattform betreibst, plane und dimensioniere diese Umgebungen unabhängig vom Bob-Deployment.
Unterstützte Stack-Konfigurationen
Überprüfe die Konfiguration, die deinem geplanten Deployment am nächsten kommt, wenn du deinen OpenShift-Cluster dimensionierst.
| Stack-Konfiguration | CPU (roh) | Memory (roh) | Storage (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 stellt die minimal unterstützte Deployment-Konfiguration dar. Ressourcenwerte repräsentieren den aggregierten Bob-Tenant-Bedarf und schließen den Overhead der Plattforminfrastruktur aus.
Bob-Ressourcen-Footprint
Der folgende Referenz-Footprint gilt für ein Bob-Core-Deployment ohne aktivierte optionale Add-ons.
Verwende bei der Dimensionierung der Worker-Nodes die Werte in der Zeile +25 % Scheduling-Headroom. Diese Werte bieten zusätzliche Kapazität über die konfigurierten Pod-Ressourcenanforderungen hinaus, um Kubernetes-Scheduling-Anforderungen und Node-Level-Overhead zu berücksichtigen.
| Deployment-Profil | CPU | Memory | Storage (PVs) |
|---|---|---|---|
| Produktion (angeforderte Ressourcen) | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Produktion (inkl. 25 % Scheduling-Headroom) | ~13,5 vCPU | ~13,5 GiB | ~24 GiB |
Der Storage-Verbrauch variiert je nach Workload-Volumen, aufbewahrten Daten und aktivierten Diensten. Die angezeigten Werte stellen den Basis-Footprint für ein Bob-Core-Deployment dar.
OpenShift-Cluster-Topologie
Die folgende Tabelle zeigt eine minimale produktionsfähige Referenzkonfiguration für einen Neun-Node-OpenShift-Cluster mit einem Bob-Core-Deployment. Wenn du zusätzliche Bob-Komponenten deployest, musst du zusätzliche Worker-Node-Kapazität bereitstellen.
Minimale Referenzkonfiguration
| Node-Rolle | Anzahl | CPU pro Node | Memory pro Node | Aggregierte Kapazität |
|---|---|---|---|---|
| Control Plane | 3 | 4 vCPU (Minimum) | 16 GiB (Minimum) | 12 vCPU / 48 GiB |
| Infrastruktur-Nodes | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Worker-Nodes | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB Storage |
| Cluster gesamt | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB Storage |
Nach Berücksichtigung des OpenShift-Cluster-Overheads und systemreservierter Ressourcen bietet die Drei-Worker-Node-Konfiguration ausreichende zuweisbare CPU- und Memory-Kapazität, um das Bob-Core-Produktions-Deployment zu unterstützen.
Referenzen: OpenShift Control Plane Sizing Guidelines, Control plane node sizing (Auslastung bei 60 % oder darunter für HA und Upgrade-Headroom) und Recommended host practices, Scalability and Performance (3 Infrastruktur-Nodes empfohlen).
Storage-Anforderungen
Bob benötigt persistenten Storage für Datenbanken, Suchdienste, Cache-Komponenten, Konfiguration, Zertifikate und Backup-Daten. Die Auswahl der geeigneten Storage-Klasse ist wichtig für Leistung und Zuverlässigkeit.
Die Referenzkonfiguration weist 200 GiB Storage pro Worker-Node zu, insgesamt 600 GiB im Worker-Pool. Dies deckt die Bob-Persistent-Volume-Anforderungen (~50 GiB), interne OpenShift-Dienste wie Image-Registry, Monitoring und Logging sowie Kapazität für zukünftiges Workload-Wachstum ab.
Unterstützte Storage-Klassen
| Storage-Klasse | Typ | Unterstützte Zugriffsmodi |
|---|---|---|
| Managed NFS | Network File System (NFS) Provisioner | RWO, RWX |
| OpenShift Data Foundation (ODF) | Ceph-basierter Storage (RBD und CephFS) | RWO, RWX |
Anforderungen an den Storage-Zugriffsmodus
Verschiedene Bob-Komponenten erfordern unterschiedliche Storage-Zugriffsmodi.
| Komponente | Erforderlicher Zugriffsmodus | Hinweise |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | Block-Storage ist erforderlich. SSD-basierter Storage wird dringend empfohlen. |
| OpenSearch | RWO (ReadWriteOnce) | Hochleistungs-Block-Storage wird empfohlen. |
| Redis | RWO (ReadWriteOnce) | Persistente Daten erfordern dedizierten Lese-/Schreibzugriff. |
| Gemeinsame Konfiguration und Zertifikate | RWX (ReadWriteMany) | Erforderlich, wenn mehrere Pods dasselbe Volume gleichzeitig einbinden müssen. |
Die Storage-Leistung hat einen erheblichen Einfluss auf die Reaktionsfähigkeit und Stabilität von Bob Self-Hosted.
Unzureichender Storage-Durchsatz oder unzureichende I/O-Leistung, insbesondere bei PostgreSQL-Workloads, kann zu erhöhten Antwortzeiten, langsameren Indexierungsoperationen und allgemein schlechterer Systemleistung führen. Bei der Auswahl von Storage für Datenbank-Workloads:
- Verwende nach Möglichkeit SSD-basierten Block-Storage.
- Vermeide Storage-Plattformen mit hoher Latenz oder begrenztem IOPS.
- Stelle ausreichend Kapazität für das erwartete Workload-Wachstum sicher.
- Validiere die Storage-Leistung vor dem Deployment von Produktions-Workloads.
Für optimale Leistung deploye PostgreSQL- und OpenSearch-Daten-Volumes auf dem schnellsten verfügbaren Block-Storage in der Umgebung.
Backup-Storage
Bob benötigt ein separates Storage-Ziel für Backup- und Restore-Operationen. Der Backup-Storage-Speicherort muss ausreichend Kapazität bieten, um Folgendes zu speichern:
- Anwendungs-Backups
- Datenbank-Backups
- Index-Snapshots
- Aufbewahrungskopien gemäß den Organisationsrichtlinien
Backup-Storage kann durch unterstützte externe Storage-Systeme bereitgestellt werden, wie z. B.:
- Network File System (NFS) Shares
- Enterprise-Backup-Repositories
- Object-Storage-Dienste (sofern von der Backup-Lösung unterstützt)
Netzwerkanforderungen
Bob-Komponenten kommunizieren intern innerhalb des OpenShift-Clusters und extern mit Model-Endpoints, Container-Registries, LDAP-Providern und Client-Workstations. Überprüfe vor der Installation, ob die erforderliche Netzwerkkonnektivität und DNS-Konfiguration vorhanden sind.
Stelle mindestens sicher, dass:
- OpenShift-Nodes miteinander kommunizieren können.
- Deine Workstation auf die OpenShift-API zugreifen kann.
- Bob die konfigurierten LLM-Endpoints erreichen kann.
- Bob LDAP- oder Active-Directory-Server erreichen kann, falls verwendet.
- Client-Workstations auf den Bob-Ingress-Endpoint zugreifen können.
- DNS-Einträge für den Bob-Anwendungs-Endpoint konfiguriert sind.
- TLS-Zertifikate von Client-Workstations validiert werden können.