Verwalten Sie Ihre Pools

Dieser Artikel beschreibt einige der Aktionen, die Sie zur Verwaltung Ihres Pools durchführen können.

Informationen zur Verwaltung einzelner Hosts finden Sie unter Ihre Hosts verwalten.

Einen Ressourcenpool erstellen

Ressourcenpools können mit XenCenter® oder der CLI erstellt werden. Wenn ein neuer Host einem Ressourcenpool beitritt, synchronisiert der beitretende Host seine lokale Datenbank mit der poolweiten Datenbank und übernimmt einige Einstellungen aus dem Pool:

• Die Konfiguration von VM, lokalem und Remote-Speicher wird der poolweiten Datenbank hinzugefügt. Diese Konfiguration wird auf den beitretenden Host im Pool angewendet, es sei denn, Sie geben die Ressourcen explizit frei, nachdem der Host dem Pool beigetreten ist.

• Der beitretende Host übernimmt vorhandene freigegebene Speicher-Repositories im Pool. Es werden entsprechende PBD-Einträge erstellt, damit der neue Host automatisch auf vorhandenen freigegebenen Speicher zugreifen kann.

• Netzwerkinformationen werden teilweise an den beitretenden Host vererbt: Die strukturellen Details von NICs, VLANs und gebündelten Schnittstellen werden alle übernommen, aber Richtlinieninformationen nicht. Diese Richtlinieninformationen, die neu konfiguriert werden müssen, umfassen:

  • Die IP-Adressen der Management-NICs, die aus der ursprünglichen Konfiguration beibehalten werden.

  • Der Speicherort der Verwaltungsschnittstelle, der derselbe bleibt wie in der ursprünglichen Konfiguration. Wenn beispielsweise die anderen Pool-Hosts Verwaltungsschnittstellen auf einer gebündelten Schnittstelle haben, muss der beitretende Host nach dem Beitritt auf die Bindung migriert werden.

  • Dedizierte Speicher-NICs, die dem beitretenden Host von XenCenter oder der CLI neu zugewiesen und die PBDs neu verbunden werden müssen, um den Datenverkehr entsprechend zu leiten. Dies liegt daran, dass IP-Adressen nicht als Teil des Pool-Beitrittsvorgangs zugewiesen werden und die Speicher-NIC nur funktioniert, wenn dies korrekt konfiguriert ist. Weitere Informationen zum Dedizieren einer Speicher-NIC über die CLI finden Sie unter Netzwerk verwalten.

  • Konfigurieren Sie die Verwaltungsschnittstelle neu und verschieben Sie sie auf eine physische NIC, bevor Sie den Host zum Pool hinzufügen. Nachdem der Host dem Pool beigetreten ist, können Sie die Verwaltungsschnittstelle erneut konfigurieren.

Bevor Sie einen Ressourcenpool erstellen, überprüfen Sie die Anforderungen für den Pool und den beitretenden Host. Weitere Informationen finden Sie unter Ressourcenpools.

Einen Host mithilfe der xe CLI zu einem Pool hinzufügen

1. Aktualisieren Sie Ihren Pool und den beitretenden Host auf dasselbe Niveau, bevor Sie den Beitritt versuchen. Sie können dies auf eine der folgenden Arten tun:

   • Aktualisieren Sie den beitretenden Host auf dasselbe Niveau wie den Pool:

     • (Empfohlen) Durch Synchronisierung des beitretenden Hosts mit dem Pool und Aktualisierung anhand von Update-Dateien, die auf dem Pool-Koordinator gespeichert sind. Weitere Informationen finden Sie unter Auf Pool-Ebene aktualisieren.
     • Durch Herunterladen eines Update-Bundles, das der Pool-Ebene entspricht, und dessen Verwendung zur Aktualisierung des beitretenden Hosts.

   • Aktualisieren Sie sowohl den Pool als auch den beitretenden Host auf die neueste Version:

     • Durch Synchronisierung von Host und Pool mit demselben Update-Kanal und Anwenden der neuesten Updates.
     • Durch Verwendung des Offline-Update-Mechanismus, um die neueste Version der Updates auf Host und Pool anzuwenden.

   Weitere Informationen zu diesen Update-Methoden finden Sie unter Updates mit XenCenter anwenden oder Updates mit der xe CLI anwenden.

