Herausforderungen im RZ-Management
Es geht nicht um das DCIM-Tool
DCIM-Werkzeuge (Datacenter-Infrastructure-Management) werden in jüngerer Vergangenheit als "Allheilmittel" zur vollständigen Erfüllung der Management-Aufgaben im RZ propagiert. Sie sollen die Infrastrukturverwaltung der technischen und nicht-technischen Anlagen effizient, Service-orientiert und nahtlos in alle Bearbeitungsprozesse einbinden. Unternehmen stehen jedoch häufig vor der Frage, sich auf die Softwaresuite eines Herstellers zu verlassen oder vorhandene Werkzeuge und Prozesse zu nutzen - und so in die Integrationsproblematik zu geraten.
DCIM muss ohne einheitliche Definition Management-Disziplinen bündeln, die bereits mit dem De-facto-Standard ITIL gewährleistet sein sollten. Zudem werden funktionale Anforderungen gestellt, die separaten Themenkomplexen wie dem Kabel-Management oder der IP-Adressverwaltung vorbehalten sind. Nachfolgende Ausführungen aus der Praxis sollen einen Überblick darüber geben, welche Themenkomplexe im gesamtheitlichen IT-Management anzutreffen sind, wo die Grenzen einzelner Systemgruppen liegen und welches Leistungsspektrum DCIM als "All-in-one"-Strategie erfüllen müsste.
ITSM
ITSM-Systeme (IT-Service-Management) dienen der Einführung oder Optimierung von ITIL-Prozessen. Demnach liegt der Schwerpunkt dieser Lösungen in der Abarbeitung und Steuerung der Arbeitsprozesse (Workflows). Während die ITIL-Disziplinen Incident- und Problem-Management heute nahezu flächendeckend und reibungslos in Betrieb sind, stellen Aufgaben wie Configuration- und Change-Management immer noch ein größeres Problemfeld dar. Letztgenannte Prozesse haben einen hohen Bedarf an Detaildaten zu Komponenten, Systemen und Beziehungen. Dieser lässt sich mit den generischen Datenmodelle der gängigen ITSM-Systeme (und deren Configuration-Management-Databases, kurz CMDBs) nur durch intensive Anpassung abbilden.
Mancher empfindet die Modellierung der Vielzahl unterschiedlichster IT-Gerätegruppen als schier unlösbare Aufgabe. Das viel gelobte Autodiscovery der Infrastruktur (inklusive Application Discovery) liefert unbefriedigende, inkonsistente Ergebnisse, und bestimmte Komponenten werden überhaupt nicht gefunden. Zudem bestehen entsprechende Softwaresuiten aufgrund von Akquisitionen oft aus mehreren Systemkernen, sodass die Modelle disziplinübergreifend (Discovery, Prozess, Konfiguration) hier nicht kongruent sind.
Mit dem Ziel der Service-Orientierung verschärft sich die Problematik um eine weitere Dimension. Auch wenn heute mit "ITSM aus der Cloud" schnelle Einführungen, Anpassungen und kostengünstiger Betrieb möglich sind, verzichtet man auf grafische Abbildungen von komplexen Konfigurationen, Schrankaufbauten und Schaltungen; zudem droht die Gefahr des sogenannten "Service-Gaps", nämlich der unterschiedlichen Sichtweise von Service, Technik und Störungsbehebung auf die Infrastruktur.
Fazit: ITSM-Systeme dienen der prozessualen Steuerung von Arbeitsprozessen. Man sollte also weder versuchen, aus einem ITSM-System ein technisches Konfigurationssystem noch ein Werkzeug für die Infrastrukturverwaltung zu machen. Denn es fehlen schlichtweg Modelle und grafische Repräsentanz.
BSM
Das BSM (Business-Service-Management) liefert die erweiterte Service-Sichtweise auf die IT-Infrastruktur und soll dem Geschäftsbetrieb dienen. Es wird, obwohl Bestandteil der ITSM-Definition, hier als eigene Disziplin genannt, weil die Hersteller häufig technisch und funktional separate BSM-Software anbieten. BSM kommt jedoch ebenfalls nicht ohne technische Detaildaten aus der Infrastruktur aus, insbesondere wenn man den Grad der Service-Erfüllung (Service-Qualität) messen will. Massiv unterschätzt werden hier bereits die Service-Definition, der Aufbau eines Service-Katalogs, die Integration von Stammdaten (Kunden, Personen, Verträge etc.) und die Integration von technischen Details. Im Betrachtungsfokus der Services sind meist nur automatisiert auffindbare Systeme. Erst das richtige Maß an Konfigurations- und Monitoring-Daten kann eine verlässliche und aussagekräftige Basis zur Service-Erbringung liefern.
Fazit: Keine Service-Erbringung ohne Service-Konsole. Werkzeuge mit vordefinierten Service-Schablonen und freier Zuordnung von Konfigurations- und Monitoringdaten helfen deutlich, das Ausklammern bestimmter Komponententypen behindert massiv.
Konfigurationsdatenbanken
Das Marketing einiger Hersteller setzt Daten aus dem Configuration- und dem Asset-Management inhaltlich nahezu gleich. Tatsächlich sind es unterschiedliche Disziplinen: technische Konfigurationsverwaltung und kaufmännische Anlagenverwaltung. Virtualisierung und Miniaturisierung machen Systemaufbauten immer komplexer, sowohl in der Konfiguration als auch in der Dokumentation, Verrechnung und Steuerung. Demnach sind einige CMDB-Modellansätze schnell überfordert, sowohl mit dem Thema Integration, als auch mit der Modellierung der Daten.
Die sich durch Discovery "selbstpflegende" Dokumentation ist in der Realität ein Ammenmärchen: In der Praxis begegnet man einem Mix aus Datenübernahme, Pflegeprozessen und den immer noch notwendigen Inventuren und Ad-hoc-Änderungen. Begleitende Disziplinen wie Kabel- und Verbindungs-Management, Netz- und IP-Adressverwaltung oder Steuerung von Drittsystemen bleiben hier kategorisch ausgeklammert, ohne dass erklärt wird, warum ein Kabel oder eine IP-Adresse als natürlich gegeben oder nicht als betriebs- oder Service-relevant einzuordnen sind. Speziell im Umfeld der Rechenzentren ergibt ein DCIM ohne Configuration- und Change-Management-Konzept keinen Sinn - auch das DCIM benötigt detaillierte Konfigurationsdaten. Und wer möchte schon gern einen notwendigen IT-Schrankausbau zunächst im Change-Prozesswerkzeug, dann im DCIM-Tool und anschließend in den CMDBs aufwändig pflegen? Denn Fakt ist, dass in den Unternehmensumgebungen eher mehrere Konfigurationsdatenbanken zu finden sind als nur eine einzelne. Man sollte mit DCIM keine weiteren Datentöpfe schaffen.
Fazit: Configuration-Management und CMDB sind zu "Buzzwords" verkommen, da sich weder zentralistische noch föderalistische Ansätze eindeutig durchgesetzt haben und viele Unternehmen das Thema aufgrund seiner Vielschichtigkeit und Komplexität kritisch betrachten. Was wir für Configuration-Management im kleineren Umfang erleben, gilt für die IT-Management-Landschaft insgesamt: Ohne Gesamtstrategie, Priorisierung, Fokussierung und Rückhalt durch das Management ist es oftmals zum Scheitern verurteilt.
Messwertverarbeitung
Mit dem Internet of Things (IoT) werden Sensoren und Roboter zunehmend an Bedeutung gewinnen, im RZ für Energie-, Belegungs- und Kühlungseffizienz. Allerdings sind Systeme unterschiedlicher Hersteller teils schwer in eine einheitliche Software zu überführen, da sie eigene Steuerungssoftware oder Protokolle mitbringen. Zudem wird man es in mittleren bis großen Umgebungen mit vielen Lieferanten zu tun haben, also begegnet man wieder Anforderungen der (Daten-)Normalisierung, Speicherung und Aufbereitung. Automatische Schlussfolgerungen aus Messdaten ohne genaue Kenntnis der zugrunde liegenden Konfigurationen oder Situationen bergen Gefahren: Temporär hohe Lasten auf Servern und Systemen müssen nicht zwangsweise ein Dauerzustand sein. Fehlt also auch hier (analog zu Prozessen) der Zugriff auf Detailinformationen aus dem Configuration- und Infrastruktur-Management, sind qualifizierte Schlussfolgerungen kaum möglich.
Fazit: Messwertverarbeitung wird als Teildisziplin von DCIM verstanden. Ohne ausreichende Informationen zur beteiligten Infrastruktur und Konfiguration sind sinnvolle Ableitungen und Maßnahmen kaum zu treffen. Die Problematik verschärft sich durch unzureichende Abbildung der Strominfrastruktur und fehlenden Zugriff auf Konfigurationsdaten.
Gebäude- und Anlagenverwaltung
Grafische Darstellungen der zu verwaltenden Anlagen wie Landkarten, Gelände- und Gebäudedarstellungen, Etagen- und RZ-Pläne schaffen Übersichtlichkeit, Orientierung und bieten Navigationshilfen. Die in Mode gekommenen 3D-Modelle des Rechenzentrums sind schick anzusehen, allerdings mangelt es an ausreichender Detailtiefe der Konfigurationsdaten oder Funktionalität. So muss man für einen Schrankumbau oder -ausbau in der Realität auch Kabel patchen, Stromanschlüsse planen und virtuelle Systeme zuordnen. Gerade bei logischen Clustern oder virtuellen Einheiten sowie auf der Port-Ebene (Anschluss-Port, Multistecker, modulare Stromleisten) stoßen Facility-Management-Systeme an ihre Grenze. Bei der Flächenbelegung muss man zusätzlich Netzwerk- und Sicherheitszonen, Kundenflächen oder Systemklassifizierungen (Service-Levels) im Auge behalten können.
Fazit: Ursprünglich aus der Gebäude- und Anlagenverwaltung entstandene Systeme sind mit zu vielen technischen Details überfordert. Grafische Darstellungen sollten dem Einsatzzweck dienen, Funktionalität geht hier vor. Architekturpläne werden häufig nicht in der IT gepflegt.
Netz- und System-Monitoring
Ähnlich wie bei Konfigurationsdatenbanken hat ein RZ-Betreiber hier eher mehrere Systeme im Einsatz als ein einheitliches. Typischerweise sind Daten im Monitoring nach Netzknoten, Host-Name sowie IP-Adresse organisiert und geprägt von hoher technischer Detailtiefe, allerdings schwacher Historisierung und Visualisierung. Wer die Live-Überwachung losgelöst betreibt, arbeitet mit Medienbrüchen zwischen den Systemen und verliert im Alarm- oder Fehlerfall viel Zeit und Geld. Notfallpläne, Impact-Analysen oder Logbücher sind bisher selten aufzufinden, bieten aber einen echten Mehrwert für das Unternehmen.
Fazit: System- und Netzwerk-Monitoring arbeitet im Regelfall sehr gut, allerdings oftmals auf der Basis mehrerer Systeme mit unterschiedlichen Identitäten und Nomenklaturen der Überwachungsknoten. "Root-Cause-" oder "Impact-Analysen" werden durch Zusatzwerkzeuge oder Integrationen abgedeckt, sind jedoch im Fehlerfall sehr dienlich. Mit systemischen Notfallplänen und qualifizierten Logbüchern erreicht man den größten Mehrwert und die geringste Wiederherstellungszeit.
Service-Orientierung statt Tool-Fokus
RZ-Management und eine Service-orientierte Ausrichtung sind letztlich keine Tool-Frage, sondern spannen je nach Anforderung des Betreibers den Bogen über die gesamte IT-Management-Landschaft. Die anfallenden Fragen sind vom DCIM alleine nicht zu beantworten. Auch wenn vielfach genau invers argumentiert wird, ist DCIM letztlich doch nur ein neuerer Kunstbegriff ohne klare Definition, dessen Inhalte sich aus schon vorher existenten Disziplinen zusammensetzen - daher wohl auch die wahrzunehmende Enttäuschung über die Zielerreichung im DCIM.
DCIM richtet sich heute vielfach an einer oberflächlichen (bildlichen) Infrastrukturverwaltung inklusive Messwertverarbeitung aus. Dabei unterschlägt es technisch detaillierte Konfigurationsdaten, ITSM-Prozesse und -Werkzeuge, die bereits vorhanden sind. Für eine Gesamtstrategie ist ein Beratungsansatz notwendig, der in einem ersten Analyseschritt vorhandene Systeme (Silos), Prozesse sowie Daten aufgreift und in eine Zieldefinition überführt. Nur so lassen sich bereits getätigte Investitionen sichern und Mammutprojekte vermeiden. Auch wenn einzelne Silos ersetzt werden oder Integrationen in ein übergreifendes ("Umbrella"-) System notwendig sind, ist dies von einem "All-in-one"-Ansatz weit entfernt.
Lediglich in der Einzelsituation lässt sich entscheiden, ob der Vorteil eines Umbrella-Systems überwiegt, das auch funktionale Teilaufgaben aus den Silos übernimmt, oder der einer Integrationsstrategie mit Fokus auf die Datenhaltung (Data Repositories). Es sei jedoch darauf hingewiesen, dass aufgrund geringerer Komplexität der Umbrella-Ansatz gar zu optimistischen Integrationsbestrebungen vorzuziehen ist. Die meisten verfügbaren DCIM-Lösungen eignen sich kaum für ein Umbrella-System, da bisher weder vielschichtige Ansätze zur Datenintegration zu erkennen sind, noch die Funktionstiefe in einzelnen Silos gegeben ist. Hier treffen Anforderungen eines Data Repositorys auf die mehrerer Expertensysteme. Glücklich scheint der, der mit einem RZ-Neubau bei Null beginnen kann.
Lesen Sie mehr zum Thema
