Re: соотношение балансировщиков/веб-серверов (оффтоп, но...)

big bond bondarets at gmail.com
Thu Oct 22 20:20:25 MSD 2009


CARP только в BSD, а эти замечательные системы у нас в компании не принято
использовать. Скорее всего балансер(ы) будут железные, но пока тестируем.

Кстати, сегодня пробовали нагрузить конкурентными SSL-сессиями один из
тестирумых балансировщиков, использовали программу flood_connect. Я
скомпилировал её на линуксовой машине (2хXEON E5420, 2.50GHz, 4GB RAM, SUSE
ENT 10.2), выжать смог максимум 16000 соединений, все 4 ядра были загружены
на 100%.
Коллега скомпилировал на старенькой железке (P3 700MHz, 512MB RAM, FreeBSD
7.2), выжал 7500 соединений и процессор был загружен не более 80%!!!!
Сам балансировщик при этом тоже неплохо был загружен.
Как такое возможно? Старая железка отстала всего в два раза от современного
неслабого сервера!
Запускали так: *flood_connect -S -f 10 -p 443 адрес_балансировщика*
-f - количество форков
-S - SSL-режим


22 октября 2009 г. 17:26 пользователь MZ <zuborg at advancedhosters.com>написал:

> big bond wrote:
>
>> Добрый день!
>> У меня вопрос к опытным коллегам: подскажите, есть ли какие-либо
>> правила, соотношения количества балансировщиков к количеству серверов
>> приложений при построении большой фермы веб-серверов? Какие-то best
>> practices?
>> Т.е. например есть такая схема (вложение)
>> При этом (M) чему должно быть приблизительно равно? Из вашей практики?
>> Очевидно, что никак не M<=N, явно M>N, но ~ во сколько раз?
>>
>>  N=2 (или 3) для отказоусточивости. По хорошему надо CARP, но в принципе
> достаточно просто чтоб в одном vlan-е были, вручную IP слегшего сервера
> можно будет перекинуть.
>
> M = Mmin + R, где Mmin - минимальное кол-во серверов способных обработать
> пиковую загрузку, R - резерв (на случай выхода одного или нескольких
> серверов из строя)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091022/104598e7/attachment.html>


More information about the nginx-ru mailing list