Verwalten Sie Ihre Pools

Dieser Artikel beschreibt einige Maßnahmen, die Sie zur Verwaltung Ihres Pools ergreifen können.

Informationen zum Verwalten einzelner Hosts finden Sie unter Verwalten Ihrer Hosts.

Erstellen eines Ressourcenpools

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

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

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

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

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

  • Der Speicherort der Verwaltungsschnittstelle, der mit der ursprünglichen Konfiguration identisch bleibt. Wenn die anderen Pool-Hosts z. B. über Verwaltungsschnittstellen auf einer gebundenen Schnittstelle verfügen, muss der beitretende Host nach dem Beitritt zu der Bindung migriert werden.

  • Dedizierte Speicher-NICs, die dem beitretenden Host von XenCenter oder der CLI neu zugewiesen werden müssen, und die PBDs müssen neu angeschlossen werden, um den Datenverkehr entsprechend weiterzuleiten. Dies liegt daran, dass IP-Adressen im Rahmen des Poolbeitrittsvorgangs nicht zugewiesen werden und die Speicher-NIC nur funktioniert, wenn sie ordnungsgemäß konfiguriert ist. Weitere Informationen zum Dedizieren einer Speicher-NIC über die CLI finden Sie unter Verwalten des Netzwerks.

  • Konfigurieren Sie die Verwaltungsschnittstelle neu und verschieben Sie sie auf eine physische Netzwerkkarte, bevor Sie den Host zum Pool hinzufügen. Nachdem der Host dem Pool beigetreten ist, können Sie die Verwaltungsoberfläche erneut konfigurieren.

Bevor Sie einen Ressourcenpool erstellen, überprüfen Sie die Anforderungen für den Pool und den beitretenden Host. Weitere Informationen finden Sie unter Ressourcenpools.

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

Hinweis:

Wir empfehlen, Ihren Pool und den beitretenden Host auf das gleiche Niveau zu aktualisieren, bevor Sie den Beitritt versuchen.

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

2. Verbinden Sie den XenServer-Host mit dem Pool, indem Sie den folgenden Befehl ausgeben:

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

   Das Master-Adresse muss auf den vollqualifizierten Domänennamen des Poolkoordinators festgelegt werden. Das Passwort Es muss sich um das Administratorkennwort handeln, das bei der Installation des Poolkoordinators festgelegt wurde.

Hinweis:

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

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 die Tabulatortaste, um die pool_uuid:

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

Erstellen heterogener Ressourcenpools

XenServer vereinfacht die Erweiterung von Bereitstellungen im Laufe der Zeit, indem unterschiedliche Host-Hardware in einen Ressourcenpool eingebunden werden kann, der als heterogene Ressourcenpools bezeichnet wird. Heterogene Ressourcenpools werden durch die Verwendung von Technologien in Intel- (FlexMigration) und AMD-CPUs (Extended Migration) ermöglicht, die CPU-“Masking” oder “Leveling” bieten. Mit den CPU-Maskierungs- und Nivellierungsfunktionen kann eine CPU so konfiguriert werden, dass erscheinen als Bereitstellung einer anderen Marke, eines anderen Modells oder einer anderen Funktionalität, als es tatsächlich der Fall ist. Mit dieser Funktion können Sie Pools von Hosts mit unterschiedlichen CPUs erstellen, die Livemigration dennoch sicher unterstützen.

Hinweis:

Die CPUs von XenServer-Hosts, die heterogenen Pools beitreten, müssen vom selben Anbieter (d. h. AMD, Intel) sein wie die CPUs der Hosts, die sich bereits im Pool befinden. Es ist jedoch nicht erforderlich, dass die Hosts auf der Ebene der Familien-, Modell- oder Schrittnummern 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 (solange die CPU aus derselben Anbieterfamilie stammt). Der Funktionsumfang des Pools wird jedes Mal dynamisch berechnet:

• Ein neuer Host tritt dem Pool bei

• Ein Poolmitglied verlässt den Pool

• Ein Poolmitglied stellt nach einem Neustart die Verbindung wieder her

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

Hinzufügen von freigegebenem Speicher

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

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

1. Öffnen Sie eine Konsole auf einem beliebigen XenServer-Host im Pool.

