Hosts und Ressourcenpools

In diesem Abschnitt wird beschrieben, wie Ressourcenpools anhand einer Reihe von Beispielen mithilfe der Befehlszeilenschnittstelle (CLI) erstellt werden können. Es wird eine einfache NFS-basierte Shared Storage-Konfiguration vorgestellt und einige einfache VM-Verwaltungsbeispiele werden erläutert. Es enthält auch Verfahren zum Umgang mit physikalischen Knotenfehlern.

Übersicht über HASH (0x2e68218) Server und Ressourcenpools

Ein Ressourcenpool umfasst mehrere HASH-Serverinstallationen (0x2e68218), die an eine einzelne verwaltete Entität gebunden sind, die virtuelle Maschinen hosten kann. In Kombination mit freigegebenem Speicher können VMs mit einem Ressourcenpool auf jedem HASH (0x2e68218) Server gestartet werden, der über ausreichend Arbeitsspeicher verfügt. Die VMs können dann dynamisch zwischen HASH-Servern (0x2e68218) verschoben werden, während sie mit minimalen Ausfallzeiten (Live-Migration) ausgeführt werden. Wenn ein einzelner HASH-Server (0x2e68218) einen Hardwarefehler erleidet, kann der Administrator ausgefallene VMs auf einem anderen HASH-Server (0x2e68218) im selben Ressourcenpool neu starten. Wenn die hohe Verfü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 Master-Knoten stellt eine Administrationsoberfläche zur Verfügung (die von HASH (0x2e6c8e8) und der HASH (0x2c1a078) Befehlszeilenschnittstelle, bekannt als Xe-CLI). Der Master leitet Befehle bei 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 die Erstellung von Ressourcenpools

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

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

  • Auf dem Server, der dem Pool beitritt, wird dieselbe Version der HASH (0x2c1a078) Software auf der gleichen Patch-Ebene ausgeführt wie Server, die sich bereits im Pool befinden.

Die Software erzwingt zusätzliche Einschränkungen beim Verbinden eines Servers zu einem Pool. Insbesondere überprüft HASH (0x2c1a078), ob die folgenden Bedingungen für den Server erfüllt sind, 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 angehaltenen VMs.

  • Auf den VMs auf dem Server werden keine aktiven Vorgänge ausgeführt, z. B. wenn eine VM heruntergefahren wird.

  • Die Uhr auf dem Server wird zur gleichen Zeit wie der Poolmaster synchronisiert (z. B. mithilfe von NTP).

  • Die Verwaltungsschnittstelle des Servers ist nicht verbunden. Sie können die Verwaltungsschnittstelle konfigurieren, wenn der Server erfolgreich dem Pool beitritt.

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

HASH (0x2e68218) Server in Ressourcenpools können unterschiedliche Anzahl physischer Netzwerkschnittstellen enthalten und lokale Speicher-Repositories unterschiedlicher Größe aufweisen. In der Praxis ist es oft schwierig, mehrere Server mit exakt gleichen CPUs zu erhalten, und daher sind geringfügige Variationen zulässig. Wenn es akzeptabel ist, Hosts mit unterschiedlichen CPUs als Teil desselben Pools zu haben, können Sie den Poolbeitritt 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 HASH (0x2e68218) Server eine VM ausführen und eine VM dynamisch zwischen HASH (0x2e68218) Servern verschieben soll. Wenn möglich, erstellen Sie einen Pool, nachdem gemeinsam genutzter Speicher verfügbar ist. Es wird empfohlen, vorhandene VMs mit Datenträgern, die sich im lokalen Speicher befinden, in den freigegebenen Speicher zu verschieben, nachdem Sie gemeinsam genutzten Speicher hinzugefügt haben. Sie können denxe vm-copy Befehl verwenden oder HASH (0x2e6c8e8) verwenden, um VMs zu verschieben.

Erstellen eines Ressourcenpools

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

  • VM, lokale und Remote-Speicherkonfiguration 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 gemeinsam genutzte 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 beitretenden Host geerbt: Die strukturellen Details von NICs, VLANs und gebundenen Schnittstellen werden alle geerbt, Richtlinien informationen jedoch nicht. Diese Richtlinieninformationen, die neu konfiguriert werden müssen, umfassen:

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

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

    • Dedizierte Speicher-NICs, die dem beitretenden Host von HASH (0x2e6c8e8) oder der CLI zugewiesen werden müssen, und die PBDs wurden neu zugeordnet, 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 InformationenVerwalten von Netzwerkenzum Dedizieren einer Speicher-NIC über die CLI finden Sie unter.

