Valeurs du délai d’attente du disque Windows et Exchange Server 2010
Article d’origine publié le jeudi 17 novembre 2011
Il y a quelques mois, Bruce Langworthy a écrit un article excellent à propos de nouvelles recommandations sur le paramétrage de la valeur de délai d’attente du disque Windows - 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.
Ce billet m’a fait penser à Exchange et à la manière avec laquelle nous gérons les problèmes d’E/S. Si vous n’avez pas lu l’article de Bruce, il explique que la valeur de délai d’attente par défaut de 60 secondes signifie que Windows ne signale pas l’E/S bloquée pendant 60 secondes et ne réessaiera pas l’E/S pendant 8 minutes. Comme 8 minutes est un délai d’attente trop long avant de retenter une E/S, Microsoft fait de nouvelles recommandations visant à attribuer au paramètre de délai d’attente du disque Windows une valeur alignée sur votre architecture de stockage.
La question que j’avais en tête à propos d’Exchange était simple, en quoi ce délai d’attente du disque affecte-t-il les déploiements de groupes de disponibilité de base de données (DAG) Exchange ; et plus spécifiquement dois-je réduire le délai d’attente du disque Windows sur mes serveurs Exchange conformément aux nouvelles recommandations ou conserver le paramètre existant ? ?
Pour répondre à cette question, j’ai approché certains de nos développeurs ESE pour connaître leur opinion… Voici les informations que j’ai recueillies…
- La valeur de délai d’attente du disque Windows concerne essentiellement la journalisation des événements et les tentatives d’E/S.
- Avant Exchange Server 2010, Exchange ne prenait aucune mesure particulière vis-à-vis des E/S lentes, si ce n’est de les signaler dans le journal des événements.
- Exchange Server 2010 RTM a introduit la correction préemptive pour les pages affectées d’E/S lentes.
- Exchange Server 2010 SP1 est la première version d’Exchange qui inclut un système intelligent de gestion des E/S bloquées et mettra activement en échec (vérification d’erreur) le serveur si l’E/S bloquée affecte les bases de données actives sur un nœud de groupe de disponibilité de base de données.
J’ai décidé qu’avant de pouvoir déterminer quoi faire de nos paramètres de délai d’attente de disque, nous devions d’abord comprendre quel système intelligent Exchange Server 2010 SP1 avait introduit et dans quelle mesure il pouvait interagir avec les délais d’attente de disque.
Récupération de moteur de stockage extensible Exchange Server 2010 SP1 sur les E/S bloquées
Exchange Server 2010 SP1 a apporté de grandes améliorations dans la manière avec laquelle nous traitons les E/S bloquées. Ces améliorations sont traitées en détail dans l’article TechNet suivant https://technet.microsoft.com/en-us/library/ff625233.aspx:
« Exchange 2010 SP1 inclut une nouvelle logique de récupération qui tire profit du comportement de vérification d’erreur Windows intégré dans certaines situations, spécifiquement lorsqu’une condition d’E/S bloquée se produit. Dans SP1, le moteur ESE (Extensible Storage Engine) a été mis à jour pour détecter les E/S bloquées et prendre les mesures correctives permettant de restaurer automatiquement le serveur. ESE maintient un fil de surveillance d’E/S qui repère les blocages d’E/S au-delà d’une période donnée. Par défaut, lorsqu’une E/S pour une base de données est bloquée pendant plus d’une minute, ESE consigne un événement. Si une base de données a un blocage d’E/S de plus de 4 minutes, elle consignera un événement d’échec spécifique, si elle peut le faire. L’événement ESE 507, 508, 509 ou 510 peut être consigné ou pas, suivant la nature de l’E/S bloquée. Si la nature du problème est telle que le volume du système d’exploitation ou que la capacité d’écrire dans le journal des événements est affectée, les événements ne seront pas consignés. Si les événements sont consignés, le service Microsoft Exchange Replication (MSExchangeRepl.exe) détectera le problème et déclenchera intentionnellement une vérification d’erreur de Windows en mettant fin au processus wininit.exe. »
Alors, qu’est-ce que cela signifie ? Et bien, après quelques discussions (et quelques recherches dans le code ESE), le tableau suivant a été créé pour faciliter la compréhension du comportement (j’ai inclus les versions antérieures d’Exchange pour référence).
Remarque : je tiens à remercier ici Alexandre Costa et Brett Shirley, développeurs ESE de l’équipe Exchange, sans qui ces informations n’auraient pas été possibles – merci les gars !
|
Version Exchange |
Type d’E/S |
Heure d’E/S |
Comportement |
|
Exchange Server 2003 |
Terminée |
>60 secondes |
|
|
Exchange Server 2007 |
Terminée |
>60 secondes |
|
|
Exchange Server 2010 RTM |
Terminée |
>60 secondes |
|
|
Exchange Server 2010 SP1 |
En vol |
>60 secondes |
|
|
>4 minutes |
| ||
|
Terminée |
>30 secondes |
|
Remarque : E/S en vol décrit une opération d’E/S lente qui n’a pas encore abouti. Une E/S terminée représente une E/S lente qui a abouti, mais a nécessité plus de 30 secondes. Il est important de noter ici qu’avant Exchange Server 2010, le concept de détection des E/S lentes en vol n’existait pas. Nous ne signalions les E/S qu’une fois terminées.
Je n’aime pas ce nouveau comportement, que puis-je faire ?
Comme souvent, je déconseille de changer le nouveau comportement à moins d’avoir une raison clairement définie et justifiée de le faire… Toutefois, si vous avez besoin de modifier le nouveau comportement de récupération d’E/S bloquée du moteur ESE (Extensible Storage Engine), des clés de Registre/attributs Active Directory vous permettent de le faire. Ces clés et attributs sont documentés ici.
Conclusion
Pour en revenir à la raison pour laquelle j’ai commencé à écrire cet article, je cherchais à évaluer si nous devions réduire la valeur Windows Disk TimeOutVale sur les nœuds DAG Exchange comme recommandé ici.
Je me suis donc adressé à Matt Gossage de l’équipe Exchange (Matt sait tout sur Exchange et les E/S), qui m’a expliqué que l’une des fonctions du délai d’attente du disque est de protéger l’hôte des « tempêtes » de réinitialisations de bus. L’un des effets secondaires intéressants lorsqu’une E/S atteint la valeur TimeOutValue du disque Windows est que le pilote disk.sys commande une réinitialisation de bus, et que cette réinitialisation affecte tous les LUN du serveur, pas uniquement celui qui ne répond pas.
Le scénario le plus courant où ce comportement a été observé concerne Exchange 2010 et le stockage JBOD. Là où une solution RAID est déployée, le contrôleur de disque est capable de résoudre les problèmes de lecture de blocs défectueux, soit en lisant les données depuis un autre disque, soit en recalculant les données à partir de la parité ; cela retarde l’E/S, mais pas de façon significative. Avec JBOD, comme il n’existe qu’une seule copie du bloc de données, la possibilité qu’un bloc défectueux cause un blocage d’E/S pendant que nous attendons que le disque essaie de lire les données, est réelle. En conclusion, avec un déploiement de JBOD, nous ne voulons pas réduire la valeur TimeOutValue. Nous souhaitons au contraire l’augmenter afin de réduire les effets d’une « tempête » de réinitialisations de bus qui se produirait si l’une des broches de disque JBOD commençait à ne plus répondre.
Le tableau suivant souligne les recommandations pour définir la valeur HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue des serveurs qui exécutent le rôle de boîte aux lettres Exchange Server 2010.
| Scénario | Recommandation |
| Stockage à attachement direct |
|
| Stockage RAID attaché au SAN |
|
| Stockage JBOD |
|
Neil Johnson
Consultant senior, MCS R.-U.
Ceci est une version localisée d’un billet de blog. Vous trouverez la version originale à la page Windows Disk Timeouts and Exchange Server 2010