Как управлять энергопотреблением датацентра

    Традиционный способ мониторинга энергопотребления в датацентре — использование «умных» блоков розеток, Power Distribution Units (PDU).



    К каждому можно подсоединиться по сети или через консоль, посмотреть потребление на сегменте или на отдельной розетке, прекрасные возможности. Производители прилагают соответствующие программные пакеты или даже целые специализированные серверы, например SPM от Server Technology.

    Можно нарисовать красивую схему датацентра, расположение серверов и строить разные графики. Ценник к ним прилагается соответствующий, негуманный.

    Смотреть сколько потребляет датацентр по ним можно, но и только. Как быть, если потреблением хочется управлять?

    Использовать встроенные возможности сервера!


    Как сервер мониторит и управляет энергопотреблением

    Современный сервер позволяет смотреть потребляемую мощность через средства IPMI:
    ~> sudo ipmitool sdr Power Unit | 150W | ns
    Либо через raw команды, но тоже можно.

    Такая возможность появилась благодаря технологии Intel Node Manager, которая была представлена с платформой Nehalem, серия Xeon 5500. В свою очередь, она опирается на возможности умных блоков питания и управление через шину PMbus.



    Базой со стороны сервера служат возможности Intel Management Engine и BMC (OCP обходится и без BMC):


    Соединения сервисных шин сервера

    Управление потребляемой мощностью сервера осуществляется через изменение состояний мощности и троттлинга процессора (P-states и T-states), также есть возможность ставить ограничения на потребление памяти, но появилась она только в последней ревизии, вместе с процессорами E5.


    Сравнение версий NM, RMLY — Xeon E5, BRLW — Xeon E3

    Итого, что можно получить:
    1. Мониторинг потребления в динамике. Intel Intelligent Power Node Manager измеряет потребление платформы с приемлемой погрешностью в ± 10%. Сбор данных идет через Power Supply Management Interface (PSMI) в реальном времени.
    2. Ограничение мощности платформы, power capping. Платформу можно ограничить по потреблению «сверху», выставив предел, свыше которого она не будет потреблять. Политика выставляется через IPMI/DCMI консоль и ограничивается потребление процессоров через работу с P-states. Ограничение работает для процессоров и памяти.
    3. Рассылка предупреждений о превышении потребления. Если не удается уложиться в назначенный целевой бюджет — на консоль управления будет послано предупреждение.


    В стоечных решениях Open Compute Platform и Open CloudServer можно ограничить потребление через контроллеры стойки.

    Ограничение потребления (Power Capping)

    Это наиболее интересная и важная технология в управлении энергопотреблением.

    В линейке процессоров Intel есть процессоры с разным термопакетом, есть и специальные модели серии L с пониженным потреблением. Вы получаете процессор, который никогда не выходит за пределы определенной мощности, но при этом имеет меньшую производительность при аналогичной или более высокой стоимости по сравнению с обычными процессорами.

    Есть ли в них смысл?

    Как показало тестирование на anandtech — нет.

    Поскольку физику обмануть не получается, то для выполнения одинакового объема работы требуется одинаковое количество энергии (плюс разница из-за скорости перехода процессоров/памяти в малопотребляющие состояния). Суммарное потребленное значение будет таково, что за время эксплуатации сервера разница в стоимости процессора не окупится.

    Выставив Power Cap на сервер с обычным процессором, вы получите тот же результат, что и при использовании моделей с пониженным потреблением.

    Для чего же нужен Power Cap?

    Для сглаживания бросков потребления. Причем удобно ограничивать не сервер, а целую стойку. Серверы загружены неравномерно, поэтому часть может брать больше среднего значения, часть меньше — главное, чтобы суммарное не выходило за пределы. Производительность от этого почти не пострадает (кроме случая, когда требуется полная загрузка всех систем и TurboBoost), а потребление стойки упадет. Самое главное, что потребление в ЦоД станет гораздо более предсказуемым и в одну стойку можно поставить больше систем.

    Обоснование этого тезиса явно видно все из того же тестирования Anandtech. Сервер, где работает технология ускорения процессора TurboBoost, обеспечивает заметно меньшее время отклика на запросы по сравнению с машиной, жестко ограниченной «сверху». Стойка, где загрузка систем неравномерна, будет работать лучше, а в случае длительной высокой нагрузки — даст некоторое ухудшение времени отклика при стабильной производительности систем. В этом случае экономия места по данным Intel может составить 20% и выше.

    Конечно, нет смысла ограничивать процессоры ниже их термопакета кроме тех случаев, когда для вас время отклика не имеет значения и средняя загрузка процессоров существенно ниже максимальной производительности, но при этом есть необходимо уместить как можно больше систем в стойку.

    Итого, можно подвести ряд преимуществ использования технологий управления потреблением:
    1. Увеличенная плотность стоек: управление энергобюджетом сервера в зависимости от реальной нагрузки в системе управления ЦоД позволяет пустить резервы неиспользуемой мощности на дополнительные серверы в стойке
    2. Максимизация производительности при скачках энергопотребления и температуры: динамическое управление потреблением сервера позволяет выделить больше ресурсов на критически важные задачи, снизив производительность второстепенных
    3. Снижение энергопотребления: система управления охлаждением получает реальные данные об энергопотреблении и температуре серверов, снижая производительность в зависимости от потребностей
    4. Появляется возможность балансировки: энергопотребление и температуру сервера можно включить в систему управления облаком или виртуальной средой для балансирования загрузки между стойками.



    Каким инструментом управлять этими функциями удобно?

    Intel DCM: Energy Director

    Intel предоставил продукт DataCenter Manager, который разделился на два — DCM: Energy Director и DCM: Virtual KVM Gateway. Помимо функционала мониторинга с web-интерфейсом, он еще является инструментарием, который можно интегрировать в собственную среду разработку.


    Основная панель

    Возможности и преимущества DCM: Energy Director

    Простота инсталляции
    • Установка за несколько минут с минимальными системными требованиями
    • Сканирование сети и добавление устройств в автоматическом или ручном режиме
    • Удобный графический интерфейс с простым добавлением новых стоек, рядов стоек и комнат датацентра для визуализации инфраструктуры

    Собирает данные о потреблении в реальном времени
    • Данные собираются в режиме Out-of-Band
    • Не требует доступа к ОС на клиенте
    • Собирает статистику за длительный период времени для построения тенденций и анализа

    Средства для анализа
    • Идентификация горячих и холодных зон в ЦоД помогает снизить ущерб от избыточной работы систем охлаждения
    • Обнаружение недогруженных систем, которые могут принять дополнительную нагрузку или быть ограниченными по потреблению
    • Визуализация энергопотребления сервера для оценки влияния изменений в политике управления питанием на потребление устройства

    Хранение истории
    • Данные статистики хранятся год (по умолчанию)
    • Данные по потребление и температуре сводятся для просмотра на уровне комнаты, ряда стоек и отдельной стойки.
    • Экспорт данных позволяет интегрировать DCM со сторонними инструментами анализа

    Система предупреждений и управления
    • Создает предупреждения и направляет их в другие инструменты управления
    • Применяет политики потребления для вскрытия резерва подведенной мощности без ущерба производительности
    • Позволяет применять политики потребления для снижения риска подвода избыточной мощности к серверу


    Вот как это выглядит вживую:


    Добавление обнаруженных серверов в стойку датацентра


    Создание политики энергопотребления


    Вид датацентра


    Создание порогов для реагирования

    Советы по оптимизации

    Мониторинг Мониторинг потребляемой мощности и температуры на входе с агрегацией данных по стойкам, линиям и комнатам

    Пользовательские физически или логические группы

    Получение оповещений о пользовательских событиях, относящихся к электропитанию и температуре

    Алгоритм расчета энергопотребления для устаревших серверов, не имеющих мониторинга питания

    Отображение тэгов активов и серийного номера сервера для ряда производителей
    Отслеживание тенденций Ведение журнала по электропитанию и температуре, запросы на расчет трендов с фильтрацией

    В целях планирования емкости хранятся данные за один год
    Контроль Интеллектуальный патентованный механизм групповых политик

    Поддерживаются одновременно несколько активных типов политик электропитания на различных уровнях иерархии

    Назначение приоритетов по нагрузке поддерживается как директивная политика

    Позволяет составлять расписание применения политик, включая ограничение мощности по времени суток и/или дню недели

    Поддерживает ограничение мощности по группам, динамически
    адаптируясь к изменяющейся нагрузке сервера

    Intel® Node Manager 2.0 поддерживает ограничение питания памяти и динамическое размещение ядер
    Отсутствие агента Не требует установки на управляемые узлы каких-либо программных агентов
    Простая интеграция и сосуществование Система учета устройств предварительно сканирует используемый диапазон IP-адресов

    Выделяются прикладные интерфейсы программирования высокоуровневых языков описания веб-служб (WSDL)

    Может находиться на независимом управляющем сервере или сосуществовать на одном сервере с продуктом ISV

    Планирование электропитания с учетом температурного режима: моделирование входной и выходной температур (зависит от производителя)

    Термодатчик на воздушном выхлопе (зависит от производителя)
    Масштабируемость Способность управлять десятками тысяч серверов
    Безопасность Защищенные API

    Безопасные каналы связи с управляемыми узлами

    Шифрование всех важных данных


    DCM: Energy Director работает на всех серверах нашего производства и доступен для опытной и боевой эксплуатации.
    • +6
    • 10,3k
    • 2
    ETegro Technologies
    20,68
    Компания
    Поделиться публикацией

    Комментарии 2

      +1
      Хм, вот какая мысль возникла:
      1. Хлеб — продукт первого порядка — нужен для пропитания
      2. Компьютер — продукт второго порядка — нужен для правильного планирования выращивания хлеба
      3. Вышеописанная система — продукт третьего (?) порядка…
        0
        Оптимизация инструмента оптимизации

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое