XenServer® Enterprise-Referenzarchitektur

Übersicht

Diese Referenzarchitektur definiert einen empfohlenen Ansatz für den Entwurf, die Bereitstellung und den Betrieb von XenServer zur Unterstützung von Workloads im Unternehmensmaßstab. Sie bietet eine validierte Grundlage für das Hosten von Citrix Virtual Apps and Desktops™ (CVAD)-Umgebungen sowie für die allgemeine Servervirtualisierung, mit einem Fokus auf Skalierbarkeit, Ausfallsicherheit und betriebliche Einfachheit.

Die Architektur basiert auf dem Konzept des XenServer-Ressourcenpools als Kerneinheit für Skalierung und Verwaltung. Jeder Ressourcenpool ist für den Betrieb innerhalb eines einzelnen Rechenzentrums (oder einer Reihe eng verbundener Rechenzentren) konzipiert und unterstützt eine vorhersagbare, hochleistungsfähige Workload-Ausführung. Bereitstellungen können horizontal skaliert werden, indem zusätzliche Ressourcenpools hinzugefügt werden, um wachsenden Kapazitäts- und Organisationsanforderungen gerecht zu werden.

Designprinzipien

Die folgenden Prinzipien fassen den Designansatz zusammen:

• Ressourcenpool als Skalierungseinheit: Workloads innerhalb klar definierter Ressourcenpools bereitstellen und verwalten und horizontal durch Hinzufügen weiterer Pools skalieren
• Workload-Isolation nach Design: Ressourcenpools an spezifische Workload-Typen anpassen, um konsistente Leistung und operatives Verhalten zu gewährleisten
• N+1-Kapazitätsmodell: Ausreichende Kapazität vorhalten, um den Ausfall eines einzelnen Hosts zu tolerieren, ohne die Workload-Verfügbarkeit zu beeinträchtigen
• Trennung der Belange: Management-, VM- und Speicherverkehr klar trennen, um Leistung, Ausfallsicherheit und Sicherheit zu gewährleisten
• Explizite Resilienzstrategie: Resilienz innerhalb des Rechenzentrums und Disaster Recovery zwischen Rechenzentren als separate architektonische Belange behandeln
• Betriebliche Einfachheit: Optionale Funktionen nur dort einführen, wo sie einen klaren Mehrwert bieten, um unnötige Komplexität zu vermeiden

Zusammen bilden diese Prinzipien einen konsistenten Rahmen für den Entwurf von XenServer-Umgebungen, die skalierbar, ausfallsicher und einfach zu bedienen sind, während sie gleichzeitig an sich entwickelnde Workload- und Organisationsanforderungen anpassbar bleiben.

Diese Architektur geht von der Verwendung von Remote-Block-Speicher, integrierter Identitätsverwaltung über Active Directory und sicherer Verwaltung über TLS aus. Optionale Funktionen wie Workload Balancing (WLB), Hochverfügbarkeit (HA) und Disaster Recovery (DR) können je nach Workload-Anforderungen integriert werden, doch jede führt zu zusätzlichen betrieblichen Überlegungen, die explizit geplant werden müssen. Die Referenzarchitektur ist für Unternehmensumgebungen gedacht, die vorhersagbare Leistung und eine starke operative Kontrolle erfordern. Sie ist nicht für spezialisierte Szenarien wie sehr große einzelne VM-Festplatten (>2 TB) oder GPU-intensive Workloads optimiert, die möglicherweise alternative Designs oder Anpassungen erfordern.

Insgesamt dient dieses Dokument sowohl als Designleitfaden als auch als operatives Framework, das es Unternehmen ermöglicht, XenServer konsistent und unterstützbar bereitzustellen, während die Flexibilität erhalten bleibt, die Plattform im Laufe der Zeit zu erweitern und weiterzuentwickeln.

Annahmen und Umfang

Die Architektur basiert auf einer Reihe grundlegender Annahmen bezüglich Skalierung, Infrastruktur und Betriebsabläufen.

• Die gesamte verwendete Hardware muss in der XenServer Hardware Compatibility List (HCL) aufgeführt sein.

• Jeder Ressourcenpool soll bis zu 1.000 virtuelle Maschinen unterstützen, wobei die Gesamtbereitstellungen durch das Hinzufügen weiterer Pools skaliert werden, anstatt einen einzelnen Pool unbegrenzt zu erweitern, bis zu einem Maximum von 200 Pools. Es wird davon ausgegangen, dass alle Hosts innerhalb eines Pools innerhalb einer eng gekoppelten Netzwerkgrenze betrieben werden, um einen konsistenten und zuverlässigen Zugriff auf den gemeinsamen Speicher zu gewährleisten.
  • Hosts müssen über ausreichend RAM verfügen, um die erforderliche Arbeitslast und die Control Domain mit allen Anforderungen an die Performance-Zwischenspeicherung zu unterstützen (siehe Dimensionierung des Ressourcenpools), bis zu einem Maximum von 6 TB.
  • Hosts müssen entweder über lokalen Speicher für das XenServer-Betriebssystem (mindestens 46 GB, idealerweise 70 GB) oder die Möglichkeit zum Booten von SAN verfügen.

• Es wird davon ausgegangen, dass der Speicher über remote blockbasierte Systeme bereitgestellt wird, wobei XenServer LVM-basierte Speicher-Repositories verwendet. Effizienz und Ausfallsicherheit werden hauptsächlich durch die zugrunde liegende Speicherplattform bereitgestellt, einschließlich Funktionen wie Thin Provisioning zur Ermöglichung einer aktiven Zuweisung bei Nutzung und Multipathing. Eine kontinuierliche und zuverlässige Speicherkonnektivität ist eine kritische Anforderung.

• Die Vernetzung folgt einem Modell der strikten Trennung zwischen Management-, Virtual-Machine- und Speicherverkehr. Um dies zu erreichen, müssen Hosts mit mindestens 2 NICs und 2 Fibre-Channel-Verbindungen oder 4 NICs ausgestattet sein. Diese Trennung wird mit gebündelten Netzwerkschnittstellen kombiniert, um Ausfallsicherheit und Durchsatz zu gewährleisten und gleichzeitig Konfigurationen zu vermeiden, die unnötige Abhängigkeiten oder Leistungseinschränkungen einführen.

• Sicherheit und Identität werden als integraler Bestandteil des Designs behandelt. Die Management-Kommunikation wird mit TLS gesichert, und die Integration mit Active Directory wird für die Authentifizierung und rollenbasierte Zugriffskontrolle angenommen. Der administrative Zugriff soll den standardmäßigen Unternehmenssicherheitspraktiken folgen, mit eingeschränkter Nutzung lokaler Konten und kontrollierter Offenlegung von Managementschnittstellen.

