Sensaka-Plattformarchitektur für den Rechenzentrumsbetrieb
Sensaka-Plattformarchitektur
Eine vierstufige Architektur von der Geräteerfassung bis zur intelligenten Anwendung: Sie deckt jeden Aspekt des Rechenzentrumsbetriebs ab.
Anwendungsebene
Verarbeitungsebene
Ressourcenebene
Erfassungsebene
Warum die Ebenen so angeordnet sind
Das Diagramm oben liest sich von oben nach unten, doch die Daten fließen von unten nach oben. Alles beginnt an der Erfassungsebene, die sich direkt mit Servern, Netzwerkgeräten, Storage, Umgebungssensoren, virtuellen Maschinen, Datenbanken und Anwendungen verbindet – agentenlos, über die Protokolle, die jedes Gerät bereits spricht. Die Ressourcenebene macht aus diesem Rohdatenstrom organisierte Datensätze: Alarme, Konfigurationsdaten, Betriebskennzahlen, Stromverbrauch und Logs. Auf der Verarbeitungsebene werden aus Datensätzen Erkenntnisse: Alarme werden korreliert und dedupliziert, IT-Ereignisse werden den Business Services zugeordnet, die sie betreffen, und Energie- sowie Raumdaten werden gemeinsam analysiert. Erst dann präsentiert die Anwendungsebene die Ergebnisse: zentralisierte Alarme, Topologie- und Business-Monitoring, Energie-Dashboards, Reports und 3D-Visualisierung.
Die Reihenfolge ist wichtig, weil jede Ebene nur so vertrauenswürdig sein kann wie die darunterliegende. Ein Dashboard auf Basis unkorrelierter Alarme erzeugt Rauschen; Korrelation auf Basis unvollständiger Erfassung erzeugt blinde Flecken. Deshalb ist die Erfassungsebene von Sensaka bewusst breit angelegt – einschließlich des unten beschriebenen Out-of-Band-Hardwarezugriffs –, bevor überhaupt Intelligenz darübergelegt wird. Dieselbe Architektur bildet die Grundlage aller drei Produktstufen: DCOS für Infrastruktur-Monitoring, iDCOS für CMDB, ITSM und Automatisierung, sowie SmartBSM für die Business-Service-Sicht.
Netzwerk für direkten Hardware-Zugriff
Direkte Verbindung zu BMC-Management-Ports (iLO, iDRAC, iBMC, IMM) über ein dediziertes Out-of-Band-Netzwerk, was Echtzeit-Hardware-Monitoring unabhängig vom Betriebssystem ermöglicht.
Netzwerkaufbau
Datenerfassung
In-Band und Out-of-Band, nebeneinander
Die Erfassungsebene nutzt bewusst beide Pfade. Sie beantworten unterschiedliche Fragen, und zusammen schließen sie die Lücke, die jeder für sich allein offen ließe.
| Dimension | In-Band | Out-of-Band |
|---|---|---|
| Woher die Daten stammen | Das Betriebssystem, remote abgefragt | Der BMC-Management-Controller, unterhalb des Betriebssystems |
| Funktioniert, wenn das Betriebssystem ausgefallen ist | Nein | Ja: Hardwarestatus und Stromsteuerung bleiben erreichbar |
| Was es am besten erfasst | Prozesse, Dienste, Anwendungen, Ressourcennutzung | Komponentenzustand, Temperaturen, Stromaufnahme, Firmware |
| Typische Protokolle | SNMP, SSH/CLI, API, JDBC | Redfish, IPMI, iDRAC, iLO, XCC, iBMC |
| Rolle in der Plattform | Server-, Netzwerk-, Storage- und Anwendungs-Monitoring | Hardware-Monitoring und Remote-Management |
Wo die Architektur zum Einsatz kommt
Jede Lösungsfamilie ist dieselbe vierstufige Plattform, ausgerichtet auf einen anderen Teil des Rechenzentrums. Sie teilen sich Erfassung, Daten und Alarme – die Einführung einer Familie schließt die anderen nicht aus.
Für AI-Infrastruktur
Dieselbe Plattform erweitert sich auf GPU-Cluster, wo sich Leistungsdichte, Kühlung und Auslastung anders verhalten als bei Universal-Compute.
Wofür Teams es einsetzen
Unbemannte und Remote-Standorte
Out-of-Band-Zugriff hält Hardware an unbemannten Standorten sichtbar und steuerbar, selbst wenn das Betriebssystem oder das In-Band-Netzwerk nicht erreichbar ist.
Tool-Konsolidierung
Ersetzen Sie separate herstellerspezifische Monitore für Server, Netzwerk, Storage und Facility durch eine Plattform und einen Alarm-Stream.
Standortübergreifende Standardisierung
Rollen Sie dasselbe Monitoring-Modell über Rechenzentren und Colocation-Standorte hinweg aus, sodass jeder Standort Zustand, Assets und Energie auf dieselbe Weise meldet.
Energie- und PUE-Programme
Erfassen Sie Strom und Kühlung pro Rack zusammen mit der IT-Last, um ungenutzte Kapazität zu finden und Effizienzmaßnahmen im Zeitverlauf zu messen.
AI-Cluster-Ausbau
Erweitern Sie dieselbe Architektur auf GPU-Knoten und Flüssigkeitskühlungskreisläufe, während Cluster wachsen, und messen Sie, wie Beschleuniger genutzt werden.
Business-bewusster Betrieb
Bilden Sie Infrastruktur über SmartBSM auf die Services ab, die sie trägt, sodass ein Alarm mit seiner Business-Auswirkung eintrifft.
Häufige Fragen zur Plattform
Warum ist die Plattform in vier Ebenen gegliedert?
Weil jede Ebene nur so gut sein kann wie die darunterliegende. Die Erfassungsebene sammelt Rohdaten von den Geräten; die Ressourcenebene normalisiert sie zu Alarm-, Konfigurations-, Betriebs- und Energiedatensätzen; die Verarbeitungsebene korreliert diese Datensätze untereinander und mit dem Business-Kontext; und die Anwendungsebene macht daraus Monitoring, Reporting und Visualisierung. Eine Lücke in der Erfassung wird von allem darüber geerbt – deshalb investiert Sensaka zuerst in breite, agentenlose, multiprotokollfähige Erfassung.
Benötigt Sensaka Agenten auf überwachten Geräten?
Nein. Die Erfassung ist agentenlos: SNMP, SSH/CLI, APIs und JDBC sammeln In-Band-Daten, während Redfish, IPMI, iDRAC, iLO, XCC und iBMC Out-of-Band-Hardwaredaten liefern. Für Fälle, in denen eine Remote-Abfrage nicht möglich ist, existiert eine Agenten-Option, doch die Plattform ist nicht darauf angewiesen.
Was ist der Unterschied zwischen DCOS, iDCOS und SmartBSM?
DCOS ist die Infrastrukturebene: Monitoring von Hardware, Servern, Netzwerk, Storage, Strom und Kühlung. iDCOS ergänzt diese Daten um CMDB, ITSM und Automatisierung. SmartBSM ist die Business-Service-Ebene, die Infrastruktur auf die Services abbildet, die sie trägt, sodass sich Auswirkungen in Business-Begriffen ausdrücken lassen. Sie teilen dieselbe Architektur und können getrennt oder gemeinsam eingeführt werden.
Kann eine Bereitstellung Hardware mehrerer Hersteller überwachen?
Ja. Redfish und IPMI sind offene Standards, und Sensaka spricht zusätzlich die herstellerspezifischen Implementierungen – iDRAC, iLO, XCC, iBMC –, sodass eine gemischte Server-Flotte aus einer einzigen Bereitstellung abgedeckt wird. Derselbe herstellerübergreifende Ansatz gilt für Netzwerk- und Storage-Geräte.
Mit welcher Lösung sollten wir beginnen?
Beginnen Sie mit der Ebene, die am meisten schmerzt. Wenn Hardwareausfälle Sie immer wieder überraschen, beginnen Sie mit Hardware-Monitoring; wenn Sie nicht sagen können, was in welchem Rack steht, beginnen Sie mit Asset-Management; wenn Strom die Einschränkung ist, beginnen Sie mit Energiemanagement. Die Familien teilen eine Plattform, sodass jede Ergänzung auf den Daten aufbaut, die die vorherige bereits erfasst.