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

Что такое BMS

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

Системы мониторинга BMS (Building Monitoring System) предлагают многие глобальные вендоры оборудования для ЦОДов. За время работы Linxdatacenter в России нам довелось познакомиться с разными системами и столкнуться с диаметрально противоположными подходами вендоров к эксплуатации этих систем.

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

Корень проблемы

Все началось 10 лет назад с запуска ЦОДа Linxdatacenter в Петербурге. Система BMS, согласно стандартам отрасли тех лет, представляла из себя физический сервер с установленным ПО, доступ к которому осуществлялся через программу-клиента (так называемый «толстый» клиент).

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

Логичным выбором для нас стало решение BMS от одного из крупнейших мировых производителей. Выбранная система на тот момент отвечала всем требованиям к мониторингу комплексного инженерного объекта, каким является ЦОД.

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

Рынок корпоративных ИТ испытал на себе серьезное влияние B2C сферы. Цифровые решения сегодня должны обеспечивать удобство работы конечного пользователя — такую цель ставят перед собой разработчики. Это видно по совершенствованию пользовательских интерфейсов (UI) и качества пользовательского опыта (UX) многих корпоративных приложений.

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

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

Недостатки старой системы BMS

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

Добавим сюда еще несколько неприятных «мелочей»:

Плата за подключение новых устройств по принципу «один IP-адрес — одна платная лицензия»;
Невозможность обновить ПО без покупки пакета поддержки (имеется в виду обновление бесплатных компонентов и устранение ошибок в самой программе BMS);
Высокая стоимость поддержки;
Расположение на «железном» сервере, который может выйти из строя и обладает лимитированными вычислительными ресурсами;
«Резервирование» посредством установки второго железного сервера, с дублирующим пакетом лицензий. При этом синхронизация баз между основным и резервным серверами отсутствует –, а это означает ручной перенос базы и долгое время перехода на резерв;
«Толстый» клиент пользователя, недоступный извне, без расширения под мобильное устройство и опции удаленного доступа;
Урезанный веб-интерфейс без графических карт и звуковых уведомлений, доступный извне, но практически не используемый сотрудниками из-за своей неинформативности;
Отсутствие анимации в интерфейсе — вся графика состоит только из картинки-«подложки» и статических иконок. Как итог — общий низкий уровень наглядности;
Выглядело все примерно вот так:
Ограничение в создании виртуальных датчиков — доступна только функция сложения, тогда как модели реальных датчиков требуют возможности выполнения комплекса математических операций для корректных расчетов, отражающих реалии работы;
Невозможность получить данные в реальном времени или из архива для каких-либо целей (например, для отображения в личном кабинете клиента);
Полное отсутствие гибкости и возможности что-то изменить в BMS под существующие процессы ЦОДа.

Требования к новой системе BMS

Учитывая вышеизложенное, наши основные требования получились следующими:

Две независимые взаиморезервирующие машины c автоматической синхронизацией, работающие на двух разных облачных платформах в разных ЦОДах (в нашем случае ЦОДы Linxdatacenter Санкт-Петербург и Москва);
Бесплатное добавление новых устройств;
Бесплатное обновление ПО и его компонентов (за исключением доработок функционала);
Открытый исходный код, позволяющий нам самостоятельно поддерживать систему в случае проблем на стороне разработчика;
Возможность получать и использовать данные из BMS, например на сайте или в личном кабинете;
Доступ через WEB браузер без «толстого» клиента;
Использование доменных учетных записей сотрудников для доступа в BMS;
Наличие анимации и еще много мелких и не очень пожеланий, которые материализовались в подробное ТЗ.

Последняя капля

В тот момент, когда мы поняли, что ЦОД перерос свою BMS, самым очевидным решением нам казалось обновление существующей системы. «Коней на переправе не меняют», так ведь?

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

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

А самое неприятное — новая система не могла полностью удовлетворить наши требования к резервированию. Обновленная система BMS могла быть реализована, как мы и хотели, на облачной платформе, что позволило бы нам отказаться от «железа», но опция резервирования в стоимость не входила. Для резервирования данных нам пришлось бы купить второй виртуальный сервер BMS и дополнительный комплект лицензий. При стоимости одной лицензии около $76 и количества IP-адресов в 1000 единиц набегает $76 000 дополнительных трат только на лицензии для резервной машины.

«Вишенкой» в новой версии BMS стала необходимость покупки дополнительных лицензий «для всех устройств» — даже для основного сервера. Тут надо пояснить, что есть устройства, подключенные к BMS через шлюзы. Шлюз имеет один IP-адрес, но контролирует несколько устройств (в среднем 10). В старой BMS для этого требовалась одна лицензия за IP-адрес шлюза, статистика выглядела примерно так: «IP-адресов/ лицензий 1000, устройств 1200». Обновленная BMS работала по другому принципу и статистика выглядела бы так «IP-адресов 1000, устройств/лицензий 1200». То есть вендор в новой версии поменял принцип присвоения лицензий, и мы должны были купить дополнительно еще примерно 200 лицензий.

Бюджет «обновления» в итоге складывался из четырех пунктов:

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

Общая стоимость проекта составила более $100 000! И это не говоря о необходимости покупки лицензий для новых устройств в будущем.

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