Netzwerk

Dieser Abschnitt bietet einen Überblick über die XenServer®-Netzwerkkonfiguration, einschließlich Netzwerken, VLANs und NIC-Bonds. Er erläutert auch, wie Sie Ihre Netzwerkkonfiguration verwalten und Fehler beheben können.

Wichtig:

vSwitch ist der Standard-Netzwerk-Stack von XenServer. Befolgen Sie die Anweisungen unter Netzwerk-Stack-Auswahl, um den Linux-Netzwerk-Stack zu konfigurieren.

Wenn Sie bereits mit den XenServer-Netzwerkkonzepten vertraut sind, können Sie zu Netzwerkkonfiguration verwalten springen, um Informationen zu den folgenden Abschnitten zu erhalten:

• Netzwerke für eigenständige XenServer-Hosts erstellen

• Netzwerke für XenServer-Hosts erstellen, die in einem Ressourcenpool konfiguriert sind

• VLANs für XenServer-Hosts erstellen, entweder eigenständig oder als Teil eines Ressourcenpools

• Bonds für eigenständige XenServer-Hosts erstellen

• Bonds für XenServer-Hosts erstellen, die in einem Ressourcenpool konfiguriert sind

Hinweis:

Der Begriff ‘management interface’ wird verwendet, um die IP-fähige NIC zu bezeichnen, die den Verwaltungsdatenverkehr überträgt. Der Begriff ‘secondary interface’ wird verwendet, um eine IP-fähige NIC zu bezeichnen, die für den Speicherdatenverkehr konfiguriert ist.

Netzwerkunterstützung

XenServer unterstützt bis zu 16 physische Netzwerkschnittstellen (oder bis zu 4 gebündelte Netzwerkschnittstellen) pro Host und bis zu 7 virtuelle Netzwerkschnittstellen pro VM.

Hinweis:

XenServer bietet die automatisierte Konfiguration und Verwaltung von NICs mithilfe der Befehlszeilenschnittstelle (CLI) xe. Bearbeiten Sie die Konfigurationsdateien für die Host-Netzwerke nicht direkt.

Auswahl des Netzwerk-Stacks

Um festzustellen, welcher Netzwerk-Stack konfiguriert ist, führen Sie den folgenden Befehl aus:

xe host-list params=software-version
<!--NeedCopy-->

Suchen Sie in der Befehlsausgabe nach network_backend. Wenn der vSwitch als Netzwerk-Stack konfiguriert ist, sieht die Ausgabe wie folgt aus:

network_backend: openvswitch
<!--NeedCopy-->

Wenn die Linux-Bridge (veraltet) als Netzwerk-Stack konfiguriert ist, sieht die Ausgabe wie folgt aus:

network_backend: bridge
<!--NeedCopy-->

Um den Linux-Bridge-Netzwerk-Stack auszuwählen, führen Sie den folgenden Befehl aus:

xe-switch-network-backend bridge
<!--NeedCopy-->

Starten Sie Ihren Host neu, nachdem Sie diesen Befehl ausgeführt haben.

XenServer-Netzwerkübersicht

Dieser Abschnitt beschreibt die allgemeinen Konzepte der Vernetzung in der XenServer-Umgebung.

XenServer erstellt während der Installation ein Netzwerk für jede physische NIC. Wenn Sie einen Host zu einem Pool hinzufügen, werden die Standardnetzwerke zusammengeführt. Dadurch wird sichergestellt, dass alle physischen NICs mit demselben Gerätenamen an dasselbe Netzwerk angeschlossen sind.

Typischerweise fügen Sie ein Netzwerk hinzu, um ein internes Netzwerk zu erstellen, ein neues VLAN mithilfe einer vorhandenen NIC einzurichten oder eine NIC-Bindung zu erstellen.

Sie können die folgenden verschiedenen Netzwerktypen in XenServer konfigurieren:

• Externe Netzwerke haben eine Zuordnung zu einer physischen Netzwerkschnittstelle. Externe Netzwerke stellen eine Brücke zwischen einer virtuellen Maschine und der mit dem Netzwerk verbundenen physischen Netzwerkschnittstelle bereit. Externe Netzwerke ermöglichen einer virtuellen Maschine, sich mit Ressourcen zu verbinden, die über die physische NIC des Hosts verfügbar sind.

• Gebündelte Netzwerke erstellen eine Bindung zwischen zwei oder mehr NICs, um einen einzelnen, leistungsstarken Kanal zwischen der virtuellen Maschine und dem Netzwerk zu erstellen.

• Einzelserver-Privatnetzwerke haben keine Zuordnung zu einer physischen Netzwerkschnittstelle. Einzelserver-Privatnetzwerke können verwendet werden, um Konnektivität zwischen den virtuellen Maschinen auf einem bestimmten Host bereitzustellen, ohne Verbindung zur Außenwelt.

Hinweis:

Einige Netzwerkoptionen verhalten sich unterschiedlich, wenn sie mit eigenständigen XenServer-Hosts im Vergleich zu Ressourcenpools verwendet werden. Dieser Abschnitt enthält allgemeine Informationen, die sowohl für eigenständige Hosts als auch für Pools gelten, gefolgt von spezifischen Informationen und Verfahren für jeden Fall.

Netzwerkobjekte

Dieser Abschnitt verwendet drei Arten von serverseitigen Softwareobjekten, um Netzwerkentitäten darzustellen. Diese Objekte sind:

• Ein PIF, der eine physische NIC auf einem Host darstellt. PIF-Objekte haben einen Namen und eine Beschreibung, eine UUID, die Parameter der NIC, die sie darstellen, sowie das Netzwerk und den Host, mit denen sie verbunden sind.

