ProHoster > Blogs > Administrācija > Monitorings datu centrā: kā mēs nomainījām veco BMS pret jaunu. 2. daļa

Monitorings datu centrā: kā mēs nomainījām veco BMS pret jaunu. 2. daļa

Monitorings datu centrā: kā mēs nomainījām veco BMS pret jaunu. 2. daļa

Pirmajā daļā mēs runājām par to, kāpēc nolēmām nomainīt veco BMS sistēmu savos datu centros pret jaunu. Un ne tikai mainīt, bet attīstīt no nulles, lai atbilstu jūsu prasībām. Otrajā daļā mēs pastāstīsim, kā mēs to izdarījām.

Tirgus analīze

Ņemot vērā tos, kas aprakstÄ«ti pirmā daļa vēlmes un lēmumu atteikties atjaunināt esoÅ”o sistēmu, rakstÄ«jām tehnisko specifikāciju, lai rastu risinājumu tirgÅ« un veicām uzziņas vairākiem lieliem uzņēmumiem, kas nodarbojas tikai ar industriālo SCADA sistēmu izveidi. 

Jau pirmās viņu atbildes liecināja, ka monitoringa sistēmu tirgus lÄ«deri galvenokārt turpina strādāt pie aparatÅ«ras serveriem, lai gan migrācijas process uz mākoņiem Å”ajā segmentā jau ir sācies. Runājot par virtuālo maŔīnu rezervÄ“Å”anu, neviens neatbalstÄ«ja Å”o iespēju. Turklāt radās sajÅ«ta, ka neviens no tirgÅ« redzamajiem izstrādātājiem pat nedemonstrēja izpratni par atlaiÅ”anas nepiecieÅ”amÄ«bu: ā€œmākonis nekrÄ«tā€ bija visizplatÄ«tākā atbilde. Faktiski mums piedāvāja datu centra uzraudzÄ«bu izvietot mākonÄ«, kas fiziski atrodas tajā paŔā datu centrā.

Å eit mums ir jāveic neliela atkāpe par darbuzņēmēja atlases procesu. Cenai, protams, ir nozÄ«me, taču jebkura kompleksa projekta Ä«stenoÅ”anas konkursa laikā dialoga stadijā ar piegādātājiem sāc just, kurÅ” no kandidātiem ir vairāk ieinteresēts un spējÄ«gāks to Ä«stenot. 

Tas ir Ä«paÅ”i pamanāms sarežģītos projektos. 

Pamatojoties uz tehnisko specifikāciju jautājumu noskaidroÅ”anas raksturu, darbuzņēmējus var iedalÄ«t tādos, kas interesējas par vienkārÅ”u pārdoÅ”anu (jÅ«tams pārdoÅ”anas vadÄ«tāja standarta spiediens) un tajos, kuri interesējas par produkta izstrādi, uzklausot un izprotot klientu, veidojot konstruktÄ«vu. grozÄ«jumus tehniskajās specifikācijās pat pirms galÄ«gās izvēles (pat neskatoties uz reālu risku uzlabot kāda cita tehniskās specifikācijas un zaudēt piedāvājumu), galu galā viņi vienkārÅ”i ir gatavi pieņemt profesionālu izaicinājumu un izgatavot labu produktu.

Tas viss lika pievērst uzmanÄ«bu salÄ«dzinoÅ”i nelielam vietējam izstrādātājam - Sunline uzņēmumu grupai, kas nekavējoties reaģēja uz lielāko daļu mÅ«su prasÄ«bu un bija gatava ieviest visas vajadzÄ«bas saistÄ«bā ar jauno BMS. 

Riski

Kamēr lielie spēlētāji mēģināja saprast, ko mēs vēlamies, un nesteidzÄ«gi veica saraksti ar mums, iesaistot pirmspārdoÅ”anas lÄ«meņa speciālistus, vietējais izstrādātājs ieplānoja tikÅ”anos mÅ«su birojā ar savas tehniskās komandas piedalÄ«Å”anos. Å ajā sanāksmē darbuzņēmējs vēlreiz demonstrēja vēlmi piedalÄ«ties projektā un, galvenais, paskaidroja, kā tiks ieviesta nepiecieÅ”amā sistēma.    

