Die VMware Event Broker Appliance (VEBA) ist über Flings erhältlich [1] – eine Art Experimentier-Marktplatz von VMware. Mit VEBA lassen sich vSphere-APIs mit einer minimal zu programmierenden Geschäftslogik in Automatisierungs-, Integrations- oder Überwachungsworkflows einbinden. Die Appliance weist für ein Fling einen relativ hohen Reifegrad auf und setzt den Schwerpunkt auf Automatisierung, Integration und Betrieb eines VMware Cloud Software-defined Datacenters (SDDC).

VEBA kommt in den Bereichen Benachrichtigungen, Automation, Integration, Standardisierung, Audit und Analytics zum Einsatz. Der ersten Schritte fallen leicht, weil die Appliance eine Vielzahl vorbereiteter Funktionen in Python, Go oder PowerCLI für viele Anwendungsszenarien mitbringt [2]. So lassen sich mit VEBA beispielsweise Benachrichtigungs-Workflows umsetzen. Die Benachrichtigungsfunktionen sorgen in Echtzeit für eine Aktualisierung derjenigen vSphere-Inventory-Objekte, die für Sie von Bedeutung sind. Allgemein ausgedrückt ermöglicht die Funktion das Überwachen von Zustand, Verfügbarkeit und Kapazität.

Mit VEBA können Sie ereignisgetriebene Automatisierungsszenarien realisieren, etwa das automatisierte Ändern bestimmter Konfigurationen als Reaktion auf ausgewählte VM- oder Host-Lebenszyklusaktivitäten innerhalb Ihres SDDC. Denkbar wäre hier beispielsweise das Anwenden von Sicherheitseinstellungen auf eine VM oder das Anpassen von Ressource-Tags auf einem ESXi-Host. Ein weiteres mögliches Szenario könnte das zeitplangesteuerte Überprüfen des Zustands einer Komponente, beispielsweise von VMs mit "vergessenen" (nicht zeitnah aufgelösten) Snapshots, sein.

Die Integrationsfunktionen in Version 0.5 ermöglichen es Ihnen auch, Drittanbieterlösungen einzubinden, die Remote-APIs zur Zuordnung zu bestimmten Infrastrukturevents bereitstellen. Die Entwickler führen hierzu als Beispiel eine automatisierte Ticketerstellung anhand von Plattformen wie Pager Duty, ServiceNow, oder Jira Service Desk in Reaktion auf spezifische Vorfälle wie Workload- und Hardwarefehler an. Sie können mit der Appliance das eigene SDDC aber auch in die Public Cloud erweitern. Mit VEBA lassen sich Dienste wie zum Beispiel Amazon EventBridge [3] besonders einfach anbinden. Amazon Event Bridge ist ein serverloser Event Bus, der Anwendungsdaten aus eigenen Apps (zum Beispiel im vSphere-SDDC) mit AWS-Services verbindet.

Mithilfe der im Lieferumfang enthaltenen Funktionen lassen sich unter anderem Workflows realisieren. Diese können bestimmte Aufgaben in Reaktion auf spezifische Ereignistypen – wie zum Beispiel das Hinzufügen oder Anfordern zusätzlicher Kapazität – erkennen und ausführen. Dies wiederum gestattet Operations- und SRE-Teams, passende Runbooks zur automatisierten Auflösung des Workflows zu schreiben.

Außerdem enthält VEBA ein Feature, mit dem Sie sämtliche Konfigurationsänderungen für Bestandsobjekte wie beispielsweise einer virtuellen Maschine (VM) nachverfolgen können. Somit lassen sich die Änderungen dann automatisiert in einer Änderungsmanagementdatenbank (CMDB) aktualisieren. Mit der Funktion können Sie auch sämtliche Authentifizierungs- und Autorisierungsereignisse automatisiert an Ihr Sicherheitsteam weiterleiten lassen, um Compliance-Vorschriften einzuhalten oder Angriffsversuche zu erkennen. Zudem ist das Wiederholen von Konfigurationsänderungen, das Beheben von Fehlern oder das Debuggen möglich.

Mit den vorgefertigten Features können Sie aber auch die Anzahl der Verbindungen und/oder Benutzer zu Ihrem vCenter Server grundsätzlich reduzieren, indem Sie den Zugriff auf Ereignisse nur in einem externen System wie einer CMDB oder einem Data Warehouse gewähren.

Darüber hinaus verschaffen Sie mit VEBA Ihren Betriebs- und Entwicklerteams ein besseres Verständnis für die Arbeitslast und das Infrastrukturverhalten, indem Sie in den Ereignisdaten beobachtete Trends identifizieren. Das können zum Beispiel die Dauer von Ereignissen, Benutzer, die bestimmte Vorgänge generieren, oder andere häufig verwendete Workflows sein.