• Ein VIF, der eine virtuelle NIC auf einer virtuellen Maschine darstellt. VIF-Objekte haben einen Namen und eine Beschreibung, eine UUID sowie das Netzwerk und die VM, mit denen sie verbunden sind.

• Ein Netzwerk, das ein virtueller Ethernet-Switch auf einem Host ist. Netzwerkobjekte haben einen Namen und eine Beschreibung, eine UUID und die Sammlung von VIFs und PIFs, die mit ihnen verbunden sind.

XenCenter® und die xe CLI ermöglichen Ihnen die Konfiguration von Netzwerkoptionen. Sie können die für Verwaltungsoperationen verwendete NIC steuern und erweiterte Netzwerkfunktionen wie VLANs und NIC-Bonds erstellen.

Netzwerke

Jeder XenServer-Host verfügt über ein oder mehrere Netzwerke, die virtuelle Ethernet-Switches sind. Netzwerke, die keinem PIF zugeordnet sind, gelten als intern. Interne Netzwerke können verwendet werden, um nur Konnektivität zwischen VMs auf einem bestimmten XenServer-Host bereitzustellen, ohne Verbindung zur Außenwelt. Netzwerke, die einem PIF zugeordnet sind, gelten als extern. Externe Netzwerke stellen eine Brücke zwischen VIFs und dem mit dem Netzwerk verbundenen PIF dar und ermöglichen die Konnektivität zu Ressourcen, die über die NIC des PIF verfügbar sind.

VLANs

VLANs, wie im IEEE 802.1Q-Standard definiert, ermöglichen es einem einzelnen physischen Netzwerk, mehrere logische Netzwerke zu unterstützen. XenServer-Hosts unterstützen VLANs auf verschiedene Weisen.

Hinweis:

• Bei Verwendung von GFS2 SR und einem geclusterten Pool darf das Clusternetzwerk nicht auf einem Nicht-Management-VLAN liegen.
• Alle unterstützten VLAN-Konfigurationen sind gleichermaßen auf Pools und eigenständige Hosts sowie auf gebundene und nicht gebundene Konfigurationen anwendbar.

Verwenden von VLANs mit virtuellen Maschinen

Als 802.1Q-VLAN-Trunk-Ports konfigurierte Switch-Ports können mit den XenServer-VLAN-Funktionen verwendet werden, um virtuelle Netzwerkschnittstellen (VIFs) von Gästen mit bestimmten VLANs zu verbinden. In diesem Fall führt der XenServer-Host die VLAN-Tagging-/Untagging-Funktionen für den Gast aus, der keine Kenntnis von einer VLAN-Konfiguration hat.

XenServer-VLANs werden durch zusätzliche PIF-Objekte dargestellt, die VLAN-Schnittstellen entsprechend einem angegebenen VLAN-Tag repräsentieren. Sie können XenServer-Netzwerke mit dem PIF verbinden, das die physische NIC darstellt, um den gesamten Datenverkehr auf der NIC zu sehen. Alternativ können Sie Netzwerke mit einem PIF verbinden, das ein VLAN darstellt, um nur den Datenverkehr mit dem angegebenen VLAN-Tag zu sehen. Sie können ein Netzwerk auch so verbinden, dass es nur den nativen VLAN-Datenverkehr sieht, indem Sie es an VLAN 0 anhängen.

Informationen zum Erstellen von VLANs für XenServer-Hosts, entweder eigenständig oder als Teil eines Ressourcenpools, finden Sie unter Erstellen von VLANs.

Wenn der Gast die VLAN-Tagging- und Untagging-Funktionen ausführen soll, muss der Gast die VLANs kennen. Konfigurieren Sie beim Einrichten des Netzwerks für Ihre VMs die Switch-Ports als VLAN-Trunk-Ports, erstellen Sie jedoch keine VLANs für den XenServer-Host. Verwenden Sie stattdessen VIFs in einem normalen, nicht-VLAN-Netzwerk.

Verwenden von VLANs mit Verwaltungsschnittstellen

Die Verwaltungsschnittstelle kann in einem VLAN über einen als Trunk-Port oder Access-Mode-Port konfigurierten Switch-Port konfiguriert werden. Verwenden Sie XenCenter oder die xe-CLI, um ein VLAN einzurichten und es zur Verwaltungsschnittstelle zu machen. Weitere Informationen finden Sie unter Verwaltungsschnittstelle.

Verwenden von VLANs mit dedizierten Speicher-NICs

Dedizierte Speicher-NICs können so konfiguriert werden, dass sie native VLAN- oder Access-Mode-Ports verwenden, wie im vorherigen Abschnitt für Verwaltungsschnittstellen beschrieben. Dedizierte Speicher-NICs werden auch als IP-fähige NICs oder sekundäre Schnittstellen bezeichnet. Sie können dedizierte Speicher-NICs so konfigurieren, dass sie Trunk-Ports und XenServer-VLANs verwenden, wie im vorherigen Abschnitt für virtuelle Maschinen beschrieben. Weitere Informationen finden Sie unter Konfigurieren einer dedizierten Speicher-NIC.

Kombinieren von Verwaltungsschnittstellen und Gast-VLANs auf einer einzelnen Host-NIC

Ein einzelner Switch-Port kann sowohl mit Trunk- als auch mit nativen VLANs konfiguriert werden, sodass eine Host-NIC für eine Verwaltungsschnittstelle (im nativen VLAN) und zum Verbinden von Gast-VIFs mit bestimmten VLAN-IDs verwendet werden kann.

Jumbo-Frames

