Dimensionamento de servidores para ERP: como acertar

O dimensionamento de servidores para ERP é uma daquelas decisões que parece técnica, mas que tem consequências comerciais significativas. Subdimensione seu servidor e você receberá reclamações de desempenho desde o primeiro dia: carregamentos lentos de páginas, tempos limite durante o pico de uso e bloqueios de banco de dados sob carga simultânea. Dimensione demais e você gastará significativamente mais do que o necessário em infraestrutura que fica praticamente ociosa.

A maioria das implementações de ERP erram o dimensionamento do servidor em uma de duas direções: equipes de TI excessivamente confiantes que dimensionam com base na intuição de "é apenas um aplicativo da web", sem levar em conta a intensidade do banco de dados do ERP, ou recomendações de fornecedores que são calibradas para desempenho máximo a qualquer custo, em vez de desempenho apropriado a um custo razoável.

Este guia fornece uma abordagem estruturada para dimensionamento de servidores para implantações de ERP: as principais variáveis que orientam os requisitos de recursos, as diretrizes de dimensionamento específicas para as principais plataformas de ERP em diferentes contagens de usuários e como usar a calculadora de dimensionamento de servidor gratuita da ECOSIRE para modelar sua situação específica.

Principais conclusões

O ERP utiliza significativamente mais bancos de dados do que aplicações web típicas — regras padrão de dimensionamento de servidores web não se aplicam

CPU raramente é a restrição; RAM e E/S de disco são quase sempre o gargalo nas cargas de trabalho de ERP

Odoo requer de 2 a 4 GB de RAM por processo de trabalho simultâneo; pelo menos 16 GB para instâncias de produção com mais de 50 usuários

Os requisitos de IOPS de armazenamento de banco de dados são dramaticamente subestimados na maioria dos exercícios de dimensionamento de servidores

Instâncias de nuvem que parecem equivalentes no papel (mesma vCPU, mesma RAM) podem ter desempenho de E/S muito diferente

Sempre dimensione para carga simultânea de pico (não carga média) com 30–40% de espaço livre

Use a Calculadora de Dimensionamento de Servidor gratuita da ECOSIRE para gerar uma especificação para sua contagem de usuários e plataforma ERP específica

Por que o dimensionamento do servidor ERP é diferente

Antes de mergulhar nas recomendações específicas, vale a pena entender por que o dimensionamento de servidores ERP requer uma análise mais cuidadosa do que o dimensionamento de uma aplicação web típica.

Intensidade do banco de dados: Os sistemas ERP são fundamentalmente sistemas de processamento de transações. Cada ação do usuário — criar um pedido de compra, lançar uma fatura, movimentar estoque — gera diversas gravações no banco de dados que devem ser confirmadas atomicamente. A camada de banco de dados lida com consultas relacionais complexas em esquemas grandes e normalizados, geralmente com múltiplas junções de tabelas e cálculos agregados. Isso é muito diferente de um sistema de gerenciamento de conteúdo ou de um site de marketing, que pode ler algumas tabelas desnormalizadas por visualização de página.

Padrões de carga de usuário simultâneos: o comportamento do usuário do ERP é mais simultâneo do que os aplicativos web típicos. Em um site de consumo, os usuários navegam de forma independente, com interações pouco frequentes. Em um sistema ERP, vários usuários do mesmo departamento podem processar pedidos simultaneamente durante os horários de pico (final do mês, final do dia, fechamento de turno). Esse padrão de gravação simultânea cria contenção de bloqueio de banco de dados que um aplicativo Web típico nunca encontra.

Carga de trabalho de geração de relatórios: relatórios de ERP (principalmente relatórios financeiros, antiguidade de estoque e previsão de demanda) executam consultas complexas de várias tabelas que podem ser executadas por 30 a 120 segundos e consomem CPU e E/S significativas durante a execução. Quando três membros da equipe financeira executam os relatórios de encerramento do mês simultaneamente, o pico de carga resultante pode ser grave.

