Мониторинг во центарот за податоци: како го заменивме стариот 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. Пристап преку ВЕБ-прелистувач без дебел клиент;
  7. Користење на сметки на вработени во домен за пристап до BMS;
  8. Достапност на анимација и многу други мали и не толку мали желби кои се материјализираа во детална техничка спецификација.

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

Мониторинг во центарот за податоци: како го заменивме стариот BMS со нов. Дел 1

Во моментот кога сфативме дека центарот за податоци го надмина својот BMS, најочигледното решение ни се чинеше дека го ажурираше постоечкиот систем. „Тие не ги менуваат коњите на половина пат“, нели? 

Сепак, големите корпорации, по правило, не нудат сопствени модификации на нивните децениски „полирани“ решенија што се продаваат во десетици земји. Додека младите компании тестираат идеја или прототип на иден производ на потенцијални потрошувачи и се потпираат на повратните информации од корисниците за да го развијат производот, корпорациите продолжуваат да продаваат лиценци за некогаш навистина кул производ, но, за жал, денес тој е застарен и нефлексибилен.

И ние самите ја почувствувавме разликата во пристапот. За време на кореспонденцијата со производителот на стариот BMS, брзо стана јасно дека ажурирањето на постоечкиот систем предложен од продавачот всушност ќе резултира со купување на нов систем за нас со полуавтоматски пренос на базата на податоци, висока цена и стапици за време на трансфер, кој ниту самиот производител не можеше да го предвиди. Се разбира, во овој случај, трошоците за техничка поддршка за ажурираното решение се зголемија, а потребата за купување лиценци за време на проширувањето остана.

И најнепријатното беше што новиот систем не можеше целосно да ги задоволи нашите барања за резервација. Ажурираниот BMS систем може да се имплементира, како што сакавме, на облак платформа, што ќе ни овозможи да го напуштиме хардверот, но опцијата за вишок не беше вклучена во цената. За да направиме резервна копија на податоците, ќе треба да купиме втор BMS виртуелен сервер и дополнителен сет на лиценци. Со оглед на тоа што цената на една лиценца е околу 76 долари и бројот на IP адреси е 1000 единици, тоа додава до 76 долари дополнителни трошоци само за лиценци за резервната машина. 

„Црешата“ во новата верзија на BMS беше потребата да се купат дополнителни лиценци „за сите уреди“ – дури и за главниот сервер. Овде е неопходно да се разјасни дека има уреди поврзани со BMS преку порти. Портата има една IP адреса, но контролира неколку уреди (10 во просек). Во стариот BMS, ова бараше една лиценца по IP адреса на портата, статистиката изгледаше вака: „1000 IP адреси/лиценци, 1200 уреди“. Ажурираниот BMS работеше на поинаков принцип и статистиката би изгледала вака: „1000 IP адреси, 1200 уреди/лиценци“. Односно, продавачот во новата верзија го смени принципот на доделување лиценци и моравме да купиме приближно 200 дополнителни лиценци. 

„Ажурирањето“ на буџетот на крајот се состоеше од четири точки: 

  • цена на облак верзијата и услугите за миграција кон неа; 
  • дополнителни лиценци за постојниот пакет за уреди поврзани преку портали;
  • цена на резервната верзија на облакот;  
  • збир на лиценци за резервната машина. 

Вкупната цена на проектот беше повеќе од 100 долари! И тука не треба да се спомене потребата за купување лиценци за нови уреди во иднина.

Како резултат на тоа, сфативме дека ќе ни биде полесно - а можеби и поевтино - да нарачаме систем создаден од нула, земајќи ги предвид сите наши барања и предвидувајќи ја можноста за модернизација во иднина. Но, оние кои сакаа да развијат ваков комплексен систем, сепак требаше да се најдат, да се споредат предлозите, да се изберат и со финалистот да го изодат патот од техничките спецификации до имплементацијата... Прочитајте за ова во вториот дел од материјалот многу наскоро. 

Извор: www.habr.com

Додадете коментар