Bedarfsgerechte Bereitstellung von IT-Ressourcen
Anwendungen als Orchester dirigieren
Anwendungslandschaften bestehen heute in der Regel aus einer Vielzahl statischer Silos. Um Spitzenlasten abzufangen, fällt die Hardwareinfrastruktur meist überproportional üppig aus. Diese Überkapazitäten stellen einen hohen Kostenfaktor dar. Zudem fehlt es oft an Automationsverfahren, um Anwendungsserver schneller und kostengünstiger bereitzustellen. Mit Provisioning- und Orchestration-Techniken tritt die IT-Administration solchen Zuständen entgegen.
Unter "Provisionining" versteht man die hoch automatisierte Bereitstellung einer IT-Ressource,
um die Bedürfnisse des IT-Umfelds zu befriedigen. Beispiele solcher Bereitstellungen sind die
Basisinstallation eines Betriebssystems, die Installation und Konfiguration von Middleware und
Applikationen, Veränderungen an Netzwerkstrukturen wie VLAN-Modifikationen sowie die Zuordnung von
Storage.
"Orchestration" bezeichnet die regelbasierte Bereitstellung von IT-Ressourcen: Veränderungen im
Kapazitätsbedarf oder SLA-Kriterien (Service-Level-Agreement) führen zu einer Tool-gestützen
Priorisierung bei der Zuordnung von IT-Ressourcen. Anstelle einer überproportionalen Bereitstellung
von Hardware zum Betrieb einer Anwendung bündelt dieses Vorgehen Ressourcen in Pools. Es stellt sie
dann bereit, wenn Bedarf besteht – und entzieht sie, wenn er nicht mehr besteht. Ziel ist es,
Serverfarmen durch dynamische Reallokation (Neuzuweisung) von Ressourcen zu verschlanken. Dies
bedarf flexibler Automationsroutinen, die im Falle eines Ressourcenengpasses ablaufen.
Idealerweise ergänzen sich beide Ansätze: Das Provisioning-Modul übernimmt dabei die Rolle einer
Automationsmaschine (Deployment-Engine) für die Abarbeitung komplexer Workflows. Ihre Aufträge
erhält diese Engine auf verschiedene Wege: entweder manuell durch den Administrator, zeitgesteuert,
über externe Schnittstellen beispielsweise durch ein Fault-Managementsystem, halbmanuell durch
Empfehlung der Lösung oder vollautomatisch durch eingebaute Mechanismen. Letztere beiden Modi
basieren auf den Mechanismen des Orchestration-Moduls, das auch als Policy-Engine bezeichnet wird.
Der Einsatz der Deployment-Engine ist somit unabhängig von der Policy-Engine möglich, umgekehrt
fehlt jedoch einer Policy-Engine ohne Deployment-Engine die Umsetzung der Empfehlungen.
Zentrale Konfigurationsdatenbank
Eine wesentliche Instanz in der Lösungsarchitektur, auf die sich die Funktionen der Deployment-
und Policy-Engine stützen, ist die zentrale Konfigurationsdatenbank. Sie dient der Beschreibung von
Rechenzentrumselementen und deren Abhängigkeiten. Physische wie auch logische Ressourcen sind in
dieser zentralen Datenbank definiert. Sie weist eine Vielzahl vordefinierter Objektklassen zu, so
zum Beispiel Netzwerkelemente (Switches, Router etc.), Server (inklusive der Modellierung
virtueller Server), Boot-Server, Storage, Cluster-Infrastrukturen, Softwareelemente, Rechner-,
Storage- und Lizenz-Pools etc.
Die Voraussetzung für den Einsatz einer Provisioning-Lösung ist die Modellierung, also die
Beschreibung der im Kontext einer Ressourcenbereitstellung relevanten IT-Elemente und ihrer
Abhängigkeiten in der Konfigurationsdatenbank. "Betanken" lässt sich eine solche Datenbank über
manuelle Wizard-gesteuerte Eingabeverfahren, XML-Importschnittstellen oder definierte und
erweiterbare Discovery-Mechanismen. Die zentrale Datenbank beinhaltet Informationen über den Soll-
wie auch über den Ist-Zustand der Infrastruktur.
Während die Konfigurationsdatenbank den Bestand der Infrastruktur abbildet, übernimmt eine
andere Engine die Ermittlung und Vorverarbeitung der Lastprofile von Systemen, die im Kontext einer
Applikation definiert sind, zum Beispiel eines Anwendungs-Clusters. Diese Informationen,
beispielsweise über die CPU-Auslastung oder Transaktionsraten eines vorgeschalteten
Load-Balancing-Systems, können als Basis für eine dynamische Ressourcenallokation dienen.
Daraufhin gilt es, die Bedarfsansprüche der Anwendungen zu beurteilen. Als Grundlage dienen die
ermittelten Lastprofile sowie definierte Schwellwerte, zum Beispiel die durchschnittliche
CPU-Auslastung des Anwendungs-Clusters. Stellt sich dabei heraus, dass die definierten
SLA-Kriterien nicht mehr mit den verfügbaren Ressourcen zu erfüllen sind, dann lässt sich eine
Bedarfsmeldung an eine übergeordnete Instanz übermitteln. Diese übergeordnete Instanz wägt
Bedarfsmeldungen unterschiedlicher Applikationen ab und zieht dabei im Konfliktfall deren
definierte Wertigkeit in Betracht. Wenn Ressourcen mehreren Anwendungen in einem Pool zur
gemeinsamen, jedoch nicht gleichzeitigen Verwendung bereitstehen, ist es Aufgabe dieses
Managementmoduls, für die optimierte Behandlung der Anforderungen zu sorgen.
Die Bedarfsmitteilungen lassen sich in einen so genannten "Fitnesswert" der Applikation
umwandeln. Zur Errechnung dieses Wertes dient unter anderem die definierte Anwendungspriorität.
Ziel der zentralen Entscheidungsinstanz ist es, den Fitnesswert in einen Bereich zu überführen, der
ein ausgewogenes Verhältnis zwischen den Anwendungen herstellt, denen ein gemeinsamer
Ressourcen-Pool zur Verfügung steht.
Von der Orchestrierung zur Provisionierung
Nachdem die zentrale Instanz entschieden hat, welcher Anwendung welche Ressourcen zuzuordnen
beziehungsweise zu entziehen sind, erhält die Deployment-Engine den Auftrag, die notwendigen
Automationsroutinen anzustoßen. Die erwähnte Konfigurationsdatenbank stellt dabei eine Vielzahl
generischer Klassenstrukturen zur Verfügung, um die konkreten Elemente in ihren Eigenschaften zu
beschreiben. Ein generisches Cluster-Modell sollte zum Beispiel die herstellerübergreifende
Beschreibung erlauben, unabhängig davon, ob es sich um einen IBM-HACMP- (High Availability Cluster
Multi-Processing), Tivoli- System-Automation-, Veritas-, MSCS- (Microsoft Cluster Server) oder
Websphere-Cluster handelt. Ebenso sollten für diese generischen Objektklassen allgemein gültige
Operationstypen definiert sein, so zum Beispiel für jedes Objekt der Klasse "Switch" Funktionen, um
einen Port zu aktivieren, zu deaktivieren und von einem VLAN (Virtual LAN) in ein anderes zu
konfigurieren. "Software" wiederum kennt beispielsweise Funktionen wie Installieren, Deinstallieren
oder automatisch Erfassen.
Innerhalb der Gesamtlösung bezeichnet man die Funktionen als "logische Operationen". Deren
Umsetzung erfolgt durch Automationsroutinen ("Workflows"). Diese Workflows können auch unabhängig
von logischen Operationen einen Automationsablauf definieren, der möglicherweise eine Unterfunktion
in einem übergeordneten Workflow-Konstrukt bereitstellt. Sie beinhalten mitunter in verschachtelter
Form andere Workflows, um übergeordnete, wiederverwendbare Automationsabläufe zu definieren.
So gibt es beispielsweise Workflow-Implementierungen, die einen exemplarischen Prozess einer
produktionsreifen Überführung eines Rechners aus einem Rechner-Pool in einen Anwendungs-Cluster
ermöglichen. Die Workflow-Implementierung der dazugehörigen logischen Operation "Cluster.AddServer"
sieht eine Vielzahl von Einzelschritten vor: zum Beispiel die Rechnerallokation aus dem Pool; die
Ermittlung notwendiger Attribute des Pools, des Anwendungs-Clusters sowie mit dem Cluster
assozierter Software-Stacks und Storage-Anforderungen aus dem DCM (Data Center Model); die
Installation des Basisbetriebssystems; Softwareinstallation; Storage-Zuteilung; IP-Adressierungen;
das Verschieben des Rechners aus einem Build-VLAN in ein Produktions-VLAN etc. Diese Einzelschritte
werden dabei durch logische Operationen vorgehalten, sodass der generelle Ablauf wiederverwendbar
bleibt.
Lösungsszenario Citrix-Serverfarm
Die beschriebenen Orchestration- und Provisioning-Möglichkeiten lassen sich zum Beispiel bei der
Automaton von Citrix-Serverfarmen einsetzen. Häufig kennzeichnen schwankende Anforderungen im
Lastverhalten der Anwendungen derartige Serverfarmen. Eine schnelle Reaktion auf das veränderliche
Umfeld ist jedoch oft aufgrund der teilweise manuellen Verfahren der Anwendungsinstallation und
-deinstallation sowie Änderungen der Farm-Membership-Prozeduren eines Servers nur bedingt möglich.
Ziel muss es hier sein, den Gesamtprozess zu automatisieren und dabei Ressourcen dynamisch zwischen
unterschiedlichen "Load-Managed Application Groups" (bezüglich Auslastung verwalteten
Anwendungsgruppen) der Serverfarm bereitzustellen. Ehemals manuelle Übergänge und teilweise manuell
durchgeführte Administrationsschritte sind dabei vollständig automatisierbar (siehe Bild 3). Der
Prozess der automatischen Überführung eines Rechners aus dem "Bare-Metal"-Status in einen produktiv
nutzbaren Applikationsserver lässt sich so erheblich verkürzen. Ein einziger übergeordneter
Workflow ermöglicht diesen Prozess.
Zunächst ist erforderlich, die vom Automationsprozess betroffenen logischen und physischen
Elemente der Infrastruktur in der zentralen Konfigurationsdatenbank abzubilden. Die Objektklasse "
Applications" findet dabei beispielsweise Verwendung, um die Konstrukte Citrix-Metaframe-Farm und
-Zone abzubilden. Die Abbildung von "Load-Managed Application Groups" erfolgt durch die
Objektklasse "Cluster/Application Tier", während sich die Citrix-Installation-Manager-Packages als "
Software Products" abbilden lassen.
Der Citrix-Automationsprozess beginnt durch die Bereitstellung von Serverressourcen in einem
definierten Rechner-Pool. Die Rechner liegen in einem definierten Status der Fertigstellung im Pool
vor. Automationsverfahren sorgen für die Bereitstellung dieses definierten Status (Betriebssystem,
Service-Packs, Patches) als Voraussetzung für die "Pool Membership" (Mitgliedschaft im Pool).
Sobald ein Rechner als Rückläufer aus dem Applikationsumfeld im Pool bereitsteht, kommen die
Workflow-Routinen zur Ausführung, die mit dem Pool-Objekt assoziiert sind. Sie stellen diesen
definierten Status her. In dem Moment, in dem die Engine – sei es manuell, halbautomatisch oder
durch ermittelte Lastkennzahlen automatisch initiiert – eine Ressourcenanforderung identifiziert,
beginnt der Bereitstellungsprozess.
Der erste Schritt umfasst die Installation des Presentation-Server-Frameworks inklusive der
dynamischen Zuordnung zur jeweiligen Serverfarm (variable Farm-Membership) sowie der
Benachrichtigung des Load-Managers. Entsprechende Parametrisierungen bezieht die Engine zur
Laufzeit aus dem DCM. Als Resultat dieses ersten automatisierten Teilprozesses steht der
Citrix-Server als aktives Mitglied der Serverfarm zur Verfügung. Dieses Beispiel zeigt, wie
Unternehmen durch Orchestration und Provisioning einem Hauptziel jeder IT-Abteilung nahe kommen:
der wirtschaftlichen Auslastung vorhandener Ressourcen.
Um einen Server einem Cluster zu entziehen, ist eine Automationsroutine in zwei Phasen
vorgesehen: Die erste Phase sieht ein "Unpublish" der Applikation aus der Load-Managed Application
Group vor. Dies bewerkstelligt eine Workflow-Implementierung der logischen Operation "
SoftwareProduct.Uninstall". Allerdings erfolgt die Deinstallation der Applikation nicht zu diesem
Zeitpunkt, um bestehende Anwender-Sessions weiterhin aufrechtzuerhalten. Dieser Vorgang führt
vielmehr dazu, die Anbindung des Servers an die Load-Managed Application Group zu lösen und zu
verhindern, dass der Load Balancer neue Anwendersitzungen zu diesem Server routet.
Im Anschluss überführt die Automationslösung den Server in einen Staging-Pool, in dem sie ihn
solange vorhält, bis sämtliche Anwender ihre aktiven Sitzungen beendet haben. Die Assoziation in
diesen Staging-Pool ist somit eine Veränderung logischer Assoziationen im Data Center Model. Sie
beinhaltet jedoch den Nebeneffekt, dass die Aktivitäten der Data Acquisition Engine zur Beschaffung
von Lastkennzahlen zum Ende kommt, um potenzielle Bedarfsanfragen zu stoppen.
Nach Beendigung der letzten Anwendersitzung erreicht ein SOAP-Request (Simple Object Access
Protocol) die Deployment Engine. Dieser Request stößt einen Workflow an, um den Rechner aus dem
Staging-Pool in den endgültigen Rechner-Pool zu überführen. Die Automationslösung versieht den
Rechner mit Betriebssystem und entsprechenden Service-Packs, um ihn wieder für die Überführung in
die entsprechenden Serverfarmen bereitzustellen.
Lesen Sie mehr zum Thema