Estado da sessão e processos de trabalho: Odoo executa especificamente processos de trabalho Python que mantêm o estado da sessão para cada conexão de usuário ativa. Cada processo de trabalho consome aproximadamente 200–400 MB de RAM em estado estacionário e até 1 GB durante a execução intensa de relatórios. O servidor precisa de RAM suficiente para executar todos os trabalhadores ativos simultaneamente, sem trocar para o disco – a troca em um servidor de banco de dados ERP causa degradação catastrófica do desempenho.

Principais variáveis no dimensionamento do servidor ERP

Quatro variáveis impulsionam os requisitos de recursos do servidor ERP mais do que quaisquer outras:

1. Contagem de usuários simultâneos (não a contagem total de usuários)

A contagem total de usuários é um mau indicador dos requisitos de recursos. A métrica correta é o pico de usuários simultâneos: o número de usuários que estão ativamente fazendo solicitações ao sistema ao mesmo tempo durante o período mais movimentado do dia.

Estimando o pico de usuários simultâneos a partir da contagem total de usuários:

ERP baseado em escritório com horário comercial normal: 15–25% do total de usuários estão simultâneos no pico
Fabricação com múltiplos turnos: 25–35% do total de usuários simultâneos (picos de mudança de turno)
Operações distribuídas entre fusos horários: menor simultaneidade de pico, mas maior duração de pico
Uso intenso de finanças durante o final do mês: aumento temporário de 40 a 50% simultâneo durante períodos de fechamento

Para uma implantação do Odoo para 100 usuários com uso normal no escritório, planeje de 15 a 25 usuários simultâneos no pico típico, com provisão para 40 a 50 usuários simultâneos durante o final do mês. Isso deve orientar o cálculo do tamanho, não o total de 100 usuários.

2. Volume de transações e complexidade das transações

Altos volumes de transações impulsionam a carga de gravação do banco de dados independentemente de usuários simultâneos. Uma empresa de distribuição que processa 2.000 pedidos de compra por dia gera significativamente mais E/S de gravação no banco de dados do que uma empresa de serviços profissionais com 100 usuários, mas com baixo volume de transações. Da mesma forma, transações complexas (ordens de serviço de fabricação que atualizam consumo de BOM, estoque, contabilidade de custos e registros de qualidade simultaneamente) geram mais E/S do que transações simples (um lançamento contábil manual que atualiza duas contas contábeis).

Estime a complexidade da sua transação pensando nos módulos em uso: o estoque de manufatura e de vários armazéns gera as transações mais complexas; módulos simples de contabilidade e RH geram os mais simples.

3. Tamanho do banco de dados e taxa de crescimento

O tamanho do banco de dados afeta o desempenho da consulta de duas maneiras: diretamente (tabelas maiores demoram mais para serem verificadas) e indiretamente (conjuntos de trabalho que excedem a RAM disponível levam a falhas de cache e aumento de E/S).

Os bancos de dados ERP crescem mais rápido do que a maioria das equipes de TI espera. Um banco de dados inicial de 20 GB pode atingir 100 GB em dois a três anos com crescimento normal do histórico de transações, anexos de documentos e registros de auditoria. Dimensione seu armazenamento para três anos de crescimento esperado, não apenas para as necessidades atuais.

4. Carga de trabalho de integração e API

Se o seu ERP se conectar a sistemas externos via API (plataforma de comércio eletrônico, sistema 3PL, APIs bancárias, conectores de mercado), essas integrações geram carga adicional no servidor que não é refletida nas contagens de usuários. Cada chamada de API passa pela camada de aplicação e banco de dados do ERP — uma integração de alto volume (processando 1.000 solicitações de sincronização de pedidos por hora) pode corresponder à carga de 10 a 20 usuários simultâneos.

Diretrizes de dimensionamento por plataforma e número de usuários

Odoo 19 Empresa