Hinweis:

Sie können einen neuen Host nur mit einem Ressourcenpool verknüpfen, wenn sich die Verwaltungsschnittstelle des Hosts auf demselben markierten VLAN wie die des Ressourcenpools befindet.

So fügen Sie HASH (0x2e68218) Server host1 und host2 in einen Ressourcenpool mithilfe der CLI

  1. Öffnen Sie eine Konsole auf dem HASH (0x2e68218) Server host2.

  2. Befehlen Sie HASH (0x2e68218) server host2 , um dem Pool auf dem HASH (0x2e68218) Server host1 beizutreten, indem Sie 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 HASH (0x2e68218) -Server host1 festgelegt werden. Derpassword muss das Administratorkennwort sein, das festgelegt wurde, wenn der HASH (0x2e68218) Server host1 installiert wurde.

HASH (0x2e68218) 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 diepool_uuidfolgenden zu finden:

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

Erstellen heterogener Ressourcenpools

HASH (0x2c1a078) vereinfacht die Erweiterung von Bereitstellungen im Laufe der Zeit, da die heterogene 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 CPU „Masking“ oder „Leveling“ bereitstellen. Die CPU-Maskierungs- und Nivellierungsfunktionen ermöglichen es, dass eine CPU so konfiguriert wird , dass sie eine andere Marke, ein Modell oder eine andere Funktionalität bereitstellt als tatsächlich. Mit dieser Funktion können Sie Pools von Hosts mit verteilten CPUs erstellen, aber dennoch die Live-Migration sicher unterstützen.

Hinweis:

Die CPUs von HASH (0x2e68218) Servern, die heterogene Pools verbinden, müssen vom gleichen Anbieter (also AMD, Intel) sein wie CPUs auf Hosts im Pool. Der spezifische Typ (Familie, Modell und Schrittnummern) muss jedoch nicht sein.

HASH (0x2c1a078) 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). Der Pool-Feature-Set wird jedes Mal dynamisch berechnet:

  • Ein neuer Host tritt dem Pool bei

  • Ein Poolmitglied verlässt den Pool

  • Ein Poolmitglied stellt die Verbindung nach einem Neustart wieder her

Änderungen am Pool-Feature-Set wirken 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 ist beim Start behoben und bleibt bei Migrations-, Anhaltens- und Fortsetzungsvorgängen bestehen. Wenn die Poolebene abfällt, wenn ein weniger fähiger Host dem Pool beitritt, kann eine ausgeführte VM auf einen 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 HASH (0x2c1a078) das Feature-Set der VM mit dem Feature-Set des Zielhosts. Wenn die Feature-Sets als kompatibel befunden werden, darf die VM migriert werden. Dadurch kann die VM unabhängig von den CPU-Funktionen, die die VM verwendet, frei innerhalb und über Pools hinweg 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-Satz als Zielhost nicht empfohlen.

Gemeinsam genutzten Speicher hinzufügen

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 gemeinsam genutzten NFS-Speicher mithilfe der Befehlszeilenschnittstelle hinzu

  1. Öffnen Sie eine Konsole auf einem beliebigen HASH-Server (0x2e68218) 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 Der Hostname des NFS-Servers unddevice-config:serverpath der Pfad auf dem NFS-Server. Wieshared auf true gesetzt, wird gemeinsam genutzter Speicher automatisch mit jedem HASH (0x2e68218) Server im Pool verbunden. Alle HASH (0x2e68218) 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 mit dem Befehl

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

    Da der freigegebene Speicher als Standardwert für den Pool festgelegt wurde, werden für alle zukünftigen VMs standardmäßig Festplatten auf freigegebenem Speicher erstellt. Weitere InformationenSpeicher-Repository-Formatezum Erstellen anderer Arten von gemeinsam genutztem Speicher finden Sie unter.

Entfernen von HASH (0x2e68218) Servern aus einem Ressourcenpool

Hinweis:

Stellen Sie vor dem Entfernen eines HASH-Servers (0x2e68218) aus einem Pool 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 einen Host aus einem Pool entfernen (auswerfen), wird der Computer neu gestartet, neu initialisiert und in einem Zustand wie bei einer Neuinstallation belassen. HASH (0x2e68218) Server nicht aus einem Pool auswerfen, wenn wichtige Daten auf den lokalen Datenträgern vorhanden sind.

