Создание фермы серверов 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?
2 ответа
Для 120 кластеров серверов, обратитесь к профессионалу. Я бы не думал, что вы получите ответ, достаточно значительный для вашего приложения.
Самая сложная кластерная конфигурация, которую мы настроили, состояла только из 20 серверов, из которых только 12% составляли трафик HTTPS (чистый SSL 14 Мбит).
Наша типичная архитектура...
Если это помогает, для веб-кластеров мы обычно используем:
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-терминаторы Benchmarks
- http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html
- http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html
- http://barry.wordpress.com/2008/04/28/load-balancer-update/
Использование процессора, вероятно, будет ключевым вопросом
Потребление ЦП будет вашей самой большой проблемой, поэтому умная работа с размером ключа SSL поможет, 1024-битный (в настоящее время большинство администраторов SSL не рекомендуется) против 2048-битных против 3072-битных ключей линейно увеличит накладные расходы.
Вот хорошее прочтение об общей производительности SSL, http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
В конечном итоге вы обнаружите, что здесь нет "правильного" ответа, и что только тестирование, повторное тестирование, а затем еще тестирование покажет вам, что лучше всего работает в вашем сценарии.
Вы можете отделить инфраструктуру от потребительского трафика с помощью брандмауэра Linux. Используя функцию сопоставления строк netfilter/iptables, вы можете сопоставлять трафик на основе URL. После сопоставления трафика вы можете использовать это для выполнения QoS или пересылки трафика по-другому.