Optimización de la distribución del servidor en los bastidores

Recientemente, un colega me preguntó en un chat:

- ¿Hay algún artículo sobre cómo empaquetar los servidores en los bastidores correctamente?

Me di cuenta de que no lo sabía. Entonces, decidí escribir mi texto.

En primer lugar, este es un artículo sobre servidores de metal desnudo en las instalaciones del centro de datos (DC). En segundo lugar, estimamos que hay muchos servidores (cientos o miles); El artículo no tiene sentido para menos cantidades. En tercer lugar, consideramos que existen tres restricciones en los bastidores: espacio físico, energía eléctrica por cada uno y los gabinetes permanecen en las filas adyacentes entre sí, por lo que podemos usar un solo interruptor ToR para conectar servidores en ellos.

La respuesta a la pregunta original depende significativamente del parámetro que estamos optimizando y de lo que podemos cambiar para obtener un mejor resultado. Por ejemplo, necesitamos usar menos espacio para dejar más para el crecimiento futuro. O tal vez tengamos libertad en la selección de la altura del gabinete, la potencia por rack, la cantidad de tomas por PDU, la cantidad de gabinetes por grupo de interruptores (un interruptor por 1, 2 o 3 bastidores), las longitudes de los cables y los trabajos de cableado. El último componente es crítico para el final de las filas del bastidor donde necesitamos tirar de cables hacia la otra fila o dejar puertos subutilizados en el conmutador. Historias completamente diferentes son la selección del servidor y la selección del centro de datos. Deberíamos considerar que ya los elegimos.

Es bueno comprender algunos matices y detalles, en particular, el consumo de energía promedio / máximo del servidor y cómo nuestro proveedor proporciona electricidad. Entonces, si tenemos una fuente de alimentación de 230V 1 fase, entonces un disyuntor de 32Amps puede contener hasta ~ 7kW. Digamos que pagamos formalmente por 6kW por rack. Si un proveedor mide nuestro consumo de energía por fila de 10 gabinetes, no por uno solo, y si los interruptores de circuito limitan la potencia a 7kW, entonces podemos usar 6.9kW en un rack y 5.1kW en otro. Estará bien e impune.

Por lo general, nuestro objetivo principal es minimizar el gasto. El mejor criterio de medición es la reducción del costo total de propiedad (TCO). Consta de las siguientes partes:

  • CAPEX: compra de infraestructura de centro de datos, servidores, dispositivos de red, cableado
  • OPEX: alquiler DC, consumo de electricidad, mantenimiento. OPEX depende de la vida útil. Es razonable suponer que una vida es igual a 3 años.

Gráfico de TCO

Deberíamos optimizar las partes más caras del pastel. Todo lo demás debe utilizar los recursos restantes de la manera más efectiva posible.

Supuestamente, tenemos un DC existente, altura de rack de unidades H (por ejemplo H = 47), potencia por rack P rack (P rack = 6kW), y decidimos usar h = 2U servidores de dos unidades. Quitemos de 2 a 4 unidades del rack para interruptores, paneles de conexión, administradores de cables. Entonces podemos colocar servidores S h = redondeado ((H-2..4) / h) en un rack (es decir, S h = redondeo ((47-4) / 2) = 21 servidores por rack). Memoricemos S h .

En un caso simple, todos los servidores son iguales. Entonces, si llenamos un rack por servidores, podemos gastar por servidor una potencia promedio de P serv = P rack / S h (P serv = 6000W / 21 = 287W). Ignoramos el consumo de energía del interruptor aquí.

Dejemos de lado y definamos cuál es el consumo máximo de energía del servidor P max . La forma directa, completamente segura y altamente ineficiente es leer lo que dice una etiqueta en la unidad de fuente de alimentación del servidor. Aquí está P max .

Un enfoque más complicado y eficiente es tomar TDP de todos los componentes y resumirlos. No es exacto, pero podemos hacerlo de esta manera.

Por lo general, no conocemos TDP de componentes aparte de la CPU. Entonces, el enfoque más correcto y más complicado es tomar un servidor experimental adecuadamente configurado, cargarlo, por ejemplo, mediante / Linpack / (CPU y memoria) y / fio / (discos), y medir el consumo de energía. Necesitamos un laboratorio en este caso. Si nos tomamos las cosas en serio, deberíamos crear un ambiente cálido en el pasillo frío porque la temperatura más alta afecta tanto a los ventiladores como al consumo de energía de la CPU. Por lo tanto, obtenemos el consumo de energía máximo del servidor de muestra con esta configuración particular dentro del entorno actual bajo la carga específica. Solo tenga en cuenta que un nuevo firmware, versión de software y otras condiciones pueden afectar el resultado.

Ahora, volvamos a P serv y cómo debemos compararlo con P max . Se trata de entender cómo funcionan los servicios y qué tan fuertes son los nervios de nuestro CTO.

Si no aceptamos ningún riesgo, debemos suponer que todos los servidores pueden comenzar a consumir su máximo potencial simultáneamente. Al mismo tiempo, una de las alimentaciones de CC también puede fallar. La infraestructura aún debe proporcionar el servicio. Entonces, P serv ≡ P max . Es el enfoque cuando la fiabilidad es muy importante.

