почему нет примеров горизонтально масштабируемых программных балансировщиков нагрузки, балансирующих ssl?

womble прав в отношении общего хранилища сеансов, которое значительно упрощает работу. В дополнение к его ответу я могу немного подробнее рассказать о балансировке нагрузки в этом вопросе:

Почему, кажется, нет других примеров установок, добавляющих больше ssl-декодеров для работы с увеличенным трафиком?

Современный многоядерные ПК могут сделать несколько тысяч SSL-транзакций в секунду. И если это станет узким местом, тогда специализированное устройство от F5, Citrix, Cisco и т.п. могут быть еще быстрее. Таким образом, большинство сайтов никогда не перерастают хорошее решение SSL для одного устройства и балансировки нагрузки.

Если предположить, что все, что я сказал, правда, у меня есть следующие варианты:

Есть варианты масштабирования SSL-дешифрования по горизонтали, если вам это нужно.

Общий подход заключается в использовании DNS Round Robin для высокодоступных пар SSL-ускорителей, то есть публикации нескольких IP-адресов для домена, каждый IP-адрес указывает на пару SSL-ускорителей.

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

В качестве одного из примеров вы можете отделить расшифровку SSL от балансировки сервера приложений. Обработка SSL требует больших затрат ресурсов ЦП, чем базовая балансировка нагрузки, поэтому один балансировщик нагрузки должен быть в состоянии перегрузить пару ускорителей SSL. Как это:

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

Как упоминалось в начале, общее хранилище сеансов упрощает многие вещи и почти наверняка является лучшим долгосрочным решением, чем усложнение уровня SSL / балансировки нагрузки.

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

Когда продукты эволюционируют, интересно отвечать на подобные вопросы двухлетней давности. Прямо сейчас haproxy поддерживает протокол PROXY, который позволяет передавать IP-адрес клиента на следующий переход даже в чистом режиме TCP. Он также поддерживает собственный SSL, а также липкость SSL, если вы хотите использовать его в качестве первого уровня перед фермой SSL (возможно, сделанной из серверов haproxy). Похоже, что ваш запрос был немного раньше времени, и реализации догнали :-)

Я согласен с Уомблом и Джеспером здесь. Самый простой / лучший способ - исправить код. Конечно, как системные администраторы, у нас часто нет такой возможности, но даже в этом случае есть достаточно уловок, которые вы можете использовать, чтобы получить относительно дешевое современное оборудование для достаточно широкого масштабирования, хотя и не совсем по горизонтали.

Я просто хотел написать, чтобы прокомментировать, где вы обеспокоены потерей клиентского IP. В любом из основных решений L7 / прокси вы можете вставить в запрос заголовок X-Forwarded-For (или что угодно). Затем на внутреннем веб-сервере, получающем запрос, вы можете изменить формат файла журнала, чтобы записать это значение в том же пространстве в файле, который он использовал для регистрации IP-адреса клиента уровня 3. Таким образом, ни одно программное обеспечение для анализа журналов не видит разницы (и вы не видите разницы).

Есть компромиссы для всего, и мы не слышали достаточно о вашей настройке, чтобы знать, но с трио, которое вы не ошибетесь, ha-proxy, nginx и varnish, вероятно, хорошая идея перенести балансировку нагрузки в инструмент прокси-слоя. Это решит вашу проблему с ssl, а также предоставит вам множество новых опций, таких как кэширование, переключение контента и манипуляции с заголовками.

Какие-то случайные мысли;)

Сначала стреляйте в человека, который решил использовать данные сеанса на основе файлов. Нет никакого способа, чтобы чтение / запись данных из файловой системы было быстрее, чем просто возврат к источнику для извлечения нужных данных. Это НАИХХИЙ способ сделать это.

Я лично никогда не видел ситуации, когда хранение данных в сеансе было лучше, чем просто извлекать их непосредственно из базы данных по мере необходимости. Тем не менее, я видел, как использование memcache или аналогичных стратегий кеширования может помочь масштабировать сайт для миллионов пользователей, но это даже не в том же парке, что и использование сессий.

Во-вторых, вы только что нашли причину номер один вообще не использовать сеансы: балансировка нагрузки. К вашему сведению - липкий не означает застрявший. Даже с включенными сеансами Sticky вы запускаете вполне реальную возможность перетасовки пользователя на другой сервер в середине использования вашего приложения. Произойдет это в самый неподходящий момент. Прикрепленный просто означает, что балансировщик нагрузки пытаться чтобы вернуть пользователя на сервер, с которого он начал, но это ни в коем случае не гарантия.

Этот момент обычно приводит людей к сохранению сеанса обратно в базе данных ... что, я считаю, является полным потерпеть поражение. Чтобы сеанс работал, он должен быть загружен и записан при каждом запросе страницы. Когда он хранится в базе данных (необходим для серверов с балансировкой нагрузки), для этого требуются два запроса к серверу: первый для получения данных, второй для записи любых обновлений.

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

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

Моя точка зрения: сеанс - это зло, и вам обычно лучше без него. Сайты с низким трафиком, которые работают только на одном веб-сервере, не нуждаются в возможном повышении производительности; и сайты с высоким трафиком, работающие на веб-ферме, ограничены в масштабировании из-за этого.

Вместо того, чтобы использовать Haproxy на передней панели, вы можете использовать циклический DNS для грубой балансировки между несколькими декодерами SSL, а затем передать его в haproxy для правильной балансировки нагрузки.