Aufbau einer Enterprise Cloud mit F5 und IBM

Einigen Schätzungen zufolge wird die Enterprise Cloud – auch als Private Cloud bekannt – schneller angenommen als die Public Cloud. Das Unternehmensberatungsunternehmen Accenture geht davon aus, dass die Private Cloud-Durchdringung in Unternehmen bis Ende 2011 bei 77 Prozent liegen wird.¹ Dieser schnelle Trend zur Schaffung einer flexiblen Infrastruktur vor Ort geht vor allem auf die Notwendigkeit zurück, dass die IT-Abteilungen großer und kleiner Unternehmen die Kontrolle und Verwaltung sowohl der Infrastruktur als auch der Daten intern behalten müssen.

Wenn die Entscheidung zur Einführung einer Cloud-Infrastruktur gefallen ist, läuft die Wahl zwischen intern/privat und extern/öffentlich auf eine Analyse von Kosten, Risiken und Nutzen hinaus. Eine öffentliche Cloud bietet normalerweise einen flexiblen Ansatz und die größten Kosteneinsparungen, birgt jedoch auch Risiken im Zusammenhang mit Sicherheit, Service-Level-Agreements (SLAs), Verfügbarkeit und Verwaltung. Die IT kann bei geringen Einstiegskosten von nahezu unbegrenzten Skalierbarkeit profitieren, verliert dabei jedoch die Kontrolle. Der Umzug von einem herkömmlichen Rechenzentrum vor Ort oder einem gehosteten Rechenzentrum in eine externe öffentliche Cloud ist im Grunde so, als würden Sie Ihr gesamtes Rechenzentrum in die Hände einer anderen Person legen.

Mit einer Enterprise Cloud verfügt die IT über das erforderliche Maß an Kontrolle und vermeidet die mit einer öffentlichen Cloud verbundenen Risiken. Die Bereitstellung einer privaten Cloud ist jedoch teurer, erfordert zusätzliches Wissen und Fachwissen seitens der Mitarbeiter und erhöht die Komplexität des Rechenzentrums vor Ort. Die Cloud-Infrastruktur des Unternehmens lässt sich nach Bedarf skalieren und bietet dynamische Bereitstellung und Agilität. Mit dieser Skalierbarkeit und Kontrolle sind jedoch häufig höhere Einstiegskosten verbunden.

Gemeinsam haben F5 Networks® und IBM eine Referenzarchitektur für die Unternehmens-Cloud entwickelt, die viele der mit der Komplexität verbundenen Herausforderungen lindert. Es bringt viele der Architektur- und Skalierungskomponenten einer öffentlichen Cloud vor Ort mit, um die Kosten für den Aufbau eines internen Stückwerksystems erheblich zu senken. Durch die Vordefinition der erforderlichen Komponenten und die Beschreibung der Zusammenarbeit dieser Komponenten haben F5 und IBM eine vollständige, dynamische und agile Enterprise-Cloud-Infrastruktur geschaffen.

Das wichtigste Element eines On-Demand-Bereitstellungssystems ist die Fähigkeit, ereignisbasierte Entscheidungen zu treffen und Maßnahmen zu ergreifen. Ein Ereignis irgendwo im System erzeugt einen Alarm oder eine Nachricht, die von einer Komponente (entweder einer, die den Nachrichtenbus abonniert hat, oder einer, die direkt über einen API-Aufruf angefordert wurde) abgerufen wird, die dann auf diese Nachricht reagiert. Der Arbeitsablauf ist der Prozess und die Reihenfolge, in der Komponenten auf Systemnachrichten reagieren.

In einer Unternehmens-Cloud gliedert sich der Workflow typischerweise in Bereitstellungskomponenten, die Ressourcen entweder anfordern oder freigeben, und die erforderlichen Schritte zur Verwaltung der Ressourcenzuweisung. Wenn eine virtuelle Maschine (VM) zusätzliche CPU-Ressourcen benötigt, wird ein Workflow gestartet, um zu bestimmen, woher diese CPU-Ressourcen kommen, eine neue VM zu starten, eine IP-Adresse zuzuweisen usw.

