Co je BMS
Systém monitorování provozu inženýrských systémů v datových centrech 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 havarijní situace a tím pádem na délku bezproblémového provozu.
Systémy monitorování BMS (Building Monitoring System) nabízejí mnozí globální dodavatelé zařízení pro datová centra. Během naší existenci Linxdatacenter v Rusku jsme měli příležitost se seznámit s různými systémy a setkat se s diametrálně odlišnými přístupy dodavatelů k provozu těchto systémů.
Vyprávíme, jak jsme za poslední rok zcela obnovili náš systém BMS a proč.
Jádro problému
Vše začalo před 10 lety spuštěním datového centra Linxdatacenter v Petrohradě. Systém BMS, podle standardů průmyslu té doby, představoval fyzický server s nainstalovaným softwarem, k němuž byl přístup realizován prostřednictvím klientského programu (takzvaného „tlustého“ klienta).
V té době na trhu existovalo jen málo společností, které nabízely taková řešení. Jejich produkty byly standardem, jedinou odpovědí na existující poptávku. A je třeba uznat, že jak tehdy, tak dnes se lídři trhu obecně výborně vypořádávají se svým základním úkolem – dodávkou funkčních ř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ů. Zvolený systém v té době splňoval všechny požadavky na monitorování komplexního inženýrského objektu, jakým je datové centrum.
Jak však čas plynul, požadavky a očekávání uživatelů (to jest nás, operátorů datových center) od IT řešení se změnily. A velké dodavatele, jak ukázala analýza trhu nabízených řešení, na to nebyly připraveny.
Trh podnikových IT zažil vážný dopad oblasti B2C. Digitální řešení dnes musí poskytovat pohodlí pro koncového uživatele – to je cíl, který si kladou vývojáři. To je vidět na zdokonalování uživatelských rozhraní (UI) a kvality uživatelského zážitku (UX) mnoha podnikových aplikací.
Člověk si zvyká na pohodlí ve všem, co se týká digitálních nástrojů v každodenním životě, a klade stejné požadavky i na nástroje, které používá pro pracovní úkoly. Lidé očekávají od firemních aplikací stejnou přehlednost, intuitivnost, jednoduchost a transparentnost, jaké mají ve službách finančních institucí, při objednávání taxi nebo online nakupování. IT specialisté, kteří implementují řešení v korporátní sféře, také touží po všech moderních „vychytávkách“: snadném nasazení a škálování, odolnosti proti poruchám a neomezených možnostech přizpůsobení.
Velké mezinárodní dodavatele často tyto trendy přehlížejí. Spoléhat se na svůj dlouholetý autoritu v oboru, korporace v práci se zákazníky bývají často kategorické a nepružné. Iluze vlastní nenahraditelnosti jim brání vidět, jak doslova před jejich očima vznikají mladé technologické firmy, které nabízejí alternativní řešení šitá na míru konkrétnímu zákazníkovi, a to bez přeplacení za značku.
Nevýhody starého systému BMS
Největší nevýhodou stávajícího zastaralého řešení BMS pro nás byla jeho pomalá reakce. Vyšetřování několika událostí, které byly spojeny s nedostatečně rychlou reakcí personálu, nám pomohlo pochopit, že některé události se v systému BMS objevovaly s velkým zpožděním. Systém přitom nebyl přetížený ani nefunkční, prostě verze jeho komponentů (například JAVA) byly zastaralé a nedokázaly správně fungovat s novými verzemi operačních systémů bez aktualizací. Tyto aktualizace bylo možné provést pouze spolu se systémem BMS, přičemž dodavatel nezajišťoval automatickou návaznost verzí, což znamenalo, že by pro nás tento proces byl prakticky stejně časově náročný jako přechod na nový systém, a nové řešení by si uchovalo část nedostatků starého.
Přidáme sem ještě několik nepříjemných „drobností“:
- Poplatek za připojení nových zařízení na principu „jedna IP adresa – jedna placená licence“;
- Nemožnost aktualizovat software bez zakoupení podpůrného balíčku (čímž se míní aktualizace 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;
- "Zálohování" instalací druhého železného serveru s duplicitním balíkem licencí. Synchronizace databází mezi hlavním a záložním serverem není, což znamená ruční přenos databáze a dlouhou dobu přechodu na záložní server;
- "Tlustý" klient uživatele, který není dostupný externě, bez rozšíření pro mobilní zařízení a možnosti vzdáleného přístupu;
- Omezené webové rozhraní bez grafických karet a zvukových oznámení, dostupné externě, ale prakticky nepoužívané zaměstnanci kvůli nedostatečnosti informativnosti;
- Nedostatek animace v rozhraní – veškerá grafika je pouze z pozadí a statických ikon. Výsledkem je celkově nízká úroveň přehlednosti;
Vypadalo to zhruba takto:
- Omezení při vytváření virtuálních senzorů – dostupná je pouze funkce sčítání, zatímco modely reálných senzorů vyžadují možnost provádění souboru matematických operací pro správné výpočty, které odráží skutečnosti práce;
- Nemožnost získat data v reálném čase nebo z archivu pro jakékoli účely (například pro zobrazení v klientském portálu);
- Úplný nedostatek flexibility a možnosti něco změnit v BMS podle existujících procesů datového centra.
Požadavky na nový systém BMS
S ohledem na výše uvedené, naše hlavní požadavky jsou následující:
- Dva nezávislé vzájemně zálohované stroje s automatickou synchronizací, které pracují na dvou různých cloudových platformách v různých datových centrech (v našem případě datová centra Linxdatacenter v Petrohradě a Moskvě);
- Bezplatné přidání nových zařízení;
- Bezplatná aktualizace softwaru a jeho komponent (s výjimkou rozšíření funkcionality);
- Otevřený zdrojový kód, který nám umožňuje samostatně udržovat systém v případě problémů na straně vývojáře;
- Možnost získávat a používat data z BMS, například na webu nebo v klientském portálu;
- Přístup přes WEB prohlížeč bez "tlustého" klienta;
- Používání doménových uživatelských účtů zaměstnanců pro přístup do BMS;
- Přítomnost animací a ještě mnoho dalších menších a větších přání, která se zhmotnila v podrobném technickém zadání.
Poslední kapka
V okamžiku, kdy jsme si uvědomili, že náš datový center přerostl svou BMS, nejlogičtější řešení, které nám přišlo na mysl, byla aktualizace stávajícího systému. 'Koně na horském přechodu se nemění', že?
Avšak velké korporace obvykle nenabízejí individuální úpravy svých desetiletí 'leštěných' řešení, prodávaných ve stovkách zemí. Zatímco mladé společnosti testují nápady nebo prototypy budoucích produktů na potenciálních zákaznících a vycházejí při vývoji produktu z uživatelských recenzí, korporace i nadále prodávají licence na kdysi opravdu skvělé, ale bohužel dnes zastaralé a nepružné produkty.
A na vlastní kůži jsme pocítili rozdíl v přístupu. V průběhu korespondence s výrobcem staré BMS bylo velmi rychle jasné, že navrhovaná aktualizace stávajícího systému se pro nás v podstatě promění v koupi nového systému s poloautomatickým převodem databáze, vysokými náklady a háčky při převodu, které nedokázal předpovědět ani samotný výrobce. Samozřejmě, že v tomto případě vzrostly náklady na technickou podporu aktualizovaného řešení a zůstala nutnost nakupovat licence při expanze.
A nejhorší bylo, že nový systém nemohl zcela splnit naše požadavky na zálohování. Aktualizovaný systém BMS mohl být realizován, jak jsme chtěli, na cloudové platformě, což by nám umožnilo vzdát se 'železa', ale možnost zálohování nebyla v ceně. Pro zálohování dat bychom museli koupit druhou virtuální server BMS a další sadu licencí. Při ceně jedné licence kolem 76 $ a počtu IP adress 1000 kusů činí 76 000 $ dodatečných výdajů pouze na licence pro záložní stroj.
"Třešničkou" v nové verzi BMS se stala potřeba nákupu dalších licencí "pro všechna zařízení" – dokonce pro hlavní server. Je třeba vysvětlit, že existují zařízení připojená k BMS přes brány. Brána má jednu IP adresu, ale ovládá několik zařízení (průměrně 10). Ve staré BMS byla na to potřebná jedna licence za IP adresu brány, statistika vypadala přibližně takto: "IP adresy / licence 1000, zařízení 1200". Aktualizovaná BMS fungovala na jiném principu a statistika by vypadala takto: "IP adresy 1000, zařízení / licence 1200". To znamená, že dodavatel ve nové verzi změnil princip přidělování licencí a my jsme museli zakoupit přibližně dalších 200 licencí.
Rozpočet na "aktualizaci" se nakonec skládal ze čtyř bodů:
- náklady na cloudovou verzi a služby její migrace;
- další licence k existujícímu balíčku pro zařízení připojená přes brány;
- náklady na záložní cloudovou verzi;
- sada licencí pro záložní stroj.
Celková cena projektu činila více než 100 000 $? A to ještě nepočítáme potřebu nákupu licencí pro nová zařízení v budoucnu.
Nakonec jsme zjistili, že pro nás bude snadnější – a možná i levnější – objednat systém, který byl vytvořen od nuly a který zohledňuje všechny naše požadavky a předpokládá možnost modernizace v budoucnu. Ale bylo třeba najít zájemce o vývoj takového složitého systému, porovnat nabídky, vybrat a projít s finalistou cestu od TZ až po realizaci… O tom – čtěte ve druhé části materiálu již brzy.
Zdroj: habr.com
