Мониторинг в ЦОД: как сменихме старата BMS с нова. Част 3

Продължаваме разказа си за това как сменихме BMS системата в нашите ЦОД-ове (част 1, част 2). При това не просто сменихме решението на един вендор с друго, а разработихме система от нулата според нашите изисквания. В заключение на нашата история споделяме резултатите от извършената работа и интересните решения, които могат да бъдат полезни за вас.

Нов интерфейс

Тук, както се казва, по-добре е да се види веднъж.

Стойки.

Нека разгледаме разликите.

• На първо място, това е красиво удобно. Обърнете внимание колко лесно стана да се проследяват натоварванията на модулите ("Banks" или просто "Банки") PDU и сумата от паралелните натоварвания на двойките модули. На модел на стойка от новата BMS, веднага виждаме, че долните двойни модули PDU са пренатоварени (общият ток е над допустимите 16А – "синьо" уведомление), а горните са недозаредени. В случай на изключване на един от входовете, цялото натоварване ще премине на втория, а оставащият под напрежение долен модул ще се изключи поради пренатоварване. За да не се допусне това, поддръжката на ЦОД предварително ще предупреди клиента и ще изпрати препоръка как да се переразпредели натоварването.
• Лесно добавяне на оборудване. В новата BMS виртуалните сензори за сумите на токовете на модулите и мощността на стойките вече са добавени в шаблоните за стандартни стойки и се създават автоматично след добавянето в стойка PDU. В старата BMS трябваше да ги създаваме ръчно, а след това да ги преместваме на картата, което увеличаваше вероятността за грешка поради "човешкия фактор".
• Неограничено пространство за творчество. Сега нямаме ограничения при създаването на виртуални сензори. Можем да изграждаме абсолютно всякакви математически модели на каквито и да било променливи. Това означава, че имаме възможността да създаваме сложни виртуални сензори (по-рано можеше само да се събират стойности) и да анализираме по-добре статистиката и тенденциите на работа на инженерните системи. Това увеличава качеството на взетите решения относно настройката на системите, подмяната на оборудването и управлението на ресурсите. 
• Ясен интерфейс. В новия интерфейс няма натрупване на значки, вентилаторите работят, превключвателите " щракат". И най-удобното е възможността за индикация на състоянието на PDU Line A/B вътре в стойките. Опитахме да направим нещо подобно в старата BMS, но количеството преливащи значки на квадратен сантиметър от картата ни принуди да се откажем от това.

Сега е приятно за окото да се гледа:

Сървърни.

Фрагмент от ГРЩ.

Щит за управление на вентилацията.

А освен това новата BMS може да бъде украсена за Нова година 🙂

One page – взаимопонимание с половин дума и без ТЗ

Отдавна искахме да реализираме още една „фишка“ в BMS: да компилираме на една страница основните параметри на ЦОД, така че един поглед на екрана да е достатъчен за оценка на състоянието на основните системи. Но не разбирахме напълно как трябва да изглежда.

Още преди да започнем разработката на новата BMS, посетихме с екскурзии десетина ЦОД в Нидерландия. Една от целите беше да видим примери за подобна страница.

И в нито един ЦОД не ни я показаха – на някои места я нямаше, на други я „разработваха точно сега“, на трети ни казаха, че е „голяма търговска тайна“. Затова в нашето ТЗ за създаването на новата BMS точното описание на тази много важна за нас страница липсваше.

В крайна сметка я измислихме буквално на ходу. Тъкмо в този момент се наложи да консултираме колеги от ЦОД дистанционно. Прелистването на страниците на BMS на телефона в търсене на разпръснати данни беше много неудобно, и всъщност на салфетка беше набросена първата версия. One page. Тя беше реализирана от разработчиците по снимка. 

Следвайки примера на внимателните холандски колеги, няма да демонстрираме окончателния вариант на нашата главна страница, особено защото всеки ЦОД е уникален и няма смисъл да се копира. Но ще опишем два основни принципа на нейното формиране:

1. Това е таблица, проектирана за формат на вертикално разположен екран на смартфон (или монитор, но с запазване на вертикалното разположение), с показване на цялата важна информация на един екран. Над таблицата се предоставя „сводка“ от активните инциденти, затова е най-удобно да ги поставим заедно във вертикален формат. 
2. Разположението на клетките в таблицата повтаря архитектурата на ЦОДа (физическа или логическа). Отказахме се от разположението на системите в азбучен ред, както може да изглежда на пръв поглед. Последователността отразява зрителните асоциации на персонала на дата-центъра – сякаш физически следят всичките помещения и системи. Това улеснява намирането на информация.

Всъщност, сега всички ключови характеристики на ЦОД са групирани и представени на един екран на смартфона или монитора на отговорния инженер и ръководителя, като е реализирана връзка с физическата и логическата топография на ЦОД. 

Ето снимка на първия черновик, въпреки че, разбира се, тази версия по-късно беше преосмислена и доработена.

Квитирането и обобщението на инцидентите

Ще поговорим за още едно ново понятие за нас, появило се в резултат на проекта за обновление на системата за мониторинг.

Квитирането е доста рядко срещан термин, предложен от разработчика на новата BMS. То означава потвърждение, че операторът е видял инцидента, потвърдил го е и е поел задълженията по его разрешаване.  

Думата се приживя, и сега ние „квитираме“ инцидентите.

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

