Servidores AMD EPYC para virtualización: VMware, Proxmox, Hyper-V y una alternativa a VMware tras el crecimiento de las licencias.

Los servidores AMD EPYC son una excelente opción para la virtualización cuando se necesita ejecutar muchas máquinas virtuales en un menor número de nodos físicos sin alcanzar demasiado pronto los límites de procesador, memoria, almacenamiento o red. Sin embargo, no se puede elegir un servidor de este tipo únicamente por el número de núcleos: con VMware es especialmente importante calcular las licencias; con Proxmox, la arquitectura de almacenamiento y las competencias del equipo; y con Hyper-V, la relación con Windows Server y el licenciamiento de Microsoft.

La mejor opción no es el EPYC más potente «por si acaso», sino una configuración equilibrada, diseñada para máquinas virtuales reales, tolerancia a fallos, copias de seguridad y un plan de crecimiento para los próximos años.

También conviene tener en cuenta otro aspecto importante: si se planea migrar de una plataforma a otra o desde plataformas basadas en Intel, copiar simplemente los archivos de las máquinas virtuales puede no ser suficiente para que arranquen. Puede ser necesaria una conversión o una reinstalación. En algunos casos, también puede verse afectado el licenciamiento del software dentro de las máquinas virtuales, por lo que las pruebas son obligatorias en estos escenarios.

Servers powered by AMD EPYC processors

Por qué se suele elegir AMD EPYC para la virtualización

La virtualización necesita una reserva de recursos predecible. Un solo servidor físico puede tener que atender simultáneamente decenas o cientos de máquinas virtuales: algunas permanecen casi inactivas, otras acceden constantemente al almacenamiento, algunas requieren grandes cantidades de RAM y otras generan picos de carga en el procesador.

AMD EPYC encaja bien en estas cargas de trabajo por varias razones:

• muchos núcleos físicos en un solo procesador;
• compatibilidad con grandes cantidades de memoria RAM;
• un gran número de líneas PCIe para unidades NVMe, adaptadores de red y controladoras;
• posibilidad de crear servidores de uno o dos sockets;
• alta densidad de recursos por nodo físico.

Los procesadores AMD EPYC 9005 actuales, por ejemplo, están disponibles en configuraciones de hasta 192 núcleos en una sola CPU, lo que demuestra la elevada densidad de cálculo que puede ofrecer una plataforma de servidor. Sin embargo, en virtualización esta ventaja debe utilizarse con cuidado: si el servidor tiene muchísimos núcleos, pero poca memoria o un almacenamiento lento, no podrá ejecutar de forma eficiente un gran número de máquinas virtuales. Las especificaciones de la generación EPYC 9005 se pueden consultar en la página oficial de AMD EPYC 9005.

Por tanto, un servidor AMD EPYC para virtualización no debe considerarse simplemente como «un procesador más un chasis», sino como una plataforma completa. El procesador, la memoria, el almacenamiento, las interfaces de red, el hipervisor, el sistema de copias de seguridad y las licencias deben seleccionarse de forma conjunta.

Qué es más importante que el número de núcleos en la virtualización

Un gran número de núcleos es una ventaja clara de EPYC, pero no resuelve por sí solo todos los problemas. En una infraestructura real, el cuello de botella suele aparecer donde menos se espera.

Memoria

Los recursos de CPU se pueden sobreasignar moderadamente porque no todas las máquinas virtuales utilizan de forma continua todos los núcleos virtuales que tienen asignados. Con la memoria resulta más difícil hacerlo de forma segura. Si las máquinas virtuales necesitan realmente entre 700 y 800 GB de RAM, un servidor con 512 GB funcionará bien solo en una presentación, no en producción.

Para una virtualización densa, normalmente conviene reservar capacidad para:

• el crecimiento del número de máquinas virtuales;
• los picos temporales de carga;
• el fallo de un nodo del clúster;
• la sobrecarga del hipervisor;
• las operaciones de copia de seguridad y migración.

