Czym jest BMS
System monitorowania pracy systemów inżynieryjnych w centrum danych to kluczowy element infrastruktury, który bezpośrednio wpływa na tak ważny wskaźnik dla centrum danych, jak czas reakcji personelu na awarie, a co za tym idzie, na czas nieprzerwanej pracy.
Systemy monitorowania BMS (Building Monitoring System) oferuje wielu globalnych dostawców sprzętu dla centrów danych. W czasie naszej działalności w Linxdatacenter w Rosji mieliśmy okazję poznać różne systemy i zetknąć się z diametralnie odmiennymi podejściami dostawców do eksploatacji tych systemów.
Opowiadamy, jak całkowicie zaktualizowaliśmy nasz system BMS w ciągu ostatniego roku i dlaczego.
Korn problemu
Wszystko zaczęło się 10 lat temu od uruchomienia Centrum Danych Linxdatacenter w Petersburgu. System BMS, zgodnie z ówczesnymi standardami branżowymi, był fizycznym serwerem z zainstalowanym oprogramowaniem, do którego dostęp uzyskiwano za pośrednictwem programu-klienta (tzw. "gruby" klient).
Czasów, kiedy na rynku było niewiele firm oferujących takie rozwiązania. Ich produkty były standardem, jedyną odpowiedzią na istniejące zapotrzebowanie. Należy im oddać sprawiedliwość: zarówno wtedy, jak i dziś, liderzy rynku w dużej mierze wywiązują się ze swojej podstawowej roli – dostarczania funkcjonalnych rozwiązań do eksploatacji centrów danych.
Logicznym wyborem dla nas było rozwiązanie BMS od jednego z największych producentów na świecie. Wybrany system w tamtym czasie spełniał wszystkie wymagania dotyczące monitorowania złożonego obiektu inżynieryjnego, jakim jest centrum danych.
Jednak z upływem czasu wymagania i oczekiwania użytkowników (czyli nas, operatorów centrów danych) wobec rozwiązań IT uległy zmianie. A dużym dostawcom, jak pokazuje analiza rynku oferowanych rozwiązań, zabrakło do tego przygotowania.
Rynek IT w przedsiębiorstwach odczuł na sobie silny wpływ sfery B2C. Dzisiejsze rozwiązania cyfrowe muszą zapewniać wygodę pracy końcowego użytkownika – taki cel stawiają sobie deweloperzy. Widać to w doskonaleniu interfejsów użytkownika (UI) i jakości doświadczeń użytkowników (UX) wielu aplikacji korporacyjnych.
Człowiek przyzwyczaja się do komfortu we wszystkim, co dotyczą narzędzi cyfrowych w codziennym życiu, i oczekuje tych samych wymagań od narzędzi, które wykorzystuje w zadaniach zawodowych. Ludzie oczekują od aplikacji korporacyjnych takiej samej przejrzystości, intuicyjności, prostoty i klarowności, jakie są dostępne w usługach finansowych, zamawianiu taksówek czy zakupach online. Specjaliści IT wdrażający rozwiązania w środowisku korporacyjnym również dążą do uzyskania wszystkich nowoczesnych „fajerwerków”: łatwego wdrożenia i skalowania, odporności na awarie oraz nieograniczonych możliwości dostosowywania.
Duzi międzynarodowi dostawcy często ignorują te trendy. Opierając się na swoim wieloletnim autorytecie w branży, korporacje w pracy z klientami często okazują się kategoryczne i mało elastyczne. Iluzja własnej niezastąpioności nie pozwala im dostrzegać, jak dosłownie pod ich nosem powstają młode firmy technologiczne oferujące alternatywne rozwiązania, dopasowane do konkretnego klienta, przy tym bez przepłacania za markę.
Wady starego systemu BMS
Największą wadą posiadanego przestarzałego rozwiązania BMS dla nas była jego wolna praca. Badanie kilku zdarzeń związanych z niewystarczająco szybką reakcją personelu dyżurującego pomogło nam zrozumieć, że czasami zdarzenia były wyświetlane w systemie BMS z dużym opóźnieniem. Przy tym system nie był przeciążony ani uszkodzony, po prostu wersje jego komponentów (np. JAVA) były przestarzałe i nie mogły prawidłowo działać z nowymi wersjami systemów operacyjnych bez aktualizacji. Można je było zaktualizować tylko wraz z systemem BMS, przy czym dostawca nie zapewniał automatycznej ciągłości wersji, co oznaczało, że proces dla nas byłby praktycznie tak samo czasochłonny, jak przejście na nowy system, a nowe rozwiązanie zachowywało część wad starego.
Dodajmy jeszcze kilka nieprzyjemnych „szczegółów”:
- Opłata za podłączenie nowych urządzeń według zasady „jeden adres IP – jedna płatna licencja”;
- Brak możliwości aktualizacji oprogramowania bez zakupu pakietu wsparcia (mowa o aktualizacji darmowych komponentów i usuwaniu błędów w samym programie BMS);
- Wysokie koszty wsparcia;
- Lokalizacja na „żywym” serwerze, który może ulec awarii i posiada ograniczone zasoby obliczeniowe;
- „Rezerwacja” poprzez instalację drugiego serwera fizycznego, z duplikującym pakietem licencji. Przy tym synchronizacji baz między głównym a rezerwowym serwerem nie ma – co oznacza ręczne przenoszenie bazy i długi czas przejścia na zapasowy;
- „Gruby” klient użytkownika, niedostępny z zewnątrz, bez rozszerzenia na urządzenia mobilne i opcji zdalnego dostępu;
- Okrojony interfejs internetowy bez kart graficznych i powiadomień dźwiękowych, dostępny z zewnątrz, ale praktycznie nieużywany przez pracowników z powodu braku informacji;
- Brak animacji w interfejsie – cała grafika składa się tylko z obrazka-„podkładu” i statycznych ikon. Efekt – ogólnie niski poziom widoczności;
Wyglądało to mniej więcej tak:
- Ograniczenie w tworzeniu wirtualnych czujników – dostępna jest tylko funkcja sumowania, podczas gdy modele rzeczywistych czujników wymagają możliwości wykonywania kompleksu operacji matematycznych dla poprawnych obliczeń, odzwierciedlających realia pracy;
- Brak możliwości uzyskania danych w czasie rzeczywistym lub z archiwum do jakichkolwiek celów (na przykład, do wyświetlenia w panelu klienta);
- Całkowity brak elastyczności i możliwości wprowadzenia jakichkolwiek zmian w BMS w kontekście istniejących procesów Centrum Danych.
Wymagania dotyczące nowego systemu BMS
Uwzględniając powyższe, nasze główne wymagania były następujące:
- Dwie niezależne maszyny wzajemnie rezerwujące z automatyczną synchronizacją, działające na dwóch różnych platformach chmurowych w różnych Centrum Danych (w naszym przypadku Centrum Danych Linxdatacenter w Sankt Petersburgu i Moskwie);
- Darmowe dodawanie nowych urządzeń;
- Darmowa aktualizacja oprogramowania i jego komponentów (z wyjątkiem rozszerzeń funkcjonalności);
- Otwarty kod źródłowy, który pozwala nam samodzielnie utrzymywać system w przypadku problemów po stronie dewelopera;
- Możliwość uzyskania i wykorzystania danych z BMS, na przykład na stronie internetowej lub w panelu klienta;
- Dostęp przez przeglądarkę WEB bez „grubej” aplikacji;
- Użycie kont domenowych pracowników do dostępu do BMS;
- Obecność animacji oraz wiele innych drobnych i większych życzeń, które przekształciły się w szczegółowy dokument wymagań.
Ostatnia kropla
W momencie, gdy zrozumieliśmy, że nasze centrum danych przerosło swój system BMS, najoczywistszym rozwiązaniem wydawała się aktualizacja istniejącego systemu. "Nie zmienia się koni na przeprawie", prawda?
Niemniej jednak, duże korporacje zazwyczaj nie oferują dostosowywania swoich dziesięcioletnich, „polerowanych” rozwiązań, sprzedawanych w dziesiątkach krajów. Podczas gdy młode firmy testują pomysły lub prototypy przyszłych produktów na potencjalnych odbiorcach i opierają rozwój produktów na opiniach użytkowników, korporacje nadal sprzedają licencje na niegdyś naprawdę świetne, ale niestety dzisiaj przestarzałe i nieelastyczne produkty.
I sami odczuliśmy różnicę w podejściu. W trakcie korespondencji z producentem starego systemu BMS szybko stało się jasne, że proponowana przez dostawcę aktualizacja istniejącego systemu w praktyce będzie dla nas oznaczać zakup nowego systemu z półautomatycznym przeniesieniem bazy, wysokimi kosztami i pułapkami przy przenoszeniu, które nie mógł przewidzieć nawet sam producent. Oczywiście w takim przypadku rosły koszty wsparcia technicznego zaktualizowanego rozwiązania, a także pozostawała konieczność zakupu licencji przy rozszerzeniu.
Najbardziej nieprzyjemne było to, że nowy system nie mógł w pełni spełnić naszych wymagań dotyczących rezerwacji. Zaktualizowany system BMS mógł być zrealizowany, jak chcieliśmy, na platformie chmurowej, co pozwoliłoby nam zrezygnować z fizycznego sprzętu, ale opcja rezerwacji nie była wliczona w koszt. Aby rezerwować dane, musielibyśmy kupić drugi serwer wirtualny system BMS i dodatkowy zestaw licencji. Przy kosztach jednej licencji wynoszących około 76 dolarów i liczbie adresów IP wynoszącej 1000 jednostek, dodatkowe wydatki tylko na licencje dla maszyny rezerwowej wynoszą 76 000 dolarów.
Nową „wisienką” w wersji BMS stała się konieczność zakupu dodatkowych licencji „dla wszystkich urządzeń” – nawet dla głównego serwera. Należy wyjaśnić, że istnieją urządzenia podłączone do BMS przez bramy. Brama ma jeden adres IP, ale kontroluje kilka urządzeń (średnio 10). W starej wersji BMS wymagana była jedna licencja za adres IP bramy, statystyki wyglądały z grubsza tak: „adresów IP/licencji 1000, urządzeń 1200”. Zaktualizowana BMS działała na innym zasadzie i statystyki wyglądałyby tak „adresów IP 1000, urządzeń/licencji 1200”. To znaczy, że dostawca w nowej wersji zmienił zasady przydzielania licencji, a my musieliśmy kupić dodatkowo jeszcze około 200 licencji.
Budżet „aktualizacji” ostatecznie składał się z czterech punktów:
- koszt wersji chmurowej oraz usługi migracji do niej;
- dodatkowe licencje do istniejącego pakietu dla urządzeń podłączonych przez bramy;
- koszt zapasowej wersji chmurowej;
- zestaw licencji dla maszyny zapasowej.
Łączny koszt projektu wyniósł ponad 100 000 USD! I to nie wspominając o konieczności zakupu licencji dla nowych urządzeń w przyszłości.
Ostatecznie zdaliśmy sobie sprawę, że dla nas będzie łatwiej – a może i taniej – zamówić system, stworzony od podstaw, spełniający wszystkie nasze wymagania i przewidujący możliwość modernizacji w przyszłości. Ale najpierw trzeba było znaleźć chętnych do opracowania tak skomplikowanego systemu, porównać oferty, wybrać i przejść z finalistą drogę od wymagań do realizacji… O tym przeczytasz w drugiej części materiału wkrótce.
Źródło: habr.com