So entfernen Sie einen Host aus einem Ressourcenpool mithilfe 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. Auswerfen des erforderlichen Hosts aus dem Pool:

    xe pool-eject host-uuid=host_uuid
    

    Der HASH (0x2e68218) Server wird ausgeworfen und in einem neu installierten Zustand belassen.

    Achtung:

    Werfen Sie einen Host nicht 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 mithilfe von HASH (0x2e6c8e8) oder demxe vm-copy CLI-Befehl in den freigegebenen Speicher im Pool.

Wenn HASH-Server (0x2e68218), 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 HASH-Server (0x2e68218) 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 HASH-Servern (0x2e68218) im Pool angezeigt wird, oder entfernt wurden. Daher empfehlen wir, jeden lokalen Speicher in den freigegebenen Speicher zu verschieben, wenn Sie einem Pool beitreten. Durch die Umstellung auf gemeinsam genutzten Speicher können einzelne HASH-Server (0x2e68218) ausgeworfen werden (oder physisch ausfallen), ohne dass Daten verloren gehen.

Hinweis:

Wenn ein Host aus einem Pool entfernt wird, der seine Verwaltungsschnittstelle in einem markierten VLAN-Netzwerk aufweist, wird der Computer neu gestartet, und seine Verwaltungsschnittstelle steht im selben Netzwerk zur Verfügung.

Vorbereiten eines Pools von HASH (0x2e68218) -Servern für die Wartung

Bevor Sie Wartungsvorgänge auf einem Host durchführen, der Teil eines Ressourcenpools ist, müssen Sie ihn deaktivieren. Das Deaktivieren des Hosts verhindert, dass virtuelle Rechner auf ihm gestartet werden. Anschließend müssen Sie die VMs auf einen anderen HASH-Server (0x2e68218) im Pool migrieren. Sie können dies tun, indem Sie den HASH (0x2e68218) Server mit HASH (0x2e6c8e8) in den Wartungsmodus versetzen. Weitere Informationen finden Sie in der Hilfe zu HASH (0x2e6c8e8).

Die Backup-Synchronisation erfolgt alle 24 Stunden. Wenn der Master-Host in den Wartungsmodus versetzt wird, werden die letzten 24 Stunden RRD-Updates für Offline-VMs verloren.

Achtung:

Es wird dringend empfohlen, alle HASH (0x2e68218) Server neu zu starten, bevor ein Update installiert und anschließend deren Konfiguration überprüft wird. Einige Konfigurationsänderungen werden nur wirksam, wenn HASH (0x2e68218) neu gestartet wird, sodass der Neustart Konfigurationsprobleme aufdeckt, 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 Befehlszeilenschnittstelle vor

  1. Führen Sie den folgenden Befehl aus:

    xe host-disable uuid=HASH(0x2e68218)_host_uuid
    xe host-evacuate uuid=HASH(0x2e68218)_host_uuid
    

    Mit diesem Befehl wird der HASH-Server (0x2e68218) deaktiviert und anschließend alle ausgeführten VMs auf andere HASH-Server (0x2e68218) im Pool migriert.

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

  3. Aktivieren Sie den HASH (0x2e68218) -Server, wenn der Wartungsvorgang abgeschlossen ist:

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

Ressourcenpooldaten exportieren

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 über verschiedene Ressourcen im Pool, z. B. 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:Ressourcenpooldaten

exportieren sind für HASH (0x2c1a078) HASH (0x2e72eb8) -Kunden oder diejenigen, die über ihre Citrix Virtual Apps und Desktops Zugriff auf HASH (0x2c1a078) haben verfügbar.

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

Server:

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

Netzwerke:

  • Name
  • Verknüpfungsstatus
  • MAC
  • MTU
  • VLAN
  • Typ
  • Standort

VDI:

  • Name
  • Typ
  • UUUID
  • Größe:
  • Speicher
  • Beschreibung

Lagerung:

  • Name
  • Typ
  • UUUID
  • Größe:
  • Standort
  • Beschreibung

VMs:

  • Name
  • Stromversorgungszustand
  • Läuft auf
  • Adresse
  • MAC
  • NIC
  • Betriebssystem
  • Speicher
  • Verwendeter Speicher
  • CPU-Auslastung
  • UUUID
  • Betriebszeit
  • Vorlage
  • Beschreibung

