En uno de los chats me hicieron una pregunta:
— ¿Hay algo que pueda leer sobre cómo empaquetar correctamente los servidores en bastidores?
Me di cuenta de que no conocía ese texto, así que escribí el mío propio.
En primer lugar, este texto trata sobre servidores físicos en centros de datos físicos (DC). En segundo lugar, creemos que hay bastantes servidores: cientos de miles; para un número menor este texto no tiene sentido. En tercer lugar, consideramos que tenemos tres limitaciones: espacio físico en los racks, suministro de energía por rack y dejar que los racks estén en filas para que podamos usar un conmutador ToR para conectar servidores en racks adyacentes.
La respuesta a la pregunta depende en gran medida de qué parámetro estemos optimizando y qué podemos variar para lograr el mejor resultado. Por ejemplo, sólo necesitamos ocupar un mínimo de espacio para dejar más para un mayor crecimiento. O tal vez tengamos libertad para elegir la altura de los racks, la potencia por rack, los enchufes en la PDU, el número de racks en un grupo de interruptores (un interruptor para 1, 2 o 3 racks), la longitud de los cables y el trabajo de tracción ( esto es crítico en los extremos de las filas: con 10 bastidores seguidos y 3 bastidores por conmutador, tendrá que tirar de los cables a otra fila o subutilizar los puertos del conmutador), etc., etc. Historias separadas: selección de servidores y selección de DC, asumiremos que están seleccionados.
Sería bueno comprender algunos de los matices y detalles, en particular, el consumo medio/máximo de los servidores y cómo nos suministran la electricidad. Entonces, si tenemos una fuente de alimentación rusa de 230 V y una fase por rack, entonces una máquina de 32 A puede manejar ~7 kW. Digamos que nominalmente pagamos 6kW por rack. Si el proveedor mide nuestro consumo sólo para una fila de 10 bastidores, y no para cada bastidor, y si la máquina está configurada en un límite condicional de 7 kW, entonces técnicamente podemos consumir 6.9 kW en un solo bastidor, 5.1 kW en otro y todo estará bien, no punible.
Normalmente nuestro principal objetivo es minimizar costes. El mejor criterio para medir es la reducción del TCO (coste total de propiedad). Se compone de las siguientes piezas:
- CAPEX: compra de infraestructura DC, servidores, hardware de red y cableado
- OPEX: Alquiler de DC, consumo eléctrico, mantenimiento. OPEX depende de la vida útil. Es razonable suponer que serán 3 años.
Dependiendo del tamaño de las piezas individuales en el pastel general, debemos optimizar las más caras y dejar que el resto utilice todos los recursos restantes de la manera más eficiente posible.
Digamos que tenemos un DC existente, hay una altura de rack de H unidades (por ejemplo, H=47), electricidad por rack Prack (Prack=6kW) y decidimos usar servidores de dos unidades h=2U. Quitaremos de 2 a 4 unidades del rack para interruptores, paneles de conexión y organizadores. Aquellos. físicamente, tenemos servidores Sh=rounddown((H-2..4)/h) en nuestro rack (es decir, Sh = rounddown((47-4)/2)=21 servidores por rack). Recordemos este Sh.
En el caso sencillo, todos los servidores de un rack son idénticos. En total, si llenamos un rack con servidores, entonces en cada servidor podemos gastar en promedio la energía Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Para simplificar, aquí ignoramos el consumo de conmutadores.
Demos un paso al costado y determinemos cuál es el consumo máximo del servidor Pmax. Si es muy simple, muy ineficaz y completamente seguro, entonces leemos lo que está escrito en la fuente de alimentación del servidor: eso es todo.
Si es más complejo y más eficiente, entonces tomamos el TDP (paquete de diseño térmico) de todos los componentes y lo resumimos (esto no es muy cierto, pero es posible).
Por lo general, no conocemos el TDP de los componentes (a excepción de la CPU), por lo que adoptamos el enfoque más correcto, pero también el más complejo (necesitamos un laboratorio): tomamos un servidor experimental de la configuración requerida y lo cargamos. por ejemplo, con Linpack (CPU y memoria) y fio (discos), medimos el consumo. Si lo tomamos en serio, también necesitamos crear el ambiente más cálido en el corredor frío durante las pruebas, porque esto afectará tanto al consumo de los ventiladores como al consumo de la CPU. Obtenemos el consumo máximo de un servidor específico con una configuración específica en estas condiciones específicas bajo esta carga específica. Simplemente queremos decir que el nuevo firmware del sistema, una versión de software diferente y otras condiciones pueden afectar el resultado.
Entonces, volvamos a Pserv y cómo lo comparamos con Pmax. Es cuestión de entender cómo funcionan los servicios y qué tan fuertes son los nervios de tu director técnico.
Si no asumimos ningún riesgo, creemos que todos los servidores pueden comenzar a consumir su máximo simultáneamente. Al mismo tiempo, puede ocurrir una entrada al CC. Incluso en estas condiciones, la infraestructura debe proporcionar servicio, por lo que Pserv ≡ Pmax. Este es un enfoque en el que la confiabilidad es absolutamente importante.
Si el director de tecnología piensa no sólo en la seguridad ideal, sino también en el dinero de la empresa y es lo suficientemente valiente, entonces usted puede decidir eso.
- Estamos empezando a controlar a nuestros proveedores, en particular, prohibimos el mantenimiento programado en los momentos de carga máxima planificada para minimizar la caída de un insumo;
- y/o nuestra arquitectura le permite perder un rack/fila/DC, pero los servicios continúan funcionando;
- y/o repartimos bien la carga horizontalmente entre los racks, para que nuestros servicios nunca salten al consumo máximo en un rack todos juntos.
Aquí es muy útil no sólo adivinar, sino monitorear el consumo y saber cómo los servidores realmente consumen electricidad en condiciones normales y pico. Por lo tanto, después de un análisis, el director técnico exprime todo lo que tiene y dice: “tomamos una decisión voluntaria de que el promedio máximo alcanzable del consumo máximo de servidor por rack está **muy** por debajo del consumo máximo”, condicionalmente Pserv = 0.8* Pmáx.
Y entonces un rack de 6kW ya no puede acomodar 16 servidores con Pmax = 375W, sino 20 servidores con Pserv = 375W * 0.8 = 300W. Aquellos. 25% más servidores. Este es un ahorro muy grande: después de todo, inmediatamente necesitamos un 25% menos de racks (y también ahorraremos en PDU, conmutadores y cables). Una seria desventaja de tal solución es que debemos monitorear constantemente que nuestras suposiciones sigan siendo correctas. Que la nueva versión de firmware no cambia significativamente el funcionamiento de los ventiladores y el consumo, que el desarrollo de repente con el nuevo lanzamiento no empezó a utilizar los servidores de manera mucho más eficiente (léase: lograron mayor carga y mayor consumo en el servidor). Después de todo, tanto nuestras suposiciones como nuestras conclusiones iniciales se vuelven inmediatamente incorrectas. Este es un riesgo que debe asumirse de manera responsable (o evitarse y luego pagar por estantes obviamente infrautilizados).
Una nota importante: debe intentar distribuir servidores de diferentes servicios horizontalmente entre bastidores, si es posible. Esto es necesario para que no sucedan situaciones en las que llega un lote de servidores para un servicio, los bastidores se llenan verticalmente para aumentar la "densidad" (porque así es más fácil). En realidad, resulta que un bastidor está lleno de servidores idénticos de baja carga del mismo servicio, y el otro está lleno de servidores igualmente de alta carga. La probabilidad de una segunda caída es significativamente mayor, porque el perfil de carga es el mismo y todos los servidores juntos en este bastidor comienzan a consumir la misma cantidad como resultado del aumento de carga.
Volvamos a la distribución de servidores en rack. Hemos analizado el espacio físico del rack y las limitaciones de energía, ahora veamos la red. Puedes utilizar conmutadores con puertos 24/32/48 N (por ejemplo, tenemos conmutadores ToR de 48 puertos). Afortunadamente, no hay muchas opciones si no se piensa en los cables de conexión. Estamos considerando escenarios en los que tenemos un conmutador por bastidor, un conmutador para dos o tres bastidores en el grupo Rnet. Me parece que más de tres parrillas en un grupo ya es demasiado, porque... el problema del cableado entre racks se vuelve mucho mayor.
Así, para cada escenario de red (1, 2 o 3 racks en un grupo), distribuimos los servidores entre los racks:
Srack = min(Sh, redondeo(Prack/Pserv), redondeo(N/Rnet))
Así, para la opción con 2 bastidores en grupo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servidores por rack.
Consideramos las opciones restantes de la misma manera:
Srack1 = 20
Srack3 = 16
Y ya casi llegamos. Contamos el número de racks para distribuir todos nuestros servidores S (que sean 1000):
R = resumen(S / (Srack * Rnet)) * Rnet
R1 = resumen(1000 / (20 * 1)) * 1 = 50 * 1 = 50 bastidores
R2 = resumen(1000 / (20 * 2)) * 2 = 25 * 2 = 50 bastidores
R3 = resumen(1000 / (16 * 3)) * 3 = 25 * 2 = 63 bastidores
A continuación, calculamos el TCO para cada opción en función de la cantidad de racks, la cantidad requerida de conmutadores, cableado, etc. Elegimos la opción donde el TCO es menor. ¡Ganancia!
Tenga en cuenta que aunque la cantidad requerida de bastidores para las opciones 1 y 2 es la misma, su precio será diferente, porque el número de interruptores para la segunda opción es la mitad y la longitud de los cables necesarios es mayor.
PD: Si tienes la oportunidad de jugar con la potencia por rack y la altura del rack, la variabilidad aumenta. Pero el proceso se puede reducir al descrito anteriormente simplemente revisando las opciones. Sí, habrá más combinaciones, pero aún un número muy limitado: el suministro de energía al rack para el cálculo se puede aumentar en pasos de 1 kW, los racks típicos vienen en 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 Tabla de datos puede ayudar con los cálculos. Miramos las placas recibidas y elegimos el mínimo.
Fuente: habr.com