Хочется поговорить о настройках серверов под хайлоад

[huanpedro]

Хочется поговорить о настройках серверов под "хайлоад".
Есть у кого опыт?

Опыта у меня особо нет, но есть желание поработать в этом направлении.
Ну и встал я в самом начале вопроса).
Итак, планирую схему серверов с возможностью расширения с одного сервера до нескольких.

Что пока пришло в голову:
1) на сервер приходит запрос юзера и попадает на Nginx
2) распределяем юзера по серверам
что-то типа

PHP код:

upstream mySuperCloud {
  ip_hash;
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
} 


3) роемся в memcached(например) в поисках кэша для ответа и если есть, то отдаем его, если нет тогда динамику раздаст например апач+python(или perl или modperl), а статику тотже nginx(или лучше еще один поставить? т.е. будет фронтенд nginx1 + два бэкенда - апач и nginx2 ? есть ли смысл?)

Как-то так. Еще думается как хранить статику, в файлах или в базах. И если статики много и на одном сервере не помещается тогда надо как-то ее раскидать по серверам.

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

Ну и вот пару ссылочек в тему почитать, если кто не видел:
устройство вконтакта http://www.xakep.ru/post/55052/?print=true
и пока все

[mfknrog]

Насколько высокие нагрузки? Какими ресурсами не обладает один сервер, что надо использовать несколько? Распределение нагрузки на разные сервера это последняя мера, которая накладывает ограничения на используемое ПО и т.п. В первую очередь надо тюнить ОС, настройки БД и оптимизировать скрипты генерирующие динамику.
P.s. Ксати, совсем статичную статику можно заранее паковать в .gz и отдавать в таком виде.

[JackSoft]

haproxy

[huanpedro]

Сообщение от mfknrog

P.s. Ксати, совсем статичную статику можно заранее паковать в .gz и отдавать в таком виде.

Да, это само собой

Сообщение от mfknrog

Насколько высокие нагрузки? Какими ресурсами не обладает один сервер, что надо использовать несколько? Распределение нагрузки на разные сервера это последняя мера, которая накладывает ограничения на используемое ПО и т.п. В первую очередь надо тюнить ОС, настройки БД и оптимизировать скрипты генерирующие динамику.

Вся фигня в том что нет желания сейчас делать проект, который возможно разрастется заткнет всяких каонтактов, фейсбуков и прочих гуглей, чтобы потом бегать по комнате хватаясь за голову в попытках все переделать.
Т.е. хочется сразу спланировать такую схему, в которой изначально у меня все будет работать на одном сервере. Но как только не будет хватать ресурсов этого сервака, я быстро ставлю второй сервер, тупо меню конфиг фронтенда(может еще какие мелочи) и у меня все снова работает на ура, до тех пор пока не придется ставить 3, 4, N-ый сервер..
+ мелкий ДДОС например не должен быть заметен для ресурса.

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

[Jeff]

вместо входящего nginx сервера лучше делать балансировку на уровне DNS, а уже на каждом сервере свой nginч, а за ним апач.

Минус данной схемы в том,что она менее отказоустойчива (при выходе одного из серверов часть запросов будет в 404). Хотя в твоей схеме тоже если падает фронтэнд, то ничего не работает :-)

Плюс в том, что такая схема очень хорошо масштабируется. Можно добавить большое количество frontend серверов, а потом еще, если возникнет такая необходимость, разнести и каждый сервер на 2 (1- nginx, 2- apache). Ну и еще возможно достаточно много вариаций придумать.

А наибольшую свинью тут может подложить база. MySQL ограниченно масштабируется. Лучше выбрать что-то более серьезное, например PostgreSQL - на нем даже кластеры поднимаются нормальные.

[Алёша]

Сообщение от huanpedro

Да, это само собой


Вся фигня в том что нет желания сейчас делать проект, который возможно разрастется заткнет всяких каонтактов, фейсбуков и прочих гуглей, чтобы потом бегать по комнате хватаясь за голову в попытках все переделать.
Т.е. хочется сразу спланировать такую схему, в которой изначально у меня все будет работать на одном сервере. Но как только не будет хватать ресурсов этого сервака, я быстро ставлю второй сервер, тупо меню конфиг фронтенда(может еще какие мелочи) и у меня все снова работает на ура, до тех пор пока не придется ставить 3, 4, N-ый сервер..
+ мелкий ДДОС например не должен быть заметен для ресурса.

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

скрипты на отд.сервак вынеси
нагрузка куда пойдёт? если на базу, то ей можно репликацию сделать, а http будет всё так же 1 сервер принимать
если на web именно нагрузка (генерация динамики), то тоже варианты: nginx, mod_perl (под ним вообще нагрузку оч.сложно сотворить)
можно шлюз впереди поставить, который будет смотреть, какие серваки заняты и слать на свободные
опять же распределение задач, если там 1 сервак про знакомства, второй про видео, их лучше разнести на разные
и конечно оптимизировать код/запросы
в этом месте обычно "бутылочное горлышко" и находится
пряморукий сервак с грамотным кодом оч.сложно грузануть такими стандартными веб-примочками

[huanpedro]

Сообщение от JackSoft

haproxy

Если я правильно понял, в моей схеме сначала он принимает траф и раскидывает его по физическим серверам, там встречает nginx, который уже проверяет кэш и разделяет статику и динамику, отдавая статику сам, а с динамикой пробрасывает дальше на апач.
Вроде неплохо полчается. Оставлю тут ссылочку по настройке haproxy http://helpers.com.ua/vysokonagruzhe...y-haproxy-cfg/

Сообщение от Jeff

вместо входящего nginx сервера лучше делать балансировку на уровне DNS, а уже на каждом сервере свой nginч, а за ним апач.

Минус данной схемы в том,что она менее отказоустойчива (при выходе одного из серверов часть запросов будет в 404). Хотя в твоей схеме тоже если падает фронтэнд, то ничего не работает :-)

Ну если я правильно понимаю, то без хардварного балансировщика на уровне dns я могу только по кругу по сервакам пускать и если какой-то недоступен, то траф на них будет теряться(а не переходить к работающему). Т.е. так и так если сервер слег, то траф теряется, так что лучше в крайнем случае балансировщик вынести на отдельный сервер, который будет только балансировкой заниматься.
Кстати, раньше я не парился и для домена прописывал 4 нс сервера, у которых стояли IP двух серверов. Но выходило как-то странно, как буд-то юзеры географически распределялись, т.е. тот сервер что быстрее отвечал юзеру туда и отправляло юзера.

[vakh]

Сообщение от JackSoft

haproxy

Обожаю ответы без аргументации )
Чем он лучше nginx?

[Sterx]

вместо mysql/pgs можно использовать noSQL решения - redis например. на нем все летает

[huanpedro]

Сообщение от vakh

Обожаю ответы без аргументации )
Чем он лучше nginx?

Почитал я о нем. Споров много, ничего конкретного нет, но все в основном сводится к подобному: http://www.lexa.ru/nginx-ru/msg21366.html
там же:

>> Наткнулся на сравнение HAProxy и Nginx:
>> http://affectioncode.wordpress.com/2...oxy-and-nginx/
>> http://affectioncode.wordpress.com/2...-applications/

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

Тот же контакт балансирует и nginx'ом и haproxy(я так понимаю чисто месенджер)