Шлюз служб удаленных рабочих столов за проблемами подключения AWS ALB
Я настроил шлюз служб удаленных рабочих столов за AWS ALB.
AWS ALB выполняет разгрузку SSL и общается с сервером шлюза RDS через HTTP (порт 80) .
Конфигурация работает, и я могу подключаться по протоколу RDP к экземплярам за шлюзом RDS, но очень часто (я бы сказал, каждые 15-20 минут в среднем) сеанс RDP тратит несколько секунд (5-10) на повторное подключение.
Есть ли у ALB проблемы с очень длинными соединениями, продолжающимися несколько минут? Каковы возможные основные причины таких частых повторных подключений?
** ОБНОВЛЕНИЕ С ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИЕЙ **
Тайм-аут простоя ALB установлен на 4000 секунд.
Настройка кажется такой работают нормально для клиентов Windows RD (в данном случае повторного подключения нет).
Однако с клиентом Microsoft RD для Mac 10.3.9 (1767), работающим на Catalina 10.15.3, мы часто сталкиваемся с повторным подключением (каждые 5– 20 минут) и случайные зависания.
Журнал клиента Microsoft RD для Mac в /var/log/systemd.log не сообщает ничего особенного, когда происходит повторное подключение.
Журнал IIS на машине шлюза RDS не сообщает тоже ничего особенного (похоже, не регистрируются RDG_IN_DATA и RDG_OUT_DATA). Он регистрирует только проверку статуса ELB и случайные несанкционированные посещения ALB.
Журнал AWS ALB, отправленный на S3, действительно сообщает о последовательности RDG_OUT_DATA и RDG_IN_DATA во время повторного подключения. Первый - это RDG_OUT_DATA с кодом состояния 200 и значительным количеством полученных байтов, за ним следуют два RDG_OUT_DATA с кодом состояния 401, затем два RDG_IN_DATA с кодом состояния 401 и, наконец, RDG_IN_DATA с кодом состояния 200 до следующего повторного подключения.
Если клиент Mac используется непосредственно со шлюзом RDS без промежуточного AWS, он работает нормально (нет повторных подключений / зависаний каждые 5–20 минут).
Для каждого запроса, клиент делает через балансировщик нагрузки, балансировщик нагрузки поддерживает два соединения. Внешнее соединение устанавливается между клиентом и балансировщиком нагрузки, а внутреннее соединение — между балансировщиком нагрузки и целью. Балансировщик нагрузки управляет тайм-аутом простоя, который инициируется, когда данные не отправляются по интерфейсному соединению в течение заданного периода времени. Если к моменту времени ожидания простоя данные не были отправлены или получены, балансировщик нагрузки закрывает соединение.
По умолчанию Elastic Load Balancing устанавливает значение тайм-аута простоя равным 60 секундам. Поэтому, если цель не отправляет какие-либо данные по крайней мере каждые 60 секунд, пока запрос находится в процессе выполнения, подсистема балансировки нагрузки может закрыть интерфейсное соединение. Чтобы гарантировать, что длительные операции, такие как загрузка файлов, успеют завершиться, отправьте по крайней мере 1 байт данных до истечения каждого периода простоя и увеличьте продолжительность периода простоя по мере необходимости.
Для внутренних подключений мы рекомендуем вам включить опцию поддержания активности HTTP для ваших инстансов EC2. Вы можете включить поддержку активности HTTP в настройках веб-сервера для ваших инстансов EC2.Если вы включите поддержку активности HTTP, балансировщик нагрузки сможет повторно использовать внутренние соединения, пока не истечет время ожидания проверки активности. Мы также рекомендуем настроить тайм-аут простоя вашего приложения так, чтобы он был больше, чем тайм-аут простоя, настроенный для балансировщика нагрузки.
Для получения дополнительной информации см. эту статью Балансировщики нагрузки приложений