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; korelacja zbudowana na niepełnym zbieraniu danych generuje martwe pola. Dlatego warstwa zbierania danych Sensaka jest celowo szeroka, obejmując opisany poniżej dostęp sprzętowy out-of-band, zanim zostanie na niej zbudowana jakakolwiek inteligencja. Ta sama architektura stanowi podstawę obu produktów. Sensaka for Data Centers obejmuje monitoring infrastruktury, CMDB, ITSM i automatyzację oraz widok usług biznesowych; Sensaka for AI Data Centers dodaje operacje GPU na tych samych modułach.
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ą modułu AIOps, 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.
Czym różni się Sensaka for Data Centers od Sensaka for AI Data Centers?
Sensaka for Data Centers ma trzy moduły. Monitoring sprzętu i obiektu to warstwa infrastruktury: monitoring sprzętu, serwerów, sieci, pamięci masowej, zasilania i chłodzenia. CMDB i ITSM dodaje na bazie tych danych zarządzanie konfiguracją, zarządzanie usługami i automatyzację. AIOps i zarządzanie usługami biznesowymi odwzorowuje infrastrukturę na obsługiwane przez nią usługi, dzięki czemu wpływ jest wyrażany w kategoriach biznesowych. Sensaka for AI Data Centers działa na tej samej architekturze i dodaje pule GPU, operacje na zadaniach, monitoring chłodzenia cieczą i pomiar godzin GPU. Moduły można 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.