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

Vue d’ensemble

Dans cette procédure pas à pas, vous pouvez apprendre à suivre une requête lorsqu’elle passe par ARR et est envoyée à un serveur de niveau supérieur, et examinez les informations qui peuvent être acquises pour déterminer où la demande a été envoyée et d’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, notamment les éléments suivants.

  • Topologie de batterie de serveurs ARR (nombre de serveurs, mode de 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 les demandes de cache.

Configuration du cache de disque

L’extrait de code suivant montre qu’un lecteur local d’une taille maximale de 100 Go est configuré.

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

Règles de contrôle du cache global

Cette règle est définie en tant que 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 échecs pendant qu’ils transitent 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é mis en cache précédemment à l’aide de la configuration fournie comme référence et des 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 requête 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 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é n’est pas trouvé localement (ni en mémoire ni sur disque)

Ici, vous pouvez identifier un accès ou une absence dans le cache dans les journaux IIS ou 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 de journal IIS : vous trouverez les entrées suivantes dans le champ cs-uri-query qui identifie le hit ou le manque du cache et le GUID de la requête, qui peuvent être utilisés pour identifier la requête sur les 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 avertissement ARR_DISK_CACHE_GET_FAILED FilePath="\ ?\C:\ARRCache\localhost\iisstart.htm.full », ErrorCode="Le système ne trouve pas le fichier spécifié. (0x80070002) », IsRangeEntry="false », RangeOffset="0 », RangeSegmentSize="0 »

Identifiez le serveur vers lequel la requête est acheminée. Observez la requête 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 de transfert. Si certains noms sont différents des noms par défaut, tels que X-Forwarded-For, X-ARR-ClientCertet X-ARR-LOG-ID, les noms ont été personnalisés dans les paramètres de proxy de la 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 requête 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étant . 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 , vous pouvez identifier si la requête a atteint ce serveur.

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

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

IIS Advanced Logging Module : à l’aide de la journalisation avancée, vous pouvez ajouter des champs de journalisation personnalisés en fonction des en-têtesX-Forwarded-For, X-ARR-LOG-ID puis utiliser le filtrage pour journaliser uniquement lorsque ces en-têtes 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-IDX-Forwarded-For si vous souhaitez effectuer le suivi d’une requête 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.

Remarque

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 arr et les fonctionnalités de mise en cache, vous devrez peut-être case activée IISLOGS ou FREB pour voir s’il y a eu un accès ou un échec dans le cache et décider où procéder en fonction de l’entrée de ce cache status.

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 rechercher les codes de réponse HTTP pour le contenu que vous suivez.
  • Journaux FREB IIS : si la requête a été trouvée dans la trace réseau et que le code de réponse HTTP n’était pas un 200, vous pouvez utiliser à nouveau FREB pour résoudre le problème.

Résolution des échecs de cache

Vérifier Cache-Control en-têtes

Vérifiez Cache-Control les en-têtes 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 HTTP.SYS paramètres

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 enregistre les événements dans le journal des événements de l’application lorsque des défaillances de disque se produisent et marquez le disque comme non sain.

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