Windows-Datenträgertimeouts und Exchange Server 2010
Veröffentlichung des Originalartikels: 17.11.2011
Vor einigen Monaten hat Bruce Langworthy einen hervorragenden Artikel zu einigen neuen Empfehlungen für das Festlegen des Windows-Datenträger-Timeoutwerts geschrieben: https://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx.
Dieser Beitrag hat mich veranlasst, über Exchange und das Behandeln von E/A-Problemen nachzudenken. Wenn Sie den Artikel von Bruce noch nicht gelesen haben, folgt hier eine kurze Zusammenfassung: Es wird erläutert, dass bei einem Standardtimeout von 60 Sekunden eine hängende E/A erst nach 60 Sekunden in Windows gemeldet wird und die E/A erst nach 8 Minuten wiederholt wird. Eine Wartezeit von 8 Minuten ist aber viel zu lang, um eine hängende E/A wieder anzustoßen. Daher veröffentlicht Microsoft eine neue Richtlinie, die empfiehlt, die Einstellung für das Windows-Datenträgertimeout auf einen Wert festzulegen, der der jeweiligen Speicherarchitektur entspricht.
Die Frage, die ich mir in Bezug auf Exchange gestellt habe, war simpel: Wie wirkt sich dieses Datenträgertimeout-Verhalten auf die Exchange DAG-Bereitstellungen aus? Konkret: Soll ich das Windows-Datenträgertimeout auf meinen Exchange-Servern gemäß den neuen Empfehlungen reduzieren oder das Timeout so belassen, wie es ist?
Um diese Frage zu beantworten, habe ich einige ESE-Entwickler auf das Timeout angesprochen, um ihre Meinung dazu zu hören… hier einige Auszüge aus der Diskussion…
- Der Windows-Datenträger-Timeoutwert ist in erster Linie für die Ereignisprotokollierung und E/A-Wiederholung vorgesehen.
- Vor Exchange Server 2010 wurden in Exchange keine Maßnahmen bei einer langsamen E/A ergriffen, es wurde lediglich im Ereignisprotokoll vermerkt.
- In Exchange Server 2010 RTM wurde ein neues präemptives Seitenpatchen (vollständiges Überschreiben) für Seiten eingeführt, die von der langsamen E/A betroffen sind.
- Exchange Server 2010 SP1 ist die erste Version von Exchange, die intelligente Funktionen zum Behandeln einer hängenden E/A umfasst und aktiv einen Serverfehler (Fehlerprüfung) auslöst, wenn die hängende E/A sich auf aktive Datenbanken in einem DAG-Knoten auswirkt.
Ich war der Ansicht, dass wir uns erst darüber informieren sollten, welche intelligente Funktionen mit Exchange Server 2010 SP1 eingeführt wurden und wie diese möglicherweise mit den Datenträgertimeouts interagieren, bevor wir uns entscheiden, was mit den Datenträger-Timeouteinstellungen geschehen soll.
Exchange Server 2010 SP1 Extensible Storage Engine-Wiederherstellung bei hängender E/A
In Exchange Server 2010 SP1 wurden einige hervorragende Verbesserungen zur Behandlung der hängenden E/A eingeführt. Diese Verbesserungen werden detailliert im folgenden TechNet-Artikel behandelt https://technet.microsoft.com/en-us/library/ff625233.aspx:
Exchange 2010 SP1 enthält eine neue Wiederherstellungslogik, die auf dem integrierten Windows-Fehlerprüfungsverhalten (BugCheck) aufbaut, wenn bestimmte Bedingungen auftreten, insbesondere bei hängender E/A. In SP1 wurde die Extensible Storage Engine (ESE) aktualisiert, um den Server durch korrigierende Maßnahmen automatisch wiederherzustellen. ESE verwaltet einen E/A-Watchdog-Thread, der erkennt, wann eine E/A für einen bestimmten Zeitraum aussteht. Wenn eine E/A für eine Datenbank länger als eine Minute aussteht, protokolliert ESE standardmäßig ein Ereignis. Wenn die E/A für eine Datenbank mehr als 4 Minuten aussteht, wird ein bestimmtes Fehlerereignis protokolliert, sofern möglich. Das ESE-Ereignis 507, 508, 509 oder 510 wird möglicherweise protokolliert, abhängig von der Art der hängenden E/A. Wenn das Problem so gestaltet ist, dass es sich auf das Betriebssystemvolume auswirkt oder auf die Fähigkeit, in das Ereignisprotokoll zu schreiben, werden die Ereignisse nicht protokolliert. Wenn die Ereignisse protokolliert werden, erkennt der Microsoft Exchange-Replikationsdienst („MSExchangeRepl.exe“) diese Bedingung und erzwingt eine Fehlerüberprüfung von Windows, indem der Prozess „wininit.exe“ beendet wird.
Was bedeutet dies also? Nun, nach einigen Diskussionen (und einer Suche nach ESE-Code) wurde die folgende Tabelle erstellt, um das Verhalten verständlicher zu machen (ich habe einige vorherige Versionen von Exchange zu Referenzzwecken eingefügt).
Anmerkung: Ich möchte mich an dieser Stelle ganz besonders bei Alexandre Costa und Brett Shirley bedanken, die ESE-Entwickler im Exchange-Team sind und ohne deren Hilfe die Bereitstellung dieser Informationen nicht möglich gewesen wären – danke Jungs!
|
Exchange-Version |
E/A-Typ |
E/A-Zeit |
Verhalten |
|
Exchange Server 2003 |
Abgeschlossen |
>60 Sekunden |
|
|
Exchange Server 2007 |
Abgeschlossen |
>60 Sekunden |
|
|
Exchange Server 2010 RTM |
Abgeschlossen |
>60 Sekunden |
|
|
Exchange Server 2010 SP1 |
Im Gange |
>60 Sekunden |
|
|
>4 Minuten |
| ||
|
Abgeschlossen |
>30 Sekunden |
|
Hinweis: „Im Gange“ beschreibt einen langsamen E/A-Vorgang, der noch nicht erfolgreich abgeschlossen wurden. „Abgeschlossen“ stellt eine langsame E/A dar, die abgeschlossen wurde, aber länger als 30 Sekunden gedauert hat. Ich möchte an dieser Stelle darauf hinweisen, dass es vor Exchange Server 2010 keine Möglichkeit gab, langsame E/A-Vorgänge zu erkennen, die noch im Gange sind. Erst nach Abschluss der E/A erfolgte eine diesbezügliche Meldung.
Ich mag dieses neue Verhalten nicht. Was kann ich unternehmen?
Wie bei den meisten Dingen, würde ich davon abraten, das neue Verhalten zu ändern, sofern nicht ein klarer und zwingender Grund dafür besteht… Wenn Sie jedoch das neue Verhalten der Extensible Storage Engine-Wiederherstellung bei hängender E/A ändern müssen, können Sie hierzu einige Registrierungsschlüssel/Active Directory-Attribute verwenden, die hier dokumentiert sind.
Schlussfolgerung
Zur Erinnerung: Mit diesem Artikel wollte ich klären, ob wir den Windows-Datenträger-Timeoutwert (TimeOutValue) für die Exchange DAG-Serverknoten ändern sollten, so wie hier empfohlen.
Ich habe mich mit Matt Gossage vom Exchange-Team unterhalten (Matt weiß alles über Exchange und E/A), und er hat mir erklärt, dass der Datenträger-Timeoutwert unter anderem den Host vor Buszurücksetzungen schützt. Wenn eine E/A den Windows-Datenträger-Timeoutwert erreicht, ist einer der interessanten Nebeneffekte hierbei, dass der Treiber „disk.sys“ eine Buszurücksetzung ausgibt. Diese Zurücksetzung wirkt sich auf alle LUNs auf dem Server aus, nicht nur auf die LUN, die nicht mehr antwortet.
Das häufigste Szenario, in dem dieses Verhalten beobachtet wurde, ist bei Verwendung von Exchange 2010 und einem JBOD-Speicher (Just a Bunch Of Disks). Falls eine RAID-Lösung bereitgestellt ist, kann der Datenträgercontroller das Lesen beschädigter Sektoren meistern, indem entweder die Daten von einem anderen Datenträger gelesen oder die Daten aus der Parität erneut berechnet werden. Hierdurch wird die E/A verzögert, aber nicht erheblich. Wird dagegen ein JBOD-Speicher verwendet, gibt es nur eine einzige Kopie des Datensektors. Daher führt ein beschädigter Sektor möglicherweise zu einer hängenden E/A, während der Datenträger versucht, die Daten zu lesen. Fazit: Bei einer JBOD-Bereitstellung sollte der Datenträger-Timeoutwert also nicht reduziert werden. Er sollte vielleicht sogar erhöht werden, um die Auswirkungen von Buszurücksetzungen zu reduzieren, wenn eine der JBOD-Datenträgerspindeln beginnt auszufallen.
Die folgende Tabelle enthält Empfehlungen zum Festlegen des HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue für Server, die unter der Exchange Server 2010-Postfachrolle ausgeführt werden.
| Szenario | Empfehlung |
| Direkt angeschlossener Speicher |
|
| Mit SAN verbundener RAID-Speicher |
|
| JBOD-Speicher |
|
Neil Johnson
Senior Consultant, UK MCS
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Windows Disk Timeouts and Exchange Server 2010