En servidores AMD EPYC suelen ser razonables las configuraciones con entre 512 GB y 1–2 TB de memoria por nodo. Los clústeres grandes, las bases de datos, los servidores de escritorio remoto y las nubes privadas pueden requerir aún más.

Subsistema de almacenamiento

Las máquinas virtuales rara vez mantienen el procesador totalmente cargado de forma continua, pero casi siempre acceden al almacenamiento. Cuando decenas de sistemas escriben registros, actualizan bases de datos, procesan solicitudes de usuarios y crean copias de seguridad al mismo tiempo, el subsistema de almacenamiento se vuelve crítico.

En virtualización, no solo importan los terabytes, sino también:

• las operaciones de entrada/salida por segundo;
• la latencia;
• la resistencia de escritura de los SSD;
• la tolerancia a fallos del conjunto;
• la capacidad de restaurar rápidamente una máquina virtual;
• la separación entre los datos de producción y las copias de seguridad.

NVMe resulta especialmente útil para bases de datos, servidores de escritorio remoto, infraestructuras de escritorios virtuales, sistemas analíticos y cualquier carga de trabajo en la que la latencia del almacenamiento afecte directamente al usuario. Sin embargo, las unidades rápidas requieren una red adecuada y una arquitectura de almacenamiento bien diseñada. De lo contrario, las unidades NVMe quedarán infrautilizadas mientras la infraestructura sigue limitada por un enlace de red o una controladora.

Red

Para un servidor independiente, 10 GbE puede ser suficiente en algunos casos. Para un clúster con migración en vivo, almacenamiento compartido y copias de seguridad, puede no bastar. En las configuraciones modernas de virtualización, 25 GbE suele ser una base más razonable, mientras que 100 GbE se utiliza en clústeres densos, almacenamiento definido por software y migraciones de gran volumen.

Es recomendable separar de antemano los siguientes tipos de tráfico:

• gestión del hipervisor;
• tráfico de las máquinas virtuales;
• migraciones entre nodos;
• acceso al almacenamiento;
• tráfico de copias de seguridad;
• redes externas de clientes.

Cuanto mayor sea la densidad de máquinas virtuales por nodo, menor será el margen de error en la arquitectura de red.

VMware sobre AMD EPYC: una plataforma madura con un nuevo modelo de costes

VMware vSphere sigue siendo una plataforma sólida para la virtualización empresarial. Se elige por sus herramientas de gestión maduras, su amplio ecosistema, sus clústeres de alta disponibilidad, la migración en vivo de máquinas virtuales y la integración con copias de seguridad, monitorización y procesos corporativos.

Para las empresas que llevan muchos años utilizando VMware, migrar a otra plataforma no siempre está justificado. Si la infraestructura es crítica para el negocio, el equipo domina vSphere y existen procesos consolidados de mantenimiento, monitorización y recuperación, conservar VMware puede ser la opción más segura.

Sin embargo, tras la integración de VMware en Broadcom, muchas empresas tuvieron que recalcular el coste total de propiedad. Broadcom anunció oficialmente la transición de VMware by Broadcom a un modelo de suscripción y el fin de la venta de licencias perpetuas. Esto no significa que VMware deba sustituirse de inmediato en todos los casos, pero sí que los cálculos anteriores no pueden trasladarse automáticamente a un nuevo periodo de compra. Los cambios se describen en el material oficial de Broadcom sobre la transformación de la cartera de VMware.

Esto es especialmente importante para AMD EPYC. Estos procesadores ofrecen una alta densidad de núcleos, pero si el licenciamiento se calcula por núcleo físico o está vinculado a paquetes de suscripción, el procesador con más núcleos no siempre es el más rentable. En algunos escenarios, la alta densidad reduce el número de servidores, racks, puertos de red y el consumo energético. En otros, aumenta la parte del presupuesto destinada a licencias.

Antes de comprar un servidor EPYC para VMware, hay que calcular:

• cuántos núcleos físicos deberán licenciarse;
• qué ediciones y paquetes de VMware son necesarios;
• si se requieren componentes adicionales de gestión, almacenamiento y monitorización;
• cuántos nodos tendrá el clúster;
• qué reserva de capacidad se necesita para soportar el fallo de un nodo;
• qué versiones de ESXi son compatibles con el servidor elegido;
• si las controladoras, los adaptadores de red y las unidades son compatibles.

