Cloud Management Platforms – die Lösung für die eigene Cloud?

Viele von uns haben schon einmal eine virtuelle Maschine aus der Cloud bestellt. Man erstellt für sich einen Account, gibt seine Zahlungsdaten ein, sucht eine VM-Größe aus und bestellt. Innerhalb weniger Minuten ist dann eine funktionsfähige Maschine geschaffen, mit der man arbeiten kann. Vergleicht man dies mit den Bereitstellungszeiten für solche Systeme in einem typischen Unternehmen, schneidet das Unternehmen meist schlechter ab. Eine Bereitstellung kann von wenigen Tagen bis zu mehreren Wochen dauern und hängt auch davon ab, wie viel Automatisierung schon umgesetzt wurde.

Genau hier bleibt die Cloud das große Vorbild, doch stellt sich die Frage: Wie kommt man an diesen Punkt? Wie wird man bei der Bereitstellung von Ressourcen so schnell? Eine mögliche Antwort: Eine „Cloud Management Platform“ oder „CMP“.

Lösungen dieser Art, die mittlerweile von einigen Herstellern angeboten werden, versprechen, die eigene Infrastruktur und diverse Clouds unter einen Hut zu bekommen und dabei eine ähnliche User Experience zu bieten wie AWS, Azure und Konsorten. Die verschiedenen Cloud Management Platforms sind sich auf technischer Ebene meist sehr ähnlich, unterscheiden sich manchmal jedoch in Zielgruppe und Fokus. In diesem Artikel sollen allerdings keine Details einzelner Lösungen behandelt werden, sondern die grundsätzlichen Funktionen, um ein generelles Verständnis zu schaffen.

Dabei wird betrachtet, wie eine CMP aufgebaut ist und wie sie funktioniert, inklusive der initialen Einrichtung. Zusätzlich werden die Herstellerversprechen mit der Realität verglichen. Zu guter Letzt wird auch der vielleicht wichtigste Aspekt einer CMP beleuchtet, der von den Herstellern oft weniger stark thematisiert wird: der Betrieb.

Aufbau einer CMP

Der Aufbau einer typischen CMP orientiert sich an der Herangehensweise der großen Cloud-Provider. Es wird ein Werkzeug angestrebt, dass zum Nutzer ein einfaches, intuitives Interface bereitstellt, über das Ressourcen belegt werden können. Dass dies im Hintergrund mehr oder weniger große Anpassungen an der Infrastruktur auslöst, soll für den Nutzer möglichst transparent gestaltet sein.

Zusätzlich möchte man ihm die Möglichkeit geben, einfache Aktionen auszuführen, ohne sich jedes Mal auf der Maschine einloggen oder, noch schlimmer, ein Ticket beim Support erstellen zu müssen, dessen Bearbeitung Tage dauern kann.

Auf Basis dieser Überlegungen teilen sich die meisten CMPs in die folgenden Bereiche auf, die – wie in Abbildung 1 dargestellt – miteinander interagieren:

• Orchestrierung:
  Der Orchestrierungsteil einer CMP bildet das Herzstück. Hier werden Schnittstellen zu anderen Infrastruktur-Komponenten hergestellt und alles eingerichtet, was zur Bereitstellung von Ressourcen benötigt wird. Da es sich dabei um eine Abfolge von verschiedenen Aktionen handelt, bietet sich für diese Abfolgen der Begriff „Workflow“ an. Die Orchestrierung ist auch die Komponente, mit der die Betriebsmannschaft am meisten interagiert, da hier alle wichtigen Informationen eingestellt werden.
• Web-Shop:
  Die Schnittstelle zum technisch ggf. wenig versierten User. Hier wird eine ähnliche Schnittstelle geschaffen wie sie von den großen Cloud-Providern bekannt ist. Man kann Ressourcen bestellen und den Status der Bereitstellung verfolgen.
