XenServer® Enterprise-Referenzarchitektur

Übersicht

Diese Referenzarchitektur definiert einen empfohlenen Ansatz für das Design, die Bereitstellung und den Betrieb von XenServer zur Unterstützung von Workloads im Unternehmensmaßstab. Sie bietet eine validierte Grundlage für das Hosting von Citrix Virtual Apps and Desktops™ (CVAD)-Umgebungen sowie für die allgemeine Servervirtualisierung, wobei der Schwerpunkt auf Skalierbarkeit, Ausfallsicherheit und operativer Einfachheit liegt.

Die Architektur basiert auf dem Konzept des XenServer-Ressourcenpools als Kerneinheit für Skalierung und Management. Jeder Ressourcenpool ist für den Betrieb innerhalb eines einzelnen Rechenzentrums (oder einer Reihe eng verbundener Rechenzentren) konzipiert und unterstützt eine vorhersehbare, 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 durch Design: Ressourcenpools an spezifische Workload-Typen anpassen, um eine konsistente Leistung und ein konsistentes Betriebsverhalten zu gewährleisten
• N+1-Kapazitätsmodell: Ausreichende Kapazität aufrechterhalten, um den Ausfall eines einzelnen Hosts zu tolerieren, ohne die Workload-Verfügbarkeit zu beeinträchtigen
• Trennung der Zuständigkeiten: Management-, VM- und Speicherverkehr klar trennen, um Leistung, Ausfallsicherheit und Sicherheit zu gewährleisten
• Explizite Resilienzstrategie: Intra-Rechenzentrums-Resilienz und Inter-Rechenzentrums-Disaster Recovery als separate architektonische Anliegen behandeln
• Operative Einfachheit: Optionale Funktionen nur dort einführen, wo sie einen klaren Mehrwert bieten, und unnötige Komplexität vermeiden

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

Diese Architektur setzt die Verwendung von Remote-Block-Speicher, integriertem Identitätsmanagement über Active Directory und sicheres Management über TLS voraus. Optionale Funktionen wie Workload Balancing (WLB), Hochverfügbarkeit (HA) und Disaster Recovery (DR) können je nach Workload-Anforderungen integriert werden, doch jede davon bringt zusätzliche betriebliche Überlegungen mit sich, die explizit geplant werden müssen. Die Referenzarchitektur ist für Unternehmensumgebungen gedacht, die eine vorhersehbare Leistung und eine starke operative Kontrolle erfordern. Sie ist nicht für spezielle 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 Betriebspraktiken.

• 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 Kontrolldomäne 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.
  • Hosts müssen UEFI-Firmware verwenden; Legacy-BIOS wird in XenServer 9 nicht unterstützt.

• Es wird davon ausgegangen, dass der Speicher über entfernte 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 Managementkommunikation wird mit TLS gesichert, und die Integration mit Active Directory wird für die Authentifizierung und rollenbasierte Zugriffssteuerung angenommen. Der administrative Zugriff soll den standardmäßigen Unternehmenssicherheitspraktiken folgen, mit eingeschränkter Nutzung lokaler Konten und kontrollierter Offenlegung von Managementschnittstellen.

• Operativ sind Ressourcenpools um ein N+1-Kapazitätsmodell herum 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

Jedes davon bringt zusätzliche betriebliche Komplexität mit sich und sollte nur auf der Grundlage klarer Workload- und Geschäftsanforderungen übernommen werden.

Nicht im Geltungsbereich

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

• Workloads, die einzelne virtuelle Festplatten größer 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. Bei kleinen Bereitstellungen sind gemischte Anwendungsfälle möglich, es muss jedoch Vorsicht geboten sein, wenn die Lastverteilung und 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 die 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 Verwaltung des Pool-Koordinators
• 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) nur in Notfällen zur Verwaltung, wenn eine Authentifizierung über AD-Anmeldeinformationen nicht möglich ist (z. B. bei Ausfall des AD-Domänencontrollers).

Bereitstellung von Zertifikaten für Hosts

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

Alle Hosts müssen über ein bereitgestelltes Zertifikat verfügen; dies kann ein gemeinsames Wildcard-Zertifikat oder ein Zertifikat pro Host sein.

Hinweis:

Einige Anwendungen, die die XenServer-APIs verwenden, wie z. B. einige ältere Versionen von Citrix Apps und Desktops, erfordern die Verwendung eines individuellen Zertifikats für jeden Host und erlauben keine Wildcard-Zertifikate. Weitere Details 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
• SSH in den Modus Auto setzen, damit SSH automatisch aktiviert wird, falls der Management-Toolstack ausfällt

Secure Boot aktivieren

XenServer 9-Hosts können so konfiguriert werden, dass sie mit aktiviertem Secure Boot in der Firmware ausgeführt werden. Dies erzwingt die Signaturprüfung in jeder Phase des Bootvorgangs und reduziert das Risiko, dass nicht vertrauenswürdiger oder bösartiger Code ausgeführt wird, bevor das Host-Betriebssystem vollständig geladen ist.

Aktivieren Sie Secure Boot in den Firmware-Einstellungen auf jedem Host. Alle Dom0-Kernelmodule in XenServer 9 sind signiert, sodass der normale Hostbetrieb nicht beeinträchtigt wird. Gemischte Pools, bei denen Secure Boot auf einigen Hosts aktiviert und auf anderen deaktiviert ist, werden unterstützt.

Die vollständigen Konfigurationsschritte finden Sie unter Secure Boot für XenServer 9.

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 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 Netzteile 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 die vom DHCP zugewiesene Host-IP-Adresse wechselt. Wenn feste DHCP-Adressen verwendet werden, sollte davon ausgegangen werden, dass die DHCP-Umgebung zuverlässig verfügbar ist (z. B. als Teil der Netzwerkinfrastruktur) und nicht von einer VM bereitgestellt werden, 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 Zeitverschiebung auftritt und die Kommunikationswege unterbrochen werden. Dies gewährleistet auch konsistente Zeitstempel für alle Systemprotokolle.

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 Best Practice, die Multipath-Unterstützung des Speichers 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 jeder. Konsultieren Sie Ihren Speicheranbieter für weitere Empfehlungen.

Speicherkonfiguration des Ressourcenpools

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

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

Es wird empfohlen, SANs zu verwenden, die ihre eigene Thin-Provisioning-Funktion bereitstellen, um eine effiziente Speichernutzung zu gewährleisten. Das Thin Provisioning des SANs nutzt den verfügbaren Speicher besser aus, indem es den 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 und die Image-Bereitstellung erheblich verzögern kann, wodurch die Einführung 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 den Verlust eines gesamten Ressourcenpools verursacht.

Diese werden unten separat betrachtet.

Ausfallsicherheit 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 Ausfallsicherheit 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 stehen zur Verfügung:

• Management-Hochverfügbarkeit (durch automatisierte Koordinatorwahlen bei ungeplanten Ausfällen)
• Workload-Compute-Hochverfügbarkeit (durch automatischen VM-Neustart bei ungeplanten Ausfällen)
• Speicher-Ausfallsicherheit (durch Speichermultipathing)
• Netzwerk-Ausfallsicherheit (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 des Workloads 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-Hostkapazität ermöglicht das Aktualisieren und Aufrüsten von Ressourcenpools ohne Workload-Ausfall, was die einfache Anwendung von Sicherheitsupdates und Funktionserweiterungen erlaubt.

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

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), wo die anfängliche Platzierung und normale Lebenszyklusoperationen bereits ein ausreichendes Gleichgewicht bieten, oder wo 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 Standarddimensionierung 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 gesamten 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.

Wartungsfenster der Datenbank 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 Ausfall der WLB-Verarbeitung von bis zu 30 Minuten kommen wird. Dies hat keine Auswirkungen auf den normalen Betrieb, sondern nur auf 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 die Ressourcenpools mit maximaler Leistung betreiben zu können. Diese können durch den Gebrauch optimiert werden, aber einige vorgeschlagene Anfangswerte 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 eine durchschnittliche Auslastung von 90 % über die letzten 1,5 Minuten erreicht, der WLB-Dienst alternative Standorte für die Ausführung von VMs bewertet.

  • Wenn die Leistung Ihrer VMs bei geringeren CPU-Auslastungen 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 unnötiger Overhead.
  • Empfohlener anfänglicher kritischer Schwellenwert: 0
  • Empfohlener anfänglicher Metrik-Gewichtungswert: Am wenigsten wichtig
