Когда-нибудь в будущем мне может потребоваться построить выделенную ферму SSL (как описано в Обеспечение масштабируемости приложений с помощью балансировки нагрузки) или что-то подобное для обработки большого количества SSL-трафика. Хотя для меня это не сиюминутная проблема, я бы хотел кое-что спланировать заранее. Итак, мой вопрос:
Насколько рентабельно использовать для этого выделенное оборудование, или я могу повторно использовать серверы приложений, возможно, с дополнительной картой оборудования? Или лучше интегрировать это в балансировщики нагрузки (вопреки тому, о чем говорилось в вышеупомянутой статье в 2006 году)?
Было бы неплохо сделать несколько ссылок на конкретное оборудование - в настоящее время я действительно не знаю, с чего начать.
AFAIK статья все еще в силе.
Если вам действительно нужна ферма с несколькими обратными прокси-серверами SSL с балансировкой нагрузки и несколькими серверами веб / приложений за ними, я бы посоветовал взглянуть на блейд-решение. Это не дешевле, чем простые стоечные серверы высотой 1 U, но при этом вы сэкономите место в стойке. Большинство крупных производителей серверов выпускают блейд-решения (Dell, HP, IBM и т. Д.). Некоторые ссылки: IBM | Dell | HP
Я бы построил балансировщики нагрузки с серверов Linux (избыточные пары, подключенные через Сердцебиение, видеть LVS проект) и имеют выделенные небольшие сети для прокси-трафика и трафика от второго балансировщика нагрузки на веб-серверы / серверы приложений.
Наиболее экономичным решением является NGINX в качестве обратного прокси-сервера, поскольку соотношение цена / производительность превосходит большинство аппаратных решений, таких как F5 Networks Big-IP 6900.
Моя конфигурация NGINX: http://gist.github.com/553235
Fig2 в вашей ссылке дает современный способ создания фермы SSL.
Что касается способа постройки фермы и стоимости, это будет зависеть от ваших потребностей.
Терминатор SSL на балансировщике нагрузки, вероятно, сегодня дешевле (даже с выделенным балансировщиком нагрузки, например Cisco CSS, Cisco ACE, F5 BIG-IP, ... но это все еще зависит от производителя балансировщика нагрузки).
Балансировщик нагрузки сможет выполнять балансировку L7, поскольку он видит незашифрованные данные. Таким образом, вам не понадобится двухуровневый балансировщик нагрузки и некоторый обратный прокси-сервер SSL. Это может снизить стоимость. (меньше оборудования на покупку, меньше места в стойке, ...)
Но наличие SSL-терминации на балансировщике нагрузки не очень масштабируемо, поэтому, если вы видите, что ваш балансировщик нагрузки начинает перегружаться SSL, у вас возникнут проблемы. Если вы взяли специальное устройство, вам нужно будет обновить его, и это будет дорого. Если вы создаете собственный балансировщик нагрузки с сервером, вам нужно будет разгрузить SSL на новом выделенном сервере.
Наличие карты на сервере приложений может быть вариантом, если балансировки нагрузки L4 достаточно и если ваше приложение обеспечивает высокую пропускную способность при низком использовании ЦП.
Я имею в виду: аппаратная карта SSL стоит дорого, поэтому вы хотите использовать ее как можно чаще.
Со специальным оборудованием для завершения SSL вы будете использовать карту как можно чаще. Если карта находится на сервере приложений и приложение имеет низкую пропускную способность, вы не будете использовать карту много времени. Но если приложение работает быстро, не используя слишком много ЦП, но с высокой пропускной способностью, можно использовать завершение SSL на сервере с выделенной картой. Обычно это не так. Это также снижает высокую доступность.
Я предполагаю, что вы говорите здесь о HTTP-трафике (существует большая разница между протоколами с сохранением состояния и протоколами без состояния).
Проблема в том, что для достижения максимальной производительности вы хотите, чтобы возобновление сеанса SSL работало - что отдает предпочтение подходу с привязкой к сеансу - но если ваши сеансы слишком липкие, у вас не будет переключения при отказе. Большие дорогие боксы от f5, Cisco и др. Могут с этим справиться, но это сложно сделать с обычными коробками, работающими (например) с stunnel.
Я по-прежнему считаю, что лучшим решением большинства проблем с балансировкой нагрузки является циклический DNS, где обнаружение сбоя - единственное место, где сбой может быть надежно обнаружен (клиент), и именно здесь реализуется аварийное переключение - он обеспечивает сервер affinity, но все же позволяет переключение запросов (обратите внимание, что он не поддерживает возобновление запросов, но я еще не встречал ничего, что поддерживает это для HTTP).
Еще одна вещь, о которой следует помнить, это то, что Хранитель Microsoft поддержка HTTP через SSL отличается от поддержки всех остальных. Это касается не только openSSL - другие поставщики дают тот же совет. Учитывая дополнительные накладные расходы на согласование SSL и огромную отдачу от использования keep-alive для HTTP-трафика, возможно, стоит рассмотреть возможность использования MS-ISA для завершения SSL - хотя я предполагаю, что можно настроить программное обеспечение как таковое, и я Меня никогда не впечатляли масштабируемость / надежность продуктов. Так что, если бы у меня было много денег, я бы, вероятно, посмотрел на MSISA для завершения SSL, но не использовал бы программное обеспечение кластеризации Microsoft и не переносил отказоустойчивость в другое место (например, на клиент!).
Для более дешевого решения отключите SSL на ящиках веб-сервера с помощью циклического DNS. Добавьте много веб-серверов. При желании используйте карту криптографического ускорителя (не сетевая карта с поддержкой SSL) на веб-сервере для дополнительной производительности.
Для очень быстрого решения - (возможно) несколько узлов MSISA, адресованных через циклический DNS, разговаривая с LVS кластер веб-серверов.
HTH
Трафик HTTP может создавать очень высокую нагрузку из-за требований к шифрованию. Они делают карты расширения, которые позволяют разгрузить шифрование / дешифрование SSL на специально разработанное оборудование. Как упоминалось выше, вы можете отключить SSL на балансировщике нагрузки, что снизит затраты, потому что (по крайней мере, для F5) эти устройства поставляются с этим оборудованием для разгрузки SSL. Кроме того, их можно приобрести и установить непосредственно на вашем сервере, хотя я не уверен, как это будет работать с VMWare. Сжатие также можно разгрузить с помощью балансировщика нагрузки.