08.05.2020

Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 3

Мы продолжаем наш рассказ о том, как мы меняли BMS-систему в наших ЦОДах (часть 1, часть 2). При этом мы не просто поменяли решение одного вендора на другого, а разработали систему с нуля под свои требования. В заключение нашей истории делимся итогами проделанной работы и интересными решениями, которые могут быть вам полезны

Мы продолжаем наш рассказ о том, как мы меняли BMS-систему в наших ЦОДах (часть 1, часть 2). При этом мы не просто поменяли решение одного вендора на другого, а разработали систему с нуля под свои требования. В заключение нашей истории делимся итогами проделанной работы и интересными решениями, которые могут быть вам полезны.

Новый интерфейс

Тут, как говорится, лучше один раз увидеть.


Стойки.

Разберем отличия.

  • Во-первых, это красиво удобно. Обратите внимание, как легко стало отслеживать нагрузки на модули («Banks» или просто «Банки») PDU и сумму параллельных нагрузок парных модулей. На модели стойки из новой BMS мы сразу видим, что нижние парные модули PDU перегружены (суммарный ток выше допустимых 16А – «синее» уведомление), а верхние недогружены. В случае отключения одного из вводов вся нагрузка перейдет на второй, и оставшийся под напряжением нижний модуль отключится из-за перегрузки. Чтобы не допустить такого, служба поддержки ЦОД заранее предупредит клиента и отправит рекомендацию, как перераспределить нагрузку.
  • Простое добавление оборудования. В новой BMS виртуальные датчики сумм токов модулей и мощности стойки уже добавлены в шаблоны типовых стоек и создаются автоматически после добавления в стойку PDU. В старой BMS их приходилось создавать вручную, а потом перетаскивать на карту, что повышало вероятность ошибки из-за «человеческого фактора».
  • Неограниченный простор для творчества. Теперь у нас нет ограничений при создании виртуальных датчиков. Можно строить абсолютно любые математические модели любых переменных. Это означает, что у нас есть возможность создавать сложные виртуальные датчики (раньше можно было только складывать значения) и лучше анализировать статистику и тенденции работы инженерных систем. Это повышает качество принимаемых решений по настройке систем, замене оборудования и управлению ресурсами.
  • Понятный интерфейс. В новом интерфейсе нет нагромождения значков, вентиляторы крутятся, выключатели «щелкают». И самое удобное – это возможность индикации состояния PDU Line A/B внутри стоек. Мы пробовали сделать нечто подобное в старой BMS, но количество сливающихся значков на квадратный сантиметр карты заставило нас от этого отказаться.

Теперь глазу приятно смотреть:

Серверные.

Фрагмент ГРЩ.

Щит управления вентиляцией.

А еще новую BMS можно украсить к Новому году 🙂

One page – взаимопонимание с полуслова и без ТЗ

Мы очень давно хотели реализовать еще одну «фишку» в BMS: скомпоновать на одной странице основные параметры ЦОД, чтобы одного взгляда на экран было достаточно для оценки состояния основных систем. Однако мы не до конца понимали, как она должна выглядеть.

Еще до начала разработки новой BMS мы посетили с экскурсиями десяток ЦОДов в Нидерландах. Одной из целей было увидеть примеры реализации такой страницы.

И ни в одном ЦОДе нам ее не показали – где-то ее не было, где-то «прямо сейчас разрабатывали», где-то это была «большая коммерческая тайна». Поэтому в нашем ТЗ на создание новой BMS точное описание этой очень важной для нас страницы отсутствовало.

В итоге мы ее придумали буквально «на ходу». Как раз в тот момент пришлось удаленно консультировать коллег в ЦОДе. Перелистывать страницы BMS в телефоне в поисках разрозненных данных было очень неудобно, и фактически на салфетке была набросана первая версия One page. Ее и реализовали разработчики по фото.

Следуя примеру осторожных голландских коллег, не будем демонстрировать итоговый вариант нашей главной страницы, тем более что каждый ЦОД уникален и копировать смысла нет. Но опишем два главных принципа ее формирования:

  • Это таблица, сверстанная под формат вертикально расположенного экрана смартфона (либо монитора, но с сохранением вертикального расположения), с выводом всей важной информации на один экран. Над таблицей приводится «сводка» активных инцидентов, поэтому размещать их вместе удобнее всего оказалось в вертикальном формате.
  • Расположение ячеек в таблице повторяет архитектуру ЦОДа (физическую или логическую). Мы отказались от расположения систем в алфавитном порядке, как хочется на первый взгляд. Последовательность отражает зрительные ассоциации персонала дата-центра – как будто они физически мониторят все помещения и системы. Это упрощает поиск информации.

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

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

Квитирование и сводка инцидентов

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

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

Слово прижилось, и теперь мы «квитируем» инциденты.

Алгоритм, заложенный в базовую версию новой BMS, нас не устроил. Фактически это были комментарии к журналу событий, то есть устраненные инциденты не исчезали из журнала, а принятые («квитированные») не отсортировывались от новых.

