Dimensionamiento del servidor para ERP: cómo hacerlo bien

El tamaño del servidor para ERP es una de esas decisiones que parece técnica pero que tiene importantes consecuencias comerciales. Si reduce el tamaño de su servidor, recibirá quejas de rendimiento desde el primer día: cargas de páginas lentas, tiempos de espera durante el uso máximo y bloqueos de la base de datos bajo carga simultánea. Si lo sobredimensiona, gastará mucho más de lo necesario en una infraestructura que permanece prácticamente inactiva.

La mayoría de las implementaciones de ERP hacen que el tamaño del servidor sea incorrecto en una de dos direcciones: equipos de TI demasiado confiados que dimensionan basándose en la intuición de "es sólo una aplicación web" sin tener en cuenta la intensidad de la base de datos del ERP, o recomendaciones de proveedores que están calibradas para un rendimiento máximo a cualquier costo en lugar de un rendimiento apropiado a un costo razonable.

Esta guía le brinda un enfoque estructurado para el dimensionamiento de servidores para implementaciones de ERP: las variables clave que impulsan los requisitos de recursos, las pautas de dimensionamiento específicas para las principales plataformas ERP en diferentes recuentos de usuarios y cómo utilizar la Calculadora de dimensionamiento de servidores gratuita de ECOSIRE para modelar su situación específica.

Conclusiones clave

ERP requiere una base de datos significativamente mayor que las aplicaciones web típicas; no se aplican las reglas de tamaño de servidor web estándar

La CPU rara vez es la restricción; La RAM y la E/S de disco son casi siempre el cuello de botella en las cargas de trabajo de ERP.

Odoo requiere de 2 a 4 GB de RAM por proceso de trabajo simultáneo; al menos 16 GB para instancias de producción con más de 50 usuarios

Los requisitos de IOPS para el almacenamiento de bases de datos se subestiman drásticamente en la mayoría de los ejercicios de dimensionamiento de servidores.

Las instancias de nube que parecen equivalentes en papel (misma vCPU, misma RAM) pueden tener un rendimiento de E/S muy diferente

Siempre dimensione para la carga simultánea máxima (no para la carga promedio) con un espacio libre del 30 al 40 %.

Utilice la Calculadora de tamaño de servidor gratuita de ECOSIRE para generar una especificación para su número de usuarios y plataforma ERP específicos.

Por qué el tamaño del servidor ERP es diferente

Antes de profundizar en recomendaciones específicas, vale la pena comprender por qué el tamaño del servidor ERP requiere un análisis más cuidadoso que el tamaño de una aplicación web típica.

Intensidad de la base de datos: Los sistemas ERP son fundamentalmente sistemas de procesamiento de transacciones. Cada acción del usuario (crear una orden de compra, publicar una factura, mover inventario) genera múltiples escrituras en la base de datos que deben confirmarse de forma atómica. La capa de base de datos maneja consultas relacionales complejas a través de esquemas grandes y normalizados, a menudo con múltiples uniones de tablas y cálculos agregados. Esto es muy diferente de un sistema de gestión de contenidos o un sitio web de marketing, que puede leer unas pocas tablas desnormalizadas por página vista.

Patrones de carga de usuarios simultáneos: el comportamiento de los usuarios de ERP es más simultáneo que el de las aplicaciones web típicas. En un sitio web para consumidores, los usuarios navegan de forma independiente con interacciones poco frecuentes. En un sistema ERP, varios usuarios del mismo departamento pueden procesar pedidos simultáneamente durante las horas pico (fin de mes, fin de día, cierre de turno). Este patrón de escritura concurrente crea una contención de bloqueo de base de datos que una aplicación web típica nunca encuentra.

