Рекомендации по переключению при отказе прокси
Обзор
В настоящее время я развертываю пару устройств брандмауэра высокой доступности, которые будут действовать как прозрачный прокси-сервер (трафик будет направляться через прокси-сервер) через маршрутизацию, а не настраивать URL-адрес прокси на клиентских машинах) для исходящего трафика. У меня есть конфигурация высокой доступности, которая работает, и я вижу, что состояние сеанса разделяется между обоими устройствами. Когда запускается аварийное переключение, пассивное устройство будет предполагать IP-адреса (фактически, весь сетевой адаптер перемещается, поскольку он находится на AWS) ранее активного экземпляра.
Процесс подключения
Клиент - -> брандмауэр / прокси - -> веб-сервер
Проблема
В качестве теста я настраиваю веб-сервер и создаю съел большой html файл. Затем я использовал клиентскую машину, чтобы получить этот файл с помощью wget и curl (через свои прокси), и во время загрузки файла я выполнил ручной переход на другой ресурс. Когда я выполнил аварийное переключение, загрузка wget (то же самое произошло с curl) застряла. Затем я добавил тайм-ауты подключения и время ожидания команды wget истекло, а затем перезапустил загрузку, которая работала нормально, хотя я мог видеть, что был создан новый сеанс. Следует отметить, что это облачная установка, в которой время переключения при отказе намного медленнее, чем на локальных устройствах с высокими техническими характеристиками, поэтому для завершения переключения может потребоваться от 15 до 60 секунд. Я пытаюсь убедиться, что мое развертывание не сильно повлияет на приложения, которые в основном будут отправлять HTTP-трафик.
Вопросы
Разумно ли ожидать продолжения загрузки HTTP после аварийного переключения, если состояние сеанса синхронизируется через Устройства высокой доступности или клиенту следует использовать тайм-ауты и повторные попытки, чтобы начать загрузку снова?
Могу ли я потребовать, чтобы группы приложений изменили свои настройки времени ожидания и повторных попыток? Что считается нормальным для настроек тайм-аута и повтора для приложений, которые регулярно отправляют запросы API? Я надеюсь, что командам разработчиков приложений не придется что-либо менять на своей стороне после того, как я разверну это.
Есть ли способ предотвратить зависание wget или curl во время загрузки, когда соединение временно прерывается на срок до минуты и автоматически продолжается после восстановления соединения на устройстве, которое приняло на себя активную роль? Я знаю, что вы можете прервать запрос и продолжить загрузку с того места, где он был остановлен, но это не то, что группы приложений будут делать.
Я в основном заменяю шлюзы NAT на AWS на пару брандмауэров Nextgen с высокой доступностью с синхронизацией сеанса и возможности проверки, и я не хочу, чтобы это вызвало какие-либо проблемы в работе.
Основываясь на вашем описании, «прозрачный прокси» — это настоящий прокси, который завершает соединения TCP и даже завершает SSL в вашем случае. Это означает, что между клиентом и прокси-сервером, а также между прокси-сервером и сервером будет установлено TCP-соединение, независимо от фактического адреса назначения, используемого клиентом (прозрачный прокси).
В связи с этим для каждого TCP-соединения, инициированного клиентом, будет два TCP-соединения (клиент-прокси и прокси-сервер), которые имеют свое собственное состояние, сохраняемое в ядре операционной системы брандмауэра. Кроме того, существует некоторое состояние уровня приложения для HTTP, а также для части TLS — оба хранятся в прокси-приложении, то есть в пользовательском пространстве.
Разумно ли ожидать, что загрузка HTTP будет продолжена после отработки отказа, или клиент должен использовать тайм-ауты и повторять попытки, чтобы начать загрузку снова?
Даже если вам удастся синхронизировать состояния TCP-соединений между брандмауэрами (которые Я сомневаюсь, что это возможно, поскольку они заканчиваются на брандмауэре), вы не сможете синхронизировать состояние приложения (например, HTTP и TLS). Это означает, что существующее соединение не может быть продолжено на другом брандмауэре. Таким образом, клиенту необходимо повторить запрос.
Может ли мне понадобиться, чтобы команды приложений изменили настройки тайм-аута и повторных попыток? Что считается нормальным для настроек времени ожидания и повторных попыток для приложений, которые регулярно отправляют запросы API?
Зависит от варианта использования, приложения и того, как часто проблема будет возникать на практике (т. е. как часто будет сбой брандмауэра). Обратите внимание, что невозможно повторить все запросы, т.е.следует повторять только идемпотентные запросы (которые не изменяют состояния на сервере). Обычно это означает GET, но не POST, хотя не все веб-приложения ведут себя таким образом.
Действительно ли совместное использование сеансов TCP между прокси-устройствами подходит только для чисто TCP-соединений (соединений с базой данных и т. д.) и есть ли реальная польза от совместного использования сеансов для HTTP-соединений?
Как я уже сказал, совместного использования TCP-соединений недостаточно. для HTTP и еще меньше для TLS. Совместного использования состояния HTTP недостаточно, если задействован HTTPS. Я знаю только теоретические работы о том, как совместно использовать состояние HTTP и TLS между системами брандмауэров в кластере высокой доступности, и никаких практических реализаций — это было бы довольно сложно, много накладных расходов, даже если не произойдет аварийного переключения, и, вероятно, оно того не стоит.