Веб-сайт Azure не обнаруживает изменения диспетчера трафика
У меня есть веб-сайт Azure (website.mycompany.com), который использует службу WCF для некоторых данных. Служба WCF находится позади диспетчера трафика Azure (service.mycompany.com), работающего в "режиме приоритета", с двумя экземплярами службы для обработки отработки отказа. В режиме приоритета первичный сервер всегда обслуживает данные в первую очередь, если он недоступен. Если недоступен, второй экземпляр ответит... и так далее по линии.
Недавно у нас было несколько случаев, когда основная конечная точка для service.mycompany.com была отключена. Для "партнеров", которые указывают на service.mycompany.com, они обнаружили переключатель, и все было в порядке. Однако в последнее время наш собственный сайт (website.mycompany.com) НЕ обнаруживает переключение диспетчера трафика, и на сайте есть ошибки, так как служба не отвечает.
Наша конечная точка аварийного переключения в этих случаях работала, и в прошлом веб-сайт Azure обнаруживал переключение, только недавно мы столкнулись с этой проблемой. Кто-нибудь сталкивался с подобными проблемами? Возможно, есть какие-то изменения DNS, которые нам нужно настроить на нашем веб-сайте Azure, чтобы он мог определять TTL?
2 ответа
Кто-нибудь сталкивался с подобными проблемами?
Вы имеете в виду, что диспетчер трафика не может сразу переключиться на другую конечную точку?
Диспетчер трафика работает на уровне DNS, вот причины, по которым диспетчер трафика не может переключиться немедленно:
Длительность кэша определяется свойством "время жизни" (TTL) каждой записи DNS. Более короткие значения приводят к более быстрому истечению срока действия кэша и, таким образом, к увеличению количества обращений к серверам имен Traffic Manager. Более длинные значения означают, что может потребоваться больше времени для направления трафика от отказавшей конечной точки.
Монитор конечной точки диспетчера трафика влияет на время отклика. Более подробную информацию о том, как работает менеджер трафика Azure, смотрите по ссылке.
Следующая временная шкала является подробным описанием процесса мониторинга.
Также мы можем проверить профиль диспетчера трафика, используя nslookup и ipconfig в Windows. О том, как проверить настройки диспетчера трафика, смотрите по ссылке.
Кстати, поскольку диспетчер трафика работает на уровне DNS, он не может влиять на существующие соединения с какой-либо конечной точкой. Когда он направляет трафик между конечными точками (либо измененными настройками профиля, либо во время восстановления после сбоя или возврата при сбое), Traffic Manager направляет новые соединения доступным конечным точкам. Однако другие конечные точки могут продолжать получать трафик через существующие соединения, пока эти сеансы не будут завершены. Чтобы разрешить пропуск трафика из существующих подключений, приложения должны ограничивать продолжительность сеанса, используемую с каждой конечной точкой.
Я собираюсь отослать вас к моему ответу здесь, потому что, хотя ситуация не совсем такая, похоже, что у нее могло бы быть то же самое решение. Подводя итог, я нахожу вероятным, что у вас есть открытое соединение с отключенным сервисом, которое не закрывается должным образом. Это соединение не зависит от TTL, которое имеет дело только с DNS-кэшированием и поэтому полностью обходит Traffic Manager.