VMware Event Broker Appliance

Mit dem VMware „Event Broker Appliance“-Fling können VMware-Admins ihrem softwaredefinierten VMware-Datacenter eine ereignisgesteuerte Funktionsebene verleihen. Die Lösung erweitert vSphere um die Fähigkeit, benutzerdefinierte oder vorgefertigter Aktionen auszulösen und damit u. a. Integrationen im eigenen Rechenzentrum oder der Public Cloud bereitzustellen.

Passende Schulungen

VMware vSphere: Data Center Virtualization: Core Technical Skills

Viele weitere Tipps und Tricks rum um die Produktpalette von VMWare zeigen wir dir gerne in unseren VMWare Schulungen.

Mit der als Appliance bereitgestellten Lösung müssen Endbenutzer, Partner oder unabhängige Softwareanbieter nur noch eine minimale Geschäftslogik programmieren, um die entsprechenden vSphere-APIs in ihre Automatisierungs-, Integrations- oder Überwachungsworkflows einzubinden. Die erste Vorab-Version 0.1.0 der Appliance erschien bereits Ende 2019. Seit Ende 2020 steht nun Version 0.5 bereit, welche neue Anwendungsfälle und Workflows für die Integration in das vSphere-Ökosystem eröffnet. Sie erschließt damit im VMware-Umfeld ein ähnliches Potenzial wie AWS mit seinen serverlosen ereignisgetriebenen Funktionen (AWS Lambda) oder Microsoft mit seinen Azure Functions.

Federführend für die Entwicklung zeichnet sich einmal mehr VMware‘s William Lam verantwortlich, der im VMware Cloud-Team innerhalb der Cloud Services Business Unit (CSBU) arbeitet. Er konzentriert sich auf Automatisierung, Integration und Betrieb für die VMware Cloud Software Defined Datacenters (SDDC). In seinem privaten Blog https://www.virtuallyghetto.com/ widmet er sich seit Jahren außergewöhnlich interessanten Projekten im VMware-Umfeld.

Was kann man mit der VMware Event Broker Appliance machen?

Die potenziellen Einsatzzwecke der VMware Event Broker Appliance sind vielfältig. Kunden können zudem schnell mit der Lösung starten, weil die Appliance eine Vielzahl https://vmweventbroker.io/examples vorgefertigter Funktionen in Python, Go oder PowerCLI  für eine Reihe von Anwendungsszenarien mitbringt.

So können Admins mit der Appliance z. B. Benachrichtigungs-Workflows realisieren: Nutzer erhalten dann Benachrichtigungen und Echtzeit-Updates über ihren bevorzugten Kommunikationskanal wie SMS, Slack, Microsoft Teams usw. . Die Benachrichtigungsfunktion ermöglicht zudem Echtzeitaktualisierungen für diejenigen vSphere Inventory-Objekte, die im eigenen Unternehmen von Bedeutung sind. Allgemein erlaubt diese Funktion das Überwachen von Zustand, Verfügbarkeit und Kapazität von SDDC-Ressourcen.

Natürlich lassen sich mit einem ereignisgetriebenen Dienst auch Automatisierungsszenarien realisieren. So können Admins beispielsweise Konfigurationsänderungen auf Basis bestimmter VM- oder Host-Lebenszyklusaktivitäten innerhalb des SDDC wie z. B. das Anwenden von Sicherheitseinstellungen auf eine VM oder eines vSphere-Tag auf den Host übernehmen. Auch geplante Jobs zur Überprüfung des Zustands einer Umgebung, z. B. eines Snapshots mit langer Laufzeit auf einer VM, gehören in diese Kategorie.

Die neuen Integrations-Funktionen 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 anhand von Plattformen wie Pager Duty, ServiceNow, Jira Service Desk und Salesforce-basierten spezifischen Vorfällen wie Workload und / oder Hardwarefehlern zu nennen.

Mit der Appliance können Admins das eigene SDDC auch komfortabel in die Public-Cloud erweitern, weil sie die Anbindung dazu prädestinierter Dienste wie https://aws.amazon.com/de/eventbridge/ AWS EventBridge recht einfach macht. AWS Event Bridge ist beispielweise in serverloser Event Bus, der Anwendungsdaten aus eigenen Apps (z. B. im vSphere-SDDC), SaaS und AWS-Services verbindet.

Zu den vorgefertigten Funktionen gehört auch das Erkennen und Ausführen bestimmter Aufgaben auf Basis spezifischer Ereignistypen wie z. B. 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 einer VM und das automatische Aktualisieren der Änderung in einer Änderungsmanagementdatenbank (CMDB).

Admins könnten mit der Funktion auch sämtliche Authentifizierungs- und Autorisierungsereignisse zur Einhaltung von Vorschriften und / oder zur Erkennung von Eindringlingen an Ihr Sicherheitsteam weiterleiten lassen. Auch das Wiederholen von Konfigurationsänderungen, die Fehlerbehebung oder das Debuggen werden durch dieses Feature möglich.

