Hosts und Ressourcenpools

In diesem Abschnitt wird beschrieben, wie Ressourcenpools anhand einer Reihe von Beispielen mithilfe der xe-Befehlszeilenschnittstelle (CLI) erstellt werden können. Eine einfache NFS-basierte Konfiguration für gemeinsam genutzten Speicher wird vorgestellt, und es werden mehrere einfache Beispiele für die VM-Verwaltung erörtert. Es enthält auch Verfahren zum Umgang mit Ausfällen physischer Knoten.

Citrix Hypervisor-Server und Ressourcenpools — Überblick

Ein Ressourcenpool umfasst mehrere Citrix Hypervisor-Serverinstallationen, die an eine einzige verwaltete Entität gebunden sind, die virtuelle Maschinen hosten kann. In Kombination mit gemeinsam genutztem Speicher ermöglicht ein Ressourcenpool den Start von VMs auf jedem Citrix Hypervisor-Server mit ausreichend Arbeitsspeicher. Die VMs können dann dynamisch zwischen Citrix Hypervisor-Servern verschoben werden, während sie mit minimaler Ausfallzeit ausgeführt werden (Livemigration). Wenn ein einzelner Citrix Hypervisor-Server einen Hardwarefehler erleidet, kann der Administrator ausgefallene VMs auf einem anderen Citrix Hypervisor-Server im selben Ressourcenpool neu starten. Wenn Hochverfügbarkeit im Ressourcenpool aktiviert ist, wechseln VMs automatisch zu einem anderen Host, wenn ihr Host ausfällt. Pro Ressourcenpool werden bis zu 64 Hosts unterstützt, obwohl diese Einschränkung nicht durchgesetzt wird.

Ein Pool hat immer mindestens einen physischen Knoten, der als Masterbekannt ist. Nur der Masterknoten macht eine Verwaltungsschnittstelle verfügbar (verwendet von XenCenter und der Citrix Hypervisor Command Line Interface, bekannt als xe CLI). Der Master leitet Befehle nach Bedarf an einzelne Mitglieder weiter.

Hinweis:

Wenn der Poolmaster ausfällt, erfolgt die Wiederwahl des Masters nur, wenn Hochverfügbarkeit aktiviert ist.

Anforderungen für das Erstellen von Ressourcenpools

Ein Ressourcenpool ist ein homogenes (oder heterogenes Aggregat mit Einschränkungen) von einem oder mehreren Citrix Hypervisor-Servern, bis zu einem Maximum von 64. Die Definition von “homogen” lautet:

• CPUs auf dem Server, der dem Pool beitritt, sind dieselben (in Bezug auf Hersteller, Modell und Funktionen) wie die CPUs auf Servern, die sich bereits im Pool befinden.

• Auf dem Server, der dem Pool beitritt, wird dieselbe Version der Citrix Hypervisor-Software auf derselben Patch-Ebene ausgeführt wie auf den Servern, die sich bereits im Pool befinden.

Die Software setzt zusätzliche Einschränkungen durch, wenn ein Server zu einem Pool hinzugefügt wird. Citrix Hypervisor überprüft insbesondere, ob die folgenden Bedingungen für den Server zutreffen, der dem Pool beitritt:

• Der Server ist kein Mitglied eines vorhandenen Ressourcenpools.

• Auf dem Server ist kein gemeinsam genutzter Speicher konfiguriert.

• Der Server hostet keine laufenden oder angehaltenen VMs.

• Auf den virtuellen Rechnern auf dem Server werden keine aktiven Vorgänge ausgeführt, z. B. beim Herunterfahren einer VM.

• Die Uhr auf dem Server wird zur gleichen Zeit wie der Poolmaster synchronisiert (z. B. mithilfe von NTP).

• Die Verwaltungsschnittstelle des Servers ist nicht gebunden. Sie können die Verwaltungsschnittstelle konfigurieren, wenn der Server dem Pool erfolgreich beitritt.

• Die Verwaltungs-IP-Adresse ist statisch und wird entweder auf dem Server selbst oder mithilfe einer entsprechenden Konfiguration auf Ihrem DHCP-Server konfiguriert.

Citrix Hypervisor-Server in Ressourcenpools können eine unterschiedliche Anzahl physischer Netzwerkschnittstellen enthalten und über lokale Speicherrepositories unterschiedlicher Größe verfügen. In der Praxis ist es oft schwierig, mehrere Server mit genau denselben CPUs zu erhalten, sodass geringfügige Abweichungen zulässig sind. Wenn es akzeptabel ist, Hosts mit unterschiedlichen CPUs als Teil desselben Pools zu haben, können Sie den Pool-Beitritt erzwingen, indem Sie den Parameter --force übergeben.

Alle Hosts im Pool müssen sich am selben Standort befinden und über ein Netzwerk mit geringer Latenz verbunden sein.

Hinweis:

Server, die gemeinsam genutzten NFS- oder iSCSI-Speicher für den Pool bereitstellen, müssen über eine statische IP-Adresse verfügen.

Ein Pool muss freigegebene Speicherrepositories enthalten, um auszuwählen, auf welchem Citrix Hypervisor-Server eine VM ausgeführt werden soll, und um eine VM dynamisch zwischen Citrix Hypervisor-Servern zu verschieben. Wenn möglich, erstellen Sie einen Pool, nachdem gemeinsam genutzter Speicher verfügbar ist. Es wird empfohlen, vorhandene VMs mit Datenträgern im lokalen Speicher in den freigegebenen Speicher zu verschieben, nachdem Sie gemeinsam genutzten Speicher hinzugefügt haben. Sie können den Befehl xe vm-copy oder XenCenter verwenden, um VMs zu verschieben.

Erstellen eines Ressourcenpools

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 erbt einige Einstellungen vom Pool:

• VM-, lokale und Remote-Speicherkonfiguration wird der poolweiten Datenbank hinzugefügt. Diese Konfiguration wird auf den beitretenden Host im Pool angewendet, sofern Sie die Ressourcen nicht explizit freigeben, nachdem der Host dem Pool beigetreten ist.

