Dokumentation als Basis für Orchestrierung

Übergreifende Prozessautomation

17. Februar 2017, 8:00 Uhr | Von Oliver Lindner.

DCIM-Software (Datacenter-Management-Infrastructure-Management) unterstützt Rechenzentrumsbetreiber heute nicht nur bei der Optimierung der Ressourcennutzung. Vielmehr kann sie auch die Grundlage für domänenübergreifende Workflows bilden. Auf diese Weise lassen sich Prozesse durchgängig automatisieren.

In nahezu allen Teilbereichen des Rechenzentrumsbetriebs finden wir heute automatisierte Prozesse: Der Generator springt bei einer Versorgungsstörung selbstständig ein, die Kühlung passt sich dem Wetter an, Management-Software provisioniert virtuelle Systeme und verschiebt sie zur Lastoptimierung transparent von einem physischen Server zu einem anderen. Innerhalb der jeweiligen Domäne und ihrem scharf abgegrenzten Aufgabenbereich funktionieren diese Prozesse tadellos.

Greift man das Beispiel der automatischen Bereitstellung einer VM auf, zeigen sich die Grenzen der derzeitigen Methoden jedoch sehr schnell: Basierend auf Vorlagen und definierten Regeln lässt sich zwar ein virtuelles System innerhalb weniger Augenblicke nach der Bestellung in einem Kundenportal vollautomatisch erzeugen und granular konfigurieren; aber was, wenn die Kapazität des darunterliegenden Clusters überschritten wird und keine ausreichende Kapazität mehr im Rechnerverbund zur Verfügung steht? Kaum ein Verfahren ist heute in der Lage, in diesem Fall eigenständig weitere Schritte zu ergreifen und entsprechende Erweiterungen zu initiieren. Die Intervention durch Bediener ist notwendig und zahlreiche manuelle Schritte sind in verschiedenen Tools durchzuführen, obwohl es sich hierbei um ein ganz übliches, zu erwartendes Szenario handelt.

Im Facility-Management-Umfeld gibt es umfangreiche und detaillierte Automatisierungen für die Steuerung von Geräten und vorbereitete Notfallpläne für alle denkbaren Störungen. Die Gebäudeleittechnik ist so zuverlässig, weil es nur sehr geringe Änderungsquoten im Bereich der Geräte(typen) gibt, die Domänengrenzen nicht überschritten werden und die Anordnung der Systemkomponenten nach der Errichtung und Erfassung quasi statisch ist.

LL02F04a
Systemgenerierte Abhängigkeiten einer SAP-Anwendung über den gesamten IT-Stack inklusive Bezug zur Hardware und Lokation (vereinfachte Darstellung). Bild: FNT Software

Auch für den normalen Betriebsablauf und die Optimierung der Störungsbehandlung ist neben einer Überwachung eine solide Dokumentation erforderlich. Wenn eine Störung eines Geräts auftritt, muss der zuständige Mitarbeiter die Auswirkung ("Impact") beurteilen und die Ursache ("Root Cause") analysieren. Hierfür sind die Abhängigkeiten und Beziehungen des betroffenen Geräts elementar. Wenn zum Beispiel die Stromversorgung für ein Rack ausfällt, weil eine Sicherung gestört ist, macht es sehr wohl einen Unterschied für die Kritikalität des Ereignisses, ob das zugehörige Rack leer ist oder prall gefüllt mit Servern für unternehmenskritische Anwendungen.

Für die Gebäudeleittechnik ergibt sich oft das Problem, dass diesen Systemen in der Regel nicht bekannt ist, welche und wessen Geräte sich in den Racks befinden: Nur der Strompfad vom Rack bis zum Erzeuger ist üblicherweise im Detail bekannt. So kann man im Störungsfall zwar beurteilen, ob zum Beispiel A- und B-Versorgung gleichzeitig betroffen sind, aber es erfolgt keine automatische Benachrichtigung der Betreiber oder Eigentümer der Systeme. Auch eine Event-Benachrichtigung an Betriebsstellen oder Steuersysteme für die Verlagerung von Lasten, zum Beispiel durch Verschiebung von virtuellen Maschinen auf nicht betroffene Bereiche im RZ oder gar in ein anderes RZ, sind somit nicht orchestriert möglich.

Ist ein Server in einem Rack zu provisionieren, müssen im Rack auch wirklich entsprechender Platz und ausreichend Strom zur Verfügung stehen. Zudem muss es langfristig möglich sein, die im Betrieb anfallende Wärme sicher abzuführen. Sollte auch nur eine Annahme nicht zutreffen, kann das Vorhaben nicht Erfolg haben, Störungen sind vorprogrammiert. Fehlt ein angenommener Port auf dem Switch in der vorherigen Planung, weil er entweder defekt ist und dies nicht dokumentiert beziehungsweise gemeldet wurde, oder weil der Port ohne entsprechende Dokumentation in Verwendung ist, muss man den Switch gegebenenfalls erst erweitern oder eine Alternative finden. Dies verursacht erhebliche Störungen und Verzögerungen im automatisierten Provisionierungsprozess.

Kenntnis der Sachlage

Für jeden Planungsprozess und Workflow ist die Zuverlässigkeit der Informationen entscheidend; gerade für vollautomatische Verfahren ist die Kenntnis des genauen Zustands des Rechenzentrums unabdingbar. Jedes System muss bekannt sein und jeder relevante Umstand berücksichtigt - und dies über Abteilungsgrenzen hinweg. Auf Dauer funktionieren hier weder manuell gepflegte Listen, noch kann der Zuständige mit Nachdokumentation oder "verteilten" Informationen sinnvoll arbeiten.

