FARO
Ferramenta · Arquitetura · Sizing

Dimensionamento do AAP 2.7

A Red Hat não publica uma calculadora de sizing — publica requisitos por nó, topologias testadas e a fórmula de forks. Esta tela aplica essas regras e explica cada parâmetro (o que é, como estimar, exemplo, impacto). Cada linha do resultado é marcada doc (requisito oficial 2.7) ou est. (estimativa da ferramenta). Clique em ⓘ em cada campo.

1 · Plataforma & disponibilidade

ⓘ o que muda
Conceito Como o AAP roda. Containerized = Podman rootless em RHEL 9.6+/10. Operator = pods no OpenShift. As instalações baseadas em RPM não estão disponíveis na 2.7 (removidas). Impacto Muda o modelo de nós (VMs vs pods) e os baselines (Operator/SNO growth = 32 GB/16 CPU/128 GB). No Operator, PostgreSQL e Redis ficam externos. Plan 2.7 ↗
ⓘ growth vs enterprise
Conceito Growth = tudo numa VM (all-in-one), sem redundância — PoC/menor porte. Enterprise = componentes em VMs separadas com redundância (2 gateway, 2 controller, 2 hub, 2 EDA, execution, metrics, DB externo, LB). Impacto Multiplica VMs (de 1 para ~14) e exige DB e LB externos. Redis HA no containerized enterprise = 6 VMs. Plan 2.7 ↗

2 · Carga de automação

ⓘ é o mesmo que "managed node"?
Conceito Sim — managed host = managed node: qualquer host (servidor/VM/device de rede/endpoint) que o AAP automatiza (roda uma task contra ele). A subscription Red Hat é por managed node. Como estimar Liste os hosts-alvo REAIS que entram em automação (de CMDB/planilha) — não o parque inteiro. O Controller conta em Settings › Subscription (Total / Automated / Remaining).
Ex.: parque de 4.000 servidores, mas só 1.200 entram no escopo do ano 1 → managed nodes = 1.200.
Impacto Driver do volume de trabalho e da licença. Não muda o requisito por-VM; muda quantas VMs. doc Install 2.7 ↗
ⓘ como chego nesse número?
Conceito Um job = um job template rodando (playbook + inventário + EE). C = quantos jobs em estado running no mesmo instante (pico). Como estimar A doc não dá fórmula — é estimativa de arquiteto. Cruze: (1) schedules no mesmo horário, (2) janelas de manutenção (patching de sábado concentra tudo), (3) webhooks/EDA em rajada, (4) nº de templates + ramos paralelos de workflows.
Ex.: janela de patching dom 01h = 30 schedules + 5 coletas + 3 workflows × 4 ramos (12) = ~47 jobs concorrentes.
Padrão FARO = 10 Sem telemetria, parte de C=10 — o valor do exemplo canônico da doc (max_concurrent_jobs:10 / max_forks:50, "10 jobs × 5 forks"). É estimativa, não número normativo. Refine com o p95 real de jobs concorrentes do Controller (running/pending jobs) antes de fechar. est. Impacto C × (F+1) = capacidade agregada no pico. Faltou capacidade → jobs em pending e a janela estoura. método = estimativa Administer 2.7 ↗
ⓘ como chego no fork?
Conceito Fork = processo paralelo que fala com um host por vez. forks = tamanho do lote atacado em paralelo. Default = 5. task_impact = forks + 1 (o +1 é o processo Ansible pai). Como estimar No job template › campo Forks. Escolha pelo lote: mais forks = mais rápido, mais RAM/CPU. Regra: forks ≤ nº de hosts do inventário.
Ex.: forks=5 sobre 50 hosts → task_impact = 6. Se subir a forks=20 → task_impact = 21.
Padrão FARO = 5 É o default oficial do ansible-core e do job template (campo Forks=0 → usa 5). Global para todos os projetos. Suba para 10–25 em automação de rede/API idempotente com muitos hosts (custa +RAM: 1GB/10 forks). Não baixe de 5. doc Impacto Converte "job" em capacidade: capacidade do nó ÷ (forks+1) ≈ jobs simultâneos. Forks demais p/ o hardware = OOM/over-commit. doc Administer 2.7 ↗
ⓘ o que é uma activation?
Conceito Uma rulebook activation é um contêiner de longa duração (a partir de um decision environment) que fica escutando uma source 24×7 (webhook, Zabbix, Kafka…) e dispara ações quando um evento casa a regra. 1 rulebook ativo = 1 activation = 1 contêiner sempre no ar. Como estimar Conte 1 por caso de uso de detecção (uma source + um conjunto de regras). Não é volume de eventos — é quantas "escutas" ativas.
Ex.: 3 triggers Zabbix + 1 webhook ServiceNow + 1 tópico Kafka = 5 activations.
Padrão FARO = 0 Mantenha 0 enquanto EDA estiver fora do escopo (a maioria dos projetos começa sem Automation Decisions). Activations são capacidade dedicada long-running, dimensionadas em trilha própria — a doc 2.7 não define RAM por activation. Só suba quando EDA entrar no escopo. est. Impacto ~250 MB por activation (validar em staging; varia com regras/eventos). O setting EDA_MAX_RUNNING_ACTIVATIONS existe, mas o valor "12" e os "250 MB" não constam nos PDFs 2.7. estimativa / a confirmar EDA / Using automation decisions ↗
Premissa dos defaults (C=10 · F=5 · A=0) — pontos de partida para projeto novo sem telemetria. Apenas F=5 é doc (default oficial); C e A são estimativa. Regra: C×(F+1) deve caber nos forks úteis da topologia escolhida (1GB/10 forks + 2GB/controller). Recalibre C e F com dados reais do Controller (p95 de jobs concorrentes; forks/template) antes de fechar o sizing.
ⓘ o que é / quando > 0
O que é Um hop só roteia (jump host, 0 forks) — atravessa uma zona de rede que o control plane não alcança direto (peering 27199/TCP TLS). Por que "compartilhado" É a zona comum que todos os sites remotos cruzam a partir do core (ex.: 1 salto para a DMZ corporativa). Conta 1 vez, não por site. Use 0 se os sites são alcançáveis direto. ≠ hops da localidade Aqui = zonas compartilhadas (core→DMZ). Na tabela abaixo, cada site declara os hops específicos dele, além destes. doc Administer 2.7 — mesh ↗

