Современный ЦОД умеет довольно хорошо сообщать, что с ним уже произошло. Температура выросла — пришла тревога. ИБП перегружен — появилась авария. Стойка запитана не так, как ожидалось, — это выяснилось в процессе работ.
Проблема в том, что для всё более плотных и дорогих вычислительных нагрузок такой стиль управления начинает напоминать вождение по зеркалам заднего вида. Видно хорошо, но в основном то, что уже осталось позади.
Следующий шаг в развитии эксплуатации — научиться отвечать не только на вопрос «что происходит?», но и на вопросы «что произойдёт, если…?» и «где мы ошибёмся, если ничего не менять?».
Проблема в том, что для всё более плотных и дорогих вычислительных нагрузок такой стиль управления начинает напоминать вождение по зеркалам заднего вида. Видно хорошо, но в основном то, что уже осталось позади.
Следующий шаг в развитии эксплуатации — научиться отвечать не только на вопрос «что происходит?», но и на вопросы «что произойдёт, если…?» и «где мы ошибёмся, если ничего не менять?».
Мониторинг полезен, но будущего он не знает
Большинство ЦОД сегодня всё ещё находятся на реактивном уровне зрелости: системы собирают телеметрию, показывают состояние оборудования, строят графики и поднимают тревоги. Это необходимый фундамент, но он плохо работает там, где инфраструктура меняется быстрее, чем успевает накопиться история.
Представим простую задачу: нужно поставить несколько высокоплотных стоек в уже работающий зал.
DCIM может показать, что свободное место есть, электрическая мощность формально доступна, а средняя температура в помещении находится в норме.
Но этого мало.
Нужно понять, как новая нагрузка изменит воздушные потоки, где появятся горячие зоны, выдержит ли охлаждение отказ одного агрегата, не окажется ли свободная мощность электрически доступной, но термически непригодной.
Исторические данные здесь помогают лишь частично. Новая конфигурация раньше не существовала — значит, наблюдать её поведение просто не из чего.
Представим простую задачу: нужно поставить несколько высокоплотных стоек в уже работающий зал.
DCIM может показать, что свободное место есть, электрическая мощность формально доступна, а средняя температура в помещении находится в норме.
Но этого мало.
Нужно понять, как новая нагрузка изменит воздушные потоки, где появятся горячие зоны, выдержит ли охлаждение отказ одного агрегата, не окажется ли свободная мощность электрически доступной, но термически непригодной.
Исторические данные здесь помогают лишь частично. Новая конфигурация раньше не существовала — значит, наблюдать её поведение просто не из чего.
Цифровой двойник — это не красивая 3D-картинка
Термин «цифровой двойник» успели использовать почти для всего, что имеет трёхмерную модель и пару датчиков. Но полезный цифровой двойник ЦОД — это не виртуальная экскурсия по машинному залу.
Он должен отражать реальное состояние объекта: состав и расположение оборудования, энергопотребление, связи, параметры охлаждения и данные датчиков. А главное — позволять моделировать поведение инфраструктуры при изменениях.
Здесь особенно важна физическая модель.
AI может увидеть корреляцию: когда растёт нагрузка на определённые стойки, температура в некоторой зоне обычно повышается. Это полезно.
Физическое моделирование идёт дальше. Оно пытается вычислить, почему температура вырастет и что произойдёт в конфигурации, которой раньше вообще не существовало.
Например: если добавить ещё 40 кВт в конкретный ряд, изменить положение стоек или отключить один кондиционер, как изменятся воздушные потоки и температура на входе серверов?
Тут уже недостаточно сказать: «похоже, станет жарче». Инженеру хотелось бы знать где именно, насколько и через сколько минут.
Он должен отражать реальное состояние объекта: состав и расположение оборудования, энергопотребление, связи, параметры охлаждения и данные датчиков. А главное — позволять моделировать поведение инфраструктуры при изменениях.
Здесь особенно важна физическая модель.
AI может увидеть корреляцию: когда растёт нагрузка на определённые стойки, температура в некоторой зоне обычно повышается. Это полезно.
Физическое моделирование идёт дальше. Оно пытается вычислить, почему температура вырастет и что произойдёт в конфигурации, которой раньше вообще не существовало.
Например: если добавить ещё 40 кВт в конкретный ряд, изменить положение стоек или отключить один кондиционер, как изменятся воздушные потоки и температура на входе серверов?
Тут уже недостаточно сказать: «похоже, станет жарче». Инженеру хотелось бы знать где именно, насколько и через сколько минут.
Главная проблема ЦОД — не всегда нехватка ресурсов
Есть любопытный парадокс: ЦОД может одновременно иметь свободную мощность, свободное место и запас охлаждения — и при этом не иметь места, куда безопасно установить новую нагрузку.
Причина в том, что эти ресурсы распределены неравномерно.
В одном ряду хватает питания, но не охлаждения. В другом есть холод, но закончились доступные порты или мощность. Третий выглядит свободным на плане, но уже живёт на границе допустимого режима.
Так возникает stranded capacity — ресурс вроде бы есть, но использовать его нельзя.
По приведённым в исследовании отраслевым оценкам, более 30% установленной мощности ЦОД может оставаться неиспользованной. Причина не только в избыточном проектировании, но и в том, что пространство, питание и охлаждение в реальной эксплуатации перестают совпадать там, где это нужно.
И вот здесь цифровая модель становится особенно полезной: она позволяет искать не свободный ресурс вообще, а совместимый набор ресурсов в конкретной точке.
Причина в том, что эти ресурсы распределены неравномерно.
В одном ряду хватает питания, но не охлаждения. В другом есть холод, но закончились доступные порты или мощность. Третий выглядит свободным на плане, но уже живёт на границе допустимого режима.
Так возникает stranded capacity — ресурс вроде бы есть, но использовать его нельзя.
По приведённым в исследовании отраслевым оценкам, более 30% установленной мощности ЦОД может оставаться неиспользованной. Причина не только в избыточном проектировании, но и в том, что пространство, питание и охлаждение в реальной эксплуатации перестают совпадать там, где это нужно.
И вот здесь цифровая модель становится особенно полезной: она позволяет искать не свободный ресурс вообще, а совместимый набор ресурсов в конкретной точке.
Иногда правильное решение выглядит совсем не очевидно
Показательный пример и сети — модернизация ЦОД крупной медицинской организации.
Площадка использовала только около 40% своей инфраструктурной мощности, но расчёты показывали: если продолжать размещать оборудование привычным способом, уже при 80% загрузки возникнет риск перегрева.
То есть половина ЦОДа вроде бы свободна, а пользоваться ей опасно.
Инженеры смоделировали три варианта размещения новой 96-киловаттной ИТ-нагрузки. Один из них обеспечивал стопроцентное соблюдение температурных требований и при этом требовал минимального расхода воздуха. Другой оставлял в допустимом температурном диапазоне менее 10% оборудования.
На плане оба варианта могли выглядеть вполне разумно.
Физике было виднее.
В результате организации удалось вернуть часть «запертой» мощности и избежать потери примерно 20% полезной инфраструктуры. Более того, моделирование стало обязательным для дальнейших внедрений мощностью свыше 10 кВт на стойку.
Площадка использовала только около 40% своей инфраструктурной мощности, но расчёты показывали: если продолжать размещать оборудование привычным способом, уже при 80% загрузки возникнет риск перегрева.
То есть половина ЦОДа вроде бы свободна, а пользоваться ей опасно.
Инженеры смоделировали три варианта размещения новой 96-киловаттной ИТ-нагрузки. Один из них обеспечивал стопроцентное соблюдение температурных требований и при этом требовал минимального расхода воздуха. Другой оставлял в допустимом температурном диапазоне менее 10% оборудования.
На плане оба варианта могли выглядеть вполне разумно.
Физике было виднее.
В результате организации удалось вернуть часть «запертой» мощности и избежать потери примерно 20% полезной инфраструктуры. Более того, моделирование стало обязательным для дальнейших внедрений мощностью свыше 10 кВт на стойку.
Авария тоже может быть смоделирована заранее
Ещё интереснее цифровой двойник становится, когда ему позволяют немного «сломать» ЦОД — разумеется, виртуально.
В одном из проектов моделировались нормальный режим, отказ части охлаждения и переходные процессы при исчезновении питания чиллеров. Проверялось, что произойдёт с температурой, если насосы и вентиляторы останутся на ИБП, а что — если нет.
Результат оказался небанальным.
При наличии резервного питания насосов и вентиляторов температурные ограничения сохранялись. Без него температура росла значительно быстрее. Причём логика регулирования, полезная в обычном режиме, в аварийном могла ухудшать ситуацию: ограничение скорости вентиляторов растягивало время достижения опасной температуры почти до 300 секунд, тогда как работа на полной мощности сокращала его примерно до 90 секунд.
Звучит парадоксально, но именно ради таких парадоксов и нужны модели. Они позволяют обнаружить ошибочную стратегию до того, как её проверит настоящий отказ.
В одном из проектов моделировались нормальный режим, отказ части охлаждения и переходные процессы при исчезновении питания чиллеров. Проверялось, что произойдёт с температурой, если насосы и вентиляторы останутся на ИБП, а что — если нет.
Результат оказался небанальным.
При наличии резервного питания насосов и вентиляторов температурные ограничения сохранялись. Без него температура росла значительно быстрее. Причём логика регулирования, полезная в обычном режиме, в аварийном могла ухудшать ситуацию: ограничение скорости вентиляторов растягивало время достижения опасной температуры почти до 300 секунд, тогда как работа на полной мощности сокращала его примерно до 90 секунд.
Звучит парадоксально, но именно ради таких парадоксов и нужны модели. Они позволяют обнаружить ошибочную стратегию до того, как её проверит настоящий отказ.
ЦОДу нужен не ещё один экран, а возможность задавать вопросы
Пожалуй, главная ценность цифрового двойника не в визуализации.
Она в возможности задавать инфраструктуре вопросы.
Что произойдёт, если добавить эту стойку?
Если отключится этот чиллер?
Если нагрузка вырастет на 20%?
Если переставить оборудование?
Если изменить алгоритм управления?
Если одна ветвь питания выйдет из строя?
Обычный мониторинг отвечает после события. Модель позволяет проверить сценарий заранее.
Именно поэтому следующий этап развития систем управления ЦОД — переход от наблюдения к прогнозированию, а затем к оптимизации.
Сначала система говорит: «здесь стало жарко».
Потом: «здесь становится жарко».
Следующий уровень — «если поставите стойку сюда, через десять минут станет жарко вот здесь».
А хороший инженер уже знает, насколько велика разница между этими тремя фразами.
Она в возможности задавать инфраструктуре вопросы.
Что произойдёт, если добавить эту стойку?
Если отключится этот чиллер?
Если нагрузка вырастет на 20%?
Если переставить оборудование?
Если изменить алгоритм управления?
Если одна ветвь питания выйдет из строя?
Обычный мониторинг отвечает после события. Модель позволяет проверить сценарий заранее.
Именно поэтому следующий этап развития систем управления ЦОД — переход от наблюдения к прогнозированию, а затем к оптимизации.
Сначала система говорит: «здесь стало жарко».
Потом: «здесь становится жарко».
Следующий уровень — «если поставите стойку сюда, через десять минут станет жарко вот здесь».
А хороший инженер уже знает, насколько велика разница между этими тремя фразами.