Die Enterprise-Cloud-Architektur von F5 und IBM basiert auf zwei wichtigen Grundsätzen:

1. Es gibt einen zentralen Nachrichtenbus zum Übertragen von Ereignisbenachrichtigungen, und alle Komponenten, die auf Ereignisse reagieren müssen, sind an den Bus gebunden.

Über diese beiden Prinzipien hinaus ist die Referenzarchitektur von F5 und IBM äußerst formbar, was bedeutet, dass sie in jedes vorhandene Rechenzentrum oder jede vorhandene Cloud-Architektur passt. Wenn beispielsweise bereits eine Orchestrierungs-Engine zum Verwalten der VM-Bereitstellung vorhanden ist, kann diese Referenzarchitektur angepasst werden, sodass die vorhandene Engine verwendet werden kann. Ein Missverständnis im Zusammenhang mit dem Aufbau einer Unternehmens-Cloud besteht darin, dass die gesamte Infrastruktur ersetzt werden muss. Die Lösung von F5 und IBM wurde entwickelt, um sich bei jedem möglichen Schritt in vorhandene Komponenten zu integrieren.

Unabhängig davon, welche Komponenten bereits vorhanden und welche neu sind, besteht der Enterprise-Cloud-Workflow aus bestimmten Komponenten, die bestimmte Aufgaben ausführen. Das gesamte Cloud-System besteht aus diesen einzelnen Komponenten, die zusammenarbeiten, um die komplette Cloud-Infrastruktur bereitzustellen. Diese Infrastruktur wird durch Komponenten-Workflows betrieben und gesteuert – koordinierte Aufgaben, die ein Cloud-Ereignis verwalten.

Der Nachrichtenbus ist das System, das ereignisbasierte Nachrichten und Warnungen an die einzelnen betroffenen Komponenten übermittelt. Wenn ein Ereignis eine Nachricht auslöst, wird diese Nachricht über den Nachrichtenbus an eine bestimmte Komponente gesendet, die über Regeln verfügt, was mit dieser Nachricht zu tun ist. Der Nachrichtenbus ist außerdem für die Normalisierung von Nachrichten basierend auf Regeln für bestimmte Komponenten verantwortlich.

Die Referenz-Cloud-Architektur von F5 und IBM verwendet die IBM Tivoli Netcool OMNIbus-Lösung als zentralen Nachrichtenbus. Allerdings kann jeder beliebige Unternehmensnachrichtenbus verwendet werden, um Ereignisbenachrichtigungen im gesamten System zu übermitteln.

Man kann sich den Orchestrator als das Gehirn der Unternehmens-Cloud vorstellen – die Komponente, die für die meisten Entscheidungen zur Makrobereitstellung auf der Grundlage von über den Bus empfangenen Nachrichten verantwortlich ist. Der Orchestrator wird wichtige Ereignisse und Workflows in der Cloud-Architektur anstoßen, beispielsweise den Start des Workflows „Neue virtuelle Maschine bereitstellen“. Der Orchestrator ist außerdem dafür verantwortlich, die für jeden Workflow erforderlichen Daten abzurufen und sie den entsprechenden Komponenten bereitzustellen. Beispielsweise stellt der Orchestrator die zum Bereitstellen einer neuen VM erforderlichen IP-Adressinformationen bereit.

Für die Referenzarchitektur wird der Orchestrator mithilfe einer Reihe interpretierter Skripts erstellt, die auf Nachrichten vom Bus reagieren und Workflow-Ereignisse starten. Es kann jeder beliebige Orchestratortyp verwendet werden, etwa IBM Tivoli Intelligent Orchestrator, HP Operations Orchestration oder VMware vCenter Orchestrator.

Der Cloud-Controller ist das Front-End-System, das für die Erfassung und Aggregierung der vorläufigen Daten verantwortlich ist, die zum Starten eines Bereitstellungsprozesses erforderlich sind. Diese Informationen werden zunächst im Rahmen des Erstellungsprozesses von einem Administrator bereitgestellt und sind für jeden Workflowtyp spezifisch, der für die Bereitstellung verwendet wird. Beispielsweise erfasst der Cloud-Controller Informationen wie den VM-Standort, die Application (Webserver, Datenbankserver, Mailserver usw.) und den Mindestressourcenbedarf.

