Помимо прочего, Nginx описывает конфигурацию для " Active-Active HA для NGINX Plus на AWS с использованием AWS Network Load Balancer ". AWS NLB (балансировщик сетевой нагрузки) балансирует соединения на уровне OSI 4 с 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 подключений к браузеру не будут подключены к одному и тому же серверу, одно подключение будет отправлено на сервер, который отклоняет идентификатор сеанса, вызывая его возобновление рукопожатия и аннулируя предыдущий идентификатор сеанса для новых подключений, даже если они все еще могут быть действительными, если это необходимоrouted.
Решение, которое приходит на ум, состоит в том, чтобы использовать что-то вроде 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, и если да, то как мне на самом деле это сделать?