• Self Service:
  Für die bestellten und bereitgestellten Ressourcen können Aktionen hinterlegt werden, die der Nutzer ausführen kann, ohne dafür die Betriebsmannschaft ansprechen zu müssen (z.B. per Ticket). Darunter können der Neustart eines Systems oder Dienstes oder die Erweiterung der Ressourcen fallen. Ein anderer häufig genutzter Begriff für diesen Self Service ist „Day-2-Operations“ oder „D2O“.
  Bei dieser Aufteilung können sich schon verschiedene Lösungen voneinander unterscheiden. Manche bieten nicht alle Aspekte vollumfänglich an, sondern konzentrieren sich beispielsweise auf die Orchestrierung. In so einem Fall kann der Web-Shop über externe Lösungen realisiert werden. Andere Produkte ziehen bei der Nutzeroberfläche keine klare Grenze zwischen Web-Shop und Self Service. Was ich in der GUI (Graphical User Interface) bestelle, sehe ich dort auch und kann von da aus Aktionen ausführen. Die vorhandenen Funktionen sind allerdings bei allen Anbietern sehr eng verzahnt und meistens von extern über eine RESTful API ihrerseits automatisierbar. So können auch weitere (Komfort-)Funktionen realisiert werden.

Aber wie genau arbeitet eine solche CMP? Und was muss technisch umgesetzt werden, damit sie funktioniert?

Die Funktionsweise einer CMP im Idealfall

In diesem Abschnitt werden die technischen Grundlagen einer CMP dargestellt und die wichtigsten technischen Rahmenbedingungen beschrieben. Dabei wird ein Idealfall angenommen, in dem alle Infrastruktur-Komponenten mit der CMP und miteinander kompatibel sind. Denn eines der großen Werbeversprechen von CMPs ist, dass mit ihnen auch vorhandene Infrastrukturen „cloudifiziert“ werden können. Dass dies in vielen Fällen nicht ganz realistisch ist, wird später noch detaillierter betrachtet.

Damit eine CMP ihren Dienst erweisen kann, muss sie zunächst einmal installiert und eingerichtet werden. Die meisten Lösungen werden von den Herstellern in Form von virtuellen Appliances bereitgestellt, für die schon vorhandene Infrastruktur genutzt werden kann. Zuerst wird also eine Reihe virtueller Maschinen mit allem, was dazu gehört, installiert:

• Reservierung von Ressourcen, v.a. CPU und RAM:
  Die Lösungen benötigen zwar nicht übermäßig viele Ressourcen, aber dieser Punkt muss trotzdem beachtet werden. Da eine (in Zukunft) so zentrale Komponente wie eine CMP auch ausfallsicher sein sollte, müssen evtl. zusätzliche Ressourcen für einen Active/Active- oder Active/Passive-Cluster bereitgestellt werden.
• Konfiguration von Netzen:
  Die Netze (und die Firewall, s.u.) müssen so konfiguriert werden, dass die CMP-Lösung alle relevanten Infrastruktur-Komponenten erreichen kann. Dies beinhaltet Dinge wie Virtualisierung, Netzwerk-Switches, Firewalls etc.
• Einrichtung von Firewall-Freischaltungen:
  Auf Firewall-Seite sind ebenfalls häufig Anpassungen notwendig. Möchte man beispielsweise auch in der Cloud Systeme bereitstellen, müssen Verbindungen ins Internet möglich sein. Bei einem segmentierten Netzwerk kommen noch entsprechende Freischaltungen hinzu, um alle Komponenten zu erreichen.

Diese Voraussetzungen zu schaffen, kann bereits eine Herausforderung sein. Und die Vorbereitungen sollten gut geplant und dokumentiert werden. Ansonsten kann es schnell zu diffusen und schwer analysierenden Fehlerbildern kommen, in denen manche Funktionen der CMP wunderbar funktionieren und andere aus unerfindlichen Gründen scheitern. Oder noch schlimmer: mal funktioniert es und mal nicht!