A carga central (jobs concorrentes acima) gera a execução central. Cada site remoto — atrás de zona(s) de rede — ganha seu par hop + execution locais (executa perto dos alvos, via Automation Mesh).

LocalidadeForksHops
ⓘ como se relacionam: hop × localidade × forks
Os 3 blocos da mesh
Executionexecuta o playbook perto dos alvossoma forks
Hopsó roteia (jump), atravessa zona de rede0 forks
Control planedecide o que roda (no core)forks centrais
As 3 regras 1. forks → só execution (hop nunca soma fork). Os forks locais de um site geram o execution DELE — não entram na conta central.
2. hop → só roteamento, 1 por fronteira de zona, compartilhado por tudo atrás dele → +1 localidade ≠ +1 hop.
3. caminho até um site = hops compartilhados (core→DMZ, contados 1×, campo acima) + hops da localidade (específicos, na tabela). Exemplo 
CORE (control plane + execution central)
 │  hop compartilhado = 1 (DMZ)
 ├ Carajas-PA  hops=1 -> execution (forks locais=100)
 ├ Itabira-MG  hops=1 -> execution (forks locais=50)
 └ Brucutu-MG  hops=2 -> execution (forks locais=30)
Caminho até Carajás = CORE → hop DMZ → hop Carajás → execution Carajás. Nesta tela Forks locais → nº de execution do site (⌈forks/64⌉, mín 2 HA, 16/32/500). Hops → zonas de rede até o site. doc · specs por site est.

3 · Componentes