2. Erstellen Sie das Speicherrepository auf server:/path, indem Sie den folgenden Befehl ausführen:

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

   Gerät-Konfiguration:Server ist der Hostname des NFS-Servers und Gerät-Konfiguration:ServerPfad ist der Pfad auf dem NFS-Server. Wie geteilt auf true festgelegt ist, wird der freigegebene Speicher automatisch mit jedem XenServer-Host im Pool verbunden. Alle XenServer-Hosts, die später beitreten, sind ebenfalls mit dem Speicher verbunden. Die Universally Unique Identifier (UUID) des Speicher-Repositorys wird auf dem Bildschirm gedruckt.

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

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

4. Legen Sie den freigegebenen Speicher mit dem folgenden Befehl als poolweiten Standard fest:

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

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

Entfernen von XenServer-Hosts aus einem Ressourcenpool

Hinweis:

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

Wenn Sie (ausstoßen) einen Host aus einem Pool erstellen, wird der Computer neu gestartet, neu initialisiert und in einem Zustand belassen, der einer Neuinstallation ähnelt. Werfen Sie XenServer-Hosts nicht aus einem Pool aus, wenn sich wichtige Daten auf den lokalen Festplatten befinden.

So entfernen Sie einen Host aus einem Ressourcenpool mithilfe der CLI

1. Öffnen Sie eine Konsole auf einem beliebigen Host im Pool.

2. Suchen Sie die UUID des Hosts, indem Sie den folgenden Befehl ausführen:

     xe host-list
   <!--NeedCopy-->
   

3. Werfen Sie den erforderlichen Host aus dem Pool aus:

     xe pool-eject host-uuid=host_uuid
   <!--NeedCopy-->
   

   Der XenServer-Host wird ausgeworfen und verbleibt in einem frisch installierten Zustand.

   Warnung:

   Tun nicht Auswerfen eines Hosts aus einem Ressourcenpool, wenn er wichtige Daten enthält, die auf seinen lokalen Festplatten gespeichert sind. Alle Daten werden gelöscht, wenn ein Host aus dem Pool ausgeworfen wird. Wenn Sie diese Daten beibehalten möchten, kopieren Sie die VM mithilfe von XenCenter in den freigegebenen Speicher im Pool xe vm-copy CLI-Befehl.

Wenn XenServer-Hosts, 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 XenServer-Hosts sichtbar. Die VMs werden erst gestartet, wenn die ihnen zugeordneten virtuellen Festplatten so geändert wurden, dass sie auf freigegebenen Speicher verweisen, der von anderen XenServer-Hosts im Pool angezeigt wird, oder entfernt wurden. Daher wird empfohlen, dass Sie den lokalen Speicher in den freigegebenen Speicher verschieben, wenn Sie einem Pool beitreten. Durch den Wechsel zu gemeinsam genutztem 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 getaggten VLAN-Netzwerk befindet, wird der Computer neu gestartet und seine Verwaltungsschnittstelle ist im selben Netzwerk verfügbar.

Drehen des Poolgeheimnisses

Das Poolgeheimnis 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 Rolle “Pooladministrator” diesen geheimen Schlüssel ermitteln können, empfiehlt es sich, den geheimen Poolschlüssel zu rotieren, wenn einer dieser Benutzer Ihre Organisation verlässt oder seine Rolle als Pooladministrator verliert.

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

XenCenter

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

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

Wenn Sie den geheimen Poolschlüssel rotieren, werden Sie auch aufgefordert, das Root-Kennwort zu ändern. Wenn Sie das Pool-Geheimnis rotiert haben, weil Sie glauben, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Passwort des Pool-Koordinators ändern. Weitere Informationen finden Sie unter Ändern des Passworts.

xe CLI

Um den geheimen Poolschlüssel 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 den geheimen Poolschlüssel rotiert haben, weil Sie der Meinung sind, dass Ihre Umgebung kompromittiert wurde, stellen Sie sicher, dass Sie auch das Root-Kennwort ändern. Weitere Informationen finden Sie unter Ändern des Passworts.

Konfigurieren des SSH-Zugriffs

