Postfächer im Gleichgewicht

von Thomas Joos

Die Exchange Server Subscription Edition lässt sich grundsätzlich problemlos virtualisieren – doch viele klassische Virtualisierungsmechanismen sind für die Messaging-Plattform ungeeignet oder sogar kritisch. Wir schauen uns an, welche technischen Rahmenbedingungen für einen stabilen Betrieb entscheidend sind und worauf Administratoren bei CPU, Speicher, Storage und Hochverfügbarkeit achten müssen.

Wenn Sie Exchange SE virtualisieren, betreiben Sie keine gewöhnliche Serverrolle in einer virtuellen Maschine, sondern eine zustandsintensive Messaging-Plattform, deren internes Transaktionsmodell strikt auf Konsistenz ausgelegt ist. Exchange arbeitet permanent mit sequenziellen Transaktionsprotokollen, repliziert Datenbanken zwischen Servern, verwaltet umfangreiche Caches im Arbeitsspeicher und reagiert empfindlich auf jede Form von I/O-Latenz oder inkonsistenter Speicherzuweisung. Eine Virtualisierung, die diese Mechanismen nicht berücksichtigt, führt nicht nur zu Installationsfehlern, sondern zu Performanceabweichungen, unerwarteten Fail-overn innerhalb einer Datenbankverfügbarkeitsgruppe und im ungünstigsten Fall zu Datenbankinkonsistenzen, die nur noch mit Reparaturwerkzeugen behoben werden können.

Damit Sie Exchange SE stabil virtualisieren können, müssen Sie die Wechselwirkung zwischen Hypervisor, Windows Server 2022/2025 und der Exchange-Architektur verstehen. Genau an dieser Schnittstelle entscheidet sich, ob eine Umgebung dauerhaft zuverlässig arbeitet oder unter Last instabil wird. Wir gehen in diesem Artikel vor allem auf die Virtualisierung von Exchange auf Hyper-V oder vSphere ein. Für andere Plattformen gelten die Hinweise analog.

Supportgrenzen und Betriebsregeln für Exchange SE

Exchange SE ist für den Betrieb in virtualisierten Umgebungen freigegeben. Sowohl Postfach- als auch Edge-Transportserver dürfen als virtuelle Maschinen betrieben werden. Microsoft empfiehlt dafür Windows Server 2025 oder Azure Local. Ein Betrieb von Exchange SE in Microsoft Azure ist nicht vorgesehen; für Cloudszenarien ist Exchange Online die passende Option. Exchange SE ist grundsätzlich für den Einsatz im eigenen Rechenzentrum konzipiert, typischerweise auf Windows Server 2022/2025 mit Hyper-V oder auf validierten Plattformen wie vSphere.

Die Supportfähigkeit hängt nicht nur vom Hypervisor, sondern vor allem vom Betriebsmodus ab. Exchange darf niemals aus einem gespeicherten Zustand wiederhergestellt werden. Dabei wird der Arbeitsspeicher einer VM eingefroren und später fortgesetzt – ein Vorgehen, das mit den strikt sequenziellen Transaktionsprotokollen von Exchange kollidiert. Stimmen Zeitstempel, Checkpoints und Logsequenzen nicht mehr mit dem Storage-Zustand überein, drohen Inkonsistenzen. Failover auf Hypervisor-Ebene müssen daher immer als vollständiger Neustart erfolgen.

Geplante Migrationen sind zulässig, solange sie als echte Onlinemigration ohne gespeicherten Zustand stattfinden. Unter Hyper-V erfolgt dies per Live Migration, unter vSphere per vMotion. Beide Verfahren übertragen den Arbeitsspeicher einer laufenden VM, ohne den Applikationszustand einzufrieren, und sind daher supportkonform.

Snapshots sind ein weiterer kritischer Punkt. Diese erfassen den Zustand von System, Datenbanken und Transaktionsprotokollen. Wird ein Snapshot zurückgesetzt, können diese Zustände auseinanderlaufen, was im Extremfall dazu führt, dass sich Datenbanken nicht mehr mounten lassen. Klassische VM-Snapshots werden daher nicht unterstützt. Zulässig sind ausschließlich applikationskonsistente Production-Snapshots – im Deutschen als Produktionsprüfpunkte bezeichnet – über den Volume Shadow Copy Service. Bei diesen ist Exchange dann als VSS-Writer eingebunden.

