Un Data Center no es solo un conjunto de sistemas, es una estructura que depende de interfases

3.004 Visitas Totales , 3.004 Visitas Hoy

Rubén Bernardino, ingeniero especializado en infraestructura, energía y desarrollo de centros de datos, plantea una advertencia que desafía la forma tradicional de evaluar estos proyectos: cada subsistema puede funcionar perfectamente por separado y, sin embargo, el centro de datos en su conjunto puede estar mal concebido.

Cuando lo correcto en cada parte no garantiza el todo

Según Bernardino, la energía puede ser técnicamente sólida y aun así generar una demanda de refrigeración innecesaria. La refrigeración puede operar con eficacia mientras consume una capacidad eléctrica escasa. La redundancia puede mejorar un subsistema mientras suma costo y complejidad en otro lugar del proyecto.

«El problema no suele estar dentro de los sistemas. Está entre ellos», resume el ingeniero, para quien ahí —en las interfaces— es donde la optimización local se convierte en riesgo a nivel de todo el sistema.

Fronteras que esconden consecuencias

Los centros de datos se organizan por disciplinas —eléctrica, mecánica, controles, obra civil, TI y operaciones— porque los proyectos complejos necesitan responsabilidades claras. Pero esas mismas fronteras, advierte Bernardino, pueden ocultar efectos en cadena.

Aumentar la densidad de TI, explica, dispara una secuencia de consecuencias: sube la demanda eléctrica, cambia el rechazo de calor, se modifican los requisitos de refrigeración, cambian los supuestos de distribución y puede crecer la potencia total de la instalación. Una decisión tomada por una sola disciplina puede así alterar la economía o el desempeño de varias otras.

«Cada equipo puede tomar una decisión defendible y el proyecto puede terminar convergiendo en la arquitectura general equivocada», señala. La pregunta que propone dejar planteada es quién asume la responsabilidad por las consecuencias que aparecen entre disciplinas de ingeniería.

Energía y refrigeración: un mismo problema

El caso de la energía y la refrigeración ilustra la lógica con particular claridad. Los equipos de TI consumen electricidad y convierten casi toda esa energía en calor; retirar ese calor exige infraestructura y energía adicionales. La secuencia resultante —carga de TI, demanda eléctrica, generación de calor, demanda de refrigeración y nueva demanda eléctrica— muestra que ambos sistemas no pueden optimizarse por separado.

Por eso, sostiene Bernardino, una arquitectura de refrigeración debe evaluarse no solo por su desempeño térmico, sino también por su impacto en la demanda eléctrica, la resiliencia, el rango operativo, la escalabilidad y la potencia total del sitio. Lo mismo aplica en sentido inverso: la arquitectura eléctrica influye en las pérdidas, la carga de los equipos, las estrategias de resiliencia y las condiciones bajo las cuales debe seguir operando la refrigeración. La unidad de ingeniería relevante, concluye, termina siendo la instalación completa.

La redundancia también traslada complejidad

La resiliencia plantea otro desafío de integración. Añadir redundancia a un subsistema puede mejorar su disponibilidad individual mientras incrementa la complejidad en otra parte: más rutas eléctricas requieren más capacidad de refrigeración; más equipos de refrigeración requieren más suministro eléctrico y lógica de control; la generación de respaldo introduce secuencias de conmutación, requisitos de combustible, restricciones de emisiones e implicancias de permisos.

Para Bernardino, la pregunta útil no es si un componente es resiliente, sino cómo esa estrategia de redundancia afecta la resiliencia, el costo y la operabilidad de la instalación completa. «Una colección de componentes altamente resiliente no produce automáticamente un sistema altamente resiliente», advierte.

Los controles, la prueba de fuego

Muchas interacciones entre sistemas solo se revelan cuando cambian las condiciones de operación. Un evento de red, una falla de equipo, una variación súbita de carga de TI o una limitación de refrigeración pueden obligar a varios subsistemas a reaccionar a la vez. Distribución eléctrica, UPS, generadores, almacenamiento, refrigeración y controles deben entonces ejecutar una respuesta coordinada sin salirse de los límites operativos que exige la carga de TI.

Los componentes individuales pueden cumplir con su especificación y, aun así, la instalación puede fallar si sus supuestos operativos, secuencias de control o estados de transición son inconsistentes entre sí. La integración de sistemas, sostiene Bernardino, va más allá de la selección de equipos: incluye cómo se espera que opere la instalación cuando las condiciones dejan de ser normales.

Una pregunta comercial, no solo técnica

Para desarrolladores e inversionistas, las consecuencias pueden ser significativas. Un diseño puede ser técnicamente viable y, al mismo tiempo, cargar riesgos a nivel de sistema que afectan el CAPEX, el consumo de energía, la capacidad de TI disponible, la resiliencia, los permisos, la escalabilidad, la puesta en marcha y el cronograma. Esas consecuencias, advierte el ingeniero, suelen emerger tarde si las interfaces no se cuestionan a tiempo.

La integración de sistemas, insiste, es más que coordinación de ingeniería: es también una forma de proteger la economía del proyecto y reducir el riesgo de que decisiones tomadas de manera independiente en distintos frentes de trabajo generen consecuencias costosas más adelante.

El vínculo con la preparación del proyecto

Esta lógica se vuelve especialmente relevante antes de las grandes decisiones de desarrollo y capital. Un proyecto puede reportar capacidad eléctrica adecuada basándose en un supuesto de refrigeración determinado; una decisión posterior sobre refrigeración puede cambiar ese requisito eléctrico. Una arquitectura de respaldo puede ser técnicamente factible y, al mismo tiempo, introducir restricciones de permisos o emisiones que afecten el cronograma. Un diseño puede satisfacer la carga de TI actual y dejar poca flexibilidad para fases posteriores.

En cada caso, una dependencia que parecía resuelta puede volver a ser incierta cuando cambia otra parte del sistema. Por eso, según Bernardino, la integración de sistemas y la preparación de proyectos de infraestructura están estrechamente conectadas: esta última no depende solo de si cada disciplina avanza, sino de si los supuestos que las conectan siguen siendo técnica y comercialmente consistentes entre sí.

La pregunta antes de congelar la arquitectura

Antes de comprometer capital significativo en un desarrollo de centro de datos a gran escala, Bernardino propone una pregunta central: ¿se optimizaron los principales sistemas de infraestructura de manera individual, o se evaluó la instalación como un solo sistema interactuante?

Esa diferencia, sostiene, puede determinar cuánta energía necesita realmente la instalación, cuánta capacidad puede entregarse finalmente a TI, qué tan resiliente es en la práctica la arquitectura, con qué facilidad puede expandirse el sitio y cuánto capital se requerirá para hacer que todos esos sistemas funcionen juntos.

«Un centro de datos no es una colección de sistemas eléctricos, mecánicos y de control», concluye. «Es un solo sistema de infraestructura cuyo desempeño depende de la calidad de las decisiones tomadas en cada interfaz.» Antes de congelar la arquitectura, dice, queda una última pregunta por responder: quién está verificando si las interfaces entre energía, refrigeración, controles y operaciones están generando costos o restricciones ocultas en algún otro punto del proyecto.

Seguiremos brindándote más información sobre este tema en las siguientes presentaciones físicas y digitales de Channel News Perú

Mantente conectado a nuestra plataforma de negocios y revista, haciendo clic aquí y suscribiéndote a nuestro newsletter para contenido de valor diario

Digiqole Ad
...

Notas Relacionadas