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.
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 eine automatisierte Konfiguration und Verwaltung von NICs über die xe-Befehlszeilenschnittstelle (CLI). Bearbeiten Sie die Netzwerkkonfigurationsdateien des Hosts nicht direkt.
XenServer-Netzwerkübersicht
Dieser Abschnitt beschreibt die allgemeinen Konzepte der Vernetzung in der XenServer-Umgebung.
XenServer erstellt während der Installation für jede physische NIC ein Netzwerk. 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 mit demselben Netzwerk verbunden sind.
Typischerweise fügen Sie ein Netzwerk hinzu, um ein internes Netzwerk zu erstellen, ein neues VLAN mit einer vorhandenen NIC einzurichten oder eine NIC-Bindung zu erstellen.
Sie können die folgenden verschiedenen Netzwerktypen in XenServer konfigurieren:
-
Externe Netzwerke sind mit einer physischen Netzwerkschnittstelle verbunden. Externe Netzwerke stellen eine Brücke zwischen einer virtuellen Maschine und der mit dem Netzwerk verbundenen physischen Netzwerkschnittstelle dar. Externe Netzwerke ermöglichen einer virtuellen Maschine die Verbindung zu Ressourcen, die über die physische NIC des Hosts verfügbar sind.
-
Gebündelte Netzwerke (Bonded Networks) erstellen eine Bindung zwischen zwei oder mehr NICs, um einen einzigen, leistungsstarken Kanal zwischen der virtuellen Maschine und dem Netzwerk zu schaffen.
-
Private Einzelserver-Netzwerke (Single-Server Private Networks) haben keine Verbindung zu einer physischen Netzwerkschnittstelle. Private Einzelserver-Netzwerke 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 bei der Verwendung mit eigenständigen XenServer-Hosts anders als bei Ressourcenpools. 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, das 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, das 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 sowie 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 Konnektivität nur 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 bereit und ermöglichen so die Konnektivität zu Ressourcen, die über die NIC des PIF verfügbar sind.
VLANs
VLANs, wie sie durch den IEEE 802.1Q-Standard definiert sind, 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 sich das Clusternetzwerk nicht auf einem Nicht-Management-VLAN befinden.
- Alle unterstützten VLAN-Konfigurationen sind gleichermaßen anwendbar auf Pools und eigenständige Hosts sowie auf gebündelte und nicht gebündelte Konfigurationen.
Verwenden von VLANs mit virtuellen Maschinen
Switch-Ports, die als 802.1Q VLAN-Trunk-Ports konfiguriert sind, können mit den XenServer-VLAN-Funktionen verwendet werden, um virtuelle Gast-Netzwerkschnittstellen (VIFs) 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-Verkehr sieht, indem Sie es an VLAN 0 anhängen.
Verfahren zum Erstellen von VLANs für XenServer-Hosts, entweder eigenständig oder als Teil eines Ressourcenpools, finden Sie unter VLANs erstellen.
Wenn der Gast die VLAN-Tagging- und Untagging-Funktionen ausführen soll, muss der Gast die VLANs kennen. Wenn Sie das Netzwerk für Ihre VMs konfigurieren, konfigurieren Sie 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 Managementschnittstellen
Die Managementschnittstelle kann auf einem VLAN über einen als Trunk-Port oder Zugriffsmodus-Port konfigurierten Switch-Port konfiguriert werden. Verwenden Sie XenCenter oder die xe CLI, um ein VLAN einzurichten und es zur Managementschnittstelle zu machen. Weitere Informationen finden Sie unter Managementschnittstelle.
Verwenden von VLANs mit dedizierten Speicher-NICs
Dedizierte Speicher-NICs können so konfiguriert werden, dass sie native VLAN- oder Zugriffsmodus-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, wodurch eine Host-NIC für eine Verwaltungsschnittstelle (im nativen VLAN) und für die Verbindung 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 dem 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.
Anforderungen für die Verwendung von Jumbo-Frames
Beachten Sie bei der Verwendung von Jumbo-Frames Folgendes:
-
Jumbo-Frames werden auf Poolebene konfiguriert
-
Jedes Gerät im Subnetz muss für die Verwendung von Jumbo-Frames konfiguriert sein
Um Jumbo-Frames zu verwenden, stellen Sie die maximale Übertragungseinheit (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. Sie können entweder zwei, drei oder vier NICs bündeln.
Alle Bonding-Modi unterstützen Failover. Allerdings erlauben nicht alle Modi, dass alle Links für alle Verkehrstypen aktiv sind. XenServer unterstützt das Bündeln der folgenden NIC-Typen:
-
NICs (Nicht-Management). Sie können NICs bündeln, die XenServer ausschließlich für VM-Datenverkehr verwendet. Das Bündeln dieser NICs bietet nicht nur Ausfallsicherheit, sondern gleicht auch den Datenverkehr 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-Datenverkehr bietet. Obwohl die Konfiguration einer LACP-Link-Aggregation ein Lastenausgleich für den Management-Datenverkehr 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 (z. B. für Speicher) konfiguriert haben. Für die meisten iSCSI-Software-Initiator-Speicher empfehlen wir jedoch die Konfiguration von Multipathing anstelle von NIC-Bonding, wie in der Dokumentation zum Entwerfen von XenServer-Netzwerkkonfigurationen beschrieben.
In diesem Abschnitt wird der Begriff IP-basierter Speicherdatenverkehr verwendet, um iSCSI- und NFS-Datenverkehr zusammenfassend zu beschreiben.
Sie können eine Bond erstellen, wenn ein VIF bereits eine der Schnittstellen verwendet, die gebündelt werden sollen: Der VM-Datenverkehr wird automatisch zur neuen gebündelten Schnittstelle migriert.
In XenServer stellt ein zusätzliches PIF eine NIC-Bond dar. XenServer NIC-Bonds umfassen die zugrunde liegenden physischen Geräte (PIFs) vollständig.
Hinweise:
- Das Erstellen einer Bond, die nur eine NIC enthält, wird nicht unterstützt.
- Die gebündelten NICs können unterschiedliche Modelle voneinander sein.
Best Practices
Beachten Sie die folgenden Best Practices beim Einrichten Ihrer NIC-Bonds:
- Verbinden Sie die Links der Bond 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, wenn möglich, in Ihrem Rechenzentrum auf verschiedenen Phasen der Stromversorgung oder sogar auf Versorgungen, die von verschiedenen Versorgungsunternehmen bereitgestellt werden.
- Erwägen Sie den Einsatz von unterbrechungsfreien Stromversorgungen (USV), um sicherzustellen, dass die Netzwerk-Switches und Hosts im Falle eines Stromausfalls weiterhin funktionieren oder einen geordneten Shutdown durchführen 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:
-
Verwaltungs- und Speichernetzwerke.
-
Wenn Sie eine Verwaltungsschnittstelle 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-Datenverkehr verwendet werden, z. B. zur Verbindung mit gemeinsam genutztem Netzwerkspeicher oder XenCenter zur 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 Verwaltungsschnittstelle oder eine sekundäre Schnittstelle erstellt haben), wird diese IP-Adresse automatisch dem gesamten Bündel zugewiesen.
-
Wenn Sie eine Verwaltungsschnittstelle 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-Verwaltungsschnittstelle und eine sekundäre Schnittstelle bündeln, wird das Verwaltungs-VLAN auf dieser gebündelten NIC erstellt.
-
-
VM-Netzwerke. Wenn gebündelte NICs für den VM-Datenverkehr 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 VIFs zugeordnet.
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-Datenverkehr 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:
Die Bündelung wird mit einer Up Delay von 31.000 ms und einer Down Delay von 200 ms eingerichtet. Die scheinbar lange Up Delay ist beabsichtigt, da einige Switches Zeit benötigen, um den Port zu aktivieren. Ohne eine Verzögerung kann die Bündelung, wenn eine Verbindung nach einem Ausfall wiederhergestellt wird, den Datenverkehr auf diese umverteilen, bevor der Switch bereit ist, Datenverkehr weiterzuleiten. Um beide Verbindungen zu einem anderen Switch zu verschieben, verschieben Sie zuerst eine und 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 Delay 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 wie im folgenden Beispiel gezeigt verwenden:
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 erscheinen in der XenCenter-Ansicht Benachrichtigungen > Ereignisse. Für Benutzer, die XenCenter nicht verwenden, erscheinen Ereignisprotokolle auch in /var/log/xensource.log auf jedem Host.
Active-Active-Bonding
Active-Active ist eine Aktiv/Aktiv-Konfiguration für den Gast-Datenverkehr: Beide NICs können VM-Datenverkehr gleichzeitig routen. Wenn Bonds für den Management-Datenverkehr verwendet werden, kann nur eine NIC im Bond Datenverkehr routen: Die andere NIC bleibt ungenutzt und bietet Failover-Unterstützung. Der Active-Active-Modus ist der Standard-Bonding-Modus.
Sie können entweder zwei, drei oder vier NICs im Active-Active-Modus bündeln. Im Active-Active-Modus ist das Bündeln von drei oder vier NICs jedoch nur für VM-Datenverkehr vorteilhaft, wie in der folgenden Abbildung gezeigt.
![ Diese Abbildung zeigt, wie das Bündeln von vier NICs nur dem Gast-Datenverkehr zugutekommen kann. Im oberen Bild eines Management-Netzwerks ist NIC 2 aktiv, aber NICs 1, 3 und 4 sind passiv. Für den VM-Datenverkehr sind alle vier NICs im Bond aktiv. Dies setzt jedoch mindestens vier VMs voraus. Für den Speicher-Datenverkehr ist nur NIC 11 aktiv. ]](/de-de/xenserver/9/media/bond-types-differences.png)
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. Insbesondere:
-
VM-Datenverkehr. Vorausgesetzt, Sie aktivieren das Bonding auf NICs, 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.
-
Management- oder Speicher-Datenverkehr. 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 Management-Schnittstelle oder einer sekundären Schnittstelle in einem gebündelten Netzwerk bietet Ausfallsicherheit.
-
Gemischter Datenverkehr. Wenn die gebündelte NIC eine Mischung aus IP-basiertem Speicher-Datenverkehr 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 des Datenverkehrs
XenServer gleicht den Datenverkehr zwischen den NICs mithilfe der Quell-MAC-Adresse des Pakets aus. Da für den Management-Datenverkehr nur eine Quell-MAC-Adresse vorhanden ist, kann der Active-Active-Modus nur eine NIC verwenden, und der Datenverkehr wird nicht ausgeglichen. Die Lastverteilung des Datenverkehrs basiert auf zwei Faktoren:
-
Die virtuelle Maschine und ihr zugehöriges VIF, die den Datenverkehr senden oder empfangen.
-
Die Datenmenge (in Kilobyte), die gesendet wird.
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 des VIFs wird übertragen. Die Last eines VIFs wird niemals auf zwei NICs aufgeteilt.
Obwohl Active-Active-NIC-Bonding einen Lastausgleich für den Datenverkehr von mehreren VMs bereitstellen kann, kann es einer einzelnen VM nicht den Durchsatz von zwei NICs bieten. Jedes gegebene VIF verwendet zu einem bestimmten Zeitpunkt nur eine der Verbindungen in einem Bond. Da XenServer den Datenverkehr regelmäßig neu ausgleicht, werden VIFs keiner bestimmten NIC im Bond dauerhaft zugewiesen.
Der Active-Active-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 Active-Active-Datenverkehr kann der gesamte Datenverkehr einer VM nur über eine NIC gesendet werden.
Hinweis:
Active-Active-Bonding erfordert keine Switch-Unterstützung für EtherChannel oder 802.3ad (LACP).
Active-Passive-Bonding
Ein Active-Passive-Bond leitet den Datenverkehr nur über eine der NICs. Verliert die aktive NIC die Netzwerkverbindung, wird der Datenverkehr auf die andere NIC im Bond umgeleitet (Failover). Der Datenverkehr wird über die aktive NIC geleitet und wechselt zur passiven NIC, wenn die aktive NIC ausfällt.
Active-Passive-Bonding kann zwei, drei oder vier NICs miteinander verbinden. Unabhängig vom Datenverkehrstyp ist jedoch beim Bündeln von NICs im Active-Passive-Modus nur eine Verbindung aktiv, und es gibt keinen Lastausgleich zwischen den Verbindungen.
Die folgende Abbildung zeigt zwei gebündelte NICs, die im Active-Passive-Modus konfiguriert sind.
Diese Abbildung zeigt zwei NICs, die im Active-Passive-Modus gebündelt sind. NIC 1 ist aktiv. Der Bond enthält eine NIC für Failover, die mit einem zweiten Switch verbunden ist. Diese NIC wird nur verwendet, wenn NIC 1 ausfällt. ](/de-de/xenserver/9/media/bond-types-active-passive.png)
Der Active-Active-Modus ist die Standard-Bonding-Konfiguration in XenServer. Wenn Sie Bonds über die CLI konfigurieren, müssen Sie einen Parameter für den Active-Passive-Modus angeben. Andernfalls wird ein Active-Active-Bond erstellt. Sie müssen den Active-Passive-Modus nicht konfigurieren, nur weil ein Netzwerk Management- oder Speicherdatenverkehr ü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 die Aktiv-Passiv-Bonding-Konfiguration die Einrichtung von zwei Switches für Redundanz, erfordert jedoch 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 neue Bonds 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. Ihre Switches müssen den IEEE 802.3ad-Standard unterstützen, um LACP-Bonding verwenden zu können.
Ein Vergleich von Active-Active SLB-Bonding und LACP-Bonding:
Active-Active SLB-Bonding
Vorteile:
- Kann mit jedem Switch auf der Hardware-Kompatibilitätsliste 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 des Datenverkehrs 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 switchseitige Konfiguration.
- 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 der Quell- und Zieladressen.
Dieser Hashing-Typ ist der standardmäßige 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 ermöglicht dem Gast die Nutzung des aggregierten Durchsatzes. Dieser Hashing-Typ erlaubt 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 der 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 so konfiguriert ist, dass sie ein Bond aus drei NICs verwendet.

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. 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.

