Partager via

Résolution des problèmes liés aux éléments de cache dans ARR version 2.0 ou ultérieure

  • Article

S’applique à : Internet Information Services

Aperçu

Dans cette procédure pas à pas, vous pouvez apprendre à tracer une demande à mesure qu’elle passe par ARR et est envoyée à un serveur de niveau suivant, et examiner les informations qui peuvent être acquises pour déterminer où la demande a été envoyée et où elle a été traitée.

Outils utilisés dans cet utilitaire de résolution des problèmes

Comprendre l’architecture de la batterie de serveurs

La première étape consiste à comprendre l’architecture de l’environnement, y compris les éléments suivants.

  • Topologie de la batterie de serveurs ARR (nombre de serveurs, configuration du routage, autres appareils)
  • Règles de réécriture d’URL en place

Dans cette procédure pas à pas, vous pouvez utiliser la configuration suivante pour suivre une demande.

Le diagramme montre un nœud enfant, un nœud parent et un serveur d’origine avec des flèches pour indiquer les absences et demandes du cache.

Configuration du cache de disque

L’extrait de code suivant montre un lecteur local dont la taille maximale est de 100 Go est configurée.

<diskCache> 
<driveLocation path="E:\temp$\arrcache" maxUsage="100" />            
</diskCache>

Règles de contrôle du cache global

Cette règle est définie comme cache pendant 60 minutes lorsqu’aucune directive de contrôle de cache n’existe.

<rule name="ARR_CacheControl_b5aec65d-6327-407f-a28c-b34e48c5cda2" enabled="true" patternSyntax="Wildcard"> 
     <match url="*" />     
       <serverVariables>        
         <set name="ARR_CACHE_CONTROL_OVERRIDE" value="0,max-age=3600" />         
       </serverVariables>
</rule>

Créer un plan de collecte de données

Cette section vous guide tout au long du flux des accès au cache et des absences lors du transit par ARR, et identifie les outils ou journaux que vous pouvez utiliser pour examiner les demandes. Les étapes suivantes décrivent le flux de demande pour le contenu qui n’a pas été précédemment mis en cache à l’aide de la configuration fournie en tant que référence et outils utilisés à chaque étape.

  • Le contenu demandé n’est pas trouvé localement (ni en mémoire ni sur le disque sur le nœud enfant).

    • Journaux FREB
    • Journalisation intégrée IIS
    • Moniteur réseau

  • La demande est transférée au nœud de cache de niveau suivant (nœud parent).

    • Journaux FREB
    • Module IIS Advanced Logging
    • Journalisation intégrée IIS
    • Moniteur réseau

  • Le contenu demandé n’est pas trouvé au niveau suivant du nœud de cache de niveau suivant (ni en mémoire ni sur le disque). Répétez le point 2 autant de fois que nécessaire en fonction de la hiérarchie du cache.

  • La demande est transférée au serveur d’origine.

    • Journaux FREB
    • Journalisation intégrée IIS
    • Moniteur réseau

Collecter les données

Le contenu demandé est introuvable localement (ni en mémoire ni sur disque)

Ici, vous pouvez identifier un accès au cache ou une absence dans les journaux IIS ou LES journaux FREB. Les journaux FREB fournissent des détails supplémentaires tels que l’emplacement où la demande a été routée, ce qui est important s’il existe plusieurs serveurs de bas niveau.

Entrée du journal IIS : vous trouverez les entrées suivantes dans le champ de requête cs-uri-query qui identifie le cache Hit ou Miss et le GUID de la demande, qui peuvent être utilisées pour identifier la requête sur des serveurs de bas niveau.

X-ARR-CACHE-HIT=0

0 =  Cache miss, 1 = Cache hit

X-ARR-LOG-ID=62a3161c-b4f5-408e-9ce7-55d25c018aea

Guid identifying this request. This can be used to track as the request is passed to Parent nodes.

Entrée de journal FREB - L’absence de cache est trouvée par l’entrée ARR_DISK_CACHE_GET_FAILED.

Type Entrée Détails
r ARR_DISK_CACHE_GET_FAILED Avertissement FilePath="\?\C:\ARRCache\localhost\iisstart.htm.full", ErrorCode="Le système ne peut pas trouver le fichier spécifié. (0x80070002)", IsRangeEntry="false", RangeOffset="0", RangeSegmentSize="0"

Identifiez le serveur vers lequel la requête est routée. Observez la demande envoyée au serveur W2K8WEBSERVER2, qui sera le serveur de niveau suivant pour la révision des données.

Type Entrée Détails
i ARR_SERVER_ROUTED RoutingReason="LoadBalancing", Server="W2K8WEBSERVER2", State="Active", TotalRequests="8", FailedRequests="0", CurrentRequests="1", BytesSent="1127", BytesReceived="6441379", ResponseTime="31351"

Les en-têtes suivants sont ajoutés à la demande pour le transfert. Si certains noms sont différents des noms par défaut tels que X-Forwarded-For, X-ARR-ClientCertet X-ARR-LOG-IDque les noms ont été personnalisés dans les paramètres du proxy de batterie de serveurs.