• Operativ sind Ressourcenpools nach einem N+1-Kapazitätsmodell konzipiert, das es ermöglicht, dass Workloads während der Host-Wartung oder im Falle eines einzelnen Host-Ausfalls weiterlaufen. Updates und Upgrades sollen regelmäßig angewendet werden, um die Wartbarkeit und Sicherheit zu gewährleisten. Wo Disaster Recovery erforderlich ist, wird es als koordinierter operativer Prozess implementiert und nicht als nahtlose oder vollautomatische Failover-Funktion.

Optionale Funktionen können bei Bedarf integriert werden, werden aber nicht standardmäßig angenommen. Dazu gehören:

• Workload Balancing (WLB)
• Hochverfügbarkeit (HA) für Workloads
• Disaster Recovery (DR) über Rechenzentren hinweg

Jede dieser Funktionen führt zu zusätzlicher betrieblicher Komplexität und sollte auf der Grundlage klarer Workload- und Geschäftsanforderungen eingeführt werden.

Nicht im Umfang enthalten

Diese Referenzarchitektur ist nicht für alle Szenarien konzipiert und sollte nicht als Universallösung betrachtet werden. Insbesondere werden folgende Punkte nicht direkt behandelt:

• Workloads, die einzelne virtuelle Festplatten von mehr als 2 TB erfordern
• GPU-beschleunigte oder GPU-abhängige Workloads
• Architekturen, die eine nahtlose, aktiv-aktive Workload-Mobilität über geografisch verteilte Rechenzentren hinweg erfordern

In diesen Fällen können Elemente dieses Designs weiterhin anwendbar sein, es sind jedoch zusätzliche architektonische Überlegungen und Anpassungen erforderlich.

Definitionen

Begriffe und Definitionen zur Unterstützung des Lesens und Verständnisses dieser Referenzarchitektur.

Architektur-Blaupause

Die Erwartungen an Ressourcenpools sind wie folgt:

• Jeder Ressourcenpool ist für bis zu 1000 laufende VMs ausgelegt.
• Jeder Ressourcenpool befindet sich vollständig innerhalb eines einzelnen Rechenzentrums oder über nahe beieinander liegende Rechenzentren hinweg.
• Jeder Ressourcenpool ist für einen spezifischen Anwendungsfall vorgesehen, bei dem alle Workloads ähnliche Eigenschaften hinsichtlich Verfügbarkeit und Leistung aufweisen. Für kleine Bereitstellungen sind gemischte Anwendungsfälle möglich, es muss jedoch Vorsicht geboten sein, wenn die Lastverteilung und die Fehlermodi für die Ressourcenpools berücksichtigt werden.

Beispiele für einzelne Anwendungsfälle sind:

• Virtuelle Desktops für eine CVAD-Bereitstellung
• Anwendungsserver für eine CVAD-Bereitstellung
• CVAD-Infrastruktur
• Allgemeine Server-Virtualisierungs-Workloads

Jeder Ressourcenpool weist die folgenden Attribute auf

• LVM-Protokoll für alle Remote-Block-Speicher. Die Verwendung des GFS2-Protokolls wird nicht empfohlen.
• Hochverfügbarkeit für die Pool-Koordinator-Verwaltung
• Verwendung von TLS 1.2 für die gesamte Verwaltungskommunikation
• Optional: Workload Balancing (WLB) für Workload-VMs
• Optional: Hochverfügbarkeit (HA) von Workload-VMs
• Optional: Disaster Recovery (DR)
• Optional: XenServer Conversion Manager installiert

Hinweis:

Das Design kann skaliert werden, indem mehrere Ressourcenpools innerhalb von Rechenzentren oder über Rechenzentren hinweg erstellt werden, um die Workload dort bereitzustellen, wo sie benötigt wird.

Konfigurieren Sie jeden Ressourcenpool wie in den folgenden Abschnitten beschrieben.

Konfiguration des Core-Ressourcenpools

Beim Aufbau eines neuen Ressourcenpools ist es bewährte Praxis, einen eigenständigen Host mit der erforderlichen Netzwerk- und Speicherkonfiguration zu konfigurieren und dann weitere Hosts zu diesem Pool hinzuzufügen. Die zusätzlichen Hosts übernehmen die Konfiguration, sobald sie dem Ressourcenpool hinzugefügt werden.

Rollenbasierte Zugriffssteuerung konfigurieren

Verbinden Sie alle Ressourcenpools mit einer vertrauenswürdigen Active Directory-Domäne, um die einfache Verwaltung und Überprüfung von AD-Benutzern und -Gruppen zu ermöglichen und den Zugriff sowie die Berechtigungen für die XenServer-Ressourcenpools zu steuern.

Hinweis:

Verwenden Sie das Standardkonto (root) nicht für die Verwaltung, außer in Notfällen, in denen eine Authentifizierung über AD-Anmeldeinformationen nicht möglich ist (z. B. bei einem Ausfall des AD-Domänencontrollers).

Bereitstellung von Zertifikaten für Hosts

Alle Hosts in allen Ressourcenpools sollten über ein bereitgestelltes TLS-Zertifikat zur Verwendung im Verwaltungsnetzwerk verfügen. Für CVAD-Workloads müssen die Hosts über ihren FQDN im DNS auflösbar sein.

Allen Hosts muss ein Zertifikat bereitgestellt werden; dies kann ein gemeinsam genutztes Wildcard-Zertifikat oder ein Pro-Host-Zertifikat sein.

Hinweis:

Einige Anwendungen, die die XenServer-APIs verwenden, wie z. B. einige ältere Versionen von Citrix Apps and Desktops, erfordern die Verwendung eines individuellen Zertifikats für jeden Host und erlauben keine Wildcard-Zertifikate. Weitere Informationen finden Sie in der entsprechenden Dokumentation:

• DaaS
• CVAD 2507 und höher
• CVAD vor 2507

Alle Drittanbieterverbindungen zum Ressourcenpool sollten TLS und den FQDN verwenden, um die Hosts im Ressourcenpool anzusprechen.

Sicherung der Kommunikation zum Ressourcenpool

• Port 80 deaktivieren
• Stellen Sie SSH auf den Modus Auto ein, damit SSH bei einem Ausfall des Management-Toolstacks automatisch aktiviert wird.

Netzwerkkonfiguration des Ressourcenpools

Für die folgenden Netzwerke ist eine Trennung erforderlich:

• Management-Netzwerk
• VM-Netzwerk
• Speichernetzwerk (bei Verwendung von netzwerkbasiertem Speicher)

Diese Trennung kann durch separate NICs oder durch die Verwendung von VLANs mit denselben NICs erfolgen. Bei der Verwendung von netzwerkbasiertem Speicher wird dringend empfohlen, aus Leistungsgründen separate NICs zu verwenden.

