AMD EPYC Turin: cómo elegir la CPU de servidor adecuada para los proveedores de alojamiento web

Cómo situar correctamente el AMD EPYC Turin

AMD EPYC Turin hace referencia a la Generación EPYC 9005 de procesadores para servidores. AMD los presentó en octubre de 2024 como la quinta generación de EPYC; la familia incluye modelos con núcleos Zen-5 y Zen-5c.

Para los proveedores de alojamiento web, Turín no es una CPU única con unas características de rendimiento uniformes. La gama de modelos abarca desde ocho hasta 192 núcleos por procesador. La elección del modelo adecuado depende de si se ejecutan en paralelo muchas solicitudes independientes de clientes, si determinadas aplicaciones requieren tiempos de respuesta cortos o si las máquinas virtuales consumen sobre todo mucha memoria.

Entre las opciones también se incluye la pregunta sobre la Número de zócalos: Un servidor con un solo procesador ofrece una combinación diferente de capacidad de cálculo, conexión de memoria y posibilidades de ampliación que una plataforma de dos zócalos. No todos los modelos están pensados para ambas variantes; según la ficha técnica, los procesadores con el sufijo «P» están diseñados para sistemas de un solo zócalo.

Por lo tanto, la preselección comienza por la composición concreta de la cartera de clientes y los requisitos en cuanto a RAM, unidades NVMe y red. Por ejemplo, un servidor VPS con alta densidad necesita reservas para máquinas virtuales activas simultáneamente, mientras que un servidor de bases de datos puede responder además a las necesidades de almacenamiento y de E/S. Las licencias de software y las autorizaciones del fabricante del servidor también forman parte de la planificación.

El mero hecho de disponer de más núcleos no indica cuántos servidores actuales se pueden sustituir. Para ello, el proveedor necesita perfiles de carga comparables y valores de medición del hardware de alojamiento existente, así como una reserva de contingencia definida. Sin esta base, es posible seleccionar un modelo, pero no se puede determinar una tasa de consolidación fiable.

Entender los núcleos, los chiplets y la frecuencia de reloj

Turín utiliza un Diseño de chiplets: Las unidades de cálculo y un chip de E/S independiente están conectados a través de AMD Infinity Fabric. El chip de E/S proporciona, entre otras cosas, las conexiones con la memoria RAM y con los dispositivos de entrada y salida. A la hora de planificar un servidor en la práctica, esto significa que no solo cuentan los núcleos, sino también la conexión a los recursos compartidos.

Zen 5 y Zen 5c se diferencian en su diseño y en la organización de sus núcleos. Zen 5c permite la mayor densidad de núcleos dentro de esta generación; sin embargo, esto no implica una clasificación general en cuanto a rendimiento. Una combinación de máquinas virtuales (VM) altamente paralelizada y una aplicación con pocas tareas en las que la latencia sea crítica pueden favorecer distintos modelos.

El EPYC 9965 cuenta con 192 núcleos Zen-5c y 384 hilos, mientras que el EPYC 9755 tiene 128 núcleos Zen-5 y 256 hilos. AMD indica una frecuencia máxima de hasta 3,7 GHz para el 9965 y de hasta 4,1 GHz para el 9755. Estos valores reflejan diferentes prioridades, pero no sustituyen a una comparación basada en el perfil de carga específico de cada usuario.

El indicado impulso máximo En particular, no se garantiza una frecuencia constante para todos los núcleos. La frecuencia que se alcanza bajo carga depende, entre otras cosas, de la carga y de las condiciones de funcionamiento. Por lo tanto, a la hora de tomar una decisión sobre el alojamiento web, el rendimiento y los tiempos de respuesta con una combinación definida de aplicaciones son más reveladores que el valor máximo aislado.

El número de subprocesos, que en cada caso es el doble, se debe a la tecnología SMT: un núcleo físico proporciona dos subprocesos lógicos. Sin embargo, estos comparten los recursos del núcleo; 384 subprocesos no equivalen ni a 384 núcleos físicos ni a una duplicación automática de la potencia de cálculo. Para determinar si la SMT y la sobreasignación de recursos de la CPU resultan útiles, hay que analizar la carga de clientes activa simultáneamente.

La memoria y las E/S limitan la capacidad

Muchos núcleos de CPU requieren una configuración de memoria adecuada. Según AMD, el EPYC 9005 admite hasta doce canales de memoria DDR5 por CPU. En el caso de un host de máquinas virtuales, no solo cuenta la capacidad total de RAM: la distribución de los módulos y el ancho de banda de memoria disponible también influyen en la capacidad de atender adecuadamente a los sistemas invitados activos simultáneamente.

