Re: Load Balancing на основе входящих IP

[Roman Golomidov]

> Про цискин SLB я в курсе. 

Железки не подойдут по идеологическим причинам. Тем более не вижу в
них смысла если распределение требуется в пределах 1 машины.

NLB - это опять таки разные машины, и я уверен что этим решается
проблема "медленный скрипт загребает всю машину". В моем же случае
скрипт быстрый, машина быстрая, все быстрое. Только скриптов очень
много одновременно запускается.

По поводу 
http://www.apsis.ch/pound/
вся проблема - в session. т.е. он в каком то виде _их_ хранит у себя.

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

Т.е. условно говоря, сейчас работает все так:
пришел запрос  - каждый раз разному веб серверу.
произошла обработка этой сессии (временный файл)
в следующий раз я этого клиента идентифицирую, беру временный файл и
предпринимаю действия.

Конкретно сейчас в пике одновременно бывает порядка 1800 максимально
оптимизированных апачей.
При использовании nginx работа получается гораздо эффективнее. Я
тестировал это ввиде 10% нагрузки от основного трафика, и испытание
показало что можно разгрузить машину раза в 2 - 2.5 при том же
трафике, следовательно трафик может вырасти раза в 2 минимум :)
Сейчас для обработки вызывается компилированный С скрипт. Все
достаточно быстро и тормоза только при этих файловых операциях с
временными файлами, и это не смотря на то что все они на RAM диске.
Тормоза причем скорее даже не их читке (они по 100 байт), а в их
поиске на диске силами файловой системы (базы для хранения ЭТОГО
рассматривались, но также были отметены как не эффективные).

Логичным этапом максимизации эффективности является искоренение этих операций.
Достичь этого можно с использованием FastCGI. Скрипт постоянно висит в
памяти, копит информацию, раз в 10 минут respawn с удалением
устаревшей информации - все в шоколаде, даже если скрипт на perl.
НО! Для целостности информации - у меня должен быть 1 только процесс,
который условно говоря хранит в себе все эти временные файлы.
Он не справляется со всей нагрузкой. Преподагаю что их должно быть
порядка 15 процессов для обработки всего трафика. И вот тут встает
проблема - запросы приходят каждый раз в разные скрипты - по
предыдущему визиту информации нет в другом скрипте. Напрашиваются
временные файлы. Но собственно зачем тогда от них уходили? :)

Вот тут и является выходом то что я говорил (может быть невнятно, признаюсь)

>Мне непонятна жёсткая балансировка вида
> 
> A.B.C.D
> D mod 3 == 0 -> первый скрипт
> D mod 3 == 1 -> второй скрипт
> D mod 3 == 2 -> третий скрипт

d mod 3 == 0 первый скрипт означает, что я без использования каких
либо внешних кук, временных файлов и прочего, уже получаю ту
функциональность которая нужна - этот клиент приходит всегда туда где
про него знают. Он сам (IP) является носителем инфы куда его послать.
При этом я легко могу увеличить это количество до сколько угодно процессов.
d mod 20 == 19 - будет 20 процессов обрабатывающих и все легко масштабируется.

Этот способ не дает 100% гарантии идентификации пользователя, но этого
и не нужно. Но зато он максимально нетребовательный к ресурсам способ
достичь этой идентификации.
И если как то можно было бы решить эту проблему - это просто сказка была бы.


Роман Голомидов