Hosts und Ressourcenpools

Wichtig:

Citrix Hypervisor 8.2 Kumulatives Update 1 wird am 25. Juni 2025 End of Life. Planen Sie jetzt Ihr Upgrade auf XenServer 8, um einen reibungslosen Übergang und kontinuierlichen Support zu gewährleisten. Weitere Informationen finden Sie unter Upgrade.

Wenn Sie Ihre Citrix Virtual Apps and Desktops-Lizenzdateien verwenden, um Ihre Citrix Hypervisor 8.2 Cumulative Update 1-Hosts zu lizenzieren, sind diese Lizenzdateien nicht mit XenServer 8 kompatibel. Vor dem Upgrade müssen Sie XenServer Premium Edition-Socket-Lizenzdateien für die Verwendung mit XenServer 8 erwerben. Diese Socket-Lizenzdateien sind als Berechtigung für die Abonnements Citrix für Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP und Citrix Platform License für die Ausführung Ihrer Citrix-Workloads verfügbar. Citrix-Kunden, die noch nicht auf diese neuen Abonnements umgestiegen sind, können die Teilnahme an einer kostenlosen Aktion für 10.000 XenServer Premium Edition-Socket-Lizenzen anfordern. Weitere Informationen finden Sie unter XenServer (Englisch).

Wenn Sie vor dem Upgrade keine kompatible Lizenz für XenServer 8 erhalten, werden Ihre Hosts beim Upgrade auf die 90-Tage-Testversion zurückgesetzt. Die Testversion bietet die gleichen Funktionen wie die Premium Edition, jedoch mit einigen Einschränkungen. Weitere Informationen finden Sie unter Übersicht über die XenServer 8-Lizenzierung.

In diesem Abschnitt wird beschrieben, wie Ressourcenpools anhand einer Reihe von Beispielen mithilfe der xe-Befehlszeilenschnittstelle (CLI) erstellt werden können. Es wird eine einfache NFS-basierte Konfiguration für gemeinsam genutzten Speicher vorgestellt und es werden mehrere einfache Beispiele für die VM-Verwaltung erläutert. Es enthält auch Verfahren für den Umgang mit physischen Knotenfehlern.

Übersicht über Citrix Hypervisor-Server und Ressourcenpools

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

Ein Pool verfügt immer über mindestens einen physischen Knoten, der als Meister. Nur der Master-Knoten stellt eine Verwaltungsschnittstelle zur Verfügung (wird von XenCenter und der Citrix Hypervisor-Befehlszeilenschnittstelle verwendet, die als xe CLI bezeichnet wird). Der Master leitet Befehle bei Bedarf an einzelne Stäbe weiter.

Hinweis:

Wenn der Poolmaster ausfällt, erfolgt die erneute Masterwahl nur, wenn die Hochverfügbarkeit aktiviert ist.

Anforderungen für das Erstellen von Ressourcenpools

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

