Architektura platformy Sensaka dla operacji centrum danych
Architektura platformy Sensaka
Czterowarstwowa architektura — od zbierania danych z urządzeń po inteligentną warstwę aplikacji — obejmująca każdy aspekt operacji centrum danych.
Warstwa aplikacji
Warstwa przetwarzania
Warstwa zasobów
Warstwa zbierania danych
Dlaczego warstwy są ułożone w tej kolejności
Powyższy diagram czyta się od góry do dołu, natomiast dane przepływają od dołu do góry. Wszystko zaczyna się w warstwie zbierania, która łączy się bezpośrednio z serwerami, urządzeniami sieciowymi, pamięcią masową, czujnikami środowiskowymi, maszynami wirtualnymi, bazami danych i aplikacjami — bezagentowo, za pomocą protokołów, które każde urządzenie już obsługuje. Warstwa zasobów zamienia ten surowy strumień w uporządkowane rekordy: alarmy, dane konfiguracyjne, metryki operacyjne, zużycie energii i dzienniki zdarzeń. W warstwie przetwarzania rekordy nabierają znaczenia: alarmy są korelowane i deduplikowane, zdarzenia IT są powiązywane z usługami biznesowymi, na które wpływają, a dane energetyczne i przestrzenne są analizowane razem. Dopiero wtedy warstwa aplikacji prezentuje wyniki: scentralizowane alarmy, monitoring topologii i biznesu, pulpity energetyczne, raporty i wizualizację 3D.
Kolejność ma znaczenie, ponieważ wiarygodność każdej warstwy zależy od warstwy pod nią. Pulpit zbudowany na nieskorelowanych alarmach generuje szum informacyjny; korelacja zbudowana na niepełnym zbieraniu danych generuje martwe pola. Dlatego warstwa zbierania danych Sensaka jest celowo szeroka — obejmuje opisany poniżej dostęp sprzętowy out-of-band — zanim dodana zostanie jakakolwiek inteligencja. Ta sama architektura stanowi podstawę wszystkich trzech poziomów produktów: DCOS do monitoringu infrastruktury, iDCOS do CMDB, ITSM i automatyzacji oraz SmartBSM do widoku usług biznesowych.
Sieć bezpośredniego dostępu sprzętowego
Bezpośrednie połączenie z portami zarządzającymi BMC (iLO, iDRAC, iBMC, IMM) za pośrednictwem dedykowanej sieci out-of-band, umożliwiające monitoring sprzętu w czasie rzeczywistym niezależnie od systemu operacyjnego.
Konfiguracja sieci
Zbieranie danych
In-band i out-of-band obok siebie
Warstwa zbierania danych celowo wykorzystuje obie ścieżki. Odpowiadają one na różne pytania, a razem domykają lukę, którą każda z nich osobno pozostawiłaby otwartą.
| Wymiar | In-band | Out-of-band |
|---|---|---|
| Skąd pochodzą dane | System operacyjny, odpytywany zdalnie | Kontroler zarządzający BMC, poniżej systemu operacyjnego |
| Działa, gdy system operacyjny nie działa | Nie | Tak — stan sprzętu i sterowanie zasilaniem pozostają dostępne |
| Co widzi najlepiej | Procesy, usługi, aplikacje, wykorzystanie zasobów | Stan komponentów, temperatury, pobór mocy, firmware |
| Typowe protokoły | SNMP, SSH/CLI, API, JDBC | Redfish, IPMI, iDRAC, iLO, XCC, iBMC |
| Rola w platformie | Monitoring serwerów, sieci, pamięci masowej i aplikacji | Monitoring sprzętu i zarządzanie zdalne |
Gdzie stosowana jest ta architektura
Każda rodzina rozwiązań to ta sama czterowarstwowa platforma skierowana na inny obszar centrum danych. Współdzielą one zbieranie danych, dane i alarmy — wdrożenie jednej nie odcina od pozostałych.
Dla infrastruktury AI
Ta sama platforma rozszerza się na klastry GPU, gdzie gęstość mocy, chłodzenie i wykorzystanie zachowują się inaczej niż w przypadku standardowej mocy obliczeniowej.
Do czego zespoły wykorzystują to rozwiązanie
Lokalizacje bezobsługowe i zdalne
Dostęp out-of-band zapewnia widoczność i możliwość sterowania sprzętem w lokalizacjach bezobsługowych, nawet gdy system operacyjny lub sieć in-band są niedostępne.
Konsolidacja narzędzi
Zastąpienie osobnych narzędzi monitoringu poszczególnych producentów dla serwerów, sieci, pamięci masowej i obiektów jedną platformą i jednym strumieniem alarmów.
Standaryzacja wielu lokalizacji
Wdrożenie tego samego modelu monitoringu we wszystkich centrach danych i lokalizacjach kolokacyjnych, dzięki czemu każda lokalizacja raportuje stan, zasoby i energię w ten sam sposób.
Programy energetyczne i PUE
Śledzenie zasilania i chłodzenia w podziale na szafy rack razem z obciążeniem IT, aby znaleźć niewykorzystaną pojemność i mierzyć efekty działań na rzecz efektywności w czasie.
Rozbudowa klastrów AI
Rozszerzenie tej samej architektury na węzły GPU i obiegi chłodzenia cieczą w miarę rozwoju klastrów oraz pomiar wykorzystania akceleratorów.
Operacje z uwzględnieniem kontekstu biznesowego
Odwzorowanie infrastruktury na obsługiwane przez nią usługi za pomocą SmartBSM, dzięki czemu każdy alarm trafia wraz z informacją o wpływie na biznes.
Najczęstsze pytania dotyczące platformy
Dlaczego platforma jest podzielona na cztery warstwy?
Ponieważ jakość każdej warstwy zależy od warstwy znajdującej się pod nią. Warstwa zbierania gromadzi surowe dane z urządzeń; warstwa zasobów normalizuje je do rekordów alarmowych, konfiguracyjnych, operacyjnych i energetycznych; warstwa przetwarzania koreluje te rekordy między sobą i z kontekstem biznesowym; a warstwa aplikacji przekształca wynik w monitoring, raportowanie i wizualizację. Luka w zbieraniu danych jest dziedziczona przez wszystkie warstwy powyżej — dlatego Sensaka w pierwszej kolejności inwestuje w szerokie, bezagentowe, wieloprotokołowe zbieranie danych.
Czy Sensaka wymaga agentów na monitorowanych urządzeniach?
Nie. Zbieranie danych jest bezagentowe — SNMP, SSH/CLI, API i JDBC gromadzą dane in-band, natomiast Redfish, IPMI, iDRAC, iLO, XCC i iBMC dostarczają danych sprzętowych out-of-band. Opcja agenta istnieje na wypadek, gdy zdalne odpytywanie nie jest możliwe, ale platforma nie jest od niej zależna.
Jaka jest różnica między DCOS, iDCOS i SmartBSM?
DCOS to warstwa infrastruktury — monitoring sprzętu, serwerów, sieci, pamięci masowej, zasilania i chłodzenia. iDCOS dodaje na bazie tych danych CMDB, ITSM i automatyzację. SmartBSM to warstwa usług biznesowych, która odwzorowuje infrastrukturę na obsługiwane przez nią usługi, dzięki czemu wpływ jest wyrażany w kategoriach biznesowych. Wszystkie trzy współdzielą tę samą architekturę, więc można je wdrażać osobno lub razem.
Czy jedno wdrożenie może monitorować sprzęt wielu producentów?
Tak. Redfish i IPMI to otwarte standardy, a Sensaka obsługuje również implementacje poszczególnych producentów — iDRAC, iLO, XCC, iBMC — dzięki czemu mieszana flota serwerów jest objęta jednym wdrożeniem. To samo podejście wielu producentów dotyczy urządzeń sieciowych i pamięci masowej.
Od którego rozwiązania warto zacząć?
Warto zacząć od obszaru, który sprawia najwięcej problemów. Jeśli awarie sprzętu wciąż zaskakują Państwa zespół, warto zacząć od monitoringu sprzętu; jeśli nie wiadomo, co znajduje się w której szafie rack, warto zacząć od zarządzania zasobami; jeśli ograniczeniem jest zasilanie, warto zacząć od zarządzania energią. Wszystkie rozwiązania współdzielą jedną platformę, więc każdy kolejny element opiera się na danych zebranych już przez poprzedni.