Die Event Broker Appliance vereinfacht die Integration von vSphere mit Systemen im eigenen Rechenzentrum oder der Cloud. Sie löst benutzerdefinierte oder vorgefertigte Aktionen aus, etwa um Tickets zu erstellen, die Konfiguration von Hosts und VMs automatisiert zu ändern oder Alerts zu versenden.
Der wesentliche Vorteil der Appliance besteht darin, dass Endbenutzer, Partner oder unabhängige Software-Anbieter nur noch eine minimale Geschäftslogik programmieren müssen, um die entsprechenden vSphere-APIs in ihre Automatisierungs-, Integrations- oder Überwachungs-Workflows einzubinden.
Die erste Vorab-Version 0.1.0 erschien bereits 2019, seit Ende 2020 steht nun Version 0.5 zur Verfügung. Sie erschließt im VMware-Umfeld ein ähnliches Potenzial wie AWS mit seinen Server-losen ereignisgetriebenen Funktionen (AWS Lambda) oder Microsoft mit seinen Azure Functions.
Einsatzgebiete für die VMware Event Broker Appliance
Die möglichen Anwendungsgebiete der VMware Event Broker Appliance sind vielfältig. Für viele davon bringt sie vorgefertigte Funktionen mit, so dass Kunden schnell mit einer Lösung starten können.
So lassen sich zum Beispiel mit der Appliance einfach Benachrichtigungs-Workflows realisieren. Nutzer erhalten dann Mitteilungen und Echtzeit-Updates über Ihren bevorzugten Kommunikationskanal wie SMS, Slack oder Microsoft Teams. Allgemein erlaubt diese Funktion das Überwachen des Zustands, der Verfügbarkeit und Kapazität von vSphere-Ressourcen.
Konfigurationen automatisch ändern
Natürlich lassen sich mit einem ereignisgetriebenen Dienst auch Aufgaben automatisieren. So können Admins beispielsweise Konfigurationsänderungen abhängig von VM- oder Host-Lebenszyklusaktivitäten steuern, zum Beispiel Sicherheitseinstellungen auf eine VM anwenden oder vSphere-Tags auf den Host vergeben.
Auch geplante Jobs zur Überprüfung des Zustands einer Umgebung, etwa eines VM-Snapshots mit langer Laufzeit, gehören in diese Kategorie.
Tickets bei bestimmten Vorfällen generieren
Die Integrationsfunktionen der Appliance erlauben zudem die Verwendung von Drittanbieterlösungen, welche Remote-APIs für die Zuordnung zu bestimmten Infrastrukturereignissen bereitstellen.
Als Beispiel sei hier eine automatisierte Ticketerstellung für Workload- und Hardware-Fehler anhand von Pager Duty, ServiceNow, Jira Service Desk oder Salesforce-basierten Vorfällen zu nennen.
Aufgaben bei Auftreten bestimmter Events ausführen
Zu den vorgefertigten Funktionen gehört auch das Erkennen und Ausführen bestimmter Aufgaben auf Basis bestimmter Ereignistypen wie das Hinzufügen oder Anfordern zusätzlicher Kapazität. Dies ermöglicht es Operations- und SRE-Teams, vorhandene und bekannte Runbooks für die automatisierte Auflösung zu kodifizieren.
Eine weitere vorgefertigte Funktion der Event Broker Appliance erlaubt das einfache Verfolgen sämtlicher Konfigurationsänderungen für Objekte wie VMs und das automatische Aktualisieren der CMDB.
Benutzeranmeldungen verfolgen
Admins könnten mit der Funktion auch sämtliche Authentifizierungs- und Autorisierungsereignisse zur Einhaltung von Vorschriften oder zur Erkennung von Eindringlingen an ihr Sicherheits-Team weiterleiten lassen.
Auch das Wiederholen von Konfigurationsänderungen, die Fehlerbehebung oder das Debuggen werden durch dieses Feature möglich.
Integration mit der Cloud
Mit der Appliance können Admins das eigene Rechenzentrum auch komfortabel in Richtung Public-Cloud erweitern, weil sie die Anbindung dazu prädestinierter Dienste wie AWS EventBridge recht einfach macht.
AWS Event Bridge ist beispielweise ein Server-loser Event Bus, der Anwendungsdaten aus eigenen Apps (zum Beispiel im vSphere-SDDC) mit SaaS und AWS-Services verbindet.
Anbindung von CMDBs
Die vorgefertigten Funktionen der Appliance erlauben darüber hinaus, die Anzahl der Verbindungen und Benutzer zum vCenter-Server zu reduzieren, indem man etwa externen System wie CMDB oder Data Warehouse den Zugriff auf Ereignisse gewährt.
Man kann mit der Funktion beispielsweise auch seinen Teams zu einem besseren Verständnis der Arbeitslast und des Infrastrukturverhaltens verhelfen, indem man in den Ereignisdaten beobachtete Trends identifiziert. Dazu gehören etwa die Dauer von Ereignissen oder Benutzer, die bestimmte Vorgänge generieren sowie der häufig verwendete Workflows.
Die Architektur der VEBA
Die VMware Event Broker Appliance verfolgt einen modularen Ansatz und verwendet Kubernetes und Container als Abstraktionsschicht zwischen dem Betriebssystem (Photon OS) und den erforderlichen Anwendungsdiensten.
Derzeit besteht die Appliance aus folgenden Komponenten:
- VMware Event Router (Quellen verfügbar auf GitHub)
- Unterstützte Event Stream Quellen:
- VMware vCenter
- Unterstützte Event Stream Prozessoren:
- Unterstützte Event Stream Quellen:
- Contour
- Kubernetes
- Photon OS
Folgende Abbildung verdeutlicht die Zusammenhänge.
Photon OS als Betriebssystem
VMwares Linux-Betriebssystem Photon sollte vSphere-Anwendern bekannt sein, kommt es doch inzwischen bei verschiedenen VMware-Appliances als Fundament zu Einsatz, einschließlich der vCSA. Konkret handelt es sich bei Photon OS um einen Linux-Container-Host, der für Cloud-native Anwendungen, Cloud-Plattformen und VMware-Infrastruktur optimiert ist.
Photon OS bietet eine sichere Laufzeitumgebung für Container und die integrierte Unterstützung von Kubernetes.
Kubernetes-Komponenten Contour und Knative
Contour ist ein Ingress-Controller für Kubernetes, der den Envoy-Proxy als Reverse-Proxy und Load Balancer nutzt. Es unterstützt von Haus aus dynamische Konfigurationsaktualisierungen, wobei ein leichtgewichtiges Profil beibehalten wird. In der VMware Event Broker Appliance kümmert sich Contour um die TLS-Terminierung für die verschiedenen bereitgestellten HTTP(S) -Endpunkte.
Knative ist eine Kubernetes-basierte Plattform zur Bereitstellung und Verwaltung moderner Workloads ohne Server. Es besteht aus zwei Kernbausteinen: Serving (Knative Service) und Eventing (Broker, Channel usw.).
Der VMware Event Router kann so konfiguriert werden, dass Ereignisse direkt an eine adressierbare Knative-Ressource („Referenz“) gesendet werden, zum Beispiel an einen Knative Broker oder Service. Broker ist das empfohlene Bereitstellungsmodell für den VMware Event Router.
Weitere Informationen zu Brokern, Triggern, Ereignisfilterung usw. finden sich in der Knative-Dokumentation. Alternativ kann der Router Ereignisse an einen URI senden, wie zum Beispiel einen externen HTTP-Endpunkt, der CloudEvents akzeptiert.