Skip to content
Start » Ressourcen » Tools
Tools · Kapazitätsplanung

XenServer-Kapazitätsrechner

Dimensionieren Sie Ihre Hypervisor-Hosts für Citrix Multi-Session und VDI. Tragen Sie Ihre Hardware- und Workload-Eckdaten ein — der Rechner ermittelt vCPU-, RAM- und Storage-Bedarf pro Host sowie die insgesamt benötigte Host-Anzahl.

Physische Host-Hardware

Phy. host requirements

×
Cores
GHz
%

VDA & vCPU-Zuteilung

VCPU requirements per host & per VDA

Anzahl Multi-Session-VMs pro Host
VDA
User
vCPU

RAM-Bedarf

RAM amount requirements per host

GB
GB
GB
GB

PVS/MCS I/O-Cache

Citrix Write-Cache: Platzierung & Dimensionierung

Citrix-Empfehlung: RAM mit Überlauf auf Storage
Tatsächliche Disk-Größe — Basis für die Cache-Anteile
GB
%
%
%

Storage-Bedarf

HDD amount requirements per host

Nutzdaten je VDA — getrennt von der vDisk-Größe
GB

Gesamt-Skalierung

Total amount of required hypervisor hosts

User
Zusätzliche Hosts als Ausfallreserve
%
Citrix-Empfehlung: 16 (max. 32)
Hosts
Benötigte Hypervisor-Hosts insgesamt
60
inkl. High-Availability-Reserve
40
Produktiv-Hosts
20
HA-Reserve
100
User / Host
Takt3,0 GHz
Over-Commit1,6:1
GHz/User1701 MHz
4
XenServer-Pools
15
Hosts / Pool
5
HA-Reserve / Pool
Pool-Aufteilung
ProduktivHA-Reserve
Dimensionierung pro Host
Gesamt vCPUs pro Host160 vCPU
RAM pro Host612 GB
Storage pro Host0,88 TB
Verfügbare phys. Cores51,2
Over-Commitment (phys.→vCPU)3,13 : 1

Schätzwerte zur Orientierung. Für eine verbindliche Dimensionierung beraten wir Sie gern persönlich.

Vollständige Berechnung anzeigen
Aus unserer Erfahrung

Worauf es in der Praxis ankommt

Zahlen sind die halbe Miete — den Unterschied macht die Auslegung. Drei Punkte, die sich in unseren Citrix-Projekten immer wieder bewährt haben.

Core-Taktrate über 3,0 GHz wählen

Auch moderne Software enthält Programmteile, die nicht multicore-fähig sind und auf einem einzelnen Kern laufen. Da ein Desktop nie schneller ist als der Kern, der ihn bedient, empfehlen wir mindestens 3,0 GHz Basistakt — lieber weniger, dafür schnellere Kerne.

Dom0-RAM (Control Domain) früh erhöhen

Die Control Domain (Dom0) betreibt den kompletten Netzwerk- und Storage-Treiberstack für alle VMs — der VM-I/O läuft über In-Memory-Ringpuffer zwischen den XenServer-VM-Tools (PV-Treiber) und Dom0. Ist Dom0 zu knapp, leiden Netzwerk und Storage der VMs:

Warum & wie vielweniger anzeigen
  • Default oft zu klein: XenServer vergibt nur 1 GiB + 5 % (max. 8 GiB) — wir setzen Dom0 standardmäßig auf 32 GB.
  • Sonst Netzwerk-Instabilität: zu wenig Dom0-RAM kann Netzwerkprobleme auslösen — besonders kritisch bei geclusterten GFS2-Pools.
  • Pflicht bei PVS-Accelerator / Read-Caching: deren Cache liegt im Dom0-Speicher — vorher erhöhen (≥ 16 GB bei >500 VMs oder PVS-Accelerator).
  • Faustregel: >50 VMs/Host oder große Pools (>32 Hosts) → mind. 8–16 GB; Änderung erfordert einen Host-Reboot, daher gleich beim Setup einplanen.

XenServer-Pools richtig schneiden

Hosts werden zu Pools zusammengefasst — die Schnittgröße entscheidet über Verwaltbarkeit und Ausfallsicherheit:

Pool-Regeln anzeigenweniger anzeigen
  • 16 Hosts pro Pool (max. 32): Citrix-Empfehlung für Virtual Apps & Desktops; mit aktivierter HA eher kleinere Pools, um unerwartetes „Fencing" zu vermeiden.
  • Mindestens 3 Hosts pro Pool: erst dann arbeitet der HA-Heartbeat zuverlässig (Quorum).
  • Pools nie über Standorte/RZ spannen: alle Hosts im selben Standort, Low-Latency-Netz und gemeinsames Shared Storage.
  • Homogene Hosts: gleiche CPU (Hersteller/Modell) und gleicher RAM-Ausbau innerhalb eines Pools.
  • PVS/MCS: PVS-Accelerator bzw. IntelliCache nutzen und VDAs über mehrere Pools verteilen — fällt ein Pool aus, bleibt der Dienst verfügbar.

vCPUs pro VDA bewusst klein halten

Mehr vCPUs ≠ mehr Leistung — oft das Gegenteil. Der Hypervisor-Scheduler muss die vCPUs einer VM möglichst gleichzeitig auf freie physische Kerne legen. Je „breiter" die VM, desto schwerer:

