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

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

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

У меня есть следующие запросы, хотя;

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

  2. Исходя из запроса 1, у меня есть запасной сервер, который я хотел бы использовать, но как я могу соотнести требуемую спецификацию аппаратного обеспечения сервера с требуемой производительностью веб-приложения?

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

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

Спасибо.

Источник

1 ответ

Решение

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

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

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

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

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

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

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

Источник
Другие вопросы по тегам