Management- und VM-Netzwerke

Die Management- und VM-Netzwerke sollten auf gebündelten NICs betrieben werden, um Ausfallsicherheit und Durchsatz zu gewährleisten.

Die Bonds sollten, wo immer möglich, als LACP-Bonds konfiguriert werden, um die beste Reaktion auf Konnektivitätsverluste zu gewährleisten und gleichzeitig die Bandbreitenverfügbarkeit zu maximieren. Dies erfordert, dass die Switches in einer passenden Konfiguration eingerichtet werden. Wenn die Switches nicht für LACP konfiguriert werden können, ist Active-Active für VM-Netzwerke vorteilhaft. Management-Netzwerke können Active-Passive ohne Auswirkungen verwenden. Weitere Informationen finden Sie unter Bonding-Typen.

Wo immer möglich, sollten die Switches mit den NICs querverbunden werden, um sicherzustellen, dass es keinen Single Point of Failure im Netzwerktransport gibt, und sie sollten separate Stromquellen oder redundante Versorgungen verwenden. Vollständige Details finden Sie unter Best Practices für Netzwerke.

Alle Hosts im Pool müssen feste IP-Adressen im Management-Netzwerk haben; XenServer unterstützt das Szenario nicht, in dem sich die vom DHCP zugewiesene Host-IP-Adresse ändert. Wenn feste DHCP-Adressen verwendet werden, sollte erwartet werden, dass die DHCP-Umgebung zuverlässig verfügbar ist (z. B. als Teil der Netzwerkinfrastruktur) und nicht von einer VM bereitgestellt werden sollte, die auf einem Host läuft, der von diesem DHCP-Server abhängt. Für die Infrastruktur wird eine statische Adressierung empfohlen.

Alle Host-Management-Netzwerke müssen eine Verbindung zu synchronisierten NTP-Servern zulassen, um sicherzustellen, dass ihre Uhren synchron bleiben; dies sollte dieselbe Zeitquelle sein, die auch für das Active Directory verwendet wird, das die Computer- und Benutzerkonten für die rollenbasierte Zugriffssteuerung bereitstellt, um sicherzustellen, dass keine Taktverschiebung auftritt und die Kommunikationswege unterbrochen werden. Dies stellt auch sicher, dass für alle Systemprotokolle konsistente Zeitstempel vorhanden sind.

Die vollständigen Konnektivitätsanforderungen, die für den Betrieb der Umgebung erforderlich sind, sind hier aufgeführt.

Speichernetzwerke

Bei der Verwendung von netzwerkbasiertem Speicher ist es bewährte Praxis, Multipath-Unterstützung vom Speicher zu nutzen, was unabhängige Netzwerke (d.h. verschiedene Subnetze) erfordert. Dies bedeutet typischerweise die Verwendung einzelner NICs anstelle von Bonds und die Konfiguration geeigneter Subnetze auf jedem. Konsultieren Sie Ihren Speicheranbieter für weitere Empfehlungen.

Speicherkonfiguration des Ressourcenpools

Multipathing sollte aktiviert sein. Dies muss auf allen Hosts einzeln eingestellt werden, und es sollten mindestens 2 Pfade für alle Speicherressourcen verfügbar sein. Diese Pfade sollten über die Netzwerk-/Fibre-Channel-Infrastruktur hinweg diversifiziert sein.

LVM ist ein Thick-Provisioning-Speicher, daher benötigt XenServer die volle Speichermenge für die erstellten VM-Datenträger. Dies bedeutet, dass jeder Datenträger und jede Vorlage die gesamte verfügbare Kapazität belegt, selbst wenn nur kleine Teile dieser Datenträger verwendet werden.

Es wird empfohlen, SANs zu verwenden, die ihre eigene Thin-Provisioning-Funktion bereitstellen, um eine effiziente Speichernutzung zu gewährleisten. Das SAN-Thin-Provisioning nutzt den verfügbaren Speicher besser aus, indem es VDIs Speicherplatz zuweist, wenn Daten auf den virtuellen Datenträger geschrieben werden, anstatt die volle virtuelle Größe des VDI im Voraus zuzuweisen. Die genutzte Speichermenge sollte vom Administrator sorgfältig mit den vom SAN-Anbieter bereitgestellten Tools überwacht werden.

Wenn Thin Provisioning auf dem SAN verwendet wird, ist die Überwachung der Speicherauslastung wichtig; wenn die SAN-Kapazität erschöpft ist, sodass keine weiteren Schreibvorgänge möglich sind, kann dies zu VM-Ausfällen und/oder Datenkorruption führen.

Wenn MCS zur Bereitstellung von Workloads für Citrix®-Umgebungen verwendet wird, wird empfohlen, eine kleine Anzahl großer LUNs dafür zu verwenden, da das Golden Image auf alle LUNs kopiert werden muss, was langsam sein kann und die Image-Bereitstellung erheblich verlängert, wodurch die Bereitstellung aktualisierter Images verzögert wird.

Resilienzstrategie

XenServer-Ressourcenpools werden zusammen mit ihren Speicherressourcen in einem einzigen Rechenzentrum (oder innerhalb einer Sammlung von Rechenzentren in unmittelbarer Nähe) betrieben.

Diese Ressourcenpools können so konfiguriert werden, dass sie gegen lokale Server-, Speicher- und Netzwerkausfälle innerhalb des Rechenzentrums resilient sind. Darüber hinaus können Ressourcenpools in Kombination verwendet werden, um Funktionen zur Notfallwiederherstellung bereitzustellen, falls ein Rechenzentrum ausfällt und zum Verlust eines gesamten Ressourcenpools führt.

Diese werden im Folgenden separat betrachtet.

Resilienz innerhalb eines Rechenzentrums

Während Workloads innerhalb eines Rechenzentrums durch eine vollständige DR-Konfiguration, wie unten beschrieben, geschützt werden können, gibt es Mechanismen zur Resilienz innerhalb jedes Ressourcenpools, um eine hohe Verfügbarkeit der Ressourcen zu gewährleisten. Diese Mechanismen sind so konzipiert, dass sie automatisiert und häufiger eingesetzt werden, um vor häufigeren und lokalisierten Problemen zu schützen. Die folgenden Funktionen sind verfügbar:

• Management-Hochverfügbarkeit (durch automatisierte Koordinatorwahlen bei ungeplanten Ausfällen)
• Workload-Compute-Hochverfügbarkeit (durch automatischen VM-Neustart bei ungeplanten Ausfällen)
• Speicherresilienz (durch Speichermultipathing)
• Netzwerkresilienz (durch Netzwerk-Bonding und Switch-Konfigurationen)