Während eines automatisierten Bereitstellungsereignisses und nachdem diese vorläufigen Daten bereits im System gespeichert wurden, fordert der Orchestrator die vorhandenen Informationen an und extrahiert sie, um den Bereitstellungsworkflow zu starten. Beispiele für Cloud-Controller sind Eucalyptus Cloud Controller, VMware vCloud Director oder Amazon EC2. Für zukünftiges Wachstum und die Erweiterbarkeit auf andere Cloud-Plattformen empfiehlt es sich, einen Cloud-Controller auszuwählen, der entweder einen Standardsatz von Cloud-APIs integrieren oder mit diesen kommunizieren kann. Dadurch kann der Cloud-Controller auf einen öffentlichen oder hybride Cloud Anbieter erweitert werden, ohne dass eine Neustrukturierung der Cloud-Plattform des Unternehmens erforderlich ist.

Der Cluster-Controller ist die Komponente in der Unternehmens-Cloud, die für die Verwaltung der bereitgestellten virtuelle Maschine sowie des zum Ausführen der VM erforderlichen Speichers und der Metadaten verantwortlich ist. Als VM-Ausführungsumgebung umfasst der Cluster-Controller den virtuellen Plattform-Hypervisor und kann auch die größere Hypervisor-Verwaltungsumgebung umfassen. Der Cluster-Controller kann beispielsweise ein einfacher Hypervisor wie VMware ESXi oder eine größere Sammlung verteilter Hypervisor-Systeme wie VMware vSphere oder VMware vCloud sein.

Die Integritäts- und Statusüberwachung ist ein wesentlicher Bestandteil der Bereitstellung jeder Application . Durch die Überwachung werden auch Statusaktualisierungen für Bereitstellungssysteme bereitgestellt, beispielsweise wenn eine virtuelle Maschine aktiv ist und auf Verbindungen im Netzwerk reagiert. Durch die kontinuierliche Überwachung des Systems können Echtzeitwarnungen bereitgestellt werden, die letztlich in neue Arbeitsabläufe einfließen und Bereitstellungsentscheidungen beeinflussen. Bei der Bereitstellung einer Unternehmens-Cloud kann jede Komponente verwendet werden, die den Application und Netzwerkstatus überwachen kann. In der Referenzarchitektur von F5 und IBM wird jedoch die IBM Tivoli Monitoring-Software verwendet.

Das Domain Name System (DNS) spielt in der Enterprise-Cloud-Referenzarchitektur von F5 und IBM eine entscheidende Rolle: Es ist nicht nur für die Speicherung der IP- und Domänennameninformationen für IPv4 und IPv6 verantwortlich, sondern auch für die Speicherung von Systemmetadaten, wie etwa der vom Cloud-Controller erfassten Informationen und eindeutigen Maschinenidentifikationsinformationen. Für diese Referenzarchitektur wurde DNS als Speicherort für Metadaten gewählt, da es sich dabei um ein standardbasiertes System handelt, das in den meisten Netzwerken bereits vorhanden ist, allen Cloud-Komponenten zur Verfügung steht und die Notwendigkeit des Hinzufügens zusätzlichen datenbankartigen Speichers zur Infrastruktur überflüssig macht. Es kann jede DNS-Lösung verwendet werden, die von der IT verwaltet wird und die Möglichkeit bietet, zusätzliche Zonen und Zonendateien hinzuzufügen.

Bei der Referenzarchitektur von F5 und IBM führt der Cluster-Controller die virtuelle Maschine vom lokalen Speicher aus aus. Wenn die Maschine jedoch nicht ausgeführt wird, befindet sich die virtuelle Festplatte der VM auf einem virtualisierten Speicher. Während eines Workflow-Bereitstellungsereignisses fordert der Cluster-Controller die virtuelle Festplatte über das Network File System (NFS) vom virtuellen Speichergerät an.