Switch-Konfiguration
Je nach Ihren Redundanzanforderungen können Sie die NICs im Bond entweder an denselben 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 einen der Links 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) zu einem zweiten Switch herstellen 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 mit mehreren Switches verbinden 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-Management-Software miteinander verbinden, damit die Switches gemäß den Richtlinien des Switch-Herstellers als eine einzige logische Switching-Einheit funktionieren. 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 Active-Active-Bonds haben, kann die Verwendung von gestapelten Switches erforderlich sein. Active-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 auf jedem Host 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 anfänglichen Host-Installation 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 über mehrere NICs verfügt, hängt die nach der Installation vorhandene Konfiguration davon ab, welche NIC während der Installation für Verwaltungsoperationen ausgewählt wird:
-
PIFs werden für jede NIC im Host erstellt
-
Die PIF der NIC, die als Verwaltungsschnittstelle ausgewählt wurde, wird mit den während der Installation angegebenen IP-Adressierungsoptionen konfiguriert.
-
Für jede PIF wird ein Netzwerk erstellt (“Netzwerk 0”, “Netzwerk 1” usw.).
-
Jedes Netzwerk ist mit einer PIF verbunden.
-
Die IP-Adressierungsoptionen bleiben für alle PIFs unkonfiguriert, außer für die PIF, die als Verwaltungsschnittstelle verwendet wird.
Wenn ein Host eine einzelne NIC hat, ist nach der Installation die folgende Konfiguration vorhanden:
-
Eine einzelne PIF wird entsprechend der einzelnen NIC des Hosts erstellt.
-
Die PIF wird mit den während der Installation angegebenen IP-Adressierungsoptionen konfiguriert, um die Verwaltung des Hosts zu ermöglichen.
-
Die PIF ist für die Verwendung in Host-Verwaltungsvorgängen festgelegt.
-
Ein einzelnes Netzwerk, Netzwerk 0, wird erstellt.
-
Netzwerk 0 ist mit der PIF verbunden, um externe Konnektivität zu VMs zu ermöglichen.
Wenn eine Installation von XenServer auf einem getaggten VLAN-Netzwerk durchgeführt wird, ist nach der Installation die folgende Konfiguration vorhanden:
-
PIFs werden für jede NIC im Host erstellt.
-
Die PIF für das getaggte VLAN auf der NIC, die als Verwaltungsschnittstelle ausgewählt wurde, 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 der ersten Netzwerkschnittstelle auf VLAN<TAG> verbunden ist).
-
Jedes Netzwerk ist mit einer PIF verbunden. Die VLAN-PIF ist für die Verwendung in Host-Verwaltungsvorgängen festgelegt.
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 VMs, die auf dem Host erstellt wurden.
Das für Verwaltungsvorgänge verwendete PIF ist das einzige PIF, das 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 Zuweisung einer NIC für den Speicherverkehr erforderlichen Schritte werden in den folgenden Abschnitten behandelt.
Ändern der Netzwerkkonfiguration
Sie können Ihre Netzwerkkonfiguration ändern, indem Sie das Netzwerkobjekt modifizieren. Dazu führen Sie einen Befehl aus, der entweder das Netzwerkobjekt oder das VIF betrifft.
Modifizieren des Netzwerkobjekts
Sie können Aspekte eines Netzwerks ändern, wie z. B. die Frame-Größe (MTU), die Namensbezeichnung (name-label), die Namensbeschreibung (name-description), den Zweck (purpose) 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 Vereinfachen der VIF-Sperrmoduskonfiguration in der Cloud. -
name-label -
name-description -
MTU -
purpose. Siehe Hinzufügen eines Zwecks zu einem Netzwerk. -
other-config
Wenn kein Wert für einen Parameter 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 des Up-Delays für Bonds
Bonding ist standardmäßig mit einem Up-Delay von 31.000 ms eingerichtet, um zu verhindern, dass der Datenverkehr nach einem Ausfall auf eine NIC neu verteilt wird. Obwohl es scheinbar lang ist, ist das Up-Delay 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 das Up-Delay für Bonds mithilfe des folgenden Verfahrens ändern.
Legen Sie das Up-Delay 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-->