Para VMware, especialmente cuando se planea utilizar vSAN, también es importante comprobar la compatibilidad del hardware con las listas actualizadas de Broadcom/VMware. Esto es especialmente relevante para las nuevas generaciones de procesadores, adaptadores de red, controladoras NVMe y servidores que se prevé utilizar durante varios años. La documentación de Broadcom describe por separado el licenciamiento de VMware vSphere Foundation mediante una licencia de solución, por lo que durante el diseño conviene revisar tanto las especificaciones técnicas como el modelo de suministro vigente.

En la práctica, esto cambia la forma de elegir un servidor. Para VMware, un procesador con menos núcleos, mayor frecuencia y suficiente capacidad de memoria puede resultar a veces más económico que la configuración EPYC más grande, cuyo coste de licencias puede aumentar más rápido que el beneficio de rendimiento que aporta en cargas reales.

Proxmox VE sobre AMD EPYC: una alternativa popular a VMware

Proxmox VE se considera a menudo una alternativa a VMware, especialmente después de revisar los costes de licenciamiento. Es una plataforma basada en Linux que utiliza KVM para las máquinas virtuales y LXC para los contenedores, ofrece una interfaz web, admite clústeres, migración, distintos tipos de almacenamiento e integración con Proxmox Backup Server. La documentación oficial de Proxmox VE la describe como una plataforma para máquinas virtuales y contenedores basada en Debian GNU/Linux.

Proxmox funciona especialmente bien en servidores AMD EPYC en varios escenarios:

• pequeñas y medianas empresas para las que VMware se ha vuelto demasiado caro;
• entornos de hosting y nube privada;
• entornos de prueba y laboratorio;
• infraestructuras con un gran número de servidores Linux;
• clústeres con almacenamiento NVMe e interfaces de red de alta velocidad;
• proyectos que requieren flexibilidad y menor dependencia de un único proveedor.

Entre los puntos fuertes de Proxmox se encuentran:

• la ausencia de la tarifa tradicional «por núcleo físico» utilizada por algunas plataformas comerciales y la posibilidad de usar el producto sin una suscripción de pago como software de código abierto;
• una interfaz web cómoda para la administración básica;
• compatibilidad con clústeres;
• migración en vivo de máquinas virtuales cuando la arquitectura de almacenamiento está correctamente diseñada;
• compatibilidad integrada con ZFS, Ceph, NFS, iSCSI y otras opciones de almacenamiento;
• compatibilidad con contenedores;
• una solución de copias de seguridad independiente.

Sin embargo, Proxmox no debe considerarse una sustitución gratuita de VMware sin contrapartidas. Los costes pueden aparecer en otros ámbitos: implantación, formación del equipo, configuración del almacenamiento, copias de seguridad, monitorización, migración y soporte. Si los administradores solo han trabajado anteriormente con VMware, necesitarán tiempo para aprender los conceptos de Linux, los puentes de red, la gestión del almacenamiento, las actualizaciones y el diagnóstico.

Esto es especialmente relevante con AMD EPYC: un servidor potente puede alojar muchas máquinas virtuales, pero cualquier error de diseño en el almacenamiento o la red se amplificará con esa densidad. Cuantas más máquinas virtuales se ejecuten en un nodo, más costosa será una interrupción y más importante será probar de antemano la tolerancia a fallos.

La migración de VMware a Proxmox se realiza mejor de forma gradual:

1. Desplegar un clúster piloto.
2. Migrar varias máquinas virtuales no críticas.
3. Probar el rendimiento del almacenamiento y de la red, incluidas las pruebas de carga.
4. Configurar las copias de seguridad y la recuperación.
5. Realizar simulacros de fallo y documentar cómo se comporta el clúster durante una interrupción completa o parcial, incluidos los posibles problemas de recuperación.
6. Comprobar la monitorización y las alertas.
7. Solo después migrar los servicios de producción.

