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). Todo rótulo doc é clicável e abre o guia, a seção, a página e a frase literal da Red Hat que sustenta aquele número. Termos com sublinhado pontilhado mostram o significado ao passar o mouse. 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. Baseline do growth doc RAM 16 GB mínimo · 20 GB recomendado; disco 80 GB (60 GB base + 20 GB do metrics service); 32 GB apenas em instalação bundled/offline com hub_seed_collections=true. 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 a frota vira carga — cobertura, janela, tempo por host

Estes três convertem managed hosts em forks no pico. Alimentam duas coisas: o porte relativo das classes de site (2 · Carga de automação) e o planejamento plurianual (4). Sem eles, a frota não entra em nenhum cálculo. est.

ⓘ de onde vem esta conta
Por que a frota não vira nós direto doc A doc não tem fórmula "managed nodes → nós". Managed node é medidor de licença, contado de forma deduplicada. O compute vem de jobs concorrentes × (forks+1). Estes três parâmetros são a ponte que nós construímos entre um número que o cliente sabe (a frota) e um que ele raramente sabe (o pico). est. — premissa desta ferramenta A conta hosts no pico = frota × cobertura · hosts por fork = janela ÷ tempo por host · forks no pico = hosts no pico ÷ hosts por fork Como estimar cada um Cobertura: que fatia da frota é tocada na mesma janela — patching mensal costuma ser alto, coleta diária é baixa. Janela: a duração real acordada com a operação, não a desejada. Tempo por host: meça num job real; varia muito entre um setup e um patch completo. O que mais pesa A janela. Dobrar a janela corta os forks pela metade — sai mais barato negociar uma hora a mais de janela do que comprar nós.
ⓘ 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 doc (produto — exemplo trabalhado) É o valor do exercício de planejamento de capacidade da doc: "300 managed hosts · 1,000 tasks per hour per host · 10 concurrent jobs · Forks set to 5 on playbooks. This is the default. · Average event size is 1 Mb. The virtual machines have 4 CPU and 16 GB RAM, and disks that have 3000 IOPS." — e a fórmula literal: (10 jobs × 5 forks) + (10 jobs × 1 base task impact) = 60 unidades, que é exatamente o C×(F+1) desta tela. É exemplo de produto, não requisito: refine com o p95 real do Controller (running/pending jobs) antes de fechar. A doc lista os fatores de caracterização: managed hosts · tasks per hour per host · maximum concurrent jobs · maximum forks · maximum API requests per second · node size. Impacto C × (F+1) = capacidade agregada no pico. Faltou capacidade → jobs em pending e a janela estoura. fórmula = doc 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 doc A = quantos rulebooks você vai rodar — nem mais, nem menos. A doc define: "A rulebook activation is a process running in the background defined by a decision environment executing a specific rulebook." Um rulebook rodando = uma activation. Não conte sources nem triggers doc Um rulebook pode cobrir várias origens de evento: "An Ansible rulebook is a collection of rulesets that references one or more sources, rules, and conditions." Logo Zabbix + ServiceNow + Kafka podem caber em 1 activation, ou virar 3 — é decisão de organização do conteúdo, não uma contagem derivável do número de integrações. O critério é raio de impacto est. A doc não prescreve como agrupar. Na prática, separe em rulebooks distintos o que precisa de ciclo de vida independente: reiniciar um sem derrubar o outro (a doc lembra que trocar o conteúdo exige reiniciar a activation), aplicar limites de memória diferentes, ou separar times/ambientes. Agrupe o resto. Piso = 1.
Ex. — 3 triggers Zabbix + 1 webhook ServiceNow + 1 tópico Kafka. Não existe resposta única:
· 1 activation — um rulebook referenciando as 3 sources (a doc permite: "one or more sources")
· 3 activations — um rulebook por origem, para reiniciar e limitar memória de forma independente
· mais que 3 — se você quebrar por caso de uso dentro da mesma origem
Este exemplo dizia "= 5 activations". Estava errado: tratava trigger como se fosse activation, e nem a doc nem a arquitetura sustentam isso. Corrigido em 2026-07-30.
Padrão FARO = 0 Mantenha 0 enquanto EDA estiver fora do escopo (a maioria dos projetos começa sem Automation Decisions). Só suba quando EDA entrar no escopo. est. (escolha de escopo) RAM por activation: 200 MB doc Correção de 2026-07-30: esta tela dizia que a doc 2.7 não definia RAM por activation. Define, no guia Optimize: "By default, each rulebook activation container has a 200 MB memory limit." Adotamos 200 MB. O teto real não é de quantidade, é de EVENTOS doc A doc dá o ponto de referência: "with 4 CPU and 16 GB of RAM, one rulebook activation container with an assigned 200 MB memory limit cannot handle more than 150,000 events per minute. If the number of parallel running rulebook activations is higher, then the maximum number of events each rulebook activation can process is reduced." Ou seja: activations dividem a vazão do nó — dobrar activations não dobra a capacidade de ingestão. Sintoma de subdimensionamento doc Evento demais estoura a memória do contêiner, o kernel o mata e a activation falha com status code 137. Se aparecer 137 em produção, é RAM de activation, não bug de rulebook. Não há teto de activations por nó doc A doc trata o limite como resultado de recurso observado, não número fixo: excesso de CPU/RAM/disco indica "either the Event-Driven Ansible controller is running too many rulebook activations, or some of the individual rulebook activations are using a high volume of resources". O troubleshooting de activation em pending manda checar "if you have reached the limits (for example, memory or CPU limits)" doc. Como caracterizar a carga doc São dois números, não um: (1) activations simultâneas e (2) eventos recebidos por minuto. Esta tela pede só o (1) — o (2) é o que determina se 200 MB bastam. Como mudar o limite gap O procedimento da doc manda pôr automationedacontroller_podman_mem_limit no setup inventory file e rodar o setup — mas o instalador RPM foi removido na 2.7 e essa variável não consta do apêndice de variáveis do Install 2.7. O número é atual; o caminho parece texto herdado da 2.4/2.5. Na 2.7 containerizada o veículo provável é eda_extra_settings doc. Pergunta aberta à Red Hat. EDA / Using automation decisions ↗
Premissa dos defaults (C=10 · F=5 · A=0) — C=10 e F=5 são os valores do exemplo trabalhado da doc (capacity planning exercise), com a fórmula (jobs×forks)+(jobs×1) literal. A=0 é escolha de escopo. 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 muda ao responder "sim"
Conceito Rede em camadas é o desenho Purdue/IDMZ: o alvo da automação vive num nível industrial (OT) separado da TI por uma ou mais DMZs industriais. Redes só-TI (datacenter, DMZ de borda, cloud) são planas para este efeito: uma fronteira, no máximo, entre o control plane e o alvo. Respondendo "não" A tela esconde Hops compartilhados (fixado em 0) e a coluna Zona. Não é simplificação cosmética: sem camadas não há 2+ fronteiras, e a própria regra desta tela diz que zona adjacente se resolve com regra ponto a ponto, sem hop. Respondendo "sim" Aparecem a Zona de rede por classe (catálogo do FARO, o mesmo de Ambientes) e o campo de hops compartilhados. A zona é o que permite ao FARO contar fronteiras e dizer se o alvo é alcançável — hoje isso só era preenchido VM a VM, depois de salvar. Purdue L1/L2 não aparecem no seletor, e é de propósito O catálogo registra ot_l0_l1.firewall_para_a_proxima = false: o modelo de referência não desenha firewall entre Level 1 e Level 2 (a OT Zone abrange os dois). Alvo de L1/L2 é alcançado por SSH a partir do execution node do L3 — pôr execution node lá embaixo multiplica a frota sem ganhar alcance nenhum. regra desta ferramenta · catálogo de zonas