Auch der Hypervisor-Host selbst unterliegt klaren Vorgaben: Er sollte ausschließlich den Hypervisor und notwendige Managementkomponenten ausführen. Zusätzliche Serverrollen wie Active Directory, SQL Server oder Exchange gehören nicht auf den Host. Diese Trennung reduziert Interferenzen zwischen Infrastruktur- und Applikationsschicht und erhöht die Stabilität der Umgebung.

Virtuell bedeutet nicht weniger Ressourcen

Exchange SE benötigt in virtuellen Maschinen dieselben Ressourcen wie auf physischer Hardware. CPU-Leistung, Arbeitsspeicher und Storage-Durchsatz richten sich nach Benutzeranzahl, Mailboxgröße, Nachrichtenvolumen, Protokollierung und Hochverfügbarkeitsdesign – nicht nach der Virtualisierung.

Exchange SE unterstützt pro Instanz maximal zwei CPU-Sockets sowie bis zu 256 GByte Arbeitsspeicher. Diese Grenzen definieren den von Microsoft getesteten und supporteten Betriebsrahmen. Auch leistungsfähige Hardware mit deutlich mehr Kernen oder RAM kann eine einzelne Exchange-Instanz nicht sinnvoll ausschöpfen. Der Vorteil der Virtualisierung liegt daher darin, große Hosts in mehrere Exchange-Server aufzuteilen, die jeweils innerhalb dieser Grenzen betrieben werden und so eine bessere Ressourcenauslastung ermöglichen.

Für Postfachserver gelten 128 GByte RAM als typischer Referenzwert, für Edge-Transportserver 64 GByte. Ob dies ausreicht, ermitteln Sie mit dem Role Requirements Calculator, der Bestandteil der Exchange-Installationsmedien ist. Das Werkzeug berechnet den CPU-Bedarf in sogenannten Megacycles, einer aus der SPECint-Leistung abgeleiteten Kennzahl. Da sich CPU-Architekturen stark unterscheiden, ist nicht die Anzahl der Kerne entscheidend, sondern die tatsächliche Rechenleistung pro Kern.

Microsoft erlaubt in virtuellen Umgebungen ein Verhältnis von virtuellen zu physischen Kernen von maximal 2:1. In der Praxis planen Sie konservativer und nähern sich diesem Wert erst anhand realer Lastdaten. Berücksichtigen Sie dabei auch die CPU-Ressourcen des Hypervisors; häufig werden zwei vCPUs für das Host-Betriebssystem reserviert, um Verwaltungsprozesse und I/O nicht mit Exchange konkurrieren zu lassen.

CPU-Architektur, NUMA und Scheduling

Moderne Server arbeiten mit NUMA-Architekturen (Non-Uniform Memory Access), bei denen jeder CPU-Socket über eigenen lokal angebundenen Speicher verfügt. Zugriffe auf Speicher eines anderen Sockets verursachen zusätzliche Latenz. Windows Server 2022/2025 ist NUMA-aware und berücksichtigt diese Struktur. Exchange SE selbst ist nicht NUMA-aware, profitiert jedoch indirekt von einer korrekten Speicherlokalisierung.

Besitzt Ihr Host beispielsweise zwei Sockel mit jeweils 24 physischen Kernen, sollte eine Exchange-VM mit bis zu 24 vCPUs innerhalb eines NUMA-Nodes betrieben werden. Wird diese Grenze überschritten, kommt es zu Remote-Memory-Zugriffen, die sich in erhöhter RPC-Latenz äußern können. Verteilen Sie vCPUs gleichmäßig auf maximal zwei virtuelle Sockel, da Exchange nur zwei Sockel unterstützt.

Unter vSphere arbeitet der Scheduler mit "relaxed co-scheduling" und versucht, die vCPUs einer VM möglichst synchron auszuführen. Werden mehr vCPUs zugewiesen, als die Workload tatsächlich nutzt, entsteht unnötiger Scheduling-Overhead. Exchange profitiert nur dann von zusätzlichen vCPUs, wenn diese durch parallele Threads ausgelastet werden.

CPU-Hot-Plug sollte für Exchange-VMs deaktiviert bleiben, da dadurch die vNUMA-Topologie außer Kraft gesetzt wird und Exchange seine Ressourcen nicht dynamisch anpasst. Ein betrieblicher Vorteil entsteht nicht, wohl aber das Risiko ungünstiger Speicherzuordnung. Hyper-Threading kann hingegen aktiviert bleiben, da es dem Hypervisor zusätzliche Scheduling-Spielräume bietet. Exchange profitiert davon nicht direkt, verhält sich jedoch stabil, solange keine aggressive Überprovisionierung erfolgt.

