-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Организация обработки запроса несколькими серверами?
- Автор темы seva2
- Дата начала
Wicked
Новичок
например, сменит свой IP по событию heartbeat'а
-~{}~ 22.07.08 16:51:
http://en.wikipedia.org/wiki/Heartbeat_(program)
http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
-~{}~ 22.07.08 16:51:
http://en.wikipedia.org/wiki/Heartbeat_(program)
http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
MiksIr
miksir@home:~$
Нет, нада рассказать что есть и что хочется.... если есть желание, что бы помогли 
- прибор?
- 50!
- что "50"?
- а что "прибор"?
-~{}~ 23.07.08 19:18:
Если не ясен пой предыдущий вопрос, то... сколько есть серверов и что хочется получить - отказоустойчивость (на сколько серверов) или распределение нагрузки или и то и другое (при 2-х серверах не доступно)
- прибор?
- 50!
- что "50"?
- а что "прибор"?
-~{}~ 23.07.08 19:18:
Если не ясен пой предыдущий вопрос, то... сколько есть серверов и что хочется получить - отказоустойчивость (на сколько серверов) или распределение нагрузки или и то и другое (при 2-х серверах не доступно)
MiksIr
miksir@home:~$
В таком случае отдельный под nginx и правда жирно. nginx кушает мало процессора и умерено памяти.
Имея 3 сервера вполне можно реализовать LB+HA схему.
Т.е. два сервера - nginx+backend, один - только backend, хотя для более легкой переносимости конфигов (если сервера более-менее одинаково сконфигурены) можно и все три сделать nginx+backend.
Каждый nginx знает про все три бекенда и на них ходит. HA тут достигается для nginx-а - или hearbeat или carp; для бекенда - сам nginx.
LB самого nginx-а дело вкуса и схемы данных. Если захочется делать все же делать - тут можно и DNS-ом, но в принципе можно и остановиться на схеме - один nginx работает, другой отдыхает.
Единственная проблема, которая возникает тут - это как отдавать статику. Т.е. если вся статика - это заранее готовый пакет, проблем тут нет - на каждую ноду разворачиваем снепшот вашего продукта и все.
Если же статика - это так же и контент загружаемый (юзерами, контентщиками), то нужно решать вопрос о ее синхронизации между нодами. В большинстве случаев в силу бедности расшаренные стораджи у нас пока не в ходу, так что придумывают схемы именно синхронизации копированием.
Вот тут как раз и видно, можно ли балансить nginx или нет. Если продукт можно настроить так, что бы по закачке чего-то он это чего-то клал и на вторую ноду, то спокойно балансим nginx. Если такая схема трудна, то можно по крону просто rsync-ать с активной ноды на пассивную и nginx не балансить. Тогда, правда, не забыть для nginx написать правило, что бы POST он слал только на свой бекенд. Тут придумали еще кучу разных схем... заполнение нод "по запросу" и т.д., ну да долго о всех рассказывать.
Если реализуете такую схему - слабым местом станет только один сервер базы данных. Что, кстати, странно, ибо база то, обычно, начинает быстрее стучать в потолок, чем бекенды. Может подумать все же о схеме 2(nginx и бекенд)+2 (mysql) b определиться что важнее LB или HA.
Имея 3 сервера вполне можно реализовать LB+HA схему.
Т.е. два сервера - nginx+backend, один - только backend, хотя для более легкой переносимости конфигов (если сервера более-менее одинаково сконфигурены) можно и все три сделать nginx+backend.
Каждый nginx знает про все три бекенда и на них ходит. HA тут достигается для nginx-а - или hearbeat или carp; для бекенда - сам nginx.
LB самого nginx-а дело вкуса и схемы данных. Если захочется делать все же делать - тут можно и DNS-ом, но в принципе можно и остановиться на схеме - один nginx работает, другой отдыхает.
Единственная проблема, которая возникает тут - это как отдавать статику. Т.е. если вся статика - это заранее готовый пакет, проблем тут нет - на каждую ноду разворачиваем снепшот вашего продукта и все.
Если же статика - это так же и контент загружаемый (юзерами, контентщиками), то нужно решать вопрос о ее синхронизации между нодами. В большинстве случаев в силу бедности расшаренные стораджи у нас пока не в ходу, так что придумывают схемы именно синхронизации копированием.
Вот тут как раз и видно, можно ли балансить nginx или нет. Если продукт можно настроить так, что бы по закачке чего-то он это чего-то клал и на вторую ноду, то спокойно балансим nginx. Если такая схема трудна, то можно по крону просто rsync-ать с активной ноды на пассивную и nginx не балансить. Тогда, правда, не забыть для nginx написать правило, что бы POST он слал только на свой бекенд. Тут придумали еще кучу разных схем... заполнение нод "по запросу" и т.д., ну да долго о всех рассказывать.
Если реализуете такую схему - слабым местом станет только один сервер базы данных. Что, кстати, странно, ибо база то, обычно, начинает быстрее стучать в потолок, чем бекенды. Может подумать все же о схеме 2(nginx и бекенд)+2 (mysql) b определиться что важнее LB или HA.
kode
never knows best
MySQL/Nginx <-> [Nginx+FastCGI, Nginx+FastCGI]
-~{}~ 24.07.08 13:19:
статику можно отдавать двумя путями:
1) Кеширующий NFS (http://www.badros.com/greg/doc/enhanced-linux-nfs-client/index.html)
2) Держать статику на фронтенде
Хотя я не спец по хайлоаду
-~{}~ 24.07.08 13:19:
статику можно отдавать двумя путями:
1) Кеширующий NFS (http://www.badros.com/greg/doc/enhanced-linux-nfs-client/index.html)
2) Держать статику на фронтенде
Хотя я не спец по хайлоаду
seva2
Партнер PHPClub.ru
А что думаете по такой схеме:
мы поднимаем на 3-х серверах полные наборы апач+нгинкс
На главном мы прописываем бекенды для распределение нагрузки
из 8 клиентов 2 останутся на внешнем сервере и по 3 уудт на бекенды сервера 2 и 3
+ отдельный сервер под mysql
Что думаете и какие слабые стороны у такой системы есть?
мы поднимаем на 3-х серверах полные наборы апач+нгинкс
На главном мы прописываем бекенды для распределение нагрузки
из 8 клиентов 2 останутся на внешнем сервере и по 3 уудт на бекенды сервера 2 и 3
+ отдельный сервер под mysql
Что думаете и какие слабые стороны у такой системы есть?