Um dies zu erreichen, wird erwartet, dass der Ressourcenpool mit mindestens N+1 Hosts betrieben wird, wobei N die Anzahl der Hosts ist, die für den Betrieb der Workload erforderlich sind. Dies ermöglicht den Betrieb des Ressourcenpools mit voller Kapazität, auch wenn ein Host nicht verfügbar ist.

Hinweis:

Die N+1 Host-Kapazität ermöglicht die Aktualisierung und das Upgrade von Ressourcenpools ohne Workload-Ausfallzeiten, was die einfache Anwendung von Sicherheitsupdates und Funktionserweiterungen erlaubt.

Diese Funktionen bieten eine hochresiliente Bereitstellung, die vollständig innerhalb eines Rechenzentrums oder über nahe beieinander liegende Rechenzentren betrieben wird. Sie unterstützen keine Resilienz über geografisch verteilte Rechenzentren hinweg. Die einzige Möglichkeit, dies zu unterstützen, ist die unten beschriebene DR-Funktion (siehe Resilienz über Rechenzentren).

Optionale Funktionen

Workload-Balancing (WLB)

• Verwenden Sie, wenn: VM-Workloads während ihrer Laufzeit wesentlich unterschiedliche und zeitlich variierende Auslastungsmuster aufweisen und Sie automatisierte Empfehlungen und/oder einen Neuausgleich zur Aufrechterhaltung der Leistung wünschen.
• Vermeiden Sie, wenn: Workloads sehr einheitlich sind (z. B. viele ähnliche nicht-persistente VDI-VMs), bei denen die anfängliche Platzierung und normale Lebenszyklusoperationen bereits ein ausreichendes Gleichgewicht bieten, oder wenn Migrationen betrieblich unerwünscht sind.
• Betriebliche Auswirkungen: Fügt eine zusätzliche Appliance hinzu, die betrieben und überwacht werden muss; beinhaltet ein tägliches Wartungsfenster, während dessen die WLB-Verarbeitung nicht verfügbar ist.

WLB kann verwendet werden, um die beste Host-Auslastung und Leistung aufrechtzuerhalten, wenn sich die Workload-Nutzung im Laufe der Zeit ändert.

Importieren Sie die Appliance in den Ressourcenpool und verwenden Sie das Management-Netzwerk für deren Konnektivität. Die Workload Balancing (WLB)-Appliance kann von der XenServer-Downloadseite heruntergeladen werden.

Die Standardgröße für die Appliance (2 GB RAM, 30 GB Festplatte und 2 vCPUs) sollte verwendet werden.

Workload-Eignung

WLB sollte nur dann erforderlich sein, wenn sich die Workload-Nachfrage innerhalb von VMs während ihrer Laufzeit dynamisch ändert. Wenn WLB verwendet wird, wird eine VM jedes Mal, wenn sie gestoppt und wieder gestartet wird, sofort optimal für die aktuelle Workload platziert, sodass VMs nur dann verschoben werden müssen, wenn sich die Host-Auslastung ändert. Wenn der Anwendungsfall viele ähnliche VMs bereitstellt, die alle ähnliche Aufgaben ausführen, ist der Einsatz von WLB von geringem Wert, und Sie können sich auf die anfängliche VM-Platzierung verlassen, um den Workload-Ausgleich zu gewährleisten.

Datenbank-Wartungsfenster anpassen

Die WLB-Appliance führt täglich routinemäßige Wartungsarbeiten durch. Standardmäßig ist dies um 00:05 UTC. Dies sollte so konfiguriert werden, dass es bei geringer Aktivität im Ressourcenpool stattfindet, da es während dieses Prozesses zu einem WLB-Verarbeitungsausfall von bis zu 30 Minuten kommen wird. Dies beeinträchtigt nicht den normalen Betrieb, sondern nur Entscheidungen zur Platzierungsoptimierung; WLB wird Aktionen abschließen, sobald die Wartung abgeschlossen ist.

WLB-Parameterkonfiguration

Viele Konfigurationseinstellungen können als Standardwerte belassen werden. Dadurch wird die WLB-Funktion so eingerichtet, dass sie Empfehlungen an einen Administrator gibt, und der Administrator muss diese Aktionen anwenden.

Die Standard- und erwartete Konfiguration für diesen Blueprint erfordert lediglich die Anpassung der „Kritischen Schwellenwerte“ und Gewichtungen, um den Ressourcenpools den Betrieb mit maximaler Leistung zu ermöglichen. Diese können durch Nutzung optimiert werden, aber einige vorgeschlagene Startwerte sind wie folgt:

• CPU-Auslastung: Der Standardwert hierfür ist ein kritischer Schwellenwert von 90 % mit einer maximalen Gewichtung. Dies stellt sicher, dass, sobald eine Host-CPU über die letzten 1,5 Minuten eine durchschnittliche Auslastung von 90 % erreicht, der WLB-Dienst alternative Standorte für die Ausführung von VMs bewertet.

  • Wenn die Leistung Ihrer VMs bei geringerer CPU-Auslastung beeinträchtigt wird, können Sie diesen kritischen Schwellenwert anpassen, um die durchschnittliche CPU-Auslastung auf den Hosts möglichst niedrig zu halten.
  • Empfohlener anfänglicher kritischer Schwellenwert: 90%
  • Empfohlener anfänglicher Metrik-Gewichtungswert: Am wichtigsten
• Freier Speicher: Es gibt keine spezifische Leistungssteigerung, die durch das Freihalten von Speicher auf Hosts erzielt werden kann, daher ist das Migrieren von Maschinen, um Speicher freizuhalten, ein nicht erforderlicher Overhead.
  • Empfohlener anfänglicher kritischer Schwellenwert: 0
  • Empfohlener anfänglicher Metrik-Gewichtungswert: Am unwichtigsten
• Netzwerk-Lese- und Schreibvorgänge: Die Standardwerte hierfür sind 25 MB/s. Dies bedeutet, dass, wenn ein Host mehr Bandbreite für Lese- oder Schreibvorgänge nutzt, er für eine Neuplatzierung in Betracht gezogen wird. Dieser Parameter ist nur relevant, wenn Sie VMs mit hoher Netzwerkauslastung betreiben und die Vermeidung von Auswirkungen auf andere VMs relevant ist.
  • Für viele Anwendungen ist dies kein relevanter Faktor, und die Gewichtung sollte auf die unwichtigste Einstellung gesetzt werden.
  • Für viele moderne Netzwerke ist dies ein sehr niedriger Wert, und wenn diese Einstellung relevant ist, empfehlen wir, sie so einzustellen, dass diese Bandbreitennutzung gut genutzt werden kann, bevor eine Migration zu einem anderen Host in Betracht gezogen wird.
  • Empfohlener anfänglicher kritischer Schwellenwert: 90 % der verfügbaren Bandbreite
  • Empfohlener anfänglicher Metrik-Gewichtungswert: Mittlere Wichtigkeit
