Среди прочего, Nginx описывает конфигурацию для «Active-Active HA для NGINX Plus на AWS с использованием AWS Network Load Balancer». AWS NLB (балансировщик сетевой нагрузки) балансирует соединения на уровне 4 OSI с nginx серверами за ним, которые выполняют балансировку нагрузки приложений уровня 7. У нас аналогичная настройка (с использованием nginx, а не NGINX Plus) и мы хотим использовать балансировщик сетевой нагрузки, потому что у нас есть широкий спектр поступающего трафика, и в настоящее время нам нужно 4 nginx сервера для обработки всего этого. Нам нужно все, от балансировки нагрузки UDP до HTTP/2 и WebSockets.
Очевидная отсутствующая функция в Пример Nginx заключается в том, что он не поддерживает TLS. Нам нужно поддерживать TLS. В идеале мы бы поддерживали TLS, отключив TLS от NLB, но, хотя Amazon недавно добавила эту возможность в свой NLB, мы используем Kubernetes 1.12 и интеграция завершения NLB TLS настолько сложна, что была отложена до Kubernetes 1.15, причем перенос даже на 1.14 был отклонен как слишком сложный. Поэтому, пока мы ждем, пока kops и EKS наверстают упущенное, и учитывая, как трудно было сделать это правильно разработчикам, которые это сделали, мы собираемся продолжать прекращать TLS на серверах nginx.
В основном это работает, но, как вы, возможно, знаете, рукопожатие SSL стоит очень дорого, и мы хотели бы сократить эти расходы. nginx предоставляет 2 способа уменьшить количество рукопожатий. Первый, отправляющий несколько запросов по одному соединению TCP/TLS, отлично работает с NLB, и мы используем его настолько, насколько его поддерживают клиенты наших клиентов. К сожалению, второе, «повторное использование параметров сеанса SSL, чтобы избежать рукопожатий SSL для параллельных и последующих подключений», не работает. Чтобы повторно использовать параметры сеанса SSL, каждое рукопожатие SSL создает сеанс SSL, и будущие соединения могут использовать эти параметры сеанса, указав идентификатор сеанса SSL. Это позволяет веб-браузеру открывать 6 параллельных TCP-соединений, при этом требуется только одно полное рукопожатие SSL (для первого соединения), а остальные 5 используют один и тот же сеанс SSL.
nginx предоставляет ssl_session_cache для отслеживания этих сеансов на стороне сервера. , но, как задокументировано, это не более чем один кеш, совместно используемый всеми рабочими процессами на одном сервере. Это отлично при использовании только 1 сервера и лучше, чем ничего при использовании более одного, но на практике с 4 серверами это мало помогает. Если все 6 подключений браузера не перейдут на один и тот же сервер, одно подключение будет отправлено на сервер, который отклоняет идентификатор сеанса, что приведет к повторному запуску рукопожатия и аннулированию предыдущего идентификатора сеанса для новых подключений, даже если они все еще могут быть действительными, если это необходимо. маршрутизированный.
Решение, которое приходит на ум, состоит в том, чтобы использовать что-то вроде memcached для расширения ssl_session_cache, чтобы все nginx серверы иметь такой же кеш. (По разным причинам мы предпочли бы не использовать билеты сеанса SSL, одна из наиболее убедительных из которых заключается в том, что в нашей конкретной ситуации многие наши клиенты не будут их использовать.) Я вижу, что kubernetes/ingreses-nginx перешел с использования nginx на OpenResty, потому что он использует nginx и добавляет lua поддержку и lua модулей, а также наличие модуль lua для memcached, но я не знаю, как ориентироваться во всей этой интеграции модулей lua. Документация, которую я нашел в модуле memcached, предполагает, что он предназначен для кэширования контента, а не для чего-то внутреннего, такого как кэширование сеансов SSL.
Итак, (1) есть ли какой-то готовый способ для nginx с открытым исходным кодом или OpenResty для совместного использования ssl_session_cache на нескольких серверах? и (2) кажется ли разумным попытаться создать общий кеш из lua модулей, и если да, то как мне это сделать?
