Monitoring w centrum danych: jak wymienialiśmy stary system BMS na nowy. Część 3

Kontynuujemy naszą opowieść o tym, jak zmienialiśmy system BMS w naszych centrach danych (część 1, Part 2). Nie tylko wymieniliśmy rozwiązanie jednego dostawcy na innego, ale zaprojektowaliśmy system od podstaw zgodnie z naszymi wymaganiami. Na zakończenie naszej historii dzielimy się wynikami wykonanej pracy i interesującymi rozwiązaniami, które mogą być dla Ciebie przydatne.

Nowy interfejs

Tutaj, jak to się mówi, lepiej raz zobaczyć.

Ramy.

Omówimy różnice.

• Po pierwsze, to piękne wygodne. Zwróć uwagę, jak łatwo stało się śledzić obciążenia na modułach („Banks” lub po prostu „Banki”) PDU oraz sumę równoległych obciążeń parzystych modułów. W nowym modelu stojaka z nowym systemem BMS od razu widzimy, że dolne parzyste moduły PDU są przeciążone (całkowity prąd przekracza dopuszczalne 16 A – „niebieskie” powiadomienie), a górne są niedoładowane. W przypadku wyłączenia jednego z wejść całe obciążenie przejdzie na drugie, a pozostający pod napięciem dolny moduł wyłączy się z powodu przeciążenia. Aby temu zapobiec, zespół wsparcia technicznego centrum danych wcześniej ostrzeże klienta i wyśle rekomendację, jak rozłożyć obciążenie.
• Proste dodawanie sprzętu. W nowym systemie BMS wirtualne czujniki sumy prądów modułów i mocy stojaka zostały już dodane do szablonów standardowych stojaków i są tworzone automatycznie po dodaniu do stojaka PDU. W starym systemie BMS trzeba było je tworzyć ręcznie, a następnie przenosić na mapę, co zwiększało ryzyko błędu z powodu „czynnika ludzkiego”.
• Nieograniczona przestrzeń dla kreatywności. Teraz nie mamy ograniczeń przy tworzeniu wirtualnych czujników. Można budować absolutnie dowolne modele matematyczne dowolnych zmiennych. Oznacza to, że mamy możliwość tworzenia skomplikowanych wirtualnych czujników (wcześniej można było tylko sumować wartości) i lepszego analizowania statystyk oraz trendów działania systemów inżynieryjnych. Zwiększa to jakość podejmowanych decyzji dotyczących konfiguracji systemów, wymiany sprzętu i zarządzania zasobami. 
• Zrozumiały interfejs. W nowym interfejsie nie ma nagromadzenia ikon, wentylatory wirują, przełączniki „klikają”. I najbardziej wygodne jest to, że możliwe jest wskazanie stanu PDU Linii A/B wewnątrz stojaków. Próbowaliśmy zrobić coś podobnego w starym systemie BMS, ale liczba zlewających się ikon na centymetr kwadratowy mapy zmusiła nas do rezygnacji z tego pomysłu.

Teraz miło się patrzy:

Serwery.

Fragment rozdzielnicy.

Panel sterowania wentylacją.

A nowy BMS można ozdobić na Nowy Rok 🙂

One page – wzajemne zrozumienie z pół słowa i bez TZ

Bardzo długo chcieliśmy zrealizować jeszcze jedną „funkcję” w BMS: złożyć na jednej stronie główne parametry centrum danych, aby rzut oka na ekran wystarczył do oceny stanu podstawowych systemów. Niemniej jednak nie do końca rozumieliśmy, jak to powinno wyglądać.

Jeszcze przed rozpoczęciem prac nad nowym BMS odwiedziliśmy z wycieczkami kilkanaście centrów danych w Holandii. Jednym z celów było zobaczenie przykładów realizacji takiej strony.

I w żadnym centrum danych nam jej nie pokazano – gdzieś jej nie było, gdzie indziej „właśnie była w opracowaniu”, a gdzie indziej była to „wielka tajemnica handlowa”. Dlatego w naszym TZ na stworzenie nowego BMS dokładny opis tej dla nas bardzo ważnej strony był nieobecny.

Ostatecznie wymyśliliśmy ją dosłownie „w biegu”. W tym momencie musiałem zdalnie konsultować kolegów w centrum danych. Przeglądanie stron BMS w telefonie w poszukiwaniu rozproszonych danych było bardzo niewygodne, a w zasadzie na serwetce powstała pierwsza wersja. One page. Została zrealizowana przez programistów na podstawie zdjęcia. 