• Festplatten-Lese- und Schreibvorgänge: Die Standardwerte hierfür sind 25 MB/s. Dies bedeutet, dass, wenn ein Host mehr Bandbreite für Lese- oder Schreibvorgänge nutzt, er für eine Neupositionierung in Betracht gezogen wird. Dieser Parameter ist nur relevant, wenn Sie VMs mit hoher Festplattenauslastung betreiben und die Auswirkungen auf andere VMs vermieden werden sollen. Wenn Remote-Speicher verwendet wird, ist dies von keinem Wert, es sei denn, die Bandbreite des Fabrics ist der Engpass, da jede Auswirkung auf den Remote-Speicher die Leistung aller VMs beeinträchtigt, die diesen Speicher nutzen, unabhängig vom Host, auf dem sie betrieben werden.
  • Für die meisten modernen Speicher und Fabrics ist dies ein niedriger Wert, und wenn diese Einstellung relevant ist, sollte sie auf einen höheren Wert gesetzt werden, um eine gute Nutzung der Bandbreite zu ermöglichen. Dies sollte hoch genug eingestellt werden, damit regelmäßige Wartungsarbeiten außerhalb der Geschäftszeiten an VMs keine Massenmigration auslösen, wenn dies nicht erforderlich ist.
  • Empfohlener anfänglicher kritischer Schwellenwert: 90 % der verfügbaren Bandbreite
  • Empfohlener anfänglicher Metrik-Gewichtungswert: Mittlere Wichtigkeit

Hochverfügbarkeit (HA) für den Ressourcenpool

Die vollständige HA-Dokumentation ist hier verfügbar.

Für XenServer sind bezüglich Hochverfügbarkeit 2 Elemente zu berücksichtigen:

• Management-HA: Die Fähigkeit, Management-Operationen automatisch aufrechtzuerhalten, wenn es zu einem unerwarteten Ausfall des Koordinator-Hosts im Ressourcenpool kommt
• VM-HA: Die Fähigkeit, Workload-Operationen aufrechtzuerhalten, wenn es zu einem unerwarteten Ausfall eines Hosts im Ressourcenpool kommt

Beide Aspekte erfordern spezifische Speicher- und Netzwerkkonfigurationen. Dies wird in den folgenden Abschnitten behandelt.

Eine der verfügbaren Speicher-LUNs wird als XenServer Heartbeat SR ausgewählt (siehe Heartbeats für Verfügbarkeit für eine vollständige Erklärung dieser Anforderung). Wenn mehr als eine LUN verfügbar ist, spielt es keine Rolle, welche ausgewählt wird. Ein kleiner Speicherplatz (<5 GB) wird von dieser LUN zugewiesen, um die HA-Funktion bereitzustellen.

Diese Referenzarchitektur ist darauf ausgelegt, die Aufrechterhaltung der Workload innerhalb der Grenzen des unerwarteten Verlusts eines einzelnen Hosts zu unterstützen. Die Einstellung „Tolerierbare Fehler“ sollte auf 1 gesetzt werden.

Hinweis:

Bei der Verwendung von HA ist es wichtig, die folgenden Merkmale zu beachten:

• Der Ressourcenpool muss mindestens 3 Hosts umfassen
• Fencing bezieht sich auf den Mechanismus, der einen Host, der als fehlerhaft oder unsicher eingestuft wird, zwangsweise isoliert, um sicherzustellen, dass er nicht auf gemeinsam genutzte Ressourcen (insbesondere gemeinsam genutzten Speicher) zugreifen kann, bevor virtuelle Maschinen an anderer Stelle neu gestartet werden. Je größer der Ressourcenpool, desto größer ist die Auswirkung des Host-Fencing und desto wahrscheinlicher ist es, dass es aufgrund der Anforderungen an den Kommunikationspfad auftritt. Pools mit >16 Hosts sollten in dieser Hinsicht sorgfältig berücksichtigt werden.
• HA sollte während Wartungsarbeiten am Host / Ressourcenpool deaktiviert werden, um das Risiko unerwarteter Ausfälle während dieser Wartungsaktivitäten zu reduzieren.
• Bei der Verwendung von HA ist darauf zu achten, dass die Speicherverbindung zum HA-Statusdateispeicher-SR und die Netzwerkverbindung nicht unterbrochen werden. Eine Unterbrechung dieser Verbindungen kann dazu führen, dass Hosts unerwartet abgeschottet werden, um den Betrieb des Ressourcenpools zu schützen. Dies bedeutet, dass bei der Durchführung von Wartungsarbeiten an der Infrastruktur sorgfältig vorgegangen werden muss, um sicherzustellen, dass die Konnektivität nicht verloren geht.

Alternative Ansätze für Management-HA

Wenn Sie HA verwenden, um eine zuverlässige, hochverfügbare Management-Konnektivität bereitzustellen, sollten auch die folgenden Ansätze in Betracht gezogen werden, um die oben genannten Einschränkungen zu vermeiden.

Host-Überwachung implementieren

Integrieren Sie XenServer-Hosts in eine Überwachungslösung eines Drittanbieters, um zu erkennen, wann ein Host nicht reagiert.

Management-Konnektivität manuell wiederherstellen

Wenn der nicht erreichbare Host der Koordinator ist und Management-Operationen nicht verfügbar sind, wechseln alle anderen Hosts im Ressourcenpool in den Notfallmodus und ermöglichen die Herstellung einer Remote-Verbindung zu ihnen, um einen von ihnen als neuen Pool-Koordinator zu wählen. Dies kann mithilfe der Remote-Sprachbindungen durchgeführt werden. Beispiele sind unten für xe CLI und PowerShell aufgeführt.

xe CLI:

xe -s <server_IP> -u <username> -pw <password> host-is-in-emergency-mode                     -> Confirm election possibility
xe -s <server_IP> -u <username> -pw <password> pool-emergency-transition-to-master           -> Designate current host as new master
xe -s <server_IP> -u <username> -pw <password> pool-recover-slaves                           -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

PowerShell:

Invoke-XenPool -XenAction EmergencyTransitionToMaster          -> Designate current host as new master
Invoke-XenPool -XenAction RecoverSlaves                        -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

VM-HA

Workload Balancing (WLB) VM

Diese VM sollte die Neustartpriorität auf „Neustart“ gesetzt haben, um sicherzustellen, dass keine WLB-Funktionen nach einem unerwarteten Ausfall verloren gehen. Sie sollte in der ersten Startgruppe 0 sein.