2. Öffnen Sie eine Konsole auf dem XenServer®-Host, den Sie einem Pool hinzufügen möchten.

3. Fügen Sie den XenServer-Host dem Pool hinzu, indem Sie den Befehl eingeben:

   xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>
   <!--NeedCopy-->
   

   Der master-address muss auf den vollqualifizierten Domänennamen des Pool-Koordinators eingestellt sein. Der password muss das Administratorpasswort sein, das bei der Installation des Pool-Koordinators festgelegt wurde.

Hinweis:

Wenn Sie einen Host einem Pool hinzufügen, wird das Administratorpasswort für den beitretenden Host automatisch an das Administratorpasswort des Pool-Koordinators angepasst.

XenServer-Hosts gehören standardmäßig zu einem unbenannten Pool. Um Ihren ersten Ressourcenpool zu erstellen, benennen Sie den vorhandenen namenlosen Pool um. Verwenden Sie die Tab-Vervollständigung, um den pool_uuid zu finden:

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Heterogene Ressourcenpools erstellen

XenServer vereinfacht die Erweiterung von Bereitstellungen im Laufe der Zeit, indem es ermöglicht, unterschiedliche Host-Hardware zu einem Ressourcenpool zusammenzufassen, der als heterogener Ressourcenpool bezeichnet wird. Heterogene Ressourcenpools werden durch Technologien in Intel (FlexMigration) und AMD (Extended Migration) CPUs ermöglicht, die CPU-“Maskierung” oder “Nivellierung” bieten. Die CPU-Maskierungs- und Nivellierungsfunktionen ermöglichen es, eine CPU so zu konfigurieren, dass sie scheinbar eine andere Marke, ein anderes Modell oder eine andere Funktionalität bietet, als sie tatsächlich besitzt. Diese Funktion ermöglicht es Ihnen, Pools von Hosts mit unterschiedlichen CPUs zu erstellen und dennoch die Live-Migration sicher zu unterstützen.

Hinweis:

Die CPUs von XenServer-Hosts, die heterogenen Pools beitreten, müssen vom selben Hersteller (d. h. AMD, Intel) sein wie die CPUs der bereits im Pool befindlichen Hosts. Die Hosts müssen jedoch nicht vom gleichen Typ auf der Ebene der Familien-, Modell- oder Stepping-Nummern sein.

XenServer vereinfacht die Unterstützung heterogener Pools. Hosts können jetzt zu bestehenden Ressourcenpools hinzugefügt werden, unabhängig vom zugrunde liegenden CPU-Typ (solange die CPU vom selben Hersteller stammt). Der Funktionsumfang des Pools wird jedes Mal dynamisch berechnet, wenn:

• Ein neuer Host dem Pool beitritt

• Ein Poolmitglied den Pool verlässt

• Ein Poolmitglied nach einem Neustart wieder verbunden wird

Jede Änderung des Funktionsumfangs des Pools hat keine Auswirkungen auf VMs, die derzeit im Pool ausgeführt werden. Eine laufende VM verwendet weiterhin den Funktionsumfang, der beim Start angewendet wurde. Dieser Funktionsumfang ist beim Booten festgelegt und bleibt über Migrations-, Anhalte- und Wiederaufnahmevorgänge hinweg bestehen. Wenn das Pool-Level sinkt, wenn ein weniger leistungsfähiger Host dem Pool beitritt, kann eine laufende VM auf jeden Host im Pool migriert werden, außer auf den neu hinzugefügten Host. Wenn Sie eine VM innerhalb oder zwischen Pools auf einen anderen Host verschieben oder migrieren, vergleicht XenServer den Funktionsumfang der VM mit dem Funktionsumfang des Zielhosts. Wenn die Funktionsumfänge als kompatibel befunden werden, darf die VM migriert werden. Dies ermöglicht der VM, sich frei innerhalb und zwischen Pools zu bewegen, unabhängig von den CPU-Funktionen, die die VM verwendet. Wenn Sie Workload Balancing verwenden, um einen optimalen Zielhost für die Migration Ihrer VM auszuwählen, wird ein Host mit einem inkompatiblen Funktionsumfang nicht als Zielhost empfohlen.

Freigegebenen Speicher hinzufügen

Dieser Abschnitt zeigt ein Beispiel, wie freigegebener Speicher (dargestellt als Speicher-Repository) auf einem vorhandenen NFS-Server erstellt werden kann. Eine vollständige Liste der unterstützten freigegebenen Speichertypen finden Sie unter Speicher.

So fügen Sie einem Ressourcenpool NFS-Freigabespeicher über die CLI hinzu

1. Öffnen Sie eine Konsole auf einem beliebigen XenServer-Host im Pool.

2. Erstellen Sie das Speicher-Repository auf server:/path, indem Sie den folgenden Befehl ausführen:

   xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
       device-config:server=server \
       device-config:serverpath=path
   <!--NeedCopy-->
   

   device-config:server ist der Hostname des NFS-Servers und device-config:serverpath ist der Pfad auf dem NFS-Server. Da shared auf „true“ gesetzt ist, wird der freigegebene Speicher automatisch mit jedem XenServer-Host im Pool verbunden. Alle XenServer-Hosts, die später beitreten, werden ebenfalls mit dem Speicher verbunden. Die Universally Unique Identifier (UUID) des Speicher-Repositorys wird auf dem Bildschirm angezeigt.

3. Ermitteln Sie die UUID des Pools, indem Sie den folgenden Befehl ausführen:

   xe pool-list
   <!--NeedCopy-->
   

4. Legen Sie den freigegebenen Speicher mit dem folgenden Befehl als Pool-weiten Standard fest:

   xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
   <!--NeedCopy-->
   

   Da der gemeinsame Speicher als Pool-weiter Standard festgelegt wurde, werden alle zukünftigen VMs standardmäßig mit ihren Festplatten auf dem gemeinsamen Speicher erstellt. Informationen zum Erstellen anderer Arten von gemeinsamem Speicher finden Sie unter SR erstellen.

XenServer-Hosts aus einem Ressourcenpool entfernen

Hinweis:

Bevor Sie einen XenServer-Host aus einem Pool entfernen, stellen Sie sicher, dass Sie alle auf diesem Host ausgeführten VMs herunterfahren. Andernfalls wird möglicherweise eine Warnung angezeigt, dass der Host nicht entfernt werden kann.

Wenn Sie einen Host aus einem Pool entfernen (auswerfen), wird die Maschine neu gestartet, neu initialisiert und in einem Zustand belassen, der einer Neuinstallation ähnelt. Werfen Sie keine XenServer-Hosts aus einem Pool aus, wenn sich wichtige Daten auf den lokalen Festplatten befinden.

So entfernen Sie einen Host aus einem Ressourcenpool mithilfe der CLI

1. Öffnen Sie eine Konsole auf einem beliebigen Host im Pool.

2. Suchen Sie die UUID des Hosts, indem Sie den folgenden Befehl ausführen:

   xe host-list
   <!--NeedCopy-->
   

3. Werfen Sie den erforderlichen Host aus dem Pool aus:

   xe pool-eject host-uuid=host_uuid
   <!--NeedCopy-->
   

   Der XenServer-Host wird ausgeworfen und befindet sich in einem frisch installierten Zustand.

   Warnung:

   Werfen Sie einen Host nicht aus einem Ressourcenpool aus, wenn er wichtige Daten auf seinen lokalen Festplatten enthält. Alle Daten werden gelöscht, wenn ein Host aus dem Pool ausgeworfen wird. Wenn Sie diese Daten erhalten möchten, kopieren Sie die VM mit XenCenter oder dem xe vm-copy CLI-Befehl auf den gemeinsamen Speicher im Pool.

Wenn XenServer-Hosts, die lokal gespeicherte VMs enthalten, aus einem Pool ausgeworfen werden, sind die VMs in der Pooldatenbank vorhanden. Die lokal gespeicherten VMs sind auch für die anderen XenServer-Hosts sichtbar. Die VMs starten erst, wenn die ihnen zugeordneten virtuellen Festplatten so geändert wurden, dass sie auf den von anderen XenServer-Hosts im Pool gesehenen gemeinsamen Speicher zeigen, oder entfernt wurden. Daher empfehlen wir, dass Sie beim Beitritt zu einem Pool jeglichen lokalen Speicher auf gemeinsamen Speicher verschieben. Das Verschieben auf gemeinsamen Speicher ermöglicht es, einzelne XenServer-Hosts auszuwerfen (oder physisch ausfallen zu lassen), ohne Daten zu verlieren.

Hinweis:

Wenn ein Host aus einem Pool entfernt wird, dessen Verwaltungsschnittstelle sich in einem getaggten VLAN-Netzwerk befindet, wird die Maschine neu gestartet und ihre Verwaltungsschnittstelle ist im selben Netzwerk verfügbar.

Pool-Geheimnis rotieren

Das Pool-Geheimnis ist ein gemeinsames Geheimnis der Hosts in einem Pool, das es dem Host ermöglicht, seine Mitgliedschaft in einem Pool nachzuweisen.

Da Benutzer mit der Rolle „Pool-Administrator“ dieses Geheimnis entdecken können, ist es eine gute Praxis, das Pool-Geheimnis zu rotieren, wenn einer dieser Benutzer Ihr Unternehmen verlässt oder seine Rolle als Pool-Administrator verliert.

Sie können das Pool-Geheimnis mit XenCenter oder der xe-CLI rotieren.

XenCenter

Um das Pool-Geheimnis für einen Pool mit XenCenter zu rotieren, führen Sie die folgenden Schritte aus:

1. Wählen Sie im Bereich Ressourcen den Pool oder einen beliebigen Host im Pool aus.
2. Wählen Sie im Menü Pool die Option Pool-Geheimnis rotieren.

Wenn Sie das Pool-Geheimnis rotieren, werden Sie auch aufgefordert, das Root-Passwort zu ändern. Wenn Sie das Pool-Geheimnis rotiert haben, weil Sie der Meinung sind, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Passwort des Pool-Koordinators ändern. Weitere Informationen finden Sie unter Passwort ändern.

xe-CLI

Um das Pool-Geheimnis mit der xe-CLI zu rotieren, führen Sie den folgenden Befehl auf einem Host im Pool aus:

xe pool-secret-rotate
<!--NeedCopy-->

Wenn Sie das Pool-Geheimnis rotiert haben, weil Sie der Meinung sind, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Passwort ändern. Weitere Informationen finden Sie unter Passwort ändern.

SSH-Zugriff konfigurieren

Der SSH-Zugriff auf Ihren XenServer-Pool ist standardmäßig aktiviert. Wenn Sie den SSH-Zugriff auf Ihren XenServer-Pool deaktivieren möchten, führen Sie den folgenden Befehl aus:

xe pool-disable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->

Dieser Befehl deaktiviert SSH. Der Pool lehnt neue SSH-Verbindungen ab, aber trennen keine bestehenden Sitzungen.

Um den SSH-Zugriff auf Ihren XenServer-Pool zu aktivieren, führen Sie den folgenden Befehl aus:

xe pool-enable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->

So legen Sie das temporäre SSH-Aktivierungs-Timeout (Sekunden) des aktuellen Pools fest:

xe pool-param-set uuid=<pool-uuid> ssh-enabled-timeout=<seconds>
<!--NeedCopy-->

Der Timeout-Parameter bestimmt die Dauer des SSH-Dienstes. Wenn er auf 0 gesetzt ist, bleibt SSH unbegrenzt aktiv. Wenn er auf eine positive Ganzzahl (Sekunden) gesetzt ist, wird SSH nach dem angegebenen Zeitraum automatisch deaktiviert. Konfigurationsänderungen wirken sich sofort auf nachfolgende aktive SSH-Sitzungen aus und werden jedes Mal wirksam, wenn der Benutzer SSH aktiviert.

Hinweis:

Der Maximalwert, den Sie für ssh-enabled-timeout festlegen können, beträgt 172800 Sekunden (was ungefähr 2 Tagen entspricht).

So legen Sie das Leerlauf-Timeout (Sekunden) der SSH-Konsole des aktuellen Pools fest

xe pool-param-set uuid=<pool-uuid> console-idle-timeout=<seconds>
<!--NeedCopy-->

Konfigurieren Sie das Leerlauf-Sitzungs-Timeout für VNC- und SSH-Konsolenverbindungen mit einem nicht-negativen Ganzzahlwert in Sekunden, wobei 0 das Timeout deaktiviert (Sitzungen laufen nie ab) und positive Werte (z. B. 3600) Leerlauf-Sitzungen nach der angegebenen Dauer automatisch beenden, wobei die Einstellungen nach der Konfiguration auf neu erstellte Konsolensitzungen angewendet werden.

So legen Sie den SSH-Auto-Modus des aktuellen Pools fest

xe poolparam-set uuid=<pool-uuid>  ssh-auto-mode=true
<!--NeedCopy-->

Konfigurieren Sie die automatische SSH-Verwaltung basierend auf dem Integritätsstatus des XAPI-Dienstes. Wenn der Auto-Modus aktiviert ist, folgt die SSH-Aktivierung dem XAPI-Status: SSH ist deaktiviert, wenn XAPI fehlerfrei ist, und aktiviert, wenn XAPI fehlerhaft ist.

Auto-Modus aktiviert + ssh_enabled_timeout = 0: Manuelle SSH-Aktivierung über pool.enable_ssh deaktiviert den Auto-Modus dauerhaft.

Auto-Modus aktiviert + ssh_enabled_timeout > 0: Manuelle SSH-Aktivierung deaktiviert den Auto-Modus vorübergehend; der Auto-Modus wird auf die ursprüngliche Einstellung zurückgesetzt, wenn das Timeout abläuft. (Wenn ein Systemneustart während eines aktiven SSH-Timeout-Zeitraums auftritt, geht die ursprüngliche Auto-Modus-Einstellung verloren und wird beim Timeout/der Wiederherstellung auf aktiviert zurückgesetzt.)

Für den Wert des Pool-Parameters in einem dieser Befehle können Sie einen Pool-Selektor verwenden. Weitere Informationen finden Sie unter Pool-Befehle.

Sie können den SSH-Zugriff für alle Pools in einem XenServer-Pool gleichzeitig verwalten. Weitere Informationen finden Sie unter SSH-Zugriff für einen Pool deaktivieren.

Verhalten beim Beitreten / Entfernen von Pools

• Beitreten – Wenn ein Server einem Pool beitritt, werden die SSH-Einstellungen (SSH-Aktivierungs-Timeout, Leerlauf-Konsolen-Timeout, Auto-Modus) übernommen.

• Auswerfen – Wenn ein Server aus einem Pool ausgeworfen wird, werden die Standardeinstellungen wiederhergestellt.

  • XenServer 8.4: SSH aktiviert, Auto-Modus aus