Wenn die Appliances laufen, ist erstmal nicht viel erreicht. Denn noch kann die CMP nichts tun, da sie ihre Umgebung nicht kennt (s. Abbildung 2). In einem nächsten Schritt müssen alle relevanten Komponenten sowie die nötigen Konfigurationsänderungen geplant und umgesetzt werden, damit die CMP auf alles zugreifen sowie Informationen abfragen kann. Ersteres umfasst sämtliche Komponenten, die für die (automatisierte) Bereitstellung von Ressourcen benötigt werden. Letzteres umfasst beispielsweise ein Active Directory oder andere zentrale Nutzerdatenbanken, über die Berechtigungen vergeben werden.

Es werden also CMP-spezifische Nutzer eingerichtet, die korrekten Rechte vergeben, APIs freigegeben, Plug-ins installiert und viele weitere kleine und große Änderungen an verschiedenen Stellen durchgeführt und dokumentiert, damit die CMP ihre Arbeit optimal erledigen kann – grob dargestellt in Abbildung 3.

Natürlich wäre es einfacher, alle Systeme in ein flaches Netz einzubinden und auf der CMP für jede Komponente den Administrator-User zu hinterlegen. Doch das ist aus Sicherheitsgründen keine gangbare Möglichkeit! Und neben der Sicherheit leidet auch das Troubleshooting enorm, wenn immer nur der Administrator-User zugreift und man nicht unterscheiden kann, wann es ein Mensch war und wann die CMP!

Nach Anpassung der vorhandenen Infrastruktur wird die CMP so konfiguriert, dass alle notwendigen Komponenten angesteuert werden können. Dazu werden unter anderem die erstellten Nutzer in der CMP eingetragen, notwendige Plug-ins installiert und eingerichtet usw. (s. Abbildung 4). Und natürlich nicht zu vergessen: Die Änderungen sollten auch getestet werden. Manche CMPs erledigen das bereits bei der Einrichtung; ohne einen erfolgreichen Test lässt sich eine Konfiguration nicht abschließen. Bei anderen Lösungen müssen diese Tests separat gestartet werden.

Auf Basis der nun funktionierenden Integrationen werden die Ressourcen eingerichtet, die ein Nutzer später bestellen kann (s. Abbildung 5). Dies umfasst eine ganze Reihe von Arbeitsschritten, die durchzuführen sind, und Informationen, die hinterlegt werden müssen:

• Erstellung von Templates, die ein User bestellen kann, und den Workflows, die für die Bereitstellung abgearbeitet werden müssen
• Zuweisung von Templates zu Nutzern oder Nutzergruppen, meistens über die Nutzung von Active-Directory-Gruppen
• Bepreisung der bestellbaren Ressourcen
• Einrichtung von Genehmígungsprozessen, damit nicht jeder Nutzer beliebig viele Ressourcen ohne Freigabe bestellen kann

Der letzte Punkt ist übrigens einer der größten Unterschiede zu Public-Cloud-Providern: Intern müssen solche Bestellungen meistens abgesegnet werden; große Cloud-Provider gehen davon aus, dass das schon vorher erledigt wurde!

Nach all dieser Arbeit für die Administratoren ist jetzt die Stunde der Nutzer gekommen: Alles ist eingerichtet und Nutzer können virtuelle Maschinen bestellen (s. Abbildung 6). Dazu wird der Web-Shop genutzt, der dann im Hintergrund die Orchestrierung ansteuert. Diese wiederum führt die hinterlegten Workflows aus, wie in Abbildung 7 dargestellt. Im Englischen würde man sagen: „This is where the magic happens!“ Es kann zwar auch eine Genehmigung notwendig sein, bevor die Orchestrierung übernimmt. Jenseits solcher Genehmigungen geht dann jedoch alles relativ schnell – es wurde ja schon alles automatisiert!

Sollte ein Nutzer zu einem späteren Zeitpunkt noch einmal Änderungen an seiner Maschine vornehmen oder diese ohne großen Aufwand neustarten wollen, kommt der Self Service ins Spiel, wie in Abbildung 8 dargestellt. Im Hintergrund wird wieder die Orchestrierung angesteuert, die die notwendigen Changes umsetzt.

