Requisitos de sistema
Antes de uma instalação on-premises do Bob, verifique se o seu ambiente atende aos requisitos de plataforma, arquitetura, computação, armazenamento e rede suportados.
Os requisitos desta seção ajudam você a planejar e dimensionar adequadamente o seu ambiente OpenShift.
Versões suportadas
A tabela a seguir lista as versões de componentes validadas e suportadas para esta versão do Bob auto-hospedado. Certifique-se de que sua implantação use versões suportadas do Bob IDE, Bob Shell, Premium Package e OpenShift Container Platform (OCP) para manter a compatibilidade e receber suporte completo do produto.
| Versão do Bob on-premises | Versão do Bob IDE | Versão do Bob Shell | Versão do Premium Package |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Arquitetura do cluster
O backend on-premises do Bob requer um cluster OCP amd64 (x86_64). Todos os nós de trabalho que agendarem cargas de trabalho do Bob devem executar hardware amd64.
| Arquitetura | Suporte do cluster backend |
|---|---|
amd64 (x86_64) | Suportado |
Clusters de arquitetura mista são suportados quando as cargas de trabalho do Bob são restritas a nós amd64 usando seletores de nós ou taints. O Bob não aplica essas restrições de agendamento automaticamente.
Versões OCP suportadas
A tabela a seguir lista as versões OCP suportadas.
| Versão OCP | Status |
|---|---|
| 4.20 | Suportado |
| 4.21 | Suportado |
| 4.22 | Suportado |
Footprint de implantação e dimensionamento
O Bob auto-hospedado é implantado como uma carga de trabalho tenant em um cluster OpenShift Container Platform (OCP) gerenciado pelo cliente. Os requisitos de recursos variam com base nos componentes do Bob que você implanta e não são fixos para todas as instalações.
Toda implantação inclui o Bob Core, que fornece os serviços fundamentais da plataforma. Componentes opcionais, como Z Context tool, Z Proxy e Z Understand, requerem recursos adicionais de computação, memória e armazenamento e devem ser considerados ao dimensionar o cluster.
Os add-ons são habilitados durante a instalação pelo administrador do cluster. Habilitar um add-on não só aumenta os requisitos de recursos do cluster, mas também determina se o direito ao pacote premium correspondente pode ser atribuído aos usuários. Para mais informações, consulte Gerenciando direitos.
Os valores de dimensionamento nesta seção representam os recursos agregados necessários pelas cargas de trabalho do Bob. Eles são fornecidos para ajudar a estimar o footprint do tenant e não se destinam a definir a arquitetura geral do cluster. Você deve dimensionar o cluster subjacente com base nos seus requisitos operacionais, incluindo alta disponibilidade, outras cargas de trabalho de tenant, crescimento esperado e overhead dos serviços da plataforma.
Esses valores representam a soma das solicitações de recursos de pod configuradas em todos os componentes do Bob nos seus contadores de réplicas especificados. Esta é a quantidade de CPU e memória que o scheduler do Kubernetes reserva nos nós do cluster.
Esses valores são destinados apenas para fins de planejamento de capacidade e dimensionamento. Eles não representam o uso de recursos em runtime observado e não devem ser interpretados como consumo de recursos garantido sob carga.
As decisões de dimensionamento do cluster, como o número de nós do plano de controle, nós de infraestrutura, nós de trabalho, requisitos de alta disponibilidade e planejamento de crescimento, permanecem sob sua responsabilidade.
O serviço de modelos (inferência) não está incluído. As estimativas de recursos nesta seção não incluem nós de GPU, infraestrutura de serviço de modelos ou outros recursos necessários para hospedar e servir modelos de IA. Se você executar inferência de modelo usando o Red Hat OpenShift AI ou uma plataforma separada de serviço de modelos, planeje e dimensione esses ambientes independentemente da implantação do Bob.
Configurações de stack suportadas
Revise a configuração que mais se aproxima da sua implantação planejada ao dimensionar seu cluster OpenShift.
| Configuração de stack | CPU (raw) | Memória (raw) | Armazenamento (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 |
O Bob Core representa a configuração mínima de implantação suportada. Os valores de recursos representam os requisitos agregados do tenant Bob e excluem o overhead da infraestrutura da plataforma.
Footprint de recursos do Bob
O seguinte footprint de referência se aplica a uma implantação do Bob Core sem add-ons opcionais habilitados.
Ao dimensionar os nós de trabalho, use os valores da linha +25% de folga de agendamento. Esses valores fornecem capacidade adicional além das solicitações de recursos de pod configuradas para acomodar os requisitos de agendamento do Kubernetes e o overhead no nível do nó.
| Perfil de implantação | CPU | Memória | Armazenamento (PVs) |
|---|---|---|---|
| Produção (recursos solicitados) | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Produção (incluindo 25% de folga de agendamento) | ~13,5 vCPU | ~13,5 GiB | ~24 GiB |
O consumo de armazenamento varia com base no volume da carga de trabalho, nos dados retidos e nos serviços habilitados. Os valores mostrados representam o footprint de base para uma implantação do Bob Core.
Topologia do cluster OpenShift
A tabela a seguir mostra uma configuração de referência mínima adequada para produção de um cluster OpenShift de nove nós executando uma implantação do Bob Core. Se você implantar componentes adicionais do Bob, deve provisionar capacidade adicional de nós de trabalho.
Configuração de referência mínima
| Função do nó | Contagem | CPU por nó | Memória por nó | Capacidade agregada |
|---|---|---|---|---|
| Plano de controle | 3 | 4 vCPU (mínimo) | 16 GiB (mínimo) | 12 vCPU / 48 GiB |
| Nós de infraestrutura | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Nós de trabalho | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB de armazenamento |
| Total do cluster | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB de armazenamento |
Após levar em conta o overhead do cluster OpenShift e os recursos reservados ao sistema, a configuração de três nós de trabalho fornece capacidade alocável suficiente de CPU e memória para suportar a implantação de produção do Bob Core.
Para referência, consulte OpenShift Control Plane Sizing Guidelines, Control plane node sizing (mantenha a utilização em 60% ou abaixo para folga de HA e upgrade) e Recommended host practices, Scalability and Performance (3 nós de infraestrutura recomendados).
Requisitos de armazenamento
O Bob depende de armazenamento persistente para bancos de dados, serviços de busca, componentes de cache, configuração, certificados e dados de backup. A seleção da classe de armazenamento adequada é importante para performance e confiabilidade.
A configuração de referência aloca 200 GiB de armazenamento por nó de trabalho, totalizando 600 GiB em todo o pool de trabalho. Isso acomoda os requisitos de volume persistente do Bob (~50 GiB), os serviços internos do OpenShift, como registro de imagens, monitoramento e logging, e capacidade para crescimento futuro de cargas de trabalho.
Classes de armazenamento suportadas
| Classe de armazenamento | Tipo | Modos de acesso suportados |
|---|---|---|
| NFS Gerenciado | Provisionador Network File System (NFS) | RWO, RWX |
| OpenShift Data Foundation (ODF) | Armazenamento baseado em Ceph (RBD e CephFS) | RWO, RWX |
Requisitos de modo de acesso ao armazenamento
Diferentes componentes do Bob requerem diferentes modos de acesso ao armazenamento.
| Componente | Modo de acesso necessário | Notas |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | Armazenamento em bloco é necessário. Armazenamento baseado em SSD é fortemente recomendado. |
| OpenSearch | RWO (ReadWriteOnce) | Armazenamento em bloco de alta performance é recomendado. |
| Redis | RWO (ReadWriteOnce) | Dados persistentes requerem acesso dedicado de leitura-escrita. |
| Configuração compartilhada e certificados | RWX (ReadWriteMany) | Necessário quando múltiplos pods precisam montar o mesmo volume simultaneamente. |
A performance do armazenamento tem um impacto significativo na responsividade e estabilidade do Bob on-premises.
Throughput de armazenamento ou performance de I/O insuficientes, especialmente para cargas de trabalho do PostgreSQL, podem resultar em tempos de resposta mais longos, operações de indexação mais lentas e degradação geral do performance do sistema. Ao selecionar armazenamento para cargas de trabalho de banco de dados:
- Use armazenamento em bloco baseado em SSD sempre que possível.
- Evite plataformas de armazenamento com alta latência ou IOPS limitados.
- Garanta capacidade suficiente para o crescimento esperado da carga de trabalho.
- Valide a performance do armazenamento antes de implantar cargas de trabalho de produção.
Para performance ideal, implante os volumes de dados do PostgreSQL e OpenSearch no armazenamento em bloco mais rápido disponível no ambiente.
Armazenamento de backup
O Bob requer um destino de armazenamento separado para operações de backup e restauração. O local de armazenamento de backup deve ter capacidade suficiente para armazenar:
- Backups de aplicação
- Backups de banco de dados
- Snapshots de índice
- Cópias de retenção exigidas pelas políticas organizacionais
O armazenamento de backup pode ser fornecido por sistemas de armazenamento externos suportados, como:
- Compartilhamentos Network File System (NFS)
- Repositórios de backup empresariais
- Serviços de armazenamento de objetos (se suportados pela solução de backup)
Requisitos de rede
Os componentes do Bob se comunicam internamente dentro do cluster OpenShift e externamente com endpoints de modelo, registros de contêineres, provedores LDAP e estações de trabalho de clientes. Antes da instalação, verifique se a conectividade de rede e a configuração de DNS necessárias estão disponíveis.
No mínimo, certifique-se de que:
- Os nós do OpenShift podem se comunicar entre si.
- Sua estação de trabalho pode acessar a API do OpenShift.
- O Bob pode alcançar os endpoints de LLM configurados.
- O Bob pode alcançar servidores LDAP ou Active Directory, se utilizados.
- As estações de trabalho de clientes podem acessar o endpoint de ingress do Bob.
- Os registros de DNS estão configurados para o endpoint da aplicação Bob.
- Os certificados TLS podem ser validados a partir das estações de trabalho de clientes.