Назад | Перейти на главную страницу

Как спрогнозировать характеристики балансировщика нагрузки Linux?

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

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

Однако у меня есть следующие вопросы:

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

    У меня есть небольшой сервер размером 1u (PowerEdge 1850) с 2 дисками SCSI 10k Ultra 320 SCSI по 76 ГБ в RAID1, 2 одноядерными процессорами Xeon с тактовой частотой 3 ГГц (шина 800 МГц с 2 МБ кеш-памяти L2) и 6 дисками по 1 ГБ с ОЗУ PC2-3200 400 МГц. Я хотел бы использовать это, но у меня нет опыта работы с HAProxy и Pound, поэтому я не могу сказать, будет ли это подходящим или нет. Я бы предположил, что 6 ГБ ОЗУ - это слишком много, учитывая спецификации аппаратного балансировщика нагрузки. Что думают другие о ЦП и жестких дисках?

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

Спасибо.

HAProxy и SSL:
Поддержка SSL непосредственно в HAProxy появилась совсем недавно (все еще в Dev, обнародована около недели назад), поэтому в зависимости от вашей временной шкалы вам понадобится что-то вроде stunnel или nginx для разгрузки SSL. Если вы не против попробовать что-то новое, вот как.

TPS, параллелизм и пропускная способность:
Основным фактором здесь, вероятно, будут транзакции в секунду (TPS). Итак, чтобы спрогнозировать вашу нагрузку, вам нужно как-то получить это число. Скорее всего, вы захотите проанализировать свои веб-журналы. Параллелизм действительно будет зависеть от того, как долго вы держите сеансы открытыми. Если вы оставите их открытыми какое-то время, ответ может казаться более быстрым, потому что вам не нужно постоянно повторять создание сеанса (это отнимает много времени и дорого, когда дело касается SSL). Однако вы не хотите держать вещи открытыми так долго, чтобы израсходовать кучу памяти.

Оценка емкости с HAProxy:
Что касается производительности памяти, Документация HAProxy дает некоторые рекомендации:

Также имейте в виду, что соединение содержит два буфера по 8 КБ каждый, а также некоторые другие данные, в результате чего на одно установленное соединение потребляется около 17 КБ ОЗУ. Это означает, что средняя система, оснащенная 1 ГБ ОЗУ, при правильной настройке может выдерживать около 40000-50000 одновременных подключений.

При использовании SSL большая часть работы ЦП будет производиться на этапе установления связи. Если то, что вы используете для обработки SSL, может кэшировать сгенерированные ключи, вы можете сэкономить много ресурсов ЦП. Видеть Эта статья для получения более подробной информации об этом.

Вы также можете использовать эталонный тест этого человека чтобы получить идею в качестве основы.

Чтобы быть уверенным, вам нужно провести тест:
В конце концов, чтобы быть уверенным, вам придется провести сравнительный анализ, вот ссылка чтобы вы начали. Мое личное впечатление, что на 4 Мбит / с у вас, вероятно, все будет хорошо.