La ficha técnica indica, para los modelos mencionados, hasta DDR5-6400 a un módulo DIMM por canal. La velocidad realmente disponible depende de la configuración de los componentes y de la homologación de la plataforma. Asimismo, los hasta 6 TB de DDR5 que se indican en la ficha técnica se refieren a las configuraciones allí especificadas, con dos módulos DIMM por canal, y no constituyen una garantía para todos los servidores.

Puede ser conveniente añadir más módulos de RAM para alcanzar la capacidad necesaria, pero esto modifica la configuración que se va a comprobar. Por ello, los proveedores deberían comparar el tamaño y la configuración deseados de los módulos con la lista de productos autorizados del fabricante del servidor, en lugar de sumar de forma independiente los valores máximos de capacidad y velocidad que figuran en la ficha técnica.

En el caso de las unidades NVMe y las tarjetas de red, también es necesario Conexión PCIe Es un factor decisivo. AMD indica hasta 128 carriles PCIe 5.0 para sistemas de un solo zócalo y hasta 160 para servidores de doble zócalo. El número real de conexiones que ofrece una placa concreta depende del diseño de la plataforma y del uso que se haga de las conexiones; el máximo de 2P no se aplica automáticamente a un host de 1P.

Por eso, a la hora de realizar la configuración, conviene tener en cuenta la interacción entre los componentes: un mayor número de unidades NVMe puede requerir conexiones adicionales, mientras que las tarjetas de red de alta velocidad también deben conectarse. CXL 2.0 forma parte de las capacidades de la plataforma, pero no es una característica que se pueda utilizar automáticamente en todos los servidores. Es necesario comprobar la compatibilidad de los dispositivos, el firmware y el sistema operativo con el sistema elegido.

Comparar planes de alojamiento de Turín

La familia EPYC 9005 ofrece diferentes enfoques: el 9965 apuesta por la máxima densidad de núcleos, mientras que el 9575F busca una frecuencia más alta. A la hora de elegir, no solo cuenta la CPU, sino la combinación del modelo concreto, el número de zócalos y la carga de trabajo. La siguiente tabla compara cuatro modelos basándose en datos de AMD.

El 9965 ofrece un número especialmente elevado de núcleos físicos para tareas independientes. Esto puede resultar interesante en el caso de una combinación de máquinas virtuales altamente paralelizadas, siempre que la memoria y las E/S puedan seguir el ritmo. El 9755 ofrece menos núcleos, pero una frecuencia máxima de impulso más alta y más caché L3 en total. A partir de estos datos por sí solos no se puede establecer una clasificación definitiva para aplicaciones de alojamiento web.

El modelo 9575F es una opción a tener en cuenta cuando algunas fases del proceso requieren tiempos de respuesta cortos. Su impulso máximo Sin embargo, no se garantiza una frecuencia constante para todos los núcleos. Que resulte más rentable que un modelo con más núcleos depende, entre otras cosas, de las solicitudes simultáneas y del modelo de licencia.

En el modelo 9655P, esto limita el Sufijo «P» la compatibilidad del zócalo con sistemas de un solo zócalo. Por lo tanto, este modelo no es una opción para un servidor de dos zócalos. Una comparación más amplia entre plataformas debería incluir configuraciones y mediciones concretas; para ello, el artículo sobre la Elección de plataforma entre AMD EPYC e Intel Xeon más información.

Asignar cargas de trabajo de alojamiento y cuellos de botella

La CPU de un servidor debe adaptarse a los servicios que se ejecutan simultáneamente. En el alojamiento compartido se generan muchas solicitudes independientes; en las máquinas virtuales, sistemas operativos completos compiten por los recursos; y las bases de datos, dependiendo de la carga de trabajo, reaccionan de forma sensible a los accesos a la memoria o a la latencia del almacenamiento. El siguiente resumen traduce estas diferencias en preguntas de evaluación para el diseño.

En el caso del alojamiento compartido, el número de trabajadores activos simultáneamente es tan relevante como la duración de cada solicitud. Una elevada carga de la CPU puede ser aceptable si el rendimiento es bueno; sin embargo, por sí sola no indica si los clientes tienen que esperar mucho tiempo. Por eso, para poder comparar, hay que tener en cuenta las distribuciones de los tiempos de respuesta y las tasas de error en niveles de carga definidos.

En el caso de las bases de datos, el Caché L3 solo una parte del panorama. El modelo 9755 cuenta con un total de 512 MB, mientras que el 9965 tiene un total de 384 MB. Estas especificaciones de los modelos no demuestran ninguna ventaja en cuanto a la base de datos: el tamaño de los registros, los patrones de acceso, la distribución del trabajo y la configuración de la RAM influyen en la frecuencia con la que se necesitan datos de otros niveles de almacenamiento.

