Использование диспетчера трафика, как уменьшить проблему недоступности службы, вызванную TTL

Я использую диспетчер трафика для балансировки нагрузки нашего трафика на службы, размещенные в другом центре обработки данных. Проблема в том, что когда клиент запрашивает диспетчер трафика, диспетчер трафика отвечает с IP-адресом с настройкой TTL (скажем, 5 минут), тогда клиент будет запрашивать этот IP-адрес в течение 5 минут. Если служба, размещенная на этом IP-адресе, не работает в течение 5 минут, клиент получит сообщение об ошибке недоступности службы. Что я могу сделать, чтобы смягчить эту проблему? Может ли шлюз приложений помочь?


person Youxu    schedule 15.06.2016    source источник


Ответы (1)


Продолжительность кэширования DNS-ответов диспетчера трафика определяется параметром DNS «TTL». Вы можете изменить это в настройках диспетчера трафика — текущий минимум составляет 30 секунд. Дополнительные сведения о том, как работает отработка отказа конечной точки диспетчера трафика, приведены здесь.

Шлюз приложений Azure обеспечивает подход к маршрутизации трафика на основе прокси-сервера, а не на основе DNS, и, таким образом, действительно позволяет избежать проблемы кэширования DNS. Между этими двумя подходами существуют различные различия, кратко изложенные здесь.

С уважением,

Джонатан Тулиани, руководитель программы, диспетчер трафика Azure

person Jonathan Tuliani - MSFT    schedule 15.06.2016
comment
Спасибо быстрый ответ! В документе здесь я увидел это утверждение для Шлюза приложений: интервал проверки бездействия 30 секунд. Сбрасывается после 5 последовательных сбоев трафика в реальном времени или одного сбоя зонда в режиме ожидания. Означает ли это, что трафик по-прежнему можно направить на неисправную конечную точку до того, как неисправная конечная точка будет отключена после 5 последовательных сбоев? - person Youxu; 15.06.2016