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 valori di sizing provvisori per le configurazioni dell'add-on Z Understand sono ora disponibili. Questi valori si basano su test di benchmark in corso e potrebbero essere aggiornati al completamento dei test.
I requisiti in questa sezione ti aiutano a pianificare e dimensionare correttamente il tuo ambiente OpenShift.
Versioni supportate
La seguente tabella elenca le versioni di Bob on-premises e le versioni compatibili dei componenti client.
| Versione Bob on-premises | Versione Bob IDE | Versione Bob Shell |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
Per la compatibilità delle versioni degli add-on Premium Package, vedere Gestione degli entitlement.
Architettura del cluster
Un'installazione on-premises di Bob su OpenShift Container Platform (OCP) supporta attualmente la seguente architettura cluster:
amd64(x86_64)
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 | Note |
|---|---|---|
| 4.20 | Testata e supportata | Versione minima supportata |
| 4.21 | Testata e supportata | |
| 4.22 | Testata e supportata |
Cluster sizing
Bob viene eseguito come workload tenant su un cluster OpenShift gestito dal cliente. I requisiti di risorse variano in base allo stack Bob deployato. Ogni installazione include i componenti core di Bob, mentre gli add-on Premium Package opzionali aumentano la capacità richiesta di CPU, memoria e storage.
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.
Le decisioni di cluster sizing, come il numero di nodi control plane, nodi infrastrutturali, nodi worker, requisiti di alta disponibilità e pianificazione della crescita, rimangono di tua responsabilità.
Configurazioni dello stack supportate
Bob supporta molteplici configurazioni di deployment. Il footprint totale delle risorse dipende dagli add-on abilitati.
| Configurazione stack | CPU (raw) | Memoria (raw) | Storage (PV) | Stato |
|---|---|---|---|---|
| Bob Core | 38,1 vCPU | 42,1 GiB | ~50 GiB | Baseline disponibile |
| Bob Core + RAG | 38,1 vCPU | 69,1 GiB | ~62 GiB | Baseline disponibile |
| Bob Core + Z Understand | 30,1 vCPU | 79,1 GiB | ~2288 GiB | Benchmarking in corso |
| Bob Core + RAG + Z Understand | 46,1 vCPU | 113,1 GiB | ~2320 GiB | Benchmarking in corso |
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. I requisiti di risorse degli add-on saranno pubblicati al completamento dei test delle prestazioni.
Footprint delle risorse Bob
Il seguente footprint di riferimento si applica a un deployment Bob Core senza add-on opzionali abilitati.
| Profilo di deployment | CPU | Memoria | Storage (PV) |
|---|---|---|---|
| Valutazione (raw) | 16,8 vCPU | 20,8 GiB | ~9 GiB |
| Valutazione (+25–30% di headroom) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Produzione (raw) | 28,1 vCPU | 41,1 GiB | ~50 GiB |
| Produzione (+25–30% di headroom) | ~36,5 vCPU | ~53,4 GiB | ~50 GiB |
I valori consigliati includono headroom di scheduling per gestire l'overhead della piattaforma, fluttuazioni del workload, upgrade e crescita futura. Utilizza i valori con headroom aggiunto per dimensionare la capacità dei nodi worker.
Cluster Single Node OpenShift (SNO)
Single Node OpenShift combina i workload del control plane e dei worker su un unico host. I deployment SNO sono adatti per ambienti proof-of-concept, sviluppo, test e edge in cui l'alta disponibilità non è richiesta.
Sizing di riferimento
| Livello | CPU | Memoria | Storage |
|---|---|---|---|
| Minimo piattaforma OpenShift | 8 vCPU | 16 GiB | 120 GiB |
| Workload di valutazione Bob (con headroom) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Riferimento nodo totale | ~29 vCPU | ~42 GiB | ~130 GiB |
- Single Node OpenShift non fornisce ridondanza dei nodi.
- I workload del control plane e dell'applicazione condividono lo stesso host.
- Un guasto al nodo comporta la completa indisponibilità del servizio.
- SNO non è consigliato per ambienti di produzione che richiedono disponibilità o capacità di disaster recovery.
Per istruzioni di installazione, vedere How to install single node OpenShift on bare metal (minimo 8 vCPU / 16 GiB RAM / 120 GiB storage) e Preparing to install on a single node, OCP 4.20.
Cluster OpenShift multi-nodo
La seguente architettura rappresenta un deployment di riferimento minimo per Bob in esecuzione su un cluster dedicato.
Configurazione di riferimento minima
| Ruolo nodo | Conteggio | CPU per nodo | Memoria per nodo | Risorse aggregate |
|---|---|---|---|---|
| Control plane | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infrastruttura | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Worker | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB storage |
| Totale cluster | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
Dopo aver tenuto conto dell'overhead di OpenShift, il pool di nodi worker fornisce approssimativamente:
- 57 vCPU di capacità allocabile
- 63 GiB di memoria allocabile
Questa capacità è sufficiente per supportare il footprint di produzione Bob Core, incluso l'headroom di scheduling consigliato:
| Requisito | CPU | Memoria |
|---|---|---|
| Requisito produzione Bob Core | ~36,5 vCPU | ~53,4 GiB |
| Capacità allocabile pool worker | ~57 vCPU | ~63 GiB |
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 | Stato |
|---|---|---|---|
| NFS gestito | Provisioner Network File System (NFS) | RWO, RWX | Supportato |
| OpenShift Data Foundation (ODF) | Storage Ceph-backed (RBD e CephFS) | RWO, RWX | Supportato |
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.