Die letzte Komponente in der Unternehmens-Cloud ist der Application Delivery Controller (auch als Load Balancer bezeichnet), der in der Referenzarchitektur von F5 und IBM der F5® BIG-IP® Local Traffic Manager™ (LTM) ist. BIG-IP LTM verwaltet Verbindungen, Dienste und die Bereitstellung der Application , die von der virtuelle Maschine kommen. Letztlich ist BIG-IP LTM der letzte Teil des Systems, der auf ein Workflow-Bereitstellungsereignis reagiert.

Das Ziel der Enterprise-Cloud-Referenzarchitektur von F5 und IBM besteht darin, eine praxisnahe, ressourcenbasierte Plattform für die dynamische Bereitstellung von Applications bereitzustellen. Sobald alle Komponenten vorhanden sind, arbeiten sie über verschiedene Arbeitsabläufe zusammen, um bei Bedarf neue Application bereitzustellen. Es gibt zwei Möglichkeiten zum Bereitstellen von Systemen, die in der Unternehmenscloud vorhanden sind: manuelle Bereitstellung und automatisierte Bereitstellung.

Normalerweise wird der erste Workflow in der Unternehmens-Cloud durch einen manuellen Prozess initiiert, der auf Eingaben des Systemadministrators oder Application basiert. Dies bedeutet nicht, dass der Arbeitsablauf manuell erfolgt. Lediglich die erstmalige Eingabe von Informationen in das System erfolgt manuell. Sobald die Daten vom Administrator erfasst wurden, startet das System vordefinierte automatisierte Workflow-Ereignisse zur Application .

Über die GUI des Cloud-Controllers gibt der Administrator (oder der Application , je nachdem, wer für das Starten eines neuen Bereitstellungsereignisses verantwortlich ist) die erforderlichen Informationen ein, um eine neue virtuelle Maschine zu starten und eine Application online zu schalten. Bei diesen Informationen handelt es sich in der Regel um Infrastrukturdaten höherer Ebene, wie etwa:

• Application : Eine vordefinierte Liste verfügbarer Application , z. B. Microsoft SharePoint, ein Webserver, ein Mailserver, eine Oracle-Datenbank usw.
• Netzwerkinformationen: Cluster-IP-Adresse, Front-End-URL, ob diese Application öffentlich oder nur intern sein wird usw.
• Bereitstellungsinformationen: Alle zusätzlichen Informationen, die für das Bereitstellungssystem erforderlich sind, z. B. der Netzwerkstandort (häufig eine geografische Referenz, die an ein physisches Rechenzentrum gebunden ist, z. B. „Europa – Rechenzentrum Kopenhagen“), und alle Einschränkungen hinsichtlich der Mindest- und Höchstzahl zulässiger Instanzen eines bestimmten Application .

Diese Informationen werden als Metadaten für die automatische Bereitstellung in der gesamten Unternehmens-Cloud verwendet.

Sobald der Administrator die erforderlichen Daten übermittelt hat, besteht der nächste Schritt darin, dass der Cloud-Controller diese Informationen – zusammen mit einer dynamisch erstellten eindeutigen Instanz-ID, die im gesamten System zur Identifizierung dieser Instanz für die Bereitstellung verwendet wird, z. B. „vm12345“ – verpackt und über den Nachrichtenbus an den Orchestrator verteilt.

Alle im ersten Schritt bereitgestellten Informationen werden vor der Übermittlung an den Orchestrator vom Nachrichtenbus normalisiert.

Gleichzeitig stellt der Cloud-Controller dem Hypervisor über eine API dieselben Metadaten und die eindeutige Instanz-ID zur Verfügung und weist ihn an, das erforderliche Application bereitzustellen. Dieses Ereignis fordert den Hypervisor auf, das entsprechende Festplattenimage der virtuelle Maschine vom Cloud-basierten Speicher anzufordern. Das Speichergerät ruft das entsprechende Disk-Image über NFS ab und beginnt mit dem Kopieren dieses Images auf den lokalen Speicher.