Das alles klingt sehr vielversprechend, sobald man die initiale Einrichtung einmal abgeschlossen hat: Die Nutzer können einfache Ressourcen bestellen, diese werden schneller bereitgestellt und die Administratoren müssen weniger bis gar keine manuellen Prozesse abarbeiten. Also ist alles mit einer CMP viel besser und einfacher? Wenn man den Herstellern glaubt, dann ja…

Die Herstellerversprechen

Glaubt man den Marketing-Materialien und den Vertretern der CMP-Hersteller, ist das oben dargestellte Idealbild grundsätzlich immer und bei allen Kunden erreichbar. Die größten und für die Kunden wichtigsten Versprechen dabei sind:

• Es werden alle erdenklichen Produkte und Hersteller unterstützt, sowohl On-Prem als auch in der Cloud. Sobald man eine Kopplung zwischen CMP und einer anderen Komponente hergestellt hat, geht alles ganz einfach!
• Die Erstellung von Workflows und Templates ist simpel und intuitiv. Die Oberflächen sind selbsterklärend. Man kann sich alles in einer GUI per Drag-and-drop-Technik zusammenstellen oder auch programmieren.
• Auch für den Nutzer ist alles einfach und selbsterklärend.
• Die Automatismen beschleunigen die Bereitstellung um Größenordnungen gegenüber den alten, manuellen Prozessen.
• Die Nutzer sehen automatisch die Kosten für die benötigten Ressourcen im Allgemeinen auch, wie in der Cloud, pro Monat.
• Der Betrieb wird viel einfacher und die bisher mit dem Alltagsgeschäft ausgelasteten Administratoren können sich Innovationsprojekten widmen, um die Konkurrenzfähigkeit des Unternehmens zu verbessern.

Doch wie so häufig bei Herstellerversprechen, ist das alles nur unter optimalen Voraussetzungen und ansatzweise realistisch. Entscheidend hierfür sind einerseits die schon vorhandene Infrastruktur sowie die vertretenen Hersteller und andererseits die schon eingespielten Prozesse und Verantwortlichkeiten. Um diesen Unterschied ein wenig deutlicher zu machen, werden im Folgenden zwei Szenarien betrachtet: Die Einführung einer CMP in einer bereits bestehenden, „historisch gewachsenen“ Infrastruktur oder (inkl. der Neubeschaffung aller anderen Komponenten) „auf der grünen Wiese“.

Eines vorweg: Die Versprechen der Hersteller umfassen nicht, dass die Workflows und Templates immer wieder an die Bedürfnisse der Nutzer angepasst werden müssen. Diese Template- und Workflow-Erstellung ist kein „Fire and Forget“, sondern bedarf einer regelmäßigen Pflege und Optimierung. Ein guter Teil des Aufwands, den man sich durch die Automatisierung sparen kann, geht in diese Pflege. Der Vorteil: Man bietet den Nutzern eine bessere User Experience.

Die CMP in bestehenden Umgebungen

In den meisten Fällen soll eine CMP dabei helfen, die schon vorhandene Infrastruktur näher an die Funktionsweise einer Public Cloud zu bringen. Dabei sind die meisten Komponenten und das Know-how zur Nutzung aller Systeme vorhanden. Die Administratoren wissen ganz genau, was ihre Switches, ihr Storage, ihre Virtualisierungslösungen und ihre Firewalls können. Also muss die CMP damit leben, was da ist.

