Назад | Перейти на главную страницу

Высокая доступность для веб-сайта SSL

Один из наших кластеров веб-серверов обслуживает умеренное количество загруженных приложений электронной коммерции. В настоящее время каждый сайт находится на определенном веб-сервере и имеет копию горячего резервирования, зеркально отображаемую на другом веб-сервере в кластере. Если сервер выходит из строя, существует ручной процесс повторной активации сайтов на их отказоустойчивом сервере. Мы приближаемся к тому моменту, когда нам нужно лучшее решение не только для отказов, но и для того, чтобы мы могли останавливать машины для обслуживания без простоев для сайтов.

Мы рассматриваем возможность создания кластера из 2-3 человек. HAProxy серверы (в первую очередь потому, что у него отличная производительность), чтобы поставить его перед веб-серверами. Судя по тому, что я прочитал, он удовлетворит большинство наших потребностей в управлении сеансами и удержании пользователей на одном сервере и т. Д. Наша самая большая проблема связана с сертификатами SSL. У каждого из сайтов есть собственный SSL-сертификат. Поскольку конечные пользователи будут подключаться к серверам HAProxy, я могу только предположить, что нам нужно будет переместить сертификаты на каждую из машин в кластере HAProxy. Поскольку HAProxy не обрабатывает SSL напрямую, я читал, что мы можем сделать это с помощью Apache + mod_ssl в той же системе с помощью механизма пересылки типа обратного прокси.

Итак, мой конкретный вопрос: действительно ли HAProxy является подходящим инструментом для работы? Будут ли существующие сертификаты SSL (в настоящее время на Windows 2003 Server некоторые являются сертификатами EV-SSL) переносимы на Apache? Есть ли другие программные или аппаратные решения, которые мы должны рассмотреть вместо этого (использование HAProxy с сайтом SSL кажется более сложным, чем должно быть)? Есть ли другие предостережения при настройке веб-кластера SSL с высокой доступностью, которые мы могли не учитывать?

Если вы открыты для решения Microsoft / IIS 7, один из вариантов - использовать маршрутизацию запросов приложений (ARR) IIS7.

В этой статье на learn.iis.net есть введение / руководство: Балансировка нагрузки HTTP с использованием маршрутизации запросов приложений. Есть функция под названием «Разгрузка SSL»:

Когда эта функция включена, вся связь между сервером ARR и серверами приложений осуществляется открытым текстом, даже для запросов HTTPS от клиентов к серверу ARR. Когда и сервер ARR, и серверы приложений развернуты в доверенной сети, например в одном центре обработки данных, включение разгрузки SSL не приводит к снижению безопасности.

Кроме того, включение этой функции может дополнительно помочь максимизировать ресурсы сервера на серверах приложений, поскольку им не нужно тратить циклы на шифрование и дешифрование запросов и ответов.

Если хотите вникнуть в тему, вот еще одна статья про ARR, в котором объясняется, как использовать механизм в сочетании с аппаратными балансировщиками нагрузки.

Раньше я устанавливал нечто подобное, но мы запускаем приложения для модов на Perl, которые довольно требовательны к ресурсам. Таким образом, мы, по сути, закончили с squid перед серверами приложений, и мы использовали прокси-сервер apache + для достижения разгрузки ssl, чтобы затем мы могли кэшировать весь контент через squid. Для части кластеризации мы использовали LVS (виртуальный сервер Linux) + пульс для отказоустойчивых балансировщиков нагрузки. Для метода разгрузки ssl, который я использовал, см. этот статья в моем блоге для получения дополнительной информации

есть способы настроить то, что вам нужно, с HAProxy, но они требуют, чтобы сертификаты ssl были на всех серверах, которые будут использоваться. Другой вариант, с которым я столкнулся, но никогда не использовал, - это приложение под названием фунт который разработан с учетом балансировки нагрузки ssl-серверов