V prvej časti sme si povedali, prečo sme sa rozhodli vymeniť starý BMS systém v našich dátových centrách za nový. A nielen meniť, ale rozvíjať sa od nuly, aby vyhovoval vašim požiadavkám. V druhej časti vám povieme, ako sa nám to podarilo.
Analýza trhu
Berúc do úvahy tie, ktoré sú opísané v želanie a rozhodnutie odmietnuť aktualizáciu existujúceho systému, sme spísali technickú špecifikáciu, aby sme našli riešenie na trhu a obrátili sa na niekoľko veľkých spoločností zaoberajúcich sa len tvorbou priemyselných SCADA systémov.
Už prvé ohlasy od nich ukázali, že lídri trhu monitorovacích systémov primárne pokračujú v práci na hardvérových serveroch, hoci proces migrácie do cloudu v tomto segmente už začal. Čo sa týka rezervovania virtuálnych strojov, túto možnosť nikto nepodporoval. Navyše tu bol pocit, že žiadny z vývojárov viditeľných na trhu ani nepreukázal pochopenie potreby redundancie: „cloud nepadá“ bola najčastejšia odpoveď. V skutočnosti nám bolo ponúknuté umiestniť monitorovanie dátového centra do cloudu fyzicky umiestneného v tom istom dátovom centre.
Tu musíme urobiť malú odbočku o procese výberu dodávateľa. Na cene, samozrejme, záleží, ale pri akomkoľvek tendri na realizáciu komplexného projektu, v štádiu dialógu s dodávateľmi, začínate cítiť, ktorý z kandidátov má väčší záujem a je schopný ho zrealizovať.
Je to viditeľné najmä pri zložitých projektoch.
Na základe povahy objasňujúcich otázok k technickým špecifikáciám možno dodávateľov rozdeliť na tých, ktorí majú záujem jednoducho predávať (štandardný tlak obchodného manažéra je cítiť) a tých, ktorí majú záujem o vývoj produktu, po vypočutí a pochopení zákazníka, konštruktívneho úpravy technických špecifikácií ešte pred konečným výberom (aj napriek reálnemu riziku zlepšenia technických špecifikácií niekoho iného a prehry vo výberovom konaní), nakoniec sú jednoducho pripravení prijať profesionálnu výzvu a vyrobiť dobrý produkt.
To všetko nás prinútilo venovať pozornosť relatívne malému lokálnemu developerovi – skupine spoločností Sunline, ktorá na väčšinu našich požiadaviek reagovala okamžite a bola pripravená realizovať všetky potreby ohľadom nového BMS.
Riziká
Zatiaľ čo sa veľkí hráči snažili pochopiť, čo chceme, a pokojne s nami korešpondovali so špecialistami na predpredajnú úroveň, miestny developer naplánoval stretnutie v našej kancelárii za účasti svojho technického tímu. Na tomto stretnutí zhotoviteľ opäť preukázal chuť podieľať sa na projekte a hlavne vysvetlil, ako bude požadovaný systém implementovaný.
Pred stretnutím sme videli dve riziká práce s tímom, ktorý nemá za sebou zdroje veľkej národnej alebo medzinárodnej spoločnosti:
- Špecialisti by mohli preceniť svoje schopnosti a v dôsledku toho jednoducho zlyhať, napríklad použiť zložitý softvér alebo navrhnúť nerealizovateľné rezervačné algoritmy.
- Po dokončení projektu sa môže projektový tím rozpadnúť, a preto bude ohrozená podpora produktu.
Aby sme tieto riziká minimalizovali, pozvali sme na stretnutie vlastných vývojových špecialistov. S potenciálnymi zamestnancami dodávateľa boli dôkladne vypočuté, na čom je systém založený, ako sa plánuje implementácia redundancie a ďalšie záležitosti, v ktorých nie sme ako prevádzková služba dostatočne kompetentní.
Verdikt bol pozitívny: architektúra existujúcej platformy BMS je moderná, jednoduchá a spoľahlivá, dá sa vylepšiť, navrhovaná schéma redundancie a synchronizácie je logická a použiteľná.
Prvé riziko bolo zvládnuté. Druhý bol vylúčený po prijatí potvrdenia od dodávateľa, že je pripravený preniesť zdrojový kód systému a dokumentácie k nám, a tiež výberom programovacieho jazyka Python, ktorý bol našim odborníkom dobre známy. To nám zaručilo možnosť samostatnej údržby systému bez akýchkoľvek ťažkostí a dlhého školenia zamestnancov v prípade odchodu developerskej spoločnosti z trhu.
Ďalšou výhodou platformy bolo, že bola implementovaná v kontajneroch Docker: v tomto prostredí funguje jadro, webové rozhranie a produktová databáza. Tento prístup poskytuje mnoho výhod, vrátane prednastavených nastavení pre najvyššiu rýchlosť nasadenia riešenia v porovnaní s „klasickým“ a jednoduchým pridávaním nových zariadení do systému. Princíp „všetko spolu“ maximálne zjednodušuje implementáciu systému: stačí systém rozbaliť a môžete ho ihneď používať.
S týmto riešením je jednoduchšie vytvárať kópie systému a môžete ho vylepšovať a implementovať upgrady v samostatnom prostredí bez zastavenia prevádzky riešenia ako celku.
Keď boli obe riziká minimalizované, dodávateľ poskytol CP. Pokrýval pre nás všetky najdôležitejšie parametre systému BMS.
Rezervácia
Nový BMS systém musel byť umiestnený v cloude, na virtuálnom stroji.
Žiadny hardvér, žiadne servery a všetky nepríjemnosti a riziká spojené s týmto modelom nasadenia – cloudové riešenie nám umožnilo sa ich navždy zbaviť. Rozhodlo sa, že systém bude fungovať v našom cloude v dvoch lokalitách dátových centier v Petrohrade a Moskve. Ide o dva plne funkčné systémy pracujúce v aktívnom pohotovostnom režime s prístupom všetkých autorizovaných špecialistov.
Oba systémy sa navzájom poisťujú a poskytujú plnú rezervu výpočtového výkonu a kanálov prenosu dát. Boli tiež nakonfigurované ďalšie bezpečnostné opatrenia, vrátane zálohovania údajov a kanálov, systémov, virtuálnych strojov vo všeobecnosti a samostatnej zálohy databázy raz za mesiac (najcennejší zdroj z hľadiska správy a analýzy).
Upozorňujeme, že redundancia ako možnosť v riešení BMS bola vyvinutá špeciálne pre našu požiadavku. Samotná schéma rezervácie vyzerala takto:
Podpora
Najdôležitejším bodom pre efektívne fungovanie BMS riešenia je technická podpora.
Všetko je tu jednoduché: nový systém by nás podľa tohto ukazovateľa stál 35 000 rubľov. za mesiac za SLA „odpoveď do 8 hodín“, to znamená 35 000 x 12 / 80 = 5 250 USD za rok. Prvý rok je zadarmo.
Pre porovnanie, údržba starého BMS od predajcu stála 18 000 dolárov ročne so zvýšením sumy za každé pridané nové zariadenie! Zároveň spoločnosť neposkytla dedikovaného manažéra, všetka interakcia prebiehala cez obchodného manažéra, ktorý sa o nás zaujíma ako o potenciálneho kupca so zodpovedajúcim dôrazom na spracovanie požiadaviek.
Za menej peňazí sme dostali plnú produktovú podporu, s account manažérom, ktorý by sa podieľal na vývoji produktu, s jediným vstupným bodom atď. Podpora sa stala oveľa flexibilnejšou – vďaka priamemu prístupu k vývojárom pre rýchle úpravy akéhokoľvek aspektu systému, integrácia cez API atď.
Aktualizácia
Podľa navrhovaného CP v novom BMS sú všetky aktualizácie zahrnuté v cene podpory, t.j. nevyžadujú dodatočnú platbu. Výnimkou je vývoj dodatočných funkcií nad rámec toho, čo je uvedené v technických špecifikáciách.
Starý systém vyžadoval platbu za aktualizácie firmvéru (napríklad Java) a opravy chýb. Nebolo možné to odmietnuť, pri absencii aktualizácií sa systém ako celok „spomalil“ kvôli starým verziám interných komponentov.
A, samozrejme, nebolo možné aktualizovať softvér bez zakúpenia balíka podpory.
Flexibilný prístup
Ďalšia zásadná požiadavka sa týkala rozhrania. Chceli sme k nemu poskytnúť prístup cez webový prehliadač odkiaľkoľvek, bez povinnej prítomnosti inžiniera na území dátového centra. Okrem toho sme sa snažili vytvoriť animované rozhranie, aby bola dynamika infraštruktúry pre inžinierov v službe jasnejšia.
Aj v novom systéme bolo potrebné poskytnúť podporu pre vzorce pre výpočet prevádzky virtuálnych senzorov v inžinierskych systémoch - napríklad pre optimálnu distribúciu elektrickej energie medzi stojanmi zariadení. Na to potrebujete mať k dispozícii všetky bežné matematické operácie, ktoré sa vzťahujú na indikátory senzorov.
Ďalej bol potrebný prístup k SQL databáze s možnosťou preberať z nej potrebné údaje o prevádzke zariadenia – konkrétne všetky záznamy z monitorovania dvoch tisíc zariadení a dvetisíc virtuálnych senzorov generujúcich približne 20 tisíc premenných.
Potrebný bol aj modul účtovania rackových zariadení, ktorý by poskytoval grafické znázornenie usporiadania zariadení v každej jednotke s výpočtom celkovej hmotnosti hardvéru, udržiaval knižnicu zariadení a podrobné informácie o každom prvku.
Schválenie technických špecifikácií a podpis zmluvy
V čase, keď bolo potrebné začať pracovať na novom systéme, mala korešpondencia s „veľkými“ firmami ešte veľmi ďaleko od diskusie o nákladoch na ich návrhy, preto sme porovnali prijaté CP s nákladmi na aktualizáciu starého BMS (viď. ), a vo výsledku sa ukázalo, že je cenovo atraktívnejší a spĺňa naše požiadavky.
Výber bol urobený.
Po výbere dodávateľa začali právnici pripravovať dohodu a technické tímy z oboch strán začali upravovať technické špecifikácie. Ako viete, podrobné a kompetentné technické špecifikácie sú základom úspechu akejkoľvek práce. Čím viac špecifikácií je v technických špecifikáciách, tým menej sklamaní typu „ale toto nie je to, čo sme chceli“.
V technických špecifikáciách uvediem dva príklady úrovne podrobnosti požiadaviek:
- Dátové centrá v službe sú oprávnené pridávať nové zariadenia do BMS, najčastejšie sú to PDU. V starom BMS to bola úroveň „správca“, ktorá umožňovala aj zmenu variabilných nastavení všetkých zariadení a nebolo možné oddeliť funkcie. Toto nám nevyhovovalo. V existujúcej základnej verzii novej platformy bola schéma podobná. Okamžite sme v podmienkach zadania naznačili, že chceme tieto roly oddeliť: nastavenia by mal meniť iba oprávnený zamestnanec, no tí, ktorí sú v službe, by mali mať aj naďalej možnosť pridávať zariadenia. Táto schéma bola prijatá na implementáciu.
- V každom štandardnom BMS existujú tri typické kategórie upozornení: ČERVENÁ – musí sa na ne reagovať okamžite, ŽLTÁ – možno pozorovať, MODRÁ – „Informačné“. Už tradične používame modré upozornenia na sledovanie prekročenia obchodných parametrov, ako je napríklad prekročenie kapacitného limitu stojana zákazníka. Tento typ upozornenia bol v našom prípade určený pre manažérov a prevádzkovú službu nezaujímal, no v starom BMS pravidelne upchával zoznam aktívnych incidentov a zasahoval do operatívnej práce. Samotnú logiku a farebné odlíšenie notifikačných nohavíc sme považovali za vydarené a zachovali sme ich, avšak technické špecifikácie konkrétne naznačovali, že „modré“ notifikácie by sa mali bez toho, aby rozptyľovali službukonajúcich dôstojníkov, potichu „presypať“ do samostatnej sekcie, kde budú riešiť obchodní špecialisti.
S podobnou mierou detailov boli predpísané formáty na vytváranie grafov a generovanie reportov, obrysy rozhraní, zoznam zariadení, ktoré bolo potrebné monitorovať a mnoho ďalších vecí.
Išlo o skutočne kreatívnu prácu troch pracovných skupín – zákazníckeho servisu, ktorý si diktoval svoje požiadavky a podmienky; technických špecialistov na oboch stranách, ktorých úlohou bolo pretaviť tieto podmienky do technickej dokumentácie; tímy zmluvných programátorov, ktorí implementovali požiadavky zákazníka podľa vypracovanej technickej dokumentácie... Výsledkom bolo, že sme niektoré naše bezzásadové požiadavky prispôsobili funkcionalite existujúcej platformy a dodávateľ sa zaviazal niečo pridať za nás.
Paralelná prevádzka dvoch systémov
Je čas na realizáciu. V praxi to znamenalo, že dodávateľovi dávame možnosť nasadiť prototyp BMS do nášho virtuálneho cloudu a poskytujeme sieťový prístup ku všetkým zariadeniam, ktoré vyžadujú monitorovanie.
Nový systém však ešte nebol pripravený na prevádzku. V tejto fáze bolo pre nás dôležité zachovať monitorovanie v starom systéme a zároveň umožniť prístup k zariadeniam do nového systému. Je nemožné správne zostaviť systém bez toho, aby ste v ňom nevideli zariadenia, ktoré zase nemožno deaktivovať z monitorovania starým systémom.
To, či zariadenia vydržia súčasné vypočúvanie dvoma systémami, nebolo bez skutočného testovania zrejmé. Existovala možnosť, že dvojitý simultánny dopyt povedie k častému odmietnutiu odpovede zo zariadení a dostaneme veľa chýb týkajúcich sa nedostupnosti zariadení, čo by následne zablokovalo prevádzku starého monitorovacieho systému.
Sieťové oddelenie spustilo virtuálne trasy z prototypu nového BMS nasadeného v cloude do zariadení a dostali sme výsledky:
- zariadenia pripojené cez protokol SNMP sa prakticky nikdy neodpojili v dôsledku simultánnych požiadaviek,
- zariadenia pripojené cez brány pomocou protokolov modbas-TCP mali problémy, ktoré sa vyriešili inteligentným znížením ich frekvencie dotazovania.
A potom sme začali pozorovať, ako sa nám pred očami stavia nový systém, objavili sa v ňom už známe zariadenia, ale v inom rozhraní - pohodlné, rýchle, dostupné aj z telefónu.
Čo sa nakoniec stalo, vám prezradíme v tretej časti nášho článku.
Zdroj: hab.com