Pirms tikÅ”anās mēs saskatÄ«jām divus riskus, strādājot ar komandu, kurai aiz muguras nav liela valsts vai starptautiska uzņēmuma resursu:

  1. Speciālisti var pārvērtēt savas iespējas un rezultātā vienkārÅ”i netikt galā, piemēram, viņi izmantos sarežģītu programmatÅ«ru vai izstrādās neizpildāmus rezervÄ“Å”anas algoritmus.
  2. Pēc projekta pabeigÅ”anas projekta komanda var izjukt, un tāpēc produkta atbalsts bÅ«s apdraudēts.

Lai mazinātu Å”os riskus, uz tikÅ”anos aicinājām savus attÄ«stÄ«bas speciālistus. Tika rÅ«pÄ«gi intervēti potenciālā darbuzņēmēja darbinieki par to, uz ko balstÄ«ta sistēma, kā plānots ieviest atlaiÅ”anu, un citiem jautājumiem, kuros mēs kā ekspluatācijas dienests neesam pietiekami kompetenti.

Spriedums bija pozitÄ«vs: esoŔās BMS platformas arhitektÅ«ra ir moderna, vienkārÅ”a un uzticama, pilnveidojama, piedāvātā redundances un sinhronizācijas shēma ir loÄ£iska un funkcionāla. 

Pirmais risks tika novērsts. Otrs tika izslēgts, saņemot apstiprinājumu no izpildÄ«tāja, ka viņi ir gatavi nodot mums sistēmas pirmkodu un dokumentāciju, kā arÄ« izvēloties Python programmÄ“Å”anas valodu, kas bija labi zināma mÅ«su speciālistiem. Tas mums garantēja iespēju patstāvÄ«gi uzturēt sistēmu bez jebkādām grÅ«tÄ«bām un ilgu darbinieku apmācÄ«bas periodu gadÄ«jumā, ja izstrādes uzņēmums aiziet no tirgus.

Platformas papildu priekÅ”rocÄ«ba bija tā, ka tā tika ieviesta Docker konteineros: kodols, tÄ«mekļa saskarne un produktu datu bāzes funkcija Å”ajā vidē. Å Ä« pieeja nodroÅ”ina daudzas priekÅ”rocÄ«bas, tostarp iepriekÅ” iestatÄ«tus iestatÄ«jumus risinājuma izvietoÅ”anas lielākajam ātrumam salÄ«dzinājumā ar ā€œklasiskoā€ un vienkārÅ”u jaunu ierīču pievienoÅ”anu sistēmai. Princips ā€œviss kopāā€ maksimāli vienkārÅ”o sistēmas ievieÅ”anu: vienkārÅ”i izpakojiet sistēmu un varat to nekavējoties izmantot. 

Izmantojot Å”o risinājumu, ir vienkārŔāk izveidot sistēmas kopijas, kā arÄ« to var uzlabot un ieviest jauninājumus atseviŔķā vidē, neapturot risinājuma darbÄ«bu kopumā.  

Kad abi riski tika samazināti lÄ«dz minimumam, darbuzņēmējs nodroÅ”ināja KP. Tas aptvēra visus mums svarÄ«gākos BMS sistēmas parametrus.

Rezervācija

Jaunajai BMS sistēmai bija jāatrodas mākonÄ«, virtuālajā maŔīnā. 

Bez aparatÅ«ras, bez serveriem un visām neērtÄ«bām un riskiem, kas saistÄ«ti ar Å”o izvietoÅ”anas modeli ā€“ mākoņrisinājums ļāva mums no tiem atbrÄ«voties uz visiem laikiem. Tika nolemts, ka sistēma darbosies mÅ«su mākonÄ« divos datu centru objektos Sanktpēterburgā un Maskavā. Å Ä«s ir divas pilnÄ«bā funkcionējoÅ”as sistēmas, kas darbojas aktÄ«vā gaidstāves režīmā ar piekļuvi visiem pilnvarotajiem speciālistiem. 

