Hosts und Ressourcenpools

In diesem Abschnitt wird beschrieben, wie Ressourcenpools anhand einer Reihe von Beispielen mit der xe-Befehlszeilenschnittstelle erstellt werden können. Eine einfache NFS-basierte Shared Storage-Konfiguration wird vorgestellt und einige einfache VM-Verwaltungsbeispiele werden diskutiert. Es enthält auch Verfahren für den Umgang mit physischen Knotenfehlern.

Übersicht über Citrix Hypervisor or-Server und Ressourcenpools

Ein Ressourcenpool besteht aus mehreren Citrix Hypervisor or-Serverinstallationen, die an eine einzelne verwaltete Entität gebunden sind, die virtuelle Maschinen hosten kann. In Kombination mit gemeinsam genutztem Speicher ermöglicht ein Ressourcenpool das Starten von VMs auf jedem Citrix Hypervisor or-Server, der über ausreichend Arbeitsspeicher verfügt. Die VMs können dann dynamisch zwischen den Citrix Hypervisor or-Servern verschoben werden, während sie mit minimalen Ausfallzeiten ausgeführt werden (Live-Migration). Wenn ein einzelner Citrix Hypervisor or-Server einen Hardwarefehler erleidet, kann der Administrator ausgefallene VMs auf einem anderen Citrix Hypervisor or-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 erzwungen wird.