Declare o que o AAP encontra na rede: ITSM, diretório, Git, repositório de pacotes, monitoração. Eles aparecem na raia Integrações & Serviços do desenho, com as portas, e não somam vCPU, RAM nem disco — já existem no cliente. Marque Integra apenas quando o serviço realmente troca tráfego com a plataforma: é isso que faz o desenho contar a fronteira de firewall.

ServiçoPortasZonaIntegra

Marque as zonas que existem na rede do cliente. Zona desmarcada não é oferecida em lugar nenhum e não conta fronteira. Sem nenhuma marcada, vale o catálogo inteiro. Um cliente com uma iDMZ marca só uma — é o que faz a contagem de fronteiras bater com o desenho dele.

O catálogo do FARO traz a cadeia padrão OT → IDMZ → TI → Internet. Declare aqui as zonas deste cliente — cada planta com fronteira própria, cada DMZ regional, cada nome que a empresa usa. Elas passam a aparecer em todos os seletores de zona desta tela e no desenho do HLD. O campo Após é o que liga a zona à cadeia: é dele que sai a contagem de fronteiras, e portanto a necessidade de hop.

Nome (como o cliente chama)ChaveApósOTFirewall

O que já foi acordado e o que ainda pende. Sem status, a linha conta como pendente — decisão cujo estado ninguém soube dizer não é consenso, e classificá-la como acordada faria o documento afirmar uma aprovação que não houve.

DecisãoStatusResponsável

