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

Во првиот дел зборувавме зошто решивме да го замениме стариот BMS систем во нашите центри за податоци со нов. И не само промена, туку развивајте се од нула за да одговараат на вашите барања. Во вториот дел ви кажуваме како го направивме тоа.

Анализа на пазар

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

Уште првите одговори од нив покажаа дека лидерите на пазарот на системи за следење претежно продолжуваат да работат на хардверски сервери, иако процесот на миграција кон облаците во овој сегмент е веќе започнат. Што се однесува до резервирањето виртуелни машини, никој не ја поддржа оваа опција. Покрај тоа, имаше чувство дека ниту еден од истакнатите програмери на пазарот не покажал разбирање за потребата од вишок: „облакот не паѓа“ беше најчестиот одговор. Всушност, ни беше понудено да поставиме мониторинг на центарот за податоци во облак физички лоциран во истиот центар за податоци.

Тука треба да направиме мала дигресија за процесот на избор на изведувач. Цената, се разбира, е важна, но при секој тендер за спроведување на сложен проект, во фаза на дијалог со добавувачите, почнувате да чувствувате кој од кандидатите е позаинтересиран и способен да го спроведе. 

Ова е особено забележливо на сложени проекти. 

Врз основа на природата на разјаснување на прашањата за техничките спецификации, изведувачите можат да се поделат на оние кои се заинтересирани за едноставно продавање (се чувствува стандардниот притисок на менаџерот за продажба) и оние кои се заинтересирани да развијат производ, откако го слушнале и разбрале клиентот, правејќи конструктивен измени на техничките спецификации уште пред конечниот избор (и покрај реалниот ризик од подобрување на туѓите технички спецификации и губење на тендерот), на крајот тие едноставно се подготвени да прифатат професионален предизвик и да направат добар производ.

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

Ризици

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

Пред состанокот, видовме два ризици за работа со тим кој нема ресурси на голема национална или меѓународна компанија зад себе:

1. Специјалистите би можеле да ги преценат своите способности и, како резултат на тоа, едноставно не успеваат да се справат; на пример, ќе користат сложен софтвер или ќе дизајнираат неостварливи алгоритми за резервации.
2. По завршувањето на проектот, проектниот тим може да се распадне и, според тоа, поддршката за производот ќе биде загрозена.

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

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

Со првиот ризик се реши. Вториот беше исклучен откако добија потврда од изведувачот дека се подготвени да ни го пренесат изворниот код на системот и документацијата, а исто така и со изборот на програмскиот јазик Python, кој им беше добро познат на нашите специјалисти. Ова ни гарантира можност сами да го одржуваме системот без никакви потешкотии и долг период на обука на вработените во случај развојната компанија да го напушти пазарот.

Дополнителна предност на платформата беше тоа што беше имплементирана во контејнери на Docker: кернелот, веб-интерфејсот и базата на податоци за производи функционираат во оваа средина. Овој пристап обезбедува многу предности, вклучувајќи ги претходно поставените поставки за најголема брзина на распоредување на решението во споредба со „класичните“ и лесното додавање на нови уреди во системот. Принципот „сите заедно“ ја поедноставува имплементацијата на системот колку што е можно: само отпакувајте го системот и можете веднаш да го користите. 

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

Откако двата ризици беа минимизирани, изведувачот го обезбеди CP. Ги опфати сите најважни параметри на BMS системот за нас.

Резервација

Новиот BMS систем мораше да биде лоциран во облакот, на виртуелна машина. 

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

Двата системи се осигуруваат еден со друг, обезбедувајќи целосна резерва и на компјутерската моќ и на каналите за пренос на податоци. Конфигурирани се и дополнителни безбедносни мерки, вклучувајќи резервна копија на податоци и канали, системи, воопшто виртуелни машини и посебна резервна копија на базата на податоци еднаш месечно (највредниот ресурс во однос на управувањето и анализата). 

Имајте предвид дека вишокот како опција во решението BMS е развиен специјално за нашето барање. Самата шема за резервации изгледаше вака:

Поддршка

Најважната точка за ефективно функционирање на решението за BMS е техничката поддршка. 

Сè е едноставно овде: новиот систем би нè чинел 35 рубли според овој индикатор. месечно за SLA „одговор во рок од 000 часа“, односно 8 x 35 / 000 = 12 долари годишно. Првата година е бесплатна. 

За споредба, одржувањето на стариот BMS од продавачот чинеше 18 долари годишно со зголемување на износот за секој додаден нов уред! Во исто време, компанијата не обезбеди посветен менаџер, целата интеракција се одвиваше преку менаџер за продажба кој е заинтересиран за нас како потенцијален купувач со соодветен акцент во обработката на барањата. 

За помалку пари добивме целосна поддршка за производот, со менаџер на сметка кој би учествувал во развојот на производот, со единствена влезна точка итн. Поддршката стана многу пофлексибилна - благодарение на директниот пристап до програмерите за брзо прилагодување на кој било аспект на системот, интеграција преку API итн.

Надградби

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

Стариот систем бараше плаќање и за ажурирања на фирмверот (како Java) и за поправки на грешки. Беше невозможно да се одбие ова; во отсуство на ажурирања, системот како целина „забави“ поради старите верзии на внатрешните компоненти.

И, се разбира, беше невозможно да се ажурира софтверот без да се купи пакет за поддршка.

Флексибилен пристап

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

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

Следно, потребен беше пристап до базата на податоци SQL со можност да се земат од неа потребните податоци за работата на опремата - имено, сите записи за следење на две илјади уреди и две илјади виртуелни сензори кои генерираат приближно 20 илјади променливи. 

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

Одобрување на технички спецификации и потпишување на договор

Во времето кога беше неопходно да се започне со работа на новиот систем, кореспонденцијата со „големите“ компании сè уште беше многу далеку од дискусија за цената на нивните предлози, па затоа го споредивме добиениот CP со трошоците за ажурирање на стариот BMS (види. првиот дел), и како резултат на тоа се покажа дека е попривлечно по цена и ги исполнува нашите барања.

Изборот е направен.

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

Ќе дадам два примери за нивото на деталност на барањата во техничките спецификации:

1. Дежурните центри за податоци се овластени да додаваат нови уреди во BMS, најчесто тоа се PDU. Во стариот BMS, ова беше ниво на „администратор“, кое исто така дозволуваше менување на поставките за променливите на сите уреди и беше невозможно да се одделат функциите. Ова не ни одговараше. Во постоечката основна верзија на новата платформа, шемата беше слична. Веднаш наведовме во работните задачи дека сакаме да ги одвоиме овие улоги: само овластен вработен треба да ги менува поставките, но дежурните треба да продолжат да можат да додаваат уреди. Оваа шема беше прифатена за имплементација.
2.  Во секој стандарден BMS има три типични категории на известувања: ЦРВЕНО - мора веднаш да се одговори, ЖОЛТО - може да се забележи, СИНО - „Информативно“. Традиционално користиме сини предупредувања за следење кога се надминати деловните параметри, како што е решетката на клиентот што го надминува ограничувањето на капацитетот. Овој тип на известување во нашиот случај беше наменет за менаџерите и не беше од интерес за оперативната служба, но во стариот BMS редовно ја затнуваше листата на активни инциденти и ја попречуваше оперативната работа. Самата логика и диференцијација на бои на панталоните за известување ја сметавме за успешна и ја задржавме, но техничките спецификации конкретно укажаа дека „сините“ известувања треба, без да го одвлекуваат вниманието на дежурните, тивко да се „излеат“ во посебен дел, каде што тие ќе се занимаваат комерцијални специјалисти.

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

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

Паралелно работење на два системи

Време е за имплементација. Во пракса, ова значеше дека му даваме можност на изведувачот да распореди прототип на BMS во нашиот виртуелен облак и да обезбеди мрежен пристап до сите уреди кои бараат мониторинг.

Сепак, новиот систем сè уште не беше подготвен за работа. Во оваа фаза ни беше важно да го одржиме мониторингот во стариот систем и во исто време да им дадеме пристап на уредите до новиот систем. Невозможно е правилно да се изгради систем без да се видат уреди во него, кои пак не можат да бидат оневозможени од мониторингот од стариот систем. 

Дали уредите би можеле да издржат симултано испрашување од два системи не беше очигледно без вистинско тестирање. Постоеше можност двојното симултано гласање да доведе до чести одбивања да одговорат од уредите и да добиеме многу грешки во врска со недостапноста на уредите, што пак ќе ја блокира работата на стариот систем за следење.

Одделот за мрежа спроведе виртуелни рути од прототипот на новиот BMS распореден во облакот до уредите и ги добивме резултатите: 

• уредите поврзани преку протоколот SNMP практично никогаш не се исклучија поради истовремени барања, 
• уредите поврзани преку портали со помош на протоколи modbas-TCP имаа проблеми кои беа решени со интелигентно намалување на нивната фреквенција на гласање.  

И тогаш почнавме да набљудуваме како се гради нов систем пред нашите очи, во него се појавија веќе познати уреди, но во различен интерфејс - удобен, брз, достапен дури и од телефон.

Што се случи на крајот ќе ви кажеме во третиот дел од нашата статија.

Извор: www.habr.com