Ошибка SSL в EC2

Question

Мы развернули наше приложение для рельсов в EC2. В нашей настройке у нас есть два прокси-сервера в небольших экземплярах за круглым DNS-сервером. Они запускают балансиры нагрузки nginx для динамически растущей и сокращающейся фермы веб-серверов. Каждый веб-сервер также запускает nginx с кластером mongrels. Nginx здесь заботится о статическом содержимом и балансировке нагрузки на монгрелей.

В любом случае, наш трафик по-большому - это HTTPS. У нас есть 2 прокси, которые заботятся о SSL. Я заметил, что пропускная способность сети в этих случаях составляет всего 60 Мбит/с или около того. Для сравнения, при тестировании я могу последовательно получать 700 Мбит/с на небольшом экземпляре через обычный HTTP. Фактически, это то же самое, что я могу получить на большом экземпляре. Подобно тому, что ребята Right Scale получили в their testing. (Amazon говорит, что маленький получает «умеренный» сетевой ввод-вывод, в то время как большой получает «высокий». Если бы мне пришлось размышлять, я думаю, что это всего лишь их способ сказать, что на физическом ящике есть более мелкие экземпляры, которые используют одну сетевую карту Я не уверен, означает ли это, что большой получает выделенный сетевой интерфейс, но я бы сомневался в этом.)

В ходе тестирования я смог получить большой экземпляр, чтобы получить протокол 250 Мбит/с. Это говорит мне, что процессор или какой-то другой ресурс является узким местом. Тем не менее, наши диаграммы мониторинга не показывают, что CPU на наших прокси-серверах особенно занят.

Мои вопросы:

1. Это мой инстинкт о SSL быть медленнее из-за процессора правильно и наши графики мониторинга неверны? Или может ли какой-то другой ресурс быть лимитирующим фактором?
2. Должны ли мы просто взять дополнительную плату и поставить прокси на высокопроцессорные экземпляры? Или было бы лучше сделать просто добавить более маленькие экземпляры?
3. Должны ли мы отключить терминацию SSL на веб-серверах? Однако это еще одна проблема: как мы получаем IP-адрес клиента в нашем приложении? Прямо сейчас наш прокси устанавливает его в заголовок X-FORWARDED-FOR, но, очевидно, это будет невозможно, если он не расшифрует SSL.

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

Answer 1

Вы используете кеш сеанса SSL, который предоставляет nginx? Это может помочь nginx экономить на циклах, постоянно перерабатывая шифрование. См. http://wiki.nginx.org/NginxHttpSslModule#ssl_session_cache

Какой мониторинг вы используете для определения использования вашего процессора? Обычно SSL очень интенсивен.

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

Answer 2

SSL медленнее: - true, то любой обычный HTTP-запрос HTTPSSL будет медленнее.

Попробуйте создать аналогичную установку в локальной локальной сети, где у вас есть 3 mongrel_clust и 2 веб-сервера. и проверьте с помощью загрузчика, с отправкой около 5 тыс. Запросов.

если все в порядке, thats great. Возможно, вы будете работать с EC2 ребятами.

Answer 3

Я использую SSL на Apache, который обрабатывает доступ к нашему репозиторию Subversion на экземпляре Small Windows EC2. При тестировании я обнаружил, что доступ HTTPS был менее медленным, чем HTTP, но это по очевидной причине, что шифрование/дешифрование не является мгновенным процессом, как и следовало ожидать.

Если показатели вашего процессора правильны и вы не видите чрезмерной нагрузки, то подразумевается, что пропускная способность является ограничивающим фактором; однако я действительно не понимаю, почему вы сможете получить 700 Мбит/с в HTTP-экземпляре по сравнению с только 60 Мбит на экземпляре HTTPS. Разумеется, если тестовые условия не были фактически идентичными, и внутри HTTPS-экземпляра, который вы не учитывали ...

Более крупные экземпляры, разумеется, получают лучшую долю пропускной способности хоста, чем Smalls - их меньше, чем конкурентов за ресурс. Поскольку внутренняя сеть EC2 представляет собой Gigabit Ethernet, просмотр 700 Мбит/с в экземпляре Large возможен, если никакие другие крупные экземпляры на одном и том же узле не будут иметь аналогичные требования к пропускной способности. Чтобы получить это из маленького экземпляра, вам нужно быть очень удачным, чтобы работать внутри очень легко загруженного хоста. И в этом случае не было бы гарантии, что вы сохраните этот уровень производительности - как только другие Smalls выйдут онлайн, ваша доля доступной пропускной способности начнет снижаться.

Я думаю, что это, по сути, проблема с пропускной способностью небольшого экземпляра - добавление большего количества Smalls не обязательно поможет многим, потому что вы не можете контролировать, какой хост они раскручиваются; Большие экземпляры, однако, получают больший кусок полосы пропускания и, следовательно, скорее всего, будут иметь более устойчивую доступность.