OpenShift Virtualization für vSphere-Admins: Eine Einführung in Netzwerkkonfigurationen

OpenShift Virtualization ist die Lösung von Red Hat für Unternehmen, die modernisieren möchten, indem sie eine containerisierte Architektur für ihre Anwendungen einführen, aber feststellen, dass die Virtualisierung ein notwendiger Bestandteil ihrer Strategie für die Bereitstellung im Rechenzentrum ist.

Offensichtlich können einige Anwendungen immer noch nicht containerisiert werden, und das ist auch in Ordnung. OpenShift Virtualization geht dieses Problem an, indem es ein moderneres Paradigma bereitstellt, das den Bedarf an Containern und virtuellen Maschinen in einer einheitlichen Plattform kohärent managt.

Wir bei Red Hat müssen uns mit folgendem Problem befassen: Wie können wir für Funktionsparität sorgen und gleichzeitig ein ähnliches Kundenerlebnis wie bei den Produkten und Konfigurationen bieten, die der Kunde gewohnt ist, sodass die Einführung der neuen Lösung im Wesentlichen ohne große Umstellung verläuft?

Wenn Menschen mit der Arbeit in einem IT-Ökosystems vertraut sind, versuchen sie im Allgemeinen, vertraute Prinzipien an neue Systeme anzupassen. Für viele Systemadministratoren ist VMware vSphere eine gängige Lösung für die Virtualisierung von Rechenzentren. Die in dieser Umgebung arbeitenden Personen haben viele Designlösungen vorgestellt, die als Best Practices für die Bereitstellung und Konfiguration virtueller Maschinen oder virtueller Rechenzentren eingeführt wurden. Diese Designentscheidungen scheinen für diejenigen, die in diesem Bereich arbeiten, oft eine Selbstverständlichkeit zu sein, und sie würden wahrscheinlich versuchen, ähnliche Entscheidungen auf andere geplante Umgebungen anzuwenden.

In dieser Blog-Reihe werden die Unterschiede zwischen der Art und Weise untersucht, wie Unternehmen und ihre Virtualisierungs-Admins mit früheren Hypervisor-Umgebungen interagiert haben und wie sie ähnliche Aktionen oder Konfigurationen mit OpenShift Virtualization durchführen.

Konzentrieren Sie sich zunächst auf das Design mit mehreren Netzwerken, das häufig bei anderen Virtualisierungslösungen wie VMware vSphere verwendet wird. Mit der Umgebung vertraute Personen wissen, dass die ESXi-Hosts hier häufig verschiedene Netzwerke unterstützen, wobei jedes virtuelle Netzwerk einen anderen Zweck innerhalb des virtuellen Rechenzentrums erfüllt. Diese Netzwerktrennung kann auf verschiedene Weise erreicht werden: durch Verkabeln verschiedener physischer NICs auf den Hosts mit verschiedenen Switches oder Netzwerken im Upstream oder durch Bündeln zusätzlicher VLANs über einen Uplink und anschließendes Überprüfen, ob sie auf dem vSwitch oder dem verteilten vSwitch innerhalb des Hypervisors richtig getaggt sind, um den gewünschten Zweck anzuzeigen. Am häufigsten werden Netzwerke mindestens in folgende Netzwerke unterteilt:

1. Ein Verwaltungsnetzwerk für die ESXi-Hosts und die vCenter-VM sowie andere Drittanbieter-Verwaltungshosts, die bereitgestellt werden können.
2. Ein Host-Migrationsnetzwerk für die ESXi-Hosts zur Unterstützung der sogenannten „Hot Migration“ von Guests (auch bekannt als vMotion) zwischen Hosts, um für  Hochverfügbarkeit zu sorgen.
3. Ein Host Storage-Netzwerk für die ESXi-Hosts für den Zugriff auf Storage-Ressourcen, die Zusatz-Storage oder Guest-Mapped Storage für die virtuellen Maschinen bereitstellen.
4. Ein VM-Netzwerk, das Netzwerkkonnektivität für die virtuellen Guests selbst bietet.

Neben den oben aufgeführten Netzwerken sind je nach Use Case der jeweiligen Kundenumgebung häufig spezielle Netzwerkkonfigurationen und -zwecke zu finden. Virtuelles Switching ermöglicht naturgemäß die einfache Implementierung einer großen Anzahl unterschiedlicher Konfigurationen. Es ist nicht verwunderlich, dass Personen, die ihre Netzwerke in der Regel auf eine allgemein verständliche Weise definieren, überrascht sind, wenn sie sich für eine Lösung wie OpenShift Virtualization entscheiden, bei der anders vorgegangen wird.

Die folgenden Abschnitte befassen sich mit den oben genannten primären Use Cases und zeigen, wie OpenShift Virtualization diese Anforderungen erfüllt.

