Мониторинг в центъра за данни: как сменихме стария BMS с новия. Част 1

Мониторинг в центъра за данни: как сменихме стария BMS с новия. Част 1

Какво е BMS

Системата за мониторинг на работата на инженерните системи в центъра за данни е ключов елемент от инфраструктурата, пряко засягащ такъв важен показател за център за данни като скоростта на реакция на персонала при извънредни ситуации и следователно продължителността на непрекъсната работа. 

BMS (Building Monitoring System) системи за мониторинг се предлагат от много световни доставчици на оборудване за центрове за данни. По време на работата на Linxdatacenter в Русия имахме възможността да се запознаем с различни системи и да се сблъскаме с диаметрално противоположни подходи на доставчиците към работата на тези системи. 

Разказваме ви как напълно актуализирахме нашата BMS система през изминалата година и защо.  

Коренът на проблема

Всичко започна преди 10 години с пускането на центъра за данни Linxdatacenter в Санкт Петербург. BMS системата, според индустриалните стандарти от онези години, беше физически сървър с инсталиран софтуер, достъпен чрез клиентска програма (т.нар. „дебел“ клиент). 

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

Логичният избор за нас беше BMS решението на един от най-големите световни производители. Избраната към този момент система отговаряше на всички изисквания за наблюдение на сложно инженерно съоръжение, като център за данни. 

С течение на времето обаче изискванията и очакванията на потребителите (т.е. на нас, операторите на центрове за данни) от ИТ решенията се промениха. И големите доставчици, както показва анализ на пазара за предложените решения, не бяха готови за това.

Корпоративният ИТ пазар изпита сериозно влияние от B2C сектора. Дигиталните решения днес трябва да осигурят комфортно изживяване за крайния потребител - това е целта, която разработчиците си поставят. Това е очевидно в подобренията в потребителския интерфейс (UI) и потребителското изживяване (UX) на много корпоративни приложения. 

Човек свиква с комфорта на всичко свързано с дигиталните инструменти в ежедневието и поставя същите изисквания към инструментите, които използва за работни задачи. Хората очакват от корпоративните приложения същата видимост, интуитивност, простота и прозрачност, които са достъпни за тях във финансовите услуги, повикването на такси или онлайн пазаруването. ИТ специалистите, внедряващи решения в корпоративна среда, също се стремят да получат всички съвременни „благини“: просто внедряване и мащабиране, толерантност към грешки и неограничени възможности за персонализиране. 

Големите международни доставчици често пренебрегват тези тенденции. Разчитайки на дългогодишния си авторитет в бранша, корпорациите често се оказват категорични и негъвкави при работа с клиенти. Илюзията за собствената им незаменимост не им позволява да видят как млади технологични компании се появяват буквално под носа им, предлагайки алтернативни решения, съобразени с конкретен клиент, и без да надплащат за марката.

Недостатъци на старата BMS система 

Основният недостатък на съществуващото остаряло BMS решение за нас беше бавната му работа. Разследването на няколко събития, при които дежурният персонал не реагира достатъчно бързо, ни накара да разберем, че понякога има значително забавяне на показването на събития в BMS. В същото време системата не беше претоварена или дефектна, а просто версиите на нейните компоненти (например JAVA) бяха остарели и не можеха да работят правилно с нови версии на операционни системи без актуализации. Беше възможно да ги актуализираме само заедно с BMS системата и доставчикът не осигури автоматична непрекъснатост на версиите, тоест за нас процесът щеше да бъде почти толкова трудоемък, колкото преминаването към нова система и новото решение се запази някои от недостатъците на стария.  

