En uno de los chats me hicieron una pregunta:
- Y hay algo para leer, ¿cómo empacar los servidores en bastidores correctamente?
Me di cuenta de que no conocía ese texto, así que escribí el mío.
En primer lugar, este texto trata sobre servidores físicos en centros de datos físicos (DC). En segundo lugar, creemos que hay muchos servidores: cientos o miles, para un número menor este texto no tiene sentido. En tercer lugar, creemos que tenemos tres limitadores: espacio físico en los bastidores, alimentación al bastidor y dejar que los bastidores se mantengan en filas, para que podamos usar un interruptor ToR para conectar servidores en bastidores vecinos.
La respuesta a la pregunta depende en gran medida del parámetro que optimicemos y de lo que podamos variar para lograr el mejor resultado. Por ejemplo, solo necesitamos tomar 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, la cantidad de racks en un grupo de interruptores (un interruptor por 1, 2 o 3 racks), la longitud de los cables y el trabajo de extracción (esto es crítico en los extremos de las filas: Con 10 bastidores en una fila y 3 bastidores en un interruptor, tendrá que tirar de los cables en otra fila o subutilizar los puertos en el interruptor), etc., etc. Historias separadas: selección del servidor y selección DC, asumimos que están seleccionadas.
Sería bueno comprender algunos de los matices y detalles, en particular, el consumo promedio / máximo de servidores y cómo se nos suministra la electricidad. Entonces, si tenemos una fuente de alimentación rusa de 230V y una fase por rack, entonces una máquina de 32A puede contener ~ 7kW. Supongamos que pagamos nominalmente 6kW por rack. Si un proveedor mide nuestro consumo solo para una serie de 10 bastidores, y no para cada bastidor, y si la máquina tiene un corte convencional de 7 kW, entonces técnicamente podemos consumir 6.9 kW en un bastidor separado, en otros 5.1 kW y todo estará bien, no se castiga.
Por lo general, nuestro objetivo principal es minimizar los costos. El mejor criterio de medición es la reducción en TCO (costo total de propiedad). Se compone de las siguientes piezas:
- CAPEX: adquisición de infraestructura DC, servidores, hardware de red y cableado
- OPEX: alquiler DC, electricidad consumida, mantenimiento. OPEX depende de la vida útil. Es razonable suponer que es igual a 3 años.
Dependiendo de qué tan grandes sean las piezas individuales en todo el pastel, necesitamos optimizar las más caras y dejar que el resto use todos los recursos restantes de la manera más eficiente posible.
Supongamos que tenemos un DC existente, hay una altura de rack de unidades H (por ejemplo, H = 47), electricidad al rack P
rack (
rack P = 6 kW), y decidimos usar h = 2U servidores de dos unidades. Quitamos 2..4 unidades del bastidor a los interruptores, paneles de conexión y organizadores. Es decir físicamente, tenemos servidores S
h = rounddown ((H-2..4) / h) en nuestro rack (es decir, S
h = rounddown ((47-4) / 2) = 21 servidores por rack). Recuerde que esto es S
h .
En el caso simple, todos los servidores en el bastidor son iguales. Total, si martillamos el rack con servidores, entonces en cada servidor podemos gastar en promedio la potencia P
serv = P
rack / S
h (P
serv = 6000 W / 21 = 287 W). Por simplicidad, ignoramos el consumo del interruptor aquí.
Damos un paso al costado y determinamos cuál es el consumo máximo del servidor P
max . Si es muy simple, muy ineficiente y completamente seguro, entonces leemos lo que está escrito en la fuente de alimentación del servidor, eso es todo.
Si es más complicado, 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 puede ser así).
Por lo general, no conocemos los componentes de TDP (excepto la CPU), por lo que tomamos el enfoque más correcto, pero también el más difícil (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) medir el consumo Si lo toma en serio, también debe crear el ambiente más cálido en el corredor frío durante las pruebas, ya que esto afectará tanto el consumo del ventilador como el 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, otra versión del software, otras condiciones pueden afectar el resultado.
En total, volvemos a P
serv y cómo lo comparamos con P
max . Se trata de comprender cómo funcionan los servicios y qué tan fuertes son sus nervios en su tecnología.
Si no se arriesga en absoluto, creemos que todos los servidores pueden comenzar a consumir su máximo de inmediato. Al mismo tiempo, se puede formar una entrada al DC. Infra en estas condiciones debe proporcionar un servicio, por lo tanto P
serv ≡ P
max . Este es un enfoque donde la confiabilidad es absolutamente crucial.
Si el técnico no solo piensa en la seguridad perfecta, sino también en el dinero de la compañía y es lo suficientemente valiente, entonces podemos decidir que
- comenzamos a administrar a nuestros proveedores, en particular, prohibimos el mantenimiento programado en los momentos de la carga pico planificada para minimizar la caída en una entrada;
- y / o nuestra arquitectura le permite perder el rack / row / DC, y los servicios continúan funcionando;
- y / o bien distribuimos la carga horizontalmente a través de los racks, por lo que nuestros servicios nunca saltarán al consumo máximo en un rack todos juntos.
Es muy útil aquí no solo para adivinar, sino para monitorear el consumo y saber cómo realmente, en condiciones normales y pico, los servidores consumen electricidad. Por lo tanto, después de un análisis, el techdir comprime todo lo que tiene y dice: "decidimos deliberadamente que el promedio máximo alcanzable del consumo máximo de servidor por rack es ** mucho ** más bajo que el consumo máximo", condicionalmente P
serv = 0.8 * P
máx .
Y luego, en un rack de 6kW, ya no 16 servidores con P
max = 375W, sino 20 servidores con P
serv = 375W \ * 0.8 = 300W. Es decir Un 25% más de servidores. Este es un gran ahorro: después de todo, necesitamos inmediatamente un 25% menos de bastidores (también ahorramos en PDU, conmutadores y cables). Una desventaja seria de tal decisión: es necesario controlar constantemente que nuestras suposiciones siguen siendo ciertas. Que la nueva versión del firmware no cambia significativamente el funcionamiento de los ventiladores y el consumo, que el desarrollo de una nueva versión de repente no comenzó a usar el servidor de manera mucho más eficiente (léase, obtuvimos más carga y más consumo en el servidor). Después de todo, nuestros supuestos y conclusiones iniciales se vuelven inmediatamente incorrectos. Este es un riesgo que debe tomarse responsablemente (o evitarse y luego pagarse por bastidores obviamente subcargados).
Una nota importante: si es posible, debe intentar distribuir servidores desde diferentes servicios en bastidores horizontalmente. Esto es necesario para que las historias no sucedan cuando llega un lote de servidores para un servicio, los racks están obstruidos verticalmente para aumentar la "densidad" (porque es más fácil). En realidad, resulta que un rack está repleto de los mismos servidores de baja carga de un servicio, y el otro tiene la misma carga. La probabilidad de una caída del segundo es mucho 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 la carga.
Volver a la distribución de servidores en los bastidores. Examinamos las limitaciones físicas del espacio de rack y las limitaciones de energía, y ahora echamos un vistazo a la red. Puede usar conmutadores en 24/32/48 puertos N (por ejemplo, tenemos conmutadores ToR de 48 puertos). Afortunadamente, no hay muchas opciones si no piensa en los cables de conexión. Consideramos los escenarios cuando tenemos un conmutador por bastidor, un conmutador a dos o tres bastidores en el grupo R
net . Me parece que más de tres bastidores en el grupo ya son demasiado, porque El problema del cableado entre bastidores se hace mucho mayor.
Entonces, para cada escenario de red (1, 2 o 3 bastidores en un grupo) distribuimos el servidor en bastidores:
S
rack = min (S
h , redondeo (P
rack / P
serv ), redondeo (N / R
neto ))
Por lo tanto, para la opción con 2 bastidores en el grupo:
S
rack 2 = min (21, redondeo (6000/300), rounddown (48/2)) = min (21, 20, 24) = 20 servidores por rack.
Del mismo modo, consideramos las opciones restantes:
S
rack 1 = 20
S
rack 3 = 16
Y ya casi llegamos. Contamos el número de bastidores para la distribución de todos nuestros servidores S (que sea 1000):
R = resumen (S / (S
rack * R
net )) * R
netR
1 = resumen (1000 / (20 * 1)) * 1 = 50 * 1 = 50 bastidores
R
2 = resumen (1000 / (20 * 2)) * 2 = 25 * 2 = 50 bastidores
R
3 = resumen (1000 / (16 * 3)) * 3 = 21 * 3 = 63 bastidores
A continuación, consideramos el TCO para cada opción en función de la cantidad de bastidores, la cantidad requerida de interruptores, cableado, etc. Elegimos la opción donde TCO es menor. Beneficio!
Tenga en cuenta que aunque el número requerido de bastidores para las opciones 1 y 2 es el mismo, su precio será diferente, porque la cantidad de interruptores para la segunda opción es la mitad y la longitud de los cables requeridos es más larga.
PD: si existe la oportunidad de jugar potencia en un estante y la altura del estante, la variabilidad aumenta. Pero el proceso puede reducirse a lo anterior, simplemente clasificando las opciones. Sí, habrá más combinaciones, pero aún un número muy limitado: la potencia del bastidor para el cálculo se puede aumentar en incrementos de 1 kW, los bastidores típicos tienen un número limitado de tamaños: 42U, 45U, 47U, 48U, 52U. Y aquí el análisis What-If de Excel en el modo Tabla de datos puede ayudar a calcular. Observamos las placas recibidas y seleccionamos el mínimo.