Requisitos del sistema
Antes de una instalación on-premises de Bob, asegúrate de que tu entorno cumple los requisitos de plataforma, arquitectura, cómputo, almacenamiento y red admitidos.
Los valores de dimensionamiento provisionales para las configuraciones del complemento Z Understand ya están publicados. Estos valores se basan en pruebas de benchmark en curso y pueden actualizarse a medida que se completen las pruebas.
Los requisitos de esta sección te ayudan a planificar y dimensionar tu entorno de OpenShift de forma adecuada.
Versiones compatibles
La siguiente tabla enumera las versiones de Bob on-premises y las versiones compatibles de los componentes del cliente.
| Versión de Bob on-premises | Versión de Bob IDE | Versión de Bob Shell |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
Para conocer la compatibilidad de versiones de los complementos del paquete Premium, consulta Gestión de asignaciones.
Arquitectura del clúster
Una instalación on-premises de Bob en OpenShift Container Platform (OCP) admite actualmente la siguiente arquitectura de clúster:
amd64(x86_64)
Los clústeres de arquitectura mixta son compatibles cuando las cargas de trabajo de Bob están restringidas a nodos amd64 mediante selectores de nodo o taints. Bob no aplica estas restricciones de programación automáticamente.
Versiones de OCP compatibles
La siguiente tabla enumera las versiones de OCP compatibles.
| Versión de OCP | Estado | Notas |
|---|---|---|
| 4.20 | Probada y compatible | Versión mínima compatible |
| 4.21 | Probada y compatible | |
| 4.22 | Probada y compatible |
Dimensionamiento del clúster
Bob se ejecuta como una carga de trabajo de tenant en un clúster de OpenShift gestionado por el cliente. Los requisitos de recursos varían según el stack de Bob desplegado. Cada instalación incluye los componentes básicos de Bob, mientras que los complementos opcionales del paquete Premium aumentan la capacidad requerida de CPU, memoria y almacenamiento.
Los complementos se habilitan durante la instalación por el administrador del clúster. Habilitar un complemento no solo aumenta los requisitos de recursos del clúster, sino que también determina si la correspondiente asignación de paquete premium puede asignarse a los usuarios. Para más información, consulta Gestión de asignaciones.
Los valores de dimensionamiento en esta sección representan los recursos agregados requeridos por las cargas de trabajo de Bob. Se proporcionan para ayudar a estimar la huella del tenant y no están destinados a definir la arquitectura general del clúster. Debes dimensionar el clúster subyacente en función de tus requisitos operativos, incluyendo alta disponibilidad, otras cargas de trabajo de tenant, crecimiento esperado y sobrecarga de servicios de la plataforma.
Las decisiones de dimensionamiento del clúster, como el número de nodos del plano de control, nodos de infraestructura, nodos de trabajo, requisitos de alta disponibilidad y planificación del crecimiento, siguen siendo tu responsabilidad.
Configuraciones de stack compatibles
Bob admite múltiples configuraciones de despliegue. La huella total de recursos depende de los complementos habilitados.
| Configuración de stack | CPU (sin procesar) | Memoria (sin procesar) | Almacenamiento (PVs) | Estado |
|---|---|---|---|---|
| Bob Core | 38,1 vCPU | 42,1 GiB | ~50 GiB | Disponible como referencia |
| Bob Core + RAG | 38,1 vCPU | 69,1 GiB | ~62 GiB | Disponible como referencia |
| Bob Core + Z Understand | 30,1 vCPU | 79,1 GiB | ~2288 GiB | Benchmark en curso |
| Bob Core + RAG + Z Understand | 46,1 vCPU | 113,1 GiB | ~2320 GiB | Benchmark en curso |
Bob Core representa la configuración de despliegue mínima compatible. Los valores de recursos representan los requisitos agregados del tenant de Bob y excluyen la sobrecarga de la infraestructura de la plataforma. Los requisitos de recursos de los complementos se publicarán una vez completadas las pruebas de rendimiento.
Huella de recursos de Bob
La siguiente huella de referencia se aplica a un despliegue de Bob Core sin complementos opcionales habilitados.
| Perfil de despliegue | CPU | Memoria | Almacenamiento (PVs) |
|---|---|---|---|
| Evaluación (sin procesar) | 16,8 vCPU | 20,8 GiB | ~9 GiB |
| Evaluación (+25–30% de margen) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Producción (sin procesar) | 28,1 vCPU | 41,1 GiB | ~50 GiB |
| Producción (+25–30% de margen) | ~36,5 vCPU | ~53,4 GiB | ~50 GiB |
Los valores recomendados incluyen margen de programación para acomodar la sobrecarga de la plataforma, fluctuaciones de carga de trabajo, actualizaciones y crecimiento futuro. Usa los valores ajustados con margen al dimensionar la capacidad de los nodos de trabajo.
Clúster Single Node OpenShift (SNO)
Single Node OpenShift combina el plano de control y las cargas de trabajo del worker en un único host. Los despliegues SNO son adecuados para pruebas de concepto, desarrollo, pruebas y entornos de borde donde no se requiere alta disponibilidad.
Dimensionamiento de referencia
| Capa | CPU | Memoria | Almacenamiento |
|---|---|---|---|
| Mínimo de la plataforma OpenShift | 8 vCPU | 16 GiB | 120 GiB |
| Carga de trabajo de evaluación de Bob (con margen) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Total de referencia del nodo | ~29 vCPU | ~42 GiB | ~130 GiB |
- Single Node OpenShift no proporciona redundancia de nodos.
- Las cargas de trabajo del plano de control y de la aplicación comparten el mismo host.
- Un fallo del nodo resulta en la indisponibilidad completa del servicio.
- SNO no se recomienda para entornos de producción que requieran disponibilidad o capacidades de recuperación ante desastres.
Para orientación sobre la instalación, consulta How to install single node OpenShift on bare metal (mínimo 8 vCPU / 16 GiB RAM / 120 GiB de almacenamiento) y Preparing to install on a single node, OCP 4.20.
Clúster Multi-nodo OpenShift
La siguiente arquitectura representa un despliegue de referencia mínimo para Bob ejecutándose en un clúster dedicado.
Configuración de referencia mínima
| Rol del nodo | Cantidad | CPU por nodo | Memoria por nodo | Recursos agregados |
|---|---|---|---|---|
| Plano de control | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infraestructura | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Worker | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB de almacenamiento |
| Total del clúster | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
Después de contabilizar la sobrecarga de OpenShift, el pool de nodos de trabajo proporciona aproximadamente:
- 57 vCPU de capacidad asignable
- 63 GiB de memoria asignable
Esta capacidad es suficiente para soportar la huella de producción de Bob Core, incluyendo el margen de programación recomendado:
| Requisito | CPU | Memoria |
|---|---|---|
| Requisito de producción de Bob Core | ~36,5 vCPU | ~53,4 GiB |
| Capacidad asignable del pool de workers | ~57 vCPU | ~63 GiB |
Para referencia, consulta OpenShift Control Plane Sizing Guidelines, Control plane node sizing (mantener la utilización al 60% o por debajo para margen de HA y actualizaciones), y Recommended host practices, Scalability and Performance (se recomiendan 3 nodos de infraestructura).
Requisitos de almacenamiento
Bob depende del almacenamiento persistente para bases de datos, servicios de búsqueda, componentes de caché, configuración, certificados y datos de respaldo. Seleccionar la clase de almacenamiento adecuada es importante para el rendimiento y la fiabilidad.
La configuración de referencia asigna 200 GiB de almacenamiento por nodo de trabajo, para un total de 600 GiB en el pool de workers. Esto acomoda los requisitos de volumen persistente de Bob (~50 GiB), los servicios internos de OpenShift como el registro de imágenes, monitorización y registro de logs, y capacidad para el crecimiento futuro de cargas de trabajo.
Clases de almacenamiento compatibles
| Clase de almacenamiento | Tipo | Modos de acceso compatibles | Estado |
|---|---|---|---|
| NFS gestionado | Aprovisionador de Network File System (NFS) | RWO, RWX | Compatible |
| OpenShift Data Foundation (ODF) | Almacenamiento respaldado por Ceph (RBD y CephFS) | RWO, RWX | Compatible |
Requisitos de modo de acceso de almacenamiento
Los diferentes componentes de Bob requieren diferentes modos de acceso de almacenamiento.
| Componente | Modo de acceso requerido | Notas |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | Se requiere almacenamiento en bloque. Se recomienda fuertemente almacenamiento respaldado por SSD. |
| OpenSearch | RWO (ReadWriteOnce) | Se recomienda almacenamiento en bloque de alto rendimiento. |
| Redis | RWO (ReadWriteOnce) | Los datos persistentes requieren acceso dedicado de lectura-escritura. |
| Configuración compartida y certificados | RWX (ReadWriteMany) | Requerido cuando múltiples pods deben montar el mismo volumen de forma concurrente. |
El rendimiento del almacenamiento tiene un impacto significativo en la capacidad de respuesta y estabilidad de Bob on-premises.
El rendimiento insuficiente del almacenamiento o el rendimiento de E/S, particularmente para las cargas de trabajo de PostgreSQL, puede resultar en tiempos de respuesta aumentados, operaciones de indexación más lentas y un rendimiento general degradado del sistema. Al seleccionar almacenamiento para cargas de trabajo de bases de datos:
- Usa almacenamiento en bloque respaldado por SSD siempre que sea posible.
- Evita plataformas de almacenamiento con alta latencia o IOPS limitadas.
- Asegura capacidad suficiente para el crecimiento esperado de la carga de trabajo.
- Valida el rendimiento del almacenamiento antes de desplegar cargas de trabajo de producción.
Para un rendimiento óptimo, despliega los volúmenes de datos de PostgreSQL y OpenSearch en el almacenamiento en bloque más rápido disponible en el entorno.
Almacenamiento de respaldo
Bob requiere un destino de almacenamiento separado para las operaciones de respaldo y restauración. La ubicación del almacenamiento de respaldo debe proporcionar capacidad suficiente para almacenar:
- Respaldos de la aplicación
- Respaldos de la base de datos
- Instantáneas de índices
- Copias de retención requeridas por las políticas organizativas
El almacenamiento de respaldo puede ser proporcionado por sistemas de almacenamiento externos compatibles, como:
- Recursos compartidos de Network File System (NFS)
- Repositorios de respaldo empresariales
- Servicios de almacenamiento de objetos (si son compatibles con la solución de respaldo)
Requisitos de red
Los componentes de Bob se comunican internamente dentro del clúster de OpenShift y externamente con los endpoints de modelos, registros de contenedores, proveedores LDAP y estaciones de trabajo de los clientes. Antes de la instalación, verifica que la conectividad de red requerida y la configuración DNS estén disponibles.
Como mínimo, asegúrate de que:
- Los nodos de OpenShift pueden comunicarse entre sí.
- Tu estación de trabajo puede acceder a la API de OpenShift.
- Bob puede alcanzar los endpoints LLM configurados.
- Bob puede alcanzar los servidores LDAP o Active Directory, si se utilizan.
- Las estaciones de trabajo de los clientes pueden acceder al endpoint de ingreso de Bob.
- Los registros DNS están configurados para el endpoint de la aplicación Bob.
- Los certificados TLS pueden ser validados desde las estaciones de trabajo de los clientes.