Un servicio Redis gestionado complementa el conjunto de aplicaciones, por ejemplo, como caché. Para ello, los proveedores deben tener en cuenta, además de los recursos de CPU, sobre todo la memoria disponible y los requisitos del servicio concreto. El artículo sobre Redis 8 y decisiones de actualización para los proveedores de alojamiento web Aborda, entre otras cosas, los límites de almacenamiento y el funcionamiento de este tipo de servicios.

Para que la comparación entre modelos sea justa, la combinación de máquinas virtuales, la capacidad de RAM, el almacenamiento y los niveles de carga deben ser lo más comparables posible. De lo contrario, no es posible atribuir de forma significativa las diferencias en los tiempos de respuesta o el rendimiento a la elección de la CPU. Asimismo, una consulta individual más rápida y un mayor rendimiento global son objetivos distintos que pueden ponderarse de forma diferente a la hora de planificar las tarifas.

Planificación de la capacidad de las máquinas virtuales a modo de ejemplo

Un ejemplo numérico permite apreciar las magnitudes: un servidor con un EPYC 9965 cuenta con 192 núcleos físicos y 384 subprocesos. Si se configuran en él 48 máquinas virtuales con cuatro vCPU cada una, el resultado es 48 × 4 = 192 vCPU asignadas. Se trata de un cálculo de asignación y no de una medición del rendimiento alcanzable de las máquinas virtuales.

A vCPU No se trata necesariamente de un núcleo físico reservado en exclusiva. El hipervisor asigna procesadores virtuales a los procesadores lógicos disponibles; la ejecución real depende de qué máquinas virtuales estén funcionando simultáneamente y de los recursos que se les asignen. Además, los 384 subprocesos del procesador no corresponden a 384 núcleos físicos independientes.

Para el Overbooking En primer lugar, debes determinar cuál es la carga simultánea que esperas y qué rendimiento ofrece cada plan de tarifas. Un mayor número de vCPU asignadas puede funcionar cuando los picos de carga rara vez coinciden, pero aumenta el riesgo de tiempos de espera cuando muchos usuarios realizan cálculos al mismo tiempo. Comprueba esta hipótesis con la composición real de la clientela, en lugar de basarte únicamente en el número de subprocesos.

A continuación, calcula por separado las necesidades de memoria: suma la RAM prevista para las máquinas virtuales y ten en cuenta, además, las necesidades del hipervisor y las reservas operativas. El cálculo de la CPU no indica si el host proporciona suficiente RAM ni si el ancho de banda de memoria necesario es suficiente cuando hay varios invitados activos al mismo tiempo.

Lo mismo se aplica al almacenamiento y a la red. Muchas máquinas virtuales pueden acceder simultáneamente a unidades NVMe o transferir datos; en este contexto, además del rendimiento total, también son relevantes las latencias de E/S y los picos de carga. Por lo tanto, ten en cuenta la conectividad y el rendimiento de las unidades y tarjetas de red que se utilicen realmente.

Por último, necesitas una reserva para el mantenimiento y las averías. Si un host restante debe albergar máquinas virtuales adicionales tras la avería de otro, la ocupación habitual no debe ocupar ya todos los recursos necesarios para ello. El ejemplo con 48 máquinas virtuales no establece ni un límite de ocupación seguro ni una tasa de consolidación; ambos aspectos deben evaluarse en función del entorno concreto.

Preparar la plataforma y la virtualización

Comienza la planificación de la plataforma por el modelo concreto de CPU y por determinar si se necesitan uno o dos zócalos. Las necesidades de núcleos, RAM y E/S deben ajustarse conjuntamente al sistema host deseado. Un modelo P, como el EPYC 9655P, está diseñado para un solo zócalo y, por lo tanto, no es adecuado para una configuración de dos zócalos.

A continuación, comprueba la Autorización del fabricante para la CPU, la placa base y la BIOS. Aunque Turín utiliza el zócalo SP5, un servidor SP5 ya existente no es compatible con todos los modelos 9005 solo por ese motivo. La fuente de alimentación y el sistema de refrigeración también deben ser compatibles con la CPU seleccionada y la carcasa prevista.

Planifica los módulos de RAM en función de la capacidad, la configuración de canales y las especificaciones del fabricante del servidor. A esto hay que añadir las unidades NVMe y las tarjetas de red necesarias: lo decisivo no es solo su número, sino también qué ranuras o bahías de unidad están conectadas en el sistema concreto. De este modo, antes de realizar el pedido se puede comprobar si la combinación deseada es realmente posible en la plataforma.

En el caso de las máquinas virtuales confidenciales de los clientes, se puede SEV-SNP Complementar la protección de la memoria de la máquina virtual con mecanismos de integridad. El I/O de confianza a través de TDISP es otro posible componente para el acceso a los dispositivos. Sin embargo, que esto se traduzca en una oferta útil depende de la combinación de firmware, hipervisor, sistema operativo invitado y, en su caso, dispositivos.