Der SSH-Zugriff auf Hosts in Ihrem Pool ist standardmäßig aktiviert. Wenn Sie den SSH-Zugriff auf alle Hosts in Ihrem Pool deaktivieren möchten, führen Sie den folgenden Befehl aus:

  xe pool-disable-ssh
<!--NeedCopy-->

Dieser Befehl deaktiviert SSH. Die Hosts lehnen neue SSH-Verbindungen ab, trennen jedoch keine bestehenden Sitzungen.

Um den SSH-Zugriff auf alle Hosts in Ihrem Pool zu aktivieren, führen Sie den folgenden Befehl aus:

  xe pool-enable-ssh
<!--NeedCopy-->

Beide Befehle versuchen, eine Änderung auf allen Hosts im Pool vorzunehmen. Wenn der Befehl auf einem oder mehreren Hosts in Ihrem Pool fehlschlägt, wird der Befehl für alle anderen Hosts im Pool weiterhin ausgeführt. Der Befehl gibt eine Liste aller Hosts zurück, bei denen der Befehl fehlschlägt.

Sie können den SSH-Zugriff für einen einzelnen Host verwalten. Weitere Informationen finden Sie unter SSH-Zugriff für einen Host deaktivieren.

Aktivieren Sie IGMP-Snooping in Ihrem XenServer-Pool

XenServer sendet Multicast-Datenverkehr an alle Gast-VMs, was zu einer unnötigen Belastung der Hostgeräte führt, da sie Pakete verarbeiten müssen, die sie nicht angefordert haben. Das Aktivieren von IGMP-Snooping verhindert, dass Hosts in einem lokalen Netzwerk Datenverkehr für eine Multicast-Gruppe empfangen, der sie nicht explizit beigetreten sind, und verbessert die Leistung von Multicast. IGMP-Snooping ist besonders nützlich für bandbreitenintensive IP-Multicast-Anwendungen wie IPTV.

Hinweise:

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

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

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

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

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

XenCenter

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

xe CLI

1. Holen Sie sich die Pool-UUID:

   xe pool-list

2. Aktivieren/Deaktivieren von IGMP-Snooping für den Pool:

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

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

IGMP-Snooping-Tabelle anzeigen

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

ovs-appctl mdb/show [bridge name]

Hinweis:

Sie können den Brückennamen mit xe network-listabrufen. Diese Brückennamen können sein xenbr0, xenbr1, Xenapioder xapi0.

Daraus ergibt sich eine Tabelle mit vier Spalten:

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

Wenn es sich bei GROUP um eine Multicast-Gruppenadresse handelt, bedeutet dies, dass auf dem zugehörigen Switch-Port eine IGMP-Berichtsnachricht empfangen wird. Dies bedeutet, dass ein Empfänger (Mitglied) der Multicastgruppe an diesem Port lauscht.

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

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

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

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

Hinweis:

Für das VLAN-Szenario müssen Sie über einen Abfragedatensatz mit einem VLAN-Spaltenwert verfügen, der der VLAN-ID des Netzwerks entspricht. Andernfalls funktioniert Multicast im VLAN-Netzwerk nicht.

Aktivieren Sie die Komprimierung des Migrationsdatenstroms in Ihrem XenServer-Pool

Bei der Live-Migration einer VM wird ihr Arbeitsspeicher als Datenstrom zwischen zwei Hosts über das Netzwerk übertragen. Die Funktion zur Komprimierung des Migrationsdatenstroms 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 Pool-Immobilien - Erweitert und Pool-Parameter. Alternativ können Sie die Komprimierung beim Migrieren eines virtuellen Computers über die Befehlszeile aktivieren. Weitere Informationen finden Sie in der vm-migrieren Befehl in VM-Befehle.

Exportieren von Ressourcenpooldaten

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

Hinweis:

Das Exportieren von Ressourcenpooldaten ist für Kunden der XenServer Premium Edition verfügbar.

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

Server:

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

Netzwerke:

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

VDI:

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

Speicher:

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

Vms:

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

Grafikprozessor:

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

Hinweis:

Informationen zu GPUs sind nur verfügbar, wenn GPUs an Ihren XenServer-Host angeschlossen sind.

So exportieren Sie Ressourcendaten

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

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

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