Jumbo-Frames können verwendet werden, um die Leistung des Datenverkehrs in Speichernetzwerken, VM-Netzwerken und im Verwaltungsnetzwerk zu optimieren. Jumbo-Frames sind Ethernet-Frames, die mehr als 1.500 Byte Nutzdaten enthalten. Jumbo-Frames werden typischerweise verwendet, um einen besseren Durchsatz zu erzielen, die Last auf dem Systembus-Speicher zu reduzieren und den CPU-Overhead zu verringern.

Hinweis:

XenServer unterstützt Jumbo-Frames nur, wenn vSwitch als Netzwerk-Stack auf allen Hosts im Pool verwendet wird.

Anforderungen für die Verwendung von Jumbo Frames

Beachten Sie bei der Verwendung von Jumbo Frames Folgendes:

• Jumbo Frames werden auf Poolebene konfiguriert

• vSwitch muss auf allen Hosts im Pool als Netzwerk-Backend konfiguriert sein

• Jedes Gerät im Subnetz muss für die Verwendung von Jumbo Frames konfiguriert sein

Um Jumbo Frames zu verwenden, stellen Sie die Maximum Transmission Unit (MTU) auf einen Wert zwischen 1500 und 9216 ein. Sie können XenCenter oder die xe CLI verwenden, um die MTU einzustellen.

NIC-Bonds

NIC-Bonds, manchmal auch als NIC-Teaming bezeichnet, verbessern die Ausfallsicherheit und Bandbreite des XenServer-Hosts, indem sie Administratoren ermöglichen, zwei oder mehr NICs zusammen zu konfigurieren. NIC-Bonds funktionieren logisch als eine Netzwerkkarte, und alle gebündelten NICs teilen sich eine MAC-Adresse.

Fällt eine NIC im Bond aus, wird der Netzwerkverkehr des Hosts automatisch über die zweite NIC umgeleitet. XenServer unterstützt bis zu acht gebündelte Netzwerke.

XenServer unterstützt Active-Active-, Active-Passive- und LACP-Bonding-Modi. Die Anzahl der unterstützten NICs und der unterstützte Bonding-Modus variieren je nach Netzwerk-Stack:

• LACP-Bonding ist nur für den vSwitch verfügbar, während Active-Active und Active-Passive sowohl für den vSwitch als auch für die Linux-Bridge verfügbar sind.

• Wenn der vSwitch der Netzwerk-Stack ist, können Sie entweder zwei, drei oder vier NICs bündeln.

• Wenn die Linux-Bridge der Netzwerk-Stack ist, können Sie nur zwei NICs bündeln.

Hinweis:

Der Linux-Bridge-Netzwerk-Stack ist veraltet und wird in einer zukünftigen Version entfernt.

Alle Bonding-Modi unterstützen Failover. Allerdings erlauben nicht alle Modi, dass alle Links für alle Verkehrstypen aktiv sind. XenServer unterstützt das Bonding der folgenden NIC-Typen:

• NICs (nicht-Management). Sie können NICs bündeln, die XenServer ausschließlich für VM-Traffic verwendet. Das Bündeln dieser NICs bietet nicht nur Ausfallsicherheit, sondern gleicht auch den Traffic mehrerer VMs zwischen den NICs aus.

• Managementschnittstellen. Sie können eine Managementschnittstelle mit einer anderen NIC bündeln, sodass die zweite NIC ein Failover für den Management-Traffic bereitstellt. Obwohl die Konfiguration einer LACP-Link-Aggregation ein Lastenausgleich für den Management-Traffic bietet, tut dies aktives-aktives NIC-Bonding nicht. Sie können ein VLAN auf gebündelten NICs erstellen, und die Host-Managementschnittstelle kann diesem VLAN zugewiesen werden.

• Sekundäre Schnittstellen. Sie können NICs bündeln, die Sie als sekundäre Schnittstellen konfiguriert haben (z. B. für Speicher). Für die meisten iSCSI-Software-Initiator-Speicher empfehlen wir jedoch die Konfiguration von Multipathing anstelle von NIC-Bonding, wie im Entwerfen von XenServer-Netzwerkkonfigurationen beschrieben.

  In diesem Abschnitt wird der Begriff IP-basierter Speichertraffic verwendet, um iSCSI- und NFS-Traffic zusammenfassend zu beschreiben.

Sie können ein Bond erstellen, wenn ein VIF bereits eine der Schnittstellen verwendet, die gebündelt werden sollen: Der VM-Traffic migriert automatisch zur neuen gebündelten Schnittstelle.

In XenServer stellt ein zusätzliches PIF ein NIC-Bond dar. XenServer NIC-Bonds umfassen die zugrunde liegenden physischen Geräte (PIFs) vollständig.

Hinweise:

• Das Erstellen eines Bonds, das nur eine NIC enthält, wird nicht unterstützt.
• Die gebündelten NICs können unterschiedliche Modelle voneinander sein.
• NIC-Bonds werden auf NICs, die FCoE-Traffic übertragen, nicht unterstützt.

Best Practices

Befolgen Sie diese Best Practices beim Einrichten Ihrer NIC-Bonds:

• Verbinden Sie die Links des Bonds mit verschiedenen physischen Netzwerk-Switches, nicht nur mit Ports desselben Switches.
• Stellen Sie sicher, dass die separaten Switches Strom von verschiedenen, unabhängigen Stromverteilungseinheiten (PDUs) beziehen.
• Platzieren Sie die PDUs in Ihrem Rechenzentrum, wenn möglich, auf verschiedenen Phasen der Stromversorgung oder sogar auf Stromversorgungen, die von verschiedenen Versorgungsunternehmen bereitgestellt werden.
• Erwägen Sie die Verwendung von unterbrechungsfreien Stromversorgungen, um sicherzustellen, dass die Netzwerk-Switches und Hosts weiterhin funktionieren oder im Falle eines Stromausfalls ordnungsgemäß heruntergefahren werden können.

