Ressourcenpools
Ein Ressourcenpool umfasst mehrere XenServer®-Hostinstallationen, die zu einer einzigen verwalteten Entität zusammengefasst sind, die virtuelle Maschinen hosten kann. In Kombination mit gemeinsam genutztem Speicher ermöglicht ein Ressourcenpool, VMs auf jedem beliebigen XenServer-Host zu starten, der über ausreichend Arbeitsspeicher verfügt.
Der Pool-Koordinator (früher „Pool-Master“) ist ein Server im Ressourcenpool, der eine Verwaltungsschnittstelle bereitstellt (die von XenCenter® und der XenServer-Befehlszeilenschnittstelle, bekannt als xe CLI, verwendet wird). Der Pool-Koordinator leitet Befehle bei Bedarf an einzelne Mitglieder weiter.
Dieser Artikel beschreibt die Konzepte, Anforderungen und Best Practices in Bezug auf Ressourcenpools. Informationen zum Erstellen und Verwalten Ihrer Pools finden Sie unter Verwalten Ihrer Pools.
Vorteile von Ressourcenpools
Obwohl Sie Ihre XenServer-Hosts als eigenständige Hosts organisieren können, effektiv ein Pool von einem Host, ist XenServer für Hosts optimiert, die in Ressourcenpools mit gemeinsam genutztem Speicher gruppiert sind. Einige unserer Funktionen, wie Hochverfügbarkeit und Live-Migration, sind nur in Ressourcenpools mit mehreren Hosts verfügbar. Die Vorteile der Organisation Ihrer XenServer-Hosts in Ressourcenpools umfassen die folgenden:
- VM-Mobilität: Wenn Ihre VMs in einem Pool ausgeführt werden und ihre Festplatten auf dem gemeinsam genutzten Speicher des Pools liegen, können diese VMs dynamisch zwischen XenServer-Hosts verschoben werden, während sie noch ausgeführt werden (Live-Migration). Wenn außerdem ein einzelner XenServer-Host einen Hardwarefehler erleidet, kann der Administrator ausgefallene VMs auf einem anderen XenServer-Host im selben Ressourcenpool neu starten.
- Hochverfügbarkeit Diese Funktion schützt die VMs in Ihrer Arbeitslast und stellt sicher, dass sie bei Hardware- oder Hostausfällen minimale Ausfallzeiten haben. Wenn Hochverfügbarkeit im Ressourcenpool aktiviert ist, können VMs automatisch auf einem anderen Host neu gestartet werden, wenn ihr Host ausfällt. Wenn der Pool-Koordinator ausfällt, wählt die Hochverfügbarkeit einen anderen Pool-Koordinator. Weitere Informationen finden Sie unter Hochverfügbarkeit.
- Workload-Balancing Workload-Balancing kann Ihren Ressourcenpool und die darauf ausgeführte VM-Arbeitslast bewerten, um die optimale Platzierung für Ihre VMs zu empfehlen. Sie können auch festlegen, dass Workload-Balancing seine Platzierungsempfehlungen automatisch befolgt und Ihre VMs zwischen Hosts im Pool migriert. Weitere Informationen finden Sie unter Workload-Balancing.
- Anti-Affinitäts-VM-Platzierung: Stellen Sie sicher, dass die VMs in einer Gruppe gleichmäßig auf die Hosts in einem Pool verteilt sind. Weitere Informationen finden Sie unter VM-Platzierung.
- Einfache Verwaltung: Anstatt jeden XenServer-Host einzeln zu verwalten, fügen Sie den Ressourcenpool zu XenCenter hinzu und verwalten Sie alle Hosts, SRs und VMs darin gemeinsam. Weitere Informationen finden Sie unter XenCenter.
Anforderungen für die Erstellung von Ressourcenpools
Beim Entwerfen Ihrer XenServer-Bereitstellung und bei der Entscheidung über Ihre Poolkonfiguration berücksichtigen Sie die folgenden Anforderungen:
Hardware-Anforderungen
Alle Server in einem XenServer-Ressourcenpool müssen weitgehend kompatible CPUs haben, das heißt:
-
Der CPU-Hersteller (Intel, AMD) muss auf allen CPUs auf allen Servern derselbe sein.
-
Bei allen CPUs muss die Virtualisierung aktiviert sein.
Je nachdem, wie ähnlich die CPUs sind, gehört der Pool zu einem der folgenden Typen:
-
Homogener Pool: Ein homogener Ressourcenpool ist ein Aggregat von Servern mit identischen CPUs. CPUs auf einem Server, der einem homogenen Ressourcenpool beitritt, müssen denselben Hersteller, dasselbe Modell und dieselben Funktionen aufweisen wie die CPUs auf Servern, die sich bereits im Pool befinden.
-
Heterogener Pool: Die Erstellung heterogener Pools wird durch die Verwendung von Technologien in Intel (FlexMigration) und AMD (Extended Migration) CPUs ermöglicht, die CPU-Maskierung oder Nivellierung bieten. Diese Funktionen ermöglichen es, eine CPU so zu konfigurieren, dass sie scheinbar eine andere Marke, ein anderes Modell oder einen anderen Funktionsumfang bietet, als sie tatsächlich hat. Diese Funktionen ermöglichen es Ihnen, Pools von Hosts mit unterschiedlichen CPUs zu erstellen und dennoch Live-Migrationen sicher zu unterstützen. Als Ergebnis dieser Funktionsmaskierung oder -nivellierung erhalten Sie möglicherweise nicht die volle Leistung Ihrer CPUs.
Anforderungen an den beitretenden Host
XenServer prüft, ob die folgenden Bedingungen für den Host, der dem Pool beitritt, erfüllt sind:
-
Er muss dieselbe Version von XenServer mit demselben Update-Level ausführen wie die Hosts, die sich bereits im Pool befinden.
-
Der beitretende Host ist kein Mitglied eines bestehenden Ressourcenpools.
-
Der beitretende Host hat keinen freigegebenen Speicher konfiguriert.
-
Der beitretende Host hostet keine laufenden oder angehaltenen VMs.
-
Es sind keine aktiven Vorgänge auf den VMs auf dem beitretenden Host im Gange, wie z. B. das Herunterfahren oder Exportieren einer VM.
-
Die Uhrzeit auf dem beitretenden Host ist mit der Uhrzeit des Pool-Koordinators synchronisiert (z. B. durch Verwendung von NTP).
-
Die Verwaltungsschnittstelle des beitretenden Hosts ist nicht gebündelt. Sie können die Verwaltungsschnittstelle konfigurieren, wenn der Host dem Pool erfolgreich beigetreten ist.
-
Die Verwaltungs-IP-Adresse des beitretenden Hosts ist statisch, entweder auf dem Host selbst konfiguriert oder durch eine entsprechende Konfiguration auf Ihrem DHCP-Server.
-
Die Verwaltungsschnittstelle des beitretenden Hosts befindet sich im selben getaggten VLAN wie die des Ressourcenpools.
-
Der beitretende Host muss mit denselben Zusatzpaketen in derselben Revision konfiguriert sein wie die bereits im Pool befindlichen Hosts.
-
Der beitretende Host muss dieselbe XenServer-Lizenz besitzen wie die bereits im Pool befindlichen Hosts. Sie können die Lizenz jedes Poolmitglieds nach dem Beitritt zum Pool ändern. Der Host mit der niedrigsten Lizenz bestimmt die für alle Mitglieder im Pool verfügbaren Funktionen.
Wenn Sie einen Host mithilfe von XenCenter zu einem Pool hinzufügen, stellt XenCenter sicher, dass dem beitretenden Host eine passende Lizenz zugewiesen wird. Wenn Sie jedoch einen Pool-Beitritt über die xe CLI durchführen, empfehlen wir Ihnen, dem Host vor dem Beitritt zum Pool eine passende Lizenz zuzuweisen.
-
Der beitretende Host muss sich am selben Standort wie der Pool befinden und über ein Netzwerk mit geringer Latenz verbunden sein.
Speicheranforderungen
Der vom Ressourcenpool genutzte gemeinsame Speicher hat folgende Anforderungen:
- Server, die gemeinsamen NFS- oder iSCSI-Speicher für den Pool bereitstellen, müssen eine statische IP-Adresse oder eine statische DHCP-Lease haben.
Empfohlene Poolgröße
Die angegebene Konfigurationsgrenze von 32 ist die maximale Anzahl von Hosts, die wir in einem Pool unterstützen. Dies ist jedoch keine empfohlene Poolgröße, da sie aus Management- oder Performance-Sicht für die meisten Workloads oft nicht optimal ist. Berücksichtigen Sie die folgenden Faktoren, wenn Sie die beste Größe für Ihre Bereitstellung festlegen:
-
Management-Überlegungen: Das meiste XenServer-Management wird auf Poolebene durchgeführt. Ein größerer Pool reduziert den Managementaufwand und ermöglicht es Ihnen, mehr Hosts zusammen zu verwalten. Einige Management-Operationen, z. B. das Anwenden von Updates auf einen Pool, können jedoch länger dauern, wenn Sie mehr Hosts haben, da die Operation sequenziell auf jedem Host im Pool ausgeführt werden muss. In diesem Fall benötigen Sie möglicherweise ein längeres Wartungsfenster, um bestimmte Operationen in einem großen Pool abzuschließen, als Sie für mehrere kleinere Pools benötigen.
-
Ressourcenfreigabe: Ein XenServer-Pool teilt typischerweise Ressourcen wie Speicher-Repositories zwischen Hosts. Ein größerer Pool ermöglicht es mehr Hosts, Ressourcen zu teilen, was Vorteile haben kann. Zum Beispiel können Sie in Ihrer Citrix Virtual Apps and Desktops™-Umgebung mehr Hosts haben, die ein Gold-Image teilen, anstatt mehrere Kopien auf verschiedenen Pools erstellen zu müssen. Die spezifischen Geräte, die Sie für Ihre gemeinsamen Ressourcen wählen, können jedoch bestimmte Performance-Überlegungen haben, die es besser machen, kleinere Host-Gruppierungen zu verwenden.
-
Control Plane-Performance: In einem XenServer-Pool werden alle Operationen vom Pool-Koordinator verwaltet. Die Last auf dem Toolstack dieses Hosts steigt, wenn Sie dem Pool weitere Hosts hinzufügen: Es gibt mehr Hintergrundaktivitäten von jedem Host und die erwartete Anzahl gleichzeitiger Operationen nimmt zu. Wenn die Last auf dem Toolstack steigt, erhöht sich wahrscheinlich die Zeit, die für jede Operation benötigt wird. Infolgedessen kann ein großer Pool merklich langsamer arbeiten als zwei kleinere Pools.
-
Fehlerisolation: Wenn XenServer oder eine andere für den Pool kritische Komponente (z. B. ein Speichergerät) ein Problem hat, kann dies in einem größeren Pool größere Auswirkungen auf Ihre Workloads haben, als wenn diese Workload auf mehrere kleinere Pools aufgeteilt ist.
-
GFS2-Speicher: Wenn Sie GFS2-Speicher für Thin Provisioning auf Blockspeicher verwenden, unterstützt XenServer maximal 16 Hosts. Dies liegt an Einschränkungen in der GFS2-Implementierung und dem erhöhten Kommunikationsbedarf zwischen den Hosts zur Verwaltung des Speichers.
-
Hochverfügbarkeit: Wenn Sie unsere Hochverfügbarkeitsfunktionalität zum Schutz Ihrer VMs verwenden, überwachen sich alle Hosts im Pool kontinuierlich gegenseitig und kommunizieren ihren Status. Wenn der Pool an Größe zunimmt, erhöht sich das Nachrichtenvolumen, das jeder Host im Rahmen dieser Überwachung senden und empfangen muss. Bei hoher Last auf der Steuerdomäne kann dies die Wahrscheinlichkeit erhöhen, dass einige dieser Überwachungsnachrichten verloren gehen. In extremen Szenarien können verlorene Nachrichten dazu führen, dass Hosts zur Sicherheit unerwartet abgeschottet werden. Bei Verwendung der Hochverfügbarkeitsfunktion empfehlen wir, kleinere Pools mit maximal 16 Hosts zu verwenden, um das Risiko einer unerwarteten Abschottung zu reduzieren.
Für die meisten Anwendungsfälle von Citrix Virtual Apps and Desktops empfehlen wir eine Poolgröße von 16 Hosts, mit einer maximalen Größe von 32.
Zusätzlich zur Berücksichtigung dieser Faktoren bei der Planung Ihrer Poolgröße sollten Sie das Verhalten Ihres Pools beobachten und überwachen, um festzustellen, ob Sie die Poolgröße in Ihrer laufenden Umgebung ändern müssen.
Kommunikation mit XenServer-Hosts und Ressourcenpools
TLS
XenServer verwendet das TLS 1.2-Protokoll zur Verschlüsselung des Management-API-Datenverkehrs. Jede Kommunikation zwischen XenServer und Management-API-Clients (oder Appliances) verwendet das TLS 1.2-Protokoll.
Wichtig:
Wir unterstützen keine Kundenmodifikationen an der kryptografischen Funktionalität des Produkts.
XenServer verwendet die folgenden Cipher Suites:
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH
Bei Verwendung eines SSH-Clients, um sich direkt mit dem XenServer-Host zu verbinden, können die folgenden Algorithmen verwendet werden:
Chiffren:
- aes128-ctr
- aes256-ctr
aes128-gcm@openssh.com- aes256-gcm@openssh.com
MACs:
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1
KexAlgorithms:
- curve25519-sha256
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
HostKeyAlgorithms:
- ecdsa-sha2-nistp256
- ecdsa-sha2-nistp384
- ecdsa-sha2-nistp521
- ssh-ed25519
- ssh-rsa
Wichtig:
Wir unterstützen keine kundenspezifischen Änderungen an der kryptografischen Funktionalität des Produkts. Wenn Sie jedoch den SSH-Zugriff auf einen XenServer-Host deaktivieren möchten, lesen Sie SSH-Zugriff für einen Host deaktivieren oder SSH-Zugriff für einen Pool deaktivieren.
Was passiert, wenn ein Host einem Ressourcenpool beitritt?
Wenn ein neuer Host einem Ressourcenpool beitritt, synchronisiert der beitretende Host seine lokale Datenbank mit der poolweiten Datenbank und übernimmt einige Einstellungen aus dem Pool:
-
Die Konfiguration von VM, lokalem und Remote-Speicher wird der poolweiten Datenbank hinzugefügt. Diese Konfiguration wird auf den beitretenden Host im Pool angewendet, es sei denn, Sie machen die Ressourcen explizit gemeinsam nutzbar, nachdem der Host dem Pool beigetreten ist.
-
Der beitretende Host übernimmt vorhandene gemeinsam genutzte Speicher-Repositories im Pool. Entsprechende PBD-Einträge werden erstellt, damit der neue Host automatisch auf vorhandenen gemeinsam genutzten Speicher zugreifen kann.
-
Netzwerkinformationen werden teilweise an den beitretenden Host vererbt: Die strukturellen Details von NICs, VLANs und gebündelten Schnittstellen werden alle vererbt, aber Richtlinieninformationen nicht. Diese Richtlinieninformationen, die neu konfiguriert werden müssen, umfassen:
-
Die IP-Adressen der Management-NICs, die aus der ursprünglichen Konfiguration beibehalten werden.
-
Der Speicherort der Managementschnittstelle, der derselbe bleibt wie in der ursprünglichen Konfiguration. Wenn beispielsweise die anderen Pool-Hosts Managementschnittstellen auf einer gebündelten Schnittstelle haben, muss der beitretende Host nach dem Beitritt zum Bond 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 verbunden werden, um den Datenverkehr entsprechend zu leiten. Dies liegt daran, dass IP-Adressen nicht als Teil des Pool-Beitrittsvorgangs 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 Netzwerkverwaltung.
-