Si el objetivo es reducir la dependencia de VMware aprovechando al mismo tiempo las ventajas de AMD EPYC, Proxmox puede ser una opción razonable. Sin embargo, exige la misma disciplina en la arquitectura y el diseño que una plataforma comercial.

Hyper-V sobre AMD EPYC: cuándo es una opción racional

Hyper-V debe considerarse principalmente en empresas que ya utilizan Windows Server, Active Directory, Microsoft SQL Server, Windows Admin Center y otros productos de Microsoft. En este entorno, Hyper-V puede ser una prolongación lógica de la infraestructura existente, no una solución de compromiso.

Microsoft describe Hyper-V como una tecnología de virtualización de Windows Server capaz de ejecutar máquinas virtuales Windows y Linux a gran escala. La documentación también cubre los clústeres de conmutación por error, los volúmenes compartidos de clúster y la migración en vivo.

Hyper-V puede ser especialmente apropiado cuando:

• la mayoría de las máquinas virtuales ejecutan Windows Server;
• ya se han adquirido o se prevé adquirir licencias de Windows Server Datacenter;
• el equipo tiene una sólida experiencia en infraestructuras Microsoft;
• se utiliza Active Directory;
• resulta conveniente administrar mediante Windows Admin Center o System Center;
• se requiere integración con las políticas existentes de seguridad y administración.

Hyper-V no debe considerarse «VMware gratis». Existe una edición gratuita limitada, pero la oferta más madura es de pago, aunque normalmente resulta menos costosa de operar que VMware. La rentabilidad depende del licenciamiento de Windows Server, del número de núcleos físicos, de la edición Standard o Datacenter y del número de máquinas virtuales Windows. Para algunas empresas es rentable; para otras, no.

Hyper-V puede funcionar de forma eficiente sobre AMD EPYC, pero se aplican las mismas limitaciones de diseño que con otros hipervisores:

• cantidad suficiente de RAM;
• almacenamiento rápido;
• interfaces de red para el tráfico de migración y almacenamiento;
• compatibilidad de controladores;
• un clúster correctamente diseñado;
• copias de seguridad separadas de los datos de producción.

Hyper-V es especialmente adecuado cuando la virtualización forma parte de un entorno Microsoft y no es una plataforma independiente. Si la infraestructura es mixta, incluye muchos sistemas Linux, utiliza redes no estándar y depende ampliamente de herramientas abiertas, Proxmox puede resultar más cómodo. Si es esencial disponer de un ecosistema empresarial maduro y la organización ya cuenta con una amplia experiencia en VMware, vSphere puede seguir siendo la opción preferible.

VMware, Proxmox y Hyper-V sobre AMD EPYC

La elección del hipervisor no debe comenzar con la pregunta «¿qué opción es más barata?». Primero hay que determinar qué máquinas virtuales deben mantenerse, qué nivel de inactividad es aceptable, quién administrará la plataforma y con qué rapidez deberá recuperarse la empresa después de una incidencia. Solo entonces conviene comparar los costes de licencias y soporte.

AMD EPYC Servers

Cómo elegir un servidor AMD EPYC para virtualización

Hay que empezar no por el modelo de procesador, sino por un inventario de las máquinas virtuales. Un servidor se compra para una carga de trabajo concreta, no por su número de núcleos.

Antes de elegir una configuración, es necesario determinar:

• cuántas máquinas virtuales se ejecutan actualmente;
• cuántas se necesitarán dentro de dos o tres años;
• qué sistemas son críticos para el negocio;
• qué máquinas funcionan bajo carga constante;
• qué cargas consumen grandes cantidades de memoria;
• qué cargas generan muchas escrituras en el almacenamiento;
• qué sistemas requieren una recuperación rápida;
• qué sistemas pueden detenerse temporalmente durante una incidencia;
• qué sistemas no deben detenerse nunca.

Solo después se debe pasar a la selección del hardware.

Procesador