• Netzwerk-Lese- und Schreibvorgänge: Die Standardwerte hierfür sind 25 MB/s. Das bedeutet, dass jeder Host, der mehr Bandbreite für Lese- oder Schreibvorgänge nutzt, für eine Verlagerung in Betracht gezogen wird. Dieser Parameter ist nur relevant, wenn Sie VMs mit hoher Netzwerkauslastung betreiben und es wichtig ist, Auswirkungen auf andere VMs zu vermeiden.
  • Für viele Anwendungen ist dies kein relevanter Faktor, und die Gewichtung sollte auf die geringste Wichtigkeit eingestellt werden.
  • Für viele moderne Netzwerke ist dies ein sehr niedriger Wert, und wenn diese Einstellung relevant ist, empfehlen wir, sie so einzustellen, dass eine gute Nutzung dieser Bandbreite möglich ist, bevor eine Migration auf einen 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. Das bedeutet, dass jeder Host, der mehr Bandbreite für Lese- oder Schreibvorgänge nutzt, für eine Verlagerung in Betracht gezogen wird. Dieser Parameter ist nur relevant, wenn Sie VMs mit hoher Festplattenauslastung betreiben und es wichtig ist, Auswirkungen auf andere VMs zu vermeiden. 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 davon, auf welchem Host 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 eingestellt 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 Massenmigrationen verursachen, wenn diese nicht benötigt werden.
  • 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 finden Sie hier

Es gibt 2 Elemente, die für XenServer bezüglich Hochverfügbarkeit zu berücksichtigen sind

• 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 for Availability für eine vollständige Erläuterung 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 Arbeitslast innerhalb der Grenzen des unerwarteten Verlusts eines einzelnen Hosts zu unterstützen. Die Einstellung „Failures to Tolerate“ sollte auf 1 gesetzt werden.

Hinweis:

Es ist wichtig, die folgenden Merkmale bei der Verwendung von HA zu beachten

• Der Ressourcenpool muss mindestens 3 Hosts umfassen
• Fencing bezieht sich auf den Mechanismus, der einen Host, der als ausgefallen oder unsicher gilt, 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. Bei Pools >16 Hosts sollte dies sorgfältig berücksichtigt werden.
• HA sollte während Host-/Ressourcenpool-Wartungsarbeiten deaktiviert werden, um das Risiko unerwarteter Ausfälle während dieser Wartungsaktivitäten zu reduzieren.
• Bei der Verwendung von HA muss darauf geachtet werden, dass die Speicherkonnektivität zum HA-Statusdatei-SR und die Netzwerkverbindung nicht unterbrochen werden. Eine Unterbrechung dieser Verbindungen kann dazu führen, dass Hosts unerwartet ein Fencing durchführen, 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.

Manuelle Wiederherstellung der Management-Konnektivität

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 hierfür sind für xe CLI und PowerShell angegeben.

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 nach einem unerwarteten Ausfall keine WLB-Funktionen verloren gehen. Sie sollte in der ersten Startgruppe 0 sein.

Andere VMs

Je nach der genauen 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 Host-Ausfall die Servicekontinuität wesentlich verbessert und bei denen der Pool N+1 dimensioniert ist, um den Ausfall aufzufangen. Vermeiden Sie VM HA für Workloads, bei denen externes Brokering/Orchestrierung bereits Neustart- oder Scale-out-Verhalten bietet (zum Beispiel 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 bei Bedarf neu konfiguriert werden, nachdem VMs zur Umgebung hinzugefügt wurden.

• PVS- und nicht-persistente MCS-VMs: Konfigurieren Sie diese VMs nicht mit HA. Stellen Sie sicher, dass diese auf Do Not Restart gesetzt sind. Andere VMs sollten verfügbar sein, um Endbenutzern sofortige Dienste bereitzustellen, und Citrix Virtual Apps and Desktops wird Energieverwaltungsfunktionen bereitstellen, 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 wird ein optimierteres Ergebnis für die kombinierte Citrix-Umgebung liefern.

• MCS-persistente VMs: Diese sollten auf ‘Neustart’ gesetzt werden. Die entworfene 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), damit diese Konfiguration möglich ist.