Cada linha vira uma seta no desenho, ligando um componente a outro, com as portas daquele fluxo. Escolha a origem e o destino pela zona + camada e, quando houver mais de um card ali, refine pelo papel ou nome. A seta não altera número nenhum do sizing — ela documenta o que a Segurança vai liberar.

NomeDeParaPortasBidir.

O que a automação toca: servidores, switches, SCADA, CLP. Aparecem na raia Dispositivos do desenho, com as portas de alvo. Desmarque alcançável para o equipamento que consta no documento mas não é alcançado diretamente — assim ele aparece sem inventar uma fronteira.

Grupo de alvosDescriçãoZonaPortasProtocoloAlcançável

Para cada zona que tem execution node no inventário: quais zonas de dispositivo ele alcança, e por onde sobe até o control plane. Deixe vazio para o motor manter o comportamento antigo (alcança a própria zona, sobe pelo caminho da malha).

Zona do nóAlcançaSobe porHAInstance group

Quantos jobs de cada tipo rodam ao mesmo tempo no pico. Um system job custa 5 unidades de impacto; sync de inventário e update de projeto custam 1 cada. Deixe tudo em zero para usar o envelope bruto — que é o que o motor fazia antes deste campo existir.

Portas deste desenho que não constam da documentação da Red Hat. Entram nas arestas do mesh e saem no HLD em tabela separada, com a justificativa — nunca apresentadas como requisito do fabricante. Sem justificativa a linha não é enviada.

ProtoPortaNomeJustificativa (obrigatória)

Cada proxy do inventário (papel haproxy) fala com um ou vários destinos. Escolha um serviço de integração já declarado — as portas vêm dele — ou o control plane, que usa a porta de malha. Sem nenhuma linha, o motor mantém a dedução antiga.

ProxyZona do destinoDestinoObservação

A ferramenta já sabe onde há fronteira — vem da cadeia de zonas. Aqui você dá o nome de cada uma, para o desenho falar a língua do cliente. Use interno para o firewall que separa segmentos dentro da mesma zona: ele aparece no desenho e não conta como travessia.

NomeTipoEntre / EmNota
ⓘ por que isto é perguntado, e o que muda se ficar vazio
O que é A zona de rede (catálogo do FARO, o mesmo de Ambientes) em que ficam os nós centrais. É topologia lógica, não geografia: é ela que decide quantas fronteiras de firewall há entre o control plane e cada alvo. Como este campo nasce Preenchido com TI corporativa e rotulado como assumido, porque é assim que o catálogo de zonas a descreve — onde normalmente fica o plano de controle da plataforma de automação. Não é levantamento: é ponto de partida. Ao tocar no campo, o valor deixa de ser assumido e passa a constar como declarado no ambiente salvo. regra desta ferramenta O que muda se ficar vazio Se você limpar o campo, os nós centrais não aparecem no desenho do HLD e não entram na análise de alcance — o motor descarta VM sem zona, aqui e no ambiente salvo. O desenho passa a dizer quantos componentes sumiram e por quê, em vez de escolher uma zona por você. regra desta ferramenta Onde declarar a das outras VMs Na coluna Zona da tabela de classes de site, abaixo. Cada classe leva a sua para os execution/hop nodes daquele site.
ⓘ o que é / quantos declarar
O que é Um hop só roteia (relay, 0 forks, capacity=0) — atravessa uma zona de rede que o control plane não alcança direto (peering do receptor, 27199/TCP TLS por default, configurável na instalação). A regra: hop é por PROFUNDIDADE DE CAMADA, não por site Precisa de hop quando o execution node está a 2 ou mais fronteiras de firewall do control plane. Se a zona é adjacente, uma regra ponto a ponto resolve e não há hop. Por que "compartilhado" Um hop na camada de borda atende TODOS os sites atrás dele. Conta 1 vez aqui, nunca por site. +1 localidade ≠ +1 hop. Quantos est. A topologia testada da Red Hat traz 1 hop node ("1 | Automation mesh hop node", Plan 2.7 p.18). O par HA (2) é decisão de arquitetura desta ferramenta, porque o hop é o único caminho da frota remota até o control plane. A doc apoia isso de forma condicional: "Horizontally scaling by adding more hop nodes could offer redundancy when one hop node goes down" produto · Optimize 2.7 p.62. Declare 0 apenas se todas as zonas forem adjacentes.
Exemplo — rede em camadas (padrão Purdue/IDMZ): se o execution node está em OT Level 3 e o control plane no IT, com uma IDMZ entre eles, são 2 fronteiras → hops compartilhados = 2 (par HA na IDMZ), e cada site OT declara hops = 0. Zonas como DMZ e cloud, se adjacentes ao control plane, não usam hop.
Quando um site declara hop próprio Só se ele estiver atrás de uma fronteira adicional exclusiva, além da borda comum. É exceção, não regra. doc Administer 2.7 — mesh ↗