Para servicios de oficina estándar, pequeños sistemas web, controladores de dominio y máquinas virtuales auxiliares, es aceptable una sobreasignación moderada de CPU. No todas las máquinas virtuales utilizan simultáneamente todos los núcleos virtuales que tienen asignados.

Los sistemas sometidos a cargas elevadas requieren una reserva mucho mayor. Entre ellos se incluyen:

• bases de datos;
• servidores de escritorio remoto;
• 1C y otros sistemas contables;
• infraestructuras de escritorios virtuales;
• servicios analíticos;
• sistemas de videovigilancia;
• servidores de correo;
• aplicaciones web de alta carga.

No basta con sumar todos los núcleos virtuales y comprar el mismo número de núcleos físicos. Hay que considerar la utilización real, los picos, el perfil de carga y los requisitos de tolerancia a fallos. Si el clúster debe soportar el fallo de un nodo, los servidores restantes deben poder absorber sus máquinas virtuales sin una pérdida crítica de rendimiento.

Memoria

En virtualización, la memoria suele ser más importante que el procesador. Un servidor con 96 núcleos y 256 GB de RAM puede estar desequilibrado: la CPU todavía dispone de capacidad libre, pero ya no queda memoria para nuevas máquinas virtuales.

Para una infraestructura de producción, normalmente se recomienda una reserva de al menos el 20–30 %. En un clúster, esta capacidad se necesita no solo para el crecimiento, sino también para trasladar máquinas virtuales de emergencia. Si todos los nodos están casi totalmente utilizados, la tolerancia a fallos solo existe en el diagrama de arquitectura.

Los servidores AMD EPYC suelen configurarse con un amplio margen de memoria: 512 GB, 1 TB, 2 TB o más. Esto es especialmente importante para plataformas de virtualización, bases de datos, servidores de escritorio remoto y nubes privadas.

Almacenamiento

Al seleccionar las unidades, conviene separar tres tareas distintas:

1. Almacenamiento de las máquinas virtuales.
2. Almacenamiento de las copias de seguridad.
3. Operaciones de servicio como registros, migraciones, datos temporales y replicación.

Los SSD con interfaces SAS o SATA pueden ser suficientes para cargas moderadas. Para virtualización densa, bases de datos, servidores de escritorio remoto y entornos de usuarios activos, es preferible NVMe. Si el servidor forma parte de un clúster, hay que decidir de antemano si el almacenamiento será local, compartido o definido por software.

Un punto importante: las copias de seguridad no pueden considerarse fiables si se almacenan únicamente en el mismo conjunto que las máquinas virtuales. Un fallo del conjunto, un error del administrador, un ataque o una corrupción de datos pueden destruir simultáneamente tanto el entorno de producción como sus copias de seguridad.

Red

Para un nodo independiente con poca carga, 10 GbE todavía puede ser suficiente. Para un clúster es mejor considerar 25 GbE desde el principio, especialmente si se prevén:

• migración en vivo de máquinas virtuales;
• almacenamiento centralizado;
• Ceph, vSAN, Storage Spaces Direct o arquitecturas similares;
• copias de seguridad durante el horario laboral;
• un gran número de máquinas virtuales por nodo.

100 GbE tiene sentido para clústeres densos, plataformas de proveedores de servicios, almacenamiento NVMe y escenarios en los que la red se convierte en parte del subsistema de almacenamiento.

Para parques de servidores modernos, Dell PowerEdge 16G y Dell PowerEdge 17G también pueden servir como referencia en cuanto a generación de plataforma, densidad de memoria, compatibilidad con interfaces de alta velocidad y posibilidades de expansión. La elección final debe seguir basándose en el perfil de carga, no en el nombre de la línea de producto.

Ejemplos de configuraciones AMD EPYC para distintos escenarios

Estas configuraciones no son normas universales. Diez máquinas virtuales con bases de datos pueden generar más carga en un servidor que cien máquinas auxiliares con poca actividad. Antes de comprar, hay que analizar no solo el número de máquinas virtuales, sino también su comportamiento: uso de memoria, actividad de almacenamiento, tráfico de red, picos y requisitos de recuperación.