Andere VMs

Je nach genauer Nutzung von XenServer können zusätzliche VMs für die Verwendung von VM HA konfiguriert werden. Im Folgenden finden Sie Vorschläge für einige Anwendungsfälle.

Entscheidungshilfe (VM HA): Verwenden Sie VM HA für Workloads, bei denen ein automatischer Neustart nach einem unerwarteten Hostausfall die Servicekontinuität wesentlich verbessert und bei denen der Pool N+1 dimensioniert ist, um den Ausfall zu absorbieren. Vermeiden Sie VM HA für Workloads, bei denen externes Brokering/Orchestrierung bereits Neustart- oder Scale-out-Verhalten bietet (z. B. viele nicht-persistente CVAD-Workloads), oder bei denen die Neustartreihenfolge und Abhängigkeiten schwer zu kontrollieren sind.

Hinweis:

VMs, die dem Ressourcenpool hinzugefügt werden, nachdem HA konfiguriert wurde, werden standardmäßig auf „Nicht neu starten“ gesetzt. Die HA muss neu konfiguriert werden, nachdem VMs zur Umgebung hinzugefügt wurden, falls erforderlich.

• PVS- und nicht-persistente MCS-VMs: Konfigurieren Sie diese VMs nicht mit HA. Stellen Sie sicher, dass diese auf Do Not Restart eingestellt sind. Andere VMs sollten verfügbar sein, um Endbenutzern sofortige Dienste bereitzustellen, und Citrix Virtual Apps and Desktops bietet Energieverwaltungsfunktionen, um den Neustart dieser VMs zu unterstützen, entweder wenn ein Endbenutzer dies benötigt oder durch Auto-Scale-Funktionen, um die erwartete Nachfrage zu unterstützen, siehe AutoScale. Dies führt zu einem optimierteren Ergebnis für die kombinierte Citrix-Umgebung.

• MCS persistente VMs: Diese sollten auf „Neustart“ eingestellt sein. Die zu entwerfende Konfiguration sollte sicherstellen, dass genügend RAM und CPU verfügbar sind, um alle VMs im Pool zu betreiben, wenn 1 Host außer Betrieb ist (für Update, Wartung oder Ausfall), sodass diese Konfiguration möglich ist.

• Allgemeine Servervirtualisierungs-Workloads (alle Workloads, die nicht zum Ausführen von Citrix VDAs verwendet werden): Diese sollten auf „Neustart“ eingestellt sein. Die zu entwerfende Konfiguration sollte sicherstellen, dass genügend RAM und CPU verfügbar sind, um alle VMs im Pool zu betreiben, wenn 1 Host außer Betrieb ist (für Update, Wartung oder Ausfall), sodass diese Konfiguration möglich ist. Die VMs können so konfiguriert werden, dass sie die Startgruppen und Verzögerungen nach Bedarf verwenden, um sicherzustellen, dass der Workload wie erforderlich neu gestartet wird. Dies könnte verwendet werden, um Workloads zu priorisieren, von denen andere Dienste abhängen, wie z. B. Active Directory, DHCP- und DNS-Dienstanbieter.

Ausfallsicherheit über Rechenzentren hinweg

Optional:

Disaster Recovery (DR) über Rechenzentren hinweg. Diese Referenzarchitektur kann bei Bedarf DR unterstützen, mit zusätzlichen Design- und Betriebsüberlegungen.

Entscheidungshilfe für DR

• Verwenden Sie, wenn: Sie eine definierte Geschäftsanforderung für Standortausfallsicherheit, eine replikationsfähige Speicherplattform und vereinbarte Wiederherstellungsverfahren (RPO/RTO) haben, die eine VM-Wiederherstellung an einem sekundären Standort erfordern.
• Vermeiden Sie dies, wenn: Sie häufige Workload-Mobilität zwischen Standorten benötigen oder nicht über die betriebliche Kapazität verfügen, Failover-/Failback-Prozesse zu testen und auszuführen. Gehen Sie bei CVAD nicht davon aus, dass die Hypervisor-Konnektivität und -Zertifikate ohne ein koordiniertes CVAD DR-Design nahtlos ein Failover durchführen.
• Betriebliche Auswirkungen: DR ist nicht vollständig automatisiert; Failover/Failback erfordert geplante Runbooks, Zugriff auf Speicherreplikationskontrollen und regelmäßige Tests.

Die hier beschriebene XenServer Disaster Recovery (DR)-Konfiguration ist ein Resilienzmodus, der voraussichtlich selten zur Unterstützung extremer und ungeplanter Infrastrukturausfälle eingesetzt wird. Dieser Vorgang ist nicht automatisiert, und die Wiederherstellung erfordert sorgfältige Planung und Durchführung. Das DR-Modell ermöglicht den Betrieb von Workloads an einem temporären Standort, der möglicherweise keine optimale Platzierung darstellt, aber den kritischen Geschäftsbetrieb während eines Ausfallzeitraums unterstützt.

Das XenServer DR-Modell ist eine komplexe Lösung, und es gibt andere Möglichkeiten, Schutz vor Standortausfällen zu bieten. Bei Citrix-Workloads, bei denen nicht-persistente VMs zur Bereitstellung von Diensten verwendet werden, können beispielsweise zusätzliche VMs in Wiederherstellungsstandorten bereitgestellt werden, um temporäre Dienste bereitzustellen. Diese Optionen müssen vor der Verwendung der XenServer DR-Funktion in Betracht gezogen werden, da sie möglicherweise einfacher zu implementieren sind.

Es wird empfohlen, DR für Citrix VDI-Workloads zu vermeiden, es sei denn, Sie verfügen über eine geeignete DR-Lösung für CVAD. Es ist nicht sicher anzunehmen, dass dieselbe Hypervisor-Verbindung auf einen XenServer DR-Standort ausfallen kann, da Netzwerk- und Zertifikatszuordnungen dies unzuverlässig machen können.

Um das Risiko eines Rechenzentrumsausfalls und des Verlusts des Workloads (oder kritischer Teile des Workloads) zu mindern, kann ein sekundärer Rechenzentrumsstandort für Disaster-Recovery-Funktionen genutzt werden. Weitere Dokumentation finden Sie hier.

Ein oder mehrere Ressourcenpools am DR-Standort können zusätzlich zur Wiederherstellung von Workloads auch für andere Workloads verwendet werden, aber Sie müssen die erforderliche freie Kapazität aufrechterhalten, um die zusätzlichen Workloads bei Bedarf ausführen zu können.

