Dimensionar un host de virtualización: guía práctica para consolidar servidores
Cómo consolidar servidores viejos en hosts de virtualización a la medida: inventario, semanas de medición, margen, N+1, almacenamiento, licencias y un ejemplo resuelto.
Dimensionar un host de virtualización para consolidar servidores empieza por medir, no por una hoja de especificaciones: haga un inventario de cada servidor, registre durante varias semanas el uso real de CPU, memoria, almacenamiento y red, agregue margen para crecimiento y picos, y confirme que los hosts restantes pueden seguir ejecutando las cargas críticas si uno falla (N+1). Solo entonces se eligen núcleos, RAM, almacenamiento NVMe, red de 10GbE, capacidad del UPS y licencias. Esta guía recorre cada paso con una hoja de trabajo y un ejemplo resuelto.
Puntos clave
- Mida durante semanas, incluidos el cierre de mes y los días de más trabajo. Los promedios esconden los picos que causan lentitud.
- La CPU normalmente se puede compartir entre VM; la memoria de las cargas críticas no se debe sobreasignar.
- En almacenamiento, la latencia y las IOPS importan más que los terabytes. Use SSD o NVMe empresariales con protección ante pérdida de energía para las VM.
- Planifique N+1: si un host falla, los demás deben soportar todas las VM críticas.
- Windows Server se licencia por núcleo físico en cada host donde puedan correr sus VM. Incluya las licencias en el diseño, no después.
Por qué consolidar ahora el cuarto de servidores
En Miami-Dade y Broward muchas oficinas todavía tienen una fila de servidores de una sola función en un cuarto pequeño: un controlador de dominio de una década, un servidor de archivos de otra, un servidor de contabilidad o de gestión que el proveedor instaló hace años. Cada uno tiene sus propios discos, garantía, tarea de respaldo y fuente de poder. Todos suman calor a un espacio reducido, y en el sur de Florida ese cuarto muchas veces comparte pared con una oficina que ya lucha contra la humedad.
Consolidar en uno o dos hosts de virtualización reduce la cantidad de equipos que hay que parchar, respaldar y reemplazar, y hace mucho más fáciles las restauraciones y los cambios de hardware, porque una máquina virtual no depende del equipo físico que tiene debajo. El riesgo es equivocarse en el tamaño: si queda corto, todo se pone lento a fin de mes; si queda grande, paga capacidad y licencias que nunca usa.
Paso 1: inventario de servidores y dependencias
Haga una lista de cada servidor físico y de lo que hace. Para cada uno, anote:
- Funciones y aplicaciones (AD, DNS, DHCP, carpetas compartidas, SQL Server, aplicaciones de negocio, impresión).
- Sistema operativo y versión, y si todavía tiene soporte. Los sistemas sin soporte conviene reinstalarlos en lugar de copiarlos.
- Dependencias: qué aplicaciones se conectan a qué bases de datos, llaves de licencia USB, equipos seriales, escáneres que guardan en una carpeta compartida.
- Almacenamiento usado y crecimiento en los últimos años, si existe el dato.
- Quién es el responsable de la aplicación y a quién llamar en el proveedor.
Este también es el momento de decidir qué no mover: una carga que estaría mejor en Microsoft 365 o una aplicación retirada que se puede archivar.
Paso 2: medir el uso real a lo largo del tiempo
Recoja al menos dos a cuatro semanas de datos, idealmente incluyendo un cierre de mes, una corrida de nómina u otro período de alta carga. En Windows, typeperf puede registrar los contadores clave en CSV cada cinco minutos:
REM counters.txt
\Processor(_Total)\% Processor Time
\Memory\Available MBytes
\Memory\Committed Bytes
\PhysicalDisk(_Total)\Disk Transfers/sec
\PhysicalDisk(_Total)\Avg. Disk sec/Transfer
\Network Interface(*)\Bytes Total/sec
typeperf -cf counters.txt -si 300 -o C:\perf\server01.csv -f CSV
En Linux, las herramientas de sysstat (sar, iostat -x) dan la misma información. Para cada servidor anote el pico y el valor típico (percentil 95), no el promedio:
- CPU: cuántos núcleos están realmente ocupados en el pico (por ejemplo, 40 % de un servidor de 8 núcleos equivale a unos 3 núcleos ocupados, si la carga está repartida).
- Memoria: cuánta se usa de verdad en el pico. SQL Server y Exchange reservan memoria a propósito; revise los límites configurados.
- Disco: IOPS en el pico y latencia promedio por operación. Si la latencia sube en los picos, esa es la señal de alerta.
- Red: tráfico en el pico y durante los respaldos.
Tenga en cuenta que el hardware viejo, sobre todo los discos mecánicos lentos, puede hacer que los resultados se vean peores de lo que serán en los hosts nuevos. Mida de todos modos: le dice dónde está el cuello de botella.
Paso 3: entender cada recurso antes de sumar margen
CPU y la relación vCPU:pCPU
Una CPU virtual (vCPU) se ejecuta sobre un núcleo físico (pCPU) según lo programe el hipervisor. Como la mayoría de los servidores de oficina pasan casi todo el tiempo sin carga, normalmente se pueden asignar más vCPU en total que núcleos físicos. Esa relación es una decisión de diseño, no una regla fija: los controladores de dominio y servidores de impresión comparten bien, mientras que SQL Server con mucha carga, escritorio remoto o renderizado comparten mal. Dos reglas prácticas:
- Asigne a cada VM solo las vCPU que necesita. Las VM sobredimensionadas pueden rendir peor, porque el hipervisor debe encontrar suficientes núcleos libres al mismo tiempo.
- Cuando sea posible, mantenga las vCPU de una VM dentro de un solo procesador físico (nodo NUMA).
Después de la puesta en marcha, vigile las demoras de programación: el tiempo de CPU ready en VMware, %steal dentro de invitados Linux y las métricas de presión del host en Proxmox VE.
Memoria: no sobreasignar en cargas críticas
La memoria es el recurso que más a menudo se agota. Los hipervisores ofrecen técnicas para estirarla, como el ballooning (un controlador del invitado devuelve memoria que no usa), la deduplicación de páginas (KSM en Proxmox) y el uso de swap. Sirven para VM de laboratorio o de baja prioridad, pero bajo presión ralentizan todo. Para controladores de dominio, bases de datos y servidores de negocio, planifique RAM real para el pico de cada VM, más la memoria del propio host. Si usa ZFS en Proxmox VE, su caché ARC también vive en la RAM del host: fije su límite a propósito e inclúyalo en el plan. Los invitados Windows necesitan el controlador VirtIO balloon para que el ballooning funcione.
Almacenamiento: primero latencia e IOPS, después capacidad
La capacidad es fácil de comprar; el rendimiento es lo que sienten los usuarios. Varias VM sobre los mismos discos generan una carga aleatoria y mezclada que los discos mecánicos manejan mal.
| Medio | Conviene para | Notas |
|---|---|---|
| SSD NVMe (empresarial) | Discos de VM, bases de datos, todo lo sensible a latencia | Prefiera unidades con protección ante pérdida de energía (PLP) y resistencia adecuada |
| SSD SATA/SAS (empresarial) | Discos de VM con cargas más livianas | Mucho mejor que HDD para operaciones aleatorias |
| HDD (7.200 rpm) | Respaldos, archivo, carpetas grandes y poco usadas | No para discos de arranque de VM en un host consolidado |
Use arreglos en espejo (RAID 10 o espejos ZFS) para el almacenamiento de las VM: se reconstruyen más rápido y manejan mejor las escrituras aleatorias que los arreglos con paridad. Deje espacio libre para instantáneas y, en ZFS, para que el rendimiento se mantenga estable a medida que se llena el pool. Evite SSD de consumo sin protección ante pérdida de energía para las VM; las escrituras síncronas y el desgaste son su punto débil.
Red: 10GbE y rutas separadas
Consolidar concentra el tráfico. Planifique 10GbE (SFP+ o 10GBASE-T) entre hosts, almacenamiento y el switch principal, y separe el tráfico con VLAN o puertos dedicados: administración, tráfico de VM, almacenamiento o replicación y respaldos. En un clúster de Proxmox VE, dé a la comunicación del clúster (corosync) su propio enlace para que un respaldo pesado no la interrumpa.
Paso 4: sumar margen y planificar N+1
El margen cubre el crecimiento durante la vida útil del hardware (normalmente varios años), aplicaciones nuevas y picos que no se capturaron. Elija un factor de planificación según los planes del negocio (contrataciones, nuevas oficinas, un sistema de gestión nuevo) y deje escrita la suposición.
N+1 significa que si un host falla o está en mantenimiento, los demás pueden seguir ejecutando todas las VM críticas. Con dos hosts, cada uno debe poder cargar solo con todas las cargas críticas. Para la conmutación automática en un clúster de Proxmox VE se necesita quórum: tres nodos, o dos nodos más un QDevice. Un diseño más simple de dos hosts puede usar replicación del almacenamiento con recuperación manual o semiautomática, algo que encaja bien en muchas oficinas pequeñas. Nuestro servicio de virtualización con Proxmox diseña ambas opciones.
Paso 5: un ejemplo resuelto (cargas hipotéticas)
Las cifras siguientes son inventadas para mostrar el método; no son valores típicos. Reemplácelas por sus propias mediciones.
| VM | Núcleos ocupados en el pico | RAM en el pico | vCPU planificadas | RAM planificada | Almacenamiento usado | ¿Crítica? |
|---|---|---|---|---|---|---|
| DC1 (AD, DNS, DHCP) | 0,5 | 3 GB | 2 | 4 GB | 60 GB | Sí |
| DC2 (nuevo, para redundancia) | n/d | n/d | 2 | 4 GB | 60 GB | Sí |
| Servidor de archivos | 1 | 6 GB | 2 | 8 GB | 1,5 TB | Sí |
| App contable + SQL Server | 3 | 20 GB | 4 | 24 GB | 300 GB | Sí |
| Host de escritorio remoto | 4 | 28 GB | 8 | 32 GB | 200 GB | Sí |
| Impresión y utilidades (Linux) | 0,3 | 1,5 GB | 2 | 2 GB | 40 GB | No |
| Total | unos 9 | 20 | 74 GB | unos 2,2 TB |
Aplicando el método:
- Margen. En este ejemplo suponemos un 30 % de crecimiento durante la vida del hardware. RAM: 74 GB × 1,3 ≈ 96 GB, más unos 16 GB para el hipervisor y la caché de ZFS ≈ 112 GB → elegimos 128 GB por host. Núcleos ocupados: 9 × 1,3 ≈ 12 en el pico → una CPU de 16 núcleos por host deja espacio, con una relación vCPU:pCPU cómoda de 20:16.
- Almacenamiento. 2,2 TB × 1,3 ≈ 2,9 TB, más espacio libre para instantáneas y la salud del pool → planifique unos 4 TB útiles o más, por ejemplo cuatro unidades NVMe empresariales en dos espejos.
- N+1. Todas las VM menos la de impresión son críticas, así que ambos hosts llevan la misma configuración y cualquiera puede ejecutar todo durante una falla o un mantenimiento.
- Red. Dos puertos de 10GbE por host (VM y administración en uno, replicación y respaldos en el otro) más un enlace aparte para el tráfico del clúster.
- Respaldo. Un servidor de respaldo separado o Proxmox Backup Server con sus propios discos, más una copia fuera de la oficina. Vea nuestra guía de Proxmox Backup Server y la estrategia de respaldo 3-2-1.
Licencias: planifíquelas junto con el hardware
Windows Server Standard y Datacenter se licencian por núcleo físico del host, con mínimos por procesador y por servidor, más licencias de acceso de cliente (CAL) por usuario o por dispositivo. Standard cubre un número limitado de VM con Windows Server por host completamente licenciado y se puede "apilar" para cubrir más; Datacenter cubre VM ilimitadas de Windows Server en ese host. Dos consecuencias para el dimensionamiento:
- Más núcleos de los necesarios significan más licencias de núcleo. No compre una CPU con muchos núcleos "por si acaso" sin calcular el efecto en las licencias.
- Con N+1, cada host donde pueda correr una VM de Windows debe estar licenciado para ella. El host de respaldo no es gratis.
SQL Server, los servicios de escritorio remoto (RDS CAL) y algunas aplicaciones de negocio tienen sus propias reglas. Los términos de licenciamiento cambian, así que confirme el conteo con su proveedor de licencias antes de pedir el hardware.
Energía, UPS y calor en un cuarto pequeño
- UPS: dimensiónelo con el consumo medido de los hosts nuevos, el switch y el almacenamiento, no con la etiqueta de las fuentes de poder, y elija una autonomía suficiente para un apagado ordenado. Configure el apagado automático con el software del fabricante del UPS o con Network UPS Tools (NUT) en Proxmox VE, y pruébelo.
- Calor: cada vatio se convierte en calor. Vatios × 3,412 da BTU por hora, un dato que su contratista de aire acondicionado puede usar para decidir si el cuarto necesita enfriamiento o ventilación dedicados.
- Temporada de tormentas: los cortes breves y las bajas de voltaje son comunes durante las tormentas del sur de Florida. Planifique el apagado ordenado y el orden de arranque (almacenamiento y controladores de dominio primero) y mantenga una copia de respaldo fuera de la oficina por si no se puede llegar a ella.
La consolidación suele reducir el calor y el consumo comparada con una fila de servidores viejos, pero mídalo después de la puesta en marcha en lugar de darlo por hecho.
Errores comunes
- Dimensionar con promedios en lugar de picos.
- Dar 8 vCPU a cada VM "por las dudas".
- Sobreasignar RAM en el servidor de base de datos.
- Comprar discos grandes y lentos para las VM porque la capacidad se veía bien.
- Olvidar que el host de respaldo también debe tener licencias y tamaño suficiente.
- Copiar tal cual (P2V) un sistema operativo sin soporte en lugar de reinstalar la función en una versión con soporte.
Preguntas frecuentes
¿Uno o dos hosts?
Un host es más simple, pero no tiene redundancia de hardware: si falla, todo se detiene hasta repararlo o restaurarlo. Dos hosts con replicación, o un clúster de tres nodos, mantienen funcionando los sistemas críticos. La elección depende de cuánto tiempo puede tolerar el negocio una interrupción.
¿Podemos reutilizar nuestros servidores actuales como hosts?
A veces, si son recientes, tienen garantía y son compatibles con el hipervisor. A menudo los servidores más viejos son justamente los que se reemplazan por confiabilidad, así que úselos solo para funciones no críticas o pruebas.
¿Proxmox VE, VMware o Hyper-V?
Los tres pueden alojar estas cargas. Normalmente deciden las licencias, la experiencia del equipo y las herramientas de respaldo. Vea Proxmox vs VMware para pequeñas empresas.
¿Algunos servidores deberían ir a la nube?
Sí, cuando la carga encaja mejor allí, por ejemplo el correo y la colaboración de archivos en Microsoft 365. Las aplicaciones locales sensibles a la latencia y las carpetas compartidas muy grandes suelen quedarse en la oficina. Nuestra página de servidores en la nube y dedicados explica las opciones híbridas.
Pida una revisión de dimensionamiento
Core Florida IT mide, dimensiona y migra cuartos de servidores para oficinas en Miami, Doral, Fort Lauderdale y todo el sur de Florida, y da soporte remoto en todo Estados Unidos. Solicite una evaluación de TI gratuita y empezamos con un inventario y un plan de medición para sus servidores.
