Устранение неполадок, связанных со сбоем диспетчера трафика
В этой статье описывается устранение неполадок в профиле диспетчера трафика 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
О методах маршрутизации трафика в диспетчере трафика