Kio estas BMS
La monitora sistemo por funkciado de inĝenieraj sistemoj en datumcentro estas ŝlosila elemento de la infrastrukturo, rekte influanta tian gravan indikilon por datumcentro kiel la rapideco de persona respondo al krizaj situacioj kaj, sekve, la daŭro de seninterrompa operacio.
BMS (Building Monitoring System) monitoradsistemoj estas ofertitaj fare de multaj tutmondaj vendistoj de ekipaĵo por datencentroj. Dum la laboro de Linxdatacenter en Rusio, ni havis la ŝancon konatiĝi kun malsamaj sistemoj kaj renkonti diametre kontraŭajn alirojn de vendistoj al la funkciado de ĉi tiuj sistemoj.
Ni rakontas al vi kiel ni komplete ĝisdatigis nian BMS-sistemon dum la pasinta jaro kaj kial.
La radiko de la problemo
Ĉio komenciĝis antaŭ 10 jaroj kun la lanĉo de la datumcentro Linxdatacenter en Sankt-Peterburgo. La BMS-sistemo, laŭ industriaj normoj de tiuj jaroj, estis fizika servilo kun instalita programaro, alirita per klientprogramo (la tielnomita "dika" kliento).
Ekzistis malmultaj firmaoj proponantaj tiajn solvojn sur la merkato tiutempe. Iliaj produktoj estis la normo, la sola respondo al ekzistanta bezono. Kaj ni devas doni al ili sian ŝuldon: kaj tiam kaj hodiaŭ, merkatgvidantoj ĝenerale traktas sian bazan taskon - liveri funkciajn solvojn por funkciigado de datumcentroj.
La logika elekto por ni estis la BMS-solvo de unu el la plej grandaj fabrikistoj de la mondo. La elektita sistemo en tiu tempo renkontis ĉiujn postulojn por monitorado de kompleksa inĝenieristikinstalaĵo, kiel ekzemple datumcentro.
Tamen, kun la tempo, la postuloj kaj atendoj de uzantoj (tio estas, ni, datumcentraj funkciigistoj) de IT-solvoj ŝanĝiĝis. Kaj grandaj vendistoj, kiel montras analizo de la merkato por la proponitaj solvoj, ne estis pretaj por ĉi tio.
La kompania IT-merkato spertis gravan influon de la B2C-sektoro. Ciferecaj solvoj hodiaŭ devas provizi komfortan sperton por la fina uzanto - ĉi tiu estas la celo, kiun programistoj starigis al si. Ĉi tio evidentiĝas en la plibonigoj en uzantinterfacoj (UI) kaj uzantsperto (UX) de multaj entreprenaj aplikoj.
Homo alkutimiĝas al la komforto de ĉio rilata al ciferecaj iloj en la ĉiutaga vivo, kaj faras la samajn postulojn al la iloj, kiujn li uzas por labortaskoj. Homoj atendas de entreprenaj aplikoj la saman videblecon, intuicion, simplecon kaj travideblecon, kiuj estas disponeblaj al ili en financaj servoj, taksiovoko aŭ interreta aĉetado. IT-specialistoj efektivigantaj solvojn en kompania medio ankaŭ strebas ricevi ĉiujn modernajn "bonaĵojn": simpla deplojo kaj skalo, mistoleremo kaj senlimaj personigaj eblecoj.
Grandaj internaciaj vendistoj ofte preteratentas ĉi tiujn tendencojn. Fidante je sia longdaŭra aŭtoritato en la industrio, korporacioj ofte rezultas kategoriaj kaj neflekseblaj kiam ili laboras kun klientoj. La iluzio de sia propra nemalhaveblo ne permesas ilin vidi kiel junaj teknologiaj kompanioj aperas laŭvorte sub siaj nazoj, proponante alternativajn solvojn adaptitajn al specifa kliento, kaj sen tropagi por la marko.
Malavantaĝoj de la malnova BMS-sistemo
La ĉefa malavantaĝo de la ekzistanta malnoviĝinta BMS-solvo por ni estis ĝia malrapida funkciado. Esplori plurajn eventojn, kie deĵoranta dungitaro ne sufiĉe rapide respondis, igis nin kompreni, ke foje estis grava prokrasto en eventoj montritaj en la BMS. Samtempe, la sistemo ne estis troŝarĝita aŭ misa, nur la versioj de ĝiaj komponantoj (ekzemple JAVA) estis malmodernaj kaj ne povis funkcii ĝuste kun novaj versioj de operaciumoj sen ĝisdatigoj. Eblis ĝisdatigi ilin nur kune kun la BMS-sistemo, kaj la vendisto ne disponigis aŭtomatan kontinuecon de versioj, tio estas, por ni la procezo estus preskaŭ same laborintensa kiel ŝanĝi al nova sistemo, kaj la nova solvo konservita. iuj el la mankoj de la malnova.
Ni aldonu kelkajn pli da malagrablaj "etaĵoj" ĉi tie:
- Pago por konekti novajn aparatojn laŭ la principo de "unu IP-adreso - unu pagita permesilo";
- Nekapablo ĝisdatigi programaron sen aĉeti subtenan pakaĵon (ĉi tio signifas ĝisdatigi senpagajn komponantojn kaj forigi erarojn en la programo BMS mem);
- Alta kosto de subteno;
- Loko sur "fera" servilo, kiu povas malsukcesi kaj havas limigitajn komputigajn rimedojn;
- "Redundo" instalante duan aparatan servilon kun duplikata permesila pako. Samtempe, ne ekzistas sinkronigado de datumbazoj inter la ĉefa kaj rezerva serviloj - kio signifas manan datumbazan translokigon kaj longan tempon de transiro al la sekurkopio;
- "Dika" uzantkliento, nealirebla de ekstere, sen etendo por poŝtelefona aparato kaj fora aliro opcio;
- Sennudigita retinterfaco sen grafikaj kartoj kaj sonaj sciigoj, alirebla de ekstere, sed praktike ne uzata de dungitoj pro sia manko de informoj;
- Manko de animacio en la interfaco - ĉiuj grafikaĵoj konsistas nur el "fono" bildo kaj senmovaj ikonoj. La rezulto estas entute malalta nivelo de videbleco;
Ĉio aspektis tiel:
- Limigo en kreado de virtualaj sensiloj estas ke nur la aldonfunkcio estas havebla, dum modeloj de realaj sensiloj postulas la kapablon elfari aron de matematikaj operacioj por ĝustaj kalkuloj kiuj reflektas la faktojn de operacio;
- Nekapablo akiri datumojn en reala tempo aŭ de la arkivo por ajna celo (ekzemple, por montri en la persona konto de la kliento);
- Kompleta manko de fleksebleco kaj kapablo ŝanĝi ion ajn en la BMS por konveni al ekzistantaj datumcentraj procezoj.
Postuloj por nova BMS-sistemo
Konsiderante la supre, niaj ĉefaj postuloj estis jenaj:
- Du sendependaj reciproke redundaj maŝinoj kun aŭtomata sinkronigo, funkciante sur du malsamaj nubaj platformoj en malsamaj datumcentroj (en nia kazo, Linxdatacenter St. Petersburg kaj Moskva datumcentroj);
- Senpaga aldono de novaj aparatoj;
- Liberaj programaj ĝisdatigoj kaj ĝiaj komponantoj (krom funkciaj plibonigoj);
- Malferma fontkodo, permesante al ni sendepende subteni la sistemon en kazo de problemoj flanke de la programisto;
- La kapablo ricevi kaj uzi datumojn de la BMS, ekzemple, en retejo aŭ en via persona konto;
- Aliro per TTT-retumilo sen dika kliento;
- Uzante domajnajn dungitajn kontojn por aliri BMS;
- Havebleco de animacio kaj multaj aliaj malgrandaj kaj ne tiom malgrandaj deziroj kiuj realiĝis en detala teknika specifo.
Lasta pajlo
En la momento, kiam ni rimarkis, ke la datumcentro superis sian BMS, la plej evidenta solvo ŝajnis al ni ĝisdatigi la ekzistantan sistemon. "Ili ne ŝanĝas ĉevalojn meze," ĉu ne?
Tamen, grandaj korporacioj, kiel regulo, ne ofertas kutimajn modifojn al siaj jardekaj "poluritaj" solvoj venditaj en dekoj da landoj. Dum junaj kompanioj testas ideon aŭ prototipon de estonta produkto ĉe eblaj konsumantoj kaj dependas de la sugestoj de uzantoj por disvolvi la produkton, korporacioj daŭre vendas licencojn por iam vere bonega produkto, sed, ve, hodiaŭ ĝi estas malaktuala kaj nefleksebla.
Kaj ni sentis la diferencon en alproksimiĝo al ni mem. Dum korespondado kun la fabrikanto de la malnova BMS, rapide evidentiĝis, ke la ĝisdatigo de la ekzistanta sistemo proponita de la vendisto efektive rezultigus la aĉeton de nova sistemo por ni kun duonaŭtomata datumbaza translokigo, alta kosto kaj malutiloj dum la translokigo, kiun eĉ la fabrikanto mem ne povis antaŭdiri. Kompreneble, en ĉi tiu kazo, la kosto de teknika subteno por la ĝisdatigita solvo pliiĝis, kaj la bezono aĉeti licencojn dum ekspansio restis.
Kaj la plej malagrabla afero estis, ke la nova sistemo ne povis plene kontentigi niajn rezervpostulojn. La ĝisdatigita BMS-sistemo povus esti efektivigita, kiel ni volis, sur nuba platformo, kio permesus al ni forlasi la aparataron, sed la redunda opcio ne estis inkluzivita en la prezo. Por sekurkopii la datumojn, ni devus aĉeti duan BMS virtualan servilon kaj plian aron de licencoj. Kun la kosto de unu permesilo estas proksimume $76 kaj la nombro da IP-adresoj estas 1000 ekzempleroj, tio aldonas ĝis $76 en kromaj elspezoj nur por permesiloj por la rezerva maŝino.
La "ĉerizo" en la nova versio de BMS estis la bezono aĉeti pliajn permesilojn "por ĉiuj aparatoj" - eĉ por la ĉefa servilo. Ĉi tie necesas klarigi, ke estas aparatoj konektitaj al la BMS per enirejoj. La enirejo havas unu IP-adreson, sed regas plurajn aparatojn (10 averaĝe). En la malnova BMS, ĉi tio postulis unu permesilon per IP-adreso por enirejo, la statistiko aspektis kiel ĉi tio: "1000 IP-adresoj/licencoj, 1200 aparatoj." La ĝisdatigita BMS funkciis laŭ malsama principo kaj la statistiko aspektus jene: "1000 IP-adresoj, 1200 aparatoj/licencoj." Tio estas, la vendisto en la nova versio ŝanĝis la principon de atribui licencojn, kaj ni devis aĉeti proksimume 200 pliajn permesilojn.
La "ĝisdatigo" buĝeto finfine konsistis el kvar poentoj:
- kosto de la nuba versio kaj migraj servoj al ĝi;
- kromaj permesiloj al la ekzistanta pako por aparatoj konektitaj per enirejoj;
- kosto de rezerva nuba versio;
- aro da permesiloj por la rezerva maŝino.
La totalkosto de la projekto estis pli ol $100! Kaj ĉi tio ne mencii la bezonon aĉeti licencojn por novaj aparatoj estonte.
Rezulte, ni komprenis, ke estus por ni pli facile – kaj eble eĉ pli malmultekosta – mendi sistemon kreitan de nulo, konsiderante ĉiujn niajn postulojn kaj antaŭzorgante la eblecon de modernigo estonte. Sed tiuj, kiuj volis evoluigi tian kompleksan sistemon, ankoraŭ devis esti trovitaj, komparitaj proponoj, elektitaj kaj kun la finalisto marŝis la vojon de teknikaj specifoj ĝis efektivigo... Legu pri tio en la dua parto de la materialo tre baldaŭ.
fonto: www.habr.com