Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
?спользование NetApp с UPS | about NetApp

Системы NetApp и их работа с бесперебойниками (UPS)

Официально NetApp поддерживает совместимость только с UPS компании APC, до версии 7.2.1 это были модели SmartUPS (и Symmetra), с версии 7.3.2 добавились модели семейства Silcon. Вот официальный список:

Модель минимальная версия ONTAP
smartUPS250 6.5
smartUPS400 6.5
smartUPS600 6.5
smartUPS900 6.5
smartUPS1250 6.5
smartUPS2000 6.5
smartUPS450 6.5
smartUPS700 6.5
smartUPS1000 6.5
smartUPS1400 6.5
smartUPS2200 6.5
smartUPS3000 6.5
smartUPS5000 7.2.1
smartUPS7500 7.2.1
smartUPS10000 7.2.1
smartUPS15000 7.2.1

После 7.2.1 официальный список был упразднен, и теперь базовая поддержка со стороны ONTAP осуществляется для всех моделей указанных выше линеек APC. Понятие “поддержка в OS” означает, что Data ONTAP может осуществить корректное завершение работы (shutdown) при использовании UPS перечисленных типов.

?спользуя возможности взаимодействия с UPS в ONTAP следует учитывать, что NetApp не использует SNMP Trap при работе с UPS, вместо этого он использует SNMP Get. Состояние UPS проверяется каждые 5 минут по сети Ethernet, в которую подключен UPS, с использованием SNMP. При этом Data ONTAP получает следующие параметры UPS:

  • Работает ли он от сети, или находится на батареях
  • При нахождении на батареях, каково оценочное оставшееся время

Когда обнаруживается переключение на батареи, интервал проверок состояния сокращается до 10 секунд. Когда уровень батарей достигает уровня, определенного как “Warning-Low” начинают поступать сообщения в систему EMS (Enterprise Messaging System), когда уровень заряда батарей снижается до “Critical-Low” отсылается сообщение в EMS и начинается процедура shutdown.

Если контроллер NetApp отслеживает состояние нескольких UPS (например отдельно для контроллера, для дисковых полок, и для сетевого оборудования), то процедура shutdown начинается при достижении уровня “Critical-Low” на любом из этих UPS.

Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились в той же IP-подсети, что и контроллер NetApp, а сетевое оборудование также должно быть подключено к UPS, чтобы, в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.

Для управления UPS в консоли администратора есть команда ups:

ups add [-c <community>] <ip address>
ups [ disable | enable ] [ all | <ip address>]
ups status
ups set-limits [ all | <ip address>] <critical-time  (secs)><warn-time  (secs)>
ups print-limits [ all | <ip address>]

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

5 комментариев

  1. Andrew Ivanov:

    Вот только по Фрейду оговорка получилась - не Silicon, а просто Silcon. :)

  2. Это не “по Фрейду”, что бы вы под этим ни понимали, это просто пальцы пишут грамматически правильно, несмотря на все маркетологические изыски в области трейдмарков. Поправил.

  3. Korj:

    “Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились _в той же IP-подсети_, что и контроллер NetApp”
    Можете пояснить причину такой рекомендации? Какое отношение IP подсеть имеет к аварийному завершению?

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

  5. Korj:

    Хм. В очередной раз вижу, что best practices NetApp нужно читать очень вдумчиво, а в сетевой части - вообще игнорировать от греха подальше…
    В современной инфраструктуре датацентра/серверной, с большой вероятностью никакого отдельного маршрутизатора (router) между подсетями СХД и ?БП не будет, а будет L3-коммутация на том же коммутаторе, что и L2.

    Предлагаю изложить в следующей редакции: ;)
    Учитывая это, следует устроить сеть управления таким образом, чтобы всё сетевое оборудование на пути от UPS до контроллера NetApp было подключено к UPS, и в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.

    Собственно такая рекомендация и так записана в документации к APC Network Shutdown, насколько я помню.

    Кстати, а какие действия будут производиться при потере контакта с UPS? Вышеупомянутый APC NS достаточно гибко позволяет себя настроить, и при этом достаточно интеллектуально обрабатывает возникающие внештатные ситуации - например можно настроить выключение в случае, если после получения сигнала о переходе на батарею была потеряна связь с ?БП, но игнорировать потерю связи в случае, если работаем от сети.

Оставить комментарий

20/0.083

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.