{"id":80952,"date":"2020-05-10T01:42:22","date_gmt":"2020-05-09T23:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2"},"modified":"2020-05-10T01:42:22","modified_gmt":"2020-05-09T23:42:22","slug":"monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","title":{"rendered":"Pra\u0107enje u podatkovnom centru: kako smo zamijenili stari BMS s novim. Dio 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Pra\u0107enje<\/p>\n

U prvom dijelu smo objasnili za\u0161to smo odlu\u010dili zamijeniti staru BMS-sustav u na\u0161im DC-ima s novim. I ne samo zamijeniti, ve\u0107 razviti od nule prema na\u0161im zahtjevima. U drugom dijelu govorimo kako smo to radili.
\n<\/a><\/noindex><\/p>\n

Analiza tr\u017ei\u0161ta<\/h2>\n

\nUzimaju\u0107i u obzir opisano u prvom delu<\/a><\/noindex> \u017eeljama i odluci da odustanemo od a\u017euriranja postoje\u0107eg sustava, napisali smo TZ za pronala\u017eenje rje\u0161enja na tr\u017ei\u0161tu i poslali zahtjeve nekoliko velikim kompanijama koje se isklju\u010divo bave izradom industrijskih SCADA sustava.\u00a0<\/p>\n

Prvi odgovori od njih pokazali su da lideri tr\u017ei\u0161ta sustava nadzora ve\u0107inom i dalje rade na fizi\u010dkim serverima, iako je proces migracije u oblake u ovom segmentu ve\u0107 zapo\u010deo. \u0160to se ti\u010de rezerviranja virtualnih ma\u0161ina \u2013 ovu opciju nitko nije podr\u017eavao. \u0160tavi\u0161e, \u010dinilo se kao da nijedan od poznatih developera na tr\u017ei\u0161tu nije \u010dak ni prikazao razumijevanje potrebe za rezerviranjem: \"oblak se ne ru\u0161i\" bio je naj\u010de\u0161\u0107i odgovor. U su\u0161tini, nudili su nam da smjestimo nadzor DC-a u oblaku koji se fizi\u010dki nalazio u istom tom DC-u.<\/p>\n

Ovdje se mora napraviti malo odstupanje o procesu odabira izvo\u0111a\u010da. Cijena, naravno, ima zna\u010daj, ali tijekom svakog natje\u010daja za realizaciju slo\u017eenog projekta, u fazi dijaloga s dobavlja\u010dima, po\u010dinje\u0161 osje\u0107ati tko od kandidata je vi\u0161e zainteresiran i sposoban ga realizirati.\u00a0<\/p>\n

To je posebno uo\u010dljivo na slo\u017eenim projektima.\u00a0<\/p>\n

Po karakteru poja\u0161njavaju\u0107ih pitanja prema TZ-u, izvo\u0111a\u010de mo\u017eemo podijeliti na one koji su zainteresirani samo za prodaju (osje\u0107a se standardni pritisak prodajnog menad\u017eera) i one koji su zainteresirani da razviju proizvod, \u010duju\u0107i i razumijevaju\u0107i klijenta, unose\u0107i konstruktivne promjene u TZ \u010dak i prije kona\u010dnog odabira (\u010dak i usprkos stvarnom riziku pobolj\u0161anja tu\u0111eg TZ-a i gubitka natje\u010daja), na kraju, jednostavno spremne prihvatiti profesionalni izazov i napraviti dobar proizvod.<\/p>\n

Sve to natjeralo nas je da obratimo pa\u017enju na relativno malog lokalnog developera \u2013 grupu kompanija \"Sanline\", koja se odmah odazvala na ve\u0107inu na\u0161ih zahtjeva i bila spremna realizirati sve potrebe vezane za novi BMS.\u00a0<\/p>\n

Rizici<\/h2>\n

\nDok su veliki igra\u010di poku\u0161avali shvatiti \u0161to mi zapravo \u017eelimo i sporazumijevali se s nama polako, lokalni developer je zakazao sastanak u na\u0161em uredu s sudjelovanjem svog tehni\u010dkog tima. Na tom sastanku, izvo\u0111a\u010d je jo\u0161 jednom pokazao \u017eelju za sudjelovanjem u projektu i \u2013 \u0161to je najva\u017enije \u2013 objasnio kako \u0107e potrebni sustav biti implementiran.\u00a0\u00a0\u00a0\u00a0<\/p>\n

Prije sastanka, primijetili smo dva rizika rada s timom koji nema podr\u0161ku velike nacionalne ili me\u0111unarodne kompanije:<\/p>\n

    \n
  1. Stru\u010dnjaci su mogli precijeniti svoje mogu\u0107nosti i kao rezultat jednostavno ne uspjeti, primjerice, koristit \u0107e slo\u017een softver ili \u0107e dizajnirati neizvedive algoritme rezervacije.<\/li>\n
  2. Nakon implementacije projekta, projektni tim se mo\u017ee raspasti i, shodno tome, podr\u0161ka proizvoda \u0107e biti ugro\u017eena.<\/li>\n<\/ol>\n

    \nKako bismo minimizirali te rizike, na sastanak smo pozvali na\u0161e vlastite stru\u010dnjake za razvoj. Zaposlenici potencijalnog izvo\u0111a\u010da su temeljito ispitani o tome na \u010demu se temelji sustav, kako planiraju provoditi rezervaciju i o drugim pitanjima u kojima, kao slu\u017eba za odr\u017eavanje, nismo dovoljno kompetentni.<\/p>\n

    Presudna prosudba bila je pozitivna: arhitektura postoje\u0107eg BMS sustava je moderna, jednostavna i pouzdana, mo\u017ee se doraditi, a predlo\u017eeni sustav rezervacije i sinkronizacije je logi\u010dan i funkcionalan.\u00a0<\/p>\n

    Prvi rizik je rije\u0161en. Drugi je isklju\u010den, dobiv\u0161i od izvo\u0111a\u010da potvrdu o spremnosti za prijenos izvornog koda sustava i dokumentacije, a tako\u0111er su odabrali programski jezik Python, koji je dobro poznat na\u0161im stru\u010dnjacima. To nam je jam\u010dilo mogu\u0107nost odr\u017eavanja sustava vlastitim snagama bez ikakvih pote\u0161ko\u0107a i dugog razdoblja obuke zaposlenika u slu\u010daju odlaska kompanije-developera s tr\u017ei\u0161ta.<\/p>\n

    Dodatna prednost platforme bila je u tome \u0161to je implementirana unutar Docker kontejnera: u ovom okru\u017eenju funkcioni\u0161u jezgro, web su\u010delje i baza podataka proizvoda. Ovakav pristup donosi brojne prednosti, uklju\u010duju\u0107i unaprijed postavljene postavke za maksimalnu brzinu implementacije rje\u0161enja u pore\u0111enju s \"klasi\u010dnim\" i jednostavno dodavanje novih ure\u0111aja u sistem. Princip \"sve zajedno\" maksimalno pojednostavljuje uvo\u0111enje sistema: dovoljno je samo raspakirati sistem i odmah ga po\u010deti koristiti.\u00a0<\/p>\n

    S ovim rje\u0161enjem jednostavnije je praviti kopije sistema, a unapre\u0111enja i implementacije mogu se raditi u odvojenom okru\u017eenju, bez zaustavljanja rada rje\u0161enja u cjelini.\u00a0\u00a0<\/p>\n

    Nakon \u0161to su oba rizika minimalizirana, izvo\u0111a\u010d je dostavio poslovnu ponudu. U njoj su razra\u0111eni svi najva\u017eniji parametri za nas u vezi s BMS sistemom.<\/p>\n

    Sigurnosna kopija<\/h2>\n

    \nNova BMS paradigma trebala je biti u oblaku, na virtualnoj ma\u0161ini.\u00a0<\/p>\n

    Bez fizi\u010dkog hardvera, bez servera i svih neugodnosti i rizika vezanih za ovaj model implementacije \u2013 obla\u010dno rje\u0161enje omogu\u0107ilo nam je da se zauvijek rije\u0161imo tih problema. Odluka je donesena da \u0107e sistem raditi u na\u0161em oblaku na dvjema lokacijama data centra u Sankt Peterburgu i Moskvi. To su dva potpuno funkcionalna sistema koja rade u re\u017eimu aktivnog spremanja s pristupom za sve ovla\u0161tene stru\u010dnjake.\u00a0<\/p>\n

    Dva sistema me\u0111usobno osiguravaju jedan drugoga, pru\u017eaju\u0107i punu rezervu i za ra\u010dunske snage i za kanale prijenosa podataka. Tako\u0111er su postavljene dodatne mjere sigurnosti, uklju\u010duju\u0107i rezervnu kopiju podataka i kanala, sistema, virtualnih ma\u0161ina u cjelini, te odvojenu rezervnu kopiju baze podataka svaki mjesec (najdragocjeniji resurs u perspektivi upravljanja i analize).\u00a0<\/p>\n

    Napomena: Rje\u0161enje rezerviranja kao opcija za BMS razvijeno je posebno prema na\u0161em zahtjevu. Sama shema rezerviranja izgledala je ovako:<\/p>\n

    \"Pra\u0107enje<\/p>\n

    Podr\u0161ka<\/h2>\n

    Najva\u017eniji trenutak za u\u010dinkovito eksploatiranje BMS rje\u0161enja \u2013 tehni\u010dka podr\u0161ka.\u00a0<\/p>\n

    Ovdje je sve jednostavno: novo rje\u0161enje ko\u0161talo bi nas prema ovom pokazatelju 35 000 rubalja mjese\u010dno za SLA \"reakcija unutar 8 sati\", \u0161to je 35 000 x 12 \/ 80 = $5 250 godi\u0161nje. Prva godina - besplatno.\u00a0<\/p>\n

    Za usporedbu: podr\u0161ka za staru BMS od dobavlja\u010da ko\u0161tala je 18 000 dolara godi\u0161nje uz pove\u0107anje iznosa za svaki novo dodani ure\u0111aj! Pri tome, kompanija nije isporu\u010dila odre\u0111enog menad\u017eera, a sve interakcije odvijale su se preko prodajnog menad\u017eera koji je bio zainteresiran za nas kao potencijalnog kupca s odgovaraju\u0107im naglaskom u obradi zahtjeva.\u00a0<\/p>\n

    Za manje novca dobili smo potpunu podr\u0161ku proizvoda, s menad\u017eerom ra\u010duna koji bi sudjelovao u razvoju proizvoda, s jednom to\u010dkom pristupa itd. Podr\u0161ka je postala znatno fleksibilnija \u2013 zahvaljuju\u0107i izravnom pristupu programerima za hitne ispravke u svim aspektima rada sustava, integraciji putem API-ja itd.<\/p>\n

    A\u017euriranja<\/h2>\n

    \nPrema predlo\u017eenom projektu u novoj BMS sve nadogradnje uklju\u010dene su u cijenu podr\u0161ke, tj. ne zahtijevaju dodatno pla\u0107anje. Iznimka su razvoj dodatne funkcionalnosti, iznad onoga \u0161to je navedeno u tehni\u010dkom zadatku.\u00a0<\/p>\n

    Stari sustav podrazumijevao je pla\u0107anje kako za nadogradnju ugra\u0111enog besplatnog softvera (poput Jave), tako i za ispravke gre\u0161aka. Nije se moglo odustati od toga, a bez nadogradnji sustav je u cjelini 'usporavao' zbog starih verzija unutarnjih komponenti.<\/p>\n

    I, naravno, nije bilo mogu\u0107e nadograditi softver bez kupnje paketa podr\u0161ke.<\/p>\n

    Fleksibilan pristup<\/h2>\n

    \nJo\u0161 jedan klju\u010dni zahtjev odnosio se na su\u010delje. \u017deljeli smo osigurati pristup njemu putem web preglednika s bilo kojeg mjesta, bez obvezne prisutnosti in\u017eenjera u podatkovnom centru. Osim toga, nastojali smo ostvariti animirano su\u010delje kako bi dinamika funkcioniranja infrastrukture bila jasnija za de\u017eurne in\u017eenjere.\u00a0<\/p>\n

    Tako\u0111er, u novom sustavu trebalo je osigurati podr\u0161ku za formule za izra\u010dun rada virtualnih senzora u in\u017eenjerskim sustavima \u2013 primjerice, za optimalnu raspodjelu elektri\u010dnih snaga po policama s opremom. Za to je potrebno imati na raspolaganju sve uobi\u010dajene matemati\u010dke operacije primjenjive na podatke senzora.\u00a0<\/p>\n

    Nakon toga, bio je potreban pristup SQL bazi podataka s mogu\u0107no\u0161\u0107u preuzimanja potrebnih podataka o radu opreme \u2013 naime, svi podaci o pra\u0107enju dvije tisu\u0107e ure\u0111aja i dvije tisu\u0107e virtualnih senzora koji generiraju otprilike 20 tisu\u0107a varijabli.\u00a0<\/p>\n

    Tako\u0111er je bio potreban modul za pra\u0107enje opreme u ormaru koji daje grafi\u010dki prikaz rasporeda ure\u0111aja u svakoj jedinici s ukupnom te\u017einom opreme, vo\u0111enje biblioteke ure\u0111aja i detaljnih informacija o svakom elementu.\u00a0<\/p>\n

    Dogovor o tehni\u010dkoj specifikaciji i potpisivanje ugovora<\/h2>\n

    \nU trenutku kada je bilo potrebno zapo\u010deti rad na novom sustavu, dopisivanje s \u2018velikim\u2019 kompanijama jo\u0161 uvijek je bilo daleko od rasprave o tro\u0161kovima njihovih ponuda, stoga smo usporedili primljenu ponudu s tro\u0161kovima a\u017euriranja starog BMS-a (vidi. prvi dio<\/a><\/noindex>), i rezultat je bio da je ona bila financijski privla\u010dnija i odgovarala na\u0161im zahtjevima.<\/p>\n

    Odlu\u010deno je.<\/p>\n

    Nakon odabira izvo\u0111a\u010da, pravnici su po\u010deli sastavljati ugovor, a tehni\u010dki timovi s obje strane usavr\u0161enju tehni\u010dku specifikaciju. Kao \u0161to je poznato, detaljna i jasna tehni\u010dka specifikacija \u2013 to je osnova uspjeha svih radova. \u0160to je vi\u0161e konkretnih informacija u tehni\u010dkoj specifikaciji, to je manje razo\u010daranja tipa \u2018mi smo htjeli druga\u010dije\u2019.<\/p>\n

    Navest \u0107u dva primjera razine detaljnosti zahtjeva u tehni\u010dkoj specifikaciji:<\/p>\n

      \n
    1. Nadzorni centri podataka imaju ovlasti dodavati nova ure\u0111aja u BMS, naj\u010de\u0161\u0107e PDU. U starom BMS-u to je bio nivo \u2018administrator\u2019 koji je tako\u0111er omogu\u0107avao promjenu postavki varijabli svih ure\u0111aja, a odvajanje funkcija nije bilo mogu\u0107e. To nam nije odgovaralo. U osnovnoj verziji nove platforme shema je bila sli\u010dna. Odmah smo naveli u tehni\u010dkoj specifikaciji da \u017eelimo odvojiti te uloge: postavke mo\u017ee mijenjati samo ovla\u0161teni radnik, dok nadzornici i dalje trebaju imati mogu\u0107nost dodavanja ure\u0111aja. Ova shema je prihva\u0107ena za realizaciju.<\/li>\n
    2. \u00a0U svakom standardnom BMS-u postoje tri tipi\u010dne kategorije obavijesti: CRVENA \u2013 potrebno je hitno reagirati, \u017dUTA \u2013 mo\u017ee se pratiti, PLAVA \u2013 'Informativna'. Tradicionalno smo koristili 'plave' obavijesti za pra\u0107enje prekora\u010denja komercijalnih parametara, na primjer, prekora\u010denje limita snage klijentove police. Ova vrsta obavijesti bila je namijenjena menad\u017eerima i nije bila zanimljiva slu\u017ebi odr\u017eavanja, ali je u starom BMS-u redovito zagu\u0161ivala popis aktivnih incidenata i ometala operativni rad. Samu logiku i bojnu diferencijaciju obavijesti smatrali smo uspje\u0161nom i zadr\u017eali, no u tehni\u010dkom zadatku smo posebno nazna\u010dili da 'plave' obavijesti trebaju, bez ometanja de\u017eurnih, ne\u010dujno 'padati' u zaseban odjeljak, gdje \u0107e s njima raditi komercijalni stru\u010dnjaci.<\/li>\n<\/ol>\n

      \nSli\u010dna razina detaljnosti opisivala je formate izrade grafova i izvo\u0111enja izvje\u0161taja, obrise su\u010delja, popis ure\u0111aja koji su trebali biti pra\u0107eni i jo\u0161 mno\u0161tvo drugih stvari.\u00a0<\/p>\n

      To je bio zaista kreativni rad triju radnih grupa \u2013 slu\u017ebe naru\u010ditelja, koja je diktirala svoje zahtjeve i uvjete; tehni\u010dkih stru\u010dnjaka s obje strane, \u010dija je zada\u0107a bila pretvoriti te uvjete u tehni\u010dku dokumentaciju; tima programera izvo\u0111a\u010da, koji su realizirali zahtjeve naru\u010ditelja prema razvijenoj tehni\u010dkoj dokumentaciji... Na kraju smo neka od na\u0161ih neprincipijelnih zahtjeva prilagodili funkcionalnosti ve\u0107 postoje\u0107ih platformi, dok je izvo\u0111a\u010d bio du\u017ean dodatno ih napisati za nas.\u00a0<\/p>\n

      Paralelni rad dvaju sustava<\/h2>\n

      \n\"Pra\u0107enje
      \nDo\u0161lo je vrijeme za realizaciju. U praksi to je zna\u010dilo da dajemo izvo\u0111a\u010du mogu\u0107nost da postavi prototip BMS-a u na\u0161em virtualnom oblaku i omogu\u0107avamo mre\u017eni pristup svim ure\u0111ajima koji zahtijevaju pra\u0107enje.<\/p>\n

      Pri tome nova sustav jo\u0161 nije bio spreman za rad. U ovoj fazi bilo nam je va\u017eno zadr\u017eati pra\u0107enje u starom sustavu i istovremeno omogu\u0107iti pristup ure\u0111ajima novom sustavu. Nemogu\u0107e je normalno izgraditi sustav ne vide\u0107i u njemu ure\u0111aje, koje zauzvrat ne mo\u017eemo isklju\u010diti iz pra\u0107enja starim sustavom.\u00a0<\/p>\n

      Je li mogu\u0107e da ure\u0111aji istovremeno odgovore na upite dviju sustava, nije bilo o\u010dito bez stvarnih ispitivanja. Postojala je mogu\u0107nost da bi dvostruki istodobni upiti doveli do \u010destih odbijanja odgovora od strane ure\u0111aja i da bismo dobili brojne pogre\u0161ke zbog nedostupnosti ure\u0111aja, \u0161to bi zauzvrat blokiralo rad starog sustava nadzora.<\/p>\n

      Mre\u017eni odjel je postavio virtualne rute od prototipa nove BMS, raspore\u0111ene u oblaku, do ure\u0111aja, a dobili smo rezultate:\u00a0<\/p>\n