Systemanforderungen
Stelle vor einer On-Premises-Installation von Bob sicher, dass deine Umgebung die unterstützten Plattform-, Architektur-, Compute-, Storage- und Netzwerkanforderungen erfüllt.
Vorläufige Größenbemessungswerte für Z-Understand-Add-on-Konfigurationen sind jetzt veröffentlicht. Diese Werte basieren auf laufenden Benchmark-Tests und können aktualisiert werden, wenn die Tests abgeschlossen sind.
Die Anforderungen in diesem Abschnitt helfen dir, deine OpenShift-Umgebung entsprechend zu planen und zu dimensionieren.
Unterstützte Versionen
Die folgende Tabelle listet die Bob-On-Premises-Versionen und die kompatiblen Client-Komponentenversionen auf.
| Bob-On-Premises-Version | Bob-IDE-Version | Bob-Shell-Version |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
Informationen zur Versionskompatibilität von Premium-Paket-Add-ons findest du unter Berechtigungsverwaltung.
Cluster-Architektur
Eine On-Premises-Installation von Bob auf OpenShift Container Platform (OCP) unterstützt derzeit die folgende Cluster-Architektur:
amd64(x86_64)
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 | Hinweise |
|---|---|---|
| 4.20 | Getestet und unterstützt | Mindestens unterstützte Version |
| 4.21 | Getestet und unterstützt | |
| 4.22 | Getestet und unterstützt |
Cluster-Dimensionierung
Bob läuft als Tenant-Workload auf einem kundenverwalteten OpenShift-Cluster. Der Ressourcenbedarf variiert je nach deploytem Bob-Stack. Jede Installation enthält die Bob-Core-Komponenten, während optionale Premium-Paket-Add-ons den erforderlichen CPU-, Memory- und Storage-Bedarf erhöhen.
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.
Cluster-Dimensionierungsentscheidungen wie die Anzahl der Control-Plane-Nodes, Infrastruktur-Nodes, Worker-Nodes, Hochverfügbarkeitsanforderungen und Wachstumsplanung bleiben deine Verantwortung.
Unterstützte Stack-Konfigurationen
Bob unterstützt mehrere Deployment-Konfigurationen. Der gesamte Ressourcen-Footprint hängt von den aktivierten Add-ons ab.
| Stack-Konfiguration | CPU (roh) | Memory (roh) | Storage (PVs) | Status |
|---|---|---|---|---|
| Bob Core | 38,1 vCPU | 42,1 GiB | ~50 GiB | Basis verfügbar |
| Bob Core + RAG | 38,1 vCPU | 69,1 GiB | ~62 GiB | Basis verfügbar |
| Bob Core + Z Understand | 30,1 vCPU | 79,1 GiB | ~2288 GiB | Benchmarking läuft |
| Bob Core + RAG + Z Understand | 46,1 vCPU | 113,1 GiB | ~2320 GiB | Benchmarking läuft |
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. Die Ressourcenanforderungen der Add-ons werden nach Abschluss der Leistungstests veröffentlicht.
Bob-Ressourcen-Footprint
Der folgende Referenz-Footprint gilt für ein Bob-Core-Deployment ohne aktivierte optionale Add-ons.
| Deployment-Profil | CPU | Memory | Storage (PVs) |
|---|---|---|---|
| Evaluierung (roh) | 16,8 vCPU | 20,8 GiB | ~9 GiB |
| Evaluierung (+25–30 % Headroom) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Produktion (roh) | 28,1 vCPU | 41,1 GiB | ~50 GiB |
| Produktion (+25–30 % Headroom) | ~36,5 vCPU | ~53,4 GiB | ~50 GiB |
Die empfohlenen Werte enthalten Scheduling-Headroom, um Plattform-Overhead, Workload-Schwankungen, Upgrades und zukünftiges Wachstum zu berücksichtigen. Verwende die headroom-angepassten Werte bei der Dimensionierung der Worker-Node-Kapazität.
Single-Node-OpenShift-(SNO-)Cluster
Single-Node-OpenShift kombiniert Control-Plane- und Worker-Workloads auf einem einzigen Host. SNO-Deployments eignen sich für Proof-of-Concept-, Entwicklungs-, Test- und Edge-Umgebungen, in denen keine Hochverfügbarkeit erforderlich ist.
Referenz-Dimensionierung
| Schicht | CPU | Memory | Storage |
|---|---|---|---|
| OpenShift-Plattform-Minimum | 8 vCPU | 16 GiB | 120 GiB |
| Bob-Evaluierungs-Workload (mit Headroom) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Node-Gesamtreferenz | ~29 vCPU | ~42 GiB | ~130 GiB |
- Single-Node-OpenShift bietet keine Node-Redundanz.
- Control-Plane- und Anwendungs-Workloads teilen denselben Host.
- Ein Node-Ausfall führt zu vollständiger Serviceunterbrechung.
- SNO wird nicht für Produktionsumgebungen empfohlen, die Verfügbarkeit oder Disaster-Recovery-Funktionen erfordern.
Installationsanleitungen findest du unter How to install single node OpenShift on bare metal (mindestens 8 vCPU / 16 GiB RAM / 120 GiB Storage) und Preparing to install on a single node, OCP 4.20.
Multi-Node-OpenShift-Cluster
Die folgende Architektur stellt eine minimale Referenz-Deployment für Bob dar, das in einem dedizierten Cluster ausgeführt wird.
Minimale Referenzkonfiguration
| Node-Rolle | Anzahl | CPU pro Node | Memory pro Node | Aggregierte Ressourcen |
|---|---|---|---|---|
| Control Plane | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infrastruktur | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Worker | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB Storage |
| Cluster gesamt | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
Nach Berücksichtigung des OpenShift-Overheads bietet der Worker-Node-Pool ungefähr:
- 57 vCPU zuweisbare Kapazität
- 63 GiB zuweisbaren Memory
Diese Kapazität reicht aus, um den Bob-Core-Produktions-Footprint einschließlich des empfohlenen Scheduling-Headrooms zu unterstützen:
| Anforderung | CPU | Memory |
|---|---|---|
| Bob-Core-Produktionsanforderung | ~36,5 vCPU | ~53,4 GiB |
| Zuweisbare Worker-Pool-Kapazität | ~57 vCPU | ~63 GiB |
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 | Status |
|---|---|---|---|
| Managed NFS | Network File System (NFS) Provisioner | RWO, RWX | Unterstützt |
| OpenShift Data Foundation (ODF) | Ceph-basierter Storage (RBD und CephFS) | RWO, RWX | Unterstützt |
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 On-Premises.
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.