Además, antes de comprometerte con un producto, debes aclarar cómo se configuran, certifican y gestionan los invitados, y qué restricciones se aplican a las funciones de las máquinas virtuales que se ofrecen. Una función de CPU por sí sola no garantiza la compatibilidad de toda la pila ni protege contra todos los ataques. Por lo tanto, documenta la configuración realmente compatible y manténla actualizada con cada actualización.

Medir el funcionamiento e identificar los cuellos de botella

Para compararlo con el hardware de alojamiento actual, necesitas un... perfil de carga: aproximadamente la misma combinación de máquinas virtuales, volúmenes de datos similares y tipos de solicitudes definidos. Anota la configuración de la RAM, el almacenamiento, la red y el software. Solo así se podrá distinguir más adelante si una desviación está relacionada más bien con la CPU o con otro cambio en el sistema.

Analiza varios niveles de carga en lugar de limitarte a un único valor máximo. Registra el rendimiento, la distribución de los tiempos de respuesta y las tasas de error: un mayor rendimiento tiene poco valor para un servicio de alojamiento si, al mismo tiempo, muchas solicitudes se ralentizan o fallan. Establece de antemano qué tiempos de respuesta y qué tasas de error son aceptables para cada servicio.

Supervisa simultáneamente la utilización de la RAM y el comportamiento de la memoria, así como la latencia y la carga del almacenamiento y la red. Si los tiempos de respuesta aumentan aunque la CPU aún tenga capacidad de reserva, es posible que, por ejemplo, otro componente de la plataforma esté limitando el rendimiento. Por el contrario, una elevada carga de la CPU por sí sola no demuestra necesariamente que los clientes tengan una mala experiencia de usuario.

Si los tiempos de respuesta de las máquinas virtuales son anómalos, comprueba la concurrencia prevista y la Sobrecarga de la CPU. A continuación, compara la dotación real de RAM y los ajustes del firmware y del hipervisor con la configuración prevista. Modifica, en la medida de lo posible, factores concretos de forma selectiva y repite el mismo nivel de carga, para que la causa no se confunda con un cambio simultáneo en la carga de trabajo.

El funcionamiento diario incluye, además, boletines de seguridad, mantenimiento del firmware, controles de acceso y copias de seguridad verificables. AMD también publica avisos sobre vulnerabilidades de seguridad y medidas correctivas para los procesadores EPYC; los operadores deben planificar las actualizaciones correspondientes del fabricante del servidor. Tras las tareas de mantenimiento, comprueba de nuevo si las funciones de protección y las configuraciones de invitado ofrecidas están disponibles tal y como estaba previsto.

La adquisición y la rentabilidad son factores decisivos

La decisión de adquisición comienza con la pregunta de si la plataforma actual sigue cumpliendo los requisitos. Si la capacidad y las reservas son suficientes, puede tener sentido seguir utilizándola. Sin embargo, para actualizar a Turín, el fabricante del servidor debe haber homologado el modelo concreto de CPU, el firmware y el resto de componentes; el zócalo común SP5 no basta como prueba.

Compara uno 1P-Host con una configuración de 2P, en función de las necesidades totales de núcleos, RAM y puertos. No es necesario disponer de dos zócalos únicamente por el elevado número de máquinas virtuales previsto. Por el contrario, una plataforma de un solo zócalo puede descartarse si la combinación necesaria de memoria y E/S no cabe en el servidor elegido.

Cuando hay muchas tareas independientes ejecutándose simultáneamente, la densidad de núcleos puede ser un criterio de selección importante. Por el contrario, para aplicaciones sensibles a la latencia, merece la pena analizar también modelos con una frecuencia de reloj más alta dentro de la propia combinación de aplicaciones. Además, calcula el modelo de licencia concreto: los costes por núcleo, por zócalo o por máquina virtual pueden alterar el orden de prioridad económico de las plataformas.

El TDP No se trata de una medición del consumo eléctrico de un servidor completo. AMD indica un TDP de 500 vatios tanto para el EPYC 9755 como para el 9965; de ahí no se deduce ni el consumo de energía bajo tu carga ni los costes energéticos anuales. La memoria RAM, las unidades de disco, la red y la refrigeración forman parte del análisis global del sistema.

Para realizar una comparación de energía y costes, evalúa el sistema en su conjunto con niveles de carga representativos e incluye las reservas necesarias. Debes comparar los costes de adquisición, las licencias de software y los gastos de funcionamiento a lo largo del periodo de uso previsto. Sin datos comparables sobre la situación actual, no es posible prometer ni un ahorro concreto ni una tasa de consolidación fiable.