layout: doc description: Create resource pools to group your XenServer hosts and shared storage into a single managed entity.—
In diesem Abschnitt wird beschrieben, wie Ressourcenpools anhand einer Reihe von Beispielen mithilfe der xe-Befehlszeilenschnittstelle (CLI) erstellt werden können. Eine einfache NFS-basierte Konfiguration für gemeinsam genutzten Speicher wird vorgestellt, und es werden mehrere einfache Beispiele für die VM-Verwaltung erörtert. Es enthält auch Verfahren zum Umgang mit Ausfällen physischer Knoten.
Ein Ressourcenpool besteht aus mehreren XenServer-Hostinstallationen, die zu einer einzigen verwalteten Einheit zusammengefasst sind, die virtuelle Maschinen hosten kann. In Kombination mit gemeinsam genutztem Speicher ermöglicht ein Ressourcenpool den Start von VMs auf jedem XenServer-Host, der über ausreichend Arbeitsspeicher verfügt. Die VMs können dann dynamisch zwischen XenServer-Hosts verschoben werden, während sie mit minimalen Ausfallzeiten ausgeführt werden (Live-Migration). Wenn ein einzelner XenServer-Host einen Hardwarefehler erleidet, kann der Administrator ausgefallene VMs auf einem anderen XenServer-Host im selben Ressourcenpool neu starten. Wenn Hochverfügbarkeit im Ressourcenpool aktiviert ist, wechseln VMs automatisch zu einem anderen Host, wenn ihr Host ausfällt. Pro Ressourcenpool werden bis zu 64 Hosts unterstützt, obwohl diese Einschränkung nicht durchgesetzt wird.
Ein Pool hat immer mindestens einen physischen Knoten, den sogenannten Poolkoordinator (früher “Pool-Master”). Der Koordinatorknoten stellt eine Verwaltungsschnittstelle zur Verfügung (die von XenCenter und der XenServer-Befehlszeilenschnittstelle verwendet wird, die als Xe-CLI bezeichnet wird). Der Koordinator leitet bei Bedarf Befehle an einzelne Mitglieder weiter.
Hinweis:
Wenn der Poolkoordinator ausfällt, findet die Wiederwahl des Koordinators nur statt, wenn Hochverfügbarkeit aktiviert ist.
Ein Ressourcenpool ist ein homogenes (oder heterogenes mit Einschränkungen) Aggregat aus einem oder mehreren XenServer-Hosts, bis zu einem Maximum von 64. Die Definition von “homogen” lautet:
Die CPUs auf dem Host, der dem Pool beitritt, sind dieselben (in Bezug auf den Anbieter, das Modell und die Funktionen) wie die CPUs auf Hosts, die sich bereits im Pool befinden.
Auf dem Host, der dem Pool beitritt, wird dieselbe Version der XenServer-Software auf derselben Patch-Ebene ausgeführt wie auf den Hosts, die sich bereits im Pool befinden.
Die Software erzwingt zusätzliche Einschränkungen, wenn ein Host zu einem Pool hinzugefügt wird. Insbesondere überprüft XenServer, ob die folgenden Bedingungen für den Host zutreffen, der dem Pool beitritt:
Der Host ist kein Mitglied eines vorhandenen Ressourcenpools.
Für den Host ist kein gemeinsam genutzter Speicher konfiguriert.
Der Host hostet keine laufenden oder angehaltenen VMs.
Auf den VMs auf dem Host werden keine aktiven Vorgänge ausgeführt, z. B. das Herunterfahren einer VM.
Die Uhr auf dem Host wird mit derselben Uhrzeit wie der Poolkoordinator synchronisiert (z. B. mithilfe von NTP).
Die Verwaltungsschnittstelle des Hosts ist nicht gebunden. Sie können die Verwaltungsschnittstelle konfigurieren, wenn der Host dem Pool erfolgreich beitritt.
Die Management-IP-Adresse ist statisch und wird entweder auf dem Host selbst oder mithilfe einer entsprechenden Konfiguration auf Ihrem DHCP-Server konfiguriert.
XenServer-Hosts in Ressourcenpools können eine unterschiedliche Anzahl von physischen Netzwerkschnittstellen enthalten und über lokale Speicherrepositorys unterschiedlicher Größe verfügen. In der Praxis ist es oft schwierig, mehrere Hosts mit exakt denselben CPUs zu erhalten, weshalb geringfügige Abweichungen zulässig sind. Wenn es akzeptabel ist, Hosts mit unterschiedlichen CPUs als Teil desselben Pools zu haben, können Sie den Pool-Beitritt erzwingen, indem Sie den Parameter --force übergeben.
Alle Hosts im Pool müssen sich am selben Standort befinden und über ein Netzwerk mit geringer Latenz verbunden sein.
Hinweis:
Server, die gemeinsam genutzten NFS- oder iSCSI-Speicher für den Pool bereitstellen, müssen über eine statische IP-Adresse verfügen.
Ein Pool muss gemeinsam genutzte Speicher-Repositorys enthalten, um auszuwählen, auf welchem XenServer-Host eine VM ausgeführt werden soll, und um eine VM dynamisch zwischen XenServer-Hosts zu verschieben. Wenn möglich, erstellen Sie einen Pool, nachdem gemeinsam genutzter Speicher verfügbar ist. Es wird empfohlen, vorhandene VMs mit Datenträgern im lokalen Speicher in den freigegebenen Speicher zu verschieben, nachdem Sie gemeinsam genutzten Speicher hinzugefügt haben. Sie können den Befehl xe vm-copy oder XenCenter verwenden, um VMs zu verschieben.
Ressourcenpools können mit XenCenter oder der CLI erstellt werden. Wenn ein neuer Host einem Ressourcenpool beitritt, synchronisiert der beitretende Host seine lokale Datenbank mit der poolweiten Datenbank und erbt einige Einstellungen vom Pool:
VM-, lokale und Remote-Speicherkonfiguration wird der poolweiten Datenbank hinzugefügt. Diese Konfiguration wird auf den beitretenden Host im Pool angewendet, sofern Sie die Ressourcen nicht explizit freigeben, nachdem der Host dem Pool beigetreten ist.
Der beitretende Host erbt vorhandene freigegebene Speicherrepositories im Pool. Entsprechende PBD-Datensätze werden erstellt, damit der neue Host automatisch auf vorhandenen freigegebenen Speicher zugreifen kann.
Netzwerkinformationen werden teilweise an den beitretenden Host vererbt: Die strukturellen Details von NICs, VLANs und gebundenen Schnittstellen werden alle vererbt, Richtlinieninformationen jedoch nicht. Zu diesen Richtlinieninformationen, die neu konfiguriert werden müssen, gehören:
Die IP-Adressen der Verwaltungs-NICs, die von der ursprünglichen Konfiguration beibehalten werden.
Der Speicherort der Verwaltungsschnittstelle, der der ursprünglichen Konfiguration entspricht. Wenn die anderen Pool-Hosts beispielsweise Verwaltungsschnittstellen auf einer gebundenen Schnittstelle haben, muss der beitretende Host nach dem Beitritt zur Bindung migriert werden.
Dedizierte Speicher-NICs, die dem beitretenden Host von XenCenter oder der CLI neu zugewiesen werden müssen, und die PBDs müssen neu angeschlossen werden, um den Datenverkehr entsprechend weiterzuleiten. Dies liegt daran, dass IP-Adressen nicht im Rahmen des Pool-Join-Vorgangs zugewiesen werden und die Speicher-NIC nur funktioniert, wenn dies korrekt konfiguriert ist. Weitere Informationen zum Dedizieren einer Speicher-NIC über die CLI finden Sie unter Verwalten von Netzwerken.
Hinweis:
Sie können einen neuen Host nur mit einem Ressourcenpool verbinden, wenn sich die Verwaltungsschnittstelle des Hosts im selben markierten VLAN wie das des Ressourcenpools befindet.
Hinweis:
Wir empfehlen, Ihren Pool und den beitretenden Host auf die gleiche Stufe zu aktualisieren, bevor Sie versuchen, eine Verbindung herzustellen.
Öffnen Sie eine Konsole auf dem XenServer-Host, den Sie einem Pool hinzufügen möchten.
Verbinden Sie den XenServer-Host mit dem Pool, indem Sie den folgenden Befehl eingeben:
xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>
<!--NeedCopy-->
Die master-address muss auf den vollqualifizierten Domänennamen des Poolkoordinators gesetzt werden. Das password muss das Administratorkennwort sein, das bei der Installation des Poolkoordinators festgelegt wurde.
Hinweis:
Wenn Sie einen Host zu einem Pool hinzufügen, wird das Administratorkennwort für den beitretenden Host automatisch so geändert, dass es dem Administratorkennwort des Poolkoordinators entspricht.
XenServer-Hosts gehören standardmäßig zu einem unbenannten Pool. Um Ihren ersten Ressourcenpool zu erstellen, benennen Sie den vorhandenen namenlosen Pool um. Verwenden Sie tab-complete, um Folgendes zu finden pool_uuid:
xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->
XenServer vereinfacht die Erweiterung von Bereitstellungen im Laufe der Zeit, indem unterschiedliche Host-Hardware zu einem Ressourcenpool zusammengefasst werden kann, der als heterogene Ressourcenpools bezeichnet wird. Heterogene Ressourcenpools werden durch den Einsatz von Technologien in Intel (FlexMigration) und AMD (Extended Migration) CPUs ermöglicht, die eine “Maskierung” oder “Leveling” der CPU ermöglichen. Mit CPU-Maskierung und -Leveling kann eine CPU so konfiguriert werden, dass sie eine andere Marke, ein anderes Modell oder eine andere Funktionalität vorgibt als sie tatsächlich ist. Mit dieser Funktion können Sie Pools von Hosts mit unterschiedlichen CPUs erstellen und dennoch die Livemigration sicher unterstützen.
Hinweis:
Die CPUs von XenServer-Hosts, die heterogenen Pools beitreten, müssen vom gleichen Hersteller (d. h. AMD, Intel) sein wie die CPUs der Hosts, die sich bereits im Pool befinden. Es ist jedoch nicht erforderlich, dass die Hosts auf der Ebene der Familie, des Modells oder der Schrittnummer vom gleichen Typ sind.
XenServer vereinfacht die Unterstützung heterogener Pools. Hosts können jetzt zu vorhandenen Ressourcenpools hinzugefügt werden, unabhängig vom zugrunde liegenden CPU-Typ (sofern die CPU aus derselben Herstellerfamilie stammt). Das Pool-Feature-Set wird jedes Mal dynamisch berechnet:
Ein neuer Host tritt dem Pool bei
Ein Poolmitglied verlässt den Pool
Ein Poolmitglied stellt nach einem Neustart eine Verbindung wieder her
Jede Änderung des Pool-Feature-Sets wirkt sich nicht auf VMs aus, die derzeit im Pool ausgeführt werden. Eine laufende VM verwendet weiterhin den Funktionssatz, der beim Start angewendet wurde. Dieser Funktionsumfang wird beim Booten behoben und bleibt bei Migrations-, Aussetzungs- und Fortsetzungsvorgängen bestehen Wenn die Poolebene abfällt, wenn ein Host mit weniger Funktionen dem Pool beitritt, kann eine laufende VM auf jeden Host im Pool migriert werden, mit Ausnahme des neu hinzugefügten Hosts. Wenn Sie eine VM auf einen anderen Host innerhalb oder zwischen Pools verschieben oder migrieren, vergleicht XenServer den Funktionsumfang der VM mit dem Funktionsumfang des Zielhosts. Wenn sich herausstellt, dass die Feature-Sets kompatibel sind, kann die VM migriert werden. Auf diese Weise kann sich die VM frei innerhalb und zwischen Pools bewegen, unabhängig von den CPU-Funktionen, die die VM verwendet. Wenn Sie den Workload Balancing verwenden, um einen optimalen Zielhost für die Migration Ihrer VM auszuwählen, wird ein Host mit einem inkompatiblen Funktionsumfang nicht als Zielhost empfohlen.
Eine vollständige Liste der unterstützten freigegebenen Speichertypen finden Sie unter Speicherrepository-Formate. In diesem Abschnitt wird gezeigt, wie gemeinsam genutzter Speicher (dargestellt als Speicherrepository) auf einem vorhandenen NFS-Server erstellt werden kann.
Öffnen Sie eine Konsole auf einem beliebigen XenServer-Host im Pool.
Erstellen Sie das Speicherrepository auf server:/path, indem Sie den folgenden Befehl ausführen:
xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
device-config:server=server \
device-config:serverpath=path
<!--NeedCopy-->
device-config:server ist der Hostname des NFS-Servers und device-config:serverpath der Pfad auf dem NFS-Server. Wenn shared auf true gesetzt, wird Shared Storage automatisch mit jedem XenServer-Host im Pool verbunden. Alle XenServer-Hosts, die später beitreten, sind ebenfalls mit dem Speicher verbunden. Der Universally Unique Identifier (UUID) des Speicherrepositorys wird auf dem Bildschirm gedruckt.
Suchen Sie die UUID des Pools, indem Sie den folgenden Befehl ausführen:
xe pool-list
<!--NeedCopy-->
Legen Sie den gemeinsam genutzten Speicher mit dem folgenden Befehl als Pool-weiten Standard fest:
xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
<!--NeedCopy-->
Da der freigegebene Speicher als poolweiter Standard festgelegt wurde, werden die Datenträger aller zukünftigen VMs standardmäßig auf freigegebenem Speicher erstellt. Informationen zum Erstellen anderer Arten von freigegebenem Speicher finden Sie unter Speicherrepository-Formate.
Hinweis:
Bevor Sie einen XenServer-Host aus einem Pool entfernen, stellen Sie sicher, dass Sie alle auf diesem Host laufenden VMs herunterfahren. Andernfalls wird eine Warnung angezeigt, dass der Host nicht entfernt werden kann.
Wenn Sie einen Host aus einem Pool entfernen (auswerfen), wird der Computer neu gestartet, neu initialisiert und in einem Zustand belassen, der einer Neuinstallation ähnelt. Werfen Sie XenServer-Hosts nicht aus einem Pool aus, wenn sich wichtige Daten auf den lokalen Datenträgern befinden.
Öffnen Sie eine Konsole auf einem beliebigen Host im Pool.
Suchen Sie die UUID des Hosts, indem Sie den folgenden Befehl ausführen:
xe host-list
<!--NeedCopy-->
Werfen Sie den erforderlichen Host aus dem Pool aus:
xe pool-eject host-uuid=host_uuid
<!--NeedCopy-->
Der XenServer-Host wird ausgeworfen und befindet sich in einem neu installierten Zustand.
Warnung:
Werfen Sie keinen Host aus einem Ressourcenpool aus, wenn er wichtige Daten enthält, die auf seinen lokalen Datenträgern gespeichert sind. Alle Daten werden gelöscht, wenn ein Host aus dem Pool ausgeworfen wird. Wenn Sie diese Daten beibehalten möchten, kopieren Sie die VM mit XenCenter oder dem CLI-Befehl
xe vm-copyin den freigegebenen Speicher im Pool.
Wenn XenServer-Hosts 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 XenServer-Hosts sichtbar. Die VMs werden erst gestartet, wenn die ihnen zugewiesenen virtuellen Datenträger so geändert wurden, dass sie auf gemeinsam genutzten Speicher verweisen, der von anderen XenServer-Hosts im Pool gesehen wird, oder entfernt wurden. Daher empfehlen wir, dass Sie jeden lokalen Speicher in den freigegebenen Speicher verschieben, wenn Sie einem Pool beitreten. Durch die Umstellung auf gemeinsam genutzten Speicher können einzelne XenServer-Hosts ohne Datenverlust ausgeworfen werden (oder physisch ausfallen).
Hinweis:
Wenn ein Host aus einem Pool entfernt wird, dessen Verwaltungsschnittstelle sich in einem markierten VLAN-Netzwerk befindet, wird der Computer neu gestartet und seine Verwaltungsschnittstelle ist im selben Netzwerk verfügbar.
Bevor Sie Wartungsvorgänge auf einem Host ausführen, der Teil eines Ressourcenpools ist, müssen Sie ihn deaktivieren. Durch das Deaktivieren des Hosts wird verhindert, dass VMs darauf gestartet werden. Anschließend müssen Sie die VMs auf einen anderen XenServer-Host im Pool migrieren. Sie können dies tun, indem Sie den XenServer-Host 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 der Poolkoordinator in den Wartungsmodus versetzt wird, gehen die RRD-Updates der letzten 24 Stunden für Offline-VMs verloren.
Warnung:
Wir empfehlen dringend, alle XenServer-Hosts neu zu starten, bevor Sie ein Update installieren und anschließend deren Konfiguration überprüfen. Einige Konfigurationsänderungen werden erst wirksam, wenn der XenServer-Host neu gestartet wird, sodass beim Neustart möglicherweise Konfigurationsprobleme aufgedeckt werden, die dazu führen können, dass das Update fehlschlägt.
Führen Sie den folgenden Befehl aus:
xe host-disable uuid=XenServer_host_uuid
xe host-evacuate uuid=XenServer_host_uuid
<!--NeedCopy-->
Dieser Befehl deaktiviert den XenServer-Host und migriert dann alle laufenden VMs auf andere XenServer-Hosts im Pool.
Führen Sie den gewünschten Wartungsvorgang durch.
Aktivieren Sie den XenServer-Host, wenn der Wartungsvorgang abgeschlossen ist:
xe host-enable
<!--NeedCopy-->
Starten Sie alle angehaltenen VMs neu und setzen Sie alle gesperrten VMs fort.
Mit der Option Ressourcendaten exportieren können Sie einen Ressourcendatenbericht für Ihren Pool erstellen und den Bericht in eine .xls- oder .csv-Datei exportieren. Dieser Bericht enthält detaillierte Informationen zu verschiedenen Ressourcen im Pool wie Hosts, Netzwerken, Speicher, virtuellen Maschinen, VDIs und GPUs. Diese Funktion ermöglicht es Administratoren, Ressourcen auf der Grundlage verschiedener Workloads wie CPU, Speicher und Netzwerk zu verfolgen, zu planen und zuzuweisen.
Hinweis:
Export Resource Pool Data ist für Kunden der XenServer Premium Edition verfügbar.
Die Liste der Ressourcen und verschiedene Arten von Ressourcendaten, die im Bericht enthalten sind:
Server:
Netzwerke:
VDI:
Speicher:
Virtuelle Maschinen:
GPU:
Hinweis:
Informationen zu GPUs sind nur verfügbar, wenn GPUs an Ihren XenServer-Host angeschlossen sind.
Wählen Sie im XenCenter Navigationsbereich Infrastructure und dann den Pool aus.
Wählen Sie das Menü Pool und dann Ressourcendaten exportieren.
Navigieren Sie zu einem Speicherort, an dem Sie den Bericht speichern möchten, und klicken Sie dann auf Speichern.
Sie können die XenServer-Host-Power-On-Funktion verwenden, um einen Host remote ein- und auszuschalten, entweder über XenCenter oder über die CLI.
Um die Host-Energie zu aktivieren, muss der Host über eine der folgenden Stromsteuerungslösungen verfügen:
Wake on LAN-fähige Netzwerkkarte.
Dell Remote-Zugriffskarten (DRAC). Um XenServer mit DRAC zu verwenden, müssen Sie das Dell Supplemental Pack installieren, um DRAC-Unterstützung zu erhalten. Die DRAC-Unterstützung erfordert die Installation des RACADM-Befehlszeilenprogramms auf dem Host mit dem Remote Access Controller und die Aktivierung von DRAC und seiner Schnittstelle. RACADM ist oft in der DRAC-Management-Software enthalten. Weitere Informationen finden Sie in der DRAC-Dokumentation von Dell.
Ein benutzerdefiniertes Skript, das auf der Management-API basiert und es Ihnen ermöglicht, das Gerät über XenServer ein- und auszuschalten. Weitere Informationen finden Sie im folgenden Abschnitt unter Konfigurieren eines benutzerdefinierten Skripts für die Host-Einschaltfunktion .
Für die Verwendung der Host-Power-On-Funktion sind zwei Aufgaben erforderlich:
Stellen Sie sicher, dass die Hosts im Pool die Fernsteuerung der Stromversorgung unterstützen. Sie verfügen beispielsweise über Wake-on-LAN-Funktionalität oder eine DRAC-Karte, oder Sie haben ein benutzerdefiniertes Skript erstellt.
Aktivieren Sie die Host-Einschaltfunktion über die CLI oder XenCenter.
Sie können das Host-Einschaltfeature entweder mit der CLI oder XenCenter verwalten. Dieser Abschnitt enthält Informationen zur Verwaltung mit der CLI.
Host Power On ist auf Host-Ebene aktiviert (d. h. auf jedem XenServer).
Nachdem Sie Host Power On aktiviert haben, können Sie Hosts entweder mit der CLI oder XenCenter einschalten.
Führen Sie den Befehl aus:
xe host-set-power-on-mode host=<host uuid> \
power-on-mode=("" , "wake-on-lan", "DRAC","custom") \
power-on-config=key:value
<!--NeedCopy-->
Für DRAC müssen die Schlüssel power_on_ip das Kennwort angeben, wenn Sie die Secret-Funktion verwenden. Weitere Informationen finden Sie unter Secrets.
Führen Sie den Befehl aus:
xe host-power-on host=<host uuid>
<!--NeedCopy-->
Wenn die Remote-Power-Lösung Ihres Hosts 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 XenServer-Computer remote einzuschalten. Sie können jedoch auch benutzerdefinierte Skripte für DRAC- und Wake-on-LAN-Remote-Stromversorgungslösungen erstellen.
Dieser Abschnitt enthält Informationen zur Konfiguration eines benutzerdefinierten Skripts für Host Power On mithilfe der Schlüssel/Wert-Paare, die dem XenServer-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 XenServer-Host fernsteuern möchten. Alternativ können Sie es in XenCenter angeben und die XenCenter UI-Funktionen verwenden, um damit zu interagieren.
Die XenServer-API ist in der XenServer ManagementAPI dokumentiert.
Warnung:
Ändern Sie nicht die standardmäßig im Verzeichnis
/etc/xapi.d/plugins/bereitgestellten Skripts. Sie können neue Skripte in dieses Verzeichnis aufnehmen, aber Sie dürfen die in diesem Verzeichnis enthaltenen Skripte nach der Installation niemals ändern.
Um Host Power On zu verwenden, konfigurieren Sie die Schlüssel host.power_on_mode und host.power_on_config. Im folgenden Abschnitt finden Sie Informationen zu den Werten.
Es gibt auch einen API-Aufruf, mit dem Sie diese Felder gleichzeitig festlegen können:
void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->
Definition: Enthält Schlüssel/Wert-Paare zur Angabe des Typs der Remote-Stromversorgungslösung (z. B. Dell DRAC).
Mögliche Werte:
Eine leere Zeichenfolge, die für deaktivierte Energiesteuerung steht.
“DRAC”: Ermöglicht die Angabe von Dell DRAC. Um DRAC verwenden zu können, müssen Sie das Dell Zusatzpaket bereits installiert haben.
“wake-on-lan”: Ermöglicht die Angabe von Wake-on-LAN.
Jeder andere Name (wird verwendet, um ein benutzerdefiniertes Einschaltskript anzugeben). Diese Option wird verwendet, um ein benutzerdefiniertes Skript für die Energieverwaltung anzugeben.
Typ: string
Definition: Enthält Schlüssel/Wert-Paare für die Moduskonfiguration. Stellt zusätzliche Informationen für DRAC bereit.
Mögliche Werte:
Wenn Sie DRAC als Typ der Remote-Stromversorgungslösung konfiguriert haben, müssen Sie auch einen der folgenden Schlüssel angeben:
“power_on_ip”: Die IP-Adresse, die Sie für die Kommunikation mit der Stromsteuerungskarte konfiguriert haben. Alternativ können Sie den Domänennamen für die Netzwerkschnittstelle eingeben, auf der DRAC konfiguriert ist.
“power_on_user”: Der mit dem Verwaltungsprozessor verknüpfte DRAC-Benutzername, den Sie möglicherweise gegenüber den werkseitigen Standardeinstellungen geändert haben.
“power_on_password_secret”: Gibt die Verwendung der Secrets Funktion an, um Ihr Kennwort zu sichern.
Um das Secrets Feature zum Speichern Ihres Kennworts zu verwenden, geben Sie den Schlüssel “power_on_password_secret” an. Weitere Informationen finden Sie unter Secrets.
Typ: Map (Zeichenfolge, Zeichenfolge)
Das Beispielskript importiert die XenServer-API, definiert sich selbst als benutzerdefiniertes Skript und übergibt dann spezifische Parameter für den Host, den Sie remote steuern möchten. Sie müssen die Parameter session in allen benutzerdefinierten Scripts definieren.
Das Ergebnis wird angezeigt, wenn das Script nicht erfolgreich ist.
import XenAPI
def custom(session,remote_host,
power_on_config):
result="Power On Not Successful"
for key in power_on_config.keys():
result=result+''
key=''+key+''
value=''+power_on_config[key]
return result
<!--NeedCopy-->
Hinweis:
Nachdem Sie das Skript erstellt haben, speichern Sie es in /etc/xapi.d/plugins mit der Erweiterung .py.
XenServer verwendet das TLS 1.2-Protokoll, um den Verwaltungs-API-Verkehr zu verschlüsseln. Jegliche Kommunikation zwischen XenServer und Management-API-Clients (oder Appliances) verwendet das TLS 1.2-Protokoll.
Wichtig:
Wir unterstützen keine Kundenänderungen an der kryptographischen Funktionalität des Produkts.
XenServer verwendet die folgende Verschlüsselungssuite:
Darüber hinaus werden die folgenden Verschlüsselungssammlungen für die Abwärtskompatibilität mit einigen Versionen von Citrix Virtual Apps and Desktops unterstützt:
Wenn Sie einen SSH-Client verwenden, um eine direkte Verbindung zum XenServer-Host herzustellen, können die folgenden Algorithmen verwendet werden:
Chiffren:
MACs:
KexAlgorithms:
HostKeyAlgorithms:
Wenn Sie den SSH-Zugriff auf Ihren XenServer-Host deaktivieren möchten, können Sie dies in tun. xsconsole
root an.xsconsole ein.Gehen Sie in xsconsole zu Remote Service Configuration > Remoteshell aktivieren/deaktivieren.
Die Konsole zeigt an, ob Remoteshell aktiviert ist.
Wichtig:
Wir unterstützen keine Kundenänderungen an der kryptographischen Funktionalität des Produkts.
Der XenServer-Host wird mit einem Standard-TLS-Zertifikat installiert. Um jedoch HTTPS zur Sicherung der Kommunikation zwischen XenServer 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 über die xe-CLI Zertifikate installieren. Informationen zum Arbeiten mit Zertifikaten über XenCenter finden Sie in der XenCenter-Dokumentation.
Stellen Sie sicher, dass Ihr TLS-Zertifikat und sein Schlüssel die folgenden Anforderungen erfüllen:
.pem oder .key..pem, .cer, oder .crt.Die xe CLI warnt Sie, wenn das Zertifikat und der Schlüssel, die Sie wählen, diese Anforderungen nicht erfüllen.
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 XenServer-Host verbleiben und nicht zwischen Systemen kopiert werden kann.
Das Erstellen eines TLS-Zertifikats umfasst die folgenden Schritte:
Generieren Sie zunächst einen privaten Schlüssel und eine Zertifikatssignieranforderung. Führen Sie auf dem XenServer-Host die folgenden Schritte aus:
Führen Sie den folgenden Befehl aus, um eine private Schlüsseldatei zu erstellen:
openssl genrsa -des3 -out privatekey.pem 2048
<!--NeedCopy-->
Sie werden zur Eingabe einer Passphrase aufgefordert. Diese Passphrase wird in einem folgenden Schritt entfernt.
Entferne die Passphrase aus dem Schlüssel:
openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->
Erstellen Sie die Zertifikatssignierungsanforderung mithilfe des privaten Schlüssels:
openssl req -new -key privatekey.nop.pem -out csr
<!--NeedCopy-->
Befolgen Sie die Anweisungen, um die zum Generieren der Zertifikatssignierungsanforderung erforderlichen Informationen anzugeben.
Die Anforderung zum Signieren des Zertifikats wird im aktuellen Verzeichnis gespeichert und hat den Namen csr.
Zeigen Sie die Zertifikatssignierungsanforderung im Konsolenfenster an, indem Sie den folgenden Befehl ausführen:
cat csr
<!--NeedCopy-->
Kopieren Sie die gesamte Zertifikatssignierungsanforderung und verwenden Sie diese Informationen, um das Zertifikat von der Zertifizierungsstelle anzufordern.
Beispiel für eine Zertifikatsignieranforderung:
-----BEGIN CERTIFICATE REQUEST-----
MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
...
SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
ZL8naumG3yU=
-----END CERTIFICATE REQUEST-----
<!--NeedCopy-->
Nachdem Sie die Zertifikatsignieranforderung generiert haben, können Sie die Anfrage an die bevorzugte Zertifizierungsstelle Ihrer Organisation senden.
Eine Zertifizierungsstelle ist ein vertrauenswürdiger Drittanbieter, der digitale Zertifikate bereitstellt. Einige Zertifizierungsstellen verlangen, dass die Zertifikate auf einem System gehostet werden, auf das über das Internet zugegriffen werden kann. Wir empfehlen, für diese Anforderung keine Zertifizierungsstelle zu verwenden.
Die Zertifizierungsstelle beantwortet Ihre Signaturanfrage und stellt die folgenden Dateien zur Verfügung:
Sie können jetzt all diese Dateien auf Ihrem XenServer-Host installieren.
Nachdem die Zertifizierungsstelle auf die Zertifikatsignieranforderung geantwortet hat, führen Sie die folgenden Schritte aus, um das Zertifikat auf Ihrem XenServer-Host zu installieren:
Führen Sie den folgenden Befehl auf dem Host aus:
xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>
Der Parameter certificate-chain ist optional.
Für zusätzliche Sicherheit können Sie die private Schlüsseldatei löschen, nachdem das Zertifikat installiert wurde.
Wenn Sie einen XenServer-Host zum ersten Mal installieren, legen Sie ein Administrator- oder Root-Kennwort fest. Sie verwenden dieses Kennwort, um XenCenter mit Ihrem Host zu verbinden oder (mit Benutzername root), um sich bei xsconsole, der Systemkonfigurationskonsole, anzumelden.
Wenn Sie einen Host zu einem Pool hinzufügen, wird das Administratorkennwort für den Host automatisch so geändert, dass es dem Administratorkennwort des Poolkoordinators entspricht.
Hinweis:
XenServer-Administratorkennwörter dürfen nur ASCII-Zeichen enthalten.
Sie können XenCenter, die xe CLI oder xsconsole verwenden, um das Administratorkennwort zu ändern.
Gehen Sie wie folgt vor, um das Administratorkennwort für einen Pool oder einen eigenständigen Host mithilfe von XenCenter zu ändern:
Um das Root-Kennwort eines eigenständigen Hosts zu ändern, wählen Sie den Host im Bereich Ressourcen aus und klicken Sie im Menü Server auf Kennwort und dann auf Ändern .
Wenn XenCenter so konfiguriert ist, dass Ihre Host-Anmeldeinformationen zwischen den Sitzungen gespeichert werden, wird das neue Kennwort gespeichert. Weitere Informationen finden Sie unter Speichern des Verbindungsstatus Ihres Hosts.
Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis. Weitere Informationen finden Sie unter Rotation des Poolgeheimnisses.
Um das Administratorkennwort mithilfe der Xe-CLI zu ändern, führen Sie den folgenden Befehl auf einem Host im Pool aus:
xe user-password-change new=<new_password>
<!--NeedCopy-->
Hinweis:
Stellen Sie sicher, dass Sie dem Befehl ein Leerzeichen voranstellen, um zu vermeiden, dass das Klartextkennwort im Befehlsverlauf gespeichert wird.
Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis. Weitere Informationen finden Sie unter Rotation des Poolgeheimnisses.
Gehen Sie wie folgt vor, um das Administratorkennwort für einen Pool oder einen eigenständigen Host mithilfe von xsconsolezu ändern:
root.xsconsole ein. Drücken Sie die Eingabetaste. Die xsconsole wird angezeigt.Der Bildschirm “ Kennwortänderung erfolgreich “ wird angezeigt. Drücken Sie zum Schließen die Eingabetaste .
Wenn der Host Poolkoordinator ist, wird dieses aktualisierte Kennwort jetzt an die anderen Hosts im Pool weitergegeben.
Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis. Weitere Informationen finden Sie unter Rotation des Poolgeheimnisses.
Wenn Sie das Administratorkennwort (Root) für Ihren XenServer-Host verlieren, können Sie das Kennwort zurücksetzen, indem Sie direkt auf den Host zugreifen.
Starten Sie den XenServer-Host neu.
Wenn das GRUB-Menü angezeigt wird, drücken Sie e, um den Startmenüeintrag zu bearbeiten.
Fügen Sie init=/sysroot/bin/sh zu der Zeile hinzu, die mit module2 beginnt.
Drücken Sie Strg-X, um in eine Root-Shell zu booten.
Führen Sie in der Befehlsshell die folgenden Befehle aus:
chroot /sysroot
passwd
(type the new password twice)
sync
/sbin/reboot -f
<!--NeedCopy-->
Wenn der Host Poolkoordinator ist, wird dieses aktualisierte Kennwort jetzt an die anderen Hosts im Pool weitergegeben.
Nachdem Sie das Administratorkennwort geändert haben, rotieren Sie das Poolgeheimnis.
Das Pool-Geheimnis ist ein Geheimnis, das von den Hosts in einem Pool gemeinsam genutzt wird und es dem Host ermöglicht, seine Mitgliedschaft in einem Pool nachzuweisen.
Da Benutzer mit der Pool-Admin-Rolle dieses Geheimnis herausfinden können, empfiehlt es sich, das Pool-Geheimnis zu rotieren, wenn einer dieser Benutzer Ihre Organisation verlässt oder seine Pool-Admin-Rolle verliert.
Sie können das Poolgeheimnis über XenCenter oder die xe-CLI rotieren.
Führen Sie die folgenden Schritte aus, um das Poolgeheimnis für einen Pool mit XenCenter zu rotieren:
Wenn Sie das Poolgeheimnis rotieren, werden Sie auch aufgefordert, das root-Kennwort zu ändern. Wenn Sie das Poolgeheimnis rotiert haben, weil Sie glauben, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Kennwort ändern. Weitere Informationen finden Sie unter Ändern des Kennworts.
Um das Pool-Geheimnis mithilfe der Xe-CLI zu rotieren, führen Sie den folgenden Befehl auf einem Host im Pool aus:
xe pool-secret-rotate
<!--NeedCopy-->
Wenn Sie das Poolgeheimnis rotiert haben, weil Sie glauben, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Kennwort ändern. Weitere Informationen finden Sie unter Ändern des Kennworts.
XenServer sendet Multicast-Verkehr 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. Durch die Aktivierung des IGMP-Snoopings wird verhindert, dass Hosts in einem lokalen Netzwerk Datenverkehr für eine Multicastgruppe empfangen, denen sie nicht explizit beigetreten sind, und verbessert die Leistung von Multicast. IGMP-Snooping ist besonders nützlich für bandbreitenintensive IP-Multicast-Anwendungen wie IPTV.
Hinweise:
IGMP-Snooping ist nur verfügbar, wenn das Netzwerk-Backend Open vSwitch verwendet.
Wenn Sie diese Funktion in einem Pool aktivieren, kann es auch erforderlich sein, den IGMP-Abfrager auf einem der physischen Switches zu aktivieren. Andernfalls fällt Multicast im Subnetzwerk auf Broadcast zurück und kann die XenServer-Leistung beeinträchtigen.
Wenn Sie diese Funktion in einem Pool aktivieren, auf dem IGMP v3 ausgeführt wird, führt VM-Migration oder Netzwerkbindung-Failover dazu, dass IGMP-Version auf v2 umgeschaltet wird.
Um diese Funktion mit einem GRE-Netzwerk zu aktivieren, müssen Benutzer einen IGMP-Querier im GRE-Netzwerk einrichten. Alternativ können Sie die IGMP-Abfragenachricht vom physischen Netzwerk in das GRE-Netzwerk weiterleiten. Oder der Multicast-Verkehr im GRE-Netzwerk kann blockiert werden.
Sie können IGMP-Snooping in einem Pool über XenCenter oder der xe-CLI aktivieren.
Holen Sie sich die Pool-UUID:
xe pool-list
Aktivieren/deaktivieren Sie IGMP-Snooping für den Pool:
xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]
Nachdem Sie IGMP-Snooping aktiviert haben, können Sie die IGMP-Snooping-Tabelle mit der xe-CLI einsehen.
Verwenden Sie den folgenden Befehl, um die IGMP-Snooping-Tabelle anzuzeigen:
ovs-appctl mdb/show [bridge name]
Hinweis:
Sie können den Namen der Brücke mit
xe network-listabrufen. Diese Brückennamen könnenxenbr0,xenbr1,xenapioderxapi0lauten.
Dadurch wird eine Tabelle mit vier Spalten ausgegeben:
Wenn die GROUP eine Multicast-Gruppenadresse ist, bedeutet dies, dass eine IGMP-Berichtsmeldung auf dem zugehörigen Switch-Port empfangen wurde. Dies bedeutet, dass ein Empfänger (Mitglied) der Multicast-Gruppe diesen Port abhört.
Nehmen wir das folgende Beispiel, das zwei Datensätze enthält:
| Port | VLAN | GRUPPE | Alter |
|---|---|---|---|
| 14 | 0 | 227.0.0.1 | 15 |
| 1 | 0 | Abfrager | 24 |
Der erste Datensatz zeigt, dass an Port 14 ein Empfänger die Multicast-Gruppe 227.0.0.1 abhört. Der Open vSwitch leitet Datenverkehr, der für die 227.0.0.1-Multicast-Gruppe bestimmt ist, nur an Listening-Ports für diese Gruppe weiter (in diesem Beispiel Port 14), anstatt ihn an alle Ports zu übertragen. Der Datensatz, der Port 14 und Gruppe 227.0.0.1 verbindet, wurde vor 15 Sekunden erstellt. Standardmäßig beträgt das Timeout-Intervall 300 Sekunden. Das heißt, wenn der Switch nach dem Hinzufügen des Datensatzes 300 Sekunden lang keine weiteren IGMP-Report-Meldungen auf Port 14 empfängt, läuft der Datensatz ab und wird aus der Tabelle entfernt.
Im zweiten Datensatz ist die GROUPabfragender, was bedeutet, dass IGMP-Abfragenachrichten auf dem zugehörigen Port empfangen wurden. Ein Querier sendet regelmäßig IGMP-Abfragenachrichten, die an alle Switch-Ports gesendet werden, um festzustellen, welche Netzwerkknoten eine Multicast-Gruppe abhören. Auf den Empfang einer IGMP-Abfragenachricht antwortet der Empfänger mit einer IGMP-Berichtsnachricht, wodurch der Multicast-Datensatz des Empfängers aktualisiert wird und ein Ablauf vermieden wird.
Die VLAN-Spalte zeigt dem VLAN an, dass ein Receiver/Querier aktiv ist. ‘0’ bedeutet systemeigenes VLAN. Wenn Sie Multicast auf einem markierten VLAN ausführen möchten, stellen Sie sicher, dass das VLAN Datensätze enthält.
Hinweis:
Für das VLAN-Szenario sollten Sie einen Abfragedatensatz mit einem VLAN-Spaltenwert haben, der der VLAN-ID des Netzwerks entspricht, da Multicast sonst im VLAN-Netzwerk nicht funktioniert.
Während der Live-Migration einer VM wird ihr Speicher als Datenstrom zwischen zwei Hosts über das Netzwerk übertragen. Die Komprimierungsfunktion für Migrationsströme komprimiert diesen Datenstrom und beschleunigt so die Speicherübertragung in langsamen Netzwerken. Diese Funktion ist standardmäßig deaktiviert, kann jedoch mithilfe von XenCenter oder der Xe-CLI geändert werden. Weitere Informationen finden Sie unter Pooleigenschaften — Erweitert und Poolparameter. Alternativ können Sie die Komprimierung bei der Migration einer VM über die Befehlszeile aktivieren. Weitere Informationen finden Sie unter dem vm-migrate Befehl unter VM-Befehle.