Ein Pool hat immer mindestens einen physischen Knoten, der als Masterbezeichnet wird. Nur der Master-Knoten stellt eine Verwaltungsschnittstelle bereit (die von XenCenter und der Citrix Hypervisor Befehlszeilenschnittstelle (XE CLI genannt). Der Master leitet Befehle nach Bedarf an einzelne Mitglieder weiter.

Hinweis:

Wenn der Poolmaster fehlschlägt, findet die Master-Wiederwahl nur statt, wenn die hohe Verfü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 or-Servern mit bis zu 64 Jahren. Die Definition von homogen ist:

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

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

Die Software erzwingt zusätzliche Einschränkungen beim Verbinden eines Servers mit einem Pool. Insbesondere überprüft Citrix Hypervisor, 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 freigegebener Speicher konfiguriert.

  • Der Server hostet keine laufenden oder suspendierten VMs.

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

  • 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 erfolgreich dem Pool beitritt.

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

Citrix Hypervisor or-Server in Ressourcenpools können unterschiedliche physische Netzwerkschnittstellen enthalten und lokale Speicher-Repositorys unterschiedlicher Größe aufweisen. In der Praxis ist es oft schwierig, mehrere Server mit genau denselben CPUs zu erhalten, und daher sind kleinere Abweichungen zulässig. Wenn es akzeptabel ist, Hosts mit unterschiedlichen CPUs als Teil desselben Pools zu haben, können Sie den Pool-Joining-Vorgang erzwingen, indem Sie--force Parameter übergeben.

Alle Hosts im Pool müssen sich am selben Standort befinden und über ein Netzwerk mit niedriger 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 gemeinsam genutzte Speicher-Repositories enthalten, um auszuwählen, auf welchem Citrix Hypervisor or-Server eine VM ausgeführt werden soll und eine VM dynamisch zwischen Citrix Hypervisor-Servern verschoben werden soll. Erstellen Sie nach Möglichkeit einen Pool, nachdem der freigegebene Speicher verfügbar ist. Es wird empfohlen, vorhandene VMs mit Datenträgern im lokalen Speicher nach dem Hinzufügen von freigegebenem Speicher in den freigegebenen Speicher zu verschieben. Sie können denxe vm-copy Befehl verwenden oder XenCenter zum Verschieben von VMs verwenden.

Erstellen eines Ressourcenpools

Ressourcenpools können mit XenCenter oder der CLI erstellt werden. Wenn ein neuer Host einem Ressourcenpool beitritt, synchronisiert der beitrittende Host seine lokale Datenbank mit der Pool-weiten Datenbank und erbt einige Einstellungen aus dem Pool:

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

  • Der beitrittsende Host erbt vorhandene freigegebene Speicher-Repositories im Pool. Geeignete PBD-Datensätze werden erstellt, damit der neue Host automatisch auf vorhandenen freigegebenen Speicher zugreifen kann.

  • Netzwerkinformationen werden teilweise an den beitrittenden Host vererbt: Die strukturellen Details von NICs, VLANs und gebundenen Schnittstellen werden alle vererbt, die Richtlinieninformationen jedoch nicht. Diese Richtlinieninformationen, die neu konfiguriert werden müssen, umfassen:

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

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

    • Dedizierte Speicher-NICs, die dem beitrittenden Host über XenCenter oder die CLI neu zugewiesen werden müssen, und die PBDs werden neu angeschlossen, um den Datenverkehr entsprechend weiterzuleiten. Dies liegt daran, dass IP-Adressen nicht als Teil des Pool-Join-Vorgangs zugewiesen werden und die Speicher-Netzwerkkarte nur funktioniert, wenn diese korrekt konfiguriert ist. Weitere InformationenVerwalten von Netzwerkenzum Deditieren einer Speicher-NIC über die CLI finden Sie unter.

Hinweis:

Sie können einen neuen Host nur dann zu einem Ressourcenpool beitreten, wenn sich die Verwaltungsschnittstelle des Hosts auf demselben getaggten VLAN befindet wie das des Ressourcenpools.

So verbinden Sie Citrix Hypervisor or-Server host1 und host2 mithilfe der CLI mit einem Ressourcenpool

  1. Öffnen Sie eine Konsole auf dem Citrix Hypervisor or-Serverhost2.

  2. Befehlen Sie Citrix Hypervisor or-Server host2 , um dem Pool auf dem Citrix Hypervisor or-Server host1 beizutreten, indem Sie den folgenden Befehl ausführen:

    xe pool-join master-address=host1 master-username=administrators_username master-password=password
    

    Dermaster-address muss auf den vollqualifizierten Domänennamen des Citrix Hypervisor-Serverhost1 festgelegt sein. Daspassword muss das Administratorkennwort sein, das bei der Installation des Citrix Hypervisor or-Servers host1 festgelegt wurde.

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

xe pool-param-set name-label="New Pool" uuid=pool_uuid

Erstellen heterogener Ressourcenpools

Citrix Hypervisor vereinfacht die Erweiterung der Bereitstellungen im Laufe der Zeit, da unterschiedliche Hosthardware mit einem Ressourcenpool verbunden werden kann, der als heterogene Ressourcenpools bezeichnet wird. Heterogene Ressourcenpools werden durch die Verwendung von Technologien in Intel (FlexMigration) und AMD (Extended Migration) CPUs ermöglicht, die „Maskierung“ oder „Nivellierung“ der CPU ermöglichen. Die CPU-Maskierungs- und Nivellierfunktionen ermöglichen es, eine CPU so zu konfigurieren , dass sie eine andere Marke, ein Modell oder eine andere Funktionalität bereitstellt, als sie tatsächlich tut. Mit dieser Funktion können Sie Pools von Hosts mit unterschiedlichen CPUs erstellen, die Livemigration jedoch sicher unterstützen.

Hinweis:

Die CPUs von Citrix Hypervisor or-Servern, die heterogene Pools verbinden, müssen vom selben Anbieter (d. h. AMD, Intel) sein wie CPUs auf Hosts im Pool. Der spezifische Typ (Familie, Modell und Schrittnummern) muss jedoch nicht sein.

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

  • Ein neuer Host tritt in den Pool ein

  • Ein Poolmitglied verlässt den Pool

  • Ein Poolmitglied verbindet sich nach einem Neustart erneut

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 Featuresatz, der beim Start angewendet wurde. Dieser Funktionsumfang wird beim Booten behoben und bleibt bei Migrations-, Suspende- und Fortsetzungsvorgängen bestehen. Wenn die Poolebene abfällt, wenn ein weniger fähiger Host 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 Featuresatz der VM mit dem Feature-Set des Zielhosts. Wenn die Feature-Sets als kompatibel erfunden werden, darf die VM migriert werden. Dadurch kann sich die VM frei innerhalb und über 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 inkompatiblen Funktionsumfang nicht als Zielhost empfohlen.

Hinzufügen von freigegebenenSpeicher

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

So fügen Sie einem Ressourcenpool mithilfe der CLI gemeinsam genutzten NFS-Speicher hinzu

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

  2. Erstellen Sie das Speicher-Repository auf Server: /path, indem Sie den Befehl

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

    device-config:server Ist der Hostname des NFS-Servers unddevice-config:serverpath der Pfad auf dem NFS-Server. Wieshared auf true festgelegt, wird gemeinsam genutzter Speicher automatisch mit jedem Citrix Hypervisor or-Server im Pool verbunden. Alle Citrix Hypervisor or-Server, die später beitreten, sind ebenfalls mit dem Speicher verbunden. Die Universally Unique Identifier (UUID) des Speicher-Repositories wird auf dem Bildschirm gedruckt.

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

    xe pool-list
    
  4. Legen Sie den gemeinsam genutzten Speicher als den Pool-weiten Standard mit dem Befehl

    xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
    

    Da der freigegebene Speicher als Pool-weiter Standard festgelegt wurde, haben alle zukünftigen VMs ihre Festplatten standardmäßig auf freigegebenem Speicher erstellt. Weitere InformationenSpeicher-Repository-Formatezum Erstellen anderer freigegebener Speichertypen finden Sie unter.

Entfernen von Citrix Hypervisor -Servern aus einem Ressourcenpool

Hinweis:

Stellen Sie vor dem Entfernen eines Citrix Hypervisor or-Servers aus einem Pool sicher, dass Sie alle auf diesem Host ausgeführten VMs herunterfahren. Andernfalls wird eine Warnung angezeigt, die besagt, 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 wie bei einer Neuinstallation belassen. Auswerfen von Citrix Hypervisor or-Servern nicht aus einem Pool, wenn wichtige Daten auf den lokalen Datenträgern vorhanden sind.

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 Befehl

    xe host-list
    
  3. Den erforderlichen Host aus dem Pool auswerfen:

    xe pool-eject host-uuid=host_uuid
    

    Der Citrix Hypervisor or-Server wird ausgeworfen und in einem neu installierten Zustand belassen.

    Warnhinweis:

    Auswerfen eines Hosts nicht aus einem Ressourcenpool, 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 demxe vm-copy CLI-Befehl in den freigegebenen Speicher im Pool.

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

Hinweis:

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

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

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 auf ihm gestartet werden. Anschließend müssen Sie die VMs auf einen anderen Citrix Hypervisor or-Server im Pool migrieren. Sie können dies tun, indem Sie den Citrix Hypervisor or-Server mit XenCenter in den Wartungsmodus versetzen. Weitere Informationen finden Sie in der XenCenter Hilfe.

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

Warnhinweis:

Wir empfehlen dringend, alle Citrix Hypervisor or-Server neu zu starten, bevor Sie ein Update installieren und anschließend deren Konfiguration überprüfen. Einige Konfigurationsänderungen werden nur wirksam, wenn Citrix Hypervisor neu gestartet wird. Daher kann der Neustart Konfigurationsprobleme aufdecken, 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
    

    Mit diesem Befehl wird der Citrix Hypervisor or-Server deaktiviert und anschließend alle ausgeführten VMs auf andere Citrix Hypervisor-Server im Pool migriert.

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

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

    xe host-enable
    
  4. Starten Sie alle angehaltenen VMs neu und setzen Sie alle angehaltenen VMs fort.

Ressourcen-Pool-Daten exportieren

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 wie Server, Netzwerke, Speicher, virtuelle Maschinen, VDIs und GPUs. Mit dieser Funktion können Administratoren Ressourcen basierend auf verschiedenen Arbeitslasten wie CPU, Speicher und Netzwerk nachverfolgen, planen und zuweisen.

Hinweis:

Exportieren von Ressourcenpooldaten ist für Citrix Hypervisor Premium Edition-Kunden oder für Kunden verfügbar, die über ihre Citrix Virtual Apps und Desktops Zugriff auf Citrix Hypervisor haben.

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

Server:

  • Name
  • Pool Master
  • UID
  • Adresse
  • CPU-Auslastung
  • Netzwerk (Durchschn. /max. KBs)
  • Verwendeter Speicher
  • Speicher
  • Betriebszeit
  • Beschreibung

Netzwerke:

  • Name
  • Link Status
  • MAC
  • MTU
  • VLAN
  • Typ
  • Lage

VDI:

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

Lagerung:

  • Name
  • Typ
  • UID
  • Größe
  • Lage
  • Beschreibung

VMs:

  • Name
  • Energiezustand
  • Laufen auf
  • Adresse
  • MAC
  • NIC
  • Betriebssystem
  • Speicher
  • Verwendeter Speicher
  • CPU-Auslastung
  • UID
  • Betriebszeit
  • Vorlage
  • Beschreibung

GPU:

  • Name
  • Server
  • PCI-Buspfad
  • UID
  • Energieverbrauch
  • Temperatur
  • Verwendeter Speicher
  • Computerauslastung

Hinweis:

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

So exportieren Sie Ressourcendaten

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

  2. Select das Menü Pool und dann Ressourcendaten exportieren aus.

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

Host-Einschalten

Remote-Einschalten von Hosts

Mit der Funktion „Power On“ des Citrix Hypervisor or-Servers können Sie einen Server remote ein- und ausschalten, entweder über XenCenter oder mithilfe der CLI.

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

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

  • Dell Remote Access Cards (DRAC). Um Citrix Hypervisor mit DRAC verwenden zu können, müssen Sie das Dell Zusatzpaket installieren, um DRAC-Unterstützung zu erhalten. DRAC-Unterstützung erfordert die Installation des RACADM-Befehlszeilenprogramms auf dem Server mit dem RAS-Controller und die Aktivierung von DRAC und dessen Schnittstelle. RACADM ist oft in der DRAC-Management-Software enthalten. Weitere Informationen finden Sie in der DRAC-Dokumentation von Dell.

  • Hewlett-Packard Integrated Lights-Out (iLO). Um Citrix Hypervisor mit iLO zu verwenden, müssen Sie iLO auf dem Host aktivieren und die Schnittstelle mit dem Netzwerk verbinden. Weitere Informationen finden Sie in der HP iLO-Dokumentation.

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

Für die Verwendung der Host-Einschaltfunktion 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, eine DRAC- oder iLO-Karte oder Sie haben ein benutzerdefiniertes Skript erstellt).

  2. Aktivieren Sie die Host-Einschaltfunktion mithilfe der CLI oder XenCenter.