Standardmäßig wird OpenShift Virtualization mit einem einzigen internen Pod-Netzwerk installiert. Wie andere Anwendungen, die in einer Kubernetes-Umgebung bereitgestellt werden, wird dieses interne Netzwerk für die Kommunikation mit dem Pod selbst für die Dauer seines Lifecycles verwendet. Mit der OpenShift-Konsole, dem CLI-Dienstprogramm virtctl oder dem Befehl oc können Sie praktisch alle wesentlichen Verwaltungsfunktionen für virtuelle Guests über das interne API-Netzwerk ausführen. Dieses Netzwerk in OpenShift Virtualization führt im Wesentlichen die gleichen Aktionen aus, die ein Administrator von seinem internen Verwaltungsnetzwerk in VMware vSphere erwarten würde.

Obwohl sämtliche Netzwerkfunktionen in einer OpenShift-Umgebung über das standardmäßige Pod-Netzwerk gemanagt werden können, wie die oben beschriebenen Verwaltungsfunktionen für eine einfache Konfiguration, ist dies oftmals nicht wünschenswert. Einige Aufgaben, beispielsweise die Migration virtueller Guests und der Storage-Zugriff, profitieren stark vom direkten Zugriff über dedizierte Netzwerke. Es gibt zwar Möglichkeiten, die Performance bestimmter Aktionen wie Guest-Migrationen über Migrationsrichtlinien so abzustimmen, dass die genutzte Bandbreite begrenzt wird. Allerdings würden die meisten Unternehmensbenutzer zustimmen, dass für zusätzliche Funktionen wie Guest-Migrationen, Storage und den Zugriff auf virtuelle Guests dedizierte Netzwerke sowohl wünschenswert als auch den Personen vertrauter sind, die bereits in einer VMware vSphere-Umgebung gearbeitet haben.

Zu diesem Zweck verwendet OpenShift das Multus CNI-Plugin, mit dem Sie zusätzliche Netzwerkschnittstellen, SR-IOV oder Linux-Bridge- Geräte konfigurieren können, die den Workerknoten zur Verfügung stehen und bei Bedarf an einzelne Pods angebunden werden können.

Vor der Installation von Multus muss der Client das zugrunde liegende Netzwerk entsprechend konfigurieren. Im Falle von Linux-Bridges erfolgt dies mit dem Operator „nmstate“. Für SR-IOV-Geräte wird der SR-IOV-Operator verwendet. Wenn die Netzwerkumgebung konfiguriert ist, kann der Administrator mit der Konfiguration einer Network Attachment Definition beginnen, die OpenShift anweist, wie zusätzliche physische Schnittstellen, SR-IOV-Geräte oder Linux-Bridges, die sie definieren, verwendet werden sollen.

Sehen Sie sich als Nächstes die Konfiguration für Live-Migrationen genauer an. Viele Deployments von VMware vSphere verfügen über ein dediziertes Netzwerk, das aufgrund der Bandbreitenanforderungen der Live-Migration zur Unterstützung von vMotion definiert wurde. Wenn ein Live-Migrations-Event in einer Infrastruktur ohne ein für diesen Zweck dediziertes Netzwerk auftritt, kann sich dies negativ auf gemeinsam genutzte Netzwerkressourcen auswirken, beispielsweise auf virtuelle Guests. Wenn ein Knoten nicht mehr verfügbar ist und mehrere Guests gleichzeitig migrieren müssen, kann auch das Management der Umgebung selbst beeinträchtigt werden. In OpenShift Virtualization gibt es mehrere Optionen, die verhindern, dass sich Live-Migrations-Events negativ auf das primäre Netzwerk oder die Performance des Clusters auswirken.

Bei der ersten Option definieren Sie eine Migrationsrichtlinie mit Regeln, beispielsweise zur Begrenzung der für Migrationen verfügbaren Bandbreite. Es ist auch möglich, ein dediziertes Netzwerk für Live-Migrationen zu definieren, indem Sie die Cluster-Einstellungen unter den Übersichtseinstellungen in OpenShift Virtualization ändern. In diesem Menü können Sie die Anzahl der Live-Migrationen begrenzen, die zu einem bestimmten Zeitpunkt stattfinden können, um für mehr Bandbreite zu sorgen. Darüber hinaus können Sie auch das Netzwerk ändern, das für diese Live-Migrationen verwendet wird.

Dazu erstellen Sie eine Network Attachment Definition für eine dedizierte Netzwerkschnittstelle auf Ihren Workerknoten und definieren ein privates Netzwerk, das eine Konnektivität nur zwischen den Workerknoten ermöglicht, die für die Unterstützung der Virtualisierung konfiguriert sind, und wählen Sie sie aus. Wenn ein Guest für die Migration ausgewählt oder ein Host in den Wartungsmodus versetzt wird, was alle Guests zum Verlassen des Hosts zwingt, wird das dedizierte Netzwerk für Live-Migrationen verwendet und eine zusätzliche Belastung der primären OpenShift-Netzwerkinfrastruktur vermieden.