GPU:

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

Hinweis:

Informationen zu GPUs sind nur verfügbar, wenn GPUs an Ihren HASH-Server (0x2e68218) angeschlossen sind.

So exportieren Sie Ressourcendaten

  1. Wählen Sie im Navigationsbereich HASH (0x2e6c8e8) die Option Infrastruktur aus, und wählen Sie dann den Pool aus.

  2. Wählen Sie das Menü Pool und dann Ressourcendaten exportieren .

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

Einschalten des Rechners

Remote-Einschalten von Hosts

Sie können die HASH (0x2e68218) Server-Einschaltfunktion verwenden, um einen Server remote ein- und auszuschalten, entweder über HASH (0x2e6c8e8) oder über die Befehlszeilenschnittstelle.

Um die Host-Stromversorgung 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 HASH (0x2c1a078) mit DRAC zu verwenden, müssen Sie das DRAC-Zusatzpaket installieren, um DRAC-Unterstützung zu erhalten. Die 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 häufig in der DRAC-Management-Software enthalten. Weitere Informationen finden Sie in der DRAC-Dokumentation von Dell.

  • Hewlett-Packard Integrierte Lichtschranken (iLO). Um HASH (0x2c1a078) 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 HASH (0x2c1a078) durchführen können. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Skripts für die Host-Einschaltfunktion im folgenden Abschnitt.

Die Verwendung der Host-Einschaltfunktion erfordert zwei Aufgaben:

  1. Stellen Sie sicher, dass die Hosts im Pool die Stromversorgung remote steuern. Beispielsweise verfügen sie über Wake-on-LAN-Funktionalität, eine DRAC- oder iLO-Karte oder Sie haben ein benutzerdefiniertes Skript erstellt).

  2. Aktivieren Sie die Host-Power-On-Funktion mit der CLI oder dem HASH (0x2e6c8e8).

Verwenden der Befehlszeilenschnittstelle zum Verwalten der Netzeinspeisung

Sie können die Host-Einschaltfunktion entweder über die CLI oder den HASH (0x2e6c8e8) verwalten. Dieser Abschnitt enthält Informationen über die Verwaltung mit der Befehlszeilenschnittstelle.

Host Power On ist auf Host-Ebene aktiviert (d. h. auf jedem HASH (0x2c1a078)).

Nachdem Sie Host Power On aktiviert haben, können Sie Hosts entweder über die CLI oder den HASH (0x2e6c8e8) aktivieren.

