Установка представляет собой один сервер (Windows 2008) в одном месте с двумя входящими подключениями. Поскольку сервер должен взаимодействовать с различными устройствами на объекте и будет иметь небольшое количество входящих подключений, дата-центр не является вариантом, и вместо этого необходимо использовать кабельные / DSL-соединения.
Цель состоит в том, чтобы пользователи посетили https://service.site.com и отправляются либо на основной IP-адрес, либо на дополнительный IP-адрес, если основной не работает.
Я видел совет использовать для этого циклический DNS, но я бы хотел избежать кеширования IP-адреса для неработающего интерфейса.
Возможно ли что-то подобное с этими ограничениями?
Большинство браузеров будет пробовать альтернативные доступные адреса, если первая попытка подключения не удалась. Но это, очевидно, зависит от реализации, для этого нет RFC-директивы или рекомендации. Так что если тебе нужно быть конечно, вам придется изменить свою зону DNS и удалить IP-адрес сбойной ссылки. Проблема кеширования может быть решена путем уменьшения TTL до низкого значения - 300 секунд - довольно распространенное явление и хороший компромисс между эффективностью кэширования и актуальностью данных.
Возможная проблема с DNS RR заключается в том, что нет способа указать какой-либо приоритет для записей DNS (кроме возможности использовать записи DNS SRV из-за отсутствия поддержки браузера), поэтому клиенты будут отправлять запросы на обе адресов за счет ротации записей в ответе DNS. Если одна из ваших ссылок «дороже» (в любых терминах), чем другая, и вы не будете использовать ее, если только основная ссылка не выйдет из строя, DNS RR не является правильным решением вашей проблемы.
Другой вариант - использовать обратный прокси-сервер в альтернативном месте / по альтернативному каналу (предположительно, имеющему лучшее время безотказной работы, чем ваша DSL / кабельная связь - например, виртуальная машина в центре обработки данных), который будет активно контролировать ваши два соединения и обрабатывать отказоустойчивость автоматически без необходимости изменять записи DNS.
Возможно ли что-то подобное с этими ограничениями?
Нет.
Если у вас есть балансировщик нагрузки с несколькими серверами за ним, существует требование, чтобы балансировщик нагрузки всегда был в сети. Есть несколько способов сделать это, например, балансировщик нагрузки на самом деле может быть не одним сервером - может быть много, которые притворяются одним сервером. Если один терпит неудачу, другой берет верх.
Однако есть предположение, что на удаленном конце есть что-то там для обслуживания запроса.
Если вы окажетесь в ситуации, когда ссылка обрывается, пакеты не будут доходить до вашего сервера - и вы ничего не можете с этим поделать. DNS RR - следующий лучший вариант, потому что вы говорите клиенту попробовать другой IP-адрес. В противном случае клиент будет весело повторять попытку того же IP, не получит ответа и откажется.
Чтобы все это работало, всегда должен быть доступен самый передний сервис. Без этого просто не может. Решения высокой доступности обычно предполагают, что ссылки хорошие. Да, есть такие вещи, как аварийное переключение на уровне центра обработки данных (например, для отключения питания на уровне страны), но они также связаны с временем простоя, если трафик будет сходиться на другой набор IP-адресов - он никогда не будет мгновенным.