Как правильно настроить проект с балансировщиком нагрузки, разместить одну базу на 2 серверах, разместить один сайт на 5 серверах?

Question

[shevalex78]

Добрый день, подскажите пожалуйста (или направьте на путь истинный - где можно почитать, изучить эту тему)
имеется схема:
Балансировщик нагрузки (2 шт.) -> сервера с сайтом (5 шт.) -> База данных (2 сервера)
отсюда вопросы:
1. Нужно сделать 2 сервера с одной (общей)базой данных, куда обращаются сервера с сайтом (5шт). Как это все реализовать? (желательно много русских ссылок)
2. Клиент авторизуется на сайте (допустим на сервере 3, который в данный момент подключен к серверу номер 1 с базой), при обновлении страницы балансировщик отправляет клиента на сервер номер 4, который в этот момент подключен к серверу номер 2 с базой. Ему надо будет заново авторизоваться? Где можно прочитать по сессиям?
3. Если внесли какие-то правки в файлы сайта, эти правки руками надо на всех (в данном случае 5) серверах?
4. Какие еще подводные камни могут быть? Дайти больше инфы кто с этим сталкивался.

Answer 1

[regretful]

Рекомендую ознакомиться с RuHighload

Answer 2

[Vi]

HAproxy( or nginx) -> 5 sites -> HAproxy(without nginx) -> 2 mariadb(master-master galera cluster)

/var/www/your-site -> lsyncd -> между пятью сайтами

Comments

[Vi]

master - master актуальнее тк иначе slave будет работать только когда основной master сломался (особенно если у вас всего лишь две базы данных, а не двадцать)

[Vi]

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

[shevalex78]

Vi: тогда повторная авторизация?

[Vi]

shevalex78: вы можете тегировать ip клиентов и каждый тег отправлять соседнему серверу и помечать что он уже авторизовался или сделать общую файловую систему и там помещать все сессии и все характеристики каждого из клиентов, и получается перед приемом нового соединения сервер сначала глянет а не авторизовался ли он уже до этого

[Vi]

shevalex78: варианты с тегированиям и маркировкой достаточно дешевые в реализации

[shevalex78]

Vi: то что нужно. Как эта технология называется и где почитать про нее?

[Vi]

а вообще можно сделать еще круче, Контейнеры) но это уже сложные архитектуры

[Vi]

shevalex78: это реализуется логикой вашего приложения тоесть операционная система передает вам запрос а вы его уже логируете и дальше делаете что хотите, или у вас просто сайт со статической информацией ?

[Vi]

shevalex78: ничего кстати отправлять руками не надо, технологии можно использовать следующие
- Destribution file system
- lsyncd (rsycn daemon) or alternative
- NFS/CIFS or network shared folder
- ISCSI or shared block devices
- Containers (Docker и я пока не знаю другой альтернативы для этих целей, есть еще LXC or OpenVZ, но я не уверен что они тут применяются)

это и еще коечто что я потерял из внимания можно использовать чтобы синхронизировать часть контента или весь сайт целиком или только сессии пользователей, или даже целый сервер с приложением

[Vi]

HAproxy удобен для балансировки тк у него вроде бы 12 методов отслеживания соединений( nginx всего 3 и четвертый в платной версии)
к тому же там всего один конфиг и один бинарный файл в HAproxy.
пока что мне кажется что HAproxy намного гибче в конфигурации он настолько гибкий что можно даже не парится что пользователь будет логинется заново и попробовать забить на пункт три

[shevalex78]

Vi: есть 2 варианта хранения кэша, первый- в файлах, второй в мемкэш, файлы можно синхронизировать, а с мемкешем как быть?

[Vi]

shevalex78:
- | app - > Balancer -> double cache to all servers
- | app1 -> memcached1 <-> mecached2 <-> appN
- | так же можно сделать один memcachel на san ферме ....
блин вариатов очень много даже нет смысла все описывать
уже все эти базы дублируются реплецируются и масшабируются что единственное где может быть проблема если пользователей 1 00 000 и более тогда там уже могут начатся глюки и отдельных пользователей которые попали на стечение обстоятельств

[Vi]

shevalex78: называй все не сервер а кластер и вуаля все проблемы решены

Кластер Proxy(Haproxy) -> Кластер App -> Кластер Cache(Redis, Memcached) -> Кластер DB(SQL or NOsql)

[shevalex78]

Vi: спасибо, буду читать)

[Vi]

shevalex78: можете начать с www.linuxvirtualserver.org
что касательно кластеров