Ressourcen-Pools
Ein -Ressourcenpool umfasst mehrere XenServer-Hostinstallationen, die zu einer einzigen verwalteten Einheit zusammengebunden sind, die virtuelle Maschinen hosten kann. In Kombination mit freigegebenem Speicher ermöglicht ein Ressourcenpool das Starten von VMs auf jegliche XenServer-Host, der über ausreichend Arbeitsspeicher verfügt.
Der -Poolkoordinator (früher „Poolmaster“) ist ein Server im Ressourcenpool, der eine Verwaltungsschnittstelle bereitstellt (verwendet von XenCenter und der XenServer-Befehlszeilenschnittstelle, bekannt als xe CLI). Der Poolkoordinator leitet bei Bedarf Kommandos an die einzelnen 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
Sie können Ihre XenServer-Hosts zwar als eigenständige Hosts organisieren, also effektiv als einen Pool aus einem Host, XenServer ist jedoch für Hosts optimiert, die in Ressourcenpools mit gemeinsam genutztem Speicher gruppiert sind. Einige unserer Funktionen, wie z. B. Hochverfügbarkeit und Livemigration, sind nur in Ressourcenpools mehrerer Hosts verfügbar. Die Organisation Ihrer XenServer-Hosts in Ressourcenpools bietet unter anderem folgende Vorteile:
- VM-Mobilität: Wenn Ihre VMs in einem Pool ausgeführt werden und ihre Festplatten sich im gemeinsam genutzten Speicher des Pools befinden, können diese VMs dynamisch zwischen XenServer-Hosts verschoben werden, während sie noch ausgeführt werden (Livemigration). Wenn bei einem einzelnen XenServer-Host ein Hardwarefehler auftritt, kann der Administrator außerdem ausgefallene VMs auf einem anderen XenServer-Host im selben Ressourcenpool neu starten.
- Hohe Verfügbarkeit Diese Funktion dient dem Schutz der VMs in Ihrer Arbeitslast und stellt sicher, dass sie bei Hardware- oder Hostfehlern nur minimale Ausfallzeiten haben. Wenn im Ressourcenpool Hochverfügbarkeit aktiviert ist, können VMs bei einem Hostausfall automatisch auf einem anderen Host neu gestartet werden. Wenn der Pool-Koordinator ausfällt, wählt die Hochverfügbarkeit einen anderen Pool-Koordinator. Weitere Informationen finden Sie unter Hohe Verfügbarkeit.
- Workload Balancing Workload Balancing kann Ihren Ressourcenpool und die darauf ausgeführte VM-Workload auswerten, um die optimale Platzierung für Ihre VMs zu empfehlen. Sie können auch festlegen, dass der Workload Balancing automatisch seinen Platzierungsempfehlungen folgt und Ihre VMs zwischen Hosts im Pool migriert. Weitere Informationen finden Sie unter Ausgleich der Arbeitsbelastung.
- 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 darin enthaltenen Hosts, SRs und VMs gemeinsam. Weitere Informationen finden Sie unter XenCenter.
Anforderungen für das Erstellen von Ressourcenpools
Berücksichtigen Sie beim Entwerfen Ihrer XenServer-Bereitstellung und bei der Entscheidung über Ihre Poolkonfiguration die folgenden Anforderungen:
Hardwareanforderungen
Alle Server in einem XenServer-Ressourcenpool müssen über weitgehend kompatible CPUs verfügen, das heißt:
-
Der CPU-Anbieter (Intel, AMD) muss bei allen CPUs auf allen Servern derselbe sein.
-
Auf allen CPUs muss die Virtualisierung aktiviert sein.
Abhängig von der Ähnlichkeit der CPUs handelt es sich bei dem Pool um einen der folgenden Typen:
-
Homogener Pool: Ein homogener Ressourcenpool ist eine Ansammlung von Servern mit identischen CPUs. CPUs auf einem Server, der einem homogenen Ressourcenpool beitritt, müssen den gleichen Anbieter, das gleiche Modell und die gleichen Funktionen aufweisen wie die CPUs auf Servern, die sich bereits im Pool befinden.
-
Heterogener Pool: Die Erstellung heterogener Pools wird durch den Einsatz von Technologien in Intel- (FlexMigration) und AMD-CPUs (Extended Migration) ermöglicht, die eine CPU- -Maskierung oder -Nivellierungbieten. Mit diesen Funktionen kann eine CPU so konfiguriert werden, dass sie erscheinen als Bereitstellung einer anderen Marke, eines anderen Modells oder eines anderen Funktionsumfangs, als dies tatsächlich der Fall ist. Diese Funktionen ermöglichen es Ihnen, Pools von Hosts mit unterschiedlichen CPUs zu erstellen, aber dennoch Live-Migrationen sicher zu unterstützen. Aufgrund dieser Funktionsmaskierung oder -nivellierung können Sie möglicherweise nicht die volle Leistung Ihrer CPUs nutzen.
Beitrittsvoraussetzungen für Hosts
XenServer überprüft, ob die folgenden Bedingungen für den Host erfüllt sind, der dem Pool beitritt:
-
Es muss dieselbe Version von XenServer auf demselben Patch-Level ausgeführt werden wie die Hosts, die sich bereits im Pool befinden.
-
Der beitretende Host ist kein Mitglied eines vorhandenen Ressourcenpools.
-
Für den beitretenden Host ist kein gemeinsam genutzter Speicher konfiguriert.
-
Der beitretende Host hostet keine laufenden oder angehaltenen VMs.
-
Auf den VMs auf dem beitretenden Host werden derzeit keine aktiven Vorgänge ausgeführt, z. B. das Herunterfahren oder Exportieren einer VM.
-
Die Uhr auf dem beitretenden Host wird auf die gleiche Zeit wie die des Pool-Koordinators synchronisiert (beispielsweise durch Verwendung von NTP).
-
Die Verwaltungsschnittstelle des beitretenden Hosts ist nicht gebunden. Sie können die Verwaltungsschnittstelle konfigurieren, wenn der Host erfolgreich dem Pool beitritt.
-
Die Verwaltungs-IP-Adresse des beitretenden Hosts ist statisch und wird entweder auf dem Host selbst oder durch Verwendung einer entsprechenden Konfiguration auf Ihrem DHCP-Server konfiguriert.
-
Die Verwaltungsschnittstelle des beitretenden Hosts befindet sich im selben getaggten VLAN wie die des Ressourcenpools.
-
Der beitretende Host muss mit denselben Zusatzpaketen und derselben Revision konfiguriert sein wie die Hosts, die sich bereits im Pool befinden.
-
Der beitretende Host muss über dieselbe XenServer-Lizenz verfügen wie die Hosts, die sich bereits im Pool befinden. Sie können die Lizenz aller Pool-Mitglieder ändern, nachdem Sie dem Pool beigetreten sind. Der Host mit der niedrigsten Lizenz bestimmt die Funktionen, die allen Mitgliedern im Pool zur Verfügung stehen.
Wenn Sie mithilfe von XenCenter einen Host zu einem Pool hinzufügen, stellt XenCenter sicher, dass auf den beitretenden Host eine passende Lizenz angewendet wird. Wenn Sie jedoch einen Poolbeitritt mithilfe der xe CLI durchführen, empfehlen wir Ihnen, dem Host eine passende Lizenz zuzuweisen, bevor Sie ihn dem Pool hinzufügen.
-
Der beitretende Host muss sich am selben Standort wie der Pool befinden und über ein Netzwerk mit geringer Latenz verbunden sein.
Speicheranforderungen
Für den vom Ressourcenpool verwendeten gemeinsam genutzten Speicher gelten die folgenden Anforderungen:
- Server, die gemeinsam genutzten NFS- oder iSCSI-Speicher für den Pool bereitstellen, müssen über eine statische IP-Adresse oder eine statische DHCP-Lease verfügen.
Empfohlene Poolgröße
Das aufgeführte Konfigurationslimit von 64 ist die maximale Anzahl von Hosts, die wir in einem Pool unterstützen. Es handelt sich jedoch nicht um eine empfohlene Poolgröße, da sie aus Verwaltungs- oder Leistungssicht für die meisten Workloads oft nicht die optimale Größe ist. Berücksichtigen Sie bei der Entscheidung über die optimale Größe für Ihre Bereitstellung die folgenden Faktoren:
-
Verwaltungsüberlegungen: Die meiste XenServer-Verwaltung wird auf Poolebene durchgeführt. Ein größerer Pool reduziert den Verwaltungsaufwand und ermöglicht Ihnen, mehr Hosts gemeinsam zu verwalten. Allerdings können einige Verwaltungsvorgänge, z. B. das Anwenden von Updates auf einen Pool, länger dauern, wenn Sie über mehr Hosts verfügen, da der Vorgang nacheinander auf jedem Host im Pool ausgeführt werden muss. In diesem Fall benötigen Sie zum Abschließen bestimmter Vorgänge in einem großen Pool möglicherweise ein längeres Wartungsfenster als für mehrere kleinere Pools.
-
Ressourcenfreigabe: Ein XenServer-Pool teilt normalerweise Ressourcen wie Speicherrepositorys zwischen Hosts. Ein größerer Pool ermöglicht es mehr Hosts, Ressourcen gemeinsam zu nutzen, was Vorteile haben kann. Beispielsweise können in Ihrer Citrix Virtual Apps and Desktops-Umgebung mehrere Hosts ein Gold-Image gemeinsam nutzen, anstatt mehrere Kopien in verschiedenen Pools erstellen zu müssen. Für die Geräte, die Sie für Ihre gemeinsam genutzten Ressourcen auswählen, gelten jedoch möglicherweise spezielle Leistungsaspekte. Daher empfiehlt sich die Verwendung kleinerer Hostgruppen.
-
Leistung der Steuerebene: In einem XenServer-Pool werden alle Vorgänge vom Pool-Koordinator verwaltet. Die Belastung des Toolstacks dieses Hosts erhöht sich, wenn Sie weitere Hosts zum Pool hinzufügen: Es gibt mehr Hintergrundaktivitäten von jedem Host und die erwartete Anzahl gleichzeitiger Vorgänge erhöht sich. Mit zunehmender Belastung des Tool-Stacks erhöht sich wahrscheinlich auch die für jeden Vorgang benötigte Zeit. Dies führt dazu, dass die Leistung eines großen Pools deutlich langsamer sein kann als die von zwei kleineren Pools.
-
Fehlerisolierung: Wenn bei XenServer oder einer anderen für den Pool wichtigen Komponente (z. B. einem Speichergerät) ein Problem auftritt, kann dies in einem größeren Pool größere Auswirkungen auf Ihre Arbeitslasten haben, als wenn diese Arbeitslast auf mehrere kleinere Pools aufgeteilt wird.
-
GFS2-Speicher: Wenn Sie GFS2-Speicher für Thin Provisioning auf Blockspeicher verwenden, unterstützt XenServer maximal 16 Hosts. Dies liegt an Einschränkungen bei der GFS2-Implementierung und dem erhöhten Kommunikationsbedarf zwischen Hosts zur Verwaltung des Speichers.
-
Hohe Verfügbarkeit: Wenn Sie zum Schutz Ihrer VMs unsere Hochverfügbarkeitsfunktion verwenden, überwachen sich alle Hosts im Pool kontinuierlich gegenseitig und kommunizieren ihren Status. Mit zunehmender Poolgröße erhöht sich das Nachrichtenvolumen, das jeder Host im Rahmen dieser Überwachung senden und empfangen muss. Bei hoher Belastung der Kontrolldomäne kann die Wahrscheinlichkeit steigen, dass einige dieser Überwachungsmeldungen verloren gehen. In Extremfällen können verloren gegangene Nachrichten dazu führen, dass Hosts aus Sicherheitsgründen unerwartet einen Zaun bilden. Wenn Sie die Hochverfügbarkeitsfunktion verwenden, empfehlen wir Ihnen, kleinere Pools mit maximal 16 Hosts zu verwenden, um das Risiko unerwarteter Einzäunungen zu verringern.
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.
Berücksichtigen Sie bei der Planung Ihrer Poolgröße nicht nur diese Faktoren, sondern beobachten und überwachen Sie auch das Verhalten Ihres Pools, um zu ermitteln, ob Sie die Poolgröße in Ihrer Laufumgebung ändern müssen.
Kommunizieren Sie mit XenServer-Hosts und Ressourcenpools
TLS
XenServer verwendet das TLS 1.2-Protokoll, um den Verwaltungs-API-Datenverkehr zu verschlüsseln. Für die Kommunikation zwischen XenServer und Management-API-Clients (oder Appliances) wird das TLS 1.2-Protokoll verwendet.
Wichtig:
Änderungen an der kryptografischen Funktionalität des Produkts durch Kunden werden nicht unterstützt.
XenServer verwendet die folgenden Verschlüsselungssammlungen:
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH
Wenn Sie einen SSH-Client verwenden, um eine direkte Verbindung zum XenServer-Host herzustellen, 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
KexAlgorithmen:
- Kurve25519-SHA256
- ECDH-SHA2-NISTP256
- ECDH-SHA2-NISTP384
- ECDH-SHA2-NISTP521
- diffie-hellman-gruppe14-sha1
HostKeyAlgorithms:
- ECDSA-SHA2-NISTP256
- ecdsa-sha2-nistp384
- ECDSA-SHA2-NISTP521
- ssh-ed25519
- ssh-rsa
Wichtig:
Änderungen an der kryptografischen Funktionalität des Produkts durch Kunden werden nicht unterstützt. Wenn Sie jedoch den SSH-Zugriff auf einen XenServer-Host deaktivieren möchten, lesen Sie Deaktivieren des SSH-Zugriffs für einen Host oder Deaktivieren des SSH-Zugriffs für einen Pool.
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 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.
-