Und hier kommt das erste Versprechen der Hersteller, die umfassende Unterstützung von „allem“, sehr schnell an seine Grenzen. Meistens sind out of the box nur die großen Hersteller in der CMP unterstützt, z.B. Cisco bei den Netzwerk-Switches oder Infoblox als IP Address Management (IPAM). Sind spezialisierte Tools für die eigene Umgebung von weniger präsenten Herstellern im Einsatz, muss man mit einem erheblichen Aufwand rechnen, diese in die CMP einzubinden. Im optimalen Fall gibt es fertige Plug-ins vom Dritthersteller oder aus der Community. Oder es existiert die Möglichkeit, REST-API-Calls für die Workflows und Templates zu definieren, die dann die externe Komponente steuern. Im schlimmsten Fall müssen eigene Plug-ins für die CMP von der eigenen Mannschaft oder vom Hersteller entwickelt werden. Doch in jedem Fall benötigt man hierfür Zeit und Geld.

Ein weiterer Punkt: Wenn bereits bestimmte Workflows in vorhandenen Tools vorgesehen sind, z.B. für die Installation und Konfiguration von Betriebssystemen, dann ergibt sich eine weitere Herausforderung für die Anbindung der bestehenden Infrastruktur: Entsprechen die schon existierenden Workflows der Philosophie der CMP-Lösung? Wenn ja, ist alles in Ordnung, aber wenn nicht, wird man sich auf kurz oder lang entscheiden müssen:

• Man bringt der CMP diese Workflows bei und lebt ggf. mit den Einschränkungen.
• Auf Dauer werden die bisherigen Workflows durch die CMP-freundlicheren abgelöst. Dabei kann Know-how einschlafen, und man bindet sich stärker an den CMP-Hersteller.

Sollte dann eine Komponente aktualisiert oder ausgetauscht werden, entsteht wieder Aufwand: Bei einem Update muss man überprüfen, ob die bisherige Integration durch das Update beeinträchtigt wird. Es stellen sich unter anderem die Fragen:

• Hat sich ein REST-API-Aufruf verändert?
• Gibt es neue Berechtigungsstufen für Nutzer?

Bei einem Austausch einer Komponente ist der Aufwand zwar auch signifikant, doch kann man die Einführung eines neuen Produkts besser auf die CMP abstimmen. Der Hersteller kann nach der Kompatibilität mit der CMP gewählt und die Nutzung des neuen Systems so gestaltet werden, dass sie besser mit der CMP zusammenarbeitet.

Zusätzlich müssen bei der initialen Installation und Konfiguration der Umgebung viele Seiteneffekte und Prozesse betrachtet werden. Wie schon erwähnt, können hier auch kleine Fehler und Unachtsamkeiten zu sehr interessanten Fehlerbildern führen.

Das heißt zusammengefasst: Technisch gesehen unterstützen die meisten CMPs wirklich alle möglichen Dritthersteller-Komponenten. Die Information, dass die Anbindung teilweise mit erheblichem Aufwand für die Administratoren verbunden ist, bleibt dabei jedoch auf der Strecke.

Was die intuitiven Oberflächen angeht: Hier sieht es am Markt nicht schlecht aus. Sobald man sich einmal an ein paar Eigenheiten einer Lösung gewöhnt hat und die grundlegende Philosophie versteht, geht die Arbeit bei der Workflow-Erstellung wirklich leichter von der Hand. Und diese Eingewöhnung gibt es eigentlich bei jeder neuen Technologie und jedem neuen Hersteller, dessen Produkte man in seiner Umgebung einsetzt. Für den Nutzer sind die Oberflächen meistens auch einfach zu verstehen. Es ist ggf. nicht ganz so einfach wie bei den großen Cloud-Providern, und vielleicht erhält man mehr technische Informationen als man benötigt, doch meistens ist eine Bestellung dann auch nicht komplizierter als der evtl. eingesetzte bisherige Antrag per Formular oder eigener Web-Oberfläche mit Anbindung an ein Ticket-System.

Auf der Betriebsseite existieren häufig die größten Abweichungen von den Herstellerversprechen. Gerade in Umgebungen mit streng getrennten Verantwortlichkeiten („Silos“) ergeben sich ganz neue Herausforderungen, die weiter unten noch einmal detailliert beschrieben werden.