ⓘ por que só um tamanho?
Conceito A topologia testada 2.7 define um único tamanho por-VM de mesh: 16 GB / 4 vCPU / 60 GB / 3000 IOPS (igual p/ execution e hop). Não há tamanhos M/L/XL testados. Como crescer A forma documentada é horizontal — adicionar mais execution nodes ao mesh, não engordar a VM. Aumentar acima de 16/4 é scale-up NÃO testado (estimativa; validar com a Red Hat). Impacto No baseline, cada nó = 4 vCPU × 4 = 16 forks. A ferramenta soma nós até cobrir a carga. doc (baseline) Plan 2.7 — mesh node requirements ↗
ⓘ gerenciado ou externo?
Conceito Gerenciado = o instalador sobe o PostgreSQL colocado (cria bancos/usuários) — é o padrão do growth (PG 15, requer ICU). Externo = banco provisionado pelo cliente — é o padrão do enterprise (PG 15/16/17). Como escolher Growth/menor porte → gerenciado (economiza VM, sem redundância). Produção/HA → externo (dimensionar à parte; é o gargalo de IOPS). Impacto Externo = +1-2 nós de DB (baseline 200 GB doc; 4 bancos: controller/hub/eda/metrics; 3000 IOPS). Gerenciado no growth = sem VM extra. doc Plan 2.7 — database ↗
quantidade
ⓘ HAProxy é obrigatório?
Conceito Na enterprise, um LB na frente dos 2 platform gateways (o gateway é o único ponto de entrada, porta 80/443). A doc lista 1 HAProxy, externally managed. Opcional? Em growth (VM única) não há LB. Na enterprise ele é necessário na prática, mas externally managed (fora do inventário do AAP) e substituível por F5, NGINX ou LB de nuvem. Impacto +N componente(s) de infra gerenciados por você; não consome capacidade de automação. A doc não especifica sizing próprio do LB. doc (papel) sizing = est. Plan 2.7 — enterprise ↗
ⓘ Redis, seed, metrics
Redis HA Exige ≥6 VMs, mas co-localizadas nos componentes (gateway/hub/EDA), exceto execution/DB — sem VMs dedicadas. A topologia enterprise acima já contempla isso. doc Hub seed hub_seed_collections=true pré-carrega o conteúdo certified/validated no Hub privado (repos rh-certified/validated) já na instalação — útil offline/air-gapped e p/ curadoria de versões. Sobe a RAM do Hub de 16 → 32 GB (pico ao descompactar o bundle; leva 45+ min); o disco baseline segue 60 GB. doc Storage dos artefatos As collections/EEs ficam no backend Pulp e crescem com o catálogo (collections × versões). Em HA (2 hubs) exigem shared storage (NFS hub_shared_data_path ou S3/Azure; RWX no OCP) — dimensionado pelo volume, sem número fixo na doc. Isto é crescimento operacional, distinto da RAM de install. doc Metrics service Obrigatório na 2.7. Growth: +4 GB RAM / +20 GB disco. Enterprise: nó dedicado 16/4/40 (mín. 4 GB/2 CPU/20 GB). doc Plan 2.7 ↗
Avançado — folga e N+1
25%
ⓘ folga, N+1, algoritmo de capacidade
Folga / N+1 Não constam na doc como fórmula — boas práticas de arquiteto: ~20–30% de folga + N+1 execution node p/ sobreviver à perda de um nó. estimativa Algoritmo de capacidade O controller calcula por memória (~100 MB/fork, reserva 2 GB) e por CPU (4 forks/core). O default do produto é o de memória (o MAIOR). Esta tela adota deliberadamente o valor conservador (CPU-bound = 16 forks/nó de 4 vCPU) — premissa de arquiteto que evita over-commit e alinha com a orientação Red Hat de capar control nodes. est. (escolha conservadora) Capacity settings 2.7 ↗

4 · Planejamento plurianual (opcional · faseado)

Dimensionamento doc = requisito oficial · est. = estimativa

—
—
VMs / nós
—
vCPU total
—
RAM total (GB)
—
Disco (GB)
Fase: base = provisionar no Ano 1 (fundacional, end-state) · incrementa = adicionar por fase conforme a carga (execution, escala horizontal)
Papel / nóQtdvCPURAMDiscoIOPSFonte / nota
Total————
Fundamentação
  • RAM/nó = forks×100 MB + 2 GB e task_impact = forks+1. a produto — CPU/nó = 4 forks/core a confirmar (Capacity settings 2.7)
  • Baseline testado por VM de mesh: 16 GB / 4 vCPU / 60 GB / 3000 IOPS por VM (validar com FIO; o DB externo é o mais sensível). a produto
  • Metrics obrigatório (+4 GB/+20 GB growth; nó 16/4/40 enterprise). a produto — EDA ≈ 250 MB/activation estimativa (não consta nos PDFs 2.7; validar em staging)
  • Linhas est. (LB, par HA do DB, shape scale-up, EDA, folga/N+1) = estimativas da ferramenta — sem spec própria na doc.
a confirmar na 2.7 Não existe calculadora oficial Red Hat. Isto aplica os requisitos por-nó (doc) + a fórmula do algoritmo de capacidade (est.) sobre a topologia testada mais próxima; o nº de nós por papel é derivado da fórmula, não da topologia testada. Feche o BoM no inventário da versão instalada, valide IOPS com FIO e confirme o minor de RHEL (9.6+/10 — a doc 2.7 tem redações divergentes).