Устранение неполадок, связанных со сбоем диспетчера трафика
В этой статье описывается устранение неполадок в профиле диспетчера трафика Azure, который находится в состоянии пониженной функциональности. В качестве первого шага при устранении неполадок в состоянии ухудшенной работоспособности Диспетчера трафика Azure необходимо включить ведение журнала. Дополнительные сведения см. в разделе Включение журналов ресурсов. Для этого сценария предположим, что вы настроили профиль диспетчера трафика, указывающего на некоторые из размещенных служб .cloudapp.net. Если в диспетчере трафика отображается состояние Деградация, одна или несколько конечных точек также могут иметь состояние Деградация.
Если в диспетчере трафика отображается состояние Неактивно, обе конечные точки могут находиться в режиме Отключено.
Общие сведения о проверках диспетчера трафика
- Диспетчер трафика считает, что конечная точка работает В СЕТИ, только если из пути проверки получен ответ HTTP 200. Если приложение возвращает любой другой код ответа HTTP, необходимо добавить этот код ответа в ожидаемые диапазоны кодов состояния профиля Диспетчера трафика.
- Ответ "Перенаправление 30x" обрабатывается как сбой, если вы не указали его как допустимый код ответа в ожидаемых диапазонах кода состояния своего профиля Диспетчера трафика. Диспетчер трафика не проверяет цель перенаправления.
- При проверках HTTP ошибки сертификата пропускаются.
- Фактическое содержимое пути проверки не имеет значения, если возвращается ответ 200. Как правило, URL-адрес проверяется на наличие статического содержимого, например /favicon.ico. Динамическое содержимое, например страницы поставщика услуг по предоставлению приложений в аренду (ASP), может не всегда возвращать ответ 200, даже если приложение работоспособно.
- Мы рекомендуем указать путь пробы, содержащий достаточную логику, чтобы определить, работает сайт или нет. В предыдущем примере, указав путь к /favicon.ico, вы проверяли, отвечает ли w3wp.exe. Эта проверка может не показать, работоспособно ли веб-приложение. Лучше было бы задать путь к элементу, например /Probe.aspx, содержащему логику для определения работоспособности сайта. Например, можно использовать счетчики производительности для определения загрузки ЦП или определить число неудачных запросов. Кроме того, можно попытаться получить доступ к ресурсам базы данных или состоянию сеанса, чтобы убедиться, что веб-приложение работает.
- Если функциональность всех конечных точек в профиле снижена, то диспетчер трафика будет считать их работоспособными и будет перенаправлять трафик во все конечные точки. Такое поведение гарантирует, что проблемы с механизмом проверки не приведут к сбою службы.
Устранение неполадок
Чтобы устранить сбой проверки, необходимо средство, позволяющее просмотреть код состояния HTTP, возвращаемый после проверки URL-адреса. Существует множество средств, позволяющих просмотреть необработанный ответ HTTP:
Кроме того, для просмотра ответа HTTP можно воспользоваться вкладкой "Сеть" средств отладки F12 в Internet Explorer.
В этом примере нам нужно вывести ответ, полученный с пробного URL-адреса: http://watestsdp2008r2.cloudapp.net:80/Probe. Проблема продемонстрирована в приведенном ниже примере PowerShell.
Invoke-WebRequest 'http://watestsdp2008r2.cloudapp.net/Probe' -MaximumRedirection 0 -ErrorAction SilentlyContinue | Select-Object StatusCode,StatusDescription
Выходные данные примера:
StatusCode StatusDescription
---------- -----------------
301 Moved Permanently
Обратите внимание, что получен ответ перенаправления. Как упоминалось ранее, любое состояние кода, отличное от 200, свидетельствует о сбое. Диспетчер трафика изменяет состояние конечной точки на Offline (Не в сети). Для решения проблемы проверьте конфигурацию веб-сайта, чтобы обеспечить возврат соответствующего кода состояния из пути проверки. Перенастройте проверку диспетчера трафика таким образом, чтобы она указывала на путь, возвращающий ответ 200.
Если при проверке используется протокол HTTPS, может потребоваться отключить проверку сертификата во избежание ошибок SSL/TLS. Следующая инструкция PowerShell отключает проверку сертификата в текущем сеансе PowerShell:
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
Next Steps
О методах маршрутизации трафика в диспетчере трафика