В крайна сметка беше разработено прозорец на име „обобщение“, в което:

1. Се показват само активни инциденти и устройства в сервисен режим (без търговски „сини“ известия).
2. Ясно се разграничават НОВИ и ПРИЕТИ инциденти.
3. Указва се, кой е приел инцидента.

Алгоритъмът на работа на дежурните в новата BMS е следният:

1. Новите инциденти попадат в обобщението и чакат квитиране. Те не могат да останат дълго в този раздел, отговорният за оборудването дежурен трябва веднага да приеме инцидента на себе си.
2. Служителят приема инцидента на себе си, натискайки галочката вдясно. Понеже всички служители имат уникални профили - автоматично се показва, кой е приел инцидента. При нужда се оставя коментар.
3. Инцидентът се премества в раздела „Квитирани“, другите дежурни и ръководителят разбират, че инцидентът се обработва от отговорния служител.

Пример за прозорец на обобщение с ново и вече квитирано съобщение.

Свързвайки прозореца на обобщението с таблицата One page, получихме напълно функционален главен екран на системата BMS, на който моментално може да се види: 

• състоянието на основните системи на ЦОД;
• наличието на нови необработени инциденти;
• наличието на приети инциденти и информация за това, кой точно ги разрешава.

Достъп през браузър и изскачащи уведомления на телефона

Уеб интерфейс, достъпен от всяко устройство от всяка точка на света, е рязък контраст с "дебел" клиент, напълно затворен за потребителите отвън. 

Старият подход носеше комплекс от неудобства, от проблеми в организацията на дистанционната работа на служителите за мониторинг, до необходимостта от инсталиране на "дебели" клиенти от дистрибуции на работните места на персонала в ЦОД.

Сега всяка страница в BMS има уникален адрес, което позволява споделяне не само на директния адрес на страницата или устройството, но и на връзки към уникални графики/отчети. 

Достъпът до системата сега е чрез LDAP удостоверяване чрез Active Directory, което увеличава нивото на сигурност. 

Мобилността днес е ключов фактор за качествената работа на дежурните инженери. Освен контрола на мониторинга в помещението на дежурната смяна, инженерите извършват обходи, изпълняват текуща работа извън "дежурката" и, благодарение на оптимизирания за мобилен екран основен екран на BMS, не губят контрол над събитията в машзалите нито за секунда. 

Качеството на контрола се повишава и благодарение на функционалността на работните чатове. Те ускоряват работните процеси, позволявайки "привързването" на кореспонденцията на дежурните инженери към BMS. Ние, например, използваме приложението Teams, което позволява вътрешна кореспонденция и получаване на всички съобщения от BMS на телефона в вид на изскачащи Push уведомления, което освобождава дежурния от необходимостта постоянно да гледа екрана на телефона.

 Push уведомление на екрана на смартфона.

А така уведомленията изглеждат в приложението Teams.

При това изскачащите уведомления са настроени само за съобщения за появата на инциденти, minimizирайки отвлекащите фактори, персоналът знае: ако на екрана на смартфона се появи Push уведомление от Teams, трябва да се влезе на страницата на BMS и да се приеме инцидента. Съобщенията за разрешаване на инциденти се проследяват вече на страницата на BMS.

На снимката интерфейсът на BMS в смартфон.

В обобщение

При цената на обновление на BMS при нашия стар стартап, която е сравнима с разработката на нова система от нулата (около 100 000 $), разликата във функционалността на продуктите се оказа колосална. Получихме гъвкава система, оптимизирана за нашите бизнес задачи и процеси. Също така постигнахме значителна икономия в текущите разходи за поддръжка и обновление на системата. 

Но, разбира се, имаше и трудности. 

• На първо място, недооценихме обема на промените, които трябваше да направим в основната версия на новия BMS, и не се вписахме в предварително уговорените срокове. За нас това не беше критичен проблем, тъй като продължавахме да използваме старата система до последно, а процесът беше творчески, сложен и затова понякога вървеше по-бавно от очакваното. Освен това винаги виждахме, че нашият разработчик полага максимални усилия, за да постигне най-добрия резултат. Но всъщност историята се оказа много дълга, а нашите ключови специалисти похарчиха значително повече усилия и време, отколкото планираха. 
• На второ място, необходимо ни беше да проведем няколко етапа на тестове, за да оптимизираме алгоритмите за резервиране на виртуални машини и канали за комуникация. Първоначално имаше проблеми както в системата BMS, така и в конфигурацията на виртуалните машини и мрежата. Тази настройка също отне време. Добре, че подрядчикът имаше тестова площадка под формата на облачен сервис, където първоначално тестувахме всички конфигурации и нововъведения.
• На трето място, финалната система се оказа по-сложна за редактиране от крайния потребител. Ако преди картата представляваше подложка (графичен файл) и иконки, които можеше лесно да се променят или преместят, то сега това е сложен графичен интерфейс с анимации, изискващ определени умения за редактиране.

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

Старият железен сървър не беше изхвърлен, а „облекчен“: почистен от хиляди „търговски“ виртуални сензори и PDU и оставен с няколко десетки от най-критичните устройства, като ДГУ, ИБП, климатици, помпи, сензори за течове и температура. В този режим се върна старата му скорост и може да бъде „резерв на резерва“. Между другото, след премахването на PDU от старата BMS, се освободиха около 1000 ненужни лицензии, вие случайно не знаете какво да правим с тях?

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