Нека добавим още няколко неприятни „малки неща“ тук:

  1. Плащане за свързване на нови устройства на принципа „един IP адрес – един платен лиценз“; 
  2. Невъзможност за актуализиране на софтуера без закупуване на пакет за поддръжка (това означава актуализиране на безплатни компоненти и отстраняване на грешки в самата BMS програма);
  3. Висока цена на поддръжката; 
  4. Местоположение на „железен“ сървър, който може да се провали и има ограничени изчислителни ресурси;
  5. „Редундантиране“ чрез инсталиране на втори хардуерен сървър с дублиран лицензен пакет. В същото време няма синхронизация на базите данни между главния и резервния сървър - което означава ръчно прехвърляне на база данни и дълго време за преход към резервния;
  6. „Дебел“ потребителски клиент, недостъпен отвън, без разширение за мобилно устройство и опция за отдалечен достъп;
  7. Съкратен уеб интерфейс без графични карти и звукови известия, достъпен отвън, но практически не се използва от служителите поради липсата на информация;
  8. Липса на анимация в интерфейса - всички графики се състоят само от „фоново“ изображение и статични икони. Резултатът е общо ниско ниво на видимост;

    Всичко изглеждаше приблизително така:

    Мониторинг в центъра за данни: как сменихме стария BMS с новия. Част 1

    Мониторинг в центъра за данни: как сменихме стария BMS с новия. Част 1

  9. Ограничение при създаването на виртуални сензори е, че е налична само функцията за добавяне, докато моделите на реални сензори изискват възможност за извършване на набор от математически операции за правилни изчисления, които отразяват реалностите на работа; 
  10. Невъзможност за получаване на данни в реално време или от архива за всякакви цели (например за показване в личния акаунт на клиента);
  11. Пълна липса на гъвкавост и възможност за промяна на нещо в BMS, за да отговаря на съществуващите процеси в центъра за данни. 

Изисквания за нова BMS система

Имайки предвид гореизложеното, нашите основни изисквания бяха следните:

  1. Две независими взаимно резервирани машини с автоматична синхронизация, работещи на две различни облачни платформи в различни центрове за данни (в нашия случай центрове за данни Linxdatacenter Санкт Петербург и Москва);
  2. Безплатно добавяне на нови устройства;
  3. Безплатни актуализации на софтуера и неговите компоненти (с изключение на функционални подобрения);
  4. Отворен изходен код, който ни позволява самостоятелно да поддържаме системата в случай на проблеми от страна на разработчика;
  5. Възможност за получаване и използване на данни от BMS, например на уебсайт или в личния ви акаунт;
  6. Достъп през WEB браузър без дебел клиент;
  7. Използване на акаунти на служители на домейн за достъп до BMS;
  8. Наличие на анимация и много други дребни и не толкова дребни желания, които се материализираха в детайлна техническа спецификация.

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

Мониторинг в центъра за данни: как сменихме стария BMS с новия. Част 1

В момента, в който разбрахме, че центърът за данни е надраснал своя BMS, най-очевидното решение ни се стори да актуализираме съществуващата система. „Те не сменят конете по средата“, нали? 

Големите корпорации обаче по правило не предлагат персонализирани модификации на своите стари от десетилетия „полирани“ решения, продавани в десетки страни. Докато младите компании тестват идея или прототип на бъдещ продукт върху потенциални потребители и разчитат на обратната връзка с потребителите, за да разработят продукта, корпорациите продължават да продават лицензи за някога наистина готин продукт, но, уви, днес той е остарял и негъвкав.

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

И най-неприятното беше, че новата система не можеше да задоволи напълно изискванията ни за резервация. Актуализираната BMS система може да бъде внедрена, както искахме, на облачна платформа, което би ни позволило да се откажем от хардуера, но опцията за резервиране не беше включена в цената. За да архивираме данните, ще трябва да закупим втори BMS виртуален сървър и допълнителен набор от лицензи. Тъй като цената на един лиценз е около $76 и броят на IP адресите е 1000 единици, това добавя до $76 000 допълнителни разходи само за лицензи за резервната машина. 

„Черешката“ в новата версия на BMS беше необходимостта от закупуване на допълнителни лицензи „за всички устройства“ – дори и за основния сървър. Тук е необходимо да се уточни, че има устройства, свързани към BMS чрез шлюзове. Шлюзът има един IP адрес, но контролира няколко устройства (средно 10). В старата BMS това изискваше един лиценз на IP адрес на шлюз, статистиката изглеждаше така: „1000 IP адреса/лицензи, 1200 устройства.“ Актуализираната BMS работи на различен принцип и статистиката ще изглежда така: „1000 IP адреса, 1200 устройства/лицензи“. Тоест доставчикът в новата версия промени принципа на възлагане на лицензи и трябваше да закупим приблизително 200 допълнителни лиценза. 

Бюджетът за „актуализация“ в крайна сметка се състоеше от четири точки: 

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

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

В резултат на това разбрахме, че би било по-лесно за нас - и може би дори по-евтино - да поръчаме система, създадена от нулата, като вземем предвид всички наши изисквания и предвидим възможността за модернизация в бъдеще. Но тези, които искаха да разработят такава сложна система, трябваше да бъдат намерени, да се сравнят предложенията, да се изберат и с финалиста да се извърви пътя от техническите спецификации до внедряването... Прочетете за това във втората част на материала съвсем скоро. 

Източник: www.habr.com

Добавяне на нов коментар