Arbeitsspeicher, JET-Cache und Hypervisor-Mechanismen

Exchange SE basiert auf der Extensible Storage Engine (ESE, häufig noch als "JET" bezeichnet) und verwendet einen großen, dedizierten Arbeitsspeicherbereich als JET-Cache. Dieser Cache ist kein optionaler Beschleuniger, sondern ein zentrales Element der Datenbankarchitektur. Postfach-Datenbanken bestehen aus logisch strukturierten Seiten fester Größe, die bei Zugriffen zunächst in den Arbeitsspeicher geladen werden. Dort koordiniert Exchange Änderungen, fasst sie zusammen und sichert sie über Transaktionsprotokolle ab, bevor die eigentliche Datenbankdatei aktualisiert wird. Dieses Vorgehen reduziert zufällige I/O-Zugriffe und sorgt auch unter Last für gleichmäßige Latenzen.

Die Größe des JET-Caches wird beim Start der Exchange-Dienste auf Basis des verfügbaren Arbeitsspeichers berechnet und anschließend nicht mehr dynamisch angepasst. Exchange reserviert dabei einen erheblichen Anteil des RAM, um möglichst viele häufig genutzte Datenbankseiten im Speicher zu halten. Wird einer virtuellen Maschine nachträglich Speicher entzogen oder verändert der Hypervisor die effektive Verfügbarkeit, arbeitet Exchange weiterhin mit den ursprünglichen Annahmen. Aus diesem Grund ist dynamischer Arbeitsspeicher für Exchange-VMs nicht unterstützt, da die Anwendung nicht darauf ausgelegt ist, eine veränderte Speicherbasis im laufenden Betrieb zu kompensieren.

In virtualisierten Umgebungen spielt zudem Memory Over-Subscription eine Rolle, bei der insgesamt mehr virtueller Arbeitsspeicher zugewiesen wird, als physisch vorhanden ist. Solange nicht alle VMs gleichzeitig ihren vollen Bedarf abrufen, bleibt dies unkritisch. Bei knappem physischen Speicher greifen Hypervisoren auf Mechanismen wie Ballooning oder Host-Swapping zurück. Beim Ballooning fordert der Hypervisor Speicher aus der VM zurück, den das Gast-Betriebssystem selbst auslagern muss, während beim Host-Swapping Speicherbereiche direkt auf Datenträger umziehen.

Beide Verfahren verändern die effektive Speicherverfügbarkeit aus Sicht der Anwendung. Für Exchange ist das kritisch, da der JET-Cache auf stabil zugewiesenem RAM basiert. Werden CacheSeiten verdrängt, steigen Latenzen, die I/O-Last nimmt zu und RPC- sowie MAPI-Zeiten verschlechtern sich. Produktive Ex- change-Umgebungen sollten Sie daher konsequent ohne Speicherüberbuchung betreiben.

Ein häufig unterschätzter Aspekt ist die Wechselwirkung zwischen Hypervisor-Speicherverwaltung und dem Speicherverhalten von Exchange. Unter vSphere etwa bewertet die sogenannte "Idle Memory Tax" ungenutzten Arbeitsspeicher höher als aktiv genutzten, um Ressourcen im Cluster effizient zu verteilen. In Exchange-Umgebungen kann das problematisch sein, wenn Sie Postfachserver vorsorglich mit deutlich mehr RAM ausstatten als tatsächlich benötigt. Exchange reserviert den JET-Cache beim Start, nutzt ihn jedoch nicht zwangsläufig dauerhaft vollständig. Wird dieser Speicher vom Hypervisor als reclaimable eingestuft, kann interner Druck entstehen, der im Extremfall Ballooning oder Host-Swapping auslöst.

Statt pauschal nach Worst-Case-Szenarien zu dimensionieren, sollten Sie den Speicherbedarf anhand realer Workloads ermitteln, etwa mit Performancemetriken, Jetstress-Tests und typischen Benutzerprofilen. Beachten Sie zudem, dass moderne Hypervisoren vNUMA automatisch ab einer bestimmten vCPU-Anzahl aktivieren. Exchange selbst nutzt NUMA nicht aktiv, Windows Server 2022/2025 innerhalb der VM jedoch schon. Wird CPU-Hot-Plug aktiviert, entfällt diese vNUMA-Topologie, was zu ungünstiger Speicherlokalisierung führen kann. Auch aus diesem Grund sollten Sie CPU- und Memory-Hot-Add für Exchange-VMs deaktivieren.

