Веб-сайт Azure не обнаруживает изменение диспетчера трафика

У меня есть веб-сайт Azure (website.mycompany.com), на котором для некоторых данных используется служба WCF. Служба WCF находится за диспетчером трафика Azure (service.mycompany.com), работающим в «приоритетном режиме», с двумя экземплярами службы для обработки отказа. В режиме приоритета первичный всегда обслуживает данные первым, если он не недоступен. Если он недоступен, ответит 2-й экземпляр… и так далее по строке.

Недавно у нас было несколько случаев, когда основная конечная точка для service.mycompany.com была отключена. Для "партнерств", которые указывают на service.mycompany.com, они обнаружили переключатель, и все было в порядке. Однако в последнее время наш собственный сайт (website.mycompany.com) НЕ обнаруживает переключатель диспетчера трафика, и на веб-сайте возникают ошибки, поскольку служба не отвечает.

Наша конечная точка аварийного переключения в этих случаях работает, и в прошлом веб-сайт Azure обнаруживал коммутатор, только недавно мы столкнулись с этой проблемой. Кто-нибудь сталкивался с подобными проблемами? Возможно, есть какие-либо изменения DNS, которые нам нужно настроить на нашем веб-сайте Azure, чтобы помочь ему определять TTL?


azure azure-web-app-service azure-traffic-manager
person ewitkows    schedule 10.04.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Кто-нибудь сталкивался с подобными проблемами?

Вы имеете в виду, что диспетчер трафика не может сразу переключиться на другую конечную точку?

Диспетчер трафика работает на уровне DNS, вот причины, по которым диспетчер трафика не может переключиться сразу:

  1. Продолжительность кеширования определяется свойством «время жизни» (TTL) каждой записи DNS. Более короткие значения приводят к более быстрому истечению срока действия кеша и, следовательно, к большему количеству обращений к серверам имен диспетчера трафика. Более длинные значения означают, что направление трафика от отказавшей конечной точки может занять больше времени.

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

  3. Также мы можем проверить профиль диспетчера трафика с помощью nslookup и ipconfig в Windows. О том, как проверить настройки диспетчера трафика, см. ссылка.

Кстати, поскольку диспетчер трафика работает на уровне DNS, он не может влиять на существующие подключения к какой-либо конечной точке. Когда он направляет трафик между конечными точками (либо путем изменения настроек профиля, либо во время отработки отказа или восстановления после отказа), диспетчер трафика направляет новые подключения к доступным конечным точкам. Однако другие конечные точки могут продолжать получать трафик через существующие соединения до тех пор, пока эти сеансы не будут завершены. Чтобы трафик мог отводиться от существующих подключений, приложениям следует ограничить продолжительность сеанса, используемого с каждой конечной точкой.

person Jason Ye    schedule 11.04.2017
comment
Пожалуйста, дайте мне знать, если вам нужна дополнительная помощь. - person Jason Ye; 14.04.2017

arrow_upward
0
arrow_downward

Я отсылаю вас к своему ответу здесь, потому что, хотя ситуация не совсем такая же, похоже, что у нее может быть такое же решение. Подводя итог, я считаю вероятным, что у вас осталось соединение с неработающей службой, которое не закрывается должным образом. Это соединение не зависит от TTL, которое имеет дело только с кэшированием DNS и, как таковое, полностью обходит диспетчер трафика.

person dornadigital    schedule 03.08.2017