• Die CPUs auf dem Server, der dem Pool beitritt, sind identisch (in Bezug auf Anbieter, 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 demselben Patch-Level ausgeführt wie auf den Servern, die sich bereits im Pool befinden.

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

• Der Server ist nicht Mitglied eines vorhandenen Ressourcenpools.

• Auf dem Server ist kein freigegebener Speicher konfiguriert.

• Der Server hostet keine ausgeführten oder angehaltenen VMs.

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

• Die Uhr auf dem Server wird mit der 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 erfolgreich dem Pool 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 Speicher-Repositories unterschiedlicher Größe verfügen. In der Praxis ist es oft schwierig, mehrere Server mit exakt gleichen CPUs zu erhalten, so dass 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-Joining-Vorgang erzwingen, indem Sie die --Kraft Parameter.

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 Speicher-Repositories 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. Erstellen Sie nach Möglichkeit einen Pool, nachdem freigegebener Speicher verfügbar ist. Es wird empfohlen, vorhandene VMs mit Datenträgern, die sich im lokalen Speicher befinden, nach dem Hinzufügen von freigegebenem Speicher in den freigegebenen Speicher zu verschieben. Sie können die Funktion xe vm-copy oder verwenden Sie XenCenter, 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 aus dem Pool:

• Die VM-, lokale und Remotespeicherkonfiguration wird der poolweiten Datenbank hinzugefügt. Diese Konfiguration wird auf den beitretenden Host im Pool angewendet, es sei denn, Sie machen die Ressourcen explizit freigegeben, nachdem der Host dem Pool beigetreten ist.

• Der beitretende Host erbt vorhandene Shared Storage-Repositorys im Pool. Entsprechende PBD-Einträge werden erstellt, damit der neue Host automatisch auf den vorhandenen Shared Storage zugreifen kann.

• Netzwerkinformationen werden teilweise an den beitretenden Host vererbt: die strukturell Details zu Netzwerkkarten, VLANs und gebundenen Schnittstellen werden alle geerbt, aber Politik Informationen sind es nicht. Zu diesen Richtlinieninformationen, die neu konfiguriert werden müssen, gehören:

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

  • Der Speicherort der Verwaltungsschnittstelle, der mit der ursprünglichen Konfiguration identisch bleibt. Wenn die anderen Pool-Hosts z. B. über Verwaltungsschnittstellen auf einer gebundenen Schnittstelle verfügen, muss der beitretende Host nach dem Beitritt zu der 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 im Rahmen des Poolbeitrittsvorgangs nicht zugewiesen werden und die Speicher-NIC nur funktioniert, wenn sie ordnungsgemäß konfiguriert ist. Weitere Informationen zum Dedizieren einer Speicher-NIC über die CLI finden Sie unter Verwalten des Netzwerks.

Hinweis:

Sie können einen neuen Host nur dann mit einem Ressourcenpool verknüpfen, wenn sich die Verwaltungsschnittstelle des Hosts im selben getaggten VLAN befindet wie die des Ressourcenpools.

Hinzufügen eines Hosts zu einem Pool mithilfe der xe CLI

1. Öffnen Sie eine Konsole auf dem Citrix Hypervisor-Host, dem Sie einem Pool beitreten möchten.

2. Treten Sie dem Citrix Hypervisor-Host dem Pool bei, indem Sie den folgenden Befehl ausgeben:

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

   Das Master-Adresse muss auf den vollqualifizierten Domänennamen des Poolmasters festgelegt werden. Das Passwort muss das Administratorkennwort sein, das bei der Installation des Poolmasters festgelegt wurde.

Hinweis:

Wenn Sie einen Host mit einem Pool verbinden, wird das Administratorkennwort für den beitretenden Host automatisch so geändert, dass es mit dem Administratorkennwort des Poolmasters übereinstimmt.

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 die Tabulatortaste, um die 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 Hosthardware in einen Ressourcenpool eingebunden werden kann, der als heterogene Ressourcenpools bezeichnet wird. Heterogene Ressourcenpools werden durch die Verwendung von Technologien in Intel- (FlexMigration) und AMD-CPUs (Extended Migration) ermöglicht, die CPU-“Masking” oder “Leveling” bieten. Mit den CPU-Maskierungs- und Nivellierungsfunktionen kann eine CPU so konfiguriert werden, dass erscheinen als Bereitstellung einer anderen Marke, eines anderen Modells oder einer anderen Funktionalität, als es tatsächlich der Fall ist. Mit dieser Funktion können Sie Pools von Hosts mit unterschiedlichen CPUs erstellen, die Livemigration dennoch sicher unterstützen.

Hinweis:

Die CPUs von Citrix Hypervisor-Servern, die heterogenen Pools beitreten, müssen vom selben Anbieter (d. h. AMD, Intel) sein wie die CPUs der Hosts, die sich bereits im Pool befinden. Es ist jedoch nicht erforderlich, dass die Server auf der Ebene der Familien-, Modell- oder Schrittnummern vom gleichen Typ sind.

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 (solange die CPU aus derselben Anbieterfamilie stammt). Der Funktionsumfang des Pools wird jedes Mal dynamisch berechnet:

• Ein neuer Host tritt dem Pool bei

• Ein Poolmitglied verlässt den Pool

• Ein Poolmitglied stellt nach einem Neustart die Verbindung wieder her

Änderungen am Poolfeaturesatz wirken sich nicht auf VMs aus, die derzeit im Pool ausgeführt werden. Eine ausgeführte VM verwendet weiterhin den Featuresatz, der beim Start angewendet wurde. Dieser Funktionssatz ist beim Booten fixiert und bleibt bei Migrations-, Suspend- und Resume-Vorgängen erhalten. Wenn die Poolebene sinkt, wenn ein weniger leistungsfähiger Host dem Pool beitritt, kann eine ausgeführte VM zu einem beliebigen Host im Pool migriert werden, mit Ausnahme des neu hinzugefügten Hosts. Wenn Sie eine VM innerhalb oder zwischen Pools auf einen anderen Host verschieben oder migrieren, vergleicht Citrix Hypervisor den Funktionsumfang der VM mit dem Funktionsumfang des Zielhosts. Wenn sich herausstellt, dass die Featuresätze 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 Arbeitslastausgleich verwenden, um einen optimalen Zielhost für die Migration Ihrer VM auszuwählen, wird ein Host mit einem inkompatiblen Funktionsumfang nicht als Zielhost empfohlen.

Hinzufügen von freigegebenem Speicher

Eine vollständige Liste der unterstützten Shared Storage-Typen finden Sie unter Formate des Speicher-Repositorys. In diesem Abschnitt wird gezeigt, wie Shared Storage (dargestellt als Storage Repository) auf einem vorhandenen NFS-Server erstellt werden kann.

So fügen Sie einem Ressourcenpool mithilfe der CLI freigegebenen NFS-Speicher 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-->
   

   Gerät-Konfiguration:Server ist der Hostname des NFS-Servers und Gerät-Konfiguration:ServerPfad ist der Pfad auf dem NFS-Server. Wie geteilt auf true festgelegt 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. Die Universally Unique Identifier (UUID) des Speicher-Repositorys 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 freigegebenen Speicher mit dem folgenden Befehl als poolweiten 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 im freigegebenen Speicher erstellt. Weitere Informationen zum Erstellen anderer Typen von freigegebenem Speicher finden Sie unter Formate des Speicher-Repositorys.

Entfernen von Citrix Hypervisor-Servern aus einem Ressourcenpool

Hinweis:

Bevor Sie einen Citrix Hypervisor-Server aus einem Pool entfernen, stellen Sie sicher, dass Sie alle VMs herunterfahren, die auf diesem Host ausgeführt werden. Andernfalls wird eine Warnung angezeigt, die besagt, dass der Host nicht entfernt werden kann.

Wenn Sie (ausstoßen) einen Host aus einem Pool erstellen, wird der Computer neu gestartet, neu initialisiert und in einem Zustand belassen, der einer Neuinstallation ähnelt. Werfen Sie Citrix Hypervisor-Server nicht 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 Citrix Hypervisor-Server wird ausgeworfen und verbleibt in einem neu installierten Zustand.

   Warnung:

   Tun nicht Auswerfen eines Hosts aus einem Ressourcenpool, wenn er wichtige Daten enthält, die auf seinen lokalen Festplatten 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 mithilfe von XenCenter in den freigegebenen Speicher im Pool xe vm-copy CLI-Befehl.

Wenn Citrix Hypervisor-Server, 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 Citrix Hypervisor-Server sichtbar. Die VMs werden erst gestartet, wenn die ihnen zugeordneten virtuellen Datenträger so geändert wurden, dass sie auf freigegebenen Speicher verweisen, der von anderen Citrix Hypervisor-Servern im Pool angezeigt wird, oder entfernt wurden. Daher wird empfohlen, dass Sie den lokalen Speicher in den freigegebenen Speicher verschieben, wenn Sie einem Pool beitreten. Durch den Wechsel zu freigegebenem Speicher können einzelne Citrix Hypervisor-Server ohne Datenverlust ausgeworfen werden (oder physisch ausfallen).

Hinweis:

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

Vorbereiten eines Pools von Citrix Hypervisor-Servern für die Wartung

Bevor Sie Wartungsvorgänge auf einem Host durchführen, der Teil eines Ressourcenpools ist, müssen Sie ihn deaktivieren. Durch das Deaktivieren des Hosts wird verhindert, dass VMs auf dem Host gestartet werden. Sie müssen dann die VMs zu einem 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 Backup-Synchronisierung erfolgt alle 24 Stunden. Wenn Sie den Masterhost in den Wartungsmodus versetzen, gehen die RRD-Updates der letzten 24 Stunden für Offline-VMs verloren.

Warnung:

Es wird dringend empfohlen, alle Citrix Hypervisor-Server neu zu starten, bevor Sie ein Update installieren und dann deren Konfiguration überprüfen. Einige Konfigurationsänderungen werden nur wirksam, wenn der Citrix Hypervisor-Server neu gestartet wird, sodass beim Neustart möglicherweise Konfigurationsprobleme aufgedeckt werden, die dazu führen können, dass das Update fehlschlägt.

So bereiten Sie einen Host in einem Pool für Wartungsvorgänge mithilfe der CLI 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 ausgeführten VMs zu anderen Citrix Hypervisor-Servern 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 angehaltenen VMs fort.

Exportieren von Ressourcenpooldaten

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

Hinweis:

Das Exportieren von Ressourcenpooldaten 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 der verschiedenen Arten von Ressourcendaten, die im Bericht enthalten sind:

Server:

• Name
• Poolmeister
• UUID
• Adresse
• CPU-Nutzung
• Netzwerk (durchschnittliche/max. KBs)
• Verwendeter Speicher
• Speicher
• Betriebszeit
• Beschreibung

Netzwerke:

• Name
• Status der Verknüpfung
• MAC
• MTU
• VLAN
• Typ
• Standort

VDI:

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

Speicher:

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

Vms:

• Name
• Energiezustand
• Läuft auf
• Adresse
• MAC
• Netzwerkkarte
• Betriebssystem
• Speicher
• Verwendeter Speicher
• CPU-Nutzung
• UUID
• Betriebszeit
• Vorlage
• Beschreibung

Grafikprozessor:

• Name
• Server
• PCI-Buspfad
• UUID
• Stromverbrauch
• Temperatur
• Verwendeter Speicher
• Computer-Auslastung

Hinweis:

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

So exportieren Sie Ressourcendaten

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

2. Wählen Sie die Schaltfläche Tümpel Menü und dann Exportieren von Ressourcendaten.

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

Einschalten des Hosts

Einschalten von Hosts aus der Ferne

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

Um die Stromversorgung des Hosts zu aktivieren, muss der Host über eine der folgenden Energiesteuerungslösungen verfügen:

• Wake-on-LAN-fähige Netzwerkkarte.

• Dell Remote Access Cards (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 ist die Installation des Befehlszeilenprogramms RACADM auf dem Server mit dem Remote Access Controller und die Aktivierung von DRAC und seiner Schnittstelle erforderlich. RACADM ist häufig in der DRAC-Verwaltungssoftware enthalten. Weitere Informationen finden Sie in der DRAC-Dokumentation von Dell.

• Ein benutzerdefiniertes Skript, das auf der Verwaltungs-API basiert und es Ihnen ermöglicht, das Gerät über Citrix Hypervisor ein- und auszuschalten. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Skripts für die Funktion zum Einschalten des Hosts im folgenden Abschnitt.

Für die Verwendung der Funktion zum Einschalten des Hosts sind zwei Aufgaben erforderlich:

1. Stellen Sie sicher, dass die Hosts im Pool die Fernsteuerung der Stromversorgung unterstützen. Sie verfügen beispielsweise über die 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 der CLI zum Verwalten des Einschaltens des Hosts

Sie können die Host-Einschaltfunktion entweder über die CLI oder XenCenter verwalten. Dieser Abschnitt enthält Informationen zur Verwaltung mit der CLI.

Das Einschalten des Hosts ist auf Hostebene aktiviert (d. h. auf jedem Citrix Hypervisor).

Nachdem Sie das Einschalten des Hosts aktiviert haben, können Sie Hosts entweder über die CLI oder XenCenter aktivieren.

So aktivieren Sie das Einschalten des Hosts mithilfe der 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 sind die Schlüssel power_on_ip , um das Kennwort anzugeben, wenn Sie die Funktion “Geheim” verwenden. Weitere Informationen finden Sie unter Geheimnisse.

So aktivieren Sie Hosts remote mithilfe der CLI

Führen Sie den Befehl aus:

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

Konfigurieren eines benutzerdefinierten Skripts für die Funktion zum Einschalten des Hosts

Wenn die Remote-Stromversorgungslösung Ihres Servers ein Protokoll verwendet, das standardmäßig nicht 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 Skripts für DRAC- und Wake-on-LAN-Lösungen für die Remote-Stromversorgung erstellen.

Dieser Abschnitt enthält Informationen zum Konfigurieren eines benutzerdefinierten Skripts für das Host-Einschalten mithilfe der Schlüssel-Wert-Paare, die dem Citrix Hypervisor-API-Aufruf zugeordnet 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 fernsteuern 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 “Citrix Hypervisor Management API” dokumentiert, das unter Entwickler-Dokumentation Website.

Warnung:

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

Schlüssel-Wert-Paare

Um das Einschalten des Hosts zu verwenden, konfigurieren Sie die host.power_on_mode und host.power_on_config Tasten. Weitere Informationen zu den Werten finden Sie im folgenden Abschnitt.

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 zum Angeben des Typs der Remote-Stromversorgungslösung (z. B. Dell DRAC).

• Mögliche Werte:

  • Eine leere Zeichenfolge, die die deaktivierte Energiesteuerung darstellt.

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

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

• Art:Schnur

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 Lösung für die Remotestromversorgung konfiguriert haben, müssen Sie auch einen der folgenden Schlüssel angeben:

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

    • “power_on_user”: Der DRAC-Benutzername, der dem Verwaltungsprozessor zugeordnet ist und den Sie möglicherweise von den Werkseinstellungen geändert haben.

    • “power_on_password_secret”: Gibt an, dass die Funktion “Geheimnisse” verwendet wird, um Ihr Kennwort zu sichern.

  • Um die Funktion “Geheimnisse” zum Speichern Ihres Passworts zu verwenden, geben Sie den Schlüssel “power_on_password_secret” an. Weitere Informationen finden Sie unter Geheimnisse.

• Art: Map (Zeichenfolge, Zeichenfolge)

Beispiel-Skript

Das Beispielskript importiert die Citrix Hypervisor-API, definiert sich selbst als benutzerdefiniertes Skript und übergibt dann Parameter, die für den Host spezifisch sind, den Sie remote steuern möchten. Sie müssen die Parameter Sitzung in allen benutzerdefinierten Skripten.

Das Ergebnis wird angezeigt, wenn das Skript 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-Datenverkehr zu verschlüsseln. Jegliche Kommunikation zwischen Citrix Hypervisor und Management-API-Clients (oder Appliances) verwendet das TLS 1.2-Protokoll.

Wichtig:

Änderungen an der kryptografischen Funktionalität des Produkts durch Kunden werden nicht unterstützt.

Citrix Hypervisor verwendet die folgende Cipher Suite:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Darüber hinaus werden die folgenden Cipher Suites aus Gründen der 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 Cipher Suites verwenden den CBC-Modus. Obwohl einige Organisationen den GCM-Modus bevorzugen, unterstützt Windows Server 2012 R2 RSA-Verschlüsselungssammlungen mit dem GCM-Modus nicht. Clients, die unter 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 mit dem 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

KexAlgorithmen:

• Kurve25519-SHA256
• ECDH-SHA2-NISTP256
• ECDH-SHA2-NISTP384
• ECDH-SHA2-NISTP521
• diffie-hellman-gruppe14-sha1

HostKeyAlgorithms:

• ECDSA-SHA2-NISTP256
• ecdsa-sha2-nistp384
• ECDSA-SHA2-NISTP521
• ssh-ed25519
• ssh-rsa

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

1. Öffnen Sie in XenCenter die Serverkonsole und melden Sie sich an als wurzel.
2. Art XS-Konsole.

3. In XS-KonsoleGehe zu Konfiguration des Remote-Dienstes > Aktivieren/Deaktivieren der Remote-Shell.

   In der Konsole wird angezeigt, ob die Remote-Shell aktiviert ist.

4. Um zu ändern, ob die Remote-Shell aktiviert oder deaktiviert ist, drücken Sie Eintreten.

Wichtig:

Änderungen an der kryptografischen Funktionalität des Produkts durch Kunden werden nicht unterstützt.

Installieren eines TLS-Zertifikats auf Ihrem Server

Der Citrix Hypervisor-Server wird mit einem standardmäßigen TLS-Zertifikat installiert. Um jedoch HTTPS zum Sichern der Kommunikation zwischen Citrix Hypervisor und Citrix Virtual Apps and Desktops zu verwenden, installieren Sie ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle bereitgestellt wird.

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

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

• Bei dem Zertifikats- und Schlüsselpaar handelt es sich um einen RSA-Schlüssel.
• Der Schlüssel stimmt mit dem Zertifikat überein.
• Der Schlüssel wird in einer separaten Datei zum Zertifikat bereitgestellt.
• Das Zertifikat wird in einer separaten Datei für alle Zwischenzertifikate bereitgestellt.
• Die Schlüsseldatei muss einen der folgenden Typen aufweisen: .Pem oder .Schlüssel.
• Alle Zertifikatsdateien müssen einen der folgenden Typen aufweisen: .Pem, .ceroder .Kathodenstrahlröhre.
• 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 verfügt nicht über einen Hauptschlüssel.
• Der Schlüssel und das Zertifikat liegen im Base-64-codierten PEM-Format vor.
• Das Zertifikat ist gültig und nicht abgelaufen.
• Der Signaturalgorithmus ist SHA-2 (SHA256).

Die xe CLI warnt Sie, wenn das von Ihnen gewählte Zertifikat und der Schlüssel diese Anforderungen nicht erfüllen.

Wo bekomme ich ein TLS-Zertifikat?

• Möglicherweise verfügen Sie bereits über 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 einer Zertifikatsignieranforderung
  2. Senden der Zertifikatsignieranforderung an eine Zertifizierungsstelle
  3. Installieren Sie das signierte Zertifikat auf Ihrem Citrix Hypervisor-Server

1. Generieren einer Zertifikatsignieranforderung

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

1. Führen Sie den folgenden Befehl aus, um eine Datei mit privatem Schlüssel zu erstellen:

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

2. Entfernen Sie das Kennwort aus dem Schlüssel:

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

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

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

4. Befolgen Sie die Anweisungen, um die Informationen anzugeben, die zum Generieren der Zertifikatsignieranforderung erforderlich sind.

   • Ländername. Geben Sie die Ländercodes des TLS-Zertifikats für Ihr Land ein. 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 Bundeslandes oder der Provinz (vollständiger Name). Geben Sie den Bundesstaat oder die Provinz ein, in dem sich der Pool befindet. Beispiel: Massachusetts oder Alberta.
   • Name des Ortes. Der Name der Stadt, in der sich das Schwimmbad 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.
   • Trivialname. 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 Zertifikatsignieranforderung wird im aktuellen Verzeichnis gespeichert und erhält den Namen csr.

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

     cat csr
   <!--NeedCopy-->
   

6. Kopieren Sie die gesamte Zertifikatsignieranforderung, 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 der Zertifikatsignieranforderung an eine Zertifizierungsstelle

Nachdem Sie die Zertifikatsignieranforderung generiert haben, können Sie die Anforderung 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. Es wird empfohlen, keine Zertifizierungsstelle mit dieser Anforderung zu verwenden.

Die Zertifizierungsstelle antwortet auf Ihre Signaturanforderung und stellt die folgenden Dateien bereit:

• das signierte Zertifikat
• ggf. ein Zwischenzertifikat

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

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

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

1. Rufen Sie das signierte Zertifikat und, falls die Zertifizierungsstelle über eines verfügt, das Zwischenzertifikat von der Zertifizierungsstelle ab.
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>
   

   Das Zertifikatskette ist optional.

Für zusätzliche Sicherheit können Sie die Datei mit dem privaten Schlüssel nach der Installation des Zertifikats löschen.

Verwalten des Administratorkennworts

Wenn Sie zum ersten Mal einen Citrix Hypervisor-Server installieren, legen Sie einen Administrator oder wurzel Passwort. Sie verwenden dieses Kennwort, um XenCenter mit Ihrem Server zu verbinden oder (mit dem Benutzernamen wurzel), um sich anzumelden XS-Konsole, die Systemkonfigurationskonsole.

Wenn Sie einen Server mit einem Pool verbinden, wird das Administratorkennwort für den Server automatisch so geändert, dass es mit dem Administratorkennwort des Poolmasters übereinstimmt.

Hinweis:

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

Ändern des Kennworts

Sie können XenCenter, die xe CLI oder XS-Konsole , 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 mithilfe von XenCenter zu ändern:

1. Im Betriebsmittel den Pool oder einen beliebigen Server im Pool aus.
2. Am Tümpel oder auf der Registerkarte Server und wählen Sie Serverkennwort ändern.

Um das Root-Kennwort eines eigenständigen Servers zu ändern, wählen Sie den Server im Feld Betriebsmittel und klicken Sie auf Passwort Und dann Veränderung vom Server Menü.

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

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie den geheimen Poolschlüssel. Weitere Informationen finden Sie unter Drehen des Poolgeheimnisses.

xe CLI

Um das Administratorkennwort mithilfe der 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 den geheimen Poolschlüssel. Weitere Informationen finden Sie unter Drehen des Poolgeheimnisses.

XS-Konsole

So ändern Sie das Administratorkennwort für einen Pool oder einen eigenständigen Server mithilfe von XS-Konsoledie folgenden Schritte aus:

1. Wechseln Sie auf dem Poolmaster zur Konsole.
2. Melden Sie sich an als wurzel.
3. Art XS-Konsole. Presse Eintreten. Das XS-Konsole wird angezeigt.
4. In XS-Konsole, navigieren Sie mit den Pfeiltasten zum Authentifizierung Option. Presse Eintreten.
5. Navigieren Sie zu Passwort ändern. Presse Eintreten.
6. Authentifizieren Sie sich mit dem Administratorkennwort.
7. Im Passwort ändern Dialogfeld:
   1. Geben Sie Ihr aktuelles Passwort ein.
   2. Geben Sie ein neues Passwort ein.
   3. Geben Sie das neue Passwort erneut ein, um es zu bestätigen.

   Das Passwortänderung erfolgreich wird angezeigt. Presse Eintreten zu entlassen.

Wenn es sich bei dem Server um einen Poolmaster handelt, wird dieses aktualisierte Kennwort jetzt an die anderen Server im Pool weitergegeben.

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie den geheimen Poolschlüssel. Weitere Informationen finden Sie unter Drehen des Poolgeheimnisses.

Setzen Sie ein verlorenes Root-Passwort zurück

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 Boot-Menüeintrag zu bearbeiten.

3. Hinzufügen init=/sysroot/bin/sh zu der Zeile, die mit Modul2.

4. Presse 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 es sich bei dem Server um einen Poolmaster handelt, wird dieses aktualisierte Kennwort jetzt an die anderen Server im Pool weitergegeben.

Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie den geheimen Poolschlüssel.

Drehen des Poolgeheimnisses

Der geheime Poolschlüssel ist ein geheimer Schlüssel, der von den Servern in einem Pool gemeinsam genutzt wird und es dem Server ermöglicht, seine Mitgliedschaft in einem Pool nachzuweisen.

Da Benutzer mit der Rolle “Pooladministrator” diesen geheimen Schlüssel ermitteln können, empfiehlt es sich, den geheimen Poolschlüssel zu rotieren, wenn einer dieser Benutzer Ihre Organisation verlässt oder seine Rolle als Pooladministrator verliert.

Sie können das Poolgeheimnis mithilfe von XenCenter oder der xe CLI rotieren.

XenCenter

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

1. Im Betriebsmittel den Pool oder einen beliebigen Server im Pool aus.
2. Am Tümpel und wählen Sie Pool-Geheimnis rotieren.

Wenn Sie den geheimen Poolschlüssel rotieren, werden Sie auch aufgefordert, das Root-Kennwort zu ändern. Wenn Sie den geheimen Poolschlüssel rotiert haben, weil Sie der Meinung sind, 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 den geheimen Poolschlüssel mithilfe der xe CLI zu rotieren, führen Sie den folgenden Befehl auf einem Server im Pool aus:

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

Wenn Sie den geheimen Poolschlüssel rotiert haben, weil Sie der Meinung sind, 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 einer unnötigen Belastung der Hostgeräte führt, da sie Pakete verarbeiten müssen, die sie nicht angefordert haben. Das Aktivieren 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:

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

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

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

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

Sie können IGMP-Snooping in einem Pool aktivieren, indem Sie XenCenter oder die xe CLI verwenden.

XenCenter

1. Navigieren Sie zu Pool-Immobilien.
2. Auswählen Netzwerk-Optionen. Hier können Sie IGMP-Snooping aktivieren oder deaktivieren.

xe CLI

1. Holen Sie sich die Pool-UUID:

   xe pool-list

2. Aktivieren/Deaktivieren von 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 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-liste. Diese Brückennamen können sein xenbr0, xenbr1, Xenapioder xapi0.

Daraus ergibt sich eine Tabelle mit vier Spalten:

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

Wenn die Option GRUPPE handelt es sich um eine Multicast-Gruppenadresse, d. h. es wurde eine IGMP-Berichtsnachricht auf dem zugehörigen Switch-Port empfangen. Dies bedeutet, dass ein Empfänger (Mitglied) der Multicastgruppe an diesem Port lauscht.

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

Der erste Datensatz zeigt, dass ein Empfänger an Port 14 die Multicastgruppe 227.0.0.1 überwacht. Der Open vSwitch leitet den Datenverkehr, der für die Multicastgruppe 227.0.0.1 bestimmt ist, nur an die Überwachungsports für diese Gruppe (in diesem Beispiel an Port 14) weiter, anstatt an alle Ports zu senden. Der Datensatz, der Port 14 und die Gruppe 227.0.0.1 verbindet, wurde vor 15 Sekunden erstellt. Standardmäßig beträgt das Timeout-Intervall 300 Sekunden. Das bedeutet, dass der Datensatz abläuft und aus der Tabelle entfernt wird, wenn der Switch 300 Sekunden lang keine weiteren IGMP-Report-Nachrichten an Port 14 erhält.

Im zweiten Datensatz wird die GRUPPE ist Querier, was bedeutet, dass IGMP-Abfragenachrichten auf dem zugeordneten Port empfangen wurden. Ein Abfrager sendet regelmäßig IGMP-Abfragenachrichten, die an alle Switch-Ports gesendet werden, um zu bestimmen, welche Netzwerkknoten eine Multicast-Gruppe überwachen. Nach dem Empfang einer IGMP-Abfragenachricht antwortet der Empfänger mit einer IGMP-Berichtsnachricht, die bewirkt, dass der Multicast-Datensatz des Empfängers aktualisiert wird und kein Ablauf erfolgt.

Das VLAN zeigt dem VLAN an, dass sich ein Empfänger/Abfrager befindet. “0” bedeutet natives VLAN. Wenn Sie Multicast in einem getaggten VLAN ausführen möchten, stellen Sie sicher, dass im VLAN Datensätze vorhanden sind.

Hinweis:

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