Requisitos del sistema
Antes de una instalación self-hosted de Bob, asegúrate de que tu entorno cumple los requisitos de plataforma, arquitectura, cómputo, almacenamiento y red admitidos.
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 componentes validadas y compatibles con esta versión de Bob self-hosted. Asegúrate de que tu despliegue usa versiones compatibles de Bob IDE, Bob Shell, Premium Package y OpenShift Container Platform (OCP) para mantener la compatibilidad y recibir soporte completo del producto.
| Versión de Bob on-premises | Versión de Bob IDE | Versión de Bob Shell | Versión de Premium Package |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Arquitectura del clúster
El backend on-premises de Bob requiere un clúster OCP amd64 (x86_64). Todos los nodos de trabajo que programen cargas de trabajo de Bob deben ejecutarse en hardware amd64.
| Arquitectura | Soporte del clúster backend |
|---|---|
amd64 (x86_64) | Compatible |
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 |
|---|---|
| 4.20 | Compatible |
| 4.21 | Compatible |
| 4.22 | Compatible |
Huella de despliegue y dimensionamiento
Bob self-hosted se despliega como una carga de trabajo de tenant en un clúster de OpenShift Container Platform (OCP) gestionado por el cliente. Los requisitos de recursos varían según los componentes de Bob que despliegues y no son fijos para todas las instalaciones.
Cada despliegue incluye Bob Core, que proporciona los servicios de plataforma fundamentales. Los componentes opcionales, como Z Context tool, Z Proxy y Z Understand, requieren recursos de cómputo, memoria y almacenamiento adicionales y deben tenerse en cuenta al dimensionar el clúster.
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.
Estas cifras representan la suma de las solicitudes de recursos de los pods configurados en todos los componentes de Bob a sus respectivos recuentos de réplicas. Es la cantidad de CPU y memoria que el planificador de Kubernetes reserva en los nodos del clúster.
Estos valores están destinados únicamente a fines de planificación de capacidad y dimensionamiento. No representan el uso de recursos observado en tiempo de ejecución y no deben interpretarse como consumo de recursos garantizado bajo carga.
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.
El servicio de modelos (inferencia) no está incluido. Las estimaciones de recursos en esta sección no incluyen nodos GPU, infraestructura de servicio de modelos ni otros recursos necesarios para alojar y servir modelos de IA. Si ejecutas inferencia de modelos usando Red Hat OpenShift AI u otra plataforma de servicio de modelos, planifica y dimensiona esos entornos de forma independiente al despliegue de Bob.
Configuraciones de stack compatibles
Revisa la configuración que más se ajuste a tu despliegue planificado al dimensionar tu clúster de OpenShift.
| Configuración de stack | CPU (sin procesar) | Memoria (sin procesar) | Almacenamiento (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 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.
Huella de recursos de Bob
La siguiente huella de referencia se aplica a un despliegue de Bob Core sin complementos opcionales habilitados.
Al dimensionar los nodos de trabajo, usa los valores de la fila +25% de margen de programación. Estos valores proporcionan capacidad adicional más allá de las solicitudes de recursos de los pods configurados para tener en cuenta los requisitos de programación de Kubernetes y la sobrecarga a nivel de nodo.
| Perfil de despliegue | CPU | Memoria | Almacenamiento (PVs) |
|---|---|---|---|
| Producción (recursos solicitados) | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Producción (incluyendo 25% de margen de programación) | ~13,5 vCPU | ~13,5 GiB | ~24 GiB |
El consumo de almacenamiento varía según el volumen de la carga de trabajo, los datos retenidos y los servicios habilitados. Los valores mostrados representan la huella base para un despliegue de Bob Core.
Topología del clúster OpenShift
La siguiente tabla muestra una configuración de referencia mínima apta para producción para un clúster de OpenShift de nueve nodos ejecutando un despliegue de Bob Core. Si despliegas componentes adicionales de Bob, debes aprovisionar capacidad adicional en los nodos de trabajo.
Configuración de referencia mínima
| Rol del nodo | Cantidad | CPU por nodo | Memoria por nodo | Capacidad agregada |
|---|---|---|---|---|
| Plano de control | 3 | 4 vCPU (mínimo) | 16 GiB (mínimo) | 12 vCPU / 48 GiB |
| Nodos de infraestructura | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Nodos de trabajo | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB de almacenamiento |
| Total del clúster | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB de almacenamiento |
Después de contabilizar la sobrecarga del clúster de OpenShift y los recursos reservados del sistema, la configuración de tres nodos de trabajo proporciona suficiente capacidad de CPU y memoria asignable para soportar el despliegue de producción de Bob Core.
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 |
|---|---|---|
| NFS gestionado | Aprovisionador de Network File System (NFS) | RWO, RWX |
| OpenShift Data Foundation (ODF) | Almacenamiento respaldado por Ceph (RBD y CephFS) | RWO, RWX |
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 self-hosted.
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.