Abas sistēmas viena otru apdroÅ”ina, nodroÅ”inot pilnu gan skaitļoÅ”anas jaudas, gan datu pārraides kanālu rezervi. Ir arÄ« konfigurēti papildu droŔības pasākumi, tostarp datu un kanālu, sistēmu, virtuālo maŔīnu dublÄ“Å”ana kopumā un atseviŔķa datu bāzes dublÄ“Å”ana reizi mēnesÄ« (pārvaldÄ«bas un analÄ«zes ziņā visvērtÄ«gākais resurss). 

Ņemiet vērā, ka atlaiÅ”ana kā iespēja BMS risinājumā tika izstrādāta Ä«paÅ”i mÅ«su pieprasÄ«jumam. Pati rezervÄ“Å”anas shēma izskatÄ«jās Ŕādi:

Monitorings datu centrā: kā mēs nomainījām veco BMS pret jaunu. 2. daļa

atbalsts

VissvarÄ«gākais BMS risinājuma efektÄ«vai darbÄ«bai ir tehniskais atbalsts. 

Å eit viss ir vienkārÅ”i: jauna sistēma pēc Ŕī rādÄ«tāja mums izmaksātu 35 000 rubļu. mēnesÄ« par SLA "atbildi 8 stundu laikā", tas ir, 35 000 x 12 / 80 = 5 USD gadā. Pirmais gads ir bezmaksas. 

SalÄ«dzinājumam, vecās BMS uzturÄ“Å”ana no pārdevēja maksāja 18 000 USD gadā, palielinot summu par katru jaunu pievienoto ierÄ«ci! Tajā paŔā laikā uzņēmums nenodroÅ”ināja Ä«paÅ”u vadÄ«tāju, visa mijiedarbÄ«ba notika ar pārdoÅ”anas menedžera starpniecÄ«bu, kurÅ” interesējas par mums kā potenciālo pircēju ar atbilstoÅ”u uzsvaru pieprasÄ«jumu apstrādē. 

Par mazāku naudu saņēmām pilnu produktu atbalstu, ar konta menedžeri, kurÅ” piedalÄ«tos produktu izstrādē, ar vienu ieejas punktu utt. Atbalsts kļuva daudz elastÄ«gāks ā€” pateicoties tieÅ”ai piekļuvei izstrādātājiem, lai veiktu tÅ«lÄ«tējus pielāgojumus jebkuram sistēmas aspektam, integrācijai, izmantojot API, utt.

Atjauninājumi

Saskaņā ar piedāvāto KP jaunajā BMS visi atjauninājumi ir iekļauti atbalsta izmaksās, t.i. neprasa papildu samaksu. Izņēmums ir papildu funkcionalitātes izstrāde, kas pārsniedz tehniskajās specifikācijās norādÄ«to. 

Vecajā sistēmā bija jāmaksā gan par programmaparatÅ«ras atjauninājumiem (piemēram, Java), gan kļūdu labojumiem. No tā nebija iespējams atteikties; ja nebija atjauninājumu, sistēma kopumā ā€œpalēninājāsā€ iekŔējo komponentu veco versiju dēļ.

Un, protams, nebija iespējams atjaunināt programmatūru, neiegādājoties atbalsta paketi.

Elastīga pieeja

Vēl viena pamatprasÄ«ba attiecās uz saskarni. Mēs vēlējāmies nodroÅ”ināt piekļuvi tai caur tÄ«mekļa pārlÅ«kprogrammu no jebkuras vietas, bez obligātas inženiera klātbÅ«tnes datu centra teritorijā. Turklāt mēs centāmies izveidot animētu saskarni, lai infrastruktÅ«ras dinamika bÅ«tu skaidrāka dežurējoÅ”ajiem inženieriem. 

ArÄ« jaunajā sistēmā bija nepiecieÅ”ams nodroÅ”ināt atbalstu formulām virtuālo sensoru darbÄ«bas aprēķināŔanai inženiersistēmās - piemēram, optimālai elektroenerÄ£ijas sadalei pa iekārtu plauktiem. Lai to izdarÄ«tu, jÅ«su rÄ«cÄ«bā ir jābÅ«t visām parastajām matemātiskajām operācijām, kas attiecas uz sensoru indikatoriem. 