Es ist nicht erforderlich, dass der gesamte Workload im DR-Standort betrieben wird, wenn ein Ausfallereignis auftritt. Teil-Workloads können wiederhergestellt werden, bis der vollständige Betrieb am primären Standort wiederhergestellt ist. Es besteht jedoch die Anforderung, dass Workloads von einem Ressourcenpool in einen einzigen Wiederherstellungs-Ressourcenpool wiederhergestellt werden müssen. Workloads können nicht auf mehrere Wiederherstellungspools verteilt werden.

Wichtig:

Der Speicherreplikationsprozess, der die Daten von LUN(s) am primären Standort zum DR-Standort spiegelt, muss außerhalb des XenServer-Toolsets konfiguriert werden, und die Neukonfiguration muss dem Administrator zur Verfügung stehen, der für das Failover verantwortlich ist, da dieser das Mirroring im Rahmen der Vorgänge im Zusammenhang mit diesem Prozess unterbrechen und zurücksetzen muss (Einzelheiten siehe Abschnitt „Vorgänge“).

Beim Aufbau dieser Bereitstellung:

• Der gesamte Speicher, der für die virtuellen VM-Festplatten verwendet wird, muss von der primären Umgebung in die Backup-Umgebung repliziert werden.
• Der gesamte Speicher, der für Pool-Metadaten verwendet wird, muss von der primären Umgebung in die Backup-Umgebung repliziert werden.
• Die Hardware-Infrastruktur an Ihrem DR-Standort muss nicht mit dem primären Standort übereinstimmen, muss aber denselben Prozessorhersteller verwenden. Im Standby-Ressourcenpool muss ausreichend Speicher, CPU und Netzwerkkapazität konfiguriert sein, um alle erforderlichen ausgefallenen VMs neu erstellen und starten zu können.
• Der XenServer-Ressourcenpool am Wiederherstellungsstandort muss dieselbe oder eine neuere Release- und Patch-Ebene als der primäre Standort aufweisen (siehe XenServer-Versionsverwaltung über Bereitstellungen hinweg für Details, wie dies erreicht werden kann).

Betriebsmodell

XenServer-Versionsverwaltung über Bereitstellungen hinweg

XenServer-Bereitstellungen bestehen aus einem oder mehreren Ressourcenpools, die sich über ein oder mehrere Rechenzentren erstrecken, um eine skalierbare, robuste und sichere Bereitstellung zu gewährleisten, die leistungsstarke Workloads in großem Umfang liefern kann.

Diese Bereitstellungen können Test- und Produktionsumgebungen bereitstellen, und es kann ein Workflow erstellt werden, um Änderungen über diese Umgebungen auszurollen.

Optional:

Die Phasen des Host-Tests und des Workload-Tests sind optional. Die Referenzarchitektur unterstützt den Betrieb mit oder ohne diese Phasen.

Die Phasen des Host-Tests und des Workload-Tests müssen nicht getrennt sein; sie können kombiniert werden. Dies kann vorteilhaft sein, da es die Zeit verkürzt, die benötigt wird, um Änderungen in die Produktion zu bringen. Der XenServer-Update-Stream ist robust und vollständig getestet, was eine kontinuierliche Bereitstellung ermöglicht. Um Sicherheit, Robustheit und Leistung zu gewährleisten, ist es wichtig, die Zeit zu minimieren, die Updates benötigen, um die Produktion zu erreichen.

Die Erwartungen für jede Phase sind wie folgt:

• Early Release Testing (Frühe Veröffentlichungstests): Diese Phase dient der frühzeitigen Sichtbarkeit von Updates und der Validierung von Funktionen. Hosts in dieser Phase sind so konfiguriert, dass sie den Early-Release-Kanal verwenden, der in der Regel 2 Wochen vor dem normalen Kanal Zugriff auf neue Versionen bietet. Hosts in dieser Phase müssen über eine ausgehende Internetverbindung verfügen (entweder direkt oder über einen Proxyserver), um auf das XenServer Content Distribution Network (CDN) zugreifen zu können.
• Host-Tests: Der Zweck dieser Phase ist es, die Update-Prozesse der XenServer-Softwareversion zu testen. Releases sind über das Internet vom XenServer CDN oder über die Offline-Kanal-Bereitstellungsmechanismen verfügbar.
• Workload-Tests/UAT: Diese Phase ermöglicht es, die XenServer-Hosts mit einer produktionsähnlichen Workload zu testen, um Skalierbarkeit und Ausfallsicherheit zu validieren. Releases sind über das Internet vom XenServer CDN oder über die Offline-Kanal-Bereitstellungsmechanismen verfügbar.
• Produktionsbereitstellungen: Die Hosts, die Produktions-Workloads ausführen, können nach den vorherigen Testphasen aktualisiert werden (direkt oder über die Offline-Bereitstellungsmechanismen).

Hinweis:

Offline-Updates können verwendet werden, um sicherzustellen, dass die erwartete XenServer-Version in den UAT- und Produktionsumgebungen bereitgestellt wird. Es ist möglich, Updates direkt von einem anderen Ressourcenpool zu synchronisieren. Wenn jedoch Updates synchronisiert, aber noch nicht auf den Quellpool angewendet wurden, können sie auf den Zielpool angewendet werden, was zu einer höheren Patch-Version auf dem Zielpool führt.

Um weiterhin unterstützt zu werden, müssen alle Ressourcenpools regelmäßig aktualisiert werden und dürfen nicht älter als 6 Monate sein.

Überwachung des Ressourcenpools

Wenn im Ressourcenpool für einen der Hosts oder VMs Warnungen auftreten, sind diese im Abschnitt „Warnungen“ von XenCenter® verfügbar.

Diese Warnungen können auch in einem externen Überwachungstool über die SNMP-Integration oder über die E-Mail-SMTP-Integration verfügbar gemacht werden.

Es sind 2 Arten der Überwachung zu berücksichtigen.

• Überwachung der Auslastung, um sicherzustellen, dass unerwartete Kapazitätsprobleme schnell erkannt und behoben werden können.
• Überwachung von Systemereignissen, um sicherzustellen, dass die Infrastruktur korrekt funktioniert und keine unerwarteten Änderungen auftreten.

Diese werden unten detailliert beschrieben, um bei der Integration berücksichtigt zu werden.

Die Integration in Überwachungsprodukte von Drittanbietern kann über die (/de-de/xenserver/8/monitor-performance/monitor-snmp.html) beschriebene SNMP-Funktion erfolgen und Warnungen bereitstellen, die in diese Drittanbieter-Tools integriert sind.

Hinweis:

Wenn Sie dem Pool einen neuen Host hinzufügen, müssen Sie die SNMP-Einstellungen neu konfigurieren, um sicherzustellen, dass der neue Host in jede SNMP-Integration einbezogen wird (Einzelheiten finden Sie unter Einschränkungen).