A arquitetura do Odoo usa processos de trabalho (trabalhadores Odoo) que atendem às solicitações do usuário. O número de trabalhadores e os recursos do servidor necessários são dimensionados com a contagem de usuários simultâneos.

Cálculo do trabalhador Odoo:

Trabalhadores recomendados = (usuários simultâneos / 6) + 1, arredondado para cima
Cada trabalhador requer aproximadamente 300–500 MB de RAM em estado estável, até 1 GB durante relatórios pesados
Trabalhadores cron (para processos em segundo plano) adicionam 2 a 4 trabalhadores adicionais

Especificações mínimas recomendadas por número de usuários:

Total de usuários	Pico simultâneo	Trabalhadores	CPU (núcleos)	memória RAM	Armazenamento SSD
10–25	3–6	3	4	8 GB	100 GB
25–50	6–12	4	4	16 GB	200 GB
50–100	12–25	6	8	32 GB	300 GB
100–200	25–50	10	16	64 GB	500 GB
200–400	50–100	18	32	128 GB	1 TB
Mais de 400	100+	30+	48+	256GB+	2 TB+

Notas importantes sobre o dimensionamento do Odoo:

O banco de dados (PostgreSQL) e o aplicativo (processos de trabalho Odoo) são executados idealmente em servidores separados com mais de 100 usuários. Combinados em um único servidor, o banco de dados e o aplicativo competem pela RAM.
A memória compartilhada do PostgreSQL ( Effective_cache_size ) deve ser definida como 50–75% da RAM do servidor de banco de dados.
O armazenamento SSD é obrigatório para o diretório de dados PostgreSQL — a rotação do disco causa um desempenho catastrófico em qualquer banco de dados ERP.
Um servidor Redis separado para armazenamento de sessão Odoo é recomendado para implantações acima de 50 usuários.

Central de Negócios do Microsoft Dynamics 365

O Business Central é hospedado na nuvem na infraestrutura do Microsoft Azure ao usar o modelo de implantação SaaS — neste caso, o dimensionamento do servidor é gerenciado pela Microsoft. Para implantações locais:

Total de usuários	Pico simultâneo	CPU (núcleos)	memória RAM	RAM do SQL Server	Armazenamento
10–25	3–6	4	16 GB	8 GB	150 GB
25–75	6–18	8	32 GB	16 GB	300 GB
75–150	18–37	16	64 GB	32 GB	500 GB
150–300	37–75	32	128 GB	64 GB	1 TB

O Business Central local usa o SQL Server como banco de dados, que possui um modelo de gerenciamento de memória separado do PostgreSQL. Aloque RAM dedicada ao buffer pool do SQL Server (por meio da configuração max server memory) — aproximadamente 75% da RAM do servidor de banco de dados.

###SAP Business One

O SAP Business One é implantado localmente (Windows ou HANA) ou no SAP Business One Cloud:

Total de usuários	Pico simultâneo	CPU	RAM (SAP HANA)	RAM (servidor SQL)	Armazenamento
Até 25	6–10	8 núcleos	64 GB	32 GB	500 GB
25–75	15–25	16 núcleos	128 GB	64 GB	1 TB
75–150	25–50	32 núcleos	256 GB	128 GB	2 TB

O SAP HANA (o banco de dados na memória usado com a edição SAP Business One HANA) tem requisitos de RAM muito mais altos do que os bancos de dados tradicionais baseados em disco porque o conjunto de trabalho deve caber na memória. Os requisitos de RAM para o HANA não são negociáveis: o HANA que fica sem memória trava, e não se degrada.

Recomendações de instâncias de nuvem

Ao auto-hospedar ERP na AWS, Azure ou GCP, selecionar o tipo de instância correto é muito importante. Nem todas as instâncias com as mesmas contagens de vCPU e RAM têm desempenho equivalente para cargas de trabalho de banco de dados.