Verwenden der CLI zum Verwalten der Stromversorgung des Hosts

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

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

Nachdem Sie Host Power On aktiviert haben, können Sie Hosts entweder mit der 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",  "iLO", "DRAC","custom") \
    power-on-config=key:value

Für iLO und DRACpower_on_ip müssen die Schlüssel das Kennwort angeben, wenn Sie die geheime Funktion verwenden. Weitere Informationen finden Sie unter Geheimnisse.

So aktivieren Sie Hosts mithilfe der CLI remote

Führen Sie den Befehl aus:

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

Konfigurieren eines benutzerdefinierten Skripts für die Host-Einschaltfunktion

Wenn die Remote-Power-Lösung Ihres Servers ein Protokoll verwendet, das standardmäßig nicht unterstützt wird (z. B. Wake-On-Ring- oder Intel Active Management-Technologie), können Sie ein benutzerdefiniertes Linux Python-Skript erstellen, um Ihre Citrix Hypervisor Computer remote einschalten zu können. Sie können jedoch auch benutzerdefinierte Skripte für iLO, DRAC und Wake-on-LAN-Fernversorgungslö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 sindhost.power_on.

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

Die Citrix Hypervisor API ist in dem Dokument, der Citrix Hypervisor Verwaltungs-API, dokumentiert, dasEntwicklerdokumentationauf der Website verfügbar ist.