Nachdem der Orchestrator die normalisierten Ereignisinformationen und Metadaten vom Nachrichtenbus erhalten hat, startet er zwei verschiedene Workflows, die die Metadaten gleichzeitig an die Überwachungssysteme und das DNS senden. Die Überwachungssysteme verwenden diese Informationen, um einen automatisierten Überwachungsplan für die Application zu konfigurieren und mit der Überwachung der Application zu beginnen, nachdem eine Benachrichtigung gesendet wurde, dass sie aktiv ist. Während dieses Schritts definiert der Orchestrator auch Schwellenwerte für die Ereignisse des Überwachungssystems. Er weist den Monitor beispielsweise an, eine Ereignisbenachrichtigung zu senden, wenn die CPU-Auslastung dieser virtuellen Instanz 75 Prozent überschreitet.

Der Orchestrator überträgt außerdem die Metadaten der virtuellen Instanz an DNS, wo die Daten für die Verwendung in der gesamten Unternehmens-Cloud gespeichert werden. Der Orchestrator ist für die Übermittlung der Metadaten im entsprechenden DNS-Zonenformat verantwortlich. Er muss daher Domänennamen auf Grundlage der Instanz-ID konstruieren, IPv4- und IPv6-DNS-Einträge erstellen, Instanzinformationen vom Cloud-Controller hinzufügen und die neuen Instanzinformationen der entsprechenden Zone hinzufügen. Beispielsweise verwendet der Orchestrator die eindeutige Instanz-ID, erstellt einen DNS-Eintrag für „vm12345.vm.cloud.example.com“ und fügt diesen der vorhandenen Zone example.com hinzu.

Der letzte Schritt bei der Verteilung von Metadaten in der gesamten Unternehmens-Cloud besteht darin, den BIG-IP LTM Application Delivery Controller mit den neuen Instanzinformationen wie Hostname, IP-Adresse, Application (oder Pool auf BIG-IP LTM) und Überwachungsinformationen zu füllen.

In Schritt 2 wies der Cloud-Controller den Hypervisor an, die mit der neu bereitgestellten Instanz verknüpfte virtuelle Maschine zu starten. Sobald die VM wie erwartet läuft und für Verbindungen verfügbar ist, benachrichtigt sie den Orchestrator über eine Ereigniswarnung auf dem Nachrichtenbus. Der Orchestrator nimmt diese Ereigniswarnung entgegen und startet einen Workflow, der BIG-IP LTM anweist, die neue VM als im Pool verfügbar zu kennzeichnen und basierend auf der Lastausgleichsmethode mit dem Senden und Verteilen neuer Verbindungen an die virtuelle Instanz zu beginnen. BIG-IP LTM beginnt außerdem mit der Überwachung der neuen Instanz mit dem zuvor konfigurierten, dem Application zugewiesenen Application .

Die Ereigniswarnung der neu ausgeführten VM fordert den Orchestrator außerdem dazu auf, das gesamte Cloud-Überwachungssystem des Unternehmens zu benachrichtigen, damit mit der Überwachung der virtuellen Instanz begonnen werden kann. An diesem Punkt ist die neu bereitgestellte virtuelle Instanz in der Unternehmens-Cloud einsatzbereit und verarbeitet Application . Dies ist der normale Betriebsmodus aller Dienste, die Teil der Unternehmens-Cloud sind.

Die manuelle Bereitstellung ist der erste Workflow-Schritt bei der Bereitstellung von Diensten innerhalb der Unternehmens-Cloud, jedoch nicht die am häufigsten verwendete Form der Bereitstellung. In einem reibungslos funktionierenden System entwickelt sich die Enterprise Cloud zu einem dynamischeren und flüssigeren System der Selbstüberwachung und stellt je nach Bedarf und Nachfrage selbst neue Dienste bereit. Diese agile Selbstbereitstellung ist das Herzstück jeder Cloud-Plattform und erfordert zusätzliche automatisierte Bereitstellungsereignisse und Workflows für die Überwachung von und die Reaktion auf Echtzeitereignisse.