Recomendações da AWS para Odoo (aplicativo + banco de dados combinado, menos de 100 usuários):

t3.xlarge (4 vCPU, 16 GB): Desenvolvimento e pequena produção (menos de 25 usuários)
r6i.xlarge (4 vCPU, 32 GB): Produção pequena e média (25–50 usuários)
r6i.2xlarge (8 vCPU, 64 GB): Produção média (50–100 usuários)
r6i.4xlarge (16 vCPU, 128 GB): Grande produção (100–200 usuários, combinados)

Recomendações da AWS para Odoo (aplicativo/banco de dados dividido, mais de 100 usuários):

Servidor de aplicativos: c6i.2xlarge (8 vCPU, 16 GB) — otimizado para computação
Servidor de banco de dados: r6i.4xlarge (16 vCPU, 128 GB) — com otimização de memória
Armazenamento de banco de dados: io2 volumes EBS (IOPS provisionados) — 3.000 a 6.000 IOPS provisionados

equivalentes do Azure:

Servidor de aplicativos: Standard_F8s_v2 (8 vCPU, 16 GB)
Servidor de banco de dados: Standard_E16s_v5 (16 vCPU, 128 GB)

Equivalentes do GCP:

Servidor de aplicativos: c2-standard-8 (8 vCPU, 32 GB)
Servidor de banco de dados: n2-highmem-16 (16 vCPU, 128 GB)

A armadilha de desempenho de E/S: volumes EBS gp3 padrão na AWS fornecem 3.000 IOPS por padrão. Para um banco de dados ERP de produção com mais de 50 usuários simultâneos, isso geralmente é insuficiente, principalmente durante o fechamento do mês, quando vários relatórios complexos são executados simultaneamente. Use volumes de IOPS provisionados io2 para o armazenamento do banco de dados, com um mínimo de 3.000 IOPS provisionados. A diferença de custo é significativa (US$ 0,065/GB/mês para gp3 versus US$ 0,125/GB/mês para io2 mais US$ 0,065/IOPS/mês para IOPS provisionados), mas a diferença de desempenho também é significativa.

Arquitetura de alta disponibilidade

Para sistemas ERP de produção onde o tempo de inatividade tem um impacto significativo nos negócios, considere uma arquitetura de alta disponibilidade que forneça resiliência contra falhas de servidor único.

Arquitetura HA mínima para Odoo (mais de 100 usuários):

Dois servidores de aplicativos atrás de um balanceador de carga (round-robin ou sessões fixas)
Banco de dados primário PostgreSQL com uma réplica em espera (usando replicação de streaming ou AWS RDS Multi-AZ)
Cluster Redis (dois nós) para armazenamento de sessão
Armazenamento de arquivos compartilhado (AWS EFS ou equivalente) para dados de anexos de arquivos do Odoo

Essa arquitetura oferece resiliência contra qualquer falha de servidor único sem exigir intervenção manual. O failover do PostgreSQL primário para o modo de espera é automático (usando Patroni ou AWS RDS) e normalmente é concluído em 30 a 60 segundos.

Metas de RPO e RTO para ERP típico:

Objetivo do ponto de recuperação (perda máxima de dados): 5 minutos (com replicação síncrona) a 30 minutos (com replicação assíncrona)
Objetivo de tempo de recuperação (tempo de inatividade máximo): 30 a 60 segundos para failover automático, 15 a 30 minutos para recuperação manual

Usando a calculadora de dimensionamento de servidor ECOSIRE

A Calculadora de Dimensionamento de Servidor gratuita da ECOSIRE em /tools/server-sizing-calculator automatiza o processo de cálculo descrito acima. Entradas:

Seleção da plataforma ERP
Contagem total de usuários
Pico de porcentagem de usuários simultâneos (ou estimativa automática com base no caso de uso)
Volume de transações (baixo, médio, alto, muito alto)
Contagem e volume de integração (nenhuma, básica, moderada, intensiva)
Requisitos de disponibilidade (servidor único, HA, recuperação de desastres)
Preferência do provedor de nuvem (AWS, Azure, GCP ou local)