Das Networking für Storage-Ressourcen hängt vom jeweiligen Storage-Anbieter ab, der für den OpenShift Cluster verwendet wird. Viele Storage-Anbieter verfügen über native, CSI-konforme Treiber für ihre Storage-Systeme, die automatisch die von ihnen festgelegten Best Practices für die Storage-Konnektivität anwenden.

Aus der Sicht von OpenShift Virtualization gibt es einige empfohlene Best Practices für die Konfiguration der Storage-Klassen zur Unterstützung virtueller Guests. Beispielsweise sollten sich für VMs provisionierte, persistente Volumes im RWX-Modus befinden, damit zusätzliche Knoten auf das persistente Volume zugreifen können, falls der virtuelle Guest zu einem anderen Knoten migriert werden muss. Wie bei der Migration können die Workerknoten so konfiguriert werden, dass sie über das Standardverwaltungsnetzwerk auf den Storage zugreifen. Alternativ kann ein separates Netzwerk angebunden werden, um Konnektivität für NFS- oder iSCSI-basierte persistente Volumes bereitzustellen. In vielen Fällen wird das standardmäßige Verwaltungs- oder Pod-Netzwerk in OpenShift mit der Initialisierung von API-Aufrufen an das angegebene Storage-System beauftragt. Der CSI-Treiber überprüft , ob das provisionierte Volume über das verfügbare Storage-Netzwerk richtig zugeordnet ist.

Ziehen Sie schließlich den öffentlichen Zugriff auf Anwendungen, die auf der VM ausgeführt werden, oder direkt auf die virtuelle Maschine in Betracht. Nutzende, die ihre Anwendungen noch nicht containerisieren möchten, können Anwendungen, die aktuell auf virtuellen Maschinen ausgeführt werden, wie Anwendungen behandeln, die gemeinsam mit ihnen in Containern ausgeführt werden. Dazu wenden Sie ein Tag auf eine virtuelle Maschine an, das die Anwendung identifiziert, auf die Sie Zugriff gewähren möchten. Anhand dieses Tags erstellen Sie einen Kubernetes-Service für die erforderlichen Ports, die die Anwendung auf der virtuellen Maschine möglicherweise benötigt. Dieser Service kann dann freigegeben werden, indem eine OpenShift-Route erstellt und der direkte Zugriff auf die Anwendung anstatt auf den gesamten virtuellen Guest über das standardmäßige OpenShift-Pod-Netzwerk ermöglicht wird, genau wie bei einer containerisierten Anwendung.

Diese Art des Zugriffs auf einen virtuellen Guest ist ein Übergangsschritt zwischen der Virtualisierung und Containerisierung von Anwendungen. Wenn Sie einen traditionelleren Ansatz mit direktem Zugriff auf das Guest-Betriebssystem einer virtuellen Maschine bevorzugen, können Sie eine Network Attachment Definition und eine Bindung zu einer Linux-Bridge oder einem SR-IOV-Gerät erstellen, die auf praktisch jedem Workerknoten verfügbar ist, der für das Hosting virtueller Guests aktiviert ist. Dadurch wird bestätigt, dass dem virtuellen Guest eine externe IP zugewiesen wird und dass Nutzende über SSH oder das bevorzugte Remotezugriffsprotokoll eine direkte Verbindung zum Guest herstellen können.

Bei der Anbindung zusätzlicher Netzwerke an virtuelle Guests ist Folgendes zu beachten: Die Linux-Bridge, die verfügbaren physischen Schnittstellen und die VLAN-Tags müssen auf jedem Workerknoten im Cluster identisch definiert und verfügbar sein, um die Hochverfügbarkeit der Guest-VMs zu unterstützen, falls sie zu einem anderen Knoten im Cluster migriert werden müssen.

Das Aufzeigen von Möglichkeiten, wie die Netzwerkarchitektur einer bereitgestellten OpenShift Virtualization-Lösung so konfiguriert werden kann, dass sie eine ähnliche Performance und ein ähnliches Verhalten wie andere gängige Hypervisor-Umgebungen wie VMware vSphere bietet, kann für ein ansprechendes Kundenerlebnis bei der Arbeit mit dem Produkt sorgen. Wir bei Red Hat sind davon überzeugt, dass positive IT-Erlebnisse die Kundenzufriedenheit und die  Produktakzeptanz erhöhen, was wiederum die Anwendungsmodernisierung erleichtert.

Wenn Sie mehr über die Anwendungsmodernisierung und die Vorteile von OpenShift Virtualization erfahren möchten, können Sie an einem unserer kommenden Live-Events teilnehmen, wie dem Red Hat Summit Connect  oder der OpenShift Virtualization Road Show. Dort bieten wir einen Produktüberblick und praxisorientierte Labs speziell für OpenShift Virtualization.