Co je BMS
Monitorovací systém pro provoz inženýrských systémů v datovém centru je klíčovým prvkem infrastruktury, který přímo ovlivňuje tak důležitý ukazatel pro datové centrum, jako je rychlost reakce personálu na nouzové situace a následně i doba nepřetržitého provozu.
Monitorovací systémy BMS (Building Monitoring System) nabízí mnoho světových výrobců zařízení pro datová centra. Během práce Linxdatacenter v Rusku jsme měli možnost seznámit se s různými systémy a setkat se s diametrálně odlišnými přístupy prodejců k provozu těchto systémů.
Řekneme vám, jak jsme za poslední rok kompletně aktualizovali náš systém BMS a proč.
Kořen problému
Vše začalo před 10 lety spuštěním datového centra Linxdatacenter v St. Petersburgu. Systém BMS byl podle průmyslových standardů oněch let fyzickým serverem s nainstalovaným softwarem, ke kterému se přistupovalo prostřednictvím klientského programu (tzv. „tlustý“ klient).
V té době bylo na trhu málo společností nabízejících taková řešení. Jejich produkty byly standardem, jedinou odpovědí na existující potřebu. A musíme jim dát za pravdu: tehdy i dnes se lídři na trhu většinou vyrovnávají se svým základním úkolem – dodávat funkční řešení pro provoz datových center.
Logickou volbou pro nás bylo řešení BMS od jednoho z největších světových výrobců. Vybraný systém v té době splňoval všechny požadavky na monitorování složitého inženýrského zařízení, jakým je datové centrum.
Postupem času se však požadavky a očekávání uživatelů (tedy nás, provozovatelů datových center) od IT řešení změnily. A velcí dodavatelé, jak ukázala analýza trhu s navrhovanými řešeními, na to nebyli připraveni.
Firemní IT trh zažil vážný vliv B2C sektoru. Digitální řešení dnes musí poskytovat pohodlný zážitek pro koncového uživatele – to je cíl, který si vývojáři stanovili. To je patrné na vylepšeních uživatelského rozhraní (UI) a uživatelské zkušenosti (UX) mnoha podnikových aplikací.
Člověk si v běžném životě zvyká na pohodlí všeho, co souvisí s digitálními nástroji, a klade na nástroje stejné nároky, jaké používá k pracovním úkonům. Lidé očekávají od podnikových aplikací stejnou viditelnost, intuitivnost, jednoduchost a transparentnost, jaké mají k dispozici ve finančních službách, volání taxi nebo online nakupování. IT specialisté implementující řešení v podnikovém prostředí se také snaží získat všechny moderní „dobroty“: jednoduché nasazení a škálování, odolnost proti chybám a neomezené možnosti přizpůsobení.
Velcí mezinárodní prodejci tyto trendy často přehlížejí. Společnosti, které se spoléhají na svou dlouhodobou autoritu v tomto odvětví, se často ukazují jako kategorické a nepružné při práci se zákazníky. Iluze vlastní nepostradatelnosti jim neumožňuje vidět, jak se jim doslova pod nosem objevují mladé technologické firmy, které nabízejí alternativní řešení na míru konkrétnímu zákazníkovi a bez přeplácení značky.
Nevýhody starého systému BMS
Hlavní nevýhodou stávajícího zastaralého BMS řešení pro nás byl pomalý provoz. Vyšetřování několika událostí, kdy personál ve službě nereagoval dostatečně rychle, nás vedlo k pochopení, že někdy došlo k významnému zpoždění v zobrazování událostí v BMS. Systém přitom nebyl přetížený ani poruchový, pouze verze jeho komponent (například JAVA) byly zastaralé a nemohly správně fungovat s novými verzemi operačních systémů bez aktualizací. Aktualizovat je bylo možné pouze společně se systémem BMS a prodejce nezajistil automatickou návaznost verzí, to znamená, že pro nás by byl proces téměř stejně pracný jako přechod na nový systém a nové řešení zůstalo zachováno některé nedostatky toho starého.
Přidejme sem ještě pár nepříjemných „maličkostí“:
- Platba za připojení nových zařízení na principu „jedna IP adresa – jedna placená licence“;
- Nemožnost aktualizace softwaru bez zakoupení podpůrného balíčku (to znamená aktualizaci bezplatných komponent a odstranění chyb v samotném programu BMS);
- Vysoké náklady na podporu;
- Umístění na „železném“ serveru, který může selhat a má omezené výpočetní zdroje;
- „Redundance“ instalací druhého hardwarového serveru s duplicitním licenčním balíčkem. Zároveň nedochází k synchronizaci databází mezi hlavním a záložním serverem - což znamená ruční přenos databáze a dlouhý čas přechodu na zálohu;
- „Tlustý“ uživatelský klient, zvenčí nepřístupný, bez rozšíření pro mobilní zařízení a možnosti vzdáleného přístupu;
- Obnažené webové rozhraní bez grafických karet a zvukových upozornění, přístupné zvenčí, ale prakticky nevyužívané zaměstnanci pro nedostatek informací;
- Nedostatek animace v rozhraní - veškerá grafika se skládá pouze z obrázku „na pozadí“ a statických ikon. Výsledkem je celkově nízká úroveň viditelnosti;
Všechno vypadalo nějak takto:
- Omezení při vytváření virtuálních senzorů spočívá v tom, že je k dispozici pouze funkce sčítání, zatímco modely skutečných senzorů vyžadují schopnost provádět sadu matematických operací pro správné výpočty, které odrážejí realitu provozu;
- Neschopnost získat data v reálném čase nebo z archivu pro jakékoli účely (například pro zobrazení v osobním účtu klienta);
- Naprostý nedostatek flexibility a schopnosti změnit cokoliv v BMS tak, aby vyhovoval stávajícím procesům datového centra.
Požadavky na nový systém BMS
S ohledem na výše uvedené byly naše hlavní požadavky následující:
- Dva nezávislé vzájemně redundantní stroje s automatickou synchronizací, běžící na dvou různých cloudových platformách v různých datových centrech (v našem případě datová centra Linxdatacenter St. Petersburg a Moskva);
- Bezplatné přidávání nových zařízení;
- Bezplatné aktualizace softwaru a jeho součástí (kromě funkčních vylepšení);
- Otevřený zdrojový kód, který nám umožňuje nezávislou podporu systému v případě problémů na straně vývojáře;
- Schopnost přijímat a používat data z BMS, například na webových stránkách nebo ve vašem osobním účtu;
- Přístup přes WEBový prohlížeč bez tlustého klienta;
- Použití účtů zaměstnanců domény pro přístup k BMS;
- Dostupnost animace a mnoho dalších drobných i ne zrovna malých přání, která se zhmotnila do podrobné technické specifikace.
Poslední sláma
Ve chvíli, kdy jsme si uvědomili, že datové centrum přerostlo své BMS, se nám jako nejsrozumitelnější řešení zdálo aktualizovat stávající systém. "Nevymění koně uprostřed cesty," že?
Velké korporace však zpravidla nenabízejí vlastní úpravy svých desítky let starých „vyleštěných“ řešení prodávaných v desítkách zemí. Zatímco mladé společnosti testují nápad nebo prototyp budoucího produktu na potenciálních spotřebitelích a při vývoji produktu se spoléhají na zpětnou vazbu od uživatelů, korporace nadále prodávají licence na kdysi opravdu skvělý produkt, který je však, bohužel, dnes zastaralý a nepružný.
A sami jsme pocítili rozdíl v přístupu. Během korespondence s výrobcem starého BMS se rychle ukázalo, že aktualizace stávajícího systému navržená prodejcem by pro nás ve skutečnosti vyústila v nákup nového systému s poloautomatickým přenosem databáze, vysokými náklady a úskalími během transfer, který nedokázal předvídat ani sám výrobce. Samozřejmě v tomto případě vzrostly náklady na technickou podporu aktualizovaného řešení a nutnost nákupu licencí při expanzi zůstala.
A nejnepříjemnější bylo, že nový systém nedokázal plně uspokojit naše požadavky na rezervaci. Aktualizovaný systém BMS bylo možné implementovat, jak jsme chtěli, na cloudové platformě, což by nám umožnilo opustit hardware, ale možnost redundance nebyla zahrnuta v ceně. Pro zálohování dat bychom museli zakoupit druhý virtuální server BMS a další sadu licencí. S náklady na jednu licenci asi 76 USD a počtem IP adres 1000 76 jednotek to znamená dodatečné výdaje až na 000 XNUMX USD pouze za licence na zálohovací stroj.
„Třešničkou“ nové verze BMS byla nutnost dokoupit další licence „pro všechna zařízení“ – i pro hlavní server. Zde je potřeba upřesnit, že k BMS jsou připojena zařízení přes brány. Brána má jednu IP adresu, ale ovládá několik zařízení (v průměru 10). Ve starém BMS to vyžadovalo jednu licenci na IP adresu brány, statistika vypadala asi takto: „1000 IP adres/licence, 1200 zařízení“. Aktualizovaný BMS fungoval na jiném principu a statistika by vypadala takto: „1000 IP adres, 1200 zařízení/licence“. To znamená, že prodejce v nové verzi změnil princip přidělování licencí a museli jsme dokoupit přibližně 200 licencí.
„Aktualizační“ rozpočet se nakonec skládal ze čtyř bodů:
- náklady na cloudovou verzi a služby migrace na ni;
- dodatečné licence ke stávajícímu balíčku pro zařízení připojená přes brány;
- náklady na zálohovací cloudovou verzi;
- sadu licencí pro zálohovací stroj.
Celkové náklady projektu byly více než 100 000 $! A to nemluvě o nutnosti nákupu licencí na nová zařízení v budoucnu.
Díky tomu jsme si uvědomili, že pro nás bude jednodušší – a možná i levnější – objednat systém vytvořený od začátku, s ohledem na všechny naše požadavky a s možností modernizace v budoucnu. Ale ten, kdo chtěl takto komplexní systém vyvinout, se musel ještě najít, porovnat návrhy, vybrat a s finalistou projít cestu od technických specifikací k realizaci... O tom se již brzy dočtete ve druhé části materiálu.
Zdroj: www.habr.com