Bei den Prozessen gibt es eine weitere Hürde, die hier thematisiert werden soll: Das Versprechen der vollständigen Automatisierung aller Infrastrukturkomponenten ist in bestehenden Strukturen meistens nicht haltbar. Eine Firewall-Freischaltung, vollkommen automatisiert und ohne Überprüfung der Konsequenzen durch Fachleute? Bei den meisten Kunden in bestehenden Umgebungen undenkbar! Also müssen vorhandene, manuelle Prozesse auf irgendeine Art und Weise mit der eigentlich auf vollständige Automatisierung ausgelegten CMP verheiratet werden. Hier gibt es Möglichkeiten. Ich kann beispielsweise ein Ticket-System anbinden (wobei die Anbindung natürlich auch nicht ohne Aufwand einzurichten ist) oder einen Genehmigungsprozess einbauen, der im Hintergrund den Durchlauf eines ggf. langwierigen, manuellen Prozesses auslöst. Wenn dann der manuelle Prozess abgeschlossen ist, wird das Ticket geschlossen oder die Genehmigung erteilt, und die CMP fährt mit ihrer Arbeit fort. Damit kann aber einer der größten Vorteile der CMP ad absurdum geführt werden: die hohe Geschwindigkeit durch Automatisierung.

Anders sieht es aus, wenn ich eine vollständig neue Umgebung aufbaue und diese automatisieren möchte:

Die CMP auf der grünen Wiese

Baut man eine neue (unabhängige) Umgebung auf und will diese „wie eine Cloud“ betreiben, so können die Herstellerversprechen leichter umgesetzt werden. Es ist möglich, die CMP und die übrigen, einzusetzenden Komponenten so aufeinander abzustimmen, dass die Kopplung über schon vorhandene Funktionen oder Hersteller-Plug-ins abgewickelt werden kann, ohne dass viel Arbeit in Eigenentwicklungen und Prozessoptimierungen gesteckt werden muss. Es gibt durchaus Hersteller, prominentestes Beispiel ist VMware, die alle notwendigen Technologien mitbringen und auch eine CMP anbieten. In diesem Fall arbeiten Virtualisierung, Software-Defined Storage und Software-Defined Networking natürlich Hand in Hand und bieten ein „Rundum-Glücklich-Paket“. Die Kosten dafür machen dann jedoch nicht mehr ganz so glücklich – besonders in großen Umgebungen.

Hinzu kommt, dass bestimmte Best Practices im Bereich der Sicherheit, wie z.B. die Trennung der DMZ durch dedizierte Firewalls verschiedener Hersteller, eine Ein-Hersteller-Lösung illusorisch machen. Man muss sich also damit auseinandersetzen, dass die geplanten Komponenten miteinander kompatibel sind.

Im Bereich der Automatisierung bringt eine komplett neue Umgebung auch viele Vorteile: Es muss sich zum Beispiel nicht um Seiteneffekte auf vorhandenen Systemen gesorgt werden. Das vielleicht relevanteste Beispiel im Bereich eines Rechenzentrums ist die Firewall. Wenn man mit einem leeren Regelwerk anfängt, ist eine Automatisierung viel einfacher und weniger fehleranfällig. Das heißt zwar nicht, dass nicht zumindest überprüft werden sollte, ob eine Regel sinnvoll und aus Sicht der Sicherheit unbedenklich ist, doch kann hier ein einfacher Genehmigungsprozess ohne manuelle Arbeiten zu einer deutlichen Beschleunigung beitragen.

Unabhängig davon, in welcher Umgebung ich ein CMP einsetze: In jedem Fall bleibt der Betrieb einer CMP eine enorme Herausforderung und sollte im Detail betrachtet werden.

Der Betrieb einer CMP-Lösung – der interessanteste Aspekt

Dadurch, dass eine CMP-Lösung schreibenden Zugriff auf eine Vielzahl sehr unterschiedlicher Komponenten benötigt, werden viele Verantwortungsbereiche durch die Einführung einer CMP berührt. Geht man von klassischen, getrennten Verantwortungsbereichen, also von „Silos“ aus, sind mindestens die folgenden Bereiche von der CMP berührt:

• Virtualisierung:
  Da die meisten per CMP bereitgestellten Systeme virtuell sind, gibt es zwangsläufig einen sehr starken Eingriff in den Bereich Virtualisierung. Nicht alle Personen aus diesem Bereich werden begeistert sein, wenn auf einmal Maschinen erscheinen und verschwinden, von denen sie noch nicht einmal genau wissen, wem sie gehören und was sie machen. Auf der anderen Seite sind CMPs häufig durch die Abteilung Virtualisierung getrieben, so dass diese Schnittstelle nicht immer betrachtet werden muss.
• Netzwerk:
  In diesem Bereich ist das Konfliktpotential nicht zu vernachlässigen. Wenn die Netzwerk-Abteilung nicht von vornherein über die CMP Bescheid weiß, können Bedenken und Missverständnisse auftreten, da sich diese Abteilung übergangen fühlen kann.
• Storage:
  Der Einfluss auf bereits bestehende Speicherlösungen kann sehr unterschiedlich ausfallen. In den meisten Kundenprojekten wurde ein schon bestehender Storage auch für die durch die CMP provisionierten Systeme genutzt, ohne dass Anpassungen notwendig waren. In diesem Fall besteht wenig Konfliktpotential. Wenn die CMP aber auch dazu genutzt wird, Speicherressourcen auf den Storage-Systemen zu konfigurieren, z.B. indem LUNs eingerichtet werden, ist auch hier eine enge Koordination sinnvoll.
• Firewall:
  Sowohl aus Sicht der IT-Sicherheit als auch für die Gewährleistung der Verfügbarkeit von Systemen und Diensten (sowohl bestehende als auch durch die CMP erstellte) bildet die Firewall eine kritische Komponente. Sollte durch eine Automatisierung die Verbindung zu einem wichtigen System nicht möglich sein, kann dies zu großen Einschränkungen für viele Mitarbeiter führen. Aus diesem Grund sind hier häufig die meisten Bedenken gegenüber einer Automatisierung zu finden. Es ist dann auch meistens der Punkt, an dem auf eine umfassende Automatisierung verzichtet und eher manuelle Prozesse vorgesehen werden. In jedem Fall müssen die Firewall-Verantwortlichen für einen erfolgreichen CMP-Einsatz involviert sein.

Genau diese Herausforderungen kommen immer wieder dann zum Tragen, wenn es um die Konsolidierung und Automatisierung von Infrastruktur geht. Bei der initialen Beschreibung der CMP wurde dieser Punkt explizit vernachlässigt. Färbt man die Komponenten der Umgebung (s. Abbildung 2) gemäß ihrer Aufteilung in Silos ein, ergibt sich beispielsweise die in Abbildung 9 dargestellte Situation. Geht man dabei davon aus, dass die CMP als eigenes Silo angesehen wird, entsteht bei jeder Aktion und jedem Workflow aus der CMP heraus ein Eingriff in andere Abteilungen, wie in Abbildung 10 dargestellt. Wenn in jedem dieser Fälle ein manueller Prozess oder auch nur eine Genehmigung benötigt wird, kann sich die Bereitstellung durch die CMP deutlich verzögern.

Diese Auswirkungen auf Prozesse und Teamstrukturen wurden im Netzwerk Insider bereits bei den Themen VMware NSX [1] und hyperkonvergente Infrastrukturen [2] betrachtet. Daher wird hier auf eine detaillierte Darstellung verzichtet und auf die Betriebskapitel dieser Artikel verwiesen. Als Zusammenfassung ergibt sich, dass Silos abgebaut und durch gemeinsame, breit aufgestellte Teams ersetzt oder ergänzt werden sollten.

Bei einer CMP werden das Aufbrechen von Silos und die Automatisierung jedoch auf die Spitze getrieben, zumindest, wenn man das Potential voll ausschöpfen will. Dies ist beispielhaft in Abbildung 11 dargestellt.

