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-режим
Добрый день!
У меня вопрос к опытным коллегам: подскажите, есть ли какие-либо
правила, соотношения количества балансировщиков к количеству серверов
приложений при построении большой фермы веб-серверов? Какие-то best
practices?
Т.е. например есть такая схема (вложение)
При этом (M) чему должно быть приблизительно равно? Из вашей практики?
Очевидно, что никак не M<=N, явно M>N, но ~ во сколько раз?
N=2 (или 3) для отказоусточивости. По хорошему надо CARP, но в принципе достаточно просто чтоб в одном vlan-е были, вручную IP слегшего сервера можно будет перекинуть.
M = Mmin + R, где Mmin - минимальное кол-во серверов способных обработать пиковую загрузку, R - резерв (на случай выхода одного или нескольких серверов из строя)