Carga de trabajo de generación de informes: los informes de ERP (en particular, los informes financieros, la antigüedad del inventario y la previsión de la demanda) ejecutan consultas complejas de varias tablas que pueden ejecutarse durante 30 a 120 segundos y consumir una cantidad significativa de CPU y E/S durante la ejecución. Cuando tres miembros del personal de finanzas ejecutan los informes de cierre de fin de mes simultáneamente, el aumento de carga resultante puede ser grave.

Estado de sesión y procesos de trabajo: Odoo ejecuta específicamente procesos de trabajo de Python que mantienen el estado de la sesión para cada conexión de usuario activa. Cada proceso de trabajo consume aproximadamente entre 200 y 400 MB de RAM en estado estable y hasta 1 GB durante la ejecución intensa de informes. El servidor necesita suficiente RAM para ejecutar todos los trabajadores activos simultáneamente sin cambiar al disco; el intercambio en un servidor de base de datos ERP provoca una degradación catastrófica del rendimiento.

Variables clave en el tamaño del servidor ERP

Cuatro variables impulsan los requisitos de recursos del servidor ERP más que cualquier otra:

1. Recuento de usuarios simultáneos (no recuento total de usuarios)

El recuento total de usuarios es un mal predictor de las necesidades de recursos. La métrica correcta es el pico de usuarios simultáneos: la cantidad de usuarios que realizan solicitudes activamente al sistema al mismo tiempo durante el período de mayor actividad del día.

Estimación del pico de usuarios simultáneos a partir del recuento total de usuarios:

ERP de oficina con horario comercial normal: entre el 15% y el 25% del total de usuarios son simultáneos en horas pico
Fabricación con múltiples turnos: 25-35% del total de usuarios simultáneos (picos de cambio de turno)
Operaciones distribuidas en zonas horarias: menor simultaneidad máxima pero mayor duración máxima
Uso intensivo de finanzas durante fin de mes: aumento temporal del 40 al 50 % simultáneo durante los períodos de cierre

Para una implementación de Odoo de 100 usuarios con uso normal de oficina, planifique entre 15 y 25 usuarios simultáneos en el pico típico, con una provisión para entre 40 y 50 usuarios simultáneos durante el fin de mes. Esto debería impulsar el cálculo del tamaño, no el total de 100 usuarios.

2. Volumen de transacciones y complejidad de las transacciones

Los altos volúmenes de transacciones impulsan la carga de escritura de la base de datos independientemente de los usuarios simultáneos. Una empresa de distribución que procesa 2000 órdenes de compra por día genera significativamente más E/S de escritura en la base de datos que una empresa de servicios profesionales con 100 usuarios pero un volumen de transacciones bajo. De manera similar, las transacciones complejas (órdenes de trabajo de fabricación que actualizan el consumo de la lista de materiales, el inventario, la contabilidad de costos y los registros de calidad simultáneamente) generan más E/S que las transacciones simples (un asiento de diario que actualiza dos cuentas del mayor).

Calcule la complejidad de sus transacciones pensando en los módulos en uso: la fabricación y el inventario de múltiples almacenes generan las transacciones más complejas; Los módulos simples de contabilidad y recursos humanos generan los más simples.

3. Tamaño de la base de datos y tasa de crecimiento

El tamaño de la base de datos afecta el rendimiento de las consultas de dos maneras: directamente (las tablas más grandes tardan más en escanearse) e indirectamente (los conjuntos de trabajo que exceden la RAM disponible provocan errores de caché y un aumento de E/S).

Las bases de datos de ERP crecen más rápido de lo que esperan la mayoría de los equipos de TI. Una base de datos inicial de 20 GB puede llegar a 100 GB en dos o tres años con un crecimiento normal a partir del historial de transacciones, documentos adjuntos y registros de auditoría. Dimensione su almacenamiento para tres años de crecimiento esperado, no solo para las necesidades actuales.

4. Carga de trabajo de integración y API

