Как можно выключить (отключить) узлы кластера при низкой нагрузке?

Как можно выключить (отключить) узлы кластера при низкой нагрузке?

Я разрабатываю программное обеспечение для консалтингового бизнеса в сфере энергетики и занимаюсь мониторингом использования энергии в центрах обработки данных, я заметил, что типичная электрическая «модель» нагрузки центра обработки данных — это просто ровная линия, потому что все оборудование работает 24/7. Если вы сравните это с фактической моделью использования (сетевая нагрузка, использование ЦП и т. д.), что мы и делали, вы регулярно будете иметь длительные периоды с небольшим использованием, но при этом доступной полной мощностью.

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

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

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

Для моих целей кластер не обязательно означает кластеризацию машин на уровне ОС, идентичные хосты, которые получают запросы через балансировщик нагрузки (т.е. кластеризация на уровне приложений), также будут учитываться. Я не уверен, как работает кластер MySQL или что-то подобное, но я бы, вероятно, тоже их посчитал.

Мне нужен совет по любой операционной системе.

См. также мойпост об энергоэффективностина Stack Overflow, где был поднят этот вопрос.

решение1

Власть

ИспользоватьКоммутируемые блоки распределения питаниятак что вы можете включать и выключать серверы и коммутаторы вне диапазона. Это не зависит от ОС и устройств, что значительно упростит конфигурацию и логику включения и выключения. Если все ваши серверы имеют сетевые интерфейсы IPMI, вы можете использовать их. Я бы не рекомендовал пытаться включать и выключать что-либо с помощью более высокоуровневых вещей, таких как wake-on-LAN.

Логика включения/выключения питания

Это может принимать различные формы. Некоторые кластерные программы (например,Моав) имеет встроенное решение для этой проблемы. В противном случае вы можете написать скрипт со следующим псевдокодом:

  1. Проверить общую нагрузку кластера
  2. Если нагрузка на кластер > threshold1, включить некоторые узлы
  3. Если нагрузка кластера < threshold2, отключить некоторые узлы

Добавьте это в cron и запускайте каждые полчаса.

Стек программного обеспечения кластеризации

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

решение2

VMware

Последняя версия их корпоративного продукта VSphere 4 может отключать хосты, которые не нужны для обеспечения пропускной способности, и пробуждать их при необходимости, распределяя виртуальные машины в режиме реального времени. Добавьте к этому экономию электроэнергии/мощности, которую вы получаете от консолидации оборудования на виртуализированной платформе, и вы получите значительную экономию электроэнергии.

решение3

Это было упомянуто на Planet Ubuntu только сегодня. Пост можно найтиздесь. В нем говорится о разработке практического решения для включения/выключения машин по требованию в облаке с использованиемPowerNap.

решение4

Ну, для серверов команда SHUTDOWN.EXE может быть использована для удаленного выключения Windows Box. То же самое можно легко сделать на Unix с помощью скрипта telnet/ssh.

Более серьезной проблемой будет то, как их снова запустить. Вам понадобитсяWake On LANили что-то подобное.

Самое сложное в этом — убедиться, что машины, которые вы выключаете, на самом деле не выполняют что-то важное. Например, то задание cron, о котором никто не был уверен, куда его следует направить, поэтому его просто поместили на один из кластерных веб-серверов. Теперь вы выключаете эту машину, и задание больше не выполняется так, как должно было.

Однако если среда жестко контролируется и вы точно знаете, что делает каждая машина, это имело бы большой смысл.

Связанный контент