В итоге было разработано окно под названием «сводка», в котором:

  • Отображаются только активные инциденты и устройства в сервисном режиме (без коммерческих «синих» уведомлений).
  • Явно разделяются НОВЫЕ и ПРИНЯТЫЕ инциденты.
  • Указано, кто принял инцидент.

Алгоритм работы дежурных в новой BMS следующий:

  • Новые инциденты попадают в сводку и ждут квитирования. Долго они в этом разделе находиться не могут, ответственный за оборудование дежурный должен сразу принять инцидент на себя.
  • Сотрудник принимает инцидент на себя, нажав на галочку справа. Так как все сотрудники под уникальными учетными записями – автоматически отображается, кто принял инцидент. При необходимости оставляется комментарий.
  • Инцидент перемещается в раздел «Квитированные», остальные дежурные и руководитель понимают, что инцидентом занимается ответственный сотрудник.

Пример окна сводки с новым и уже квитированным сообщением.

Соединив окно сводки с таблицей One page, мы получили полноценный главный экран системы BMS, на котором сразу можно увидеть:

  • состояние основных систем ЦОД;
  • наличие новых необработанных инцидентов;
  • наличие принятых инцидентов и данные о том, кто конкретно их устраняет.

Доступ через браузер и всплывающие оповещения на телефоне

Веб-интерфейс, доступный с любого устройства из любой точки мира, – это разительный контраст с «толстым» клиентом, полностью закрытым для пользователей извне.

Старый подход тянул за собой комплекс неудобств, от проблем в организации удаленной работы сотрудников службы мониторинга до необходимости устанавливать «толстые» клиенты из дистрибутивов на рабочие места персонала в ЦОДе.

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

Доступ в систему теперь осуществляется посредством LDAP-аутентификации через Active Directory, что усиливает уровень ее защищенности.

Мобильность сегодня – ключевой фактор качественной работы дежурных инженеров. Помимо контроля мониторинга в помещении дежурной смены, инженеры делают обходы, выполняют текущую работу вне «дежурки» и, благодаря оптимизированному под мобильный экран главному экрану BMS, не теряют контроль за происходящим в машзалах ни на секунду.

Качество контроля повышается и благодаря функциональности рабочих чатов. Они ускоряют рабочие процессы, позволяя «привязать» переписку дежурных инженеров к BMS. Мы, например, используем приложение Teams, которое позволяет вести внутреннюю переписку и получать на телефон все сообщения из BMS в виде всплывающих Push-уведомлений, что избавляет дежурного от необходимости постоянно смотреть в экран телефона.


Push-уведомление на экране смартфона.


А так уведомления выглядят в приложении Teams.

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


На фото интерфейс BMS в смартфоне.

Подводя итог

При стоимости обновления BMS у нашего старого вендора, сопоставимой с разработкой новой системы с нуля (около $100 000), разница в функциональности продуктов оказалась колоссальной. Мы получили гибкую систему, оптимизированную под наши бизнес-задачи и процессы. Мы также добились существенной экономии в текущих расходах на поддержку и обновление системы.

Но, конечно, были и сложности.

• Во-первых, мы недооценили объем изменений, которые требовалось внести в базовую версию новой BMS, и не уложились в заранее оговоренные сроки. Для нас это не было критической проблемой, так как мы до последнего страховались и работали на старой системе, а процесс был творческий, сложный и поэтому шел иногда медленнее, чем ожидалось. К тому же мы всегда видели, что наш разработчик прикладывает максимум усилий для достижения лучшего результата. Но по факту история оказалась очень долгой, и наши ключевые специалисты потратили на нее значительно больше усилий и времени, чем планировали.
• Во-вторых, нам потребовалось несколько этапов испытаний, чтобы отладить алгоритм резервирования виртуальных машин и каналов связи. Изначально сбои были и на стороне системы BMS, и на стороне настройки виртуальных машин и сети. Эта отладка тоже заняла время. Благо, подрядчику была предоставлена тестовая площадка в виде облачного сервиса, где изначально тестировались все настройки и нововведения.
• В-третьих, итоговая система оказалась сложнее для редактирования конечным пользователем. Если раньше карта представляла собой подложку (графический файл) и значки, изменить или переместить которые не составляло труда, то теперь это сложный графический интерфейс с анимацией, требующий определенных навыков для редактирования.

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

Старый железный сервер мы, конечно же, не выкинули, а «облегчили»: очистили от тысяч «коммерческих» виртуальных датчиков и PDU и оставили в нем только несколько десятков самых критичных устройств, таких как ДГУ, ИБП, кондиционеры, насосы, датчики протечек и температур. В таком режиме к нему вернулась былая скорость, и он может быть «резервом резерва». Кстати, после удаления PDU из старой BMS у нас освободилось около 1000 теперь уже ненужных лицензий, вы случайно не знаете, что с ними делать?

Другие новости и публикации

