Мониторинг инженерной инфраструктуры в дата-центре. Часть 1. Основные моменты

    Часть 1. Мониторинг инженерной инфраструктуры в дата-центре. Основные моменты.
    Часть 2. Как устроен мониторинг энергоснабжения в дата-центре.
    Часть 3. Мониторинг холодоснабжения на примере дата-центра NORD-4.
    Часть 4. Сетевая инфраструктура: физическое оборудование.

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

    В статьях будем делиться своим опытом, тем, что пробовали и используем сами в собственных дата-центрах. На полноту не претендуем, зато все будет из жизни, а не из учебника.

    В комментариях можно попробовать повлиять на редакторскую политику и предложить для рассмотрения интересные именно для вас аспекты мониторинга.



    С организационными моментами вроде разобрались, приступим к азбуке мониторинга в редакции DataLine :). Итак, сегодня речь пойдет о концептуальных вещах, которые нужно учитывать на этапе проектирования, внедрения и настройки системы мониторинга. Сабж рассмотрим на примере нашего мониторинга, построенного на базе Nagios и Cacti.

    Что такое мониторинг


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

    Мониторинг можно трактовать по-разному: как систему и как процесс. В нашем случае это две стороны одной медали – одно без другого существовать не может.

    Мониторинг как система помогает непрерывно собирать, хранить и анализировать параметры оборудования и систем. Он снабжает данными, на основе которых инженер делает выводы о текущем состоянии и о возможном будущем поведении наблюдаемого объекта.

    Система мониторинга дает лишь вводную информацию, дальше дело за людьми и процессами. Четкие регламенты в штатных и аварийных ситуациях, выстроенная система уведомления ответственных лиц – все это превращает мониторинг из простого сбора данных в полезный инструмент для управления инфраструктурой.

    Когда нужно озадачиться системой мониторинга


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

    Пример 1: дата-центр запустили в эксплуатацию. Первые месяцы зал был почти пустой и из трех кондиционеров работал только один. С заполнением зала температура в зале выросла. Так как мониторинга нет, то службе эксплуатации будет сложно определить момент, когда включить второй, а в случае аварии – резервный.

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

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

    За чем нужно следить


    Мониторинг инженерной инфраструктуры нужно вести по возможности на трех уровнях: автономные датчики, оборудование и системы в целом.

    Под автономными датчиками мы в первую очередь подразумеваем датчики протечек, температурные датчики, датчики объема и движения.

    • датчики протечек нужны всегда, особенно если в дата-центре используется система охлаждения с жидким теплоносителем или фреоновая с увлажнением. Размещаем их под каждым кондиционером, узлом и краном трубопровода, т. е. в тех местах, где может закапать.
    • температурные датчики устанавливаем в холодных и горячих коридорах машинных залов, в помещениях с инженерной инфраструктурой (насосные, помещения АКБ, ГРЩ и пр.).
    • датчики объема/движения, открытия и закрытия дверей стоек. В отличие от предыдущих, они опциональны. Их можно использовать в залах или для группы стоек, огороженной забором (cage).

    Оборудование нужно мониторить по возможности все: ИБП, ДГУ, кондиционеры, PDU, АВР, камеры и пр. По каждому важно получать следующую информацию:

    • работает ли;
    • какие ошибки возникают в работе;
    • значения отдельных параметров (напряжение в ИБП, сила тока, уровень топлива в баке ДГУ, температура на входе и выходе кондиционера, скорость вращения вентилятора и пр.).

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

    Пример 2: отключился распределительный щит в машинном зале. Если мы мониторим оборудование по отдельности, то понадобится время, чтобы понять источник поломки – щит или ИБП, от которого он питается. Если же у нас перед глазами будет схема всей системы, то мы быстро увидим слабое звено.


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

    Документация по мониторингу


    По мере того, как определяемся с объектами и параметрами мониторинга, составляем документацию по системе. В ней фиксируем:

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

    Это тоже лучше делать на этапе проектирования, чтобы у службы эксплуатации была полная документация с самого начала и они понимали:

    • все ли интересующие объекты поставлены на мониторинг;
    • где искать проблему в случае неисправности самой системы мониторинга;
    • какие пороговые значения используются.

    Без такой шпаргалки службе эксплуатации придется исследовать систему мониторинга заново.

    Независимость и резервирование системы мониторинга


    Под мониторинг лучше использовать отдельное серверное и сетевое оборудование с выделенным сетевым сегментом.

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

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

    Единый центр мониторинга


    Всю информацию с датчиков, оборудования и систем нужно сводить в единый интерфейс и выборочно отображать на экранах в центре мониторинга.
    За всем этим хозяйством должен следить круглосуточно хотя бы один дежурный инженер. Здесь же все уведомления регистрируются в виде инцидентов на ответственных лиц или отделы.
    Это своего рода ЦУП и первый рубеж обороны в случае аварии в дата-центре.


    Центр мониторинга на площадке OST.

    В каждом профильном отделе можно дополнительно повесить экраны со схемами и оповещениями, которые входят в зону ответственности данного отдела: для инженеров эксплуатации – одни экраны, для сетевиков – другие.

    Визуализация


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


    Сводная схема дата-центра OST-2.

    Со схемой дежурному инженеру будет легче понять, в каком машинном зале находится сломанный кондиционер, что происходит с температурой в ближайшем холодном коридоре. Кроме того, визуализация дает возможность увидеть взаимосвязь между отдельными элементами инженерной системы и быстрее определить первоисточник проблемы.

    Разное время опроса для разных систем


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

    Устанавливайте разное время опроса для разных систем. Так вы не пропустите важных событий и не перегрузите систему слишком частыми запросами.

    Правильно выбранные пороговые значения для уведомлений


    Прописывайте критические значения, по достижении которых будут срабатывать оповещения. Лучше предусмотреть как минимум два уровня оповещения – предупреждения и критические ошибки. В Nаgios, например, такому разделению соответствуют warning и critical:

    • warning предупреждает о том, что какие-то параметры оборудования или системы подходят к критическому значению;
    • critical означает аварийную ситуацию, когда что-то сломалось, ошибка в оборудовании.

    Правильное разделение уведомлений позволит сократить количество ложных тревог. Провести четкую черту между warning и critical сложно, но понимание приходит с опытом. Если монитор перманентно красный от аварий, значит что-то настроено неправильно. Для инженера такой мониторинг быстро станет неинформативным, будут возникать ложные тревоги, а настоящие аварии могут остаться незамеченными среди рутинных оповещений.

    При необходимости корректируйте пороговые значения для разных типов уведомлений.

    Примеры warning и alarm


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

    Четкий регламент действий при аварийных ситуациях


    Не пропустить аварию важно, но еще важнее правильно на нее среагировать и запустить процесс реакции на инцидент.

    У дежурного инженера должна быть четкая инструкция, по которой он действует, и контакты людей, которых нужно оповестить в случае аварийной ситуации.

    Вся информация должна быть перед глазами и ясно сформулирована, чтобы инженеру не приходилось тратить время на поиски или расшифровывание пунктов инструкции.

    Для удобства дежурных инженеров каждое уведомление можно сопроводить всплывающей подсказкой с контактами ответственного лица и инструкцией. Регламенты же прописываются заранее и проверяются на жизнеспособность во время плановых тестирований.

    Не заставляйте дежурного инженера придумывать план действий с нуля, когда в дата-центре авария.

    Оповещение по email и смс


    Вещь полезная при правильном использовании. Для небольших серверных такие оповещения могу заменить круглосуточного дежурного инженера. В большом дата-центре это своего рода резервирование дежурного инженера. Но и здесь важно не перестараться и не рассылать уведомления ответственным лицам по любому чиху.

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

    Сбор статистики


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

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

    DataLine

    181,00

    Экосистема на базе дата-центров TIER III

    Поделиться публикацией
    Комментарии 18
      0
      Куда эффективней оповещений email и sms — звуковая трансляция в радиоканал + гарнитура на рации дежурной смены, желательна световая индикация режима «приём» на рации.
      В случае если смена на обходе или в шумном маш. зале — это может ускорить время реакции.
        0
        В нашем случае email и sms уходят уже ответственным лицам.
        С учетом того, что за мониторами круглосуточно сидит как минимум один инженер, ему слать sms не нужно.
        Еще в центре мониторинга срабатывает звуковое оповещение (противное такое:)), так что дежурному будет сложно пропустить аларм.
        Если у вас никто не сидит постоянно за экранами мониторинга, то можно другие варианты оповещения использовать.
          0
          Что произойдет, если в ночную смену, допустим, срывает или лопает шланг системы охлаждения на развязке около чиллера (резко падает давление в системе охлаждения)?
          А инженер в это время отошел заварить кофе и в туалет.
            0
            В нашей практике в дежурной смене (даже ночной) 4 инженера, поэтому если смотрящему за мониторами захочется в туалет, покурить, сделать кофе, то он сначала дожидается, пока его подменят на посту, и только идет делать свои дела.
              0
              Круто!
              Хорошо, когда есть достаточное количество персонала.
          0
          Хорошей практикой является использование световых маячков в шумных помещениях.
          А email и sms — для «высокоуровневых» ликвидаторов. Процедура уведомления согласно DRP. На дежурной смене обычно сидит младший инженерный состав. У них может быть опытный руководитель, но их задача локализовать проблему, не допустить распространения и пройтись по скрипту для её устранения. Если скрипт не работает — тогда едут опытные товарищи.
          0
          А с помощью чего карты создаете? Они интерактивные?
            +1
            Карты делаем с помощью серверных скриптов (Ralio в частности) как надстройка над системой мониторинга.
            В центре мониторинга можно переключаться между дата-центрами и инженерными системами. Часть экранов располагается рядом с машинными залами, они сенснорные и поддерживают функциональность drill-down.
            <img src="" alt=«image»/>

              0
              Спасибо
              Скорее все-таки railo, судя по гуглу…
              А не могли бы чуть подробнее, как это работает?

                0
                да, railo, конечно, опечатался.
                Подробнее обязательно расскажу, но в отдельной статье про инстурменты.
            0
            И еще вопрос… А используется у вас какая-то система ticket tracker?
            Особенно интересно, чтобы в этой (или другой системе) можно было бы прописывать workflow для диспетчера, персонала, knowledge base… Ну и т.п.
              +1
              Мы используем BMC Remedy.
              +1
              Про периодичность «опроса».
              Особого смысла опрашивать ИБП на тему напряжения на входе/выходе можно гораздо реже. Важно вести учет минимума и максимума по токам и напряжениям за период. Период может быть и час, если нагрузка сильно не скачет. Если есть ощущение необходимости снимать показания раз в секунду — лучше поставить анализатор качества питания на вводных фидерах, который при помехах, скачках токов-напряжений и других отклонениях в сети пишет форму тока и напряжения по трем фазам. Есть варианты, предназначенные для установки в ГРЩ
              .
              А вот с опросом кондиционеров и чиллеров — очень сильно зависит от нагрузки и плотности мощности. В вашем случае — судя по иллюстрации у вас около 3000 м3 объем машинных залов, около 4 МВт общее энергопотребление комплекса. При PUE 1.3 это значит, что в случае катастрофического отказа кондиционеров через секунду после опроса, к моменту следующего опроса температура в машзалах у вас может быть до 80 градусов Цельсия…
              Не надо вестись на сказки продавцов «шкафных» кондиционеров про «буферный объем воздуха» и прочую чушь. Когда плотность мощности была 200-500 ватт на м2, да, оно так работало. Когда плотность мощности 1 кВт на м3 — при отказе охлаждения температура растет почти на градус в секунду.

              Еще интересный вопрос, мониторинг сделали на базе BMS системы? Какой, если не очень большой секрет?
              DCIM какой-нибудь используете (по старой памяти интересуюсь, хоть и не занимаюсь DCIM уже больше года :-) )
                0
                Извините, выше налепил опечаток и недоредоктировал, пятница утомительной недели… А потом коммент на модерации и его нельзя отредактировать…
                Особого смысла опрашивать ИБП на тему напряжения на входе/выходе можно гораздо реже.

                Надо читать как: «Особого смысла часто опрашивать ИБП на тему напряжения на входе/выходе нет. Можно это делать гораздо реже.»
                0
                Подробно про мониторинг электроснабжения будет отдельная статья. Если коротко, то мы мониторим всю цепочку – от городских вводов до PDU в стойках. Во всех щитах установлены анализаторы тока. Напряжение на входе и выходе ИБП – это слишком важный показатель, чтобы замерять его раз в час. Отсутствие напряжения на входе или выходе ИБП – уже аварийная ситуация.

                Теперь про охлаждение. Если это чиллерная схема, то у нее большая инерционность. С учетом баков-аккумуляторов температура в залах точно не будет расти так, как вы говорите.
                Наш опыт с фреоновой схемой также показывает, что отключение половины кондиционеров на пару минут (например, во время тестирования ДГУ) не приведет к критическому повышению температуры. Точных измерений мы не делали, но скорее всего речь идет об 1 градусе в минуту, а не в секунду.

                Мониторинг на базе Nagios, DCIM не используем.
                  0
                  Ну, раз в час, да — все же нагрузка меняется. Но раз в секунду — особо ничему не поможет, ведь ИБП при аварии и отключении напряжения на выходе в любом случае должен выдать аварийный сигнал (и вообще должно быть резервирование и авария одного ИБП не должна ничего менять для оборудования). Из личного опыта, при анализе логов после аварии, информация мониторинга ИБП с частотой чаще примерно раза в пять минут — не добавляет полезной информации. Другое дело, что некоторые ИБП умеют показывать реальную кривую напряжения на входе и выходе… Но это тоже, по большому счету, перебор.

                  Про охлаждение — ситуация из личного опыта. Глюк в одном АВР привел к отключению сразу всех насосов, обеспечивающих циркуляцию жидкости во «внутреннем» контуре системы охлаждения. Наличие баков-аккумуляторов на 20 минут охлаждения при полной нагрузке тут помочь не смогло. Хорошо еще система была в процессе наладки, а не в боевом режиме, из вычислительных систем еще почти ничего не смонтировали в тот момент. Но все равно, ручка двери машзала успела нагреться так, что была обжигающе горячей.
                  С фреоновыми кондиционерами — чуть лучше и чуть хуже одновременно. Меньше шансов одновременного катастрофического отказа, но меньше инерционность и потенциальные проблемы, если вдруг ДГУ не запустились с первой попытки…
                  Еще один важный момент, что все же половина работающих у вас была. Я, видимо, пропустил ваш рассказ про систему охлаждения, но обычно в таких системах очень серьезный перезаклад по мощности кондиционеров. Вполне возможно, что у вас половины кондиционеров было бы достаточно, чтобы тянуть все охлаждение неограниченно долго. Такое тоже случалось у меня в практике, когда вендор мамой клялся, что потребление их оборудования будет 40 кВт и письма про это писал, по моим расчетам (я тогда был моложе и больше верил вендорам) получилось, что оборудование будет потреблять 12-15 кВт. Когда все запустили в боевом режиме, выяснилось, что оборудование кушает 3.5 кВт большую часть дня, а когда запускается генерация отчетов больших, раз в день на примерно 30 минут, потребление поднимается аж до 5 кВт! Понятно, что у вас ситуация другая и понимание реального потребления в зале у вас есть, но нужно еще учитывать, что многие кондиционеры не умеют вычислять реальную тепловую нагрузку на себя. (не будем говорить какой большой вендор за пять лет обновлений прошивок сумел снизить индикацию тепловой нагрузки с 80 кВт на блок до 50 кВт на блок, но реальная тепловая нагрузка как была 35 кВт на блок, так и оставалась такой все это время...)
                    0
                    Если один АВР валит _все_ насосы, то, я так понимаю, это не Tier III…
                      0
                      Это и не ЦОД был, а суперкомпьютер. Особенность суперкомпьютера — когда выбор стоит между повышением надежности инфраструктуры еще чуть-чуть или добавлением пары терафлопс производительности — выберут всегда производительность. Насосы питались от частотных регуляторов, частотные регуляторы от АВР, АВР — от двух независимых ИБП.
                      Главное, что для СК простой день-два — не смертельно. Соответственно, инфраструктура затачивается на сохранение вычислительного оборудования при проблемах. Буржуи разбаловались со своим качественным энергоснабжением, даже ИБП не ставят ради экономии.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое