🥇Jälgimine andmekeskuses: kuidas vahetasime vana BMS uue vastu. Osa 2

Esimese osana rääkisime, miks me otsustasime vahetada meie andmepunktides vana BMS-süsteemi uue vastu. Ja mitte lihtsalt vahetada, vaid arendada see nullist meie nõuete järgi. Teises osas räägime, kuidas me seda tegime.

Turuanalüüs

Arvestades ülaltoodud esimeses osas soove ning otsustust loobuda olemasoleva süsteemi uuendamisest, kirjutasime turulahenduste leidmiseks tehnilise ülesande (TÜ) ning esitasime päringud mitmesse suurde ettevõttesse, mis tegelevad ainult tööstuslike SCADA-süsteemide loomisega.

Esimesed vastused, mida me saime, näitasid, et turu liidrid monitorimissüsteemide valdkonnas töötavad peamiselt endiselt füüsilistel serveritel, kuigi sellel segmendil on migratsioon pilve juba alanud. Mis puudutab virtuaalmasinate varundamist – seda valikut ei toetanud keegi. Veelgi enam, tekkis tunne, et ükski tuntud arendaja turul ei näidanud isegi arusaama varundamise olulisusest: „pilv ju ei kuku” oli kõige sagedasem vastus. Praktikas pakuti meile võimalust viia andmepunkti jälgimine pilve, mis asub füüsiliselt samas andmepunktis.

Siin on vajalik teha väike kõrvalpöörde sõlmimise protsessist, valides alltöövõtjat. Hind on loomulikult oluline, kuid igasugustes keeruliste projektide elluviimise hangetes, tarnijatega dialooge pidades, hakkad tunnetama, kes kandidaatidest on rohkem huvitatud ja suudab selle ellu viia.

See on eriti märgatav keeruliste projektide puhul.

TÜ-de täpsustamise küsimuste iseloomu järgi võib alltöövõtjaid jagada kahte: need, kes tahavad lihtsalt müüa (tunda tavalist müügihalduri survet) ja need, kes on huvitatud toote arendamisest, kuuldes ja mõistes tellijat, tehes konstruktiivseid muudatusi TÜ-s juba enne lõplikku valikut (isegi vaatamata reaalsele riskile parandada kellegi teise TÜ-d ja kaotada hange), lõpuks lihtsalt valmis minema professionaalsele väljakutsele ja looma hea toote.

Kõik see sundis meid pöörama tähelepanu suhteliselt väikesele kohalikele arendajale – Sanline’i ettevõtterühmale, kes reageeris enamikele meie nõudmistele koheselt ja oli valmis rahuldama kõik vajadused uue BMS-i osas.

Riskid

Kuid samal ajal, kui suured mängijad üritasid mõista, mida me soovime, ja pidid meiega rahulikku kirjavahetust, kutsus kohalikke arendaja meid oma kontoris kohtumisele koos oma tehnilise meeskonnaga. Selles kohtumises näitas töövõtja veel kord soovi projektis osaleda ja – mis kõige tähtsam – selgitas, kuidas nõutav süsteem ellu viiakse.

Enne kohtumist nägime kahte riski meeskonnaga töötamisel, kellel puudub suure riikliku või rahvusvahelise ettevõtte tagasihoidlik kogemus:

Spetsialistid võivad oma võimalusi üle hinnata ja seetõttu ei suuda lihtsalt hakkama saada, näiteks kasutavad keerulisi tarkvarasid või projekteerivad teostatamatuid varundusalgoritme.
Pärast projekti rakendamist võib projektimeeskond laguneda ja seega on toote tugi ohus.

Nende riskide minimeerimiseks kutsusime kohtumisele oma arenduseksperdid. Potentsiaalsete töövõtjate töötajaid küsitleti põhjalikult, et teada saada, millele süsteem tugineb, kuidas varundamist plaanitakse ja teiste küsimuste kohta, milles meie, kui teenindusüksus, ei ole piisavalt kompetentsed.

Otsus oli positiivne: olemasoleva BMS platvormi arhitektuur on kaasaegne, lihtne ja usaldusväärne, seda saab täiustada, pakutud varundus- ja sünkroonimisskeem on loogiline ja töökindel.

Esimese riski suudeti lahendada. Teine risk välistati, saades töövõtjalt kinnituse, et nad on valmis meile andma süsteemi lähtekoodid ja dokumentatsiooni, valides ka programmeerimiskeele Python, mis on meie spetsialistidele hästi tuttav. See tagas meile võimaluse süsteemi ise hallata ilma igasuguste raskusteta ja pika koolitusperioodita, kui arendajafirma turult lahkub.

Platvormi täiendav pluss oli see, et see oli rakendatud Docker konteineritesse: selles keskkonnas töötavad toote tuum, veebiliides ja andmebaas. Selline lähenemine pakub hulgaliselt eeliseid, sealhulgas seadistuste etteinstallimist, mis tagab lahenduse äärmiselt kiire juurutamise võrreldes "klassikaga" ja lihtsa uute seadmete lisamise süsteemi. Prinsip "kõik koos" lihtsustab süsteemi juurutamist maksimaalselt: piisab süsteemi dekompressioonist, et seda kohe kasutada.

Sellise lahenduse korral on lihtsam teha süsteemi koopiaid, ja selle täiustamine ning uuenduste rakendamine on võimalik eraldi keskkonnas, ilma et peaks katkestama lahenduse tööd tervikuna.

Pärast seda, kui mõlemad riskid oli minimaalseteks viidud, esitas hankija pakkumise. Selles töötati välja kõik meie jaoks kõige olulisemad BMS süsteemi parameetrid.

Varustamine

Uus BMS süsteem pidi asuma pilves, virtuaalses masinas.

Mingit riistvara, mingeid servereid ja kõiki sellega seotud juurutusmugavusi ja riske – pilvelahendus võimaldas meil neist igaveseks vabaneda. Otsustati, et süsteem töötab meie pilves kahes andmekeskuse asukohas Peterburis ja Moskvas. Need on kaks täisfunktsionaalset süsteemi, mis töötavad aktiivse varukoopa režiimis ning on kättesaadavad kõigile volitatud spetsialistidele.

Kaks süsteemi kindlustavad üksteist, tagades täieliku varukoopia nii arvutusvõimete kui ka andmeedastuse kanalite osas. Samuti on seadistatud täiendavad turvameetmed, sealhulgas andmete ja kanalite, süsteemide, virtuaalsete masinate varundamine ning eraldi andmebaasi varundamine kord kuus (kõige väärtuslikum ressurss tulevase haldamise ja analüüsi seisukohalt).

Oluline on märkida, et varundamine kui BMS lahenduse valik töötati välja spetsiaalselt meie taotluse alusel. Varundamise skeem nägi välja järgmiselt:

Tugi

Tõhusaks BMS lahenduse kasutamiseks on oluline tehniline tugi.

Siin on kõik lihtne: uus süsteem maksaks meile selle näitaja kohaselt 35 000 rubla kuus SLA mõistes "reaktsioon 8 tunni jooksul", st 35 000 x 12 / 80 = 5 250 dollarit aastas. Esimene aasta – tasuta.

Võrdluseks: vana BMS-i toe aastane maksumus oli $18 000, mille summa kasvas iga uue seadme lisamisega! Lisaks ei pakkunud ettevõte pühendatud haldurit, kogu suhtlemine toimus müügihalduri kaudu, kes oli meie suhtes huvitatud potentsiaalsest ostjast koos vastava rõhuasetusega päringute töötlemisel.

Kasutades vähem raha, saime täieliku tootetoe, kus kontohaldur osaleb toote arenduses, koos ühe sisenemise punktiga jne. Tugi muutus märgatavalt paindlikumaks – tänu otsesele juurdepääsule arendajatele operatiivsete kohandamiste tegemiseks iga süsteemi töö aspekti, integratsiooni kaudu API jne.

Uuendused

Uue BMS-i pakkumise kohaselt on kõik uuendused toega sisse arvestatud, st ei nõua täiendavat tasu. Erandiks on lisafunktsionaalsuse arendamine, mis ületab TŠ-s märgitud.

Vana süsteem eeldas tasumist nii tasuta tarkvara (nt Java) uuenduste kui ka vigade parandamise eest. Sellest loobuda ei olnud võimalik, kuna uuenduste puudumisel „töötas” süsteem aeglaselt vanade sisekomponentide tõttu.

Ja muidugi ei saanud tarkvara uuendada, ilma et oleks ostetud toeteenuspakett.

Paindlik lähenemine

Teine oluline nõue puudutas kasutajaliidest. Soovisime tagada selle juurdepääsu veebibrauseri kaudu igast punktist, ilma et insener peaks olema kohal andmekeskuses. Pealegi püüdlesime luua animatsiooni sisaldava liidese, et infrastruktuuri toimimise dünaamika oleks vahetusena selgem valveinseneridele.

Samuti pidi uus süsteem toetama valemeid virtuaalsete andurite töö arvutamiseks insenerisüsteemides – näiteks elektrivõimsuste optimaalse jaotuse tagamiseks seadmete riiulitel. Selleks peab olema kõik tuntud matemaatilised operatsioonid, mida saab anduri näitude rakendada.

Edasi, oli vajalik pääseda SQL andmebaasi, mille kaudu saaksime vajalikud andmed seadmete töö kohta – nimelt, kõik kirjed kahe tuhande seadme ja kahe tuhande virtuaalse anduri jälgimise kohta, mis genereerivad umbes 20 tuhat muutujat.

Samuti oli vajalik riiuli seadmete arvestuse moodul, mis annab visuaalse ülevaate seadmete asukohast igas üksuses, loendades kogu „rauda“ ja pidades seadmete raamatukogu, koos detailse teabega iga elemendi kohta.

Tehnilise ülesande kooskõlastamine ja lepingu sõlmimine

Sel ajal, kui oli vaja alustada uue süsteemi arendamist, oli suhtlemine "suurte" ettevõtetega kõik veel kaugel nende pakkumiste hindade arutamisest, seetõttu võrreldes saadud pakkumist vana BMS-i uuendamise kuludega (vt. esimest osa), oli see hind veelgi atraktiivsem ja vastavalt meie nõuetele.

Valik tehti.

Pärast alltöövõtja valimist hakkasid juristid koostama lepingut, samas kui mõlema poole tehnilised meeskonnad täpsustasid tehnilist ülesannet. Nagu teada, on detailselt ja õigesti vormistatud TÕ alus igasuguste tööde edukusele. Mida rohkem konkreetset teavet TÕ-s, seda vähem pettumusi nagu „aga me tahtsime teistmoodi“.

Toon välja kaks näidet nõuete detailitsemise tasemest TÕ-s:

Vahetuste keskused on saanud õiguse lisada BMS-i uusi seadmeid, enamasti PDU-sid. Vanas BMS-is oli see "administraatori" tasand, mis võimaldas ka kõigi seadmete muutujate seadistusi muuta, ning funktsioonide eraldamine ei olnud võimalik. See meid ei rahuldanud. Uue platvormi põhiversioonis oli skeem analoogne. Me nägime kohe TÕ-s, et soovime neid rolle eraldada: seadistusi tohib muuta ainult volitatud töötaja, kuid vahetuste meeskonnad peavad endiselt saama seadmeid lisada. Just see skeem võeti elluviimiseks vastu.
Igas tavapärases BMS-is on kolm tüüpilist teavituskategooriat: PUNANE – vajalik kiire reageerimine, KOLLANE – jälgimine on lubatud, SININE – „Teavitav”. Oleme traditsiooniliselt kasutanud „siniseid” teateid äri parameetrite ületamise jälgimiseks, näiteks kliendi rack'i koormuse piiri ületamine. See teavitustüüp oli mõeldud meie puhul juhtidele ja ei olnud operatiivteenistusele huvitav, kuid vanas BMS-is takistas see pidevalt aktiivsete sündmuste nimekirja ja segas operatiivset tööd. Otsustasime, et teavituste loogika ja värvide diferentseerimine on edukas ning säilitasime selle, kuid tellimuses on selgelt märgitud, et „sinised” teated peavad, segamatult valves olevaid inimesi, vaikselt „sadu” eraldi sektsiooni, kus nendega tegelevad äritehnikud.

Sarnase detailsuse tasemega määrati ülesehitusvormid diagrammide loomiseks ja raportite esitamiseks, liideste jooned, seadmete nimekiri, mida tuli jälgida, ja veel palju muud.

See oli tõeliselt loominguline töö kolme töögrupi vahel – tellijate teenistus, kes dikteeris oma nõudmisi ja tingimusi; tehnilised spetsialistid mõlemalt poolt, kelle ülesanne oli need tingimused tehniliseks dokumentatsiooniks vormistada; ja kontraktitööde programmeerijate meeskond, kes rakendas tellija nõudmisi välja töötatud tehnilise dokumentatsiooni alusel... Lõpuks kohandasime mõned meie mitte-prinsipiaalsed nõudmised olemasoleva platvormi funktsionaalsuse järgi, samas kui alltöövõtja lubas meie nõudmiste vara lõpetamise.

Kahe süsteemi paralleelne töö

On käes rakendamise aeg. Praktikas tähendas see, et anname alltöövõtjale õiguse luua BMS-i prototüübi meie virtuaalses pilves ja pakume võrguühendust kõigile seadmetele, mida tuleb jälgida.

Samas ei olnud uus süsteem veel tööks valmis. Sellel etapil oli meie jaoks oluline säilitada jälgimine vanas süsteemis ja samal ajal anda seadmetele juurdepääs uuele süsteemile. Süsteemi ei olnud võimalik normaalselt üles ehitada, nägemata selles seadmeid, mida ei saanud omakorda vanast süsteemist jälgimisest lahti ühendada.

Kas seadmed taluvad kahes süsteemis samaaegset küsitlemist, ei olnud selge ilma tegelike katseteta. Oli olemas tõenäosus, et kahekordne samaaegne küsitlus põhjustab seadmete seas sagedasi vastusepuudusi, mille tulemuseks oleks mitmed seadmete kättesaamatuse vead, mis omakorda blokeeriks vana jälgimissüsteemi toimimist.

Võrguosakond suunatud virtuaalsed marsruudid uue pilves juurutatud BMS prototüübist seadmetesse, ja saime tulemused:

seadmed, mis on ühendatud SNMP protokolli kaudu, ei kukkunud praktiliselt välja samaaegsete päringute tõttu,
seadmed, mis on ühendatud modbas-TCP protokollide kaudu, lävasid probleeme, mis lahendati arvestatava küsitlusfrekeentsi vähendamisega.

Ja siis hakkasime jälgima, kuidas meie silme ees ehitatakse uut süsteemi, kuhu ilmuvad juba tuttavad seadmed, kuid teises liideses – mugavas, kiiretas ja kergesti ligipääsetavas, isegi telefonist.

Kuidas see kõik kokku tuli, räägime oma artikli kolmandas osas.

Allikas: habr.com