Diese Maßnahmen erhöhen die Ausfallsicherheit gegenüber Software-, Hardware- oder Stromausfällen, die Ihre Netzwerk-Switches beeinträchtigen können.

Wichtige Punkte zur IP-Adressierung

Gebündelte NICs haben entweder eine IP-Adresse oder keine IP-Adressen, wie folgt:

• Management- und Speichernetzwerke.

  • Wenn Sie eine Managementschnittstelle oder eine sekundäre Schnittstelle bündeln, wird der Bündelung eine einzelne IP-Adresse zugewiesen. Das heißt, jede NIC hat keine eigene IP-Adresse. XenServer behandelt die beiden NICs als eine logische Verbindung.

  • Wenn Bündel für Nicht-VM-Verkehr verwendet werden, z. B. zur Verbindung mit gemeinsam genutztem Netzwerkspeicher oder XenCenter für die Verwaltung, konfigurieren Sie eine IP-Adresse für das Bündel. Wenn Sie jedoch bereits einer der NICs eine IP-Adresse zugewiesen haben (d. h. eine Managementschnittstelle oder eine sekundäre Schnittstelle erstellt haben), wird diese IP-Adresse automatisch dem gesamten Bündel zugewiesen.

  • Wenn Sie eine Managementschnittstelle oder eine sekundäre Schnittstelle mit einer NIC ohne IP-Adresse bündeln, übernimmt das Bündel die IP-Adresse der jeweiligen Schnittstelle.

  • Wenn Sie eine getaggte VLAN-Managementschnittstelle und eine sekundäre Schnittstelle bündeln, wird das Management-VLAN auf dieser gebündelten NIC erstellt.

• VM-Netzwerke. Wenn gebündelte NICs für den VM-Verkehr verwendet werden, müssen Sie keine IP-Adresse für das Bündel konfigurieren. Dies liegt daran, dass das Bündel auf Schicht 2 des OSI-Modells, der Sicherungsschicht, arbeitet und auf dieser Schicht keine IP-Adressierung verwendet wird. IP-Adressen für virtuelle Maschinen sind mit VIFs verknüpft.

Bonding-Typen

XenServer bietet drei verschiedene Arten von Bonds, die alle entweder über die CLI oder XenCenter konfiguriert werden können:

• Active-Active-Modus, bei dem der VM-Verkehr zwischen den gebündelten NICs ausgeglichen wird. Siehe Active-Active-Bonding.

• Active-Passive-Modus, bei dem nur eine NIC aktiv Datenverkehr überträgt. Siehe Active-Passive-Bonding.

• LACP Link Aggregation, bei der aktive und Standby-NICs zwischen dem Switch und dem Host ausgehandelt werden. Siehe LACP Link Aggregation Control Protocol Bonding.

Hinweis:

Bonding wird mit einer Up-Verzögerung von 31.000 ms und einer Down-Verzögerung von 200 ms eingerichtet. Die scheinbar lange Up-Verzögerung ist beabsichtigt, da einige Switches Zeit benötigen, um den Port zu aktivieren. Ohne Verzögerung kann der Bond, wenn eine Verbindung nach einem Ausfall wiederhergestellt wird, den Datenverkehr wieder auf diese umleiten, bevor der Switch bereit ist, Datenverkehr weiterzuleiten. Um beide Verbindungen zu einem anderen Switch zu verschieben, verschieben Sie eine, warten Sie dann 31 Sekunden, bis sie wieder verwendet wird, bevor Sie die andere verschieben. Informationen zum Ändern der Verzögerung finden Sie unter Ändern der Up-Verzögerung für Bonds.

Bond-Status

XenServer stellt den Status von Bonds in den Ereignisprotokollen für jeden Host bereit. Wenn eine oder mehrere Verbindungen in einem Bond ausfallen oder wiederhergestellt werden, wird dies im Ereignisprotokoll vermerkt. Ebenso können Sie den Status der Verbindungen eines Bonds abfragen, indem Sie den Parameter links-up verwenden, wie im folgenden Beispiel gezeigt:

xe bond-param-get uuid=bond_uuid param-name=links-up
<!--NeedCopy-->

XenServer überprüft den Status der Verbindungen in Bonds etwa alle fünf Sekunden. Wenn daher innerhalb des Fünf-Sekunden-Fensters weitere Verbindungen im Bond ausfallen, wird der Fehler erst bei der nächsten Statusprüfung protokolliert.

Bonding-Ereignisprotokolle werden in der XenCenter-Ansicht Benachrichtigungen > Ereignisse angezeigt. Für Benutzer, die XenCenter nicht verwenden, werden Ereignisprotokolle auch in /var/log/xensource.log auf jedem Host angezeigt.

Aktiv-Aktiv-Bonding

Aktiv-Aktiv ist eine Aktiv/Aktiv-Konfiguration für Gast-Datenverkehr: Beide NICs können VM-Datenverkehr gleichzeitig routen. Wenn Bonds für Verwaltungsdatenverkehr verwendet werden, kann nur eine NIC im Bond Datenverkehr routen: Die andere NIC bleibt ungenutzt und bietet Failover-Unterstützung. Der Aktiv-Aktiv-Modus ist der Standard-Bonding-Modus, wenn entweder die Linux-Bridge oder der vSwitch-Netzwerk-Stack aktiviert ist.