Überwachung der Nutzung

Es können Warnungen konfiguriert werden, um Dinge wie übermäßige CPU-Auslastung zu erkennen. Einzelheiten finden Sie unter Leistungswarnungen.

Nachfolgend finden Sie ein Beispiel für die Daten, die in den für diese Ereignisse ausgelösten SNMP-Traps bereitgestellt werden.

2026-02-19 09:44:35 <UNKNOWN> [UDP: [10.71.64.14]:53876->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196826250) 22 days, 18:44:22.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:eea63153-f96c-25f5-17b9-08ce49e7ccf4"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "83a9c805-a172-f1b2-55d4-081ec180893b" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALARM"    iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3     iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "VM"       iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "681e4064-16cb-4d0c-9c2c-887623bc623f" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:45:55Z"       iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "The memory required by the control domain on \"Control domain on host: pm-demolab-3\" is about 5.7% of its allocated memory. Occasional performance degradation can be expected when memory swapping is forced to happen.
This alarm is set to be triggered when the memory required by the control domain is above 5.0% of its allocated memory."
<!--NeedCopy-->

Überwachung von Systemereignissen

Die Systemwarnungen werden hier beschrieben.

Nachfolgend finden Sie ein Beispiel für die Daten, die in den für diese Ereignisse ausgelösten SNMP-Traps bereitgestellt werden.

2026-02-19 09:43:39 <UNKNOWN> [UDP: [10.71.64.14]:46982->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196820650) 22 days, 18:43:26.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:ca95e2da-06b7-9aa5-fa4b-ddf007a50c59"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "525e459c-51bc-c71c-9c52-dcd747e9a84f" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALL_RUNNING_VMS_IN_ANTI_AFFINITY_GRP_ON_SINGLE_HOST"      iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "Pool"  iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "419d6735-5d11-56b1-8cdc-2853ce709a27"     iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:44:59Z"   iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "<body><message>Breach on VM anti-affinity rules</message><VM_group>3224f9d9-9492-06f7-3c92-da610cde33a8</VM_group><host>ce2a3c26-6bbc-4d23-8626-fba28d3dc651</host></body>"
<!--NeedCopy-->

Remote-Protokollierung

Der Hauptzweck besteht darin, die Unterstützung zu ermöglichen. Um die Verfügbarkeit dieser Daten während der Problemlösung sicherzustellen, kann die Syslog-Weiterleitung konfiguriert werden. Dies ermöglicht das Abrufen der Protokolle, falls sie nicht direkt vom Host abgerufen werden können oder wenn Grund zu der Annahme besteht, dass die Protokolle auf dem Host manipuliert wurden.

Wenn dies konfiguriert ist, muss es auf allen Hosts im Pool konfiguriert werden.

Diese Daten können erheblichen Speicherplatz beanspruchen. Die Nutzung und Aufbewahrung dieser Funktion und der Daten liegt in Ihrem Ermessen, basierend auf internen Sicherheitsrichtlinien.

Modell zur Kapazitätsplanung

Dimensionierung des Ressourcenpools

Jeder Ressourcenpool sollte genügend Ressourcen enthalten, damit der Ressourcenpool die volle Arbeitslast betreiben kann, selbst wenn 1 Host ausfällt. Dies ermöglicht:

• Geplante Ausfälle können bei Bedarf auf jeweils 1 Host erfolgen
• Aktualisierungen des Ressourcenpools ohne Ausfall der Arbeitslast
• Sicherstellung minimaler Arbeitslastausfälle, wenn 1 Host unerwartet ausfällt

Um dies zu erreichen, wird erwartet, dass alle Hosts im Ressourcenpool die gleiche Fähigkeit zur Unterstützung der Arbeitslast haben (d. h. gleiche Konfiguration, RAM, CPU). Dies kann zu einem höheren Grad an CPU-Überbelegung während eines Ausfalls führen, aber dies wird voraussichtlich nur von kurzer Dauer sein, bis der Ausfall behoben ist.

Wenn mehr als 1 Host in einem Ressourcenpool verloren geht, ist es nicht mehr möglich, die gesamte Arbeitslast aufrechtzuerhalten, und es kann zu einem Arbeitslastausfall kommen, bis die Hosts wiederhergestellt sind.

Hinweis:

Wenn Hosts während Aktivitäten wie Hardware-Updates/-Aktualisierungen für bestimmte Zeiträume keine identische Kapazität aufweisen, sollte ein Ausfall des Hosts mit dem meisten Arbeitsspeicher einkalkuliert werden.

Kapazitätsberechnungen des Ressourcenpools

In dieser Referenzarchitektur sind wir davon ausgegangen, dass jeder Ressourcenpool einem bestimmten Zweck dient. Folglich gehen die folgenden Berechnungen davon aus, dass alle VMs im Ressourcenpool die gleiche Spezifikation aufweisen.

Dom0 ist auf 32 GB RAM ausgelegt. Wenn jedoch der PVS-Beschleuniger verwendet wird, muss dieser um mindestens 5 GB pro vDisk erhöht werden, um die Beschleunigung zu unterstützen, und muss in diesen Berechnungen berücksichtigt werden.

Eingaben

Ausgaben

Hinweis:

Während eines Host-Ausfalls, einer Wartung oder eines Update-Vorgangs vm_host = vm_pool_max / (hosts_total - 1)

Praxisbeispiel

• vm_host_max = (1000 - 32 - 2) / 16 = 60 max VMs per Host
• vm_pool_max = 60 * (8 - 1) = 420 max VMs per pool
• srs_total = 420 * (3 + 0) / 1000 = 1.26 SRs (>1 so need 2 SRs spread over 2 LUNS)
• Normalbetrieb:
  • vm_host = 420 / 8 = 52.5 VMs per host (round down to 52)
  • host_cpu_overcommit = ((52 * 4) + 16 + 2) / 128 = 1.77 vCPU per pCPU
• Während eines einzelnen Host-Ausfalls oder eines Update-/Wartungsvorgangs:
  • vm_host = 420 / 7 = 60 VMs per host
  • host_cpu_overcommit = ((60 * 4) + 16 + 2) / 128 = 2.01 vCPU per pCPU

Hinweis:

Es wird keine dynamische Speichersteuerung (DMC) verwendet, um RAM-Overcommit bereitzustellen. XenServer unterstützt dies im Normalbetrieb nicht. Dies wird nur für kurze Zeiträume geplanter, kontrollierter Wartung erwartet, wenn keine andere Option verfügbar ist, um die erforderliche Arbeitslast am Laufen zu halten.

Wenn der Overcommit zu hoch ist, muss die Anzahl der VMs für den Pool reduziert werden, bis ein akzeptabler Punkt erreicht ist.