• Der beitretende Host erbt vorhandene freigegebene Speicherrepositories im Pool. Entsprechende PBD-Datensätze werden 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 gebundenen Schnittstellen werden alle vererbt, Richtlinieninformationen jedoch nicht. Zu diesen Richtlinieninformationen, die neu konfiguriert werden müssen, gehören:

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

  • Der Speicherort der Verwaltungsschnittstelle, der der ursprünglichen Konfiguration entspricht. Wenn die anderen Pool-Hosts beispielsweise Verwaltungsschnittstellen auf einer gebundenen Schnittstelle haben, muss der beitretende Host nach dem Beitritt zur Bindung migriert werden.

  • Dedizierte Speicher-NICs, die dem beitretenden Host von XenCenter oder der CLI neu zugewiesen werden müssen, und die PBDs müssen neu angeschlossen werden, um den Datenverkehr entsprechend weiterzuleiten. Dies liegt daran, dass IP-Adressen nicht im Rahmen des Pool-Join-Vorgangs 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 Verwalten von Netzwerken.

Hinweis:

Sie können einen neuen Host nur mit einem Ressourcenpool verbinden, wenn sich die Verwaltungsschnittstelle des Hosts im selben markierten VLAN wie das des Ressourcenpools befindet.

Host zu einem Pool mit der xe-CLI hinzufügen

1. Öffnen Sie eine Konsole auf dem Citrix Hypervisor-Host, den Sie einem Pool hinzufügen möchten.

2. Verbinden Sie den Citrix Hypervisor-Host mit dem Pool, indem Sie den folgenden Befehl eingeben:

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

   Die master-address muss auf den vollqualifizierten Domänennamen des Poolkoordinators gesetzt werden. Das password muss das Administratorkennwort sein, das bei der Installation des Poolkoordinators festgelegt wurde.

Hinweis:

Wenn Sie einen Host zu einem Pool hinzufügen, wird das Administratorkennwort für den beitretenden Host automatisch so geändert, dass es dem Administratorkennwort des Poolkoordinators entspricht.

Citrix Hypervisor-Server gehören standardmäßig zu einem unbenannten Pool. Um Ihren ersten Ressourcenpool zu erstellen, benennen Sie den vorhandenen namenlosen Pool um. Verwenden Sie tab-complete, um Folgendes zu finden pool_uuid:

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

Erstellen heterogener Ressourcenpools

Citrix Hypervisor vereinfacht die Erweiterung von Bereitstellungen im Laufe der Zeit, indem unterschiedliche Host-Hardware mit einem Ressourcenpool verbunden werden kann, der als heterogene Ressourcenpools bezeichnet wird. Heterogene Ressourcenpools werden durch den Einsatz von Technologien in Intel (FlexMigration) und AMD (Extended Migration) CPUs ermöglicht, die eine “Maskierung” oder “Leveling” der CPU ermöglichen. Mit CPU-Maskierung und -Leveling kann eine CPU so konfiguriert werden, dass sie eine andere Marke, ein anderes Modell oder eine andere Funktionalität vorgibt als sie tatsächlich ist. Mit dieser Funktion können Sie Pools von Hosts mit unterschiedlichen CPUs erstellen und dennoch die Livemigration sicher unterstützen.

Hinweis:

Die CPUs von Citrix Hypervisor-Servern, die heterogenen Pools beitreten, müssen vom gleichen Anbieter (d. h. AMD, Intel) sein wie die CPUs der Hosts, die sich bereits im Pool befinden. Es ist jedoch nicht erforderlich, dass es sich bei den Servern um den gleichen Typ handelt, was die Familien-, Modell- oder Schrittnummern angeht.

Citrix Hypervisor vereinfacht die Unterstützung heterogener Pools. Hosts können jetzt zu vorhandenen Ressourcenpools hinzugefügt werden, unabhängig vom zugrunde liegenden CPU-Typ (sofern die CPU aus derselben Herstellerfamilie stammt). Das Pool-Feature-Set wird jedes Mal dynamisch berechnet:

• Ein neuer Host tritt dem Pool bei

• Ein Poolmitglied verlässt den Pool

• Ein Poolmitglied stellt nach einem Neustart eine Verbindung wieder her

Jede Änderung des Pool-Feature-Sets wirkt sich nicht auf VMs aus, die derzeit im Pool ausgeführt werden. Eine laufende VM verwendet weiterhin den Funktionssatz, der beim Start angewendet wurde. Dieser Funktionsumfang wird beim Booten behoben und bleibt bei Migrations-, Aussetzungs- und Fortsetzungsvorgängen bestehen Wenn die Poolebene abfällt, wenn ein Host mit weniger Funktionen dem Pool beitritt, kann eine laufende VM auf jeden Host im Pool migriert werden, mit Ausnahme des neu hinzugefügten Hosts. Wenn Sie eine VM auf einen anderen Host innerhalb oder über Pools hinweg verschieben oder migrieren, vergleicht Citrix Hypervisor den Funktionssatz der VM mit dem Funktionssatz des Zielhosts. Wenn sich herausstellt, dass die Feature-Sets kompatibel sind, kann die VM migriert werden. Auf diese Weise kann sich die VM frei innerhalb und zwischen Pools bewegen, unabhängig von den CPU-Funktionen, die die VM verwendet. Wenn Sie den 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.

Shared Storage hinzufügen

Eine vollständige Liste der unterstützten freigegebenen Speichertypen finden Sie unter Speicherrepository-Formate. In diesem Abschnitt wird gezeigt, wie gemeinsam genutzter Speicher (dargestellt als Speicherrepository) auf einem vorhandenen NFS-Server erstellt werden kann.

So fügen Sie gemeinsam genutzten NFS-Speicher über die CLI zu einem Ressourcenpool hinzu

1. Öffnen Sie eine Konsole auf einem beliebigen Citrix Hypervisor-Server im Pool.