Podążając za przykładem ostrożnych holenderskich kolegów, nie będziemy demonstrować końcowej wersji naszej strony głównej, tym bardziej że każde centrum danych jest unikalne i nie ma sensu kopiować. Ale opiszemy dwa główne zasady jej tworzenia:

1. To tabela, zaprojektowana pod format pionowo umiejscowionego ekranu smartfona (lub monitora, ale z zachowaniem pionowego układu), wyświetlająca wszystkie ważne informacje na jednym ekranie. Nad tabelą zamieszczana jest „nakładka” aktywnych incydentów, dlatego umieszczanie ich razem okazało się najwygodniejsze w formacie pionowym. 
2. Układ komórek w tabeli powtarza architekturę centrum danych (fizyczną lub logiczną). Zrezygnowaliśmy z układu systemów w porządku alfabetycznym, co na pierwszy rzut oka wydaje się oczywiste. Kolejność odzwierciedla wizualne skojarzenia personelu centrum danych – jak gdyby fizycznie monitorowali wszystkie pomieszczenia i systemy. Ułatwia to wyszukiwanie informacji.

Zasadniczo wszystkie kluczowe cechy centrum danych są teraz zgrupowane i przedstawione na jednym ekranie smartfona lub monitora odpowiedzialnego inżyniera i menedżera, przy czym zrealizowano powiązanie z fizyczną i logiczną topografią centrum danych. 

Oto zdjęcie pierwszego szkicu, chociaż oczywiście ta wersja została później przemyślana i dopracowana.

Potwierdzanie i podsumowanie incydentów

Opowiemy o jeszcze jednym nowym pojęciu, które pojawiło się w wyniku projektu aktualizacji systemu monitorowania.

Potwierdzanie to dość rzadko spotykany termin, który zaproponował do użycia twórca nowej BMS. Oznacza to potwierdzenie, że operator zauważył incydent, potwierdził go i wziął na siebie obowiązek jego usunięcia.  

Słowo przyjęło się, więc teraz "potwierdzamy" incydenty.

Algorytm zawarty w podstawowej wersji nowej BMS nas nie zadowolił. W praktyce były to komentarze do rejestru zdarzeń, co oznaczało, że usunięte incydenty nie znikały z rejestru, a przyjęte ("potwierdzone") nie były odseparowywane od nowych.

W efekcie opracowano okno zatytułowane „podsumowanie”, w którym:

1. Wyświetlane są tylko aktywne incydenty i urządzenia w trybie serwisowym (bez komercyjnych „niebieskich” powiadomień).
2. Jasno dzielą się NOWE i PRZYJĘTE incydenty.
3. Wskazano, kto przyjął incydent.

Algorytm pracy dyżurnych w nowej BMS jest następujący:

1. Nowe incydenty trafiają do podsumowania i czekają na potwierdzenie. Nie mogą długo pozostawać w tej sekcji, odpowiedzialny za sprzęt dyżurny musi od razu przyjąć incydent na siebie.
2. Pracownik przyjmuje incydent na siebie, klikając znaczek po prawej stronie. Ponieważ wszyscy pracownicy mają unikalne konta – automatycznie wyświetla się, kto przyjął incydent. W razie potrzeby można pozostawić komentarz.
3. Incydent przenosi się do sekcji „Potwierdzone”, pozostali dyżurni i kierownik rozumieją, że incydentem zajmuje się odpowiedzialny pracownik.

Przykład okna podsumowania z nową i już potwierdzoną wiadomością.

Łącząc okno podsumowania z tabelą One page, uzyskaliśmy kompleksowy główny ekran systemu BMS, na którym można od razu zobaczyć: 

• stan podstawowych systemów centrum danych;
• obecność nowych, nieprzetworzonych incydentów;
• obecność przyjętych incydentów oraz dane o tym, kto konkretnie je eliminuje.

Dostęp przez przeglądarkę i powiadomienia push na telefonie

Interfejs webowy, dostępny z dowolnego urządzenia z dowolnego miejsca na świecie, to wyraźny kontrast w porównaniu do „grubej” aplikacji, całkowicie zamkniętej dla użytkowników z zewnątrz. 

Stare podejście wiązało się z całym zestawem niedogodności, od problemów z organizacją zdalnej pracy pracowników działu monitorowania po konieczność instalowania „grubych” aplikacji z dystrybucji na stanowiskach pracowników w centrum danych.

Teraz każda strona w BMS ma unikalny adres, co umożliwia dzielenie się nie tylko bezpośrednim adresem strony lub urządzenia, ale także linkami do unikalnych wykresów/raportów. 

Dostęp do systemu odbywa się teraz za pośrednictwem uwierzytelniania LDAP przez Active Directory, co zwiększa poziom jego zabezpieczeń. 

