Що таке BMS
Система моніторингу роботи інженерних систем у ЦОД – ключовий елемент інфраструктури, що безпосередньо впливає на такий важливий показник для дата-центру, як швидкість реакції персоналу на аварійні ситуації і, отже, на тривалість безперебійної роботи.
Системи моніторингу BMS (Building Monitoring System) пропонують багато глобальних вендоров обладнання для ЦОДів. За час роботи Linxdatacenter у Росії нам довелося познайомитися з різними системами та зіткнутися з діаметрально протилежними підходами вендорів до експлуатації цих систем.
Розповідаємо, як ми повністю оновили нашу систему BMS за останній рік та чому.
Корінь проблеми
Все почалося 10 років тому з запуску ЦОД Linxdatacenter в Петербурзі. Система BMS, згідно зі стандартами галузі тих років, являла собою фізичний сервер із встановленим ПЗ, доступ до якого здійснювався через програму-клієнта (так званий «товстий» клієнт).
Компаній, які пропонують такі рішення, на той час на ринку було небагато. Їхні продукти були стандартом, єдиною відповіддю на існуючий запит. І треба віддати їм належне: і тоді, і сьогодні лідери ринку загалом справляються зі своїм базовим завданням – постачанням функціональних рішень для експлуатації дата-центрів.
Логічним вибором стало рішення BMS від одного з найбільших світових виробників. Вибрана система на той момент відповідала всім вимогам до моніторингу комплексного інженерного об'єкта, яким є ЦОД.
Однак з часом вимоги та очікування користувачів (тобто нас, операторів дата-центрів) від ІТ-рішень змінилися. І великі вендори, як показав аналіз ринку запропонованих рішень, виявилися до цього не готові.
Ринок корпоративних ІТ зазнав серйозного впливу B2C сфери. Цифрові рішення сьогодні мають забезпечувати зручність роботи кінцевого користувача – таку мету ставлять перед собою розробники. Це видно по вдосконаленню інтерфейсів користувача (UI) і якості користувальницького досвіду (UX) багатьох корпоративних додатків.
Людина звикає до комфорту у всьому, що стосується цифрових інструментів у повсякденному житті, і висуває ті ж вимоги до інструментів, які використовує для робочих завдань. Люди очікують від корпоративних додатків такої ж наочності, інтуїтивності, простоти та прозорості, які доступні їм у сервісах фінансових послуг, виклику таксі чи онлайн-шопінгу. ІТ-фахівці, які впроваджують рішення в корпоративному середовищі, теж прагнуть отримувати всі сучасні «плюшки»: просте розгортання та масштабування, стійкість до відмов і необмежені можливості кастомізації.
Великі міжнародні вендори часто зважають на ці тренди. Спираючись на свій багаторічний авторитет у галузі, корпорації у роботі із замовниками найчастіше виявляються категоричними та негнучкими. Ілюзія власної незамінності не дозволяє їм побачити, як буквально під носом з'являються молоді технологічні компанії, які пропонують альтернативні рішення, заточені під конкретного замовника, без переплати за бренд.
Недоліки старої системи BMS
Найголовніший мінус наявного застарілого BMS-рішення для нас полягав у його повільній роботі. Розслідування кількох подій, пов'язаних із недостатньо швидкою реакцією чергового персоналу, допомогло нам зрозуміти, що іноді події відображалися в системі BMS з великою затримкою. Система не була перевантажена або несправна, просто версії її компонентів (наприклад, JAVA) застаріли і не могли коректно працювати з новими версіями операційних систем без оновлень. Оновити їх можна було лише разом із системою BMS, при цьому вендор не забезпечував автоматичної наступності версій, тобто для нас процес був би практично таким же трудомістким, як перехід на нову систему, а нове рішення зберігало частину недоліків старого.
Додамо сюди ще кілька неприємних «дрібниць»:
- Плата за підключення нових пристроїв за принципом «одна IP-адреса – одна платна ліцензія»;
- Неможливість оновити програмне забезпечення без придбання пакета підтримки (мається на увазі оновлення безкоштовних компонентів та усунення помилок у самій програмі BMS);
- Висока вартість підтримки;
- Розташування на «залізному» сервері, який може вийти з ладу та має лімітовані обчислювальні ресурси;
- «Резервування» за допомогою інсталяції другого залізного сервера, з дублюючим пакетом ліцензій. При цьому синхронізація баз між основним та резервним серверами відсутня – а це означає ручне перенесення бази та довгий час переходу на резерв;
- "Товстий" клієнт користувача, недоступний ззовні, без розширення під мобільний пристрій та опції віддаленого доступу;
- Урізаний веб-інтерфейс без графічних карт та звукових повідомлень, доступний ззовні, але практично не використовуваний співробітниками через свою неінформативність;
- Відсутність анімації в інтерфейсі – вся графіка складається лише з картинки-«підкладки» та статичних іконок. Як наслідок – загальний низький рівень наочності;
Виглядало все приблизно так:
- Обмеження у створенні віртуальних датчиків – доступна лише функція додавання, тоді як моделі реальних датчиків вимагають можливості виконання комплексу математичних операцій для коректних розрахунків, що відбивають реалії роботи;
- Неможливість отримати дані в реальному часі або з архіву для будь-якої мети (наприклад, для відображення в особистому кабінеті клієнта);
- Повна відсутність гнучкості та можливості щось змінити у BMS під існуючі процеси ЦОДу.
Вимоги до нової системи BMS
З огляду на вищевикладене наші основні вимоги вийшли такими:
- Дві незалежні взаєморезервні машини з автоматичною синхронізацією, що працюють на двох різних хмарних платформах у різних ЦОДах (у нашому випадку ЦОДи 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! І це не кажучи про необхідність придбання ліцензій для нових пристроїв у майбутньому.
У результаті ми зрозуміли, що для нас буде простіше – а, може, й дешевше – замовити систему, створену з нуля, яка враховує всі наші вимоги та передбачає можливість модернізації у майбутньому. Але бажаючих розробляти таку складну систему потрібно було ще знайти, порівняти пропозиції, вибрати та пройти з фіналістом шлях від ТЗ до реалізації… Про це читайте у другій частині матеріалу дуже швидко.
Джерело: habr.com