Das heißt: Es sollte nur ein „gemeinsames“ CMP-Team geben, das sich auch mit allen anderen Bereichen befasst. Hier empfiehlt es sich, dass die Mitglieder dieses Teams ein Grundverständnis für alle relevanten Themen mitbringen und jeweils Detailwissen zu bestimmten Aspekten haben. Dabei kann es in bestehenden Umgebungen sinnvoll sein, ein solches Team aus Mitgliedern der jeweiligen Bereiche zusammenzustellen, ggf. zunächst „virtuell“, um Know-how-Transfer zu ermöglichen und die Konsequenzen einer CMP-Einführung gemeinsam zu planen.

Werden die klassischen Strukturen beibehalten, werden viele der Vorteile einer CMP durch manuelle Prozesse und abteilungsübergreifende Kommunikation wieder zunichtegemacht.

Doch selbst mit einem optimalen Team hat sich in Kundenprojekten gezeigt: Der Aufwand für den Betrieb einer solchen Lösung wird nicht weniger, sondern die Art der Arbeiten verschiebt sich. Weg vom Alltagsgeschäft, hin zu einer Optimierung der für den User verfügbaren Ressourcen und der dahinterstehenden Automatisierung. Damit kann den Nutzern bei gleichem Aufwand eine wesentlich bessere Nutzererfahrung geboten werden, die näher an „der Cloud“ ist.

Fazit

Eine Cloud Management Platform stellt eine Technologie dar, die auf viele Bereiche im eigenen Rechenzentrum Einfluss hat. Wenn man sich darauf einlässt, kann eine CMP sehr viele Vorteile, besonders bei der Bereitstellungsgeschwindigkeit von Systemen, bringen. Es ist also möglich, seinem Ziel, die eigene Infrastruktur „wie die Cloud“ zu nutzen, deutlich näherzukommen.

Auf der technischen Ebene bildet die CMP ein Bindeglied zwischen verschiedenen Bereichen und eventuell schon vorhandenen Tools. Dazu werden weitverbreitete Mechanismen wie REST-APIs genutzt, die jedoch in einer zentralen Lösung unter einer einheitlichen Oberfläche zusammengebracht werden.

Die Herausforderungen auf der technischen Seite liegen primär in der Auswahl des richtigen Herstellers. Dabei sollte die Kompatibilität der schon vorhandenen Werkzeuge überprüft werden, sodass so wenige eigene Anpassungen wie möglich notwendig sind. Dazu gehört auch die Recherche von Plug-ins aus verschiedenen Quellen sowie der Verfügbarkeit und Dokumentation von Schnittstellen. Dies mag erst einmal simpel klingen, ist aber typischerweise mit einer gründlichen Marktsichtung und einem ebenso gründlichen Proof of Concept verbunden.

Der Betrieb einer CMP ist die deutlich größere Herausforderung. Klassische Silos geraten hier schnell an ihre Grenzen, doch wenn sie aber bereits jetzt gut zusammenarbeiten und gemeinsam an einem Strang ziehen, kann eine CMP beim Abriss von Silos oder Mauern behilflich sein. Auf Dauer ergeben sich Vorteile für alle Beteiligten:

• Die Administratoren können sich auf Optimierungen konzentrieren und müssen nicht so viel Zeit mit der Umsetzung klassischer Anforderungen verbringen.
• Die Nutzer erhalten ihre benötigten Systeme und Ressourcen schneller und können flexibler damit umgehen.

Verweise

[1] M. Ermes, „VMware NSX und Mikrosegmentierung in Theorie und Praxis,“ Der Netzwerk Insider, Nr. Juli, 2019.

[2] C. Höchel-Winter und M. Ermes, „Konsolidierung im Rechenzentrum weitergedacht – Converged und Hyperconverged Infrastructure“ Der Netzwerk Insider, Nr. Oktober, 2019.