Requisitos para entrega do ambiente Citsmart

objetivo este documento tem como objetivo descrever a arquitetura de referência para a implantação da plataforma citsmart on premise, contemplando organização em camadas, estrutura física e lógica, mecanismos de automação, segurança e infraestrutura necessária para operação em ambiente do cliente visão geral das camadas camada web kong – api gateway segurança, roteamento e rate limiting nginx – ingress controller do cluster keycloak – autenticação centralizada oauth2, oidc, saml rancher/okd – orquestrador do cluster edge runtime – executor de código javascript/typescript camada de aplicação aplicações aplicações do citsmart implantadas como microserviços kafka + kafka connect fila de eventos e conectores externos redis caching e controle de sessão elasticsearch logs, buscas e indexação distribuída camada de dados postgresql 13+ banco de dados principal (cluster principal e réplicas) minio armazenamento de objetos compatível com s3 nfs volumes persistentes para pvcs no kubernetes pgbouncer gerenciamento do pool de conexões camada de integração apache nifi fluxo de dados, transformação e integração visual kafka connect conectividade com sistemas externos webhooks/rest apis consumo e entrega de eventos camada de ia tika extração de conteúdo pdfs, docx, imagens, planilha e apresentações langchain framework modular para construir aplicações com llms psycopg armazenamento de embeddings, cache de conversa e metadados estruturados gtts tts, prototipagem funcional langsmith debugging de chains, avaliação de qualidade e monitoramento pgvector extensão para vetores ✅ 1 entrega de servidores para o cluster necessário acesso root aos servidores topologia do ambiente sistema operacional aws linux redhat on premises rock linux, ubuntu, linux red hat oke – oci oracle linux (baseado no redhat) cluster kubernetes hostname cpu ram (gb) hd tipo master1 8 8 100 gb controlplane, etcd master2 8 8 100 gb controlplane, etcd master3 8 8 100 gb controlplane, etcd worker1 16 32 200 gb worker worker2 16 32 200 gb worker worker3 16 32 200 gb worker worker4 16 32 200 gb worker worker5 16 32 200 gb worker servidores adjacentes hostname cpu ram hd função database1 32 64 100 gb lvm postgresql primário database2 32 64 100 gb lvm postgresql secundário (ha) haproxy1 2 4 40 gb load balancer (exposição 443) haproxy2 1 4 40 gb load balancer secundário (ha) nfs 2 4 500 gib – 1 tib lvm volumes persistentes bastion 2 4 40 gb runner + ansible + provisionamento llm free hostname gpu cpu ram (gb) hd llm node nvidia a100 1 80gb de ram 14 236 50 justificativa cluster kubernetes ao implantar o kubernetes, você obtém um cluster para mais informações detalhadas, pode ser consultado o documento oficial do kubernetes no link https //kubernetes io/ptbr/docs/concepts/overview/components/ um cluster kubernetes consiste em um conjunto de servidores de processamento, chamados nodes, que executam aplicações containerizadas todo cluster possui ao menos um servidor de processamento (worker node), porém se este falhar, todo o ambiente fica sem monitoramento das funcionalidades dos serviços e sem gerênciamento a descrição simples de cada tipo de nó pode ser da seguinte forma servidores master , são responsáveis por manter o estado do cluster kubernetes, agendam e criam pods nos nodes workers kubernetes usa o algoritmo de consenso raft para quorum para manter o quorum, você precisará de nodes mestres íntegros floor(n/2) 1 praticamente isso significa 1 nó mestre você precisará de 1 nó mestre íntegro para o quorum, a perda do nó mestre deixará o cluster sem gerenciamento 2 nodes mestres você precisará de 2 nodes mestres íntegros para o quorum; a perda de qualquer um dos nodes mestres deixará o cluster sem gerenciamento 3 nodes mestres você precisará de 2 nodes mestres íntegros para o quórum, a perda de um dos nodes mestres pode ser compensada 4 nodes mestres você precisará de 3 nodes mestres íntegros para o quorum, a perda de um nos nodes mestres pode ser compensada uma configuração com 4 nodes mestres não tem vantagem sobre uma configuração de 3 nodes mestres 5 nodes mestres você precisará de 3 nodes mestres íntegros para o quorum, a perda de até dois nodes mestres pode ser compensada 6 nodes mestres você precisará de 4 nodes mestres íntegros para o quorum, a perda de até dois nodes mestres pode ser compensada nenhuma vantagem em comparação com 5 nodes mestres 7 nodes mestres você precisará de 4 nodes mestres íntegros para o quorum, a perda de até três nodes mestres pode ser compensada esta é a razão pela qual é necessário utilizar um número ímpar de nodes master para o gerênciamento servidores workers são responsáveis por receberem as cargas de trabalho e executar os pods(contêineres) um node apenas é possível executar cargas de trabalho, mas a perda deste, deixará o cluster sem lugar para os pods foi selecionado a quantidade de 5 servidores worker para dividir a carga de trabalho, deixando os servidores com menos estresse nos recursos como cpu e ram, a perda de um dos nodes worker será compensada pelos nodes restantes servidores adjacentes database será o servidor responsável pelo banco de dados para todas as ferramentas do citsmart x haproxy um serviço de proxy que pode ser utilizado em ha alta disponibilidade), a escolha de dois servidores será opcional, mas a perda dele, não pode ser compensada bastion responsável por criar o cluster kubernetes com o rke, também será responsável pelo gerênciamento via linha de comando no cluster diagrama do ambiente diagrama acima contempla a utilização de 3 workers, que devem ser escalados de acordo com a necessidade da carga como é feita a implantação diagrama acima contempla a utilização de 3 workers, que devem ser escalados de acordo com a necessidade da carga observações bastion precisa chegar ao banco de dados na porta 22 e 5432 bastion precisa chegar aos servidores do cluster na porta 22 bastion precisa resolver nomes(dns) do ambiente todos os servidores precisam ter acesso root haproxy porta 443 banco de dados porta 5432 para o cluster ✅ 2 regras de firewall justificativas ✅ 3 dns após criar o servidor haproxy na etapa 1 , deve ser criadas as url's abaixo e aponta las para o servidor haproxy caso for on premises ou igresscontroller caso for na cloud ✅ 4 certificado ✅ 5 acesso à internet acesso ao git da empresa para automação de implantação url https //gitlab centralit io porta 443 o processo de implantação faz uso de vários helm charts disponíveis em fontes como artifact hub e github, gitlab da central it além disso, o processo depende de repositórios de imagens de contêiner, como docker hub, quay io e nexus em ambientes restritos, é essencial garantir acesso à internet durante a implantação para agilizar o processo considerações finais esta arquitetura oferece alta disponibilidade redundância de control plane, workers, bancos e proxy automação ci/cd gitlab + runner + ansible + helm escalabilidade horizontal adição de workers conforme necessidade flexibilidade on prem ou cloud adaptação de dns e load balancer segurança acesso restrito, certificados tls e autenticação e autorização centralizada