A carga central (jobs concorrentes acima) gera a execução central. Cada site remoto ganha seus execution nodes locais — executam perto dos alvos, via Automation Mesh. Declare os sites por classe: o BoM lê de cada site apenas porte→forks, adjacência e hops — o nome não entra em conta nenhuma, então setenta plantas iguais são uma linha com Qtd 70. Hops normalmente ficam em 0: vêm do campo "hops compartilhados" acima, e são partilhados por todos os sites.

ClasseQtdPorteZonaAdjac.Hops excl.

A classe é o default; a exceção é explícita. Quando um site foge do padrão da classe (porte maior, fronteira exclusiva), use ⤴ desvio na linha dela: o botão tira 1 site da classe e o promove a linha própria — é como se declara "69 plantas médias + 1 gigante" sem transformar as 69 em 69 linhas.

ⓘ como se relacionam: hop × classe de site × 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 4 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, e é por fronteira de camada, não por site: compartilhado por tudo atrás dele → +1 localidade ≠ +1 hop.
3. hop só existe se o site estiver a 2+ fronteiras de firewall do control plane. Zona adjacente dispensa hop.
4. Piso de alcance: cada zona remota tem no mínimo 1 execution node independentemente do pico de carga — porque alcance é binário e capacidade é contínua. Capacidade ociosa no core não executa nada atrás de um firewall. Exemplo — borda compartilhada 
CORE  (control plane + execution central)
 │
 │  hops compartilhados = 2   -> par HA na camada de borda
 │                               atende TODAS as zonas atras dela
 ├ Zona remota A   hops=0 -> execution local
 ├ Zona remota B   hops=0 -> execution local
 └ Zona remota C   hops=0 -> execution local

Caminho ate a zona A: execution ==> hop(borda) ==> control plane
  2 hops no TOTAL, para 3 zonas -- nao 3 pares de hop.
