Mi az a BMS
Az adatközponti mérnöki rendszerek működésének felügyeleti rendszere az infrastruktúra kulcseleme, amely közvetlenül befolyásolja az adatközpontok számára olyan fontos mutatót, mint a személyzet vészhelyzetekre való reagálásának sebessége, és ebből következően a zavartalan működés időtartama.
BMS (Building Monitoring System) felügyeleti rendszereket sok globális adatközponti berendezés szállító kínál. Az oroszországi Linxdatacenter munkája során lehetőségünk nyílt megismerkedni a különböző rendszerekkel, és találkozni egymással merőben ellentétes gyártói megközelítésekkel e rendszerek működését illetően.
Elmondjuk, hogyan frissítettük teljesen BMS rendszerünket az elmúlt évben, és miért.
A probléma gyökere
Az egész 10 évvel ezelőtt kezdődött a szentpétervári Linxdatacenter adatközpont elindításával. A BMS rendszer az akkori ipari szabványok szerint egy fizikai szerver volt telepített szoftverrel, amelyhez kliensprogramon (ún. „vastag” kliensen) keresztül lehetett hozzáférni.
Akkoriban kevés ilyen megoldást kínáló cég volt a piacon. Termékeik voltak a szabványok, az egyetlen válasz egy létező igényre. És meg kell adnunk nekik a méltóságot: a piacvezetők akkor és ma is általában megbirkóznak alapvető feladatukkal - funkcionális megoldások szállításával az adatközpontok üzemeltetéséhez.
A logikus választás számunkra a világ egyik legnagyobb gyártójának BMS megoldása volt. A kiválasztott rendszer akkoriban megfelelt a komplex mérnöki létesítmények, például az adatközpontok felügyeletéhez szükséges összes követelménynek.
Az idő múlásával azonban megváltoztak a felhasználók (vagyis mi, adatközpontok üzemeltetői) igényei és elvárásai az informatikai megoldásokkal szemben. A nagy gyártók pedig, amint azt a javasolt megoldások piacának elemzése mutatja, nem álltak készen erre.
A vállalati IT piac komoly befolyást tapasztalt a B2C szektor részéről. A digitális megoldásoknak ma kényelmes élményt kell nyújtaniuk a végfelhasználónak – ezt a célt tűzik ki maguk elé a fejlesztők. Ez nyilvánvaló számos vállalati alkalmazás felhasználói felületének (UI) és felhasználói élményének (UX) fejlesztésében.
Az ember megszokja a mindennapi életben a digitális eszközökkel kapcsolatos minden kényelmét, és ugyanazokat az igényeket támasztja az eszközökkel szemben, amelyeket a munkavégzés során használ. Az emberek ugyanazt a láthatóságot, intuitivitást, egyszerűséget és átláthatóságot várják el a vállalati alkalmazásoktól, mint a pénzügyi szolgáltatások, a taxihívások vagy az online vásárlás során. A megoldásokat vállalati környezetben megvalósító informatikusok is arra törekednek, hogy minden modern „jót” megkapjanak: egyszerű üzembe helyezés és méretezés, hibatűrés és korlátlan testreszabási lehetőség.
A nagy nemzetközi beszállítók gyakran figyelmen kívül hagyják ezeket a trendeket. Az iparágban fennálló, régóta fennálló tekintélyükre támaszkodva a vállalatok gyakran kategorikusnak és rugalmatlannak bizonyulnak az ügyfelekkel való együttműködés során. Saját nélkülözhetetlenségük illúziója nem engedi, hogy láthassák, hogyan jelennek meg a szó szoros értelmében az orruk alatt a fiatal technológiai cégek, amelyek egy adott vásárlóra szabott alternatív megoldásokat kínálnak, anélkül, hogy túlfizetnék a márkát.
A régi BMS rendszer hátrányai
A meglévő, elavult BMS megoldás fő hátránya számunkra a lassú működése volt. Számos olyan esemény kivizsgálása, amelyekre az ügyeletes személyzet nem reagált elég gyorsan, megértettük, hogy néha jelentős késéssel jelennek meg az események a BMS-ben. Ugyanakkor a rendszer nem volt túlterhelt vagy hibás, csupán az összetevőinek verziói (például JAVA) elavultak, és nem tudtak megfelelően működni az operációs rendszerek új verzióival frissítés nélkül. Frissíteni csak a BMS rendszerrel együtt lehetett, és a gyártó nem biztosította a verziók automatikus folytonosságát, vagyis nálunk a folyamat majdnem olyan munkaigényes lenne, mint az új rendszerre váltás, és megmaradt az új megoldás a régi néhány hiányossága.
Tegyünk még néhány kellemetlen „apróságot”:
- Fizetés új eszközök csatlakoztatásáért az „egy IP-cím – egy fizetett licenc” elve alapján;
- Képtelenség a szoftverfrissítésre támogatási csomag vásárlása nélkül (ez az ingyenes komponensek frissítését és magában a BMS program hibáinak kiküszöbölését jelenti);
- A támogatás magas költsége;
- Hely egy „vas” szerveren, amely meghibásodhat és korlátozott számítási erőforrásokkal rendelkezik;
- „Redundancia” egy második hardverkiszolgáló telepítésével, duplikált licenccsomaggal. Ugyanakkor nem történik meg az adatbázisok szinkronizálása a fő és a tartalék szerver között - ami kézi adatbázis-átvitelt és hosszú átállást jelent a biztonsági mentésre;
- „Vastag” felhasználói kliens, kívülről elérhetetlen, mobileszköz-kiterjesztés és távoli hozzáférési lehetőség nélkül;
- Lecsupaszított webes felület grafikus kártyák és hangértesítések nélkül, kívülről elérhető, de információhiánya miatt gyakorlatilag nem használják a dolgozók;
- Animáció hiánya a felületen - minden grafika csak „háttér” képből és statikus ikonokból áll. Az eredmény általánosságban alacsony láthatósági szint;
Minden valahogy így nézett ki:
- A virtuális érzékelők létrehozásának korlátja, hogy csak az összeadás funkció érhető el, míg a valódi érzékelők modelljeihez matematikai műveletek végrehajtásának képessége szükséges a helyes számításokhoz, amelyek tükrözik a működés valóságát;
- Az adatok valós idejű vagy az archívumból történő bármilyen célú (például az ügyfél személyes fiókjában való megjelenítése) megszerzésének képtelensége;
- A rugalmasság és a BMS-ben a meglévő adatközponti folyamatoknak megfelelő változtatási lehetőség teljes hiánya.
Új BMS rendszer követelményei
A fentiek figyelembevételével főbb követelményeink a következők voltak:
- Két független, kölcsönösen redundáns gép automatikus szinkronizálással, két különböző felhőplatformon fut különböző adatközpontokban (esetünkben Linxdatacenter St. Petersburg és Moszkva adatközpontja);
- Új eszközök ingyenes hozzáadása;
- Ingyenes szoftverfrissítések és összetevői (a funkcionális fejlesztések kivételével);
- Nyílt forráskód, amely lehetővé teszi számunkra, hogy a fejlesztői oldalon felmerülő problémák esetén önállóan támogassuk a rendszert;
- A BMS-től származó adatok fogadásának és felhasználásának képessége, például egy webhelyen vagy az Ön személyes fiókjában;
- Hozzáférés WEB böngészőn keresztül vastag kliens nélkül;
- Domain alkalmazotti fiókok használata a BMS eléréséhez;
- Animáció elérhetősége és sok más apró és nem is olyan apró kívánság, amelyek egy részletes műszaki specifikációban valósultak meg.
Az utolsó csepp a pohárban
Abban a pillanatban, amikor rájöttünk, hogy az adatközpont kinőtte BMS-ét, a legkézenfekvőbb megoldásnak a meglévő rendszer frissítése tűnt számunkra. „Nem cserélnek lovat félúton”, igaz?
A nagyvállalatok azonban általában nem kínálnak egyedi módosításokat több tucat országban értékesített, több évtizedes „csiszolt” megoldásaikhoz. Míg a fiatal cégek egy jövőbeli termék ötletét vagy prototípusát tesztelik a potenciális fogyasztókon, és a felhasználói visszajelzésekre támaszkodnak a termék fejlesztése során, a vállalatok továbbra is adják el a licenceket egy egykor igazán menő termékhez, de sajnos ma már elavult és rugalmatlan.
És mi magunk is éreztük a különbséget a megközelítésben. A régi BMS gyártójával folytatott levelezés során gyorsan világossá vált, hogy a meglévő rendszer gyártó által javasolt frissítése valójában egy új rendszer vásárlását eredményezi számunkra félautomata adatbázis-átvitellel, magas költségekkel és buktatókkal az üzemeltetés során. transzfert, amit még maga a gyártó sem tudott megjósolni. Természetesen ebben az esetben a frissített megoldás műszaki támogatásának költsége megnőtt, a bővítés során megmaradt a licencvásárlás igénye.
A legkellemetlenebb pedig az volt, hogy az új rendszer nem tudta maradéktalanul kielégíteni a foglalási követelményeinket. A frissített BMS rendszer, ahogy szerettük volna, felhőplatformon is megvalósítható, ami lehetővé tenné a hardver elhagyását, de a redundancia opció nem volt benne az árban. Az adatok biztonsági mentéséhez egy második BMS virtuális szervert és egy további licenckészletet kellene vásárolnunk. Mivel egy licenc ára körülbelül 76 dollár, az IP-címek száma pedig 1000 egység, ez 76 000 dollár többletköltséget jelent, csak a tartalék gép licenceiért.
A „cseresznye” a BMS új verziójában az volt, hogy további licenceket kellett vásárolni „minden eszközhöz” – még a fő szerverhez is. Itt tisztázni kell, hogy vannak olyan eszközök, amelyek átjárókon keresztül csatlakoznak a BMS-hez. Az átjárónak egy IP-címe van, de több eszközt vezérel (átlagosan 10-et). A régi BMS-ben ehhez átjáró IP-címenként egy licenc kellett, a statisztika valahogy így nézett ki: "1000 IP-cím/licenc, 1200 eszköz." A frissített BMS más elven működött, és a statisztika így nézne ki: „1000 IP-cím, 1200 eszköz/licenc.” Azaz a gyártó az új verzióban megváltoztatta a licenckiosztás elvét, és hozzávetőleg 200 további licencet kellett vásárolnunk.
A „frissítési” költségvetés végül négy pontból állt:
- a felhőverzió és az arra való migrációs szolgáltatások költsége;
- további licencek a meglévő csomaghoz az átjárókon keresztül csatlakoztatott eszközökhöz;
- a biztonsági mentés felhőverziójának költsége;
- licenckészlet a tartalék géphez.
A projekt összköltsége több mint 100 000 dollár volt! És nem beszélve arról, hogy a jövőben új eszközökhöz licenceket kell vásárolni.
Ennek eredményeként rájöttünk, hogy minden igényünket figyelembe véve és a jövőbeni korszerűsítés lehetőségét is biztosítva nekünk egyszerűbb - és talán olcsóbb is - egy alapból megalkotott rendszert rendelni. De még meg kellett találni azokat, akik ilyen összetett rendszert akartak kidolgozni, össze kellett vetni a javaslatokat, kiválasztani és a döntőssel végigjárni az utat a műszaki specifikációtól a megvalósításig... Erről hamarosan olvashat az anyag második részében.
Forrás: will.com