Статья
09.08.2022
ИБ в условиях дефицита: стратегия большого перехода
Новость
01.08.2022
Linxdatacenter – в топ-10 крупнейших поставщиков услуг ЦОД
Новость
25.07.2022
Linxdatacenter запускает собственные PaaS-инструменты
Новость
20.07.2022
Петербургское облако Linxdatacenter прошло аттестацию по ...
Статья
30.06.2022
Как мы оптимизировали управление ЦОДами клиента
Новость
27.06.2022
Linxdatacenter: рынок российских облаков вырастет в 2022 ...
Новость
26.05.2022
Анна Мальми назначена региональным директором Linxdatacen...
Статья
20.05.2022
Облачный край: что происходит на российском рынке
Новость
13.05.2022
Новым генеральным директором Linxdatacenter назначен Андр...
Статья
03.05.2022
Блок на моноблок: модульная ИБП-революция в ЦОДах

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

Дата-центр – комплексный ИТ- и инженерный объект, требующий профессионализма на всех уровнях управления: от руководителей до технических специалистов и исполнителей эксплуатационных работ. Рассказываем, как мы помогли клиенту навести порядок в операционном управлении в корпоративных ЦОДах.
 

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

Дата-центр – комплексный ИТ- и инженерный объект, требующий профессионализма на всех уровнях управления: от руководителей до технических специалистов и исполнителей эксплуатационных работ. Рассказываем, как мы помогли клиенту навести порядок в операционном управлении в корпоративных ЦОДах.  

В главной роли – управление 

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

Роль надежных и производительных дата-центров в современной экономике постоянно растет вместе с требованиями к их бесперебойной работе. Однако на этом направлении существует большая системная проблема.  

Высокий уровень «аптайма» – безаварийной работы дата-центра без простоев – очень сильно зависит от команды инженеров, которая занимается управлением площадки. А единой формализованной школы управления ЦОДами не существует.  

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

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

Наконец, государственные ведомственные ЦОДы – в этом отношении они часто представляют собой неизвестную территорию в силу закрытости. Международный аудит таких объектов по понятным причинам невозможен. Российские госстандарты только разрабатываются.  

Все это выливается в ситуацию «кто во что горазд». «Разношерстный» состав команд эксплуатации из специалистов с разным бэкграундом, различные подходы к организации корпоративной архитектуры, взгляды и требования в отношении ИТ-департаментов.  

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

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

Кейс: через тернии к относительному порядку 

Проиллюстрируем на примере реализованного проекта. К нам обратилась крупная международная компания с сетью собственных дата-центров. Запрос был на помощь в оптимизации процессов управления тремя площадками, где на серверах развернуты ИТ-системы и приложения, абсолютно критичные для бизнеса.  

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

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

И здесь началось самое интересное.  

Познай себя 

Чтобы оценить уровень работы ЦОДов с точки зрения соответствия стандартам, нужно знать точные требования бизнеса к ИТ-системам: каков уровень внутренних SLA, допустимый период простоя оборудования и т.д.  

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

Коллеги просто не представляли, каково допустимое время простоя операций, завязанных на ИТ, каково оптимальное время восстановления систем в случае аварии, как устроена архитектура собственных приложений. Например, пришлось разбираться, будет ли критичным для работы приложения «падение» одного из ЦОДов, или в нем нет компонентов, влияющих на приложение.  

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

Когда было достигнуто понимание архитектуры ИТ-систем, команда смогла суммировать требования к службе эксплуатации, подрядчикам и к уровню надежности оборудования.  

Улучшения в процессе 

Наши специалисты выезжали на площадки для оценки инфраструктуры, читали имеющуюся документацию, проверяли уровень соответствия проектов ЦОДов фактической реализации.  

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

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

Однако правильная оптимизация управления «инженеркой» ЦОДа предполагает выполнение задачи научить людей правильно оценивать процессы и писать под них уникальную документацию исходя из специфики конкретного объекта.  

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

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

Далее последовал этап первичной поддержки работ по обновленным регламентам, который в удаленном формате продолжался один год. Затем мы перешли к тренингам и учениям – единственный путь закрепления нового материала на практике.  

Что сделано 

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

Прежде всего, мы избежали ведения двойной документации, которой опасались сотрудники клиента. Для этого соединили в новых регламентах нормативные требования, применяющиеся к различным инженерным системам стандартно (электрика, охлаждение, контроль доступа), с отраслевыми best practices, создав прозрачную структуру документации с простой и логичной навигацией.  

Принцип «просто найти, просто понять, легко запомнить» дополнился тем, что новая информация привязывается к старому опыту и знаниям сотрудников. 

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

За 1,5 года процессы управления инженерными системами были прокачаны до уровня, который позволил специалистам компании успешно отчитаться «за качество» перед аудиторами из головного офиса.  

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

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

Главная проблема здесь: многие руководители не понимают, по какому тонкому льду они идут, не уделяя этому моменту должного внимания. Человеческий фактор по-прежнему остается главным источником самых неприятных аварий и сбоев. И это нужно объяснять.  

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

Когда требования к государственным ЦОДам в РФ на уровне законодательного акта будут сведены в стандарт, его можно будет применять и для коммерческих дата-центров, в том числе и для размещения государственных ИТ-ресурсов.  

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

Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 3

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!