Existe uma diferença fundamental entre administrar servidores e orquestrar uma nuvem. Durante muito tempo, o foco de muitos profissionais de infraestrutura esteve em como provisionar e gerenciar máquinas virtuais da forma mais eficiente possível. Ferramentas de virtualização tradicionais cumprem esse papel com excelência. Mas a evolução natural da tecnologia exige que mudemos a forma como entregamos infraestrutura.
Não se trata mais de entregar um servidor para o time de desenvolvimento. Trata-se de entregar serviços consumíveis por meio de APIs, onde a infraestrutura subjacente se torna invisível. Essa mudança de perspectiva é o que separa um analista de infraestrutura de um Arquiteto de Soluções. E foi exatamente essa necessidade de mudança que motivou a criação do projeto “Ajuricaba”: a construção do marco zero de uma Cloud Privada com OpenStack.
Resumo
Neste artigo você verá:
- Por que gerenciar hypervisors tradicionais deixou de ser suficiente para o meu contexto.
- O trade-off arquitetural: a escolha pelo OpenStack para construir uma verdadeira Cloud Privada.
- Como transformar um hardware limitado (um notebook) em um laboratório de engenharia avançada.
- A decisão pelo Kolla-Ansible para isolamento de recursos e conteinerização do control plane.
- O roadmap para a entrega de IaaS e SaaS em um ambiente local corporativo.
O conflito arquitetural: Virtualização vs. Cloud Privada #
Quando iniciei o planejamento desse ambiente local, a primeira opção parecia óbvia. Se o objetivo é subir máquinas virtuais e containers em um hardware físico, o Proxmox é uma escolha fantástica. Ele é rápido, estável e tem uma curva de aprendizado acessível. A questão era outra.
O Proxmox resolveria o problema da virtualização? A resposta era sim. A pergunta correta era: a virtualização tradicional atende ao que eu preciso construir como arquiteto? A resposta, nesse caso, era não.
Trabalhar exclusivamente com um hypervisor me manteria limitado ao papel de analista de infraestrutura. Na prática, eu continuaria acessando consoles, gerenciando discos manualmente e operando focado no servidor físico. O que eu precisava era avaliar e construir um ambiente real de nuvem privada. Um ambiente onde a interação direta com o servidor físico é a exceção, e não a regra. Onde os serviços (seja IaaS ou SaaS) são consumidos de forma declarativa e automatizada. Isso me levou ao OpenStack.
Assumir o OpenStack significa assumir uma curva gigantesca de complexidade operacional. Sob o capô, a virtualização ainda é feita pelo bom e velho KVM/QEMU, e a rede (SDN) opera sobre Open vSwitch (OVS/OVN). Mas a grande diferença é que o operador não toca neles diretamente. Eles são abstraídos e orquestrados por múltiplos serviços interdependentes (Nova, Neutron, Keystone, Glance) apenas para ligar a primeira máquina virtual.
O trade-off compensa. O ganho não é ter uma máquina virtual ligada. O ganho é ter um catálogo de serviços, isolamento multi-tenant e o comportamento idêntico ao de uma nuvem pública corporativa, rodando dentro de casa.
O Desafio Físico: Pragmatismo no host Ajuricaba #
Existe uma percepção comum de que uma Cloud Privada com OpenStack exige racks inteiros de servidores, switches top-of-rack e storages caríssimos. Essa é a realidade de um datacenter corporativo. A realidade do projeto Ajuricaba precisou ser muito mais pragmática.
O host bare-metal escolhido não é um servidor de gaveta. É um notebook Dell Vostro 5471. Equipado com um processador Intel Core i7 de 8ª geração, 32GB de RAM, 128GB de SSD M.2 e 1TB de HD SATA.
Parece insuficiente para rodar um ecossistema gigantesco como o OpenStack? Para quem apenas instala sistemas no modelo “next, next, finish”, com certeza. Para um arquiteto de soluções, isso não é um impeditivo. É um cenário de restrição que exige decisões de engenharia reais. Em um ambiente na nuvem pública, otimizar recursos significa reduzir a fatura no final do mês. No host Ajuricaba, otimizar recursos significa a diferença entre a nuvem funcionar ou o servidor apresentar falha generalizada por falta de memória.
Kolla-Ansible e a gestão rigorosa de recursos #
Subir os serviços do OpenStack nativamente consumiria a maior parte dos recursos do meu hardware antes mesmo da primeira carga de trabalho ser iniciada. Foi aqui que a decisão de design de implantação se mostrou crítica. A escolha foi utilizar o Kolla-Ansible.
O Kolla-Ansible conteineriza os serviços do control plane do OpenStack usando Docker e os orquestra com Ansible. Por que isso importa na arquitetura? Porque me permite isolamento e controle estrito. O sistema operacional base (Ubuntu) e o control plane do OpenStack foram arquitetados para rodar exclusivamente no SSD M.2 de 128GB. Isso garante velocidade de leitura e escrita (IOPS) cruciais para o funcionamento estável dos bancos de dados internos (MariaDB) e do barramento de mensagens (RabbitMQ).
Enquanto isso, o disco mecânico de 1TB foi logicamente isolado e mapeado para ser consumido pelo serviço de storage (Cinder) e de infraestrutura (Nova), onde residirão as instâncias e volumes de dados dos usuários.
A gestão da memória exigiu um racional matemático frio. Dos 32GB de RAM totais, reservei aproximadamente 12GB como hard limit estritamente para sustentar a densidade dos containers de controle. Isso deixou cerca de 16GB a 18GB dedicados exclusivamente para as instâncias (Compute), garantindo que o control plane não seja asfixiado pelos workloads de usuário. Com o vCPU overcommit devidamente calculado, o hardware se tornou capaz de rodar a fundação de forma estável.
O roadmap: além da infraestrutura como serviço #
Arquitetura não é sobre o estado atual. É sobre para onde a plataforma pode evoluir. O host Ajuricaba e o control plane configurados representam apenas o Marco Zero.
Estabelecer a fundação IaaS (Infrastructure as a Service) com o OpenStack foi apenas o pré-requisito para o verdadeiro objetivo: entregar serviços de alto nível com a mesma autonomia de uma nuvem pública. Ao adotar uma Cloud Privada real, pavimentamos o caminho para as próximas camadas arquiteturais. Nos próximos artigos desta série, vou detalhar como essa base será utilizada para suportar serviços avançados, incluindo:
- Armazenamento de Arquivos Compartilhado como Serviço: Trazendo capacidades NAS corporativas (Manila).
- Kubernetes as a Service (KaaS): Orquestração de clusters automatizada direto pela nuvem local (Magnum).
- Database as a Service (DBaaS): Provisionamento de bancos de dados gerenciados (Trove).
Conclusão #
A decisão pelo OpenStack no host Ajuricaba não foi sobre facilidade técnica. Se o objetivo fosse apenas facilidade, o Proxmox já estaria rodando. Foi sobre entender a diferença entre virtualizar servidores e arquitetar soluções de nuvem.
Em arquitetura, as restrições (sejam elas de budget ou de um hardware de 32GB de RAM) não devem ditar se um projeto de nuvem privada é possível. As restrições apenas ditam quão boas terão que ser as suas decisões de design. Conhecer as ferramentas disponíveis no mercado é essencial. Mas saber escolher o caminho mais difícil quando ele é o único que entrega o valor arquitetural que você busca, é o que realmente faz a diferença.