Die Entwickler stellen die VMware Event Broker Appliance, wie der Name unschwer suggeriert, als virtuelle Appliance zur Verfügung. Sie lässt sich also problemlos auf jeder vSphere-basierten Infrastruktur einsetzen. Das gilt auch für VMware Cloud on AWS oder VMware Cloud on DellEMC.

Betreiben Sie beispielsweise bereits einen Kubernetes-Cluster auf AWS mit dem Kubernetes-Dienst EKS, können Sie die Appliance auch einfach via Helm Charts ausrollen. Hilfreiche Informationen zum Einsatz des Helm-Installationsprogramms für VEBA finden Sie in der Dokumentation [4]. Die Quellen der Software sind unter [5] auf GitHub verfügbar.

Die Entwickler haben VEBA mit einer modularen Architektur versehen und nutzen Kubernetes beziehungsweise Container als Abstraktionsschicht zwischen dem Basis-OS der VM (Photon OS) und dem eigentlichen Anwendungsdienst "VMware Event Router". Als Ingress-Controller für Kubernetes kommt Contour [6] zum Einsatz. Bild 2 verdeutlicht die Zusammenhänge. Das Architekturschema zeigt die Gliederung nach sogenannten Event-Providern (derzeit vCenter Server), dem eigentlichen Event-Router und den unterstützten Event-Prozessoren, wobei Event-Router und Event-Prozessoren jeweils in Kubernetes Namespaces verpackt sind. Zu den unterstützten Event-Stream-Prozessoren gehören derzeit Knative [7], OpenFaaS [8] sowie die oben erwähnte Amazon EventBridge [3] .

Als Ingress-Controller für Kubernetes setzte VEBA auf Contour. Dieser stellt den Envoy-Proxy [9] als Reverse-Proxy und Loadbalancer bereit. Der Vorteil: Contour unterstützt im Gegensatz zu NGINX von Haus aus dynamische Konfigurationsaktualisierungen. In VEBA kümmert sich Contour auch um die TLS-Terminierung für die einzelnen bereitgestellten HTTP(S)-Endpunkte. Knative ist eine auf Kubernetes basierende Plattform, um moderne serverlose Workloads bereitzustellen und zu verwalten und enthält mit "Serving" (Knative Service) und "Eventing" (Broker, Channel et cetera) zwei wesentliche Kernkomponenten.

Zwar wird VEBA wie beschrieben als einzelne VM instanziiert, trotzdem stellen die beschriebenen Komponenten intern eine Microservices-Architektur dar, die auf Kubernetes läuft, wobei die einzelnen Dienste über TCP/IP-Sockets kommunizieren. Der überwiegende Teil der Kommunikation verbleibt dabei stets "innerhalb" der VM. Allerdings bleibt die VM selbst vorerst für sich allein. Dabei böte Kubernetes grundsätzlich die ideale Plattform für den Betrieb verteilter Systeme. Sollte eine Komponente nämlich nicht verfügbar sein – beispielsweise bei einem Ausfall oder einer Überlastung – beeinträchtigt das die Kommunikation mit entsprechenden Konsequenzen für die Ereignisübermittlung.

Obwohl VEBA Cluster-Funktionen für mehrere Knoten derzeit noch gar nicht nutzt, bietet die Kubernetes-Plattform trotzdem Vorteile: Die eingebauten Selbstheilungsfunktionen überwachen kontinuierlich alle kritischen VEBA-Komponenten sowie die von ihnen bereitgestellten Funktionen. Beim Ausfall einer Komponente erfolgt deren Neustart automatisiert.

Die Entwickler verwenden außerdem anpassbare Zeitlimits, um das Risiko des Blockierens von Remote-Anrufen zu verringern, die das gesamte System unbrauchbar machen könnten. Dass Kubernetes einschließlich seiner Abhängigkeiten als systemd-Unit realisiert ist, behebt zudem das Problem "Wer überwacht den Beobachter?", sollte die Runtime des Kubernetes-Node-Agents (kubelet) oder des -Containers abstürzen.

Die VMware Event Broker Appliance ist mehr als ein kleines Fling, sondern stellt eine mächtige Lösung zur Ereignisübermittlung und Integration in lokalen, vor allem aber auch in hybriden vSphere-Szenarien dar. Aus den angedeuteten Anwendungsfällen ergeben sich faszinierende Möglichkeiten. Dabei ist VEBA bereits gut dokumentiert. Zudem stellen die Entwickler unter [10] eine Reihe von aufschlussreichen Video-Tutorials bezüglich Deployment, weiterer interessanter Use Cases oder der Bereitstellung serverloser Funktionen zur Verfügung.