ITSM in dynamischen Serverumgebungen
Die Virtualisierung geht weiter
Die Servervirtualisierung ist den Kinderschuhen entwachsen. Die einfache Virtualisierung eines physischen Serversystems zu mehreren virtuellen Einheiten zur Kosteneinsparung ist Alltag geworden, neue Herausforderungen stehen im Blickpunkt. Dies sind insbesondere höhere Flexibilität, die Kapselung der Komplexität, die Dynamisierung der IT-Infrastrukturschicht und die Energieeffizienz.
Wenn man über dynamische IT-Strukturen spricht, lautet das wesentliche Stichwort: "
anforderungsgerechte IT-Infrastruktur". Anforderungen an die IT können vielfältiger Natur sein.
Diese sind heute in der Regel in SLAs (Service Level Agreements) zwischen IT und Kunde
festgehalten. Zusätzliche operative oder wirtschaftliche Anforderungen an die IT wie zum Beispiel
die Reduktion des Energieverbrauchs lassen sich über die Preiskomponente der SLAs regeln oder durch
interne SLA-konforme Maßnahmen umsetzen. In der Praxis ergeben sich zwei Ansatzpunkte, um die IT
durch Dynamisierung zu optimieren:
neue oder wechselnde Anforderungen durch die Kunden (zum Beispiel die
Bereitstellung eines neuen Webservers oder Bedarf an mehr Performance für das ERP-System),
effiziente Bereitstellung der IT-Leistung.
Häufig sind IT-Infrastrukturen auf Maximalanforderungen (Peaks) ausgelegt. Einige
Softwarehersteller setzen dieses Designkriterium für ihre Produkte sogar voraus. In der Praxis
findet man jedoch nur selten Betriebssituationen, in denen alle Services rund um die Uhr (24×7) mit
voller Leistung bereitzustellen sind. Hier kann eine Dynamisierung der IT helfen, die Last so zu
verteilen, das die Gesamtkapazität der Infrastruktur geringer ausfallen kann. Allerdings sind hier
derzeit noch die genannten Designkriterien der Softwarehersteller zu berücksichtigen – ein
beginnendes Umdenken ist jedoch bereits erkennbar. Damit ergibt sich die Möglichkeit, im Rahmen
eines dynamischen Rechenzentrums die jeweils tatsächlich bereitzustellenden Services so auf wenigen
Systemen zusammenzufassen (zum Beispiel nachts), dass die IT-Abteilung nicht benötigte Systeme zum
Beispiel zur Stromeinsparung abschalten oder warten kann, ohne dass SLAs verletzt werden.
Anforderungen an Werkzeuge
Dass all die notwendigen Aktionen für die Dynamisierung und Flexibilisierung in heutigen
verteilten und komplexen Infrastrukturen manuell kaum mehr fehlerfrei und effizient durchführbar
sind, steht außer Frage – ein Werkzeug muss her! Ein solches Werkzeug, das große Teile eines
RZ-Betriebs automatisiert, muss besonderen Anforderungen genügen: Erstens muss das Tool
serviceorientiert sein – ein scheinbar trivialer Punkt für ein ITSM-Tool (IT-Service-Management) in
dynamischen Umgebungen. Wichtig ist jedoch, ob das Konzept des Tools (insbesondere die Möglichkeit
zur Policy-Erstellung) es zulässt, auf Serviceebene oder "nur" auf technischer IT-Ebene zu agieren.
Hinzu kommt die Formulierung eigener SLAs.
Die zweite Forderung: Prozessorientierung. Neben der konkreten Unterstützung der
Betriebsprozesse sollen sich klassische Prozesse oder Workflows abbilden lassen. Ein einfaches
Beispiel ist die Unterstützung klassischer Genehmigungsprozesse bei der Bereitstellung neuer
Infrastruktur-komponenten. Hier müssen Schritte wie Genehmigungsverfahren und Kontrollinstanzen
abbildbar sein. Daraus ergibt sich auch die Anforderung an die Flexibilität des Werkzeugs:
Beliebige Prozesse müssen umsetzbar sein.
Eine Schnittstelle zu Change-, Configuration- und Capacity-Management muss vorhanden sein. Diese
zentralen Prozesse für den täglichen Betrieb muss das Werkzeug unterstützen, das Change- und
Configuration-Management auch im Sinne einer Zwei-Wege-Kommunikation: Manuelle Veränderungen müssen
dem Automationswerkzeug einfach mitteilbar sein. Umgekehr muss die aktuelle Konfiguration der
dynamischen IT-Landschaft jederzeit einfach abgerufen und gegebenenfalls verändert werden können.
Optimalerweise besteht eine direkte Verbindung zur CMDB (Configuration Management Database).
Hochverfügbarkeit und Stabilität
Ein Tool zur Automatisierung muss nicht ständig aktiv sein – neue Anforderungen ergeben sich
tages- oder maximal stundenweise. Ein Ausfall des Tools im Minutenbereich ist also nicht tragisch.
Umgebungen, die kritische Änderungen im Sekundentakt durchführen, sind selten, wenn überhaupt zu
finden. Sehr viel wichtiger ist die Fähigkeit, die CMDB für die dynamische Infrastruktur konsistent
betreiben zu können und im Fall eines Desasters sowohl die Automationsumgebung als auch in der
Folge die IT-Landschaft automatisiert, schnell und zuverlässig wieder aufsetzen zu können. Im
einfachsten Fall kann dies zunächst eine vordefinierte Standardkonfiguration sein, die sich im
Laufe des Betriebs wieder gemäß den Anforderungen rekonfiguriert.
Wichtig sind zudem offene Schnittstellen und die Unterstützung heterogener IT-Landschaften.
Proprietäre Lösungen, die die eigenen Produktlinien der jeweiligen Hersteller unterstützen, gibt es
einige. Ihre Aufgaben erledigen diese Tools in der Regel auch sehr gut. Die übergreifende Steuerung
einer dynamischen IT über verschiedene Serverplattformen, Betriebssysteme, Storage-Infrastrukturen
(DAS, NAS, SAN) und Netzwerkkomponenten hinweg lässt sich mit diesen Werkzeugen aber häufig nicht
zufriedenstellend lösen. Offene Schnittstellen (APIs), die Unterstützung von Standardschnittstellen
wie XML, SSH oder WMI sowie vordefinierte Schnittstellen zu den Standardmanagementwerkzeugen sind
notwendige Voraussetzungen.
Im produktiven RZ-Betrieb wird man nicht "mal eben" neue Regeln für die Automation oder
Dynamisierung eines Services einführen. Das Werkzeug muss also den klassischen Lebenszyklus der
Softwareentwicklung – Entwicklung, Test, Produktion, Revision – unterstützen. Idealerweise kann es
auch revisionssicher nachweisen, dass die Verfahren tatsächlich für die Produktion freigegeben
wurden, zum Beispiel durch die elektronische Signatur der Verfahren. Die Einführung neuer Regeln
oder Services muss dokumentiert und einfach reversibel sein. Für den Fall, dass die Ausführung
einer Regel die IT-Services beeinträchtigt, muss automatisiert oder manuell eine Rückkehr zum
vorherigen Zustand oder zu einem definierten stabilen Zustand möglich sein
(Rollback-Verfahren).
Schnittstelle zur Leistungsverrechnung
Ist die verursachergerechte Leistungsverrechnung in der heutigen IT schon ein Thema für sich,
wird dies in einer dynamischen Umgebung technisch gesehen nicht einfacher, da sich hier die
Zuordnung zwischen Services, IT-Komponenten und Kosten ständig ändern können. Konzeptionell gibt es
Lösungsmöglichkeiten über Service-Standardpreise, die weitgehend von der zugrunde liegenden
Hardware abstrahieren. Dennoch sind Nutzungsdaten und bereitgestellte Leistungen in Bezug zu den
Services zum Beispiel in Stückzahlen oder Performance erforderlich. Diese Daten sind aus der
Automationsinfrastruktur oder damit verbundenen Systemen wie der CMDB bereitzustellen.
Mit diesen Anforderungen steht die Frage im Raum: Soll es das Universalwerkzeug sein
(Framework), das alle Systeme direkt bedienen kann, oder ist es sinnvoller, an zentraler Stelle ein
schlankes System einzusetzen, das über Schnittstellen die Herstellerwerkzeuge steuert? Wer sich
bereits mit der Auswahl von Netz- und Systemmanagementwerkzeugen beschäftigt hat, kennt diese Frage
und weiß auch, dass es keine allgemeingültige Antwort geben kann. Vor dem Hintergrund der Vielfalt
und Spezialisierung der Managementwerkzeuge für die IT-Komponenten scheinen derzeit schlanke
Automationswerkzeuge im Sinne eines Umbrella-Managements die bessere Wahl zu sein. Auch vor dem
wirtschaftlichen Hintergrund (Return on Investment) kann es sinnvoller sein, kleine, schlanke
Lösungen zu implementieren, um die häufig schon vorhandenen Managementsysteme zu ergänzen.
Nicht nur eine Frage des Werkzeugs
Mit dem Einsatz eines Werkzeugs allein ist es nicht getan. Trotz der Anforderung, auch (nach wie
vor etablierte) heterogene IT-Landschaften zu unterstützen, ist dennoch vor der Einführung von
Automationswerkzeugen zur Servicesteuerung eine weitgehende Standardisierung der IT-Landschaft
anzustreben. Die Integration der Systeme kann sonst leicht unwirtschaftlich ausfallen und der
Betrieb der Gesamtstruktur ineffizient oder fehleranfällig werden.
Ein weiterer wichtiger Punkt ist an sich trivial, aber in der Praxis nur selten vorzufinden: die
Kenntnis der eigenen IT-Landschaft, insbesondere die Abbildung der Zusammenhänge zwischen Services
und IT-Komponenten. Wer sich bereits mit Notfallplänen oder Risikobewertungen beschäftigt hat, dem
sind die Verfahren dazu bekannt; wer gar eine CMDB eingeführt hat und diese im Rahmen der
Betriebsprozesse pflegt, sollte hier bereits auf die notwendigen Informationen zugreifen
können.
Außerdem hilft ein Automatisierungswerkzeug natürlich nicht über das Fehlen eigener
Steuerungsprozesse hinweg: Ein Werkzeug kann diese Prozesse nur unterstützen und die Schnittstellen
bedienen. Speziell in diesem Zusammenhang sind noch einmal die Prozesse Change-, Configuration- und
Capacity-Management zu nennen. Incident- und Problem-Management sind im Hinblick auf
automatisiertes ITSM weniger kritisch, sofern die Schnittstellen sauber definiert sind. Wer zudem
die Nutzungsdaten der Services auch zur Verrechnung der Kosten und Leistungen verwenden will, muss
sich auch mit den Prozessen zur Leistungsverrechnung auseinandersetzen (Accounting und Pricing nach
ITIL). Im Zusammenhang mit den Prozessen und deren zentraler Steuerung gilt es auch, sich Gedanken
über die eigene Organisation zu machen. Häufig stellt sich heraus, dass die klassische
Säulenorganisation (Mainframe, Windows, Unix, Netzwerk, Storage) nicht adäquat und kontraproduktiv
ist.
Zu guter Letzt ein scheinbar trivialer Punkt: Steuert das Werkzeug tatsächlich das, was die
Kunden wollen, oder aber das, was technisch machbar ist? Diese Fragestellung sollte man mit der
Chance verbinden, die IT-Services darauf hin zu überprüfen, ob sie tatsächlich kundenorientiert
sind. Denken die Endwender beispielsweise in TpmC-Werten und GByte oder eher in "Kontoauszug
drucken", "CAD-Zeichnung archivieren" oder "Risikoanalyse durchführen"? Gegebenenfalls kann hier
ein Service-Manager die Übersetzerrolle wahrnehmen, um tatsächlich das zu automatisieren, was die
Kunden dynamisch fordern. Übersetzungsfehler sind jedoch nicht auszuschließen.
Zusammenfassung
Tools zur dynamischen Erfüllung der Serviceanforderungen sind bereits in Teilbereichen
verfügbar, zum Beispiel für die x86-Virtualisierung. Übergreifende Werkzeuge, die alle
IT-Infrastrukturschichten des Rechenzentrums automatisieren und dynamisieren und so auch die
zusätzliche Komplexität kapseln, die zum Beispiel Virtualisierungslösungen mit sich bringen, sind
auf dem Vormarsch. Um diese aber wirtschaftlich und effizient einsetzen zu können, sollte die
IT-Landschaft zumindest innerhalb der Plattformen weitgehend standardisiert sein. Zudem kann ein
Werkzeug nicht über Schwächen im Service-Management oder in den Prozessimplementierungen hinweg
helfen. Solide und etablierte Prozesse sind die Grundvoraussetzung für effizientes ITSM in
dynamischen Umgebungen.
Lesen Sie mehr zum Thema
