Requisiti di sistema
Prima di un'installazione on-premises di Bob, verifica che il tuo ambiente soddisfi i requisiti supportati di piattaforma, architettura, calcolo, storage e rete.
I requisiti in questa sezione ti aiutano a pianificare e dimensionare correttamente il tuo ambiente OpenShift.
Versioni supportate
La seguente tabella elenca le versioni dei componenti convalidate e supportate per questa release di Bob self-hosted. Assicurati che il tuo deployment utilizzi versioni supportate di Bob IDE, Bob Shell, Premium Package e OpenShift Container Platform (OCP) per mantenere la compatibilità e ricevere il supporto completo del prodotto.
| Versione Bob on-premises | Versione Bob IDE | Versione Bob Shell | Versione Premium Package |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Architettura del cluster
Il backend on-premises di Bob richiede un cluster OCP amd64 (x86_64). Tutti i nodi worker che schedulano i workload Bob devono essere su hardware amd64.
| Architettura | Supporto cluster backend |
|---|---|
amd64 (x86_64) | Supportata |
I cluster ad architettura mista sono supportati quando i workload Bob sono limitati ai nodi amd64 tramite node selector o taint. Bob non applica automaticamente questi vincoli di scheduling.
Versioni OCP supportate
La tabella seguente elenca le versioni OCP supportate.
| Versione OCP | Stato |
|---|---|
| 4.20 | Supportata |
| 4.21 | Supportata |
| 4.22 | Supportata |
Footprint di deployment e sizing
Bob self-hosted viene eseguito come workload tenant su un cluster OpenShift Container Platform (OCP) gestito dal cliente. I requisiti di risorse variano in base ai componenti Bob deployati e non sono fissi per tutte le installazioni.
Ogni deployment include Bob Core, che fornisce i servizi di piattaforma fondamentali. Componenti opzionali, come Z Context tool, Z Proxy e Z Understand, richiedono risorse di calcolo, memoria e storage aggiuntive e devono essere considerati nel dimensionamento del cluster.
Gli add-on vengono abilitati durante l'installazione dall'amministratore del cluster. L'abilitazione di un add-on non solo aumenta i requisiti di risorse del cluster, ma determina anche se il corrispondente entitlement del pacchetto premium può essere assegnato agli utenti. Per ulteriori informazioni, vedere Gestione degli entitlement.
I valori di sizing in questa sezione rappresentano le risorse aggregate richieste dai workload Bob. Sono forniti per stimare il footprint del tenant e non sono intesi a definire l'architettura complessiva del cluster. Devi dimensionare il cluster sottostante in base ai tuoi requisiti operativi, inclusi alta disponibilità, altri workload tenant, crescita attesa e overhead dei servizi di piattaforma.
Queste cifre rappresentano la somma delle richieste di risorse dei pod configurate per tutti i componenti Bob ai relativi numeri di repliche specificati. Questa è la quantità di CPU e memoria che lo scheduler di Kubernetes riserva sui nodi del cluster.
Questi valori sono intesi esclusivamente a scopo di pianificazione della capacità e dimensionamento. Non rappresentano l'utilizzo effettivo delle risorse a runtime e non devono essere interpretati come consumo di risorse garantito sotto carico.
Le decisioni di dimensionamento del cluster, come il numero di nodi del control plane, nodi infrastrutturali, nodi worker, requisiti di alta disponibilità e pianificazione della crescita, rimangono di tua responsabilità.
Il model serving (inference) non è incluso. Le stime delle risorse in questa sezione non includono nodi GPU, infrastruttura di model serving o altre risorse necessarie per ospitare e servire modelli AI. Se esegui l'inference dei modelli utilizzando Red Hat OpenShift AI o una piattaforma di model serving separata, pianifica e dimensiona tali ambienti indipendentemente dal deployment di Bob.
Configurazioni dello stack supportate
Esamina la configurazione che corrisponde più da vicino al tuo deployment pianificato durante il dimensionamento del cluster OpenShift.
| Configurazione stack | CPU (raw) | Memoria (raw) | Storage (PV) |
|---|---|---|---|
| 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 rappresenta la configurazione di deployment minima supportata. I valori delle risorse rappresentano i requisiti aggregati del tenant Bob ed escludono l'overhead dell'infrastruttura di piattaforma.
Footprint delle risorse Bob
Il seguente footprint di riferimento si applica a un deployment Bob Core senza add-on opzionali abilitati.
Quando si dimensionano i nodi worker, utilizzare i valori nella riga +25% di headroom di scheduling. Questi valori forniscono capacità aggiuntiva oltre alle richieste di risorse dei pod configurate per tenere conto dei requisiti di scheduling di Kubernetes e dell'overhead a livello di nodo.
| Profilo di deployment | CPU | Memoria | Storage (PV) |
|---|---|---|---|
| Produzione (risorse richieste) | 10.8 vCPU | 10.8 GiB | ~24 GiB |
| Produzione (incluso il 25% di headroom di scheduling) | ~13.5 vCPU | ~13.5 GiB | ~24 GiB |
Il consumo di storage varia in base al volume del carico di lavoro, ai dati conservati e ai servizi abilitati. I valori mostrati rappresentano il footprint di base per un deployment Bob Core.
Topologia del cluster OpenShift
La seguente tabella mostra una configurazione di riferimento minima pronta per la produzione per un cluster OpenShift a nove nodi che esegue un deployment Bob Core. Se si esegue il deployment di componenti Bob aggiuntivi, è necessario effettuare il provisioning di capacità aggiuntiva per i nodi worker.
Configurazione di riferimento minima
| Ruolo nodo | Conteggio | CPU per nodo | Memoria per nodo | Capacità aggregata |
|---|---|---|---|---|
| Control plane | 3 | 4 vCPU (minimo) | 16 GiB (minimo) | 12 vCPU / 48 GiB |
| Nodi infrastrutturali | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Nodi worker | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB storage |
| Totale cluster | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB storage |
Dopo aver tenuto conto dell'overhead del cluster OpenShift e delle risorse riservate di sistema, la configurazione a tre nodi worker fornisce una capacità allocabile di CPU e memoria sufficiente per supportare il deployment di produzione di Bob Core.
Per riferimento, vedere OpenShift Control Plane Sizing Guidelines, Control plane node sizing (mantenere l'utilizzo al 60% o inferiore per headroom HA e upgrade), e Recommended host practices, Scalability and Performance (3 nodi infra raccomandati).
Requisiti di storage
Bob si affida allo storage persistente per database, servizi di ricerca, componenti cache, configurazione, certificati e dati di backup. La scelta della storage class appropriata è importante per prestazioni e affidabilità.
La configurazione di riferimento alloca 200 GiB di storage per nodo worker, per un totale di 600 GiB su tutto il pool worker. Questo gestisce i requisiti dei persistent volume Bob (~50 GiB), i servizi interni OpenShift come image registry, monitoring e logging, e la capacità per la crescita futura dei workload.
Storage class supportate
| Storage class | Tipo | Modalità di accesso supportate |
|---|---|---|
| NFS gestito | Provisioner Network File System (NFS) | RWO, RWX |
| OpenShift Data Foundation (ODF) | Storage Ceph-backed (RBD e CephFS) | RWO, RWX |
Requisiti della modalità di accesso allo storage
I diversi componenti Bob richiedono diverse modalità di accesso allo storage.
| Componente | Modalità di accesso richiesta | Note |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | È richiesto block storage. È fortemente consigliato storage SSD-backed. |
| OpenSearch | RWO (ReadWriteOnce) | È raccomandato block storage ad alte prestazioni. |
| Redis | RWO (ReadWriteOnce) | I dati persistenti richiedono accesso dedicato in lettura-scrittura. |
| Configurazione condivisa e certificati | RWX (ReadWriteMany) | Richiesto quando più pod devono montare lo stesso volume contemporaneamente. |
Le prestazioni dello storage hanno un impatto significativo sulla reattività e stabilità di Bob on-premises.
Throughput di storage o prestazioni I/O insufficienti, in particolare per i workload PostgreSQL, possono causare tempi di risposta aumentati, operazioni di indicizzazione più lente e prestazioni generali del sistema degradate. Quando si seleziona lo storage per workload di database:
- Utilizzare storage block SSD-backed quando possibile.
- Evitare piattaforme storage con alta latenza o IOPS limitati.
- Garantire capacità sufficiente per la crescita attesa del workload.
- Validare le prestazioni dello storage prima di deployare workload di produzione.
Per prestazioni ottimali, deploya i volumi dati di PostgreSQL e OpenSearch sullo storage block più veloce disponibile nell'ambiente.
Storage di backup
Bob richiede un target di storage separato per le operazioni di backup e ripristino. La posizione dello storage di backup deve fornire capacità sufficiente per memorizzare:
- Backup dell'applicazione
- Backup del database
- Snapshot degli indici
- Copie di retention richieste dalle policy organizzative
Lo storage di backup può essere fornito da sistemi di storage esterni supportati, come:
- Condivisioni Network File System (NFS)
- Repository di backup enterprise
- Servizi di object storage (se supportati dalla soluzione di backup)
Requisiti di rete
I componenti Bob comunicano internamente all'interno del cluster OpenShift ed esternamente con endpoint dei modelli, container registry, provider LDAP e workstation client. Prima dell'installazione, verifica che la connettività di rete e la configurazione DNS richieste siano disponibili.
Come minimo, assicurati che:
- I nodi OpenShift possano comunicare tra loro.
- La tua workstation possa accedere all'API OpenShift.
- Bob possa raggiungere gli endpoint LLM configurati.
- Bob possa raggiungere i server LDAP o Active Directory, se utilizzati.
- Le workstation client possano accedere all'endpoint ingress di Bob.
- I record DNS siano configurati per l'endpoint dell'applicazione Bob.
- I certificati TLS possano essere validati dalle workstation client.