Was dabei passiertweniger anzeigen
  • Co-Scheduling („Tetris-Problem"): Eine breite VM wartet, bis genug Kerne gleichzeitig frei sind — sie ist „ready", steht aber (Co-Stop / CPU-Ready-Time).
  • Mehr Scheduler-Overhead: Je mehr vCPUs gleichzeitig einzuplanen sind, desto höher der Verwaltungsaufwand des Hypervisors — die Leistung sinkt, statt zu steigen.
  • NUMA-Grenze: Eine VDA nie breiter als einen NUMA-Knoten — sonst frisst Cross-Node-Speicherlatenz den CPU-Gewinn auf.
  • Faustregel: klein anfangen, nur bei belegtem Bedarf erhöhen — Over-Commitment (phys.→vCPU) im Blick behalten.

Standby-Cache (RAM) nicht knapp bemessen

Windows hält häufig gelesene Daten — OS-DLLs, App-Binaries, gemeinsame Image-Inhalte — in der Standby-Liste im RAM. In Citrix-Umgebungen wirkt das besonders stark, weil alle Sessions dieselben Basis-Image- und Anwendungsdateien nutzen:

Vorteile im Detailweniger anzeigen
  • Weniger Storage-IOPS: Treffer im RAM-Cache ersparen Lesezugriffe auf die Platte — bei PVS/MCS-Shared-Images sinken die IOPS um bis zu ~90 %.
  • Mehr nutzbare CPU-Leistung: Jeder vermiedene I/O spart CPU-Zyklen im Storage-Stack (Interrupts, Filtertreiber, Dateisystem) — diese Last steht direkt den Benutzer-Workloads zur Verfügung.
  • Schnellere Starts für Folgebenutzer: Hat der erste User eine Anwendung geladen, liegen deren gemeinsam genutzte Code-Seiten (DLLs/Image-Sektionen) bereits im RAM — App-Start und Logon sind für alle weiteren Sessions spürbar schneller (warmer Cache, ideal bei Anmelde-Wellen).
  • Es zählt die Reserve, nicht die Belegung: Zu wenig RAM-Headroom verdrängt den Cache zu früh (kurze „Standby-Cache-Lifetime") — dann steigen Plattenzugriffe und Latenz wieder.

Over-Commitment unter 3:1 halten

Liegt das Verhältnis physischer CPUs zu vCPUs über 3:1, werden Workloads in Spitzenzeiten spürbar langsamer — bei Anmelde-Wellen morgens, Reconnects nach der Mittagspause oder im Monatsreporting.

Mind. ~300 MHz CPU-Takt pro User

Fällt der verfügbare CPU-Takt pro Benutzer unter rund 300 MHz, fehlt dem Multi-Session-Host die Reserve, um Lastspitzen abzufedern. Typische Anomalien:

Typische Anomalien anzeigenweniger anzeigen
  • Höhere Netzwerklatenz & Paketverluste: NIC-Interrupts und Socket-Puffer werden von der OS-CPU verarbeitet — bei Sättigung führt Queue-Lock-Contention zu verworfenen Paketen und steigender Latenz.
  • Vermehrtes Context-Switching: Die CPU-Pipeline wird bei jedem Wechsel geleert und neu gefüllt — verlorene Zyklen statt Nutzlast.
  • Wachsende Processor-Queue / CPU-Ready-Time: Threads warten auf einen freien Kern — der klassische Contention-Indikator.
  • Spürbar im Alltag: hängende Sessions, ruckelndes Scrollen in Webseiten und PDFs.

Konsolidierung vs. Ausfallrisiko abwägen

Mehr User pro Host spart Lizenzen, Netzwerk-Ports, Strom und Monitoring — erhöht aber die Zahl der Sessions, die ein einzelner Host-Ausfall mitnimmt. Vorab im Proof-of-Concept und mit Try-and-Buy-Hardware validieren.

Branchenkonsens u. a. von Citrix, Dell Technologies und TechTarget bestätigt: ≥ 3 GHz Takt bringen bei single-threaded Anteilen den größten Performance-Gewinn.

Ihre aktuelle Konfiguration

Core-Taktrate
3,0 GHz
Over-Commitment
3,13 : 1
CPU-Takt pro User
1.574 MHz

„Eine saubere Auslegung prüfen wir am liebsten vorab im PoC — das erspart später teure Überraschungen.“ — VS Qloud Citrix-Team

Auslegung mit uns besprechen
Hardware- & BIOS-Checkliste vor dem Rollout
BIOS auf „OS Control" + TurboDer Xen-Scheduler steuert die Taktung über P-States — kein fixes Performance-Profil im BIOS erzwingen.
C-States aktiviert lassenGeben dem Prozessor Thermal-Headroom für Turbo. C0-Zwang kostet Leistung, Strom und CPU-Lebensdauer.
NUMA-Topologie beachtenAb 2 Sockeln VDAs möglichst in einen NUMA-Knoten legen — sonst teurer Cross-Node-Speicherzugriff.
Hyper-Threading / SMT anLogische Threads erhöhen die Dichte zusätzlich zu den physischen Kernen. Im PoC verifizieren.
UEFI + Secure BootStatt Legacy-BIOS für die VMs — Sicherheits-Baseline, sauber fürs MCS/PVS-Provisioning.
Schnelle lokale SSDFür IntelliCache und Write-Cache-Overflow — entlastet das Shared Storage spürbar.
Quelle: Citrix CTX200390 · Red Hat KB · XenServer-Doku — die berechnete Kapazität kommt nur an, wenn die Hardware-Ebene stimmt. Power Settings (CTX200390) ↗
An den Anfang scrollen
Translate »
No results found...