Што такое 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! І гэта не кажучы аб неабходнасці пакупкі ліцэнзій для новых прылад у будучыні.
У выніку мы зразумелі, што для нас будзе прасцей - а, можа, і танней - замовіць сістэму, створаную з нуля, якія ўлічваюць усе нашы патрабаванні і прадугледжвае магчымасць мадэрнізацыі ў будучыні. Але жадаючых распрацоўваць такую складаную сістэму трэба было яшчэ знайсці, параўнаць прапановы, абраць і прайсці з фіналістам шлях ад ТЗ да рэалізацыі… Пра гэта - чытайце ў другой частцы матэрыялу зусім хутка.
Крыніца: habr.com