So aktivieren Sie das Einschalten des Hosts mithilfe der Befehlszeilenschnittstelle

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 DRAC sind die Schlüsselpower_on_ip{#prmnmN7008A},power_on_user{#prmnmN70090},power_on_password_secret{#prmnmN70096}. Verwenden Siepower_on_password_secret{#prmnmN7009C}, um das Kennwort anzugeben, wenn Sie die geheime Funktion verwenden. Weitere Informationen finden Sie unter Geheimnisse.

So aktivieren Sie Hosts remote mithilfe der Befehlszeilenschnittstelle

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-Stromversorgungslösung Ihres Servers ein Protokoll verwendet, das standardmäßig nicht unterstützt wird (z. B. Wake-On-Ring oder Intel Active Management Technology), können Sie ein benutzerdefiniertes Linux Python-Skript erstellen, um Ihre HASH-Computer (0x2c1a078) remote zu aktivieren. Sie können jedoch auch benutzerdefinierte Skripte für iLO-, DRAC- und Wake-on-LAN-Remote-Stromversorgungslösungen erstellen.

Dieser Abschnitt enthält Informationen zum Konfigurieren eines benutzerdefinierten Skripts für das Einschalten von Host mithilfe der Schlüssel/Wert -Paare, die dem API-Aufruf von HASH (0x2c1a078) zugeordnet sindhost.power_on.

Wenn Sie ein benutzerdefiniertes Skript erstellen, führen Sie es jedes Mal von der Befehlszeile aus, wenn Sie die Stromversorgung über HASH fernsteuern möchten (0x2c1a078). Alternativ können Sie es in HASH (0x2e6c8e8) angeben und die Funktionen der HASH (0x2e6c8e8) verwenden, um damit zu interagieren.

Die HASH (0x2c1a078) API ist im Dokument, der HASH (0x2c1a078) Management-API, dokumentiert, dieEntwicklerdokumentationauf der Website verfügbar ist.

Achtung:

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

Schlüssel/Wert -Paare {#host .power_on_mode}

Konfigurieren Sie diehost.power_on_mode Tastenhost.power_on_config und, um den Host-Einschalten zu verwenden. 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 darstellt

    • „iLO“: Hier können Sie HP iLO angeben.

    • „DRAC“: Hier können Sie Dell DRAC angeben. Um DRAC verwenden zu können, müssen Sie das Dell-Zusatzpaket bereits installiert haben.

    • „wake-on-lan“: Hier können Sie Wake on LAN angeben.

    • 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

host.power_on_config
  • Definition: Enthält Schlüssel/Wert -Paare für die Moduskonfiguration. Enthält zusätzliche Informationen zu iLO und DRAC.

  • Mögliche Werte:

    • Wenn Sie iLO oder 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 Power-Control-Karte 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“: Legt fest, mit der Secrets-Funktion Ihr Passwort zu sichern.

    • Um das Secrets-Feature 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 HASH (0x2c1a078) 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 Parametersession{#prmnmN8012E},remote_host{#prmnmN80134} undpower_on_config{#prmnmN8013A} 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 HASH (0x2e68218) Servern und Ressourcenpools

HASH (0x2c1a078) verwendet TLS-Protokolle zur Verschlüsselung des Management-API-Datenverkehrs. Jede Kommunikation zwischen HASH (0x2c1a078) und Management-API-Clients (oder Appliances) verwendet nun standardmäßig 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.

HASH (0x2c1a078) 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 HASH (0x2c1a078) können Sie außerdem Ihren Host- oder Ressourcenpool so konfigurieren, dass nur die Kommunikation über TLS 1.2möglich ist. Diese Option ermöglicht die Kommunikation zwischen HASH (0x2c1a078) und Management-API-Clients (oder Appliances) mithilfe des TLS 1.2-Protokolls. Die Option „Nur TLS 1.2“ verwendet die VerschlüsselungssuiteTLS_RSA_WITH_AES_128_CBC_SHA256.

Warnung:

Wählen Sie die Option Nur TLS 1.2aus, nachdem Sie sichergestellt haben, dass alle Management-API-Clients und -Appliances, die mit dem HASH (0x2e68218) -Pool kommunizieren, mit TLS 1.2 kompatibel sind.

Aktivieren Sie IGMP Snooping auf Ihrem HASH (0x2e68218) Pool

HASH (0x2e68218) sendet Multicastverkehr an alle Gast-VMs, was zu unnötiger Belastung der Hostgeräte führt, indem sie die Verarbeitung von Paketen, die sie nicht angefordert haben, verlangt. Durch Aktivieren von IGMP Snooping wird verhindert, dass Hosts in einem lokalen Netzwerk Datenverkehr für eine Multicastgruppe empfangen, die ihnen nicht explizit beigetreten ist, und die Leistung von Multicast verbessert. IGMP Snooping ist besonders nützlich für bandbreitenintensive IP-Multicast-Anwendungen wie IPTV.

Sie können IGMP Snooping in einem Pool entweder mit HASH (0x2e6c8e8) oder der Befehlszeilenschnittstelle aktivieren. Um IGMP Snooping mit HASH (0x2e6c8e8) zu aktivieren, navigieren Sie zu Pooleigenschaften , und wählen Sie Netzwerkoptionen aus. Weitere Informationen finden Sie in der Hilfe zu HASH (0x2e6c8e8). Weitere Informationen zu xe-Befehlen finden Sie unterPool-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-Abfragen auf einem der physischen Switches zu aktivieren. Andernfalls wird Multicast im Unternetzwerk auf Broadcast zurückgreifen und kann die HASH-Leistung (0x2e68218) verringern.

  • Wenn Sie diese Funktion in einem Pool aktivieren, auf dem IGMP v3 ausgeführt wird, führt die Migration von VMs oder das Failover von Netzwerkbindungen dazu, dass die IGMP-Version zu v2 wechselt.

  • Um diese Funktion im GRE-Netzwerk zu aktivieren, müssen Benutzer einen IGMP-Querier im GRE-Netzwerk einrichten. Alternativ können Sie die IGMP-Abfragemeldung vom physischen Netzwerk an das GRE-Netzwerk weiterleiten. Andernfalls kann der Multicastverkehr im GRE-Netzwerk blockiert werden.