Da einem immer agileren Umfeld in der Regel immer weniger Personal gegenübersteht, müssen IT-Organisationen zwangsläufig Prozesse durch Orchestrierungen und automatische Abläufe optimieren. Automatisierte oder zumindest teilautomatisierte Workflows gewinnen so für den RZ-Betrieb an Bedeutung. Es muss das Bestreben aller RZ-Betreiber sein, sich nicht nur mit Teillösungen zufriedenzugeben und in engen Korridoren eine Automation und Optimierung zu erreichen, sondern übergreifende Prozesse zu ermöglichen und auf die vollständige Automation hinzuarbeiten.

Natürlich gibt es am Markt seit Längerem extrem leistungsfähige Orchestrierungslösungen, doch finden diese bis heute ihren Einsatz in der Regel in der Bearbeitung und Bereitstellung von "Services"; im Rechenzentrum ist ihr Einsatz begrenzt auf White Space - und sie haben noch keinen Einzug gefunden in die umliegenden Bereiche. Der Hauptgrund liegt hier sicher nicht in der mangelnden Eignung der Software für die Orchestrierung, sondern im Fehlen von Daten und Datenkommunikation. Beim Abtauchen von der virtualisierten Welt in die darunterliegenden physischen Schichten zeigen sich klare Deckungslücken in der durchgängigen Dokumentation und Modellierung sowie harte Grenzen an den Domänen. So fehlen die Informationen, um ein System automatisch Entscheidungen treffen und Prozesse steuern zu lassen.

LL02F04b
Workflow-Definition für die automatisierte Provisionierung einer Applikation auf einer virtuellen Maschine. Bild: FNT Software

Entgegen der weit verbreiteten Angewohnheit, Änderungen nachträglich zu dokumentieren, muss man für einen sinnvollen RZ-Betrieb mit automatisierten Prozessen erst dokumentieren und die Dokumentation nach einer Änderung validieren. Vom Benutzer gestaltete Listen, die wichtige Informationen in frei beschreibbaren Bemerkungsfeldern enthalten, scheiden als Datenquelle für derartige Verfahren aus.

Der gerne aufgeführte Weg der automatischen Dokumentation ist leider kein ausreichender Ersatz: Gerade an der Verbindungsstelle von physisch zu logisch und in Teilbereichen der Dokumentation physischer Ressourcen versagen Verfahren der automatischen Dokumentation mittels Autodiscovery. Bei Passivkomponenten wie konventionellen Patch-Panels oder Kabelverbindungen ist diese Variante gar nicht benutzbar. Da jedoch ein erheblicher Anteil aller Störungen im RZ aber auf Passivkomponenten und Kabelprobleme zurückzuführen ist, ergibt sich hier eine gefährliche Lücke.

Diese Problematik zeigt sich auch bei Wenn/dann-Analysen und Resilienzbetrachtungen. Auch hier müssen alle Komponenten, die einer Störung oder einer Änderung unterliegen, berücksichtigt sein. Wenn die Beziehungen nicht lückenlos erfasst sind und die Dokumentation nicht vollständig ist, ergeben sich unzulässige Annahmen - und scheitern Methoden wie auch Prozesse. Für viele Prozesse sind zudem weitergehende Informationen notwendig, die weder über Autodiscovery zu erkennen sind, noch von den heute üblichen Tools im RZ-Umfeld erfasst werden: SLA-Daten, Vertragsinformationen, Eigentumsverhältnisse und Lifecycle-Zustand eine Komponente zum Beispiel sollten in Orchestrierungsprozessen Berücksichtigung finden.

Geeignetes Datenmodell zählt

Als Lösung für die vorstehenden Problematiken bieten leistungsfähige moderne DCIM-Lösungen heute umfangreiche Datenmodelle, um alle relevanten RZ-Komponenten zu erfassen. Über offene Schnittstellen können auch externe Orchestrierungswerkzeuge und sonstige Softwarelösungen auf diese Daten zugreifen und sie für ihren Betrieb nutzen - stets mit dem Ziel, von allen wichtigen Systemen relevante und valide Informationen über vorhandene Geräte und deren Beziehungen und Zustände zu richtigen Zeitpunkt zu liefern. So können IT-Organisationen durchgängige Workflows über Bereichsgrenzen hinweg modellieren und erhebliche Prozessoptimierungen erreichen.

Eine ordnungsgemäße, aktuelle und valide Dokumentation ist die Voraussetzung für einen optimalen Betrieb und übergreifende automatisierte Prozesse. In Anbetracht der Möglichkeiten und des unbestrittenen Nutzens erscheint das "langweilige" und gerne stiefmütterlich behandelte Thema Dokumentation in einem ganz anderen Licht: Mit der richtigen Management-Software, die alle Aspekte verwaltet und die erforderliche Integrationsfähigkeit aufweist, kann ein Unternehmen eine optimale Planung und Ressourcennutzung erreichen; und sie kann einen Workflow erarbeiten, der das Personal entlastet und im Fehlerfall zielorientiert unterstützt. So können Facility, IT und Netzwerk wirklich zusammenwachsen. Eine Compliance-, rechts- und revisionssichere Dokumentation ist dabei sozusagen gratis inbegriffen.

Oliver Lindner ist Geschäftsfeldverantwortlicher für das Segment Data Center Infrastructure Management (DCIM) bei FNT ().

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Stratus Technologies GmbH

Weitere Artikel zu INCOM Storage GmbH

Matchmaker+