Das Windows-Energieschema innerhalb der VM sollte auf "Höchstleistung" stehen, da Mechanismen wie CPU-Core-Parking zusätzliche Latenzen verursachen können. Auch auf Hypervisor-Ebene empfiehlt sich ein performanceorientiertes Profil. Im BIOS konfigurieren Sie die Energieverwaltung idealerweise als "OS-controlled" und deaktivieren tiefe C-States.

Storage-Architektur im Detail

Exchange SE arbeitet ausschließlich mit Speicher, den das Betriebssystem als Blockgerät erkennt. Windows adressiert solche Volumes wie lokale Festplatten, führt sektorbasierte I/O-Operationen aus und verwaltet Dateisysteme wie NTFS oder ReFS eigenständig. Darauf fußt die gesamte Datenbankarchitektur von Ex- change. Transaktionsprotokolle werden sequenziell geschrieben, Datenbankseiten in definierter Größe verarbeitet, und jede bestätigte Schreiboperation muss physisch stabil auf dem Datenträger vorliegen. Dieses Verhalten erfordert deterministische I/O-Eigenschaften, die Exchange für eine konsistente Transaktionsverarbeitung benötigt, ohne zusätzliche Zwischenschichten, die Reihenfolgen verändern oder Latenzen einführen.

In virtualisierten Umgebungen bedeutet das, dass Sie Exchange-Daten ausschließlich auf Storage ablegen dürfen, der dem Gast als Blockgerät präsentiert wird. Dies erfolgt über feste virtuelle Festplatten, Pass-Through-Volumes oder iSCSI-LUNs im Gast-Betriebssystem. Entscheidend ist, dass Windows das Volume wie eine lokale Disk behandelt und Exchange vollständige Kontrolle über Schreibreihenfolge und Flush-Operationen behält.

Virtuelle Festplatten sollten grundsätzlich mit fester Größe konfiguriert sein. Thin Provisioning weist Speicherblöcke erst bei tatsächlicher Nutzung zu und kann dadurch zusätzliche Latenzen verursachen, vor allem bei hoher Storage-Auslastung. Da Exchange Transaktionsprotokolle konti- nuierlich schreibt und jede Operation be- stätigt, wirken sich solche Verzögerungen direkt auf die Antwortzeiten aus.

Nicht unterstützt sind NAS-Volumes als direkte Ablage für Datenbanken oder Logdateien, da sie Dateidienste statt Blockzugriff bereitstellen. Eine Ausnahme besteht, wenn feste virtuelle Festplatten auf einer SMB-3.x-Freigabe liegen. In diesem Fall sieht das Gast-Betriebssystem weiterhin ein Blockgerät, da der Hypervisor die Datei abstrahiert. Voraussetzung ist jedoch eine hochverfügbare und leistungsfähige SMB-Infrastruktur.

Virtuelle Maschinen greifen zudem nicht direkt auf physische HBA-Adapter zu. Der Hypervisor abstrahiert diese Ebene vollständig und stellt Speicher entweder als virtuelle Datenträger oder als Pass-Through-Disks bereit. Entscheidend bleibt, dass der Gast stets ein konsistentes Blockgerät sieht.

Performance optimieren, Hochverfügbarkeit einrichten

Unter vSphere empfiehlt sich für Datenbank- und Log-Volumes der Einsatz des Paravirtual-SCSI-Controllers, da dieser für I/O-intensive Workloads optimiert ist und den CPU-Overhead reduziert. Ein wichtiger Parameter ist dabei die Queue-Depth, also die Anzahl gleichzeitig verarbeitbarer I/O-Operationen. Standardmäßig liegt sie bei 64 pro Device und 254 pro Controller und lässt sich bei entsprechend dimensioniertem Storage erhöhen. Anpassungen sollten jedoch stets in Abstimmung mit dem Storage-Hersteller erfolgen, um Überlastungen zu vermeiden.

Ein weiterer zentraler Mechanismus ist AutoReseed innerhalb der Datenbank- Verfügbarkeitsgruppe. Diese Funktion stellt bei Ausfall eines Datenträgers automatisch eine neue Datenbankkopie auf einem Ersatzvolume bereit. Voraussetzung hierfür ist eine strikt standardisierte Volume-Struktur, bei der Datenbank-Volumes als Mountpoints unterhalb eines definierten Stammverzeichnisses eingebunden werden.