2. Erstellen Sie das Speicherrepository 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 Citrix Hypervisor-Server im Pool verbunden. Alle Citrix Hypervisor-Server, die später beitreten, sind ebenfalls mit dem Speicher verbunden. Der Universally Unique Identifier (UUID) des Speicherrepositorys wird auf dem Bildschirm gedruckt.

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

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

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

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

   Da der freigegebene Speicher als poolweiter Standard festgelegt wurde, werden die Datenträger aller zukünftigen VMs standardmäßig auf freigegebenem Speicher erstellt. Informationen zum Erstellen anderer Arten von freigegebenem Speicher finden Sie unter Speicherrepository-Formate.

Entfernen von Citrix Hypervisor-Servern aus einem Ressourcenpool

Hinweis:

Stellen Sie vor dem Entfernen eines Citrix Hypervisor-Servers aus einem Pool sicher, dass Sie alle auf diesem Host ausgeführten VMs herunterfahren. Andernfalls wird eine Warnung angezeigt, dass der Host nicht entfernt werden kann.

Wenn Sie einen Host aus einem Pool entfernen (auswerfen), wird der Computer neu gestartet, neu initialisiert und in einem Zustand belassen, der einer Neuinstallation ähnelt. Werfen Sie keine Citrix Hypervisor-Server aus einem Pool aus, wenn wichtige Daten auf den lokalen Datenträgern sind.

So entfernen Sie einen Host über die CLI aus einem Ressourcenpool

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 Citrix Hypervisor-Server wird ausgeworfen und befindet sich in einem neu installierten Zustand.

   Warnung:

   Werfen Sie keinen Host aus einem Ressourcenpool aus, wenn er wichtige Daten enthält, die auf seinen lokalen Datenträgern gespeichert sind. Alle Daten werden gelöscht, wenn ein Host aus dem Pool ausgeworfen wird. Wenn Sie diese Daten beibehalten möchten, kopieren Sie die VM mit XenCenter oder dem CLI-Befehl xe vm-copy in den freigegebenen Speicher im Pool.

Wenn Citrix Hypervisor-Server mit lokal gespeicherten VMs aus einem Pool ausgeworfen werden, sind die VMs in der Pooldatenbank vorhanden. Die lokal gespeicherten VMs sind auch für die anderen Citrix Hypervisor-Server sichtbar. Die VMs werden erst gestartet, wenn die ihnen zugeordneten virtuellen Datenträger so geändert wurden, dass sie auf gemeinsam genutzten Speicher zeigen, den andere Citrix Hypervisor-Server im Pool sehen, oder entfernt wurden. Daher empfehlen wir, dass Sie jeden lokalen Speicher in den freigegebenen Speicher verschieben, wenn Sie einem Pool beitreten. Durch die Umstellung auf gemeinsam genutzten Speicher können einzelne Citrix Hypervisor-Server ohne Datenverlust ausgeworfen (oder physisch ausfallen).

Hinweis:

Wenn ein Host aus einem Pool entfernt wird, dessen Verwaltungsschnittstelle sich in einem markierten VLAN-Netzwerk befindet, wird der Computer neu gestartet und seine Verwaltungsschnittstelle ist im selben Netzwerk verfügbar.

Bereiten Sie einen Pool von Citrix Hypervisor-Servern für die Wartung vor

Bevor Sie Wartungsvorgänge auf einem Host ausführen, der Teil eines Ressourcenpools ist, müssen Sie ihn deaktivieren. Durch das Deaktivieren des Hosts wird verhindert, dass VMs darauf gestartet werden. Sie müssen dann die VMs auf einen anderen Citrix Hypervisor-Server im Pool migrieren. Sie können dies tun, indem Sie den Citrix Hypervisor-Server mit XenCenter in den Wartungsmodus versetzen. Weitere Informationen finden Sie unter Im Wartungsmodus ausführen in der XenCenter-Dokumentation.

Die Backupsynchronisierung erfolgt alle 24 Stunden. Wenn Sie den Masterhost in den Wartungsmodus versetzen, gehen die letzten 24 Stunden an RRD-Updates für Offline-VMs verloren.

Warnung:

Wir empfehlen dringend, alle Citrix Hypervisor-Server neu zu starten, bevor Sie ein Update installieren und dann ihre Konfiguration überprüfen. Einige Konfigurationsänderungen werden nur wirksam, wenn der Citrix Hypervisor-Server neu gestartet wird, sodass der Neustart möglicherweise Konfigurationsprobleme aufdeckt, die zum Fehlschlagen des Updates führen können.

So bereiten Sie einen Host in einem Pool über die CLI für Wartungsvorgänge vor

1. Führen Sie den folgenden Befehl aus:

   xe host-disable uuid=Citrix Hypervisor_host_uuid
   xe host-evacuate uuid=Citrix Hypervisor_host_uuid
   <!--NeedCopy-->
   

   Dieser Befehl deaktiviert den Citrix Hypervisor-Server und migriert dann alle laufenden VMs auf andere Citrix Hypervisor-Server im Pool.

2. Führen Sie den gewünschten Wartungsvorgang durch.

3. Aktivieren Sie den Citrix Hypervisor-Server, wenn der Wartungsvorgang abgeschlossen ist:

   xe host-enable
   <!--NeedCopy-->
   

4. Starten Sie alle angehaltenen VMs neu und setzen Sie alle gesperrten VMs fort.

Exportieren von Ressourcenpool-Daten

Mit der Option Ressourcendaten exportieren können Sie einen Ressourcendatenbericht für Ihren Pool erstellen und den Bericht in eine .xls- oder .csv-Datei exportieren. Dieser Bericht enthält detaillierte Informationen zu verschiedenen Ressourcen im Pool wie Server, Netzwerke, Speicher, virtuelle Maschinen, VDIs und GPUs. Mit dieser Funktion können Administratoren Ressourcen basierend auf verschiedenen Workloaden wie CPU, Speicher und Netzwerk verfolgen, planen und zuweisen.

Hinweis:

Ressourcenpooldaten exportieren ist für Citrix Hypervisor Premium Edition-Kunden oder Kunden verfügbar, die über ihre Citrix Virtual Apps and Desktops-Berechtigung oder Citrix DaaS-Berechtigung Zugriff auf Citrix Hypervisor haben.

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

Server:

• Name
• Poolmaster
• UUID
• Adresse
• CPU-Nutzung
• Netzwerk (avg/max kBs)
• Benutzter Speicher
• Speicher
• Betriebszeit
• Beschreibung

Netzwerke:

• Name
• Status verknüpfen
• MAC
• MTU
• VLAN
• Typ
• Ort

VDI:

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

Speicher:

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

Virtuelle Maschinen:

• Name
• Energiestatus
• Ausgeführt auf
• Adresse
• MAC
• Netzwerkkarte
• Betriebssystem
• Speicher
• Benutzter Speicher
• CPU-Nutzung
• UUID
• Betriebszeit
• Vorlage
• Beschreibung

GPU:

• Name
• Server
• PCI-Buspfad
• UUID
• Stromverbrauch
• Temperatur
• Benutzter Speicher
• Computernutzung

Hinweis:

Informationen zu GPUs sind nur verfügbar, wenn GPUs an Ihren Citrix Hypervisor-Server angeschlossen sind.

So exportieren Sie Ressourcendaten

1. Wählen Sie im XenCenter Navigationsbereich Infrastructure 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.

Host-Einschalten

Hosts remote einschalten

Sie können die Funktion zum Einschalten des Citrix Hypervisor-Servers verwenden, um einen Server entweder über XenCenter oder über die CLI remote ein- und auszuschalten.

Um die Host-Energie zu aktivieren, muss der Host über eine der folgenden Stromsteuerungslösungen verfügen:

• Wake on LAN-fähige Netzwerkkarte.

• Dell Remote-Zugriffskarten (DRAC). Um Citrix Hypervisor mit DRAC zu verwenden, müssen Sie das Dell Zusatzpaket installieren, um DRAC-Unterstützung zu erhalten. Für die DRAC-Unterstützung muss das RACADM-Befehlszeilendienstprogramm auf dem Server mit dem RAS-Controller installiert und DRAC und seine Schnittstelle aktiviert werden. RACADM ist oft in der DRAC-Management-Software enthalten. Weitere Informationen finden Sie in der DRAC-Dokumentation von Dell.

• Ein benutzerdefiniertes Skript, das auf der Verwaltungs-API basiert und mit dem Sie das Ein- und Ausschalten über Citrix Hypervisor ermöglichen. Weitere Informationen finden Sie im folgenden Abschnitt unter Konfigurieren eines benutzerdefinierten Skripts für die Host-Einschaltfunktion .

Für die Verwendung der Host-Power-On-Funktion sind zwei Aufgaben erforderlich:

1. Stellen Sie sicher, dass die Hosts im Pool die Fernsteuerung der Stromversorgung unterstützen. Sie verfügen beispielsweise über Wake on LAN-Funktionalität oder eine DRAC-Karte, oder Sie haben ein benutzerdefiniertes Skript erstellt).

2. Aktivieren Sie die Host-Einschaltfunktion über die CLI oder XenCenter.

Verwenden Sie die CLI, um das Einschalten des Hosts zu verwalten

Sie können das Host-Einschaltfeature entweder mit der CLI oder XenCenter verwalten. Dieser Abschnitt enthält Informationen zur Verwaltung mit der CLI.

Host Power On ist auf Host-Ebene aktiviert (d. h. auf jedem Citrix Hypervisor).

Nachdem Sie Host Power On aktiviert haben, können Sie Hosts entweder mit der CLI oder XenCenter einschalten.

So aktivieren Sie das Host-Einschalten über die CLI

Führen Sie den Befehl aus:

xe host-set-power-on-mode host=<host uuid> \
    power-on-mode=("" , "wake-on-lan", "DRAC","custom") \
    power-on-config=key:value
<!--NeedCopy-->

Für DRAC müssen die Schlüssel power_on_ip das Kennwort angeben, wenn Sie die Secret-Funktion verwenden. Weitere Informationen finden Sie unter Secrets.

So schalten Sie Hosts über die CLI remote ein

Führen Sie den Befehl aus:

xe host-power-on host=<host uuid>
<!--NeedCopy-->

Konfigurieren Sie ein benutzerdefiniertes Skript für die Host-Einschaltfunktion

Wenn die Remote-Stromversorgungslösung Ihres Servers ein Protokoll verwendet, das nicht standardmäßig unterstützt wird (z. B. Wake-On-Ring oder Intel Active Management Technology), können Sie ein benutzerdefiniertes Linux-Python-Skript erstellen, um Ihre Citrix Hypervisor Computer remote einzuschalten. Sie können jedoch auch benutzerdefinierte Skripte für DRAC- und Wake-on-LAN-Remote-Stromversorgungslösungen erstellen.

Dieser Abschnitt enthält Informationen zum Konfigurieren eines benutzerdefinierten Skripts für Host Power On mithilfe der Schlüssel/Wert-Paare, die mit dem Citrix Hypervisor API-Aufruf verknüpft sind host.power_on.

Wenn Sie ein benutzerdefiniertes Skript erstellen, führen Sie es jedes Mal über die Befehlszeile aus, wenn Sie die Stromversorgung auf einem Citrix Hypervisor-Server remote steuern möchten. Alternativ können Sie es in XenCenter angeben und die XenCenter UI-Funktionen verwenden, um damit zu interagieren.

Die Citrix Hypervisor API ist in dem Dokument, der Citrix Hypervisor Management-API, dokumentiert, die auf der Website der Entwicklerdokumentation verfügbar ist.

Warnung:

Ändern Sie nicht die standardmäßig im Verzeichnis /etc/xapi.d/plugins/ bereitgestellten Skripts. Sie können neue Skripte in dieses Verzeichnis aufnehmen, aber Sie dürfen die in diesem Verzeichnis enthaltenen Skripte nach der Installation niemals ändern.