Tālāk bija nepiecieÅ”ama piekļuve SQL datu bāzei ar iespēju paņemt no tās nepiecieÅ”amos datus par iekārtas darbÄ«bu - proti, visus divu tÅ«kstoÅ”u ierīču un divu tÅ«kstoÅ”u virtuālo sensoru monitoringa ierakstus, kas Ä£enerē aptuveni 20 tÅ«kstoÅ”us mainÄ«go. 

Bija nepiecieÅ”ams arÄ« statÄ«va aprÄ«kojuma uzskaites modulis, kas nodroÅ”ina grafisku ierīču izvietojuma attēlojumu katrā blokā ar aparatÅ«ras kopējā svara aprēķinu, ierīču bibliotēku uzturÄ“Å”anu un detalizētu informāciju par katru elementu. 

Tehnisko specifikāciju apstiprināŔana un līguma parakstīŔana

Laikā, kad bija jāuzsāk darbs pie jaunās sistēmas, sarakste ar ā€œlielajiemā€ uzņēmumiem vēl bija ļoti tālu no to piedāvājumu izmaksu apsprieÅ”anas, tāpēc saņemto KP salÄ«dzinājām ar vecās BMS atjaunināŔanas izmaksām (sk. pirmā daļa), un rezultātā tas izrādÄ«jās pievilcÄ«gāks cenas ziņā un atbilst mÅ«su prasÄ«bām.

Izvēle ir izdarīta.

Pēc darbuzņēmēja izvēles juristi sāka sastādÄ«t lÄ«gumu, un abu puÅ”u tehniskās komandas sāka pieslÄ«pēt tehniskās specifikācijas. Kā jÅ«s zināt, detalizētas un kompetentas tehniskās specifikācijas ir jebkura darba panākumu pamatā. Jo vairāk specifikācijas ir tehniskajās specifikācijās, jo mazāk vilÅ”anās, piemēram, ā€œbet tas nav tas, ko mēs gribējāmā€.

Es sniegÅ”u divus piemērus par prasÄ«bu detalizācijas pakāpi tehniskajās specifikācijās:

  1. DežūrējoÅ”ie datu centri ir pilnvaroti BMS pievienot jaunas ierÄ«ces, visbiežāk tās ir PDU. Vecajā BMS tas bija "administratora" lÄ«menis, kas arÄ« ļāva mainÄ«t visu ierīču mainÄ«gos iestatÄ«jumus, un nebija iespējams nodalÄ«t funkcijas. Tas mums nederēja. EsoÅ”ajā jaunās platformas pamata versijā shēma bija lÄ«dzÄ«ga. Uzreiz darba uzdevumā norādÄ«jām, ka vēlamies Ŕīs lomas nodalÄ«t: uzstādÄ«jumus drÄ«kst mainÄ«t tikai pilnvarots darbinieks, bet dežurantiem jāturpina pievienot ierÄ«ces. Å Ä« shēma tika pieņemta Ä«stenoÅ”anai.
  2.  Jebkurā standarta BMS ir trÄ«s tipiskas paziņojumu kategorijas: SARKANS - uz tiem jāreaģē nekavējoties, DZELTENS - var novērot, ZILS - "InformatÄ«vs". Mēs tradicionāli esam izmantojuÅ”i zilos brÄ«dinājumus, lai uzraudzÄ«tu, kad ir pārsniegti biznesa parametri, piemēram, klienta plaukts pārsniedz ietilpÄ«bas ierobežojumu. Šāda veida paziņoÅ”ana mÅ«su gadÄ«jumā bija paredzēta vadÄ«tājiem un neinteresēja ekspluatācijas dienestu, taču vecajā BMS tas regulāri aizsērēja aktÄ«vo incidentu sarakstu un traucēja operatÄ«vajam darbam. PaÅ”u paziņojumu bikÅ”u loÄ£iku un krāsu diferenciāciju uzskatÄ«jām par veiksmÄ«gu un saglabājām, tomēr tehniskajās specifikācijās Ä«paÅ”i bija norādÄ«ts, ka ā€œzilajiemā€ paziņojumiem, nenovērÅ”ot dežurantu uzmanÄ«bu, klusi ā€œjālienā€ atseviŔķā sadaļā, kur tie ar to nodarbosies komercspeciālisti.