O erro que isto evita Declarar hop em cada site multiplica VMs de roteamento por site. Com 10 sites, o modelo errado gera 10+ hops; o correto gera 2. Nesta tela Uma linha é uma classe. O cálculo é feito por site — ⌈forks×folga ÷ capacidade do shape⌉, elevado ao piso de alcance — e só então multiplicado por Qtd. A ordem importa: dividir a carga da classe pelo total de nós apagaria o piso e devolveria 1 nó para 70 plantas. Hops excl. → deixe 0, salvo fronteira exclusiva daquela classe. 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 no próprio host e cria bancos e usuários — padrão do growth, e só PostgreSQL 15. Externo = fora do controle do instalador, aceita PG 15/16/17 — e é o externo que "require International Components for Unicode (ICU) support" produto. "Externo" NÃO significa "o cliente já tem PostgreSQL" doc Externo quer dizer apenas não gerenciado pelo instalador do AAP. Serve igual uma VM que você provisiona agora só para isso, um RDS, um Cloud SQL. O que muda no inventário é uma linha: "When using an externally managed database, do not include the [database] group in your inventory file." E o instalador ainda ajuda: "If you have PostgreSQL admin credentials, you can supply them in the inventory file and the installation program creates the PostgreSQL users and databases for each component for you. The PostgreSQL admin account must have SUPERUSER privileges." Sem credenciais de admin, você cria os cinco na mão — a doc dá o SQL: CREATE USER … CREATEDB; e CREATE DATABASE … OWNER …; Quantos discos doc + gap A doc especifica um volume de dados: "200 GB storage on a volume capable of at least 3000 IOPS". Não há disco separado para WAL nem tablespaces — pg_wal, tablespace e "separate volume" têm zero ocorrências nos 18 PDFs 2.7. Separar o WAL é prática corrente de PostgreSQL, mas seria decisão sua, sem respaldo na doc. O disco de SO do nó de banco não é especificado — as tabelas de 60/80 GB por mount point valem para os nós do AAP, não para a VM do banco. Na prática você provisiona 2 discos: SO (dimensionado pelo seu padrão de RHEL) + dados (200 GB @ 3000 IOPS). Só o segundo vem da doc. 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; 5 bancos: gateway/controller/hub/eda/metrics — 20+80+40+60+20 = 220 GB na tabela External database storage allocation; 3000 IOPS). Gerenciado no growth = sem VM extra. doc Plan 2.7 — database ↗
ⓘ HA, specs e o que faz o disco crescer
Baseline 4 vCPU · 16 GB · 200 GB @ 3000 IOPS, max_connections ≥ 1024. doc Medir o IOPS antes de instalar é o item mais sensível do sizing — e a ferramenta de medição é escolha nossa: FIO (Flexible I/O Tester) serve. est. A doc 2.7 exige o número (3000) e não prescreve ferramenta: não consta — fio tem zero ocorrências nos 16 guias 2.7. São 5 bancos — e cada guia lista 4 diferentes doc O Plan 2.7 (p.47) diz "Support for 4 separate databases: automationcontroller, automationhub, automationeda, metrics_service" — omite o gateway. O inventário de banco externo do Install 2.7 (p.30 e p.43) traz gateway_pg_database, controller_pg_database, hub_pg_database, eda_pg_database e automationmetrics_pg_database. A união é 5. Provisione os cinco — quem seguir só o Plan não cria o banco do gateway. Divergência entre guias da própria Red Hat, a reportar. Requisitos extra do banco de metrics doc 100 conexões mínimo, usuário com role CREATEDB, e ms_awx_readonly com SELECT em todas as tabelas do schema public — exige ALTER DEFAULT PRIVILEGES para tabelas futuras. HA — o que a Red Hat cobre e o que não cobre doc A topologia enterprise testada conta 1 banco externo. Marcar HA aqui acrescenta a 2ª VM ao BoM est. — mas a decisão importante não é a VM, é a fronteira de suporte, definida no artigo Database Scope of Coverage que o Install 2.7 referencia:
É suportado — "Ansible Automation Platform connecting to a highly-available or disaster-recovery configured database is a supported configuration. In this scenario, support is limited to the connection to the database."
NÃO é coberto — "Replication configuration for HA or DR" e "HA/DR operation", tanto no banco embarcado quanto no banco do cliente. E: "if issues are detected that are determined to be with the HA configuration or the underlying infrastructure, Red Hat may at their discretion provide suggestions, or refer the customer to the appropriate vendor."
Tradução para a proposta: pôr o banco em HA não invalida o suporte do AAP — pode e, para produção, deve. Mas o desenho, a operação e o troubleshooting do cluster são seus. Se o incidente for do HA, a Red Hat encaminha ao fornecedor. Isso precisa estar escrito no escopo de serviço, não descoberto no primeiro failover. Escolha do mecanismo: a doc 2.7 só exemplifica multi_az: true na referência AWS/OpenShift doc. Qualquer outro (Patroni, CNPG, replicação nativa) é decisão sua — declare como tal. gap O que faz o disco crescer É aqui — e só aqui — que a contagem de hosts entra direto no sizing. O storage cresce com frequência de jobs × nº de tasks × verbosidade × nº de hosts por job × retenção. A maior tabela é a de job_events. O que os "100" realmente são produto Os limiares de 100 GB em 30 dias, >100 jobs concorrentes, >100 conexões e >1 réplica de qualquer componente delimitam quando NÃO usar o banco provisionado pelo Operator (que tem max_connections 100 e teto de 100 GB) — não são gatilhos genéricos de escalar plataforma. Para banco externo, use-os como sinal de engenharia. doc Antes de aumentar o disco Rode os cleanup jobs de management (retenção de job events/activity stream). Muita gente compra storage quando o problema é retenção sem política.
Estimar o disco pela carga (opcional)
ⓘ por que a carga do banco vem da frota, e o que a doc publica
O que o banco realmente lê A conta é eventos/dia = tarefas/dia × eventos por task. Os campos jobs, hosts por job e tasks por job só existiam para produzir tarefas/dia como produto — e três números para um resultado deixam duas liberdades soltas: 200×50×30, 100×100×30 e 3000×1×100 dão exatamente o mesmo volume. Por que isso importava Sem amarração, a frota declarada lá em cima e o disco estimado aqui embaixo podiam descrever clientes diferentes. Nos valores de fábrica, descreviam: 500 hosts de frota contra 10.000 execuções de host por dia — cada host tocado 20×/dia, premissa que ninguém tomou. O que a Red Hat publica doc Ela não publica managed nodes → jobs concorrentes (e derivar isso continua proibido nesta ferramenta). Mas caracteriza carga assim: "300 managed hosts · 1,000 tasks per hour per host · 10 concurrent jobs" — hosts × taxa de tarefas, que é exatamente a grandeza do storage. Por que o default não é 1.000/hora Naquele exemplo, numa janela de 4h, seriam 4.000 tarefas por host — ~130× o que esta tela usava. O número fica como referência da doc, não como default: trocar modelagem e valor no mesmo passo esconderia qual dos dois moveu o resultado. Calibre com um job real. Se preferir declarar à mão Desmarque a caixa e informe jobs, hosts e tasks. A tela passa a mostrar a divergência contra a frota em vez de escondê-la.
ⓘ de onde vêm esses dois números
Eventos por task doc Não é 1 por task. A doc mede: "a debug task printing 'Hello World' produces 6 job events with the verbosity of 1 on one host. With a verbosity of 3, it produces 34 job events... Therefore, you must estimate that the task produces at least 6 events." Por isso o default é 6 — assumir 1 subestima o storage em ~6× no melhor caso. KB por evento est. O exemplo da doc usa "Average event size is 1 Mb", valor que parece generoso e pode ser específico daquele workload. Não há número normativo de bytes por evento. Mantemos 2 KB como ponto de partida conservador e exigimos calibração em staging: consulte o tamanho real da tabela de job_events após uma semana de operação. Como calibrar SELECT pg_size_pretty(pg_total_relation_size('main_jobevent')); dividido pelo nº de eventos do período.
quantidade
ⓘ proxy reverso como caminho para OT — e a armadilha de configuração
O caso Um proxy reverso (NetScaler, F5) na IDMZ por onde passa o alcance às zonas OT. Ele deixa de ser só a porta de entrada do cluster e vira trânsito — por isso a camada é escolhível: em ACESSO ele é entrada; em EXECUÇÃO ele aparece na raia por onde o tráfego desce para as plantas. A armadilha, e ela quebra o mesh doc O mesmo appliance atende dois fluxos com configurações OPOSTAS, e confundi-los é falha de instalação, não de desenho:
443 — UI/API e pull de EE: o proxy TERMINA o TLS. A doc é explícita: passthrough SSL não é suportado para o platform gateway, exige HTTP/1.1 (HTTP/2 não suportado), o FQDN do LB no SAN/CN do certificado e gateway_main_url apontando para ele.