Schlüssel/Wert-Paare

Um Host Power On zu verwenden, konfigurieren Sie die Schlüssel host.power_on_mode und host.power_on_config. Im folgenden Abschnitt finden Sie Informationen zu den Werten.

Es gibt auch einen API-Aufruf, mit dem Sie diese Felder gleichzeitig festlegen können:

void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->

host.power_on_mode

• Definition: Enthält Schlüssel/Wert-Paare zur Angabe des Typs der Remote-Stromversorgungslösung (z. B. Dell DRAC).

• Mögliche Werte:

  • Eine leere Zeichenfolge, die für deaktivierte Energiesteuerung steht.

  • “DRAC”: Ermöglicht die Angabe von Dell DRAC. Um DRAC verwenden zu können, müssen Sie das Dell Zusatzpaket bereits installiert haben.

  • “wake-on-lan”: Ermöglicht die Angabe von Wake-on-LAN.

  • Jeder andere Name (wird verwendet, um ein benutzerdefiniertes Einschaltskript anzugeben). Diese Option wird verwendet, um ein benutzerdefiniertes Skript für die Energieverwaltung anzugeben.

• Typ: string

host.power_on_config

• Definition: Enthält Schlüssel/Wert-Paare für die Moduskonfiguration. Stellt zusätzliche Informationen für DRAC bereit.

• Mögliche Werte:

  • Wenn Sie DRAC als Typ der Remote-Stromversorgungslösung konfiguriert haben, müssen Sie auch einen der folgenden Schlüssel angeben:

    • “power_on_ip”: Die IP-Adresse, die Sie für die Kommunikation mit der Stromsteuerungskarte konfiguriert haben. Alternativ können Sie den Domänennamen für die Netzwerkschnittstelle eingeben, auf der DRAC konfiguriert ist.

    • “power_on_user”: Der mit dem Verwaltungsprozessor verknüpfte DRAC-Benutzername, den Sie möglicherweise gegenüber den werkseitigen Standardeinstellungen geändert haben.

    • “power_on_password_secret”: Gibt die Verwendung der Secrets Funktion an, um Ihr Kennwort zu sichern.

  • Um das Secrets Feature zum Speichern Ihres Kennworts zu verwenden, geben Sie den Schlüssel “power_on_password_secret” an. Weitere Informationen finden Sie unter Secrets.

• Typ: Map (Zeichenfolge, Zeichenfolge)

Beispiel eines Skripts

Das Beispielskript importiert die Citrix Hypervisor API, definiert sich selbst als benutzerdefiniertes Skript und übergibt dann spezifische Parameter für den Host, den Sie remote steuern möchten. Sie müssen die Parameter session in allen benutzerdefinierten Scripts definieren.

Das Ergebnis wird angezeigt, wenn das Script nicht erfolgreich ist.

import XenAPI
def custom(session,remote_host,
power_on_config):
result="Power On Not Successful"
for key in power_on_config.keys():
result=result+''
key=''+key+''
value=''+power_on_config[key]
return result
<!--NeedCopy-->

Hinweis:

Nachdem Sie das Skript erstellt haben, speichern Sie es in /etc/xapi.d/plugins mit der Erweiterung .py.

Kommunizieren Sie mit Citrix Hypervisor-Servern und Ressourcenpools

TLS

Citrix Hypervisor verwendet das TLS 1.2-Protokoll, um den Verwaltungs-API-Verkehr zu verschlüsseln. Jede Kommunikation zwischen Citrix Hypervisor und Verwaltungs-API-Clients (oder Appliances) verwendet das TLS 1.2-Protokoll.

Wichtig:

Wir unterstützen keine Kundenänderungen an der kryptographischen Funktionalität des Produkts.

Citrix Hypervisor verwendet die folgende Verschlüsselungssammlung:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Darüber hinaus werden die folgenden Verschlüsselungssammlungen für die Abwärtskompatibilität mit einigen Versionen von Citrix Virtual Apps and Desktops unterstützt:

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Hinweis:

Diese zusätzlichen Verschlüsselungssammlungen verwenden den CBC-Modus. Obwohl einige Unternehmen den GCM-Modus bevorzugen, unterstützt Windows Server 2012 R2 keine RSA-Verschlüsselungssammlungen mit GCM-Modus. Clients, die auf Windows Server 2012 R2 ausgeführt werden und eine Verbindung zu einem Citrix Hypervisor-Server oder -Pool herstellen, müssen möglicherweise diese Verschlüsselungssammlungen im CBC-Modus verwenden.

SSH

Wenn Sie einen SSH-Client verwenden, um eine direkte Verbindung zum Citrix Hypervisor-Server herzustellen, können die folgenden Algorithmen verwendet werden:

Chiffren:

• aes128-ctr
• aes256-ctr
• aes128-gcm@openssh.com
• aes256-gcm@openssh.com
• aes128-cbc
• aes256-cbc

MACs:

• hmac-sha2-256
• hmac-sha2-512
• hmac-sha1

KexAlgorithms:

• curve25519-sha256
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521
• diffie-hellman-group14-sha1

HostKeyAlgorithms:

• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521
• ssh-ed25519
• ssh-rsa

Hinweis:

Um die verfügbaren Verschlüsselungssammlungen auf die in der vorherigen Liste aufgeführten zu beschränken, stellen Sie sicher, dass Sie Hotfix XS82E015 - Für Citrix Hypervisor 8.2installieren.

Wenn Sie den SSH-Zugriff auf Ihren Citrix Hypervisor-Server deaktivieren möchten, können Sie dies in xsconsole tun.

1. Öffnen Sie in XenCenter die Serverkonsole und melden Sie sich als root an.
2. Geben Sie xsconsole ein.

3. Gehen Sie in xsconsole zu Remote Service Configuration > Remoteshell aktivieren/deaktivieren.

   Die Konsole zeigt an, ob Remoteshell aktiviert ist.

4. Um zu ändern, ob die Remoteshell aktiviert oder deaktiviert ist, drücken Sie die EINGABETASTE.