Mit den vorgefertigten Funktionen der Appliance ist es darüber hinaus möglich, die Anzahl der Verbindungen und/oder Benutzer zum vCenter Server zu reduzieren, indem man z. B. den Zugriff auf Ereignisse in einem externen System wie CMDB oder Data Warehouse-Lösung gewährt. Man kann mit der Funktion z. B. auch seinen Teams zu einem besseren Verständnis der Arbeitslast und des Infrastrukturverhaltens verhelfen, indem man in den Ereignisdaten beobachtete Trends identifiziert, einschließlich der Dauer von Ereignissen, Benutzern, die bestimmte Vorgänge generieren oder der häufig verwendeten Workflows.

Wie kommt man an die Lösung?

Die VMware Event Broker Appliance wird als virtuelle Appliance bereitgestellt und lässt sich problemlos auf jeder vSphere-basierten Infrastruktur betreiben, einschließlich VMware Cloud on AWS oder VMware Cloud on DellEMC. Kunden mit einem vorhandenen Kubernetes-Cluster können den VMware Event Router mit nur einem einzigen Befehl von Helm (Kubernetes Paketmanager) aus ausrollen. Ausführliche Anweisungen zur Verwendung des Helm-Installationsprogramms finden Sie in der https://vmweventbroker.io/kb/advanced-deploy-k8s Dokumentation.

Die Architektur der VEBA

Die VMware Event Broker Appliance verfolgt einen sehr modularen Ansatz und verwendet Kubernetes und Container als Abstraktionsschicht zwischen dem Basisbetriebssystem (Photon OS) und den erforderlichen Anwendungsdiensten. Derzeit besteht die Appliance aus folgenden Komponenten:

• VMware Event Router (Quellen verfügbar auf https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/master/vmware-event-router  Github)
  • Unterstützte Event Stream Quellen:
    • VMware vCenter
  • Unterstützte Event Stream Prozessoren:
    • Knative (https://knative.dev/)
    • OpenFaaS (https://www.openfaas.com/)
    • AWS EventBridge (https://aws.amazon.com/de/eventbridge/)
• Contour (https://github.com/projectcontour/contour)
• Kubernetes
• Photon OS

Die Abbildung verdeutlicht die Zusammenhänge:

VMware´s Cloud-natives 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 quelloffenen Linux-Container-Host, der für Cloud-native Anwendungen, Cloud-Plattformen und VMware-Infrastruktur optimiert ist. Photon OS bietet eine sichere Laufzeitumgebung für die effiziente Ausführung von Containern und die sofortige Unterstützung von Kubernetes.

Contour ist ein Ingress-Controller für Kubernetes, der den https://www.envoyproxy.io/  Envoy-Proxy als Reverse-Proxy und Load Balancer bereitstellt. Contour 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. Knative hat zwei Kernbausteine: 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, z. B. ein 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 z. B, einen externen HTTP-Endpunkt, der CloudEvents akzeptiert.

Auch wenn die VMware Event Broker Appliance als einzelne virtuelle Maschine instanziiert wird, weisen die oben beschriebenen Komponenten eine Microservices-Architektur auf, die auf Kubernetes ausgeführt wird und in der die einzelnen Dienste TCP/IP-Netzwerk-Sockets kommunizieren. Der größte Teil der Kommunikation erfolgt dabei intern in der Appliance. Sollte eine Komponente nicht mehr verfügbar sein (Absturz, Überlastung) kann das die Kommunikation beeinträchtigen. Das hat dann Konsequenzen für die Ereignisübermittlung, d. h. den jeweiligen Funktionsaufruf. Um das Risiko des Blockierens von Remote-Anrufen zu vermeiden, die das gesamte System unbrauchbar machen könnte, werden sinnvolle Standardzeitlimits angewendet, die bei Bedarf angepasst werden können.

Grundsätzlich ist Kubernetes aber eigentlich die perfekte Plattform zum Aufbau hochverfügbarer verteilter Systeme. Obwohl die VEBA-Entwickler die Clustering-Funktionen für mehrere Knoten derzeit noch gar nicht nutzen bietet Kubernetes Entwicklern und Benutzern viele Vorteile. Die Selbstheilungsfunktionen überwachen kontinuierlich die kritischen Komponenten der VMware Event Broker Appliance und die vom Benutzer bereitgestellten Funktionen und lösen bei Bedarf einen Neustart aus.

Kubernetes und seine Abhängigkeiten wie Docker werden übrigens als systemd-Einheiten bereitgestellt. Dies behebt das Problem “Wer überwacht den Beobachter?”, falls die Laufzeit des Kubernetes-Knotenagenten (Kubelet) oder des Docker-Containers abstürzt.