Citrix Hypervisor

Hosts und Ressourcenpools

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

Citrix Hypervisor-Server und Ressourcenpools — Überblick

Ein Ressourcenpool besteht aus mehreren Citrix Hypervisor-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-Server, der über ausreichend Arbeitsspeicher verfügt. Die VMs können dann dynamisch zwischen Citrix Hypervisor-Servern verschoben werden, während sie mit minimalen Ausfallzeiten ausgeführt werden (Livemigration). Wenn bei einem einzelnen Citrix Hypervisor-Server ein Hardwarefehler auftritt, kann der Administrator ausgefallene VMs auf einem anderen Citrix Hypervisor-Server im gleichen 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 hat immer mindestens einen physischen Knoten, der als Masterbezeichnet wird. Nur der Masterknoten stellt eine Administrationsoberfläche zur Verfügung (die von XenCenter und der Citrix Hypervisor Befehlszeilenschnittstelle verwendet wird, die als xe CLI bezeichnet wird). 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-Servern mit bis zu einem Maximum von 64. Die Definition von homogen lautet:

  • CPUs auf dem Server, der dem Pool beitritt, sind identisch (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 Patchebene ausgeführt, die bereits im Pool vorhanden ist.

Die Software erzwingt zusätzliche Einschränkungen, wenn ein Server mit einem Pool verbunden 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 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. eine heruntergefahrende 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, entweder auf dem Server selbst konfiguriert oder mithilfe einer entsprechenden Konfiguration auf dem DHCP-Server.

Citrix Hypervisor-Server in Ressourcenpools können unterschiedliche Anzahl physischer Netzwerkschnittstellen enthalten und lokale Speicherrepositorys unterschiedlicher Größe aufweisen. In der Praxis ist es oft schwierig, mehrere Server mit den exakt gleichen CPUs zu erhalten, weshalb kleinere Abweichungen zulässig sind. Wenn es akzeptabel ist, Hosts mit unterschiedlichen CPUs als Teil desselben Pools zu haben, können Sie den Poolverbindungsvorgang erzwingen, indem Sie Parameter --force ü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 freigegebene Speicherrepositorys 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 eines freigegebenen Speichers in den freigegebenen Speicher zu verschieben. Sie können den Befehl xe vm-copy verwenden oder XenCenter verwenden, um VMs zu verschieben.

Erstellen eines Ressourcenpools

Ressourcenpools können mit XenCenter oder der Befehlszeilenschnittstelle 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:

  • VM-, lokale und Remotespeicherkonfiguration wird der Pool-weiten 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 beitritt.

  • Der beitretende Host erbt vorhandene freigegebene Speicher-Repositories 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 geerbt: Die strukturellen Details von Netzwerkkarten, VLANs und gebundenen Schnittstellen werden alle vererbt, jedoch nicht die Richtlinieninformationen. Diese Richtlinieninformationen, die neu konfiguriert werden müssen, umfassen:

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

    • Der Speicherort der Verwaltungsschnittstelle, der mit der ursprünglichen Konfiguration identisch bleibt. Wenn die anderen Pool-Hosts beispielsweise Verwaltungsschnittstellen auf einer gebundenen Schnittstelle haben, muss der beigetretene 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 werden neu zusammengefügt, um den Datenverkehr entsprechend weiterzuleiten. Dies liegt daran, dass IP-Adressen nicht als Teil 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 Befehlszeilenschnittstelle finden Sie unter Verwalten von Netzwerken.

Hinweis:

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

So verbinden Sie die Citrix Hypervisor-Server host1 und host2 mit der Befehlszeilenschnittstelle mit einem Ressourcenpool

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

  2. Führen Sie den Befehl Citrix Hypervisor-Server host2 aus, um dem Pool auf dem Citrix Hypervisor-Serverhost1 beizutreten, indem Sie den folgenden Befehl ausführen:

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

    Der master-address muss auf den vollqualifizierten Domänennamen des Citrix Hypervisor-Serverhost1festgelegt sein. Das password muss das Administratorkennwort sein, das bei der Installation des Citrix Hypervisor-Servers host1 festgelegt wurde.

Citrix Hypervisor-Server gehören standardmäßig zu einem unbenannten Pool. Um den 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

Erstellen heterogener Ressourcenpools

Citrix Hypervisor vereinfacht die Erweiterung der Bereitstellungen im Laufe der Zeit, da unterschiedliche Hosthardware in einen Ressourcenpool eingebunden 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 CPUs “Masking” oder “Leveling” bereitstellen. Die CPU-Maskierungs- und Nivellierungsfunktionen ermöglichen es, eine CPU so zu konfigurieren, dass sie eine andere Marke, ein Modell oder eine andere Funktionalität als tatsächlich bereitstellt. Mit dieser Funktion können Sie Host-Pools mit unterschiedlichen CPUs erstellen, aber dennoch sicher die Livemigration unterstützen.

Hinweis:

Die CPUs von Citrix Hypervisor-Servern, die heterogene Pools verbinden, müssen vom gleichen Hersteller sein (d. h. AMD, Intel) 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 jetzt zu vorhandenen Ressourcenpools hinzugefügt werden, unabhängig vom zugrunde liegenden CPU-Typ (solange die CPU aus derselben Anbieterfamilie 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 ausgeführte VM verwendet weiterhin den Featuresatz, der beim Start angewendet wurde. Dieser Funktionsumfang wird beim Booten behoben und bleibt bei Migrations-, Suspend- und Fortsetzungsvorgängen bestehen. Wenn die Poolebene abfällt, wenn ein weniger fä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 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. Auf diese Weise kann die VM unabhängig von den CPU-Funktionen, die die VM verwendet, innerhalb und über Pools hinweg frei verschoben werden. Wenn Sie den Workload Balancing verwenden, um einen optimalen Zielhost für die Migration Ihrer VM auszuwählen, wird ein Host mit inkompatiblen Feature-Sets nicht als Zielhost empfohlen.

Freigegebener Speicher hinzufügen

Eine vollständige Liste der unterstützten freigegebenen Speichertypen finden Sie unter Speicher-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 einen freigegebenen NFS-Speicher mit der Befehlszeilenschnittstelle zu einem Ressourcenpool hinzu

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

  2. Erstellen Sie das Speicher-Repository auf dem 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 Der Hostname des NFS-Servers und device-config:serverpath der Pfad auf dem NFS-Server. Wie shared auf “true” gesetzt, 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 Speicher-Repositorys 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 poolweite Standardwert mit dem Befehl

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

    Da der freigegebene Speicher als poolweite Standardeinstellung festgelegt wurde, haben alle zukünftigen VMs standardmäßig ihre Datenträger auf freigegebenem Speicher erstellt. Weitere Informationen zum Erstellen anderer Arten von freigegebenem Speicher finden Sie unter Speicher-Repository-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, 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 belassen, der einer Neuinstallation ähnlich ist. Auswerfen von Citrix Hypervisor-Servern nicht aus einem Pool, wenn wichtige Daten auf den lokalen Datenträgern vorhanden sind.

So entfernen Sie einen Host aus einem Ressourcenpool mit der Befehlszeilenschnittstelle

  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. Werfen Sie den erforderlichen Host aus dem Pool aus:

    xe pool-eject host-uuid=host_uuid
    

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

    Warnung:

    Werfen Sie einen Host nicht aus einem Ressourcenpool aus, 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 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 Laufwerke so geändert wurden, dass sie auf gemeinsam genutzten Speicher verweisen, der von anderen Citrix Hypervisor-Servern im Pool angezeigt wird, oder entfernt wurden. Daher wird empfohlen, jeden lokalen Speicher in freigegebenen Speicher zu verschieben, wenn Sie einem Pool beitreten. Durch das Verschieben auf gemeinsam genutzten Speicher können einzelne Citrix Hypervisor-Server ohne Datenverlust ausgeworfen (oder physisch ausfallen) werden.

Hinweis:

Wenn ein Host aus einem Pool entfernt wird, dessen Verwaltungsschnittstelle in einem gekennzeichneten VLAN-Netzwerk hat, wird der Computer neu gestartet und die Verwaltungsschnittstelle steht im selben Netzwerk zur Verfügung.

Vorbereiten eines Pools von Citrix Hypervisor-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 dem Host gestartet werden. Anschließend müssen Sie 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 Master-Host in den Wartungsmodus versetzen, werden die letzten 24 Stunden RRD-Updates für Offline-VMs verloren.

Warnung:

Es wird dringend empfohlen, alle Citrix Hypervisor-Server neu zu starten, bevor ein Update installiert wird und anschließend deren Konfiguration überprüft wird. 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 mit der Befehlszeilenschnittstelle 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
    

    Mit diesem Befehl wird der Citrix Hypervisor-Server deaktiviert und anschließend alle ausgeführten VMs zu anderen Citrix Hypervisor-Servern im Pool migriert.

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

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

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

Ressourcenpool-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 verfolgen, planen und zuweisen.

Hinweis:Ressourcen-Pool-Daten

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

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

Server:

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

Netzwerke:

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

VDI:

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

Speicher:

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

VMs:

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

GPU:

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

Hinweis:

Informationen zu GPUs sind nur verfügbar, wenn GPUs an den Citrix Hypervisor-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. Wählen Sie das Menü Pool und dann Ressourcendaten exportierenaus.

  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 Einschaltfunktion des Citrix Hypervisor-Servers können Sie einen Server remote ein- und ausschalten, entweder über XenCenter oder über die Befehlszeilenschnittstelle.

Um die Host-Stromversorgung 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. Die DRAC-Unterstützung erfordert die Installation des RACADM-Befehlszeilendienstprogramms 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 iLO-Dokumentation von HP.

  • Ein benutzerdefiniertes Skript, das auf der Management-API basiert, mit dem Sie das Ein- und Ausschalten über Citrix Hypervisor aktivieren können. 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 Stromversorgung ferngesteuert steuern. 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 mit der Befehlszeilenschnittstelle oder XenCenter.

Verwenden der Befehlszeilenschnittstelle zum Verwalten des Hosts

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

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

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

So aktivieren Sie das Einschalten des Hosts mit der Befehlszeilenschnittstelle

Führen Sie folgenden 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 DRAC power_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 remote mit der Befehlszeilenschnittstelle

Führen Sie folgenden Befehl aus:

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

Konfigurieren eines benutzerdefinierten Skripts für die Host-Einschaltfunktion

Wenn die Remote-Energielösung des 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 die Citrix Hypervisor Computer remote einzuschalten. Sie können jedoch auch benutzerdefinierte Skripts für Remote-Stromversorgungslösungen von iLO, DRAC und Wake-on-LAN erstellen.

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

Wenn Sie ein benutzerdefiniertes Skript erstellen, führen Sie es jedes Mal von der Befehlszeile aus, wenn Sie die Stromversorgung remote über Citrix Hypervisor steuern möchten. Alternativ können Sie ihn 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, das Entwicklerdokumentation auf der Website verfügbar ist.

Warnung:

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

Schlüssel/Wert-Paare

Um Host Power On zu verwenden, konfigurieren Sie die host.power_on_mode Schlüssel host.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-Energie-Lösung (z. B. Dell DRAC).

  • Mögliche Werte:

    • Eine leere Zeichenfolge, die Energiesteuerung 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.

    • Ein beliebiger anderer 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 Modus-Konfiguration. Enthält zusätzliche Informationen für iLO und DRAC.

  • Mögliche Werte:

    • Wenn Sie iLO oder DRAC als Typ der Lösung für die Remote-Stromversorgung 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 iLO oder DRAC konfiguriert ist.

      • “power_on_user”: Der iLO- oder DRAC-Benutzername, der dem Verwaltungsprozessor zugeordnet ist, den Sie möglicherweise von den Werkseinstellungen 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 Geheimnisse.

  • Typ: Map (String, String)

Beispiel-Skript

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 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 das TLS 1.2-Protokoll zum Verschlüsseln des Verwaltungs-API-Datenverkehrs. Jede Kommunikation zwischen Citrix Hypervisor und Management-API-Clients (oder Appliances) verwendet das TLS 1.2-Protokoll.

Citrix Hypervisor verwendet die folgenden Verschlüsselungssammlungen:

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256

Installieren eines TLS-Zertifikats auf dem Server

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

In diesem Abschnitt wird beschrieben, wie Zertifikate mit der Xe-Befehlszeilenschnittstelle installiert werden. Weitere Informationen zum Arbeiten mit Zertifikaten mithilfe von XenCenter finden Sie unter 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 entspricht dem Zertifikat
  • Der Schlüssel wird in einer separaten Datei für das Zertifikat bereitgestellt
  • Das Zertifikat wird in einer separaten Datei für alle Zwischenzertifikate bereitgestellt.
  • Die Schlüsseldatei muss einer der folgenden Typen sein: .pem oder .key
  • Alle Zertifikatdateien müssen einer der folgenden Typen sein: .pem, .cer, oder .crt
  • Der Schlüssel ist größer oder gleich 2048 Bits und kleiner oder gleich 4096 Bits Länge
  • Der Schlüssel ist ein unverschlüsselter PKCS #8 Schlüssel und hat keinen Hauptschlüssel
  • Schlüssel und Zertifikat sind im Base-64-codierten “PEM” -Format
  • Das Zertifikat ist gültig und ist noch 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.

Möglicherweise verfügen Sie bereits über ein vertrauenswürdiges Zertifikat, das Sie auf dem Citrix Hypervisor-Server installieren möchten. Sie können jedoch stattdessen ein Zertifikat auf dem Server erstellen und es an eine Zertifizierungsstelle senden, die signiert werden soll. Diese Methode ist sicherer, da der private Schlüssel auf dem Citrix Hypervisor-Server verbleiben und nicht zwischen Systemen kopiert werden kann.

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 private Schlüsseldatei zu erstellen:

    openssl genrsa -des3 -out privatekey.pem 2048
    
  2. Entfernen Sie das Kennwort aus dem Schlüssel:

    openssl rsa -in privatekey.pem -out privatekey.nop.pem
    
  3. Erstellen Sie die Zertifikatsignieranforderung mithilfe des privaten Schlüssels:

    openssl req -new -key privatekey.nop.pem -out csr
    
  4. Befolgen Sie die Anweisungen, um die Informationen anzugeben, die zum Generieren der Zertifikatsignieranforderung erforderlich sind.

    • Name des Landes. 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 des TLS-Zertifikats finden Sie im Web.
    • Bundes- oder Provinzname (vollständiger Name). Geben Sie das Bundesland oder die Provinz ein, in der sich der Pool befindet. Zum Beispiel Massachusetts oder Alberta.
    • Name des Orts. 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 Abteilungsnamen ein. Dieses Feld ist optional.
    • Common Name: Geben Sie den vollqualifizierten Domänennamen des 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 beim Generieren im Zertifikat enthalten.

    Die Zertifikatsignieranforderung wird im aktuellen Verzeichnis gespeichert und trägt den Namen csr.

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

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

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

  1. Laden Sie das signierte Zertifikat, das Stammzertifikat und, falls die Zertifizierungsstelle eines besitzt, das Zwischenzertifikat von der Zertifizierungsstelle herunter.
  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.

Um zusätzliche Sicherheit zu gewährleisten, können Sie die private Schlüsseldatei löschen, nachdem das Zertifikat installiert wurde.

Aktivieren von IGMP-Snooping auf dem Citrix Hypervisor -Pool

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

Sie können IGMP-Snooping in einem Pool entweder über XenCenter oder über die Befehlszeilenschnittstelle aktivieren. Um IGMP-Snooping mit XenCenter zu aktivieren, navigieren Sie zu Pooleigenschaften, und wählen Sie Netzwerkoptionenaus. Weitere Informationen zu xe-Befehlen finden Sie unter pool-igmp-snooping.

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, IGMP-Abfrage auf einem der physischen Switches zu aktivieren. Andernfalls wird Multicast im Unternetzwerk auf Broadcast zurückgesetzt und kann 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 Netzwerkbindung-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 vom physischen Netzwerk an das GRE-Netzwerk weiterleiten. Andernfalls kann der Multicastverkehr im GRE-Netzwerk blockiert werden.