Las licencias pueden cambiar todo el cálculo

AMD EPYC suele ayudar a reducir el número de servidores físicos. Un nodo potente puede sustituir varias máquinas antiguas, simplificar el rack, reducir el número de puertos de red y disminuir el consumo energético. Sin embargo, el licenciamiento por núcleo físico o por paquete de suscripción complica el cálculo.

En un entorno VMware, un procesador con muchos núcleos debe evaluarse con especial atención. Elegir el EPYC más grande disponible solo porque existe puede obligar a la empresa a pagar por núcleos sobrantes mientras las máquinas virtuales reales están limitadas por la memoria o el almacenamiento.

Hyper-V sigue un modelo económico diferente. Hay que evaluar las licencias de Windows Server, la edición Standard o Datacenter y los derechos para ejecutar instancias virtuales. Datacenter puede estar económicamente justificado cuando la mayoría de los sistemas ejecutan Windows Server. En un entorno mixto, el cálculo final puede ser menos evidente.

Proxmox no utiliza el mismo modelo de cobro por núcleo físico, pero eso no hace que el proyecto sea gratuito. Deben tenerse en cuenta los siguientes costes:

• implantación;
• formación del equipo;
• soporte;
• monitorización;
• configuración de las copias de seguridad;
• migración;
• pruebas de tolerancia a fallos;
• documentación y operación continua.

A veces una licencia más cara resulta más barata que un error de migración. En otros casos, abandonar la plataforma anterior genera un ahorro considerable a lo largo de varios años. Por tanto, la cifra final debe calcularse como coste total de propiedad, no como el precio aislado del servidor o de la suscripción.

Tolerancia a fallos, copias de seguridad y migración

La virtualización proporciona flexibilidad, pero no elimina la necesidad de una arquitectura sólida. Si un único servidor potente ejecuta todas las máquinas virtuales de la empresa, se convierte en un punto único de fallo. AMD EPYC permite consolidar una gran carga en un solo nodo, pero esto no siempre beneficia a la fiabilidad.

Clúster

La infraestructura de producción suele requerir un clúster. Dos nodos pueden ser un punto de partida, pero tres suelen ser mejores para un diseño más resistente. Un tercer nodo o un testigo independiente ayuda al clúster a tomar decisiones correctas durante fallos de comunicación e interrupciones.

Al diseñar un clúster:

• no hay que llenar cada nodo hasta el límite;
• se debe reservar capacidad para el fallo de un servidor;
• conviene utilizar procesadores de generaciones similares;
• hay que diseñar cuidadosamente el almacenamiento compartido o distribuido;
• se deben separar las redes de gestión, almacenamiento y migración;
• hay que probar la migración de máquinas virtuales antes de una incidencia, no después.

Si un clúster consta de dos servidores EPYC potentes, cada uno debe poder alojar temporalmente las máquinas virtuales críticas del otro nodo. De lo contrario, la tolerancia a fallos declarada solo existirá sobre el papel.

Copias de seguridad

Una instantánea no es una copia de seguridad. Una instantánea permite volver rápidamente a un estado anterior antes de una actualización o un cambio de configuración, pero no protege frente a la pérdida de todo el sistema de almacenamiento, un error del administrador, el cifrado por ransomware o la corrupción del conjunto.

La virtualización requiere copias de seguridad independientes:

• en otro sistema de almacenamiento;
• con una recuperación verificada;
• con un periodo de retención claramente definido;
• con protección frente al borrado o el cifrado;
• con pruebas periódicas de recuperación de al menos una parte de las máquinas virtuales.

Los entornos VMware suelen utilizar Veeam y otras soluciones comerciales. Para Proxmox se puede considerar Proxmox Backup Server. Hyper-V puede utilizar herramientas de Microsoft y sistemas de copia de seguridad de terceros. El nombre del producto es menos importante que la capacidad demostrada de restaurar el servicio dentro del plazo requerido.

Migración desde VMware