Warnhinweis:

Ändern Sie die standardmäßig im/etc/xapi.d/plugins/ Verzeichnis bereitgestellten Skripte nicht. 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 diehost.power_on_mode Schlüsselhost.power_on_config und. 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)
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 Power-Control deaktiviert

    • „iLO“: Ermöglicht die Angabe von HP iLO.

    • „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 (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. Enthält zusätzliche Informationen für iLO und DRAC.

  • Mögliche Werte:

    • Wenn Sie iLO oder DRAC als Remotestromlö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 angegeben haben. Alternativ können Sie den Domänennamen für die Netzwerkschnittstelle eingeben, auf der iLO oder DRAC konfiguriert ist.

      • „power_on_user“: Der dem Verwaltungsprozessor zugeordnete iLO oder DRAC Benutzername, den Sie möglicherweise von den Werkseinstellungen geändert haben.

      • „power_on_password_secret“: Gibt die Verwendung der Secrets-Funktion zum Sichern Ihres Passworts an.

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

  • Typ: Map (string, string)

Beispielskript

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 Parametersession in allen benutzerdefinierten Skripten definieren.

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

Hinweis:

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

Kommunikation mit Citrix Hypervisor -Servern und Ressourcenpools

Citrix Hypervisor verwendet TLS-Protokolle zum Verschlüsseln des Management-API-Datenverkehrs. Jede Kommunikation zwischen Citrix Hypervisor und Verwaltungs-API-Clients (oder -Appliances) verwendet jetzt standardmäßig das TLS 1.2-Protokoll. Wenn der Verwaltungs-API-Client oder die Appliance jedoch nicht mit TLS 1.2 kommuniziert, können frühere Protokolle für die Kommunikation verwendet werden.

Citrix Hypervisor verwendet die folgenden Verschlüsselungssammlungen:

-TLS_RSA_WITH_AES_128_CBC_SHA256

-TLS_RSA_WITH_AES_256_CBC_SHA

-TLS_RSA_WITH_AES_128_CBC_SHA

-TLS_RSA_WITH_RC4_128_SHA

-TLS_RSA_WITH_RC4_128_MD5

-TLS_RSA_WITH_3DES_EDE_CBC_SHA

Mit Citrix Hypervisor können Sie auch Ihren Host oder Ressourcenpool so konfigurieren, dass die Kommunikation nur über TLS 1.2möglich ist. Diese Option ermöglicht die Kommunikation zwischen Citrix Hypervisor und Verwaltungs-API-Clients (oder -Appliances) mithilfe des TLS 1.2-Protokolls. Die Option nur TLS 1.2 verwendet Chiffre SuiteTLS_RSA_WITH_AES_128_CBC_SHA256.

Warnung:

Select die Option Nur TLS 1.2aus, nachdem Sie sichergestellt haben, dass alle Verwaltungs-API-Clients und -Appliances, die mit dem Citrix Hypervisor Pool kommunizieren, mit TLS 1.2 kompatibel sind.

Aktivieren von IGMP-Snooping auf Ihrem Citrix Hypervisor Pool

Citrix Hypervisor sendet Multicastdatenverkehr an alle Gast-VMs, was zu unnötiger Last auf Hostgeräten führt, indem sie von ihnen verlangt werden, Pakete zu verarbeiten, die sie nicht angefordert haben. Das Aktivieren von IGMP-Snooping verhindert, dass Hosts in einem lokalen Netzwerk Datenverkehr für eine Multicastgruppe empfangen, die sie nicht explizit beigetreten sind, und verbessert die Leistung von Multicast. IGMP-Snooping ist besonders nützlich für bandbreitenintensive IP-Multicastanwendungen wie IPTV.

Sie können IGMP-Snooping in einem Pool mithilfe von XenCenter oder der Befehlszeilenschnittstelle aktivieren. Um IGMP-Snooping mit XenCenter zu aktivieren, navigieren Sie zu Pooleigenschaften und wählen Sie Netzwerkoptionen aus. Weitere Informationen finden Sie in der XenCenter Hilfe. Hinweise zu xe-Befehlen finden Sie unterpool-igmp-schnüffeln.

Hinweise:

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

  • Wenn Sie diese Funktion in einem Pool aktivieren, ist es möglicherweise auch notwendig, IGMP-Querier auf einem der physischen Switches zu aktivieren. Andernfalls wird Multicast im Unternetzwerk auf Broadcast zurückgreifen und die Leistung von Citrix Hypervisor verringern.

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

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