Системы 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 соседа, для обеспечения корректной работы и правильного выключения без попыток ненужного кластерного тэйковера в случае общего отказа по питанию системы целиком.
Вот только по Фрейду оговорка получилась - не Silicon, а просто Silcon. :)
Это не “по Фрейду”, что бы вы под этим ни понимали, это просто пальцы пишут грамматически правильно, несмотря на все маркетологические изыски в области трейдмарков. Поправил.
“Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились _в той же IP-подсети_, что и контроллер NetApp”
Можете пояснить причину такой рекомендации? Какое отношение IP подсеть имеет к аварийному завершению?
Так уж написано в документации.
Подозреваю, что причина в первую очередь в стремлении минимизировать вовлеченную в процесс сетевую инфраструктуру, чтобы не получить ситуацию, когда подсеть управления UPS в результате отключения питания отвалилась оттого, что обесточился роутер, обеспечивающий передачу между подсетями.
Хм. В очередной раз вижу, что best practices NetApp нужно читать очень вдумчиво, а в сетевой части - вообще игнорировать от греха подальше…
В современной инфраструктуре датацентра/серверной, с большой вероятностью никакого отдельного маршрутизатора (router) между подсетями СХД и ??БП не будет, а будет L3-коммутация на том же коммутаторе, что и L2.
Предлагаю изложить в следующей редакции: ;)
Учитывая это, следует устроить сеть управления таким образом, чтобы всё сетевое оборудование на пути от UPS до контроллера NetApp было подключено к UPS, и в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.
Собственно такая рекомендация и так записана в документации к APC Network Shutdown, насколько я помню.
Кстати, а какие действия будут производиться при потере контакта с UPS? Вышеупомянутый APC NS достаточно гибко позволяет себя настроить, и при этом достаточно интеллектуально обрабатывает возникающие внештатные ситуации - например можно настроить выключение в случае, если после получения сигнала о переходе на батарею была потеряна связь с ??БП, но игнорировать потерю связи в случае, если работаем от сети.