Exchange-Troubleshooting – Fall 2: Storage

Dies ist der zweite Teil meiner Blog-Serie mit Exchange-Troubleshooting-Fällen aus der Praxis. Nachdem ich im ersten Teil die nicht ganz alltäglichen Probleme mit Netzwerken behandelt habe, zeige ich in diesem Beitrag die kniffligen Fällen im Zusammenhang mit Storage.

Fall 1: Schlechte Performance bei Zugriff mit Outlook im Online-Mode

Ein Kunde, bei dem wir die Migration von Exchange 2010 zu Exchange 2013 vornahmen, meldete extrem schlechte Performance und lange Wartezeiten für Outlook-Benutzer beim Markieren von Objekten in der Mailbox. Da XenApp im Einsatz steht, ist Outlook im Online-Mode konfiguriert und damit auch sehr anfällig bei Leistungsengpässen auf den Servern.

Eine Analyse der Performancedaten auf dem Server zeigte hohe Latenz bei Read-Zugriffen mit Zeiten konstant über 100ms. Im Schnitt sollten 20ms nicht überschritten werden und Spitzen sollten nicht über 50ms liegen.

Im vorliegenden Fall waren gleich mehrere Rahmenbedingungen auf Seite des Storage suboptimal:

• Die Exchange-Datenbanken und -Logs liegen auf vom Betriebssystem separaten virtuellen Disks, die aber über NFS an die Virtualisierungsplattform angebunden sind. Dies ist durch Microsoft nicht unterstützt.
• Die Netapp-Appliance, die den Diskspace zur Verfügung stellt, ist extrem stark ausgelastet, da sich zu viele VMs die gleichen physischen Spindeln teilen.
• Es ist keine Ausweichmöglichkeit vorhanden. Die zweite Netapp-Appliance zeigt nach Verschiebung der Exchange-VM dieselbe schlechte Leistung.
• Gemäss Storage-Team ist die maximale IOPS-Performance schon überschritten.

Zum Glück hatte der Kunde noch einen physischen Server für seine Backup-Lösung gekauft, den er nicht benötigte. Wir konnten vier zusätzliche 7200 RPM SAS Disks einbauen, ein RAID 10 Array damit konfigurieren und Exchange darauf installieren.

Ob dies nun die endgültige Lösung darstellt oder die Netapp erweitert wird, überlasse ich dem Kunden.

Microsoft Exchange Trainings Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. Zu allen Exchange-Server-Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Fall 2: Schlechte Performance bei Zugriff mit Outlook

Der zweite Fall äusserte sich sehr ähnlich wie der erste, aber Outlook war hier im Cached Mode. Ausserdem reagierte nicht nur Outlook langsam, sondern auch die Exchange Server, Domain Controller und weitere Server auf der Hyper-V basierten Virtualiserungsplattform waren kaum zu bedienen. Die Response Times des Storage lag zeitweise bei über 1.3 Sekunden.

Beim Storage handelte es sich um ein neu gekauftes Netgear ReadyNAS mit 10-Gbit-Netzwerkadaptern, angebunden über iSCSI. Leider liessen die dürftigen Logging-Optionen der Appliance keine tiefere Analyse zu und die Resultate auf Seite Windows waren klar: Storport Logging zeigte, dass das Problem effektiv beim Storage liegen musste.

Das Zurückverschieben aller VMs auf den ursprünglichen Speicher löste das Performance-Problem. Das ReadyNAS muss nun vom Händler oder Hersteller überprüft werden, damit die Ursache gefunden werden kann.

Fall 3: Replikation innerhalb des DAG lässt sich nicht einrichten

Beim dritten Fall musste vom Kunden ein virtueller Exchange Server auf einer Hyper-V-Plattform neu aufgesetzt werden. Er war Teil einer Database Availability Group und nach erfolgreicher Installation und Konfiguration von Exchange sollten auch die Datenbank-Kopien wieder angelegt werden. Dabei kam es aber zu Fehlermeldungen und das Seeding der Datenbank konnte nicht durchgeführt werden.

Der Fehler liess sich schliesslich darauf zurückführen, dass der Disk-Typ auf den bestehenden und dem neuen Exchange Server nicht identisch war – die alten verwendeten 512-Byte-Sektor-Disks, während der neue 4-KB-Disks im 512e-Modus verwendete. Dies kann natürlich bei physischen Disks auftreten – im vorliegenden Fall war es aber wegen den unterschiedlichen Hyper-V-Disk-Typen: VHD und VHDX, die die vorher genannten Sektorgrössen emulieren.

Nach Neukonfiguration des Servers mit VHD-Disks statt VHDX konnten die Datenbankenkopien erfolgreich erstellt werden.

Fazit

Viele Probleme, insbesondere jene, die die Performance betreffen, lassen sich auf Storage-Virtualisierung zurückführen. Nicht umsonst empfiehlt Microsoft physische Server mit Direct Attached Storage. Ein sehr gutes Wissen über die komplexen Storage-Systeme ist unabdingbar, um einen fehlerfreien Betrieb zu gewährleisten.