Wenn Aktiv-Aktiv-Bonding mit der Linux-Bridge verwendet wird, können Sie nur zwei NICs bündeln. Bei Verwendung des vSwitch als Netzwerk-Stack können Sie entweder zwei, drei oder vier NICs im Aktiv-Aktiv-Modus bündeln. Im Aktiv-Aktiv-Modus ist das Bündeln von drei oder vier NICs jedoch nur für VM-Datenverkehr von Vorteil, wie in der folgenden Abbildung gezeigt.

XenServer kann Datenverkehr nur über zwei oder mehr NICs senden, wenn dem Bond mehr als eine MAC-Adresse zugeordnet ist. XenServer kann die virtuellen MAC-Adressen im VIF verwenden, um Datenverkehr über mehrere Links zu senden. Im Einzelnen:

• VM-Datenverkehr. Wenn Sie Bonding auf NICs aktivieren, die nur VM- (Gast-)Datenverkehr übertragen, sind alle Links aktiv, und NIC-Bonding kann den verteilten VM-Datenverkehr über die NICs ausgleichen. Der Datenverkehr eines einzelnen VIFs wird niemals zwischen NICs aufgeteilt.

• Verwaltungs- oder Speicherdatenverkehr. Nur einer der Links (NICs) im Bond ist aktiv, und die anderen NICs bleiben ungenutzt, es sei denn, der Datenverkehr fällt auf sie aus. Das Konfigurieren einer Verwaltungsschnittstelle oder einer sekundären Schnittstelle in einem gebündelten Netzwerk bietet Ausfallsicherheit.

• Gemischter Datenverkehr. Wenn die gebündelte NIC eine Mischung aus IP-basiertem Speicherdatenverkehr und Gast-Datenverkehr überträgt, werden nur der Gast- und der Kontrolldomänen-Datenverkehr lastverteilt. Die Kontrolldomäne ist im Wesentlichen eine virtuelle Maschine, daher verwendet sie eine NIC wie die anderen Gäste. XenServer gleicht den Datenverkehr der Kontrolldomäne auf die gleiche Weise aus wie den VM-Datenverkehr.

Lastverteilung

XenServer verteilt den Datenverkehr zwischen den NICs mithilfe der Quell-MAC-Adresse des Pakets. Da für den Verwaltungsdatenverkehr nur eine Quell-MAC-Adresse vorhanden ist, kann der Aktiv-Aktiv-Modus nur eine NIC verwenden, und der Datenverkehr wird nicht ausgeglichen. Die Lastverteilung basiert auf zwei Faktoren:

• Die virtuelle Maschine und die zugehörige VIF, die den Datenverkehr sendet oder empfängt

• Die Menge der gesendeten Daten (in Kilobyte).

XenServer bewertet die Datenmenge (in Kilobyte), die jede NIC sendet und empfängt. Wenn die über eine NIC gesendete Datenmenge die über die andere NIC gesendete Datenmenge überschreitet, gleicht XenServer neu aus, welche VIFs welche NICs verwenden. Die gesamte Last der VIF wird übertragen. Die Last einer VIF wird niemals auf zwei NICs aufgeteilt.

Obwohl die Aktiv-Aktiv-NIC-Bonding eine Lastverteilung für den Datenverkehr mehrerer VMs bieten kann, kann sie einer einzelnen VM nicht den Durchsatz von zwei NICs bieten. Jede VIF verwendet jeweils nur einen der Links in einem Bond. Da XenServer den Datenverkehr regelmäßig neu ausgleicht, sind VIFs keiner bestimmten NIC im Bond dauerhaft zugewiesen.

Der Aktiv-Aktiv-Modus wird manchmal als Source Load Balancing (SLB) Bonding bezeichnet, da XenServer SLB verwendet, um die Last über gebündelte Netzwerkschnittstellen zu verteilen. SLB leitet sich vom Open-Source-Modus Adaptive Load Balancing (ALB) ab und nutzt die ALB-Funktionalität, um die Last dynamisch über NICs neu zu verteilen.

Beim Neuausgleich wird die Anzahl der Bytes, die über jede sekundäre (Schnittstelle) gehen, über einen bestimmten Zeitraum verfolgt. Wenn ein zu sendendes Paket eine neue Quell-MAC-Adresse enthält, wird es der sekundären Schnittstelle mit der geringsten Auslastung zugewiesen. Der Datenverkehr wird in regelmäßigen Abständen neu ausgeglichen.

Jede MAC-Adresse hat eine entsprechende Last, und XenServer kann je nach der Datenmenge, die eine VM sendet und empfängt, ganze Lasten zwischen NICs verschieben. Für Aktiv-Aktiv-Datenverkehr kann der gesamte Datenverkehr einer VM nur über eine NIC gesendet werden.

Hinweis:

Aktiv-Aktiv-Bonding erfordert keine Switch-Unterstützung für EtherChannel oder 802.3ad (LACP).

Aktiv-Passiv-Bonding

Ein Aktiv-Passiv-Bond leitet den Datenverkehr nur über eine der NICs. Wenn die aktive NIC die Netzwerkverbindung verliert, wird der Datenverkehr auf die andere NIC im Bond umgeleitet. Aktiv-Passiv-Bonds leiten den Datenverkehr über die aktive NIC. Der Datenverkehr wechselt zur passiven NIC, wenn die aktive NIC ausfällt.

Aktiv-Passiv-Bonding ist in der Linux-Bridge und im vSwitch-Netzwerk-Stack verfügbar. Bei Verwendung mit der Linux-Bridge können Sie zwei NICs miteinander verbinden. Bei Verwendung mit dem vSwitch können Sie nur zwei, drei oder vier NICs miteinander verbinden. Unabhängig vom Datenverkehrstyp ist jedoch beim Bonding von NICs im Aktiv-Passiv-Modus nur ein Link aktiv, und es gibt keine Lastverteilung zwischen den Links.