En-tête Détails
GENERAL_SET_REQUEST_HEADER HeaderName="Max-Forwards", HeaderValue="10", Replace="true"
GENERAL_SET_REQUEST_HEADER HeaderName="X-Forwarded-For", HeaderValue="127.0.0.1:62489", Replace="true"
GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-SSL", HeaderValue="", Replace="true"
GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-ClientCert", HeaderValue="", Replace="true"
GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-LOG-ID", HeaderValue="fe9d20da-a571-4451-8ef3-0e7faf1a463a", Replace="true"

La demande est transférée au nœud de cache de niveau suivant (nœud parent)

À l’étape précédente, vous aviez identifié ce serveur comme W2K8WEBSERVER2. Dans cette étape, vous pouvez examiner les données suivantes sur ce serveur. Plusieurs points de données peuvent être utilisés. À l’aide X-ARR-LOG-IDde ce serveur, vous pouvez identifier si la requête a atteint ce serveur.

Journaux FREB : la requête peut être identifiée par l’envoi X-ARR-LOG-ID à partir du nœud enfant. L’étape fe9d20da-a571-4451-8ef3-0e7faf1a463a précédente a été identifiée.

En-tête Détails
GENERAL_REQUEST_HEADERS Headers="Connection: Keep-Alive Accept: */* Host: localhost Max-Forwards: 10 X-Original-URL: /iisstart.htm X-Forwarded-For: 127.0.0.1:62489 X-ARR-LOG-ID: fe9d20da-a571-4451-8ef3-0e7faf1a463a

Module de journalisation avancée IIS : à l’aide de la journalisation avancée, vous pouvez ajouter des champs de journalisation personnalisés basés sur les en-têtes, X-ARR-LOG-ID puis utiliser le filtrage pour journaliser uniquement lorsque ces en-têtes X-Forwarded-For sont présents.

#Software: IIS Advanced Logging Module
#Version: 1.0
#Start-Date: 2009-10-16 18:42:51.494
#Filter: ((ARRLogID isPresent ) || (xforward isPresent ))
#Fields:  date time cs-uri-stem cs-uri-query s-contentpath sc-status s-computername cs(Referer) sc-win32-status sc-bytes cs-bytes X-ARR-LOG-ID X-Forwarded-For

2009-10-16 18:51:29.983 /iisstart.htm - "C:\inetpub\wwwroot\iisstart.htm" 200 "W2K8WEBSERVER2" - 0 1680 219 "fe9d20da-a571-4451-8ef3-0e7faf1a463a" "127.0.0.1:62489"

Moniteur réseau : utilisez la trace pour identifier et X-ARR-LOG-ID X-Forwarded-For si vous souhaitez suivre une demande particulière.

ARR Helper - Ce module ajoute l’en-tête X-Forwarded-For au C-IP champ et l’en-tête X-ARR-LOG-ID au cs-uri-query champ des journaux IIS par défaut.

Note

ArrHelper n’est actuellement pas pris en charge par Microsoft.

Répétez les étapes 1 et 2 pour plusieurs niveaux de cache

Si le nœud W2K8WEBSERVER2 parent du serveur est configuré avec les fonctionnalités ARR et de mise en cache, vous devrez peut-être vérifier IISLOGS ou FREB pour voir s’il y a eu un cache Hit ou Miss et décider où procéder en fonction de l’état d’entrée de ce cache.

La demande est transférée au serveur d’origine

Cette étape peut être traitée comme une requête HTTPS normale et peut être suivie avec les outils suivants :

  • Moniteur réseau : capture les traces sur le serveur d’origine pour vérifier la réception de la demande.
  • Journaux IIS : vérifie les journaux IIS pour les codes de réponse HTTP pour le contenu que vous effectuez le suivi.
  • Journaux IIS FREB : si la requête a été trouvée dans la trace réseau et que le code de réponse HTTP n’était pas 200, vous pouvez utiliser à nouveau FREB pour résoudre le problème.

Résolution des problèmes liés aux défaillances du cache

Vérifier les en-têtes Cache-Control

Vérifiez les en-têtes Cache-Control reçus du client. Cela peut être effectué conjointement avec la vérification des règles de contrôle du cache, car les en-têtes peuvent être configurés pour remplacer les en-têtes.

Passer en revue les règles Cache-Control dans ARR

Vérifiez les règles de contrôle du cache dans ARR pour vérifier si la mise en cache ARR est activée.

Vérifier les paramètres HTTP.SYS

Pour plus d’informations sur la raison pour laquelle le contenu n’est pas mis en cache par HTTP.sys dans le noyau, consultez Instances dans lesquelles HTTP.sys ne met pas en cache le contenu.

Échecs du cache de disque

ARR consigne les événements dans le journal des événements d’application lorsque des défaillances de disque se produisent et marquent le disque comme défectueux.

Log Name: Application 
Source: Application Request Routing 
Date: 11/2/2009 5:26:59 PM 
Event ID: 1006 
Task Category: None 
Level: Warning 
Keywords: Classic 
User: N/A 
Computer: 
Description: Drive with path '\?\E:\temp$\arrcache\' is being marked unhealthy. The data contains the error code. 
Event Xml:

Plus d’informations