Migrar de VMware a Proxmox o Hyper-V no consiste simplemente en convertir archivos de discos virtuales. Hay que tener en cuenta los controladores, la configuración de red, los tipos de controladoras de disco, los cargadores de arranque, los agentes del sistema invitado, las copias de seguridad, la monitorización y el orden de inicio de los servicios.

Un proceso seguro suele ser el siguiente:

1. Migrar primero las máquinas virtuales no críticas.
2. Comprobar el arranque, la conectividad de red, el rendimiento y las copias de seguridad.
3. Configurar la monitorización.
4. Documentar el proceso de reversión.
5. Solo entonces planificar la migración de los sistemas de producción.
6. Mantener disponible la plataforma anterior hasta completar el piloto.

Si la empresa cambia simultáneamente los servidores, el hipervisor y la arquitectura de almacenamiento, el proyecto se vuelve más complejo. En ese caso, conviene dividir los cambios en etapas: desplegar primero la nueva plataforma de servidores, después el hipervisor de prueba y, por último, migrar una parte de la carga.

Cuándo tiene sentido seguir con VMware

Mantener VMware es razonable cuando la plataforma ya es estable y el coste de la suscripción resulta aceptable frente a los riesgos de migración. Esto es especialmente relevante cuando la virtualización soporta sistemas críticos como ERP, bases de datos, facturación, servicios de producción, granjas de escritorios remotos, aplicaciones médicas o financieras.

VMware puede ser preferible cuando:

• el equipo tiene una amplia experiencia con vSphere;
• las copias de seguridad y la monitorización ya están configuradas;
• se utilizan arquitecturas de red complejas;
• ya existen SAN, vSAN o procesos de almacenamiento maduros;
• se necesita minimizar al máximo el riesgo de cambios;
• el coste de la inactividad es superior al ahorro potencial;
• deben cumplirse requisitos corporativos de soporte y certificación.

En este escenario, AMD EPYC puede seguir siendo una excelente plataforma de servidor. Simplemente hay que elegir el procesador teniendo en cuenta el licenciamiento. Menos núcleos físicos, más memoria y almacenamiento NVMe rápido pueden ser preferibles a la máxima densidad de núcleos si esta aporta poco beneficio práctico a las máquinas virtuales.

Cuándo considerar alternativas a VMware

Las alternativas deben evaluarse cuando los costes de VMware se han vuelto desproporcionados respecto al tamaño de la infraestructura o están limitando su crecimiento. Esto es especialmente relevante para pequeñas y medianas empresas, proveedores de hosting, entornos de laboratorio y organizaciones que no dependen en gran medida de funciones específicas de VMware.

Proxmox puede ser una buena opción cuando:

• el equipo está preparado para trabajar con infraestructura Linux;
• se necesita flexibilidad en el almacenamiento;
• es importante ahorrar en licencias;
• hay tiempo para realizar un proyecto piloto;
• la infraestructura no depende de funciones poco comunes y específicas de VMware;
• es necesario crear una nube privada o una plataforma de hosting.

Hyper-V puede ser más lógico cuando:

• la mayoría de los servicios se ejecutan en Windows;
• la empresa ya compra Windows Server Datacenter;
• la administración está centrada en tecnologías Microsoft;
• el equipo tiene experiencia con los clústeres de conmutación por error de Windows;
• es importante la integración con Active Directory y Windows Admin Center.

Abandonar VMware no debe ser una decisión emocional. Ahorrar en licencias y, al mismo tiempo, perder capacidad de gestión, copias de seguridad fiables o una recuperación predecible puede generar un coste total mayor.

AMD EPYC Servers

Servidor AMD EPYC de uno o dos sockets

Dell PowerEdge R7625, servidor rack 2U.

Fuente de la imagen: dell.com

Una pregunta menos evidente es si realmente se necesita un servidor de dos procesadores. En el pasado, las grandes instalaciones de virtualización solían recurrir por defecto a sistemas de dos sockets. Con AMD EPYC, esto no siempre es necesario.

Un servidor EPYC de un solo socket puede ser ventajoso cuando:

• un procesador proporciona suficientes núcleos;
• hay suficientes ranuras de memoria;
• hay suficientes líneas PCIe;
• se prefiere una arquitectura más sencilla;
• el consumo energético y la generación de calor son importantes;
• se necesita reducir la complejidad y los posibles costes de licenciamiento.

Se necesita un servidor de dos sockets cuando:

• se requiere la máxima capacidad de memoria posible;
• se necesitan muchas unidades NVMe y tarjetas de expansión;
• es importante alcanzar la máxima densidad de máquinas virtuales;
• el servidor formará parte de un clúster grande;
• la carga escala de forma eficiente entre dos procesadores.

En una configuración de dos sockets, debe tenerse en cuenta NUMA. En términos sencillos, la memoria y los núcleos dentro del servidor no siempre están a la misma distancia entre sí. Las máquinas virtuales grandes pueden rendir peor si sus recursos se distribuyen de forma inadecuada entre los dominios de procesador. Por tanto, para bases de datos grandes, servidores de escritorio remoto y aplicaciones exigentes, hay que configurar correctamente el tamaño de las máquinas virtuales y seguir las recomendaciones del hipervisor.

Cómo debe ser un servidor AMD EPYC equilibrado

Una buena configuración de virtualización no consiste en instalar el procesador más grande en la configuración mínima posible. Debe ser un sistema equilibrado, sin puntos débiles evidentes.

Para un nodo pequeño, puede incluir:

• un procesador AMD EPYC con 32–48 núcleos;
• 512 GB de RAM;
• un conjunto NVMe o SSD;
• red de 10/25 GbE;
• un sistema de copias de seguridad independiente.

Para un clúster mediano:

• 2–3 nodos AMD EPYC;
• 48–64 núcleos por nodo;
• 512 GB–1 TB de RAM por nodo;
• almacenamiento NVMe para las máquinas virtuales;
• 25 GbE para el tráfico de migración y almacenamiento;
• un sistema de copias de seguridad independiente.

Para virtualización densa:

• EPYC con 64–96 núcleos o más;
• 1–2 TB de RAM por nodo;
• NVMe o almacenamiento externo/distribuido;
• red de 25/100 GbE;
• cálculos cuidadosos de licenciamiento;
• capacidad reservada para fallos;
• monitorización y pruebas periódicas de recuperación.

Al comprar equipos reacondicionados o usados, es especialmente importante verificar la compatibilidad entre el modelo exacto de servidor, los procesadores, la memoria, las unidades, los adaptadores de red y el hipervisor. Las plataformas de virtualización tienen ciclos de vida largos: un servidor puede permanecer en servicio entre tres y cinco años o más, por lo que un pequeño ahorro en una controladora o un adaptador de red puede generar limitaciones durante futuras actualizaciones del hipervisor.

Qué elegir para virtualización sobre AMD EPYC

Para una empresa que construye una nueva infraestructura y busca una alta densidad de máquinas virtuales, AMD EPYC es una plataforma sólida. Resulta especialmente adecuada para entornos que requieren muchos núcleos, gran capacidad de memoria, almacenamiento NVMe rápido y redes avanzadas. Sin embargo, el servidor debe elegirse junto con el hipervisor, no de forma independiente.

VMware sigue siendo una opción racional para entornos empresariales críticos cuando el coste de la suscripción se justifica por la estabilidad, un ecosistema maduro y un menor riesgo de migración. Proxmox es adecuado para organizaciones que desean mayor flexibilidad y están dispuestas a invertir en arquitectura, conocimientos de Linux y una migración piloto. Hyper-V es lógico para empresas con un entorno Microsoft consolidado en el que las licencias de Windows Server pueden aprovecharse de forma eficiente.

La estrategia más fiable no consiste en calcular «cuántos núcleos se pueden comprar», sino cuánta virtualización resistente se puede construir. El cálculo debe incluir el procesador, la memoria, el almacenamiento, la red, las licencias, las copias de seguridad, la tolerancia a fallos y el coste de la inactividad. Solo entonces un servidor AMD EPYC aportará una ventaja real, en lugar de convertirse en un equipo potente pero desequilibrado.