Die folgende Abbildung zeigt zwei gebündelte NICs, die im Aktiv-Passiv-Modus konfiguriert sind.

Der Aktiv-Aktiv-Modus ist die Standard-Bonding-Konfiguration in XenServer. Wenn Sie Bonds über die CLI konfigurieren, müssen Sie einen Parameter für den Aktiv-Passiv-Modus angeben. Andernfalls wird ein Aktiv-Aktiv-Bond erstellt. Sie müssen den Aktiv-Passiv-Modus nicht konfigurieren, weil ein Netzwerk Management- oder Speicherverkehr überträgt.

Aktiv-Passiv kann eine gute Wahl für die Ausfallsicherheit sein, da es mehrere Vorteile bietet. Bei Aktiv-Passiv-Bonds bewegt sich der Datenverkehr nicht zwischen den NICs. Ebenso ermöglicht das Aktiv-Passiv-Bonding die Konfiguration von zwei Switches für Redundanz, erfordert aber kein Stacking. Wenn der Management-Switch ausfällt, können gestapelte Switches einen Single Point of Failure darstellen.

Der Aktiv-Passiv-Modus erfordert keine Switch-Unterstützung für EtherChannel oder 802.3ad (LACP).

Erwägen Sie die Konfiguration des Aktiv-Passiv-Modus in Situationen, in denen Sie keinen Lastausgleich benötigen oder wenn Sie den Datenverkehr nur über eine NIC senden möchten.

Wichtig:

Nachdem Sie VIFs erstellt haben oder Ihr Pool in Produktion ist, sollten Sie vorsichtig sein, wenn Sie Bonds ändern oder erstellen.

LACP Link Aggregation Control Protocol Bonding

LACP (Link Aggregation Control Protocol) ist eine Art von Bonding, das eine Gruppe von Ports bündelt und diese wie einen einzigen logischen Kanal behandelt. LACP-Bonding bietet Failover und kann die insgesamt verfügbare Bandbreite erhöhen.

Im Gegensatz zu anderen Bonding-Modi erfordert LACP-Bonding die Konfiguration beider Seiten der Links: das Erstellen eines Bonds auf dem Host und das Erstellen einer Link Aggregation Group (LAG) für jeden Bond auf dem Switch. Siehe Switch-Konfiguration für LACP-Bonds. Sie müssen den vSwitch als Netzwerk-Stack konfigurieren, um LACP-Bonding zu verwenden. Außerdem müssen Ihre Switches den IEEE 802.3ad-Standard unterstützen.

Ein Vergleich von Aktiv-Aktiv-SLB-Bonding und LACP-Bonding:

Aktiv-Aktiv-SLB-Bonding

Vorteile:

• Kann mit jedem Switch auf der Hardware Compatibility List verwendet werden.
• Erfordert keine Switches, die Stacking unterstützen.
• Unterstützt vier NICs.

Überlegungen:

• Optimaler Lastausgleich erfordert mindestens eine NIC pro VIF.
• Speicher- oder Verwaltungsdatenverkehr kann nicht auf mehrere NICs aufgeteilt werden.
• Lastausgleich erfolgt nur, wenn mehrere MAC-Adressen vorhanden sind.

LACP-Bonding

Vorteile:

• Alle Links können unabhängig vom Datenverkehrstyp aktiv sein.
• Der Lastausgleich hängt nicht von Quell-MAC-Adressen ab, sodass alle Datenverkehrstypen ausgeglichen werden können.

Überlegungen:

• Switches müssen den IEEE 802.3ad-Standard unterstützen.
• Erfordert eine Konfiguration auf Switch-Seite.
• Nur für den vSwitch unterstützt.
• Erfordert einen einzelnen Switch oder einen gestapelten Switch.

Lastausgleich des Datenverkehrs

XenServer unterstützt zwei LACP-Bonding-Hashing-Typen. Der Begriff Hashing beschreibt, wie die NICs und der Switch den Datenverkehr verteilen – (1) Lastausgleich basierend auf IP und Port von Quell- und Zieladressen und (2) Lastausgleich basierend auf der Quell-MAC-Adresse.

Abhängig vom Hashing-Typ und dem Datenverkehrsmuster kann LACP-Bonding den Datenverkehr potenziell gleichmäßiger verteilen als Active-Active-NIC-Bonding.

Hinweis:

Sie konfigurieren die Einstellungen für ausgehenden und eingehenden Datenverkehr separat auf dem Host und dem Switch: Die Konfiguration muss nicht auf beiden Seiten übereinstimmen.

Lastausgleich basierend auf IP und Port von Quell- und Zieladressen.

Dieser Hashing-Typ ist der Standard-LACP-Bonding-Hashing-Algorithmus. Wenn es eine Variation in den Quell- oder Ziel-IP- oder Portnummern gibt, kann der Datenverkehr von einem Gast über zwei Links verteilt werden.

Wenn eine virtuelle Maschine mehrere Anwendungen ausführt, die unterschiedliche IP- oder Portnummern verwenden, verteilt dieser Hashing-Typ den Datenverkehr über mehrere Links. Die Verteilung des Datenverkehrs gibt dem Gast die Möglichkeit, den aggregierten Durchsatz zu nutzen. Dieser Hashing-Typ ermöglicht es einem Gast, den gesamten Durchsatz mehrerer NICs zu nutzen.

Wie in der folgenden Abbildung gezeigt, kann dieser Hashing-Typ den Datenverkehr von zwei verschiedenen Anwendungen auf einer virtuellen Maschine auf zwei verschiedene NICs verteilen.

