Granikos Technology Blog

Exchange Server war in der Vergangenheit eine Applikation, die sehr strenge Vorgaben für den sicheren und stabilen Betrieb vorgegeben hat. Von den Vorgaben hinsichtlich Server-Hardware, SCSI-Controller u.ä. abzuweichen galt als zu vermeiden. Dies hat sich seit der Einführung von Exchange Server 2010, der Datenbankportabilität und Datenbankverfügbarkeitsgruppen drastisch geändert.

Diesen Umstand hat die Exchange Server Produktgruppe durch zahlreiche Supportfälle zu spüren bekommen und für Exchange Server 2013 die Exchange Server Preferred Architecture, oder kurz, die Exchange PA eingeführt. Die Exchange PA gibt eine Empfehlung, wie man Exchange Server in einer On-Premises IT-Infrastruktur am besten implementiert. Mehr Informationen finden Sie in der Präsentation zum aOS Vortrag: Exchange Server 2019 - Wie macht man es richtig?. 

Aktuelles Beispiel

In diesem Beispiel werden in einer Exchange Organisation werden zwei Datenbankverfügbarkeitsgruppen (DAG) betrieben, um primäre Anwender- und Funktionspostfächer von Online-Archivpostfächern zu trennen.

Die virtualisierten Serversysteme sind auf zwei Rechenzentren aufgeteilt und. In Rechenzentrum A werden drei der fünf Server von DAG1 betrieben, in Rechenzentrum B die anderen zwei Server. Für DAG2 ist die Verteilung recht einfach, jeweils eins der beide Serversysteme steht in einem der vorhandenen Rechenzentren. Die beiden Server von DAG2 sind im Load Balancer Pool nicht konfiguriert. Dort sind nur die fünf Server von DAG1 als aktive Zielsysteme konfiguriert.  

Das folgende Schaubild verdeutlicht die Konfiguration.

• DAG1 - Produktive Postfächer für Anwender, Funktionskonten und geteilte Postfächer 
• DAG2 - Online-Archivpostfächer

Fragen

Der Betrieb einer solchen Konfiguration wirft natürlich einige Fragen auf. Nicht alle Fragen konnten während des Analyse der Umgebung beantwortet werden, da die Architekten dieser Betriebsumgebung nicht mehr im Unternehmen angestellt sind.

• Warum wurde eine asymmetrische Konfiguration der Exchange-Serversysteme für DAG1 gewählt?
  • Der Hauptgrund für diese asymmetrische Verteilung ist, dass Rechenzentrum B als Backup-Rechenzentrum für den Störungsfall gesehen wird. Dieser Logik folgend, muss diesem Rechenzentrum nicht die gleiche Verfügbarkeit sichergestellt werden, wie im Hauptrechenzentrum.
     
• Warum wurde eine separate DAG für Online-Archivpostfächer eingerichtet?
  • Die Begründung für eine separate DAG sind die geringeren Anforderungen an die Datensicherung und Verfügbarkeit der Online-Archivpostfächer. Die Postfachdatenbanken von DAG2 werden in einem anderen Sicherungsintervall gesichert, als die Postfachdatenbanken von DAG1. 
    
    Hier muss zuerst die Frage gestellt werden, ob die Daten in den Archivpostfächern weniger schützenswert sind, als die Daten in den primären Postfächern. Der Betrieb von zwei zusätzlichen Servern nur zu diesem Zweck erhöht den Verbrauch an Ressourcen und die Aufwände für den Betrieb unnötig. Es ist wesentlich einfacher für den täglichen Betrieb, primäre Postfächer und Archivpostfächer in den gleichen Postfachdatenbanken zu betreiben.

Empfehlung

Die Empfehlungen für diese Exchange Server Umgebung sind:

• Rückbau der dedizierten DAG für Online-Archivpostfächer
• Erweiterung der DAG1 auf ein symmetrisches Server- und Datenbank-Layout
• Regelmäßige Prüfung der Verteilung der Postfächer in den den Datenbanken, um eine möglichst gleichmäßige Datenbankgrößen zu betreiben
• Einführung von Postfach-Quota für Anwender-Postfächer

Links

• Exchange Server Preferred Architecture
• Exchange Server 2019 Planung

Viel Spaß mit Exchange Server.

Das Thema "ungünstiger Exchange Server Implementierungen" scheint in seiner Vielfalt unerschöpflich. Leider ist Exchange Server, auch in der aktuellen Version 2019, ein sehr tolerantes Produkt, wenn es um die Installation und den Erstbetrieb geht. Die eigentlichen Probleme und Fehler einer schlechten Exchange Server Implementierung treten erst nach einer gewissen Betriebszeit in Erscheinung.  Ähnlich sieht es aus, wenn nach einer IT-Störung notwendige Wiederherstellungsschritte ausgelassen oder unbedacht ausgeführt werden. 

