¿Cómo dimensionar un servidor para 100 usuarios?

Por qué "100 usuarios" no es una spec

El error más común al dimensionar es pensar en "número de usuarios" como variable única. Cien usuarios usando solo correo y archivos compartidos tienen demanda muy distinta de cien usuarios consultando ERP transaccional con base de datos de 500 GB. El dimensionamiento correcto exige primero definir el workload — qué hace el servidor — antes de calcular CPU, RAM o storage.

Los 4 perfiles típicos para empresas con ~100 usuarios

Perfil 1: Servidor de archivos + impresión + Active Directory

El caso más común para PYMEs. El servidor maneja autenticación, archivos compartidos, colas de impresión y servicios DNS/DHCP.

• CPU: 4-8 cores físicos (Intel Xeon Bronze/Silver o AMD EPYC entry)
• RAM: 16-32 GB
• Storage: 2-4 TB en RAID 5 o RAID 10. Mix SSD para sistema operativo (240-480 GB) + HDD para datos
• IOPS: bajos. SSD para SO suficiente
• Red: 2 puertos 1 Gbps o 1 puerto 10 Gbps si tienes switch capable

Perfil 2: Servidor de ERP/contabilidad (small to mid)

Sistemas como SAP Business One, Microsoft Dynamics SMB, Aspel, Contpaq, Odoo. Base de datos transaccional con consultas típicas de oficina.

• CPU: 8-16 cores físicos con clock alto (Intel Xeon Silver/Gold, AMD EPYC mid). Sí, importa el clock — bases de datos tradicionales no escalan linealmente con cores
• RAM: 32-64 GB. La base de datos quiere caché grande
• Storage: 1-2 TB NVMe en RAID 1 (mirror) o RAID 10. NVMe es no negociable para base de datos transaccional moderna
• IOPS: medios-altos. Verifica el SLA del fabricante del ERP — algunos requieren mínimos específicos
• Red: 10 Gbps recomendado

Perfil 3: Servidor de virtualización (host VMware/Hyper-V con 5-15 VMs)

Consolidación: en lugar de 5 servidores físicos, uno con 5 VMs corriendo cada workload. Modelo dominante en PYMEs modernas.

• CPU: 16-32 cores físicos con hyperthreading. Considera al menos 1 core físico por VM crítica más 2 cores para el hipervisor
• RAM: 128-256 GB. Memoria es el recurso que más limita densidad de VMs típicamente
• Storage: 4-8 TB NVMe RAID 10 o storage compartido (SAN/NAS) con 10 Gbps. Para producción, shared storage habilita HA real
• IOPS: altos. Suma demanda de todas las VMs
• Red: 2x 10 Gbps (uno para gestión/VM traffic, otro para storage)

Perfil 4: Servidor de correo + colaboración (Exchange On-Premise)

Cada vez menos común con migración a Microsoft 365 / Google Workspace, pero existe en sectores regulados.

• CPU: 8-16 cores físicos
• RAM: 64-128 GB (Exchange consume RAM agresivamente)
• Storage: 4-10 TB. Casillas típicas + archivado. Mezcla SSD para BBDD activas + HDD para archivado
• IOPS: medios. Pico durante respaldos y migraciones
• Red: 10 Gbps

Cómo calcular dimensionamiento real

CPU

Estimar carga base por usuario en el workload. Para oficina típica, 0.05-0.1 cores virtuales por usuario activo simultáneo en horas pico es referencia. Para 100 usuarios, eso significa 5-10 vCPU base + overhead del sistema operativo + servicios + headroom para picos = típicamente 8-16 cores físicos con hyperthreading.

RAM

RAM base del sistema operativo (4-8 GB Windows Server / Linux) + RAM por aplicación (varía masivamente: SQL Server quiere 25%+ del DB size, Exchange quiere 4-8 GB por mil mailboxes activos) + overhead. Sobreaprovisionar conservador es siempre mejor: agregar RAM después de la compra es relativamente fácil, pero descubrir que faltó RAM después de migrar producción es doloroso.

Storage

Capacidad bruta + 30-40% para crecimiento + overhead de RAID. Para 100 usuarios con archivos típicos de oficina, considera 20-50 GB por usuario para datos personales/compartidos. ERP suele empezar en 50-200 GB y crecer 30-50% al año. Para virtualización, suma capacidad de cada VM más overhead del hipervisor (10-15%).

IOPS y latencia

El parámetro más subestimado. SSD/NVMe modernos entregan 50K-1M IOPS según calidad. HDD entrega 100-200 IOPS por disco. Para base de datos transaccional, IOPS bajos = aplicación lenta sin importar cuántos cores tengas. Para producción crítica, NVMe siempre.

Errores frecuentes al dimensionar

• Comparar solo specs de CPU/RAM: ignorar IOPS de storage es el error más caro. Un servidor con 32 cores y 128 GB pero discos lentos da peor rendimiento que uno con 16 cores, 64 GB y NVMe
• No considerar crecimiento: dimensionar al pico actual sin margen lleva a refresh forzado en 2-3 años en lugar de 5
• Ignorar overhead del hipervisor: en virtualización, reservar 10-15% de CPU y RAM para el hipervisor
• No verificar con el fabricante del software: ERPs y bases de datos tienen requisitos formales — instalar fuera de spec puede invalidar soporte del fabricante
• Sobre-aprovisionar masivamente: el opuesto también existe — comprar servidor para 500 usuarios cuando esperas 100 es desperdicio que se nota a los 5 años cuando refresh llega y nunca lo aprovechaste

En resumen

Dimensionar servidor para 100 usuarios depende del workload. Para file/print + AD: 4-8 cores, 16-32 GB RAM, 2-4 TB storage. Para ERP/base de datos: 8-16 cores, 32-64 GB RAM, NVMe obligatorio. Para virtualización con 5-15 VMs: 16-32 cores, 128-256 GB RAM, NVMe RAID 10 o storage compartido. Para Exchange On-Premise: 8-16 cores, 64-128 GB RAM.

Reglas no negociables: dimensionar al pico esperado + 30-50% de margen, NVMe para producción transaccional, verificar specs formales con el fabricante de tu software, considerar refresh a 5 años. Y la regla maestra: antes de comprar, valida el dimensionamiento con tu integrador o un ingeniero certificado en el stack que vas a operar — el costo de equivocarse en dimensionamiento es mucho mayor que el costo de la consultoría inicial.