Saídas:

Especificações de servidor recomendadas para camadas de aplicativos e bancos de dados
Recomendações específicas de instâncias de nuvem para seu provedor preferido
Estimativa mensal de custos de infraestrutura
Projeção de crescimento de três anos mostrando quando você precisará fazer upgrade
Requisitos de IOPS de armazenamento e nível de armazenamento recomendado

A calculadora é calibrada com base nos dados de implantação de produção do próprio ECOSIRE em dezenas de implementações de clientes, tornando as estimativas mais confiáveis do que apenas a documentação do fornecedor.

Perguntas frequentes

Como posso estimar o pico de usuários simultâneos se nunca usamos ERP antes?

Para implementações greenfield sem dados históricos, use 20% do total de usuários como estimativa inicial para uma implantação normal baseada em escritório. Se você tiver vários turnos ou trabalhar em vários fusos horários, use 25–30%. Em seguida, adicione 50% de margem de crescimento nos primeiros dois anos. Para um ERP de 100 usuários com horário comercial normal, planeje 20 usuários simultâneos no pico típico, provisione 30 e aumente a capacidade para chegar a 40 sem alterações de infraestrutura. Essa abordagem de margem de manobra evita problemas de desempenho à medida que a adoção melhora nos meses após a entrada em operação.

Devemos executar o aplicativo e o banco de dados Odoo no mesmo servidor ou em servidores separados?

Para implantações com menos de 50 usuários, um único servidor combinado geralmente é adequado — as cargas de trabalho de aplicativos e bancos de dados nessa escala normalmente não entram em conflito. Para 50 a 100 usuários, a decisão depende dos padrões de uso: se a base de usuários estiver distribuída uniformemente ao longo do dia, sem períodos de pico significativos, um servidor combinado ainda poderá funcionar. Se houver picos acentuados (fim do mês, fechamento do turno), servidores separados de aplicativos e bancos de dados proporcionam melhor isolamento. Acima de 100 usuários, servidores separados são fortemente recomendados.

Que tipo de armazenamento devemos usar para o banco de dados Odoo?

O armazenamento SSD é obrigatório para o diretório de dados PostgreSQL – o disco giratório (HDD) produz um desempenho inaceitável em qualquer banco de dados ERP de produção. Em plataformas de nuvem, use IOPS SSD provisionado (AWS io2, Azure Premium SSD v2, GCP Extreme Persistent Disk) para o armazenamento do banco de dados se você tiver mais de 50 usuários simultâneos. O SSD de uso geral (AWS gp3, Azure Standard SSD) é aceitável para desenvolvimento e implantações de pequena produção com menos de 25 usuários simultâneos.

Quanto espaço devemos incluir no dimensionamento do nosso servidor?

Crie 30 a 40% de espaço acima da carga de pico esperada para operações normais e 100% de espaço (efetivamente o dobro da capacidade de pico) para períodos excepcionais, como fechamento de final de mês ou temporadas de pico de vendas. As implantações em nuvem podem usar o escalonamento automático para lidar com períodos excepcionais sem pagar permanentemente por essa capacidade – uma vantagem de custo significativa em relação à infraestrutura fixa local.

Próximas etapas

Use a calculadora de dimensionamento de servidor gratuita da ECOSIRE em /tools/server-sizing-calculator para gerar uma especificação para sua implantação específica. A calculadora gera uma recomendação de instância AWS/Azure/GCP e uma estimativa mensal de custo de infraestrutura que você pode usar para planejar o orçamento.

Se você está planejando uma implementação do Odoo e deseja que o ECOSIRE lide com o dimensionamento e configuração da infraestrutura junto com a implementação, o planejamento da infraestrutura está incluído em cada compromisso de implementação do ECOSIRE.

Server Sizing for ERP: How to Get It Right