Heute möchte ich mit Ihnen folgendes Beispiel teilen, bei dem einige Informationen auf Annahmen basieren, da von Kundenseite nicht alle Fragen beantwortet wurden bzw.  beantwortet werden konnten. 

Ausgangssituation

In der lokal installierten Exchange Server Plattform treten Performance-Probleme mit der Nachrichtenzustellung im Outlook-Client auf. Nach Aussage des Kunden erfolgt die Zustellung eingehener Nachrichten mit einer bis zu 60-minütigen Verzögerung. 

Diese Beschreibung erscheint auf den ersten Blick auf einen einfach zu lösenden Fehler hinzudeuten. Bei genauer Betrachtung zeigt sich aber, dass es sich um ein schwerwiegendes Problem innerhalb der Exchange Server-Plattform handelt.

Im Vorfeld wurde, so die Aussage des Kunden, die IT-Infrastruktur durch eine Krypto-Attacke kompromittiert. Im Rahmen der ausgeführten Wiederherstellungsmassnahmen wurde, so der Anschein, ein Domain Controller auf einen älteren Stand zurückgesetzt. Zu dieser Maßnahme fehlen leider detaillierte Informationen. 

Fakten

Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:

• 6 Exchange Server 2010 SP3
  • 3 Systeme mit Mailbox-Rolle
    30 Postfachdatenbanken
  • 3 Systeme mit kombinierter CAS- und Hub-Transport-Rolle
     
• 5 Exchange Server 2016 mit CU12
  • 2 Systeme mit produktiv eingebunden Postfachdatenbanken in einer DAG mit ca. 40 Postfachdatenbanken
  • 3 Systeme ohne produktiv eingebundene Postfachdatenbanken
     
• 2 konfigurierte Datenbankverfügbarkeitsgruppen (DAG)

In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:

• Exchange Server 2010 Systeme sind nicht mehr vorhanden
• Keine Aussage, ob Exchange Server 2010 auf diesen sechs Systemen deinstalliert wurde oder ob die Systeme einfach gelöscht wurden
• Migration von Exchange Server 2010 zu Exchange Server 2016 gilt beim Kunden offiziell als abgeschlossen

Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:

• 12 vCores
• 16 GB Arbeitsspeicher
• Bereitstellung des Datenspeichers per iSCSI von einem QNAP NAS

Weitere Fakten:

• Selbstsignierte Exchange Server Zertiifkate für Frontend-Dienste
• Unterschiedliche Konfiguration je Exchange Server
• ~100 Transportregeln mit CC-Ergänzungen für die Zustellung an weitere Mitarbeiter
• Endpunkt-Sicherheitslösung ohne Konfiguration von Exchange Server-Ausnahmen

Fazit

In der beschriebene Exchange Server Plattform kommen unterschiedliche Probleme zusammen. Das beschriebene Fehlerbild der verzögerten Nachrichtenzustellung hängt weniger mit der eklatante Fehlkonfiguration der Exchange Organisation zusammen, als mit dem schlechten Aufbau der IT-Hardware. Hier kommen mehrere Punkte zusammen:

• Die Einbindung der Volumes per iSCSI über die allgemeine Netzwerkinfrastruktur führt zu einer schlechten Disk I/O Performance
• Die Nutzung von 40 Exchange-Postfachdatenbanken per iSCSI über den gleichen iSCSI Endpunkt verschlechtert die Disk I/O Performance nochmals
• Das Verhältnis von verfügbarer Prozessorleistung und Arbeitsspeicher der Exchange Server 2016 Systeme ist unüberlegt konfiguriert
• Der Arbeitsspeicher ist für die Einbindung von 40 Postfachdatenbanken viel zu gering
  • Bei einer guten Datenbankverteilung innerhalb der DAG und Einbindung von 20 aktiven Postfachdatenbankkopien je DAG-Mitgliedsserver ist der Arbeitsspeicher bereits zu gering
  • Bei einer Aktivierung aller Datenbankkopien auf einem Exchange Server im Fehlerfall steht nicht ausreichend Arbeitsspeicher zur Verfügung

Die Probleme hinsichtlich der Leistungsdefizite der beiden Exchange Server 2016 Systeme hätten bereits im Vorfeld mit einer einfachen Systemüberwachung des Betriebssystems erkannt werden können. Bei der Konfiguration des Arbeitsspeicher für die Systeme standen die Einschränkungen der Hypervisor-Hostsysteme im Vordergrund. Die realen Anforderungen von Betriebssystem, Exchange Server 2016, Endpunkt-Sicherheitslösung und anderer installierter Komponenten, fanden keinen Anwendung. Insbesondere wurden auch die internen Anforderungen von Exchange Server 2016 beim Betrieb einer DAG, in Kombination mit der Managed Availability, nicht berücksichtigt. 

