Устранение неполадок с элементами кэша в ARR версии 2.0 или более поздней

Применимо к: службы IIS

Обзор

В этом пошаговом руководстве вы узнаете, как трассировать запрос по мере передачи ARR и отправляется на сервер следующего уровня и просмотреть сведения, которые можно получить, чтобы определить, откуда был отправлен запрос и откуда он был отправлен.

Средства, используемые в этом средстве устранения неполадок

• Вспомогательный помощник по ARR
• Трассировка неудачных запросов (FREB)
• Расширенное ведение журнала IIS
• Сетевой монитор

Общие сведения об архитектуре фермы

Первым шагом является понимание архитектуры среды, в том числе следующего.

• Топология фермы ARR (сколько серверов, как настроена маршрутизация, другие устройства)
• Правила переопределения URL-адресов на месте

В этом пошаговом руководстве можно использовать следующую конфигурацию для трассировки запроса.

Конфигурация кэша дисков

В следующем фрагменте кода показан локальный диск с максимальным размером 100 ГБ.

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

Правила управления глобальным кэшем

Это правило определяется как кэш в течение 60 минут, если директива управления кэшем не существует.

<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>

Создание плана сбора данных

В этом разделе описывается поток попаданий и пропусков кэша по мере их передачи через ARR, а также определение средств или журналов, которые можно использовать для изучения запросов. Следующие шаги описывают поток запросов для содержимого, который ранее не кэшировался с помощью конфигурации, предоставленной в качестве ссылки, и средств, используемых на каждом шаге.

• Запрошенный контент не найден локально (ни в памяти, ни на диске на дочернем узле).

  • Журналы FREB
  • Встроенные службы IIS для ведения журнала
  • Сетевой монитор

• Запрос перенаправлен на узел кэша следующего уровня (родительский узел).

  • Журналы FREB
  • Модуль расширенного ведения журнала IIS
  • Встроенные службы IIS для ведения журнала
  • Сетевой монитор

• Запрошенный контент не найден на узле кэша следующего уровня (ни в памяти, ни на диске). Повторяйте точку 2 столько раз, сколько нужно на основе иерархии кэша.

• Запрос пересылается на сервер-источник.

  • Журналы FREB
  • Встроенные службы IIS для ведения журнала
  • Сетевой монитор

Сбор данных

Запрошенный контент не найден локально (ни в памяти, ни на диске)

Здесь можно определить попадание или пропустить кэш в журналах IIS или журналах FREB. Журналы FREB предоставляют дополнительные сведения, например, где был перенаправлен запрос, что важно при наличии нескольких серверов нижнего уровня.

Запись журнала IIS . В поле cs-uri-query вы найдете следующие записи, определяющие попадание кэша или пропустить запрос и GUID запроса, который можно использовать для идентификации запроса на серверах нижнего уровня.

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.

Запись журнала FREB — кэш не найден записью ARR_DISK_CACHE_GET_FAILED.

Определите сервер, на который направляется запрос. Просмотрите запрос, отправляемый на сервер W2K8WEBSERVER2, который будет сервером следующего уровня для проверки данных.

В запрос переадресации добавляются следующие заголовки. Если некоторые имена отличаются от имен по умолчанию, таких как X-Forwarded-For, X-ARR-ClientCertи X-ARR-LOG-IDимена были настроены в параметрах прокси-сервера фермы серверов.

Запрос перенаправлен на узел кэша следующего уровня (родительский узел)

На предыдущем шаге вы определили этот сервер как W2K8WEBSERVER2. На этом шаге можно проверить следующие данные на этом сервере. Существует несколько точек данных, которые можно использовать. С помощью X-ARR-LOG-IDэтого запроса можно определить, достиг ли запрос этого сервера.

Журналы FREB— запрос может быть идентифицирован отправленным X-ARR-LOG-ID из дочернего узла. Он fe9d20da-a571-4451-8ef3-0e7faf1a463a был определен на предыдущем шаге.

Модуль расширенного ведения журнала IIS— с помощью расширенного ведения журнала можно добавлять настраиваемые поля ведения журнала на основе заголовков X-Forwarded-For , а X-ARR-LOG-ID затем использовать фильтрацию только при наличии этих заголовков.

#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"

Сетевой монитор — используйте трассировку для идентификации X-ARR-LOG-ID и X-Forwarded-For трассировки определенного запроса.

Вспомогательный модуль ARR — этот модуль добавляет X-Forwarded-For заголовок в поле и X-ARR-LOG-ID заголовок C-IP cs-uri-query в поле журналов IIS по умолчанию.

Повторите шаги 1 и 2 для нескольких уровней кэша

Если родительский узел W2K8WEBSERVER2 сервера настроен с помощью функций ARR и кэширования, может потребоваться проверить IISLOGS или FREB, чтобы узнать, был ли кэш хит или мисс, и решить, куда следует продолжить в зависимости от состояния входа кэша.

Запрос пересылается на сервер источника

Этот шаг можно рассматривать как обычный HTTPS-запрос и отслеживаться с помощью следующих средств:

• Сетевой монитор — записывает трассировки на сервере источника для проверки получения запроса.
• Журналы IIS — проверяет журналы IIS для кодов http-ответов для отслеживаемого содержимого.
• Журналы FREB IIS. Если запрос найден в трассировке сети и код ответа HTTP не был 200, возможно, потребуется снова использовать FREB для устранения проблемы.

Устранение неполадок кэша

Проверка заголовков элементов управления кэшем

Проверьте заголовки cache-Control, полученные от клиента. Это можно сделать вместе с проверкой правил управления кэшем, так как заголовки можно настроить для переопределения заголовков.

Проверка правил управления кэшем в ARR

Проверьте правила управления кэшем в ARR, чтобы проверить, включена ли кэширование ARR.

Проверка параметров HTTP.SYS

Дополнительные сведения о том, почему содержимое не кэшировано HTTP.sys в ядре, см. в примерах, в которых HTTP.sys не кэширует содержимое.

Сбои кэша дисков

ARR регистрирует события в журнал событий приложения при сбое диска и помечает диск как неработоспособный.

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: 

Дополнительная информация

• Причины, по которым содержимое не кэшируется HTTP.sys в ядре
• Сетевой монитор