27199 — Automation Mesh: o proxy NÃO PODE TERMINAR. O receptor usa TLS mútuo com CA própria do mesh; terminar a sessão quebra a autenticação mútua. Tem de ser L4 / SSL_BRIDGE (passthrough) — que é exatamente o oposto da regra acima.
Por que isto está escrito aqui Porque as duas afirmações são verdadeiras ao mesmo tempo e parecem contradizer-se. São dois virtual servers no mesmo equipamento: um terminando 443, outro fazendo bridge de 27199. Um HLD que diga só "passa pelo NetScaler" deixa a decisão para quem for configurar, e a chance de errar é alta. O que o proxy NÃO substitui Ele não elimina o hop node. O hop existe por profundidade de fronteira (2+ firewalls entre execution e control plane); o bridge de 27199 transporta a sessão, não reduz a contagem de fronteiras. Declare os hops normalmente.
ⓘ 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 ↗
ⓘ o que é "semear" e por que dobra a RAM
Conceito hub_seed_collections=true faz o instalador pré-carregar o catálogo Red Hat dentro do seu Automation Hub privado, já na instalação — as collections Certified e Validated caem nos repositórios rh-certified e validated. Sem semear, o Hub sobe vazio e você sincroniza depois (do console.redhat.com) ou publica à mão. Por que a RAM sobe Não é consumo de regime — é pico durante a instalação: o bundle é descompactado e indexado no Pulp de uma vez. A doc registra ~32 GB nesse pico e 45+ min de duração. O disco baseline segue 60 GB; o que cresce com o catálogo é o storage de artefatos (Pulp), dimensionado à parte. doc Como esta tela trata Marcado, a linha do Hub passa de 16 GB para 32 GB e é remarcada est. — porque provisionar 32 GB em regime é escolha conservadora, não requisito. Alternativa: provisionar 16 GB, subir para 32 GB só na janela de instalação e devolver depois. Mais barato, mais trabalho operacional — e exige que a VM aceite mudança de memória. Quando LIGAR · Ambiente desconectado / air-gapped, ou com egress restrito ao console.redhat.com.
· Você quer curadoria de versão desde o dia 1 — o catálogo entra numa versão conhecida, não "a mais recente do dia".
· Política de segurança exige que todo conteúdo venha do Hub interno, nunca do Galaxy público. Quando DEIXAR DESLIGADO · Laboratório e provas de conceito — cabe em 16 GB e instala muito mais rápido.
· Você vai sincronizar só um subconjunto de collections (o caso comum: poucas famílias, como rede e virtualização).
· A janela de instalação é curta — semear acrescenta 45+ min.
Distinção que costuma confundir: o execution node remoto puxa o Execution Environment do Hub por 443. O EE é uma imagem de contêiner, não uma collection — semear não resolve a distribuição de EE. O que semear resolve é ter o catálogo Certified/Validated interno para construir esses EEs, útil quando a política exige que todo conteúdo venha do Hub interno.
Plan 2.7 ↗
ⓘ 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%
0.0
ⓘ o parâmetro que multiplica o resultado por ~9
O que é produto Campo por instância, de 0.0 a 1.0, que interpola entre os dois cálculos de capacidade: 0.0 usa o MENOR (limite de CPU), 1.0 usa o MAIOR (limite de memória), 0.5 fica no meio. Fórmula: capacity = menor + (maior − menor) × capacity_adjustment. Os dois cálculos produto "By default, 1 fork of Ansible is estimated to use 0.25 of a CPU and 100 Mb of memory". O setting SYSTEM_TASK_FORKS_CPU vale 4 (forks por core) — os 0,25 CPU são o equivalente derivado. Num nó 4 vCPU / 16 GB: 16 forks por CPU contra 137 por memória — 8,6× de diferença. Por que 137 e não 140 ou 143 143 não existe em nenhum guia 2.7 — é aritmética nossa, aplicando a fórmula da p.42 ((mem − 2048) / 100) com mem = 16384. 137 é resultado experimental publicado: a tabela da p.64 fica sob "Reference the experimental results […] that shows the observed event processing rate" doc. Adotamos 137: é o número da Red Hat, é o mais conservador dos dois, e é o que se defende numa auditoria. Por que os dois não batem: o MemTotal da máquina de teste não consta na doc. Que a RAM detectada seja ~4% menor que 16.384 MiB é explicação plausível — e é inferência nossa, não afirmação da Red Hat. est. O default: RESOLVIDO em 2026-08-17 — a p.44 é defeito de documentação O default do produto é 1.0 (mem_capacity), e a contradição da p.44 foi datada e rastreada até um defeito editorial. Mas atenção à distinção que organiza tudo abaixo: o default do produto e a base deste sizing são valores diferentes, e é correto que sejam — ver o quadro ao final. Verificado no PDF oficial Optimize AAP 2.7:
(A) p.44 diz MÍNIMO — Select the correct capacity: "By default, automation controller selects the minimum number of forks calculated by these two algorithms. This is to ensure that the instance does not overcommit resources." produto · Optimize 2.7 p.44
Esta frase não existia na 2.5 — entrou na 2.6 e persiste na 2.7. Datado por comparação dos ramos 2.5 e 2.6 do repositório-fonte ansible/aap-docs.
(B) p.62 diz MÁXIMO — Benefits of scaling execution nodes: "By default, all nodes are set to the top of that range." produto · Optimize 2.7 p.62
Presente sem alteração desde a 2.5.
O que mais existe — e que NÃO fecha a questão A tabela de Example workload requirements (p.64) registra capacidade default de 137 para um nó de 4 CPU / 16 GB, que é o valor por memória — coerente com (B) produto. E a p.65 manda "reduce the capacity down to 16, the lowest value" no control node, ação que só faz sentido se o ponto de partida for o alto — também coerente com (B). No código upstream do AWX o campo tem default=Decimal(1.0), também coerente com (B) upstream — não é produto. Nos demais guias 2.7 (Plan, Install, Administer, Observe e outros 13) o termo capacity_adjustment não aparece nenhuma vez — só no Optimize; o único ajuste de capacidade num inventário de exemplo é controller_percent_memory_capacity=0.5, e só na topologia growth produto. A passagem que decide, e que faltava
(C) p.41 NOMEIA o default — Resource determination for capacity algorithm: "The default, mem_capacity, enables you to over-commit processing resources while protecting the system from running out of memory." produto · Optimize 2.7 p.41
É a única passagem do conjunto 2.7 que nomeia o default diretamente. Tem ancestral canônico: awx/docs/capacity.md:32 traz mem_capacity (the default).
Por que a p.44 perde. A frase "selects the minimum" não tem ancestral upstream nenhum — não existe no docs/capacity.md do AWX nem em Improving AWX Performance. Entrou em ansible/aap-docs pelo commit ba8fb34246 (2025-10-30, "DITA changes for controller guides"), dentro de um bloco [role="_abstract"] acrescentado numa passagem de estilo. Ramo 2.5: zero ocorrências. É defeito de documentação, não afirmação concorrente. Placar de produto: p.41, p.62 e a tabela da p.64 contra um abstract editorial. Ressalva de precisão: a p.65 ("reduce the capacity down to 16") fala do control node, não do execution node — vale como corroboração direcional, não como evidência sobre o nó de execução.Por que esta ferramenta mostra 0.0 e não 1.0São duas perguntas distintas, e confundi-las foi o erro que a ADR-VALE-025 corrige. Default do produto = 1.0 — o que um AAP recém-instalado faz. É fato, citado acima. Base deste sizing = 0.0 — o que este projeto vai operar. É decisão de engenharia (ADR-VALE-024, decisão 2), que torna capacity_adjustment=0.0 requisito de configuração verificável por GET /api/v2/instances/, critério de saída da fase F1. Dimensionar em 1.0 seria dimensionar uma configuração que a própria ADR proíbe. E a assimetria de risco confirma: subdimensionar erra tarde e caro (aparece em produção, com o contrato assinado); superdimensionar erra cedo e barato (aparece na revisão da proposta, e é negociável). O que continua aberto na Red Hat deixou de ser "qual é o default?" e passou a ser pedido de errata para a p.44, instruído com o commit e com awx/main/models/ha.py:163. Como resolver na prática, sem depender do default 1. Declare o valor. Não herde: fixe capacity_adjustment explicitamente em cada instância e registre no as-built. Um sizing por CPU só é válido se o valor estiver declarado. 2. Ponha um teto que a doc 2.7 sustenta. Limite também no instance group com max_concurrent_jobs e max_forks — mecanismo integralmente documentado na 2.7 e que não depende de saber o default. Ambos têm default 0 = sem limite. produto 3. Meça. Confira o valor efetivo em GET /api/v2/instances/ e acompanhe o job events lag — a própria doc manda usar o capacity adjustment quando ele sobe. produto Por que isto é o item mais importante da tela Dimensionar conservador (0.0) e deixar o produto no default produz um BoM ficcional: o Controller vai calcular ~140 e despachar até lá, o nó satura, e o dimensionamento não protege ninguém. A escolha conservadora só é honesta se virar configuração. O valor aqui entra no BoM e na lista de configuração pós-instalação. Reforço Combine com max_forks e max_concurrent_jobs por instance group (default 0 = sem limite). Atenção: a Administer 2.7 descreve os dois campos com as descrições trocadas na tela de criação — confira pelo comportamento, não pelo texto. Capacity settings 2.7 ↗
ⓘ 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 — SYSTEM_TASK_FORKS_MEM, default 100) e por CPU (4 forks/core — SYSTEM_TASK_FORKS_CPU, default 4). produto Qual dos dois vale por default é pergunta aberta — a doc de produto afirma os dois gap. Esta tela adota deliberadamente o conservador (CPU-bound = 16 forks/nó de 4 vCPU): evita over-commit, e é o único dos dois que não depende de resolver a contradição a nosso favor. 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, derivado de "0.25 of a CPU" por fork a produto
  • Baseline testado por VM de mesh: 16 GB / 4 vCPU / 60 GB / 3000 IOPS por VM. a produto Medir esse IOPS com FIO (o DB externo é o mais sensível) é recomendação desta ferramenta — a doc 2.7 não prescreve ferramenta de medição. est.
  • Metrics obrigatório (+4 GB/+20 GB growth; nó 16/4/40 enterprise). a produto — EDA = 200 MB por rulebook activation a produto — e o teto real é a vazão de eventos, não a quantidade de activations
  • Linhas est. (LB, par HA do DB, shape scale-up, EDA, bastion, folga/N+1) = estimativas da ferramenta — sem spec própria na doc.