Mit dieser Hardware-Konfiguration kann der Programmcode von Exchange Server nicht korrekt arbeiten. Die im Verhältnis recht hohe Zahl an vorhandenen Prozessorkernen führt nicht zu einer Beschleunigung von Exchange Server. Da gleichzeitig nicht genug freier Arbeitsspeicher zur Verfügung steht und die Disk I/O-Leistung zu gering ist, kommt es zwangsläufig zu einer verzögerten Ausführung des Codes und damit automatisch zu einer verzögerten Verarbeitung von Nachrichten.

Für diese Hardware-Plattform sind zu viele iSCSI-Volumes in Betrieb und zu viele Postfachdatenbanken je Server eingebunden. Bei 40 Datenbanken mit je einer aktiven und einer passiven Kopie werden insgesamt 80 Datenbankkopien auf den iSCSI-Zielen betrieben. Trotz der starken Reduzierung der Disk I/O-Anforderungen in Exchange Server 2016, im Vergleich zu den Vorversionen, kann ein iSCSI-NAS die permanent erforderliche Leistung nicht liefern. Für ein Caching von Postfachinformationen steht nicht genug Arbeitsspeicher zur Verfügung. Exchange Server muss die Daten direkt auf Disk schreiben, um die Daten sicher zu persistieren. 

Die fehlerhafte Konfiguration der Exchange Organisation im Active Directory trägt ihren ganz eigenen Teil zu den Problemen bei. Diese Konfiguration wird von allen Exchange Servern gelesen und für weitere Aktionen verwendet. Einige dieser Aktionen, die jeder einzelne, in Betrieb befindliche, Exchange Server durchführt, sind:

• Regelmäßiger Test der Kommunikationsverbindungen (http https, etc.) zu den anderen Exchange Servern, die in der Konfiguration der Exchange Organisation vorhanden sind
  • Funktionstest zu anderen Mitgliedsservern der gleichen DAG
  • Funktionstest der Erreichbarkeit von Exchange Servern außerhalb der DAG
• Versand von Test-Nachrichten zwischen allen aktiven Postfachdatenbanken einer DAG
  • Funktionstest der E-Mail-Zustellung
  • Funktionstest der Suchindizierung
  • Funktionstest der Client-Protokolle
• Prüfung auf fehlende Kalendereinträge in jedem Postfach

Exchange Server besteht aus viel mehr als nur der Verarbeitung von individuellen eingehende und ausgehenden Nachrichten. Die Funktion der Managed Availability nimmt einen nicht unerheblichen Teil des Leistungsbedarfs eines Exchange Servers in Anspruch. Exchange Server ist dafür ausgelegt, eine hochverfügbare Messaging-Plattform bereitzustellen. Hierzu dienen all die Funktionen, die unter der Haube ablaufen. Neben den Anforderungen an die Systemleistung von CPU und Arbeitsspeicher, schreiben alle Exchange Server Komponenten Protokolldateien auf Disk. Dies wird gerne ebenfalls vernachlässigt. 

Die in der Active Directory Konfigurationspartition vorhandenen Exchange Server 2010 Systeme sind als Computerobjekte nicht mehr vorhanden. Dies deutet darauf hin, dass die Wiederherstellung der authoritativen AD-Datensicherung Ursache des Fehlers ist. Alternativ ist es auch möglich, dass diese Situation durch eine "Ad-Hoc-Deinstallation" von Exchange Server aus dem Active Directory eingetreten ist. Unter einer "Ad-Hoc-Deinstallation" versteht man das unmittelbare Löschen des AD-Computerobjektes eines Servers, auf dem Exchange Server installiert ist. Diese Art der "Deinstallation" von Exchange Server führt automatisch zu verwaisten Einträgen in der Konfigurationspartition und damit zu Folgeproblemen beim Betrieb der Exchange Organisation. 

Führen Sie unter keinen Umständen eine "Ad-Hoc-Deinstallation" von Exchange Server durch.

Die Fehlersituation in der Exchange Server-Plattform bei diesem Kunden ist noch nicht abschließend gelöst. Die optimale Lösung erfordert zum einen die Bereinigung des Active Directory und zum anderen einen Umbau der Exchange Server Infrastruktur. Dies ist jedoch mit Investitionen verbunden.

Links

• Exchange Server Systemanforderungen
• Exchange Server Unterstützungsmatrix
• Exchange Server Architektur

Dieses Beispiel ist eine Ergänzung zu den in meinem Buch "Exchange Server 2019 - Das Handbuch für Administratoren" beschriebenen Beispielen ungünstiger Exchange Server Implementierungen. 

Ich wünsche Ihnen viel Spaß und gute Laune mit Exchange Server.

Image by Pexels