Si el CIO toma en cuenta no solo la seguridad ideal sino también el dinero de la compañía, si es lo suficientemente valiente, entonces puede decidir que

  • comenzamos a administrar a nuestros proveedores, en particular, prohibimos cualquier mantenimiento planificado en los períodos de nuestra alta carga esperada para minimizar la falla de energía
  • o nuestra arquitectura nos permite perder un rack / fila / DC mientras los servicios continúan operando
  • o bien distribuimos la carga horizontalmente en los bastidores tan bien que nuestros servidores en un solo gabinete nunca consumirán su máximo teórico por completo.

Es ventajoso no solo adivinar aquí, sino también monitorear el consumo de energía y comprender cómo los servidores consumen energía durante las cargas habituales y pico. Por lo tanto, después de un análisis, el CIO trabaja y dice:
"Ordeno que el promedio máximo alcanzable de todo el consumo máximo de energía del servidor sea mucho menor que el consumo máximo del servidor individual". Deje que sea P serv = 0.8 * P max

Y luego un rack de 6kW puede acomodar no 16 servidores de P max = 375W sino 20 servidores de P serv = 375W * 0.8 = 300W. Es decir, un 25% más de servidores. Es una economía real porque necesitamos un 25% menos de bastidores. Y podemos ahorrar en PDU de rack, conmutadores y cableado. Una seria desventaja de la solución es la necesidad de verificar continuamente que nuestras suposiciones sigan siendo válidas. Debemos asegurarnos de que un nuevo firmware no cambie la operación del ventilador y el consumo de energía de manera significativa, que el equipo de desarrollo no comience a usar los servidores de manera mucho más eficiente (significa que lograron aumentar la utilización y el consumo de energía). Entonces, tanto los supuestos iniciales como las conclusiones se vuelven erróneos. Por lo tanto, es el riesgo de ser aceptado de manera responsable. O se puede evitar el riesgo y luego la compañía paga por los racks obviamente subcargados.

Una nota importante: vale la pena intentar distribuir diferentes servidores de servicios en los bastidores horizontalmente si es posible. Se requiere para evitar casos en los que llega un grupo de servidores para el servicio y se instala verticalmente en los gabinetes para mejorar la "densidad" (solo porque es más fácil hacerlo de esta manera). De hecho, lleva a la situación cuando un rack se llena con los mismos servidores de baja carga, mientras que todos los altamente cargados residen en otro. Cuando el perfil de carga es el mismo, y todos los servidores comienzan a consumir de manera simultánea por una carga alta, la probabilidad de perder el segundo bastidor es mucho mayor.

Volvamos a la distribución del servidor en los bastidores. Consideramos las limitaciones físicas en los gabinetes y las limitaciones de energía. Ahora consideremos la red. Se pueden usar conmutadores N = 24/32/48 puertos (suponiendo conmutadores ToR de 48 puertos). Afortunadamente, no hay tantas opciones si ignoramos los cables de conexión. Consideramos las opciones de un interruptor en cada bastidor, un interruptor por dos o por tres gabinetes por grupo (R net ). Creo que el grupo no debería ser tres. De lo contrario, conduce a problemas de cableado.

Por lo tanto, distribuimos servidores en los bastidores para cada escenario de red (1, 2 o 3 bastidores por grupo):

S rack = min (S h , redondeo (P rack / P serv ), redondeo (N / R neto ))

Por lo tanto, un escenario de grupo de dos bastidores es

S rack 2 = min (21, redondeo (6000/300), rounddown (48/2)) = min (21, 20, 24) = 20 servidores por rack

Del mismo modo, contamos los otros escenarios:

S rack 1 = 20

S rack 3 = 16

Ya casi hemos terminado. Deberíamos contar la cantidad total de bastidores para distribuir todos los servidores S (que haya 1000 servidores):

R = resumen (S / (S rack * R net )) * R net

R 1 = resumen (1000 / (20 * 1)) * 1 = 50 * 1 = 50 bastidores

R 2 = resumen (1000 / (20 * 2)) * 2 = 25 * 2 = 50 bastidores

R 2 = resumen (1000 / (16 * 3)) * 3 = 21 * 3 = 63 bastidores

Luego deberíamos contar el TCO para cada opción en función del número de bastidores, interruptores necesarios, cableado, etc. Elegimos el escenario con el TCO más bajo. Beneficio!

Tenga en cuenta que aunque el número de bastidores para los escenarios 1 y 2 es el mismo, el costo total de propiedad es diferente debido a la cantidad dos veces menor de interruptores y cables más largos para el segundo escenario.

PD Si la potencia por rack o la altura del rack puede variar, entonces aumenta la variabilidad. Pero la selección puede reducirse al método anterior mediante la fuerza bruta de las opciones. Habrá más escenarios, pero su cantidad será limitada. Podemos aumentar la potencia por rack en pasos de 1kW, y hay un número limitado de tipos de rack estándar: 42U, 45U, 47U, 48U. Puede ser útil utilizar el análisis de casos hipotéticos de Excel en el modo Tabla de datos. Debemos mirar la tabla resultante y seleccionar la mejor opción.

Source: https://habr.com/ru/post/473988/


All Articles