Die Konfiguration von LACP-Bonding basierend auf IP und Port von Quell- und Zieladresse ist vorteilhaft, wenn Sie den Datenverkehr von zwei verschiedenen Anwendungen auf derselben VM ausgleichen möchten. Zum Beispiel, wenn nur eine virtuelle Maschine für die Verwendung eines Bonds von drei NICs konfiguriert ist.

Der Lastausgleichsalgorithmus für diesen Hashing-Typ verwendet fünf Faktoren, um den Datenverkehr auf die NICs zu verteilen: die Quell-IP-Adresse, die Quell-Portnummer, die Ziel-IP-Adresse, die Ziel-Portnummer und die Quell-MAC-Adresse.

Lastausgleich basierend auf der Quell-MAC-Adresse.

Diese Art des Lastausgleichs funktioniert gut, wenn mehrere virtuelle Maschinen auf demselben Host vorhanden sind. Der Datenverkehr wird basierend auf der virtuellen MAC-Adresse der VM ausgeglichen, von der der Datenverkehr stammt. XenServer sendet ausgehenden Datenverkehr mit demselben Algorithmus wie beim Active-Active-Bonding. Der Datenverkehr, der vom selben Gast kommt, wird nicht über mehrere NICs aufgeteilt. Daher ist dieser Hashing-Typ nicht geeignet, wenn weniger VIFs als NICs vorhanden sind: Der Lastausgleich ist nicht optimal, da der Datenverkehr nicht über die NICs aufgeteilt werden kann.

![Diese Abbildung zeigt, wie bei Verwendung von LACP-Bonding und Aktivierung von LACP basierend auf der Quell-MAC-Adresse als Hashing-Typ, wenn die Anzahl der NICs die Anzahl der VIFs übersteigt, nicht alle NICs verwendet werden. Da es drei NICs und zwei VMs gibt, können nur zwei NICs gleichzeitig verwendet werden. Daher kann der maximale Bond-Durchsatz nicht erreicht werden. Die Pakete von einer VM können nicht auf mehrere VMs aufgeteilt werden. ]](/de-de/xenserver/8/media/lacp-option-a.png)

Switch-Konfiguration

Je nach Redundanzanforderungen können Sie die NICs im Bond entweder an dieselben oder an separate gestapelte Switches anschließen. Wenn Sie eine der NICs an einen zweiten, redundanten Switch anschließen und eine NIC oder ein Switch ausfällt, wird der Datenverkehr auf die andere NIC umgeleitet. Das Hinzufügen eines zweiten Switches verhindert einen Single Point of Failure in Ihrer Konfiguration auf folgende Weisen:

• Wenn Sie eine der Verbindungen in einer gebündelten Verwaltungsschnittstelle an einen zweiten Switch anschließen und der Switch ausfällt, bleibt das Verwaltungsnetzwerk online und die Hosts können weiterhin miteinander kommunizieren.

• Wenn Sie eine Verbindung (für jede Art von Datenverkehr) an einen zweiten Switch anschließen und die NIC oder der Switch ausfällt, bleiben die virtuellen Maschinen im Netzwerk, da ihr Datenverkehr auf die andere NIC/den anderen Switch umgeleitet wird.

Verwenden Sie gestapelte Switches, wenn Sie gebündelte NICs an mehrere Switches anschließen möchten und den LACP-Bonding-Modus konfiguriert haben. Der Begriff „gestapelte Switches“ beschreibt die Konfiguration mehrerer physischer Switches, die als ein einziger logischer Switch fungieren. Sie müssen die Switches physisch und über die Switch-Verwaltungssoftware miteinander verbinden, damit die Switches gemäß den Richtlinien des Switch-Herstellers als eine einzige logische Switching-Einheit fungieren. Typischerweise ist Switch-Stacking nur über proprietäre Erweiterungen verfügbar, und Switch-Anbieter vermarkten diese Funktionalität möglicherweise unter verschiedenen Begriffen.

Hinweis:

Wenn Sie Probleme mit aktiv-aktiven Bonds haben, kann die Verwendung von gestapelten Switches erforderlich sein. Aktiv-passive Bonds erfordern keine gestapelten Switches.

Switch-Konfiguration für LACP-Bonds

Da die spezifischen Details der Switch-Konfiguration je nach Hersteller variieren, gibt es einige wichtige Punkte, die bei der Konfiguration von Switches für die Verwendung mit LACP-Bonds zu beachten sind:

• Der Switch muss LACP und den IEEE 802.3ad-Standard unterstützen.

• Wenn Sie die LAG-Gruppe auf dem Switch erstellen, müssen Sie für jeden LACP-Bond auf dem Host eine LAG-Gruppe erstellen. Wenn Sie beispielsweise einen Pool mit fünf Hosts haben und einen LACP-Bond auf den NICs 4 und 5 jedes Hosts erstellt haben, müssen Sie fünf LAG-Gruppen auf dem Switch erstellen. Eine Gruppe für jeden Satz von Ports, die den NICs auf dem Host entsprechen.

  Möglicherweise müssen Sie auch Ihre VLAN-ID zu Ihrer LAG-Gruppe hinzufügen.

• XenServer LACP-Bonds erfordern, dass die Einstellung „Static Mode“ in der LAG-Gruppe auf „Disabled“ gesetzt ist.

Wie bereits unter Switch-Konfiguration erwähnt, sind Stacking-Switches erforderlich, um LACP-Bonds mit mehreren Switches zu verbinden.

Anfängliche Netzwerkkonfiguration nach der Einrichtung

Die Netzwerkkonfiguration des XenServer-Hosts wird während der Erstinstallation des Hosts festgelegt. Optionen wie die IP-Adresskonfiguration (DHCP/statisch), die als Verwaltungsschnittstelle verwendete NIC und der Hostname werden basierend auf den während der Installation angegebenen Werten festgelegt.

Wenn ein Host mehrere NICs hat, hängt die nach der Installation vorhandene Konfiguration davon ab, welche NIC während der Installation für Verwaltungsoperationen ausgewählt wurde:

• Für jede NIC im Host werden PIFs erstellt

• Der PIF der als Verwaltungsschnittstelle ausgewählten NIC wird mit den während der Installation angegebenen IP-Adressierungsoptionen konfiguriert

• Für jeden PIF wird ein Netzwerk erstellt (“Netzwerk 0”, “Netzwerk 1” usw.)

• Jedes Netzwerk ist mit einem PIF verbunden

• Die IP-Adressierungsoptionen bleiben für alle PIFs außer dem als Verwaltungsschnittstelle verwendeten PIF unkonfiguriert

Wenn ein Host eine einzelne NIC hat, ist nach der Installation die folgende Konfiguration vorhanden:

• Ein einzelner PIF wird erstellt, der der einzelnen NIC des Hosts entspricht

• Der PIF wird mit den während der Installation angegebenen IP-Adressierungsoptionen konfiguriert, um die Verwaltung des Hosts zu ermöglichen

• Der PIF ist für die Verwendung in Host-Verwaltungsoperationen festgelegt

• Ein einzelnes Netzwerk, Netzwerk 0, wird erstellt

• Netzwerk 0 ist mit dem PIF verbunden, um externe Konnektivität zu VMs zu ermöglichen

Wenn eine Installation von XenServer in einem getaggten VLAN-Netzwerk durchgeführt wird, ist nach der Installation die folgende Konfiguration vorhanden:

• Für jede NIC im Host werden PIFs erstellt

• Die PIF für das getaggte VLAN auf der als Verwaltungsschnittstelle ausgewählten NIC wird mit der während der Installation angegebenen IP-Adresskonfiguration konfiguriert.

• Für jede PIF wird ein Netzwerk erstellt (zum Beispiel: Netzwerk 1, Netzwerk 2 usw.). Ein zusätzliches VLAN-Netzwerk wird erstellt (zum Beispiel für ein Pool-weites Netzwerk, das mit eth0 auf VLAN<TAG> verbunden ist).

• Jedes Netzwerk ist mit einer PIF verbunden. Die VLAN-PIF wird für Host-Verwaltungsvorgänge verwendet.

In beiden Fällen ermöglicht die resultierende Netzwerkkonfiguration die Verbindung zum XenServer-Host über XenCenter, die xe CLI und jede andere Verwaltungssoftware, die auf separaten Maschinen läuft, über die IP-Adresse der Verwaltungsschnittstelle. Die Konfiguration bietet auch externe Netzwerkanbindung für auf dem Host erstellte VMs.

Die für Verwaltungsvorgänge verwendete PIF ist die einzige PIF, die während der XenServer-Installation jemals mit einer IP-Adresse konfiguriert wird. Die externe Netzwerkanbindung für VMs wird durch die Überbrückung von PIFs zu VIFs mithilfe des Netzwerkobjekts erreicht, das als virtueller Ethernet-Switch fungiert.

Die für Netzwerkfunktionen wie VLANs, NIC-Bonds und die Dedizierung einer NIC für den Speicherverkehr erforderlichen Schritte werden in den folgenden Abschnitten behandelt.

Netzwerkkonfiguration ändern

Sie können Ihre Netzwerkkonfiguration ändern, indem Sie das Netzwerkobjekt modifizieren. Dazu führen Sie einen Befehl aus, der entweder das Netzwerkobjekt oder die VIF betrifft.

Netzwerkobjekt modifizieren

Sie können Aspekte eines Netzwerks ändern, wie z. B. die Frame-Größe (MTU), den Namen (name-label), die Beschreibung (name-description), den Zweck und andere Werte. Verwenden Sie den Befehl xe network-param-set und die zugehörigen Parameter, um die Werte zu ändern.

Wenn Sie den Befehl xe network-param-set ausführen, ist der einzige erforderliche Parameter uuid.

Optionale Parameter umfassen:

• default_locking_mode. Siehe Vereinfachung der VIF-Sperrmoduskonfiguration in der Cloud.

• name-label

• name-description

• MTU

• purpose. Siehe Hinzufügen eines Zwecks zu einem Netzwerk.

• other-config

Wenn für einen Parameter kein Wert angegeben wird, wird der Parameter auf einen Nullwert gesetzt. Um ein (Schlüssel, Wert)-Paar in einem Kartenparameter festzulegen, verwenden Sie die Syntax map-param:key=value.

Ändern der Up-Verzögerung für Bonds

Bonding wird standardmäßig mit einer Up-Verzögerung von 31.000 ms eingerichtet, um zu verhindern, dass der Datenverkehr nach einem Ausfall auf eine NIC neu verteilt wird. Obwohl sie scheinbar lang ist, ist die Up-Verzögerung für alle Bonding-Modi wichtig und nicht nur für Active-Active.

Wenn Sie jedoch die geeigneten Einstellungen für Ihre Umgebung kennen, können Sie die Up-Verzögerung für Bonds mithilfe des folgenden Verfahrens ändern.

Legen Sie die Up-Verzögerung in Millisekunden fest:

xe pif-param-set uuid=<uuid of bond interface PIF> other-config:bond-updelay=<delay in ms>
<!--NeedCopy-->

Damit die Änderung wirksam wird, müssen Sie die physische Schnittstelle trennen und dann wieder anschließen:

xe pif-unplug uuid=<uuid of bond interface PIF>
<!--NeedCopy-->

xe pif-plug uuid=<uuid of bond interface PIF>
<!--NeedCopy-->