Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 4
В предыдущих частях мы рассказывали, как создавали и внедряли новую систему мониторинга ЦОД. В итоге у нас появился мощный механизм отслеживания и ведения статистики всех параметров ЦОДа, влияющих на доступность его ресурсов и показатели бесперебойной работы.
Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной?
Проблема здесь в том, что функционал системы позволяет включить множество аварийных оповещений и сигналов — при таких настройках персонал будет вынужден постоянно реагировать на них, отрабатывая соответствующие сценарии.
Другой вариант: выставить недостаточное количество таких оповещений, создав риски для дежурных пропустить действительно важное событие.
В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.
Немного теории
«Собираемые системой SCADA переменные делятся на телесигнализацию и телеизмерения» –учили меня когда-то в институте. И на самом деле ничего не поменялось: телесигнализация — это состояние устройства, например, «нет аварии», «есть авария», «открыт», «закрыт» и т. д.
А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например »220 Вольт» или »10 Ампер».
Состояние или значение, настроенное пользователем, при котором на экране появляется сообщение (авария), называется «уставкой». Можно настроить задержку до появления сообщения, то есть авария на экране появляется только через Х секунд (при условии, если аварийная ситуация не прекратилась раньше) или на «замораживание» сообщения на экране — в этом случае авария уже пропала, но сообщение о ней на экране сохраняется еще Х секунд.
Аварии по показателю приоритетности обычно делятся на три основных типа: «Красная», «Желтая» и «Голубая». «Красные» аварии требуют немедленных действий сотрудников, «Желтые» о чем-то их предупреждают, «Голубые» чаще всего сообщают о каких-то некритичных событиях. Например, мы вывели «Голубые» аварии из сводки, которую видят дежурные, и используем их для мониторинга различных коммерческих параметров (превышение заказанной мощности). Отчеты по этим авариям направляются только менеджерам и не отвлекают дежурных.
Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, «OutputCurrent») имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте — она меняется везде.
Когда какое-то устройство требует индивидуальных настроек у требуемой переменной, мы применяем специальную отметку «Только для этого устройства». Теперь переменная стала индивидуальной для одного конкретного устройства, имеет свою уставку и не влияет на другие одноименные переменные.
Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии «Overload Alarm». И это совсем другая переменная, не связанная с переменной «OutputCurrent», настроенной в BMS.
Пример заводских настроек уставок внутри PDU:
Итак, мы перечислили основной функционал для настройки системы мониторинга.
Как же правильно настроить это «пианино»? Давайте рассмотрим задачи по порядку.
Чего мы хотим добиться
Самая главная задача: любое аварийное сообщение на морде панели управления оборудования должно отображаться в системе мониторинга. Если на устройстве горит красная лампочка, а в мониторинге ничего нет, значит не все переменные включены в мониторинг или их уставки настроены неверно.
Вторая задача — минимизировать ложные или неинформативные сообщения. Какие бы внимательные и ответственные дежурные у вас ни были, если перед их глазами постоянно что-то моргает, мигает и звонит, то либо они пропустят реальную аварию, утонув в море оповещений, либо отключат звук — и в итоге также пропустят оповещение об инциденте.
Этап 1. Определение нужных и ненужных переменных у каждого устройства
Обычно к каждому устройству идет так называемая «карта переменных», на основании которой инженером-наладчиком создается «драйвер». Его задача — «указать» системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя «System_on_fun», а в регистре 2 — о режиме работы компрессора «Compressor_1».
Количество переменных у одного устройства часто бывает больше 100. Сотрудник, изначально настраивающий систему (обычно это ИТ-инженер), не может сам решить, что здесь важно, а что нет. Как правило, все переменные добавляются в мониторинг по принципу «а вдруг пригодится».
На первое время это допустимо — сотрудники службы эксплуатации могут посмотреть на реальные значения всех доступных переменных и понять, что на самом деле им нужно. Но если надолго оставить систему в этом состоянии, то мы получим следующие негативные эффекты:
- Лишние переменные загружают оперативную задачу системы мониторинга и увеличивают размер архива, система вынуждена обрабатывать и сохранять ненужные данные.
- Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний «нет данных (Н/Д)» или «обрыв связи», то есть фактически устройство периодически выпадает из мониторинга.
- Некоторые переменные — лишние «по умолчанию». Например, в вашей версии оборудования нет компрессора или датчика давления, но они прописаны в универсальном драйвере для всего модельного ряда оборудования и опрашиваются, добавляясь в архив, нагружая сеть и процессинг.
На скриншотах приведена часть кода драйвера. Символами // указаны скрытые из опроса переменные. Также виден список переменных, отображаемых для пользователя при настройке уставок в самой BMS.
Заводские уставки внутри устройств по нашему опыту на начальном этапе лучше не трогать (конечно, если они не сообщают вам уже об аварии). Однако на каждой тренировке по конкретному оборудованию следует напоминать сотрудникам о наличии уставок и в самом устройстве, и в BMS. Это в будущем поможет дежурным точно понимать, что именно является причиной аварийного сообщения.
Лишние переменные в драйвере надо постепенно выявлять и скрывать из опроса, а оставшиеся разделить на те, к которым следует назначить уставки, и на те, которые сохраняются без уставок только для последующего анализа и статистики.
Делать это должен не наладчик системы, а сотрудник, понимающий работу системы, которую контролирует система мониторинга, — желательно главный инженер или главный энергетик.
Этап 2. Минимизация ложных и неинформативных сообщений
Ложные срабатывания часто происходят из-за сбоев в опросе устройства. Если сетевая карта устройства не снабжена автономным питанием, то и сбой в опросе и реальное отключение питания будут отображаться как один тип аварии — «обрыв связи».
В этом случае надо разделить оборудование на критическое (например, PDU) и обычное (например, щиты вентиляции «ЩУВ»). Для обычного оборудования можно установить задержку на сигнал «обрыв связи» (например, 300 секунд) — тогда большинство ложных обрывов будут игнорироваться.
Понятно, что на критическое оборудование такую задержку ставить нельзя, поэтому если оно постоянно дает ложные сбои, то следует разбираться с физической сетью, количеством опрашиваемых переменных. Вполне возможно, что на один шлюз «повешено» очень много устройств и надо сегментировать сеть через добавление новых шлюзов.
Неинформативные аварии чаще всего возникают при переходных процессах. Их нельзя назвать ложными — они на самом деле есть, но они «нормальны» при каком-то конкретном режиме работы оборудования. Самый очевидный пример — переход на ДГУ.
В этом случае часть оборудования, запитанного без ИБП, «штатно» обесточивается и выдает ошибку «обрыв связи», а сами ИБП выдают целый «букет» сообщений — «нет питания на вводе», «нет питания на байпасе», «питание от АКБ» и т. п. Персонал сразу получает десятки сообщений.
Для оптимизации количества сообщений при переходе на ДГУ следует:
- настроить на «штатно» появляющиеся во время перехода аварийные сигналы более длительные временные задержки, чем время появления питания от ДГУ. Например, установить задержку на сигнал «обрыв связи» щита вентиляции 300 секунд при штатном времени перехода на ДГУ 200 секунд.
Тогда питание на ЩУВ появится раньше задержки уставки, и ситуация не будет распознана как аварийная. При это есть критически важные устройства, которые запитаны от ИБП и всегда должны быть на связи (например, PDU) — сообщения об их «дисконнекте» должны появляться без задержки.
- проанализировать сообщения от ИБП при переходе на ДГУ и разделить их на «нормальные» с присвоением им «желтого» типа (например, констатация факта «нет питания на вводе») и «ненормальные» («отключение батарейного автомата», которого быть не должно в любом режиме работы), с присвоением им «красного» типа.
При этом отдельно записываем в инструкцию дежурным, что в случае перехода на ДГУ «желтые» аварии можно наблюдать и не квитировать (они пропадут сами после завершения штатного перехода), а «красные» немедленно устранять (их быть не должно).
За один раз, полагаясь только на теорию, настроить уставки для этого «переходного» процесса очень сложно. Для успешной настройки надо несколько раз наблюдать за переходами на ДГУ в реальном времени.
Например, нам потребовалось наблюдение за 4–5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.
Этап 3. Дополнительные советы из нашего опыта
1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений.
Пример из реальной практики. Один ЦОД заказал карту температурных потоков в серверной. Это 3D модель потоков воздуха с множеством температурных данных с датчиков. Получился вид северной с потоками воздуха — где-то воздух был выделен зеленым, где-то — желтым и красным (от самого холодного к самому горячему). При этом температуры воздуха везде в пределах нормы, а цвета применены только для наглядности отображения разницы температур в разных точках.
Далее этот «пестрый» вид вывели на один из мониторов в «дежурке». В итоге получилось, что инструмент, созданный для аналитики процессов, оказался перед глазами дежурных, которые «заточены» бежать к оборудованию при виде красного цвета и напрягаться при виде желтого.
Наверное, дежурным объяснили, что на левом экране «красное/желтое» — это нормально, а на правом экране эти же цвета — сигнал к действию. Однако ясно, что такая практика очень серьезно увеличивает риск человеческого фактора.
Логично убрать такие системы с мониторов в помещении дежурных, их должен наблюдать главный инженер для целей анализа тенденций — например, после каких-то изменений параметров воздушной среды в серверной или ввода в работу нового оборудования.
2. С осторожностью используйте SMS-оповещения.
Несколько лет назад мы еще опасались плохого мобильного интернета и использовали SMS вместо мессенджеров. Один раз я случайно выставил неправильную уставку, она применилась ко всем одноименным в 100 устройствах, и подписанным на рассылку коллегам на телефоны пришло по 100 SMS-сообщений. С тех пор мы не используем SMS-рассылку.
3. Настраивайте дублирование сообщений об авариях через мессенджер.
Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер).
И не бойтесь, что сообщений будет много. По нашему опыту, за среднестатистический день работы ЦОДа приходит всего несколько десятков сообщений, и они не загружают телефоны сотрудников. То есть оборудование ЦОД и систему BMS можно настроить так, чтобы не получать сотни оповещений и при этом ничего важного не пропускать.
Чтобы сообщений было меньше, включайте в рассылку только оповещения о возникновении «красных» и «желтых» аварий, то есть необходимый минимум, позволяющий держать руку на пульсе событий.
4. Группируйте сообщения в мессенджерах.
Во время перехода на ДГУ или из-за комплексной аварии у вас будут запущены десятки активных аварийных ситуаций, телефон будет постоянно вибрировать от поступающих в мессенджер сообщений, не давая сделать важный звонок или открыть окно системы мониторинга.
Можно настроить рассылку так, чтобы в мессенджер приходило одно общее сообщение с общим списком аварий, произошедших за последнюю минуту. На появление аварий в сводке системы BMS эта настройка не влияет (аварии появляются в сводке без задержки), а за 1 минуту задержки поступления сообщения на телефон вы ничего не пропустите, а вот сообщений на ваш телефон будет приходить в разы меньше.
5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.
Например, в помещении дежурных пропал интернет. Интерфейс пользователя не имеет связи с сервером и поэтому авария не появляется в сводке, тусклая надпись «сервер не доступен» может быть не замечена персоналом, сотрудники могут долго смотреть в «зеленую» панель BMS с числовыми параметрами, не подозревая о том, что она находится в офлайне.
На скриншоте — пример индикации о пропадании связи с сервером BMS, при этом отображаются неактуальные параметры работы оборудования.
6.Подключайте к мониторингу как можно больше систем.
Например, традиционно система пожарной сигнализации работает автономно, а ее панель висит на посту охраны.
Да, по сигналу «ПОЖАР» срабатывают автоматические алгоритмы работы систем, запускается система оповещения, но о появлении сигналов «Неисправность» или «Внимание» сотрудник охраны сообщает дежурным голосом.
Полноценно подключить к мониторингу такую систему очень сложно, но в такой системе легко настроить три релейных сигнала «неисправность», «внимание» и «пожар», а затем подключить их «сухими контактами» в модуль системы BMS.
Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала «ПОЖАР» в системе BMS ЦОДа, подключенного через «сухие контакты».
Подведем итоги нашей 4-серийной истории
Система мониторинга дата-центра — это не просто «глаза и уши» для наблюдения за инженерными системами ЦОДа. Ее правильная работа позволяет достигать высочайшего уровня надежности через непрерывность работы площадки, а, значит, обеспечивает компании дополнительное конкурентное преимущество.
Пройдя довольно трудный и длинный путь, мы получили:
- быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2 500 устройств и обсчитывает около 10 000 виртуальных датчиков;
- резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве;
- доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты;
- ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей;
- надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам — гибко настраиваемую и масштабируемую систему мониторинга.