Der erste Schritt jedes Auto-Provisioning-Systems ist die Überwachung: das Erfassen und Erkennen von Ereignissen im gesamten System. Während der ersten Runde der manuellen Bereitstellung wurden die Überwachungssysteme mit Informationen zu virtuellen Instanzen wie Name, Standort, Überwachungstyp und Ereignisschwellenwerten gefüllt. Diese Informationen werden verwendet, um die Verfügbarkeit und Leistung der Applications und virtuellen Instanzen automatisch zu überwachen. Sobald ein Ereignis vom Überwachungssystem erkannt wird, beispielsweise wenn eine bestimmte virtuelle Instanz mehr als 75 Prozent der verfügbaren CPU-Ressourcen verbraucht, generiert es ein Ereignis auf dem Nachrichtenbus, das den Orchestrator auf die erschöpften Ressourcen hinweist.

In einem typischen Szenario mit automatisierter Bereitstellung ist der Orchestrator für die Erstellung einer neuen virtuellen Instanz verantwortlich, die dazu beiträgt, die Ressourcenlast der aktuellen Instanz zu verringern. Zwei oder mehr virtuelle Instanzen werden verwendet, um die Application und Netzwerklasten zu verteilen.

Um einen automatisierten Bereitstellungsworkflow zu initiieren, muss der Orchestrator für das Sammeln von Komponentenereignissen sowie für das Anfordern von Metadaten verantwortlich sein, die zum Bereitstellen einer neuen virtuellen Instanz erforderlich sind. In der Referenzarchitektur von F5 und IBM werden die Metadaten im DNS gespeichert und als Teil des ursprünglichen manuellen Bereitstellungsworkflows aufgefüllt. DNS gibt Informationen wie Application , geografischer Standort und Bereitstellungsschwellenwerte an den Orchestrator zurück.

Im letzten Schritt eines automatisierten Bereitstellungsworkflows überträgt der Orchestrator die vom DNS abgerufenen Metadaten über den Nachrichtenbus an den Cloud-Controller. Im Wesentlichen simuliert dieser automatisierte Schritt den Schritt, in dem ein Administrator Maschineninformationen eingibt und den Bereitstellungsworkflow manuell startet. Der Cloud-Controller übernimmt diese Informationen (genauso wie er sie von dem Administrator bei der manuellen Bereitstellung erhalten würde) und startet einen neuen Bereitstellungsworkflow für die virtuelle Instanz. Von diesem Punkt an werden die oben beschriebenen Bereitstellungsschritte und Arbeitsabläufe wiederholt, bis die neue virtuelle Instanz betriebsbereit ist und neue Verbindungen akzeptiert.

Eine typische Cloud-Bereitstellung in einem Unternehmen umfasst sowohl manuelle als auch automatisierte Bereitstellungs-Workflows. Neue Dienste oder Applications werden zunächst mithilfe eines manuellen Workflows bereitgestellt, sodass ein Administrator steuern kann, wie und wo der Dienst bereitgestellt wird. Sobald ein Dienst einsatzbereit ist, verwalten die automatisierten Bereitstellungs-Workflows die Bereitstellung basierend auf Ressourcenbedarf und -verfügbarkeit.

Die Entscheidung für die Bereitstellung einer privaten Unternehmens-Cloud sollte nicht mit einer erhöhten Komplexität oder Funktionsbeeinträchtigung einhergehen. Der Zweck jeder Cloud-Bereitstellung besteht darin, die Hürden bei der Erstellung neuer Dienste abzubauen und eine flexiblere Computerinfrastruktur bereitzustellen. Eine Enterprise-Cloud bringt diese Agilität in das Rechenzentrum und sorgt so für deutlich verbesserte Verwaltbarkeit und Kontrolle.

Gemeinsam mit IBM hat F5 eine Referenzarchitektur für eine automatisch bereitgestellte Unternehmens-Cloud erstellt. Diese Architektur ist modular und flexibel konzipiert. Sie ermöglicht die Integration vorhandener Komponenten nach Bedarf und die Anbindung der gesamten Unternehmens-Cloud an jede andere Cloud-Plattform über APIs und eine gemeinsame Messaging-Infrastruktur. Keine private Unternehmens-Cloud ist wie die andere. Die Architektur von F5 und IBM passt sich jedoch an unterschiedliche Umgebungen an und bringt gleichzeitig die Vorteile einer agilen Infrastruktur in jede Application oder jedes Rechenzentrum.

¹ Babcock, Charles (18. Januar 2011). „Private Clouds heben ab.“ Informationswoche. Internet.