• Allgemeine Server-Virtualisierungs-Workloads (alle Workloads, die nicht zum Ausführen von Citrix VDAs verwendet werden): Diese sollten auf ‘Neustart’ gesetzt werden. Die entworfene 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), damit 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 startet. Dies könnte verwendet werden, um Workloads zu priorisieren, die von anderen Diensten 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 dies, 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 Modus der Ausfallsicherheit, der voraussichtlich selten eingesetzt wird, um extreme und ungeplante Infrastrukturausfälle zu unterstützen. 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 Ort, 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 der Workload (oder kritischer Teile der Workload) zu mindern, kann ein sekundärer Rechenzentrumsstandort für Disaster-Recovery-Funktionen genutzt werden. Weitere Dokumentation ist hier verfügbar.

Ein oder mehrere Ressourcenpools am DR-Standort können zusätzlich zur Wiederherstellungsstelle für Workloads auch für andere Workloads verwendet werden, Sie müssen jedoch die erforderliche freie Kapazität aufrechterhalten, um die Ausführung der zusätzlichen Workloads bei Bedarf zu ermöglichen.

Es ist nicht erforderlich, dass die gesamte Workload am DR-Standort betrieben wird, wenn ein Fehlerereignis auftritt. Teilweise Workloads können wiederhergestellt werden, bis der vollständige Betrieb am primären Standort wiederhergestellt ist. Es besteht jedoch die Anforderung, dass Workloads von 1 Ressourcenpool in einen einzigen Wiederherstellungsressourcenpool 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 mit diesem Prozess verbundenen Vorgänge 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. Ausreichend Arbeitsspeicher, CPU und Netzwerkkapazität müssen im Standby-Ressourcenpool konfiguriert werden, um die Neuerstellung und den Start aller erforderlichen ausgefallenen VMs zu ermöglichen.
• 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 zur Umsetzung).

Betriebsmodell

XenServer-Versionsverwaltung über Bereitstellungen hinweg

XenServer-Bereitstellungen werden aus einem oder mehreren Ressourcenpools über ein oder mehrere Rechenzentren hinweg aufgebaut, um eine skalierbare, robuste und sichere Bereitstellung zu ermöglichen, die performante Workloads in großem Maßstab liefern kann.

Diese Bereitstellungen können Test- und Produktionsumgebungen bereitstellen, und ein Workflow kann erstellt werden, um Änderungen in diesen 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 keine getrennten Phasen 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: Diese Phase ist für eine frühzeitige Sichtbarkeit von Updates und die Validierung von Funktionen vorgesehen. Hosts in dieser Phase sind so konfiguriert, dass sie den Early-Release-Kanal verwenden, der in der Regel zwei Wochen vor dem normalen Kanal Zugriff auf neue Versionen bietet. Hosts in dieser Phase müssen über eine ausgehende Verbindung zum Internet verfügen (entweder direkt oder über einen Proxy-Server), um auf das XenServer Content Distribution Network (CDN) zugreifen zu können.
• Host-Tests: Der Zweck dieser Phase ist es, die Update-Prozesse für XenServer-Software-Releases 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 Version von XenServer 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 länger als 6 Monate veraltet sein.

Treiberverwaltung mit Treiber-Multi-Versioning (DMV)

XenServer 9 führt Treiber-Multi-Versioning (DMV) ein, das genehmigte Treiberversionen über den standardmäßigen gestreamten Host-Update-Kanal bereitstellt, wodurch in den meisten Fällen keine separaten Treiber-Disks mehr erforderlich sind.