Wichtig:

Wir unterstützen keine Kundenänderungen an der kryptographischen Funktionalität des Produkts.

TLS-Zertifikat auf dem Server installieren

Der Citrix Hypervisor-Server wird mit einem Standard-TLS-Zertifikat installiert. Um jedoch HTTPS für die sichere Kommunikation zwischen Citrix Hypervisor und Citrix Virtual Apps and Desktops zu verwenden, müssen Sie ein Zertifikat installieren, das von einer vertrauenswürdigen Zertifizierungsstelle bereitgestellt wird.

In diesem Abschnitt wird beschrieben, wie Sie über die xe-CLI Zertifikate installieren. Informationen zum Arbeiten mit Zertifikaten über XenCenter finden Sie in der XenCenter-Dokumentation.

Stellen Sie sicher, dass Ihr TLS-Zertifikat und sein Schlüssel die folgenden Anforderungen erfüllen:

• Das Zertifikat und das Schlüsselpaar sind ein RSA-Schlüssel.
• Der Schlüssel stimmt mit dem Zertifikat überein.
• Der Schlüssel wird in einer separaten Datei für das Zertifikat bereitgestellt.
• Das Zertifikat wird in einer separaten Datei zu allen Zwischenzertifikaten bereitgestellt.
• Die Schlüsseldatei muss einen der folgenden Typen haben: .pem oder .key.
• Alle Zertifikatsdateien müssen einen der folgenden Typen haben: .pem, .cer, oder .crt.
• Der Schlüssel ist größer oder gleich 2048 Bit und kleiner oder gleich 4096 Bit lang.
• Der Schlüssel ist ein unverschlüsselter PKCS #8 -Schlüssel und hat keinen Hauptschlüssel.
• Der Schlüssel und das Zertifikat liegen im Base-64-kodierten PEM-Format vor.
• Das Zertifikat ist gültig und nicht abgelaufen.
• Der Signaturalgorithmus ist SHA-2 (SHA256).

Die xe CLI warnt Sie, wenn das Zertifikat und der Schlüssel, die Sie wählen, diese Anforderungen nicht erfüllen.

Wo erhalte ich ein TLS-Zertifikat?

• Möglicherweise haben Sie bereits ein vertrauenswürdiges Zertifikat, das Sie auf Ihrem Citrix Hypervisor-Server installieren möchten.

• Alternativ können Sie ein Zertifikat auf Ihrem Server erstellen und es zur Signierung an Ihre bevorzugte Zertifizierungsstelle senden. Diese Methode ist sicherer, da der private Schlüssel auf dem Citrix Hypervisor-Server verbleiben und nicht zwischen Systemen kopiert werden kann.

  Das Erstellen eines TLS-Zertifikats umfasst die folgenden Schritte:

  1. Generieren Sie eine Anfrage zum Signieren eines Zertifikats
  2. Senden Sie die Zertifikatssignieranforderung an eine Zertifizierungsstelle
  3. Installieren Sie das signierte Zertifikat auf Ihrem Citrix Hypervisor-Server

1. Generieren Sie eine Anfrage zum Signieren eines Zertifikats

Generieren Sie zunächst einen privaten Schlüssel und eine Zertifikatssignieranforderung. Führen Sie auf dem Citrix Hypervisor-Server die folgenden Schritte aus:

1. Führen Sie den folgenden Befehl aus, um eine private Schlüsseldatei zu erstellen:

   openssl genrsa -des3 -out privatekey.pem 2048
   <!--NeedCopy-->
   

2. Entferne das Kennwort aus dem Schlüssel:

   openssl rsa -in privatekey.pem -out privatekey.nop.pem
   <!--NeedCopy-->
   

3. Erstellen Sie die Zertifikatssignierungsanforderung mithilfe des privaten Schlüssels:

   openssl req -new -key privatekey.nop.pem -out csr
   <!--NeedCopy-->
   

4. Befolgen Sie die Anweisungen, um die zum Generieren der Zertifikatssignierungsanforderung erforderlichen Informationen anzugeben.

   • Name des Landes. Geben Sie die Ländercodes des TLS-Zertifikats für Ihr Land ein. Zum Beispiel CA für Kanada oder JM für Jamaika. Eine Liste der Ländercodes für TLS-Zertifikate finden Sie im Internet.
   • Name des Bundesstaates oder der Provinz (vollständiger Name). Geben Sie den Bundesstaat oder die Provinz an, in der sich der Pool befindet. Zum Beispiel Massachusetts oder Alberta.
   • Name der Lokalität. Der Name der Stadt, in der sich der Pool befindet.
   • Name der Organisation. Der Name Ihres Unternehmens oder Ihrer Organisation.
   • Name der Organisationseinheit. Geben Sie den Namen der Abteilung ein. Das Feld ist optional.
   • Common Name: Geben Sie den FQDN Ihres Citrix Hypervisor-Servers ein. Citrix empfiehlt, entweder einen FQDN oder eine IP-Adresse anzugeben, die nicht abläuft.
   • E-Mail-Adresse: Diese E-Mail-Adresse ist im Zertifikat enthalten, wenn Sie es generieren.

   Die Anforderung zum Signieren des Zertifikats wird im aktuellen Verzeichnis gespeichert und hat den Namen csr.

5. Zeigen Sie die Zertifikatssignierungsanforderung im Konsolenfenster an, indem Sie den folgenden Befehl ausführen:

   cat csr
   <!--NeedCopy-->
   

6. Kopieren Sie die gesamte Zertifikatssignierungsanforderung und verwenden Sie diese Informationen, um das Zertifikat von der Zertifizierungsstelle anzufordern.

   Beispiel für eine Zertifikatsignieranforderung:

   -----BEGIN CERTIFICATE REQUEST-----
   MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
   aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
   ...
   SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
   Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
   ZL8naumG3yU=
   -----END CERTIFICATE REQUEST-----
   <!--NeedCopy-->
   

2. Senden Sie die Zertifikatssignieranforderung an eine Zertifizierungsstelle