Mesh em rede segmentada — as 3 regras que a ferramenta aplica
  • Hop é por fronteira de camada, não por site. Um par HA na borda atende toda a frota atrás dele. +1 localidade ≠ +1 hop. regra desta ferramenta
    O que é de produto: o hop não executa automação, usa CPU e memória mínimos e "vertically scaling hop nodes does not impact system capacity" — logo capacity=0, entra na conta de VMs e de HA, não na de capacidade. a produto
  • Piso de alcance. Cada zona remota tem no mínimo 1 execution node independentemente do pico: capacidade ociosa no core não executa nada atrás de um firewall. Com poucos sites o pico manda na conta; com muitos sites, o piso manda. estimativa (regra de arquitetura)
  • Só há hop onde há 2+ fronteiras. Zona adjacente ao control plane resolve com regra ponto a ponto. regra desta ferramenta
    A doc trata o hop como "an option for connecting control and execution nodes" — não como exigência. Quem impõe a direção é a política de firewall do cliente; o hop é a nossa escolha de arquitetura para não multiplicar regras de travessia. a produto (o hop existe)
Fora do sizing, mas condicionam o desenho: instance group por zona é obrigatório (sem ele o job cai no default e pode ir para um nó sem rota); o tráfego de mesh não passa por reverse proxy L7 nem por inspeção SSL (TLS mútuo); e o instalador exige SSH a todos os nós — daí o bastion na borda.
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, meça o IOPS (com FIO ou equivalente — a ferramenta é escolha nossa, não da doc) e confirme o minor de RHEL (9.6+/10 — a doc 2.7 tem redações divergentes).