Создание фермы серверов SSL

Я заинтересован в построении архитектуры, описанной в статье, указанной ниже.

В настоящее время у меня есть недорогой балансировщик нагрузки уровня 4, и мои серверы приложений являются конечными точками SSL. Я хочу разместить ферму серверов SSL между моим балансировщиком нагрузки и моими серверами приложений. Затем я поставлю еще один недорогой балансировщик нагрузки между фермой SSL и моими серверами приложений для маршрутизации уровня 7.

Мое веб-приложение имеет довольно большой объем потребительского трафика, который 6 серверов могут обрабатывать примерно на 50% мощности. Вдобавок у меня трафик инфраструктуры на несколько порядков тяжелее моего потребительского. Это данные, поступающие со всего мира, которые должны интегрироваться с моим веб-приложением в режиме реального времени. Всего у меня 18 серверов приложений для обработки всего трафика плюс 6 серверов баз данных. Я добавлю еще 6 серверов приложений в течение следующих 2 недель и еще 6 в течение 2 недель после этого. По моим скромным подсчетам, к концу года мне потребуется масштабирование до 120 серверов.

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

Сложность заключается в том, что весь трафик адресуется с использованием одного и того же имени хоста и почти на 100% составляет https. В моем случае единственный способ отличить инфраструктуру от потребительского трафика - это URL-адрес (плохая архитектура, которую я унаследовал), поэтому мне нужен балансировщик нагрузки уровня 7, чтобы иметь возможность маршрутизировать. Однако для этого мне нужен либо модный аппаратный терминатор SSL, либо ферма серверов SSL, как описано выше. Поскольку моя пользовательская база быстро масштабируется, я беспокоюсь, что, если я выберу аппаратный путь, он очень быстро станет очень дорогим, тем более, что для высокой доступности мне понадобятся всего 4 единицы (2 идентичные установки на 2 объектах). Между тем, приведенная выше диаграмма кажется очень гибкой и более масштабируемой по горизонтали.

Кто-нибудь строил это раньше? Есть ли готовые конфигурации? На что следует обратить внимание и какое программное обеспечение следует использовать (я слышал о людях, использующих apache с mod-ssl, nginx и stunnel)? Кроме того, когда имеет смысл покупать дорогой балансировщик нагрузки вместо создания фермы серверов SSL?

http://1wt.eu/articles/2006_lb/index_05.html

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

Самая сложная кластерная конфигурация, которую мы настроили, состояла всего из 20 серверов, из которых только 12% составлял трафик HTTPS (14 Мбит чистого SSL).

Наша типичная архитектура ...

Если это помогает, для веб-кластеров мы обычно используем:

lvs (initial ssl load balancing)
    -> pound (ssl-unwrapping) 
    -> varnish (caching) 
    -> haproxy (load balancing) 
    -> nginx (static content) 
    -> php (dynamic content) 
    -> mysql (db)

Мы использовали stunnel в комбинации с HAProxy (вместо Pound), но это вызывало некоторые сложности (с невозможностью установить заголовки) дальше по цепочке.

Фунт

Мы используем это, и он работает очень хорошо, настолько, что мы не могли довести его до ограничений на имеющееся у нас оборудование и объем проходящего трафика. Apache jMeter во время тестирования.

Также есть примечание о домашняя страница из pound относительно улучшения производительности

Если доступны PCRE, tcmalloc (из пакета Google perftools) и / или Hoard, Pound свяжется с ними. Это обеспечит значительный прирост производительности и настоятельно рекомендуется.

Но pound считается хорошим для приложений с «низким» трафиком, но, похоже, не так хорошо масштабируется, как его конкуренты, что другие документально подтвердили в тестовых тестах

Программные терминаторы SSL Тесты

Использование ЦП, вероятно, будет ключевой проблемой

Потребление ЦП будет вашей самой большой проблемой, поэтому будьте умны с Размер ключа SSL поможет, 1024-битные (теперь не рекомендуемые большинством SSL-сертификатов), 2048-битные и 3072-битные ключи увеличивают накладные расходы линейно.

Вот хорошее чтение об общей производительности SSL, http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

В конечном итоге вы обнаружите, что нет «правильного» ответа и что только тестирование, повторное тестирование, а затем еще несколько тестов покажут вам, что лучше всего работает в вашем сценарии.

Вы можете отделить инфраструктуру от потребительского трафика с помощью брандмауэра Linux. Используя функцию сопоставления строк netfilter / iptables, вы можете сопоставить трафик на основе URL-адреса. После сопоставления трафика вы можете использовать это для выполнения QoS или пересылки трафика по-другому.