Ar lÄ«dzÄ«gu detalizācijas pakāpi tika noteikti grafiku veidoÅ”anas un atskaiÅ”u Ä£enerÄ“Å”anas formāti, saskarņu kontÅ«ras, to ierīču saraksts, kuras bija jāuzrauga, un daudzas citas lietas. 

Å is bija patiesi radoÅ”s trÄ«s darba grupu darbs ā€“ klientu apkalpoÅ”ana, kas diktēja savas prasÄ«bas un nosacÄ«jumus; abu puÅ”u tehniskie speciālisti, kuru uzdevums bija Å”os nosacÄ«jumus pārveidot tehniskajā dokumentācijā; darbuzņēmēju programmētāju komandas, kas ieviesa pasÅ«tÄ«tāja prasÄ«bas atbilstoÅ”i izstrādātajai tehniskajai dokumentācijai... Rezultātā mēs pielāgojām dažas mÅ«su bezprincipiālās prasÄ«bas esoÅ”as platformas funkcionalitātei, un darbuzņēmējs apņēmās kaut ko pievienot mÅ«su vietā. 

Divu sistēmu paralēla darbība

Monitorings datu centrā: kā mēs nomainījām veco BMS pret jaunu. 2. daļa
Ir pienācis laiks Ä«stenoÅ”anai. Praksē tas nozÄ«mēja, ka mēs sniedzam darbuzņēmējam iespēju izvietot BMS prototipu mÅ«su virtuālajā mākonÄ« un nodroÅ”ināt piekļuvi tÄ«klam visām ierÄ«cēm, kurām nepiecieÅ”ama uzraudzÄ«ba.

Taču jaunā sistēma vēl nebija gatava darbÄ«bai. Å ajā posmā mums bija svarÄ«gi saglabāt uzraudzÄ«bu vecajā sistēmā un vienlaikus nodroÅ”ināt piekļuvi ierÄ«cēm jaunajai sistēmai. Nav iespējams pareizi izveidot sistēmu, neredzot tajā ierÄ«ces, kuras savukārt nevar atslēgt no vecās sistēmas uzraudzÄ«bas. 

Bez reālas pārbaudes nebija skaidrs, vai ierÄ«ces spēj izturēt vienlaicÄ«gu divu sistēmu pratināŔanu. Pastāvēja iespēja, ka dubultā vienlaicÄ«ga aptauja izraisÄ«s biežu atteikumu atbildēt no ierÄ«cēm un saņemsim daudz kļūdu par ierīču nepieejamÄ«bu, kas savukārt bloķēs vecās uzraudzÄ«bas sistēmas darbÄ«bu.

TÄ«kla nodaļa veica virtuālus marÅ”rutus no jaunā BMS prototipa, kas tika izvietots mākonÄ«, uz ierÄ«cēm, un mēs saņēmām rezultātus: 

  • ierÄ«ces, kas savienotas, izmantojot SNMP protokolu, praktiski nekad netika atvienotas vienlaicÄ«gu pieprasÄ«jumu dēļ, 
  • ierÄ«cēm, kas savienotas caur vārtejām, izmantojot modbas-TCP protokolus, radās problēmas, kuras tika atrisinātas, saprātÄ«gi samazinot to aptauju biežumu.  

Un tad sākām vērot, kā mÅ«su acu priekŔā top jauna sistēma, tajā parādÄ«jās mums jau pazÄ«stamas ierÄ«ces, bet citā saskarnē - ērti, ātri, pieejami pat no telefona.

Mēs jums pastāstÄ«sim, kas beigās notika mÅ«su raksta treÅ”ajā daļā.

Avots: www.habr.com

Pievieno komentāru