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 valores provisórios de dimensionamento para configurações do add-on Z Understand estão agora publicados. Esses valores são baseados em testes de benchmark em andamento e podem ser atualizados à medida que os testes forem concluídos.
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 do Bob on-premises e as versões compatíveis dos componentes clientes.
| Versão do Bob on-premises | Versão do Bob IDE | Versão do Bob Shell |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
Para compatibilidade de versão dos add-ons do Premium Package, consulte Gerenciando direitos.
Arquitetura do cluster
Uma instalação on-premises do Bob no OpenShift Container Platform (OCP) suporta atualmente a seguinte arquitetura de cluster:
amd64(x86_64)
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 | Notas |
|---|---|---|
| 4.20 | Testado e suportado | Versão mínima suportada |
| 4.21 | Testado e suportado | |
| 4.22 | Testado e suportado |
Dimensionamento do cluster
O Bob é executado como uma carga de trabalho tenant em um cluster OpenShift gerenciado pelo cliente. Os requisitos de recursos variam de acordo com o stack do Bob implantado. Cada instalação inclui os componentes principais do Bob, enquanto add-ons opcionais do Premium Package aumentam a capacidade necessária de CPU, memória e armazenamento.
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.
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.
Configurações de stack suportadas
O Bob suporta múltiplas configurações de implantação. O footprint total de recursos depende dos add-ons habilitados.
| Configuração de stack | CPU (raw) | Memória (raw) | Armazenamento (PVs) | Status |
|---|---|---|---|---|
| Bob Core | 38,1 vCPU | 42,1 GiB | ~50 GiB | Baseline disponível |
| Bob Core + RAG | 38,1 vCPU | 69,1 GiB | ~62 GiB | Baseline disponível |
| Bob Core + Z Understand | 30,1 vCPU | 79,1 GiB | ~2288 GiB | Benchmarking em andamento |
| Bob Core + RAG + Z Understand | 46,1 vCPU | 113,1 GiB | ~2320 GiB | Benchmarking em andamento |
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. Os requisitos de recursos dos add-ons serão publicados após a conclusão dos testes de performance.
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.
| Perfil de implantação | CPU | Memória | Armazenamento (PVs) |
|---|---|---|---|
| Avaliação (raw) | 16,8 vCPU | 20,8 GiB | ~9 GiB |
| Avaliação (+25–30% de folga) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Produção (raw) | 28,1 vCPU | 41,1 GiB | ~50 GiB |
| Produção (+25–30% de folga) | ~36,5 vCPU | ~53,4 GiB | ~50 GiB |
Os valores recomendados incluem folga de agendamento para acomodar overhead da plataforma, flutuações de carga de trabalho, upgrades e crescimento futuro. Use os valores ajustados com folga ao dimensionar a capacidade dos nós de trabalho.
Cluster Single Node OpenShift (SNO)
O Single Node OpenShift combina o plano de controle e as cargas de trabalho de trabalho em um único host. Implantações SNO são adequadas para prova de conceito, desenvolvimento, teste e ambientes de borda onde alta disponibilidade não é necessária.
Dimensionamento de referência
| Camada | CPU | Memória | Armazenamento |
|---|---|---|---|
| Mínimo da plataforma OpenShift | 8 vCPU | 16 GiB | 120 GiB |
| Carga de trabalho de avaliação do Bob (com folga) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Total de referência do nó | ~29 vCPU | ~42 GiB | ~130 GiB |
- O Single Node OpenShift não oferece redundância de nós.
- O plano de controle e as cargas de trabalho de aplicação compartilham o mesmo host.
- Uma falha de nó resulta em indisponibilidade total do serviço.
- SNO não é recomendado para ambientes de produção que requerem disponibilidade ou capacidades de recuperação de desastres.
Para orientações de instalação, consulte How to install single node OpenShift on bare metal (mínimo 8 vCPU / 16 GiB RAM / 120 GiB de armazenamento) e Preparing to install on a single node, OCP 4.20.
Cluster OpenShift multi-nós
A arquitetura a seguir representa uma implantação de referência mínima para o Bob em execução em um cluster dedicado.
Configuração de referência mínima
| Função do nó | Contagem | CPU por nó | Memória por nó | Recursos agregados |
|---|---|---|---|---|
| Plano de controle | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infraestrutura | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Trabalho | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB de armazenamento |
| Total do cluster | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
Após levar em conta o overhead do OpenShift, o pool de nós de trabalho fornece aproximadamente:
- Capacidade alocável de 57 vCPU
- Memória alocável de 63 GiB
Essa capacidade é suficiente para suportar o footprint de produção do Bob Core, incluindo a folga de agendamento recomendada:
| Requisito | CPU | Memória |
|---|---|---|
| Requisito de produção do Bob Core | ~36,5 vCPU | ~53,4 GiB |
| Capacidade alocável do pool de trabalho | ~57 vCPU | ~63 GiB |
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 | Status |
|---|---|---|---|
| NFS Gerenciado | Provisionador Network File System (NFS) | RWO, RWX | Suportado |
| OpenShift Data Foundation (ODF) | Armazenamento baseado em Ceph (RBD e CephFS) | RWO, RWX | Suportado |
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.