Si su ERP se conecta a sistemas externos a través de API (plataforma de comercio electrónico, sistema 3PL, API bancarias, conectores de mercado), estas integraciones generan una carga adicional en el servidor que no se refleja en el recuento de usuarios. Cada llamada API pasa por la capa de aplicación y la base de datos del ERP: una integración de gran volumen (que procesa 1000 solicitudes de sincronización de pedidos por hora) puede igualar la carga de 10 a 20 usuarios simultáneos.

Pautas de tallas por plataforma y número de usuarios

Odoo 19 Empresa

La arquitectura de Odoo utiliza procesos de trabajo (trabajadores de Odoo) y cada uno atiende las solicitudes de los usuarios. La cantidad de trabajadores y los recursos del servidor necesarios aumentan con el recuento de usuarios simultáneos.

Cálculo del trabajador de Odoo:

Trabajadores recomendados = (usuarios simultáneos / 6) + 1, redondeado hacia arriba
Cada trabajador requiere aproximadamente entre 300 y 500 MB de RAM en estado estable, hasta 1 GB durante informes pesados
Los trabajadores cron (para procesos en segundo plano) agregan entre 2 y 4 trabajadores adicionales

Especificaciones mínimas recomendadas por número de usuarios:

Usuarios totales	Máximo concurrente	Trabajadores	CPU (núcleos)	RAM	Almacenamiento 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
400+	100+	30+	48+	256GB+	2 TB+

Notas importantes sobre el tamaño de Odoo:

Lo ideal es que la base de datos (PostgreSQL) y la aplicación (procesos de trabajo de Odoo) se ejecuten en servidores separados con más de 100 usuarios. Combinadas en un único servidor, la base de datos y la aplicación compiten por la RAM.
La memoria compartida de PostgreSQL (efectivo_cache_size) debe configurarse entre el 50% y el 75% de la RAM del servidor de la base de datos.
El almacenamiento SSD es obligatorio para el directorio de datos de PostgreSQL: el disco giratorio provoca un rendimiento catastrófico en cualquier base de datos ERP.
Se recomienda un servidor Redis separado para el almacenamiento de sesiones de Odoo para implementaciones de más de 50 usuarios.

Microsoft Dynamics 365 Empresa Central

Business Central está alojado en la nube en la infraestructura de Microsoft Azure cuando se utiliza el modelo de implementación SaaS; en este caso, Microsoft administra el tamaño del servidor. Para implementaciones locales:

Usuarios totales	Máximo concurrente	CPU (núcleos)	RAM	RAM del servidor SQL	Almacenamiento
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

Business Central local utiliza SQL Server como base de datos, que tiene un modelo de administración de memoria independiente de PostgreSQL. Asigne RAM dedicada al grupo de búfer de SQL Server (a través de la configuración max server memory): aproximadamente el 75 % de la RAM del servidor de bases de datos.

SAP Business One

SAP Business One se implementa localmente (Windows o HANA) o en SAP Business One Cloud:

Usuarios totales	Máximo concurrente	CPU	RAM (SAPHANA)	RAM (servidor SQL)	Almacenamiento
Hasta 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

SAP HANA (la base de datos en memoria utilizada con la edición SAP Business One HANA) tiene requisitos de RAM mucho más altos que las bases de datos tradicionales basadas en disco porque el conjunto de trabajo debe caber en la memoria. Los requisitos de RAM para HANA no son negociables: HANA que se queda sin memoria falla, no se degrada.

Recomendaciones de instancias en la nube

Cuando se autohospeda un ERP en AWS, Azure o GCP, seleccionar el tipo de instancia correcto es muy importante. No todas las instancias con los mismos recuentos de vCPU y RAM funcionan de manera equivalente para cargas de trabajo de bases de datos.

Recomendaciones de AWS para Odoo (aplicación + base de datos combinada, menos de 100 usuarios):

t3.xlarge (4 vCPU, 16 GB): Desarrollo y pequeña producción (menos de 25 usuarios)
r6i.xlarge (4 vCPU, 32 GB): producción pequeña y mediana (25 a 50 usuarios)
r6i.2xlarge (8 vCPU, 64 GB): producción media (50–100 usuarios)
r6i.4xlarge (16 vCPU, 128 GB): gran producción (100–200 usuarios, combinados)