DMV ermöglicht es Operatoren, aus mehreren genehmigten Treiberversionen auszuwählen, die im Update-Stream verfügbar sind. XenServer präsentiert nur Treiber-Varianten, die mit der Hardware auf jedem Host kompatibel sind. Wenn ein falscher Treiber angewendet wird, kann die korrekte Version ausgewählt und installiert werden, ohne den Host neu zu installieren, obwohl ein Neustart erforderlich ist, damit die Änderung wirksam wird. XenServer 9 erzwingt die Validierung signierter Treiber, wodurch nicht genehmigte Drittanbieter-Binärdateien blockiert werden.

Weitere Informationen finden Sie unter Treiber-Multi-Versioning.

Überwachung des Ressourcenpools

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

Diese Warnungen können auch in einem externen Überwachungstool über SNMP-Integration oder über 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 ordnungsgemäß funktioniert und keine unerwarteten Änderungen auftreten.

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

Die Integration in Überwachungsprodukte von Drittanbietern kann über die hier beschriebene SNMP-Funktion erfolgen und Warnmeldungen 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 Warnmeldungen konfiguriert werden, um Dinge wie übermäßige CPU-Auslastung zu erkennen. Einzelheiten finden Sie unter Leistungswarnungen.

Unten sehen Sie ein Beispiel der 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.

Unten sehen Sie ein Beispiel der 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 hierbei ist die Ermöglichung der Unterstützung. 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 diese nicht direkt vom Host abgerufen werden können oder wenn Grund zu der Annahme besteht, dass 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 ein Host ausgefallen ist. Dies ermöglicht:

• Geplante Ausfälle können bei Bedarf auf jeweils einem Host durchgeführt werden
• Aktualisierungen des Ressourcenpools können ohne Arbeitslastausfall vorgenommen werden
• Sicherstellung eines minimalen Arbeitslastausfalls, falls ein Host unerwartet ausfällt

Um dies zu erreichen, wird davon ausgegangen, 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-Überprovisionierung während eines Ausfalls führen, aber es wird erwartet, dass dies nur von kurzer Dauer ist, bis der Ausfall behoben ist.

Wenn mehr als ein Host in einem Ressourcenpool ausfällt, 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/-Erneuerungen für bestimmte Zeiträume keine identische Kapazität haben, sollte der Ausfall des Hosts mit dem meisten Speicher berücksichtigt werden.

Berechnungen der Ressourcenpool-Kapazität

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

NUMA-Optimierung

XenServer 9 aktiviert die NUMA-Platzierungsoptimierung standardmäßig. Wenn die vCPUs und der Speicher einer VM in einen einzelnen NUMA-Knoten auf dem Host passen, erreichen Arbeitslasten eine geringere Speicherzugriffslatenz und eine konsistentere Leistung. Dies kann auch eine höhere VM-Dichte pro Host ermöglichen, wodurch der Bedarf an zusätzlichen Servern reduziert wird.

Für beste Ergebnisse dimensionieren Sie VMs so, dass ihr Speicher in einen einzelnen physischen NUMA-Knoten passt. Wenn eine VM mehr Speicher benötigt, als ein einzelner Knoten bereitstellen kann, verteilt XenServer die VM auf mehrere Knoten, und der Optimierungsvorteil wird reduziert. Die VM-Dimensionierung, die NUMA-Knotengrenzen überschreitet, sollte eher als Ausnahme denn als Norm behandelt werden.

NUMA-Metriken pro VM stehen zur Verfügung, um die Platzierung zu überwachen und Affinitätsverletzungen zu erkennen. Weitere Informationen finden Sie unter NUMA-Optimierung in XenServer 9.

Berechnungen der Kapazität des Ressourcenpools

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

Eingaben

Ausgaben

Hinweis:

Während eines Host-Ausfalls, Wartungs- oder 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 Ausfalls eines einzelnen Hosts 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 Dynamic Memory Control (DMC) zur Bereitstellung von RAM-Überbelegung verwendet. XenServer unterstützt dies im Normalbetrieb nicht. Dies sollte nur während kurzer Zeiträume geplanter, kontrollierter Wartung verwendet werden, wenn keine andere Option verfügbar ist, um die erforderliche Arbeitslast am Laufen zu halten.

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