Fällt ein Volume aus, bindet Exchange ein vorbereitetes Ersatzvolume an derselben Stelle ein und startet den Wiederherstellungsprozess, indem es die Datenbankkopie erneut aus einer vorhandenen DAG-Kopie aufbaut. In virtualisierten Umgebungen müssen Sie diese Ersatzvolumes ebenfalls als separate virtuelle Datenträger bereitstellen. Nur bei konsistenter Planung der Mountpoint-Struktur kann AutoReseed im Fehlerfall automatisch und ohne manuelles Eingreifen arbeiten.

Failover- und DR-Strategien in virtualisierten Umgebungen

Die Hochverfügbarkeit von Exchange SE realisieren Sie über Datenbank-Verfügbarkeitsgruppen. Eine DAG repliziert Postfach-Datenbanken per Transaktionsprotokollen zwischen mehreren Servern und nutzt dafür Komponenten des Windows-Failover-Clusters. Welche Datenbankkopie aktiv ist, steuert der Active Manager mit den Rollen "Primary Active Manager" und "Standby Active Manager".

Virtualisieren Sie DAG-Mitglieder, dürfen diese nicht dauerhaft auf demselben Host laufen. Unter vSphere setzen Sie dafür Anti-Affinity-Regeln ein, die Sie als Must-Run- oder Should-Run-Regeln konfigurieren können. So steuern Sie gezielt die Platzierung der VMs im Cluster. Mit Admission Control stellen Sie sicher, dass bei einem Hostausfall ausreichend Ressourcen für Neustarts zur Verfügung stehen.

Besondere Aufmerksamkeit erfordert die Interaktion zwischen Hypervisor-Migrationen und dem Windows-Failover-Cluster. Bei einer Livemigration entsteht ein kurzer "Stun"-Moment, in dem die VM pausiert wird, während der Arbeitsspeicher synchronisiert wird. In dieser Zeit empfängt der Cluster keine Heartbeats vom betroffenen DAG-Mitglied und kann dies als Ausfall interpretieren. Zwar sind die Timeout-Werte in Windows Server 2019 sowie 2022/2025 großzügiger dimensioniert, unter hoher Last oder bei großen Speicherkonfigurationen kann es dennoch zu Fehlinterpretationen und ungeplanten Failovern kommen – etwa bei überlasteten vMotion-Netzwerken oder langsamen Verbindungen.

Um dieses Risiko zu reduzieren, sollten Sie dedizierte 10-GBit-Netzwerke für vMotion beziehungsweise Livemigration einsetzen und – sofern die Infrastruktur dies unterstützt – Jumbo Frames durchgängig aktivieren. Dadurch verkürzt sich die Migrationsdauer messbar. Zusätzlich lassen sich mehrere VM-Kernel-Ports oder Livemigration-Pfade konfigurieren, um den Durchsatz zu erhöhen und die Stun-Dauer weiter zu reduzieren.

vSphere HA startet virtuelle Maschinen nach einem Hostausfall automatisch neu, ersetzt jedoch keine DAG, sondern ergänzt sie. Während die DAG den Ausfall von Datenbanken abdeckt, sorgt HA für die Wiederverfügbarkeit auf Infrastruktur- ebene. Für Disaster-Recovery-Szenarien reicht eine DAG allein nicht aus, da sich komplette Standortausfälle damit nur eingeschränkt testen lassen. Werkzeuge wie Site Recovery Manager automatisieren Shutdown, Storage-Promotion, Re-IP und den Wiederanlauf abhängiger Dienste und ermöglichen reproduzierbare DR-Tests ohne Unterbrechung des Produktivbetriebs.

Fazit

Exchange SE lässt sich stabil virtualisieren, wenn Sie die technischen Rahmenbedingungen konsequent einhalten. CPU-Topologie muss der physischen Struktur folgen, Arbeitsspeicher darf nicht dynamisch verändert werden, und Storage muss blockbasiert sowie deterministisch angebunden sein. Nur unter diesen Voraussetzungen arbeitet die Plattform zuverlässig und performant.

Die DAG bleibt dabei der zentrale Mechanismus für die Applikationsverfügbarkeit, während Hypervisor-Funktionen die Infrastruktur absichern. Für Exchange SE ist Virtualisierung kein Selbstläufer, sondern erfordert eine konsequent durchdachte Architektur. Richtig umgesetzt ermöglicht sie konsolidierte Hardware, planbare Wartung und ein kontrollierbares Failover-Verhalten bei gleichzeitig reproduzierbarer Performance.