Ungünstige Exchange Server Implementierungen | Teil 2

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