Recomendaciones de AWS para Odoo (aplicación dividida/base de datos, más de 100 usuarios):

Servidor de aplicaciones: c6i.2xlarge (8 vCPU, 16 GB): optimizado para computación
Servidor de base de datos: r6i.4xlarge (16 vCPU, 128 GB) — memoria optimizada
Almacenamiento de base de datos: io2 volúmenes de EBS (IOPS aprovisionadas): 3000 a 6000 IOPS aprovisionadas

Equivalentes de Azure:

Servidor de aplicaciones: Standard_F8s_v2 (8 vCPU, 16 GB)
Servidor de base de datos: Standard_E16s_v5 (16 vCPU, 128 GB)

Equivalentes de GCP:

Servidor de aplicaciones: c2-standard-8 (8 vCPU, 32 GB)
Servidor de base de datos: n2-highmem-16 (16 vCPU, 128 GB)

La trampa del rendimiento de E/S: los volúmenes gp3 de EBS estándar en AWS proporcionan 3000 IOPS de forma predeterminada. Para una base de datos ERP de producción con más de 50 usuarios simultáneos, esto suele ser insuficiente, especialmente durante el cierre de fin de mes, cuando se ejecutan varios informes complejos simultáneamente. Utilice volúmenes de IOPS aprovisionados io2 para el almacenamiento de la base de datos, con un mínimo de 3000 IOPS aprovisionados. La diferencia de costo es significativa ($0,065/GB/mes para gp3 frente a $0,125/GB/mes para io2 más $0,065/IOPS/mes para IOPS aprovisionadas), pero la diferencia de rendimiento también es significativa.

Arquitectura de alta disponibilidad

Para los sistemas ERP de producción donde el tiempo de inactividad tiene un impacto comercial significativo, considere una arquitectura de alta disponibilidad que brinde resiliencia contra fallas de un solo servidor.

Arquitectura HA mínima para Odoo (más de 100 usuarios):

Dos servidores de aplicaciones detrás de un equilibrador de carga (sesiones por turnos o fijas)
Base de datos primaria PostgreSQL con una réplica en espera (usando replicación de streaming o AWS RDS Multi-AZ)
Clúster Redis (dos nodos) para almacenamiento de sesiones.
Almacenamiento de archivos compartido (AWS EFS o equivalente) para los datos adjuntos de archivos de Odoo

Esta arquitectura proporciona resiliencia contra cualquier falla de un solo servidor sin requerir intervención manual. La conmutación por error del PostgreSQL principal al standby es automática (usando Patroni o AWS RDS) y normalmente se completa en 30 a 60 segundos.

Objetivos de RPO y RTO para un ERP típico:

Objetivo del punto de recuperación (pérdida máxima de datos): 5 minutos (con replicación sincrónica) a 30 minutos (con replicación asíncrona)
Objetivo de tiempo de recuperación (tiempo de inactividad máximo): 30 a 60 segundos para conmutación por error automática, 15 a 30 minutos para recuperación manual

Uso de la calculadora de tamaño del servidor ECOSIRE

La Calculadora de tamaño de servidor gratuita de ECOSIRE en /tools/server-sizing-calculator automatiza el proceso de cálculo descrito anteriormente. Entradas:

Selección de plataforma ERP
Recuento total de usuarios
Porcentaje máximo de usuarios simultáneos (o estimación automática basada en el caso de uso)
Volumen de transacciones (bajo, medio, alto, muy alto)
Recuento y volumen de integración (ninguno, básico, moderado, intensivo)
Requisitos de disponibilidad (servidor único, HA, recuperación ante desastres)
Preferencia de proveedor de nube (AWS, Azure, GCP o local)

Salidas:

Especificaciones de servidor recomendadas para niveles de aplicaciones y bases de datos.
Recomendaciones específicas de instancias en la nube para su proveedor preferido
Estimación mensual de costos de infraestructura.
Proyección de crecimiento a tres años que muestra cuándo será necesario actualizar
Requisitos de IOPS de almacenamiento y nivel de almacenamiento recomendado

La calculadora está calibrada con los propios datos de implementación de producción de ECOSIRE en docenas de implementaciones de clientes, lo que hace que las estimaciones sean más confiables que la documentación del proveedor por sí sola.

Preguntas frecuentes

¿Cómo calculo el pico de usuarios simultáneos si nunca antes hemos usado ERP?

Para implementaciones totalmente nuevas sin datos históricos, utilice el 20 % del total de usuarios como estimación inicial para una implementación normal en una oficina. Si tiene varios turnos o trabaja en varias zonas horarias, utilice entre un 25% y un 30%. Luego agregue un 50% de margen de crecimiento durante los primeros dos años. Para un ERP de 100 usuarios con horario de oficina normal, planifique 20 usuarios simultáneos en un pico típico, aprovisione para 30 y desarrolle capacidad para llegar a 40 sin cambios en la infraestructura. Este enfoque de margen evita problemas de rendimiento a medida que la adopción mejora en los meses posteriores a la puesta en marcha.

¿Deberíamos ejecutar la aplicación Odoo y la base de datos en el mismo servidor o en servidores separados?

Para implementaciones de menos de 50 usuarios, un único servidor combinado suele ser suficiente: las cargas de trabajo de aplicaciones y bases de datos a esa escala no suelen entrar en conflicto. Para 50 a 100 usuarios, la decisión depende de los patrones de uso: si la base de usuarios se distribuye uniformemente a lo largo del día sin períodos pico significativos, es posible que un servidor combinado aún funcione. Si hay picos bruscos (fin de mes, cierre de turno), los servidores de aplicaciones y bases de datos separados proporcionan un mejor aislamiento. Por encima de 100 usuarios, se recomienda encarecidamente utilizar servidores independientes.

¿Qué tipo de almacenamiento deberíamos utilizar para la base de datos de Odoo?

El almacenamiento SSD es obligatorio para el directorio de datos de PostgreSQL: el disco giratorio (HDD) produce un rendimiento inaceptable en cualquier base de datos ERP de producción. En plataformas en la nube, utilice SSD IOPS aprovisionado (AWS io2, Azure Premium SSD v2, GCP Extreme Persistent Disk) para el almacenamiento de la base de datos si tiene más de 50 usuarios simultáneos. Las SSD de uso general (AWS gp3, Azure Standard SSD) son aceptables para desarrollo y pequeñas implementaciones de producción con menos de 25 usuarios simultáneos.

¿Cuánto espacio libre debemos incorporar al tamaño de nuestro servidor?

Cree un espacio libre entre un 30% y un 40% por encima de su carga máxima esperada para operaciones normales y un espacio libre del 100% (efectivamente, el doble de la capacidad máxima) para períodos excepcionales, como cierres de fin de mes o temporadas de ventas máximas. Las implementaciones en la nube pueden utilizar el escalado automático para manejar períodos excepcionales sin pagar por esa capacidad de forma permanente, una ventaja de costos significativa sobre la infraestructura fija local.

Próximos pasos

Utilice la Calculadora de tamaño de servidor gratuita de ECOSIRE en /tools/server-sizing-calculator para generar una especificación para su implementación específica. La calculadora genera una recomendación de instancia de AWS/Azure/GCP y una estimación del costo de infraestructura mensual que puede utilizar para la planificación presupuestaria.

Si está planificando una implementación de Odoo y desea que ECOSIRE se encargue del dimensionamiento y la configuración de la infraestructura junto con la implementación, la planificación de la infraestructura se incluye en cada compromiso de implementación de ECOSIRE.

Server Sizing for ERP: How to Get It Right