Mobilność dzisiaj to kluczowy czynnik w efektywnej pracy dyżurnych inżynierów. Oprócz nadzorowania monitoringu w pomieszczeniu dyżurnym, inżynierowie przeprowadzają obchody, wykonują bieżące zadania poza „dyżurką” i, dzięki zoptymalizowanemu pod kątem mobilnym głównemu ekranowi BMS, nie tracą kontroli nad tym, co dzieje się w maszynowniach ani na chwilę. 

Jakość kontroli wzrasta również dzięki funkcjonalności czatów roboczych. Przyspieszają one procesy robocze, pozwalając „przypiąć” konwersację dyżurnych inżynierów do BMS. My na przykład korzystamy z aplikacji Teams, która umożliwia prowadzenie wewnętrznej korespondencji i odbieranie na telefon wszystkich wiadomości z BMS w postaci powiadomień push, co uwalnia dyżurnego od konieczności ciągłego patrzenia w ekran telefonu.

 Powiadomienie push na ekranie smartfona.

Tak wyglądają powiadomienia w aplikacji Teams.

Przy tym powiadomienia push są skonfigurowane tylko na wiadomości o pojawieniu się incydentów, co minimalizuje czynnik rozpraszający, personel wie: jeśli na ekranie smartfona pojawiło się powiadomienie push Teams, to należy wejść na stronę BMS i przyjąć incydent. Wiadomości o usunięciu incydentów są już śledzone na stronie BMS.

Na zdjęciu interfejs BMS na smartfonie.

Podsumowując

Przy kosztach aktualizacji BMS u naszego starego dostawcy, odpowiednich do opracowania nowego systemu od podstaw (około 100 000 USD), różnica w funkcjonalności produktów okazała się ogromna. Otrzymaliśmy elastyczny system, zoptymalizowany pod kątem naszych zadań biznesowych i procesów. Udało nam się również znacznie zaoszczędzić na bieżących kosztach wsparcia i aktualizacji systemu. 

Jednak oczywiście pojawiły się również trudności. 

• Po pierwsze, niedoszacowaliśmy zakresu zmian, które należało wprowadzić w podstawowej wersji nowego BMS, i nie zmieściliśmy się w wcześniej umówionych terminach. Dla nas nie było to krytycznym problemem, ponieważ do ostatniego momentu korzystaliśmy ze starego systemu, a proces był twórczy, skomplikowany i dlatego czasami przebiegał wolniej, niż oczekiwano. Ponadto zawsze widzieliśmy, że nasz deweloper dokłada maksymalnych starań, aby osiągnąć najlepszy rezultat. W rzeczywistości historia okazała się bardzo długa, a nasi kluczowi specjaliści spędzili na tym znacznie więcej wysiłku i czasu, niż planowali. 
• Po drugie, potrzebowaliśmy kilku etapów testów, aby dopracować algorytm rezerwacji wirtualnych maszyn i kanałów komunikacyjnych. Początkowo występowały awarie zarówno po stronie systemu BMS, jak i w ustawieniach wirtualnych maszyn i sieci. Ta diagnoza również zajęła czas. Na szczęście wykonawca otrzymał platformę testową w postaci usługi chmurowej, na której początkowo testowano wszystkie ustawienia i nowości.
• Po trzecie, końcowy system okazał się bardziej skomplikowany w edytowaniu przez użytkownika końcowego. Jeśli wcześniej mapa była podkładem (plik graficzny) oraz ikonami, których zmiana lub przemieszczenie nie sprawiało trudności, to teraz jest to złożony interfejs graficzny z animacjami, wymagający pewnych umiejętności do edycji.

Rewolucyjna aktualizacja naszego systemu BMS już dziś można uznać za najważniejszy projekt ubiegłego roku, który poważnie wpłynie na jakość operacyjnego zarządzania naszymi platformami w przyszłości. 

Stary serwer żelazny oczywiście nie został wyrzucony, a raczej "odchudzony": oczyściliśmy go z tysięcy "komercyjnych" wirtualnych czujników i PDU, pozostawiając w nim tylko kilka dziesiątek najważniejszych urządzeń, takich jak DGU, UPS, klimatyzatory, pompy, czujniki wycieków i temperatury. W takim trybie przywrócono mu dawną prędkość, a może on być „rezerwą rezerwy”. Nawiasem mówiąc, po usunięciu PDU ze starej BMS uwolniliśmy około 1000 teraz już niepotrzebnych licencji, czy przypadkiem nie wiecie, co z nimi zrobić?

Źródło: habr.com