Nachdem Sie die Zertifikatsignieranforderung generiert haben, können Sie die Anfrage an die bevorzugte Zertifizierungsstelle Ihrer Organisation senden.

Eine Zertifizierungsstelle ist ein vertrauenswürdiger Drittanbieter, der digitale Zertifikate bereitstellt. Einige Zertifizierungsstellen verlangen, dass die Zertifikate auf einem System gehostet werden, auf das über das Internet zugegriffen werden kann. Wir empfehlen, für diese Anforderung keine Zertifizierungsstelle zu verwenden.

Die Zertifizierungsstelle beantwortet Ihre Signaturanfrage und stellt die folgenden Dateien zur Verfügung:

• das signierte Zertifikat
• ein Stammzertifikat
• falls zutreffend, ein Zwischenzertifikat

Sie können jetzt all diese Dateien auf Ihrem Citrix Hypervisor-Server installieren.

3. Installieren Sie das signierte Zertifikat auf Ihrem Citrix Hypervisor-Server

Nachdem die Zertifizierungsstelle auf die Zertifikatssignierungsanforderung geantwortet hat, führen Sie die folgenden Schritte aus, um das Zertifikat auf Ihrem Citrix Hypervisor-Server zu installieren:

1. Holen Sie sich das signierte Zertifikat, das Stammzertifikat und, falls die Zertifizierungsstelle eines hat, das Zwischenzertifikat von der Zertifizierungsstelle.
2. Kopieren Sie den Schlüssel und die Zertifikate auf den Citrix Hypervisor-Server.

3. Führen Sie den folgenden Befehl auf dem Server aus:

   xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>
   

   Der Parameter certificate-chain ist optional.

Für zusätzliche Sicherheit können Sie die private Schlüsseldatei löschen, nachdem das Zertifikat installiert wurde.

Administratorkennwort verwalten

Bei der ersten Installation eines Citrix Hypervisor-Servers legen Sie ein Administrator- oder Root-Kennwort fest. Mit diesem Kennwort verbinden Sie XenCenter mit Ihrem Server oder (mit dem Benutzernamen root), um sich bei xsconsole, der Systemkonfigurationskonsole, anzumelden.

Wenn Sie einen Server einem Pool beitreten, wird das Administratorkennwort für den Server automatisch an das Administratorkennwort des Poolmasters angepasst.

Hinweis:

Citrix Hypervisor-Administratorkennwörter dürfen nur ASCII-Zeichen enthalten.

Das Kennwort ändern

Sie können XenCenter, die xe CLI oder xsconsole verwenden, um das Administratorkennwort zu ändern.

XenCenter

Führen Sie die folgenden Schritte aus, um das Administratorkennwort für einen Pool oder einen eigenständigen Server mit XenCenter zu ändern:

1. Wählen Sie im Bereich Ressourcen den Pool oder einen beliebigen Server im Pool aus.
2. Wählen Sie im Menü Pool oder im Menü Server die Option Serverkennwort ändernaus.

Um das Rootkennwort eines eigenständigen Servers zu ändern, wählen Sie den Server im Bereich Ressourcen aus und klicken Sie im Menü Server auf Kennwort und dann auf Ändern.

Wenn XenCenter so konfiguriert ist, dass die Anmeldeinformationen des Servers zwischen Sitzungen gespeichert werden, wird das neue Kennwort gespeichert. Weitere Informationen finden Sie unter Speichern des Verbindungsstatus Ihres Servers.

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis. Weitere Informationen finden Sie unter Rotation des Poolgeheimnisses.

xe CLI

Um das Administratorkennwort über die xe-CLI zu ändern, führen Sie den folgenden Befehl auf einem Server im Pool aus:

  xe user-password-change new=<new_password>
<!--NeedCopy-->

Hinweis:

Stellen Sie sicher, dass Sie dem Befehl ein Leerzeichen voranstellen, um zu vermeiden, dass das Klartextkennwort im Befehlsverlauf gespeichert wird.

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis. Weitere Informationen finden Sie unter Rotation des Poolgeheimnisses.

xsconsole

Um das Administratorkennwort für einen Pool oder einen eigenständigen Server mithilfe von xsconsolezu ändern, führen Sie die folgenden Schritte aus:

1. Gehen Sie auf dem Poolmaster zur Konsole.
2. Logge dich ein als root.
3. Geben Sie xsconsole ein. Drücken Sie die Eingabetaste. Die xsconsole wird angezeigt.
4. Navigieren Sie in xsconsolemit den Pfeiltasten zur Option Authentifizierung . Drücken Sie die Eingabetaste.
5. Navigieren Sie zu Kennwort ändern. Drücken Sie die Eingabetaste.
6. Authentifizieren Sie sich mit dem Administratorkennwort.
7. Gehen Sie im Dialog Kennwort ändern wie folgt vor
   1. Geben Sie Ihr aktuelles Kennwort ein.
   2. Geben Sie ein neues Kennwort ein.
   3. Geben Sie das neue Kennwort noch einmal ein, um es zu bestätigen.

   Der Bildschirm “ Kennwortänderung erfolgreich “ wird angezeigt. Drücken Sie zum Schließen die Eingabetaste .

Wenn der Server Poolmaster ist, wird dieses aktualisierte Kennwort jetzt an die anderen Server im Pool weitergegeben.

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis. Weitere Informationen finden Sie unter Rotation des Poolgeheimnisses.

Ein verlorenes Root-Kennwort zurücksetzen

Wenn Sie das Administratorkennwort (Root) für Ihren Citrix Hypervisor-Server verlieren, können Sie das Kennwort zurücksetzen, indem Sie direkt auf den Server zugreifen.

1. Starten Sie den Citrix Hypervisor-Server neu.

2. Wenn das GRUB-Menü angezeigt wird, drücken Sie e, um den Startmenüeintrag zu bearbeiten.

3. Fügen Sie init=/sysroot/bin/sh zu der Zeile hinzu, die mit module2 beginnt.

4. Drücken Sie Strg-X, um in eine Root-Shell zu booten.

5. Führen Sie in der Befehlsshell die folgenden Befehle aus:

   chroot /sysroot
   passwd
   
   (type the new password twice)
   
   sync
   /sbin/reboot -f
   <!--NeedCopy-->
   

Wenn der Server Poolmaster ist, wird dieses aktualisierte Kennwort jetzt an die anderen Server im Pool weitergegeben.

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis.

Poolgeheimnis rotieren

Das Poolgeheimnis ist ein Geheimnis, das von den Servern in einem Pool geteilt wird und es dem Server ermöglicht, seine Mitgliedschaft in einem Pool nachzuweisen.

Da Benutzer mit der Pool-Admin-Rolle dieses Geheimnis herausfinden können, empfiehlt es sich, das Pool-Geheimnis zu rotieren, wenn einer dieser Benutzer Ihre Organisation verlässt oder seine Pool-Admin-Rolle verliert.

Sie können das Poolgeheimnis über XenCenter oder die xe-CLI rotieren.

XenCenter

Führen Sie die folgenden Schritte aus, um das Poolgeheimnis für einen Pool mit XenCenter zu rotieren:

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

Wenn Sie das Poolgeheimnis rotieren, werden Sie auch aufgefordert, das root-Kennwort zu ändern. Wenn Sie das Poolgeheimnis rotiert haben, weil Sie glauben, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Kennwort ändern. Weitere Informationen finden Sie unter Ändern des Kennworts.

xe CLI

Um das Poolgeheimnis über die xe-CLI zu rotieren, führen Sie den folgenden Befehl auf einem Server im Pool aus:

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

Wenn Sie das Poolgeheimnis rotiert haben, weil Sie glauben, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Kennwort ändern. Weitere Informationen finden Sie unter Ändern des Kennworts.

Aktivieren Sie IGMP-Snooping in Ihrem Citrix Hypervisor-Pool

Citrix Hypervisor sendet Multicast-Datenverkehr an alle Gast-VMs, was zu unnötiger Belastung der Hostgeräte führt, indem sie Pakete verarbeiten müssen, die sie nicht angefordert haben. Durch die Aktivierung des IGMP-Snoopings wird verhindert, dass Hosts in einem lokalen Netzwerk Datenverkehr für eine Multicastgruppe empfangen, denen 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:

• IGMP-Snooping ist nur verfügbar, wenn das Netzwerk-Backend Open vSwitch verwendet.

• Wenn Sie diese Funktion in einem Pool aktivieren, kann es auch erforderlich sein, den IGMP-Abfrager auf einem der physischen Switches zu aktivieren. Andernfalls fällt Multicast im Subnetzwerk auf Broadcast zurück und kann die Leistung von Citrix Hypervisor beeinträchtigen.

• Wenn Sie diese Funktion in einem Pool aktivieren, auf dem IGMP v3 ausgeführt wird, führt VM-Migration oder Netzwerkbindung-Failover dazu, dass IGMP-Version auf v2 umgeschaltet wird.

• 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. Oder der Multicast-Verkehr im GRE-Netzwerk kann blockiert werden.

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

XenCenter

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

xe CLI

1. Holen Sie sich die Pool-UUID:

   xe pool-list

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

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

Nachdem Sie IGMP-Snooping aktiviert haben, können Sie die IGMP-Snooping-Tabelle mit der xe-CLI einsehen.

Sehen Sie sich die IGMP-Snooping-Tabelle an

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

ovs-appctl mdb/show [bridge name]

Hinweis:

Sie können den Namen der Brücke mit xe network-list abrufen. Diese Brückennamen können xenbr0, xenbr1, xenapi oder xapi0 lauten.

Dadurch wird eine Tabelle mit vier Spalten ausgegeben:

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

Wenn die GROUP eine Multicast-Gruppenadresse ist, bedeutet dies, dass eine IGMP-Berichtsmeldung auf dem zugehörigen Switch-Port empfangen wurde. Dies bedeutet, dass ein Empfänger (Mitglied) der Multicast-Gruppe diesen Port abhört.

Nehmen wir das folgende Beispiel, das zwei Datensätze enthält:

Der erste Datensatz zeigt, dass an Port 14 ein Empfänger die Multicast-Gruppe 227.0.0.1 abhört. Der Open vSwitch leitet Datenverkehr, der für die 227.0.0.1-Multicast-Gruppe bestimmt ist, nur an Listening-Ports für diese Gruppe weiter (in diesem Beispiel Port 14), anstatt ihn an alle Ports zu übertragen. Der Datensatz, 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 heißt, wenn der Switch nach dem Hinzufügen des Datensatzes 300 Sekunden lang keine weiteren IGMP-Report-Meldungen auf Port 14 empfängt, läuft der Datensatz ab und wird aus der Tabelle entfernt.

Im zweiten Datensatz ist die GROUPabfragender, was bedeutet, dass IGMP-Abfragenachrichten auf dem zugehörigen Port empfangen wurden. Ein Querier sendet regelmäßig IGMP-Abfragenachrichten, die an alle Switch-Ports gesendet werden, um festzustellen, welche Netzwerkknoten eine Multicast-Gruppe abhören. Auf den Empfang einer IGMP-Abfragenachricht antwortet der Empfänger mit einer IGMP-Berichtsnachricht, wodurch der Multicast-Datensatz des Empfängers aktualisiert wird und ein Ablauf vermieden wird.

Die VLAN-Spalte zeigt dem VLAN an, dass ein Receiver/Querier aktiv ist. ‘0’ bedeutet systemeigenes VLAN. Wenn Sie Multicast auf einem markierten VLAN ausführen möchten, stellen Sie sicher, dass das VLAN Datensätze enthält.

Hinweis:

Für das VLAN-Szenario sollten Sie einen Abfragedatensatz mit einem VLAN-Spaltenwert haben, der der VLAN-ID des Netzwerks entspricht, da Multicast sonst im VLAN-Netzwerk nicht funktioniert.