En uno de los chats me hicieron una pregunta:
— ¿Hay algo que leer sobre cómo empaquetar adecuadamente los servidores en racks?
Me di cuenta de que no conocía un texto así, así que escribí el mío.
En primer lugar, este texto trata sobre servidores físicos en centros de datos físicos (CD). En segundo lugar, asumimos que hay muchos servidores: cientos o miles; este texto no tiene sentido para cantidades menores. En tercer lugar, consideremos que tenemos tres limitaciones: espacio físico en los racks, suministro eléctrico por rack y, aunque los racks están dispuestos en filas, podemos usar un switch ToR para conectar servidores en racks adyacentes.
La respuesta a la pregunta depende mucho de qué parámetro estamos optimizando y qué podemos variar para lograr el mejor resultado. Por ejemplo, puede que solo necesitemos ocupar el mínimo espacio para dejar más para un crecimiento futuro. O quizás tengamos libertad en la elección de la altura de los racks, potencia por rack, enchufes en el PDU, cantidad de racks en el grupo de switches (un switch para 1, 2 o 3 racks), longitud de los cables y el trabajo de tendido (esto es crítico en los extremos de las filas: en una fila de 10 racks y con 3 racks conectados al switch, será necesario llevar los cables a otra fila o utilizar puertos en el switch de manera ineficiente), etc., etc. Historias aparte: la elección de los servidores y la elección del CD; supondré que ya han sido elegidos.
Sería bueno entender algunos matices y detalles, en particular, el consumo medio/máximo de los servidores y cómo se nos suministra electricidad. Por ejemplo, si tenemos una alimentación rusa de 230V y una fase por rack, un automático de 32A puede soportar aproximadamente 7kW. Supongamos que nominalmente pagamos por 6kW por rack. Si el proveedor mide nuestro consumo solo por la fila de 10 racks y no por cada rack, y si el automático se corta a condiciones de 7kW, entonces técnicamente podemos consumir 6.9kW en un rack, 5.1kW en otro y todo estará bien, sin penalizaciones.
Generalmente, nuestro objetivo principal es la minimización de costos. El mejor criterio para medir es la reducción del TCO (costo total de propiedad). Consiste en las siguientes partes:
- CAPEX: compra de infraestructura del CD, servidores, equipos de red y cableado
- OPEX: alquiler del CD, electricidad consumida, mantenimiento. OPEX depende de la vida útil. Es razonable suponer que equivale a 3 años.
Dependiendo de cómo sean de grandes las porciones individuales en el total, necesitamos optimizar lo más costoso, mientras que el resto debe utilizar todos los recursos restantes de la manera más eficiente posible.
Supongamos que ya tenemos un centro de datos (DС), tenemos la altura del rack H (por ejemplo, H=47), electricidad por rack Prack (Prack=6kW), y decidimos utilizar servidores de 2U. Quitaremos de 2 a 4 unidades del rack para switches, paneles de parcheo y organizadores. Es decir, físicamente, en nuestro rack cabrán Sh=rounddown((H-2..4)/h) servidores (es decir, Sh = rounddown((47-4)/2)=21 servidores por rack). Recordemos esto Sh.
En el caso más simple, todos los servidores en el rack son iguales. En total, si llenamos el rack servidores, entonces en cada servidor podremos gastar en promedio Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Para simplificar, ignoramos el consumo del switch aquí.
Hagamos un paso atrás y definamos qué es el consumo máximo del servidor Pmax. Si lo decimos de manera sencilla, muy ineficaz y completamente segura, entonces leemos lo que está escrito en la fuente de alimentación del servidor: eso es.
Si es más complejo, más eficiente, tomamos el TDP (paquete de diseño térmico) de todos los componentes y lo sumamos (esto no es del todo cierto, pero se puede hacer así).
Generalmente no conocemos el TDP de los componentes (excepto la CPU), así que tomamos el enfoque más correcto, pero también el más complicado (se necesita un laboratorio): tomamos un servidor experimental con la configuración deseada y lo sometemos a carga, por ejemplo, con Linpack (CPU y memoria) y fio (discos), y medimos el consumo. Si se hace en serio, también hay que crear el ambiente más cálido en el pasillo frío durante las pruebas, porque esto afecta tanto el consumo de los ventiladores como el de la CPU. Obtenemos el consumo máximo de un servidor específico con una configuración concreta en estas condiciones específicas bajo esta carga particular. Simplemente debemos tener en cuenta que un nuevo firmware, una versión diferente de software y otras condiciones pueden influir en el resultado.
En resumen, volvemos a Pserv y cómo compararlo con Pmax. Esta es una cuestión de entender cómo funcionan los servicios y cuán fuertes son los nervios de su ingeniero de soporte técnico.
Si no queremos correr riesgos, consideramos que todos los servidores pueden comenzar a consumir su máximo al mismo tiempo. En ese mismo momento, puede producirse una sola entrada en el centro de datos. La infraestructura, en estas condiciones, debe proporcionar servicio, por lo que Pserv ≡ Pmax. Este es un enfoque donde la fiabilidad es absolutamente crucial.
Si el director técnico no solo piensa en la seguridad ideal, sino también en el dinero de la empresa y es lo suficientemente audaz, se puede concluir que
- comenzamos a gestionar a nuestros proveedores, en particular, prohibimos realizar mantenimiento programado en momentos de alta carga planificada para minimizar la caída de un suministro;
- y/o nuestra arquitectura permite perder un rack/fila/datacenter, mientras los servicios continúan funcionando;
- y/o distribuimos bien la carga horizontalmente entre los racks, por lo que nuestros servicios nunca saltarán a un consumo máximo en un solo rack todos a la vez.
Es muy útil no solo adivinar, sino monitorear el consumo y saber cómo realmente los servidores consumen electricidad en condiciones normales y picos. Por lo tanto, después de un análisis, el director técnico compacta todo lo que tiene y dice: 'tomamos la decisión voluntaria de que el promedio máximo alcanzable del consumo de servidores por rack es **tanto** inferior al consumo máximo', condicionalmente Pserv=0.8*Pmax.
Entonces, en un rack de 6kW ya no caben 16 servidores con Pmax = 375W, sino 20 servidores con Pserv = 375W * 0.8 = 300W. Es decir, un 25% más de servidores. Esto es un gran ahorro, ya que también necesitaremos un 25% menos de racks (y además ahorraremos en PDU, switches y cables). Una desventaja seria de esta solución es que debemos monitorear constantemente si nuestras suposiciones siguen siendo correctas. Que la nueva versión del firmware no cambia de manera significativa el funcionamiento de los ventiladores y el consumo, que el desarrollo de repente con un nuevo lanzamiento no ha comenzado a utilizar los servidores de manera mucho más eficiente (es decir, logramos una mayor carga y mayor consumo en el servidor). Porque entonces, tanto nuestras suposiciones iniciales como las conclusiones se vuelven de inmediato incorrectas. Este es un riesgo que debemos asumir responsablemente (o evitarlo y entonces pagar por racks claramente subutilizados).
Nota importante: es recomendable intentar distribuir los servidores de diferentes servicios horizontalmente entre los racks, si es posible. Esto es necesario para evitar situaciones en las que un lote de servidores para un mismo servicio llega y los racks se llenan verticalmente para aumentar la "densidad" (porque es más fácil). Sin embargo, en realidad, resulta que un rack está lleno de servidores de bajo rendimiento del mismo servicio, mientras que otro está lleno de servidores de alto rendimiento. La probabilidad de caída del segundo es significativamente mayor, ya que el perfil de carga es el mismo y todos los servidores juntos en este rack comienzan a consumir de manera similar debido a un aumento en la carga.
Regresamos a la distribución de servidores en los racks. Ya hemos considerado las limitaciones físicas del espacio en el rack y las limitaciones de alimentación, ahora echemos un vistazo a la red. Se pueden utilizar switches de 24/32/48 puertos N (por ejemplo, switches ToR de 48 puertos). Afortunadamente, no hay muchas opciones, si no pensamos en los cables break-out. Consideramos escenarios donde tenemos un switch por rack, un switch para dos o tres racks en el grupo Rnet. Me parece que más de tres racks en un grupo es excesivo, ya que el problema de cableado entre racks se vuelve significativamente mayor.
Así que, para cada escenario de red (1, 2 o 3 racks en grupo) distribuimos los servidores entre los racks:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Por lo tanto, para la opción con 2 racks en grupo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servidores por rack.
Calculamos de manera similar las demás opciones:
Srack1 = 20
Srack3 = 16
Y ya estamos casi allí. Calculamos la cantidad de racks para distribuir todos nuestros servidores S (supongamos que hay 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 racks
A continuación, calculamos el TCO para cada opción en función del número de racks, la cantidad necesaria de switches, cableado, etc. Elegimos la opción donde el TCO es menor. ¡Beneficio!
Notemos que, aunque la cantidad necesaria de racks para las opciones 1 y 2 es la misma, su costo será diferente, ya que la cantidad de switches para la segunda opción es la mitad, mientras que la longitud de los cables necesarios es mayor.
P.S. Si hay la posibilidad de jugar con la potencia y la altura del rack, la variabilidad aumenta. Pero el proceso se puede reducir a lo que se describió anteriormente, simplemente explorando las opciones. Sí, habrá más combinaciones, pero seguirá siendo una cantidad bastante limitada: la alimentación para el rack se puede aumentar en incrementos de 1 kW, los racks típicos suelen tener un número limitado de tamaños estándar: 42U, 45U, 47U, 48U, 52U. Y aquí el análisis What-If de Excel en modo Data Table puede ser útil para el cálculo. Miramos las tablas obtenidas y elegimos el mínimo.
Fuente: habr.com
