Инженерные системы наших дата-центров, часть 2
Trace Mode и с чем его едят
Повторюсь, изначально в в первом дата-центре выраженного мониторинга не было, а необходимость в нем была. И воплощать эту потребность решили сперва на базе уже строящегося «Миран-2», который планировался еще и модульным. Проектировщики и интеграторы предложили в качестве SCADA использовать отечественный Trace Mode. Данный продукт на тот момент мог удовлетворить все хотелки в плане мониторинга, был относительно простым в дальнейшей разработке (ежели бы такая необходимость возникла… и она-таки возникла) и стоил вроде бы не очень больших денег. В общем, неплохой вариант для простой системы.
АРМ дежурного ЦОД «Миран-2».
Trace Mode являет собой вполне классической образчик SCADA, имеет в себе ядро-сервер, опрашивающий циклично все необходимые железки по сети и клиент-консоли на АРМах дежурных, которые всю жизненную информацию от сервера и выводят, в виде различных мнемосхем. Такой вариант исполнения был использован для мониторинга «Миран-2» в целом. Для модульных ЦОД внутри (их пока у нас два) — был использован вариант с «тонкими» клиентами (java-апплет в браузере).
Фото панели с «тонким» клиентом в браузере и панели с клиент-консолью.
Кратко расскажу о внутренней структуре проектов. Есть условно два уровня:
Trace Mode IDE. «Источники/Приемники».
Trace Mode IDE. «Каналы».
Это и есть ядро SCADA.
Конечно же в Trace Mode есть также возможность писать подпрограммы на общепринятых промышленных языках (ST, LD, FBD), создавать отчеты, рассылать SMS и E-mail.
Изначально, мониторинг от интегратора был довольно прост. Самый минимум: данные о состоянии вводных и вспомогательных автоматов, данные по энергопотреблению, показания температурных датчиков и датчиков влажности, состояние кондиционеров и ИБП, а также (один из важнейших параметров) — по-стоечный расчет энергопотребления.
Т.к. система, конечно же, была неидеальна и страдала от всяческих недоработок, ее нужно было поддерживать и совершенствовать. Здесь на сцене и появляется ваш покорный слуга. Основной моей задачей стало свести количество ошибок в системе к минимуму, а в последующей перспективе — добавить новых глюков фич, которые должны облегчить эксплуатацию всей инженерной инфраструктуры наших дата-центров.
Перво-наперво, система мониторинга была «причесана и вылизана», а именно: исправлены всяческие «очепятки», приведены в соответствие порядок чисел (200 градусов Цельсия в холодном коридоре превращаются в 20,0), найден консенсус, в чем же мы меряем потребление в стойках — в кВт или все-таки в кВА. Спойлер!
Вторым эшелоном шли исправления стратегические. Например, в первоначальной версии проекта первого модульного ЦОД не было никакой индикации о состоянии его ИБП, в норме ли они или уже отключились в аварийном состоянии из-за поломки. Был расширен список возможных аварийных ситуаций и сообщений о многих узлах ЦОД. Мнемосхемы обрастали различными значками, индикаторами и дополнительными параметрами, в общем, всем, что должно было помочь понять — здоров или нет дата-центр.
Основная мнемосхема ЦОД «Миран-2»
Основная мнемосхема ЦОД «Миран-1»
Мнемосхема состояния ИБП узла связи «Миран-2»
Мнемосхема ДГУ-1 «Миран-2»
Всплывающая мнемосхема модульного ЦОД «Модуль-2»
Огромные панели с мигающими мнемосхемами — это очень круто и хорошо, но дежурный все же человек, которому свойственно уставать, забывать и не замечать. Системы мобильных ЦОД не имеют, к сожалению, журнала тревог, поэтому было решено реализовать рассылку аварийных писем, как службе главного инженера, так и в тикетную систему нашей тех.поддержки. В последствии, к этому еще добавилась и оповещающая сирена.
Крутые метрики и все-все-все
После года шлифовки проектов Trace Mode, был достигнут некий удобоваримый компромисс между «хотим красиво, современно и круто» и «реализовали как смогли и как получилось». В целом, система справлялась с мониторингом и оповещением по текущему состоянию, но хотелось иметь и возможность простейшего анализа климатики и энергопотребления.
Т.к. системы модульных ЦОД были оснащены только лишь «тонкими» клиентами и графиков и трендов они не поддерживали (опять же), хоть какой-то анализ был выполнен в виде суточных отчетов на E-mail`ы службы главного инженера (с простейшими табличками, заполненных мин/максами значений по датчикам температур и энергопотребления стоек). Наглядность, впрочем, все равно оставляла желать лучшего. Ко всему прочему, еще одним камнем преткновения стала нестабильная работа собственных архивов Trace Mode, из которых эти данные извлекались.
Перебрав несколько вариантов решения всего этого безобразия, было решено остановиться на варианте с отгрузкой данных из Trace Mode во внешнюю БД для дальнейшей обработки.
Когда я уже хотел приступать к реализации вышеозначенного варианта, наш главный инженер наткнулся на просторах интернета на сайт grafana. Дружно повздыхав над красотой графиков, мы сошлись на том, что-де реализовать подобное под наши нужды на текущей платформе — затруднительно. Тем не менее, grafana крепко засела у меня в голове и я стал искать любые гайды с описанием реализованных решений с ее участием. Переломными стали несколько статей на хабре: 1 и 2 (Хабр окрыляет помогает!) с упоминанием демона collectd и его плагинов.
Теперь уже вполне себе вызрела идея как все это реализовать под наши нужды.
Под все это дело был выделен скучающий от низкой нагрузки blade-сервер и развернута тестовая Ubuntu со всем необходимым набором софта. После этого настал черед заполнить конфиг collectd на предмет что и как ему опрашивать. Ниже некоторые выдержки из конфига. Ничего особенного, все строго в соответствии с документацией по демону и плагинам:
Содержимое файла конфигурации для collectd
Дашборд главного ВРУ «Миран-2».
Дашборд с наиболее важными параметрами «Модуль-2».
Дашборд с климатическими трендами «Модуль-2».
Дашборд с трендами по потреблению стоек «Модуль-1».
Подводя итоги
Итак, текущие плюсы решения на collectd + graphite + grafana в сравнении с Trace Mode:
Минусы:
Пока решено оставить систему мониторинга неким гибридом из классической SCADA Trace Mode со своими клиент-приложениями и серверами как скрытого от посторонних ядра с АСУ и АСМ и внешней обертки grafana с красивыми и удобными метриками, доступной всем внутри корпоративной сети. К чему в итоге мы придем — покажет время, разных инженерных задач еще хватает.
Повторюсь, изначально в в первом дата-центре выраженного мониторинга не было, а необходимость в нем была. И воплощать эту потребность решили сперва на базе уже строящегося «Миран-2», который планировался еще и модульным. Проектировщики и интеграторы предложили в качестве SCADA использовать отечественный Trace Mode. Данный продукт на тот момент мог удовлетворить все хотелки в плане мониторинга, был относительно простым в дальнейшей разработке (ежели бы такая необходимость возникла… и она-таки возникла) и стоил вроде бы не очень больших денег. В общем, неплохой вариант для простой системы.
АРМ дежурного ЦОД «Миран-2».
Trace Mode являет собой вполне классической образчик SCADA, имеет в себе ядро-сервер, опрашивающий циклично все необходимые железки по сети и клиент-консоли на АРМах дежурных, которые всю жизненную информацию от сервера и выводят, в виде различных мнемосхем. Такой вариант исполнения был использован для мониторинга «Миран-2» в целом. Для модульных ЦОД внутри (их пока у нас два) — был использован вариант с «тонкими» клиентами (java-апплет в браузере).
Фото панели с «тонким» клиентом в браузере и панели с клиент-консолью.
Кратко расскажу о внутренней структуре проектов. Есть условно два уровня:
- нижний уровень, опрос устройств. Осуществляется «Источниками/Приемниками» — некие структурные шаблоны, которые определяют различные протоколы, технологии и интерфейсы (Modbus RTU/TCP-IP, SNMP, DDE, OPC etc.), содержат настройки связи. В общем, являются софтварным отражением периферии.
- верхний уровень, тэги. В Trace Mode они называются «Каналами». Эти шаблоны уже определяют тип параметра, получаемого от «Источников» (дискретный/аналоговый), задают для него масштабирование, аварийные/предаварийные пределы (для аналоговых сигналов), назначают привязку к словарям аварийных сообщений, наконец, «каналы» же устанавливают будет ли данный параметр архивироваться или нет. Соответственно, к различным графическим элементам на мнемосхемах эти «каналы» можно привязать для оперативного мониторинга.
Trace Mode IDE. «Источники/Приемники».
Trace Mode IDE. «Каналы».
Это и есть ядро SCADA.
Конечно же в Trace Mode есть также возможность писать подпрограммы на общепринятых промышленных языках (ST, LD, FBD), создавать отчеты, рассылать SMS и E-mail.
На заметку.
Все продукты в семействе Trace Mode защищены HASP-ключами. Для работы в IDE требуется свой ключ, лимитирующий в проекте количество источников данных (e.g. лицензия на 128, 256, 512… N устройств). Для работы МРВ требуется свой ключ. Он лимитирует максимальное количество «каналов» в скомпилированном проекте; в подмножество каналов, помимо самих каналов, входят и вызовы программ, шаблонов экранов. Также ключ определяет доступность некоторых технологий, у нас, в частности, возможность запуска OPC-сервера Trace Mode. Для клиент-консолей, которые используются в АРМах, ключ лимитирует число экранов (в проекте дюжина мнемосхем, а ключ на десять? Два экрана перестанут вызываться). «Тонкие» клиенты? Ну вы поняли, ограничения на кол-во одновременных подключений, шаблонов документов...
Изначально, мониторинг от интегратора был довольно прост. Самый минимум: данные о состоянии вводных и вспомогательных автоматов, данные по энергопотреблению, показания температурных датчиков и датчиков влажности, состояние кондиционеров и ИБП, а также (один из важнейших параметров) — по-стоечный расчет энергопотребления.
Т.к. система, конечно же, была неидеальна и страдала от всяческих недоработок, ее нужно было поддерживать и совершенствовать. Здесь на сцене и появляется ваш покорный слуга. Основной моей задачей стало свести количество ошибок в системе к минимуму, а в последующей перспективе — добавить новых глюков фич, которые должны облегчить эксплуатацию всей инженерной инфраструктуры наших дата-центров.
Перво-наперво, система мониторинга была «причесана и вылизана», а именно: исправлены всяческие «очепятки», приведены в соответствие порядок чисел (200 градусов Цельсия в холодном коридоре превращаются в 20,0), найден консенсус, в чем же мы меряем потребление в стойках — в кВт или все-таки в кВА. Спойлер!
Вторым эшелоном шли исправления стратегические. Например, в первоначальной версии проекта первого модульного ЦОД не было никакой индикации о состоянии его ИБП, в норме ли они или уже отключились в аварийном состоянии из-за поломки. Был расширен список возможных аварийных ситуаций и сообщений о многих узлах ЦОД. Мнемосхемы обрастали различными значками, индикаторами и дополнительными параметрами, в общем, всем, что должно было помочь понять — здоров или нет дата-центр.
Основная мнемосхема ЦОД «Миран-2»
Основная мнемосхема ЦОД «Миран-1»
Мнемосхема состояния ИБП узла связи «Миран-2»
Мнемосхема ДГУ-1 «Миран-2»
Всплывающая мнемосхема модульного ЦОД «Модуль-2»
Огромные панели с мигающими мнемосхемами — это очень круто и хорошо, но дежурный все же человек, которому свойственно уставать, забывать и не замечать. Системы мобильных ЦОД не имеют, к сожалению, журнала тревог, поэтому было решено реализовать рассылку аварийных писем, как службе главного инженера, так и в тикетную систему нашей тех.поддержки. В последствии, к этому еще добавилась и оповещающая сирена.
Крутые метрики и все-все-все
После года шлифовки проектов Trace Mode, был достигнут некий удобоваримый компромисс между «хотим красиво, современно и круто» и «реализовали как смогли и как получилось». В целом, система справлялась с мониторингом и оповещением по текущему состоянию, но хотелось иметь и возможность простейшего анализа климатики и энергопотребления.
Т.к. системы модульных ЦОД были оснащены только лишь «тонкими» клиентами и графиков и трендов они не поддерживали (опять же), хоть какой-то анализ был выполнен в виде суточных отчетов на E-mail`ы службы главного инженера (с простейшими табличками, заполненных мин/максами значений по датчикам температур и энергопотребления стоек). Наглядность, впрочем, все равно оставляла желать лучшего. Ко всему прочему, еще одним камнем преткновения стала нестабильная работа собственных архивов Trace Mode, из которых эти данные извлекались.
Перебрав несколько вариантов решения всего этого безобразия, было решено остановиться на варианте с отгрузкой данных из Trace Mode во внешнюю БД для дальнейшей обработки.
Когда я уже хотел приступать к реализации вышеозначенного варианта, наш главный инженер наткнулся на просторах интернета на сайт grafana. Дружно повздыхав над красотой графиков, мы сошлись на том, что-де реализовать подобное под наши нужды на текущей платформе — затруднительно. Тем не менее, grafana крепко засела у меня в голове и я стал искать любые гайды с описанием реализованных решений с ее участием. Переломными стали несколько статей на хабре: 1 и 2 (Хабр окрыляет помогает!) с упоминанием демона collectd и его плагинов.
Теперь уже вполне себе вызрела идея как все это реализовать под наши нужды.
Под все это дело был выделен скучающий от низкой нагрузки blade-сервер и развернута тестовая Ubuntu со всем необходимым набором софта. После этого настал черед заполнить конфиг collectd на предмет что и как ему опрашивать. Ниже некоторые выдержки из конфига. Ничего особенного, все строго в соответствии с документацией по демону и плагинам:
Содержимое файла конфигурации для collectd
# Config file for collectd(1).
#
# Some plugins need additional configuration and are disabled by default.
# Please read collectd.conf(5) for details.
#
# You should also read /usr/share/doc/collectd-core/README.Debian.plugins
# before enabling any more plugins.
Hostname "graphite"
FQDNLookup true
#BaseDir "/var/lib/collectd"
#PluginDir "/usr/lib/collectd"
TypesDB "/usr/share/collectd/types.db" "/etc/collectd/my_types.db"
Interval 10
#Interval 60
#Timeout 2
#ReadThreads 5
LoadPlugin logfile
LoadPlugin cpu
LoadPlugin disk
LoadPlugin memory
LoadPlugin modbus //тот самый плагин
LoadPlugin snmp
LoadPlugin write_graphite
#LoadPlugin email
#LoadPlugin sensors
#LoadPlugin serial
<Plugin logfile>
LogLevel "info"
File STDOUT
Timestamp true
PrintSeverity true
</Plugin>
<Plugin modbus>
#DC2 VRU Data -------------------------------------------------
<Data "VRU-QF1-Status">
RegisterBase 380
RegisterType int16
Type word
Instance "VRU-QF1-Status"
</Data>
<Data "VRU-QF2-Status">
RegisterBase 381
RegisterType int16
Type word
Instance "VRU-QF2-Status"
</Data>
…
<Data "VRU1-U-AN">
RegisterBase 300
RegisterType int16
Type voltage
Instance "VRU1-U-AN"
</Data>
<Data "VRU1-U-BN">
RegisterBase 301
RegisterType int16
Type voltage
Instance "VRU1-U-BN"
</Data>
<Data "VRU1-U-CN">
RegisterBase 302
RegisterType int16
Type voltage
Instance "VRU1-U-CN"
</Data>
<Host "DC2_PLC">
Address "XXX.XXX.XXX.XXX"
Port "502"
Interval 5
<Slave 1>
Instance "Vars"
Collect "VRU-QF1-Status"
Collect "VRU-QF2-Status"
...
Collect "VRU1-U-AN"
Collect "VRU1-U-BN"
Collect "VRU1-U-CN"
...
</Slave>
</Host>
<Plugin snmp>
# DC2_Module1_UPS1 -------------------------------------------------
<Data "UPS1_load_A">
Type "percent"
Table false
Instance "Load_A"
Values ".1.3.6.1.2.1.33.1.4.4.1.5.1"
</Data>
<Data "UPS1_load_B">
Type "percent"
Table false
Instance "Load_B"
Values ".1.3.6.1.2.1.33.1.4.4.1.5.2"
</Data>
<Data "UPS1_load_C">
Type "percent"
Table false
Instance "Load_C"
Values ".1.3.6.1.2.1.33.1.4.4.1.5.3"
</Data>
...
<Host "DC2_Module1_UPS1">
Address "XXX.XXX.XXX.XXX"
Version 1
Community "public"
Collect "UPS1_load_A"
Collect "UPS1_load_B"
Collect "UPS1_load_C"
...
Interval 5
</Host>
<Plugin write_graphite>
<Carbon>
Host "localhost"
# Port "2003"
Prefix "collectd."
Protocol "tcp"
# Postfix "collectd"
# StoreRates false
# AlwaysAppendDS false
# EscapeCharacter "_"
</Carbon>
</Plugin>
Include "/etc/collectd/collectd.conf.d/*.conf"Дашборд главного ВРУ «Миран-2».
Дашборд с наиболее важными параметрами «Модуль-2».
Дашборд с климатическими трендами «Модуль-2».
Дашборд с трендами по потреблению стоек «Модуль-1».
Подводя итоги
Итак, текущие плюсы решения на collectd + graphite + grafana в сравнении с Trace Mode:
- Бесплатно (финдир вытирает скупую мужскую слезу счастья).
- Open Source. Можно теоретически добавить недостающую фичу, написав ее самому.
- Доступность. По сути, это страничка в браузере для конечного пользователя, а, следовательно, есть у каждого в гаджете в кармане. В Trace Mode поддержки для гаджетов толком нет.
- Простота и удобство расширения. Достаточно при первоначальной настройке collectd + graphite «скормить» им все необходимые данные — и последующие получившиеся метрики можно редактировать и преобразовывать на лету прямо в grafana. Скажем «Нет!» компиляциям МРВ и клиент-консолей в Trace Mode!
- Очень неплохие возможности по отображению и анализу графиков «из коробки». Trace Mode в этом плане крайне, хм, консервативен.
- Есть оповещения и уведомления об аварийных ситуациях во всех новомодных чатиках, по почте etc. Trace Mode же может рассылать E-mail`ы и за отдельную денежку — SMS (если у вас есть необходимое железо).
Минусы:
- Полновесную SCADA подобной связкой не заменить. Никакого управления тех.процессом. Если, конечно, управление Вам необходимо.
- Open Source. Ваш покорный слуга не имеет надлежащей квалификации для дописания хотелок, а посему смиренно ждет и/или просит более умных товарищей в git-сообществе.
- Набор панелей невелик (хоть и расширяется за счет плагинов).
- Движок алертинга пока очень прост, хитрых условий в нем не настроишь. Разработчики обещают расширить функционал.
Пока решено оставить систему мониторинга неким гибридом из классической SCADA Trace Mode со своими клиент-приложениями и серверами как скрытого от посторонних ядра с АСУ и АСМ и внешней обертки grafana с красивыми и удобными метриками, доступной всем внутри корпоративной сети. К чему в итоге мы придем — покажет время, разных инженерных задач еще хватает.
0 комментариев
Вставка изображения
Оставить комментарий