Существует ли программный балансировщик нагрузки Linux HA, который обслуживает HTTPS для нескольких несвязанных доменных имен, но балансирует в одном кластере веб-сервера?
У меня есть мультитенантное SaaS-приложение на основе облака (Amazon AWS, Rackspace и т. Д.), И мне нужно поддерживать связь HTTPS для нескольких не связанных между собой доменов-арендаторов.
В качестве иллюстративного примера предположим, что наш SaaS доступен по адресу:
https://foo.com
Арендаторы могут получить доступ к своему пользовательскому интерфейсу и конечным точкам обслуживания через:
https://tenantA.foo.com
https://tenantB.foo.com
...
Это легко поддержать сегодня с одним подстановочным SSL-сертификатом.
Тем не менее, с нашим SaaS, наши арендаторы могут пожелать предоставить наш пользовательский интерфейс (но для них) непосредственно своим пользователям.
Это вызывает проблему: скажем, Джон Смит является существующим клиентом tenantA (и не знает foo.com). Если Джон Смит направлен на https://tenantA.foo.com, они могут легко запутаться (например, "кто, черт возьми, foo.com? Почему я здесь? Меня взломали? Ааааа!").
Чтобы избежать этой проблемы, наши арендаторы должны создать подобласть:
https://foo.tenantA.com
Это позволяет избежать путаницы среди конечных пользователей: tenantAпользователи могут видеть URL, который они распознают как принадлежащий tenantA и будет более охотно использовать приложение. Но tenantA хочет, чтобы мы разместили все о приложении, что означает foo.comИнфраструктура должна обслуживать соединение SSL.
Для этого мы хотим поддержать следующее:
- Арендатор загружает нам сертификат SSL + для
foo.tenantA.com, - Мы берем этот сертификат SSL и динамически устанавливаем его в высокодоступный кластер балансировки нагрузки (2 или более узлов LB), который запрашивает балансировку нагрузки для веб-конечных точек нашего приложения SaaS.
- Арендатор обновляет свой DNS, чтобы иметь
foo.tenantA.comбыть перенаправленным на CNAMEtenantA.foo.com,
Таким образом, наш пул балансировки нагрузки будет обслуживать / прерывать все соединения HTTPS с foo.tenantA.com и все запросы сбалансированы по нагрузке на наш кластер веб-серверов SaaS.
Это означает, что сертификаты SSL должны быть добавлены и удалены из пула LB во время выполнения. Изменения не могут прервать возможность обслуживания существующих или новых запросов HTTPS.
Кроме того, поскольку мы будем развертывать на виртуализированном оборудовании (например, EC2) с Linux, у нас нет доступа к оборудованию / центру обработки данных. Это должно быть программное решение, которое может работать в Linux. Он также должен быть высокодоступным (2 или более LB-узлов).
Кто-нибудь знает о конкретном решении? Например, можно ли настроить Nginx, HAProxy или Squid (или что-либо еще) для поддержки этого? Существует ли "рецепт" или существующее решение, которое задокументировано и подходит?
PS Elastic Load Balancer (на момент написания статьи) от Amazon не может прагматически удовлетворить эту потребность - для каждого домена клиента потребуется Amazon ELB. Поскольку каждый ELB должен "пинговать" веб-серверы, если бы у вас было 500 арендаторов, у вас было бы 500 ELB, которые пинговали бы конечные точки веб-службы SaaS, что является немаловажным отрицательным ударом по производительности.
2 ответа
Обновление 2017-09-13: SNI стал достаточно распространенным в основных браузерах, поэтому его, вероятно, можно использовать для ответа на запрос, и этот ответ следует считать устаревшим.
Единственный способ поддержать это - иметь IP для каждого из ваших клиентов. Когда вы подключаетесь через https, соединение немедленно шифруется, и браузер не может сказать "Я здесь для foo.tenantA.com". Таким образом, единственный способ для сервера узнать, какой сертификат SSL следует использовать для шифрования соединения, основан на IP-адресе, с которого было установлено соединение.
Теперь это все еще возможно, но это означает, что вам понадобится много IP-адресов. Мы на самом деле делаем эту точную настройку на моей работе. У нас есть 2 активных / активных балансировщика нагрузки: половина IP-адресов на одном балансировщике, другая половина - на другом балансировщике (всего около 500 IP-адресов). Тогда у нас есть несколько веб-серверов, которые принимают все соединения. Любой веб-сервер может выйти из строя, и балансировщик нагрузки перестанет отправлять ему соединения. Или сам балансировщик нагрузки может выйти из строя, а другой получит все свои IP-адреса.
Программное обеспечение для балансировки нагрузки, которое делает это, - Pacemak er и ldirectord (оба являются основными проектами, и любой дистрибутив, который вы запускаете, должен иметь их в своем хранилище). Ядро Linux - это то, что фактически выполняет балансировку нагрузки, а программное обеспечение просто отвечает за обработку отказов.
Примечание. Для балансировки нагрузки существует множество альтернатив ldirectord, таких как k eepalived и surealived. Хотя для реального программного обеспечения для отработки отказа балансировщика нагрузки вам следует использовать кардиостимулятор.
Основные руководства:
Это даст основные инструкции по настройке кардиостимулятора. Вы можете пропустить все предыдущие вещи, так как CMAN является его заменой. Единственное, что вам нужно сделать, чтобы добраться до этой точки в руководстве, - это установить кардиостимулятор и его зависимости. Остановитесь в разделе 8.2.4. Вам не нужно переходить к разделу 8.3, поскольку это не имеет отношения к тому, что вы делаете.
Как только у вас будет работать кардиостимулятор, это обеспечит очень простую конфигурацию для балансировки нагрузки http-сервера.
Вы также можете посмотреть на это и это. Это скорее обзор кардиостимулятора более высокого уровня, что он делает и как его использовать.
А как насчет того, чтобы порекомендовать вашему клиенту надеть на него тонкую обертку? Что-то вроде этого:
- Конечный пользователь отправляет запрос
https://api.tenantA.com api.tenantA.comпросто направляет запросhttps://tenanta.foo.com- Ответ затем фильтруется обратно таким же образом.
Я предполагаю, что до тех пор, пока это более сложный случай, он должен работать нормально.