Definition der neuen SSH-Verwaltungssteuerung

Legen Sie die neue XAPI-API pool.set_ssh_auto_mode auf Poolebene fest, um SSH zu konfigurieren.

set_ssh_auto_mode: Konfigurieren Sie, um den SSH-Auto-Modus zu aktivieren oder zu deaktivieren. Wenn der Auto-Modus aktiviert ist, hängt der SSH-Status vom XAPI-Status ab: SSH ist deaktiviert, wenn XAPI fehlerfrei ist, und SSH ist aktiviert, wenn XAPI fehlerhaft ist.

Wenn ein Benutzer den Auto-Modus auf „aktiviert“ setzt und der aktuelle ssh_enabled_timeout 0 ist, wird durch die Aktivierung von SSH mit pool.enable_ssh der Auto-Modus dauerhaft deaktiviert.

Wenn ein Benutzer den Auto-Modus mit pool.set_auto_mode als aktiviert oder deaktiviert festlegt, wird dies als „ursprüngliche Auto-Modus-Einstellung“ bezeichnet. Wenn der aktuelle ssh_enabled_timeout auf eine positive Zahl (z. B. 1800 Sekunden) eingestellt ist, wird durch die Aktivierung von SSH mit pool.enable_ssh der Auto-Modus vorübergehend deaktiviert. Wenn die Zeitüberschreitung abläuft, wird SSH automatisch deaktiviert und der Auto-Modus auf seine ursprüngliche Einstellung zurückgesetzt.

Wenn ein Benutzer ssh_enabled_timeout auf eine positive Zahl (z. B. 3600 Sekunden) setzt und den Host neu startet (oder XAPI neu startet), bevor die Zeitüberschreitung abläuft, wird SSH nach Ablauf der Zeitüberschreitung automatisch deaktiviert und der Auto-Modus auf „true“ zurückgesetzt, da der Neustart die ursprüngliche Auto-Modus-Einstellung verloren hat.

Wenn Sie ssh_enabled_timeout auf eine positive Zahl (z. B. 180 Sekunden) konfigurieren und XAPI anschließend ausfällt, bleibt SSH aktiviert, bis XAPI neu startet, falls XAPI nach Ablauf der Zeitüberschreitung in einem fehlerhaften Zustand verbleibt. Nach dem Neustart von XAPI wird SSH automatisch deaktiviert und der Auto-Modus auf „true“ zurückgesetzt, da der Systemneustart zum Verlust der ursprünglichen Auto-Modus-Einstellung führt.

This command disables SSH. The hosts refuse new SSH connections, but do not disconnect any existing sessions.

To enable SSH access to all hosts in your pool, run the following command:

xe pool-enable-ssh ```

Both of these commands attempt to make a change on all hosts in the pool. If the command fails on one or more of the hosts in your pool, the command continues to run for all other hosts in the pool. The command returns a list of any hosts where the command fails.

You can manage the SSH access for an individual host. For more information, see Disable SSH access for a host.–>

IGMP-Snooping in Ihrem XenServer-Pool aktivieren

XenServer sendet Multicast-Datenverkehr an alle Gast-VMs, was zu einer unnötigen Last auf Host-Geräten führt, da diese Pakete verarbeiten müssen, die sie nicht angefordert haben. Die Aktivierung von IGMP-Snooping verhindert, dass Hosts in einem lokalen Netzwerk Datenverkehr für eine Multicast-Gruppe empfangen, der sie nicht explizit beigetreten sind, und verbessert die Leistung von Multicast. IGMP-Snooping ist besonders nützlich für bandbreitenintensive IP-Multicast-Anwendungen wie IPTV.

Hinweise:

• Wenn diese Funktion in einem Pool aktiviert wird, kann es auch erforderlich sein, IGMP-Querier auf einem der physischen Switches zu aktivieren. Andernfalls fällt Multicast im Subnetz auf Broadcast zurück und kann die XenServer-Leistung beeinträchtigen.

• Wenn diese Funktion in einem Pool mit IGMP v3 aktiviert wird, führt die VM-Migration oder das Failover der Netzwerkbindung zu einem Wechsel der IGMP-Version auf v2.

• Um diese Funktion mit einem GRE-Netzwerk zu aktivieren, müssen Benutzer einen IGMP-Querier im GRE-Netzwerk einrichten. Alternativ können Sie die IGMP-Abfragenachricht vom physischen Netzwerk in das GRE-Netzwerk weiterleiten. Andernfalls kann der Multicast-Datenverkehr im GRE-Netzwerk blockiert werden.

Sie können IGMP-Snooping in einem Pool mithilfe von XenCenter oder der xe CLI aktivieren.

XenCenter

1. Navigieren Sie zu Pooleigenschaften.
2. Wählen Sie Netzwerkoptionen. Hier können Sie IGMP-Snooping aktivieren oder deaktivieren.

xe CLI

1. Pool-UUID abrufen:

   xe pool-list

2. IGMP-Snooping für den Pool aktivieren/deaktivieren:

   xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]

Nach dem Aktivieren von IGMP-Snooping können Sie die IGMP-Snooping-Tabelle mithilfe der xe CLI anzeigen.

IGMP-Snooping-Tabelle anzeigen

Verwenden Sie den folgenden Befehl, um die IGMP-Snooping-Tabelle anzuzeigen:

ovs-appctl mdb/show [bridge name]

Hinweis:

Sie können den Bridge-Namen mit xe network-list abrufen. Diese Bridge-Namen können xenbr0, xenbr1, xenapi oder xapi0 sein.

Dies gibt eine Tabelle mit vier Spalten aus:

• port: Der Port des Switches (OVS).
• VLAN: Die VLAN-ID des Datenverkehrs.
• GROUP: Die Multicast-Gruppe, die der Port angefordert hat.
• Age: Das Alter dieses Eintrags in Sekunden.

Wenn die GROUP eine Multicast-Gruppenadresse ist, bedeutet dies, dass eine IGMP-Report-Nachricht am zugehörigen Switch-Port empfangen wird. Dies bedeutet, dass ein Empfänger (Mitglied) der Multicast-Gruppe an diesem Port lauscht.

Betrachten Sie das folgende Beispiel, das zwei Einträge enthält:

Der erste Eintrag zeigt, dass ein Empfänger auf Port 14 für die Multicast-Gruppe 227.0.0.1 lauscht. Der Open vSwitch leitet den für die Multicast-Gruppe 227.0.0.1 bestimmten Datenverkehr nur an die lauschenden Ports für diese Gruppe weiter (in diesem Beispiel Port 14), anstatt ihn an alle Ports zu senden. Der Eintrag, der Port 14 und Gruppe 227.0.0.1 verbindet, wurde vor 15 Sekunden erstellt. Standardmäßig beträgt das Timeout-Intervall 300 Sekunden. Das bedeutet, dass der Eintrag abläuft und aus der Tabelle entfernt wird, wenn der Switch nach dem Hinzufügen des Eintrags 300 Sekunden lang keine weiteren IGMP-Berichtsnachrichten auf Port 14 empfängt.

Im zweiten Eintrag ist die GRUPPE ein Querier, was bedeutet, dass IGMP-Abfragenachrichten auf dem zugehörigen Port empfangen wurden. Ein Querier sendet periodisch IGMP-Abfragenachrichten, die an alle Switch-Ports gesendet werden, um festzustellen, welche Netzwerkknoten auf einer Multicast-Gruppe lauschen. Beim Empfang einer IGMP-Abfragenachricht antwortet der Empfänger mit einer IGMP-Berichtsnachricht, wodurch der Multicast-Eintrag des Empfängers aktualisiert wird und ein Ablaufen verhindert wird.

Die Spalte VLAN gibt das VLAN an, in dem sich ein Empfänger/Querier befindet. ‘0’ bedeutet natives VLAN. Wenn Sie Multicast auf einem getaggten VLAN ausführen möchten, stellen Sie sicher, dass Einträge auf dem VLAN vorhanden sind.

Hinweis:

Für das VLAN-Szenario müssen Sie einen Querier-Eintrag mit einem VLAN-Spaltenwert haben, der der VLAN-ID des Netzwerks entspricht, andernfalls funktioniert Multicast im VLAN-Netzwerk nicht.

Migrationsstromkomprimierung in Ihrem XenServer-Pool aktivieren

Während der Live-Migration einer VM wird ihr Speicher als Datenstrom über das Netzwerk zwischen zwei Hosts übertragen. Die Funktion zur Migrationsstromkomprimierung komprimiert diesen Datenstrom und beschleunigt die Speicherübertragung in langsamen Netzwerken. Diese Funktion ist standardmäßig deaktiviert, kann aber über XenCenter oder die xe CLI geändert werden. Weitere Informationen finden Sie unter Pool-Eigenschaften – Erweitert und Pool-Parameter. Alternativ können Sie die Komprimierung bei der Migration einer VM über die Befehlszeile aktivieren. Weitere Informationen finden Sie im Befehl vm-migrate unter VM-Befehle.

Ressourcen-Pool-Daten exportieren

Die Option „Ressourcendaten exportieren“ ermöglicht es Ihnen, einen Ressourcendatenbericht für Ihren Pool zu erstellen und diesen Bericht in eine .xls- oder .csv-Datei zu exportieren. Dieser Bericht enthält detaillierte Informationen zu verschiedenen Ressourcen im Pool, wie Hosts, Netzwerke, Speicher, virtuelle Maschinen, VDIs und GPUs. Diese Funktion ermöglicht es Administratoren, Ressourcen basierend auf verschiedenen Arbeitslasten wie CPU, Speicher und Netzwerk zu verfolgen, zu planen und zuzuweisen.

Hinweis:

Der Export von Ressourcen-Pool-Daten ist für Kunden der XenServer Premium Edition verfügbar.

Die Liste der Ressourcen und verschiedene Arten von Ressourcendaten, die im Bericht enthalten sind:

Server:

• Name
• Pool-Koordinator
• UUID
• Adresse
• CPU-Auslastung
• Netzwerk (Durchschn./Max. KBs)
• Genutzter Speicher
• Speicher
• Betriebszeit
• Beschreibung

Netzwerke:

• Name
• Verbindungsstatus
• MAC
• MTU
• VLAN
• Typ
• Standort

VDI:

• Name
• Typ
• UUID
• Größe
• Speicher
• Beschreibung

Speicher:

• Name
• Typ
• UUID
• Größe
• Speicherort
• Beschreibung

VMs:

• Name
• Betriebszustand
• Läuft auf
• Adresse
• MAC
• NIC
• Betriebssystem
• Speicher
• Genutzter Speicher
• CPU-Auslastung
• UUID
• Betriebszeit
• Vorlage
• Beschreibung

GPU:

• Name
• Server
• PCI-Buspfad
• UUID
• Stromverbrauch
• Temperatur
• Belegter Speicher
• Computerauslastung

Hinweis:

Informationen zu GPUs sind nur verfügbar, wenn GPUs an Ihren XenServer-Host angeschlossen sind.

Ressourcendaten exportieren

1. Wählen Sie im XenCenter Navigationsbereich Infrastruktur und dann den Pool aus.

2. Wählen Sie das Menü Pool und dann Ressourcendaten exportieren.

3. Navigieren Sie zu einem Speicherort, an dem Sie den Bericht speichern möchten, und klicken Sie dann auf Speichern.