Цитата(awers @ 5.3.2008, 13:38  ) |
| Cisco - балансировщик нагрузок |
балансировщик ведь может быть любой.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Для профи > Распределение нагрузки по серверам |
| Автор: Wowa 5.3.2008, 14:28 |
| Пишу проект на PHP, использую в качестве веб-сервера Apache.. Нужна система способная справиться с очень большим объемом посетителей на сайте. Переписать всё на яву - не предлагайте. Не вижу смысла. Мне кажется, что решения написанные на пхп должны без проблем справляться с любой нагрузкой, если распределить обработку пхп-скриптов по разным серверам (пример: wikipedia). А в Базу данных поставить на отдельном сервере/серверах. Т.е. со стороны Базы данны - проблем не предвидится, т.к. есть много хорого зарекомендовавших себя технологий. Интересная сторона PHP. Давайте пообсуждаем, как бороться и распределять нагрузку. Можно использовать в качестве веб-сервера nginx, но это имхо решение для "бедных", когда нет возможности поставить нужное кол-во серверов. А если серверов достаточно, то как распределять нагрузку лучшим образом? Какие есть решения, предложения? |
| Автор: awers 5.3.2008, 14:38 |
| Варианта всего два. Cisco - балансировщик нагрузок, либо грамотная реализация MVC. Других вариантов я не вижу |
| Автор: Wowa 5.3.2008, 15:19 | ||
балансировщик ведь может быть любой. |
| Автор: awers 5.3.2008, 15:28 |
| Wowa, я незнаю других ) |
| Автор: Sardar 5.3.2008, 15:50 | ||
Вообще то это не совсем вебсервер, а reverse-proxy, собственно то что тебе нужно. reverse-proxy - быстрая штука, распределяющая запросы на целую сетку серверов. Сам он ничего не вычисляет, просто держит/отдаёт статику, которую push'ат сервера на подобии apache. |
| Автор: Wowa 5.3.2008, 16:02 |
| ок, но как мне кажется самое простое и действенное решение, это распределять загрузку уже на уровне DNS (http://en.wikipedia.org/wiki/Round_robin_DNS). ДНС-сервера будут выдавать случайным образом IP-адрес какого-то веб-сервера. А с помощью этой штуки можно управлять распределеним. Например, временно убирать из списка перегруженные сервера. http://www.math.utah.edu/~pocock/lbnamed.html |
| Автор: Feldmarschall 5.3.2008, 16:43 |
| Стоило, наверное, посетить HighLoad или, хотя бы, Веборуб, если планировалась такая задача Вообще, с нуля, на форуме такие вещи не делаются, имхо. Ну что насоветуют такие советчики, как я? Тут действительно надо общаться со специалистами. Насколько я понимаю, тут же все в комплексе. отдельно - сервера с динамикой, ngnix + PHP fcgi отдельно - с картинками, ngnix или что-то ещё легче. фронтендами(ом?) в Мамбе, насколько мне известно, стоит ngnix сессии в мемкеше. вообще, можно посмотреть презентации с ХайЛоада, http://highload1.rutube.ru/ там должны быть, кажется, как раз, схемы. |
| Автор: marykone 5.3.2008, 16:50 | ||
совместно можно srv - запись использовать !! |
| Автор: Sardar 5.3.2008, 18:04 | ||
Тогда нужно истинно REST (state-less) сервисы, т.е. никаких PHP сессий. А это значит большую половину нынешнего кода в утиль. Хотя этот форум так разгрузить можно, он сессии свои в базе держит. Также могут быть траблы если целая сеть будет использовать DNS кеш, тогда все ломануться на твою прервую машину и так до обновления кеша... |
| Автор: Endeveit 6.3.2008, 13:13 |
| В самом простейшем случае - отказаться от монструозного апача в пользу "лайти", который имеет встроенный балансировщик. Подробнее http://trac.lighttpd.net/trac/wiki/Docs%3AModFastCGI#load-balancing. |
| Автор: FractalizeR 8.3.2008, 13:37 |
| Подобная проблема уже обсуждалась на форуме неоднократно. И рекомендации приводились (типа папку для хранения сессий разместить на одном из серверов и примонтировать по NFS на все остальные). Думаю, сначала стоит прочитать все, что есть по этому вопросу на форуме и только потом начинать тему с вопросом. |
| Автор: IZ@TOP 12.3.2008, 16:57 |
| Вов, чем тебе Nginx не угодил? У нас все проекты им прикрыты как балансером. Статику им же отдаем (картинки, css, js и т.п.). Посещаемость - от 1 млн. до 100 млн. обращений в сутки. |
| Автор: WIPS 30.4.2008, 22:38 |
| Сервера закрываем http://www.freebsd.org/doc/en/books/handbook/carp.html-ом. Сессии в БД или через NFS. Скрипты либо дублируются по всем серверам, либо опять же доступны через NFS. Хотя идея с NFS имеет один минус - если сервер отваливается, все процессы обращающиеся туда лочатся, что не очень приятно. |
| Автор: Wowa 13.5.2008, 16:44 |
| Стартовав эту тему я заблуждался думая. что проблем с Базой Данных не будет. На самом деле это самая серьезная проблема в сильно посещаемых проектах. Для сессий и кеширования надо использовать memcache запущенный на отдельном(-ых) сервере(-ах). База при определённой нагрузке начнет не справляться с сессиями. PHP масштабируется очень легко. Хотя бы даже через робин ДНС или nginx Полнотекстовый поиск по БД - тут Сфинкс подойдет. Также масштабирование не вызовет проблем. А вот для базы данных нужно ставить один Master(операции записи) и несколько Slave-серверов(операции чтения). Использовать репликацию. Но при определенной нагрузке, БД все равно не будет выдерживать. Поэтому базу и таблицу придеся сегментировать(прим. разделять на части). IZ@TOP, у вас применяется сегментирование БД ? Интересно бы знать, когда без него уже не обойтись. При каком объеме данных и при каком кол-ве запросов. |
| Автор: Kallisto 14.5.2008, 08:59 |
| Wowa, можешь написать какая стоит сейчас архитектура и что используется. Самому интересно в дальнейшем будущем будет, прошу поделиться идеей. |
| Автор: MoLeX 14.5.2008, 09:13 | ||
поддерживаю. раньше не имел дело с очень уж большим кол-вом поситителей, но мощности наращиваются и стало интересно как это дело организуют умные люди  |
| Автор: Wowa 14.5.2008, 10:52 | ||
Все то, что я описал в пред. посте. Проблема лишь с БД сейчас. Стоит MySQL на одной машине и всё. Но пока и посещаемости нет. |
| Автор: Endeveit 14.5.2008, 12:41 |
| Wowa, у нас на выделенном сервере, правильно настроенный сервер MySQL, обрабатывает порядка 350 запросов в секунду (и это не предел). Все запросы, естественно, очень легкие и быстрые. Данных - несколько гигабайт (десятки миллионов строк). Тяжелые запросы агрессивно кэшируются на уровне приложения в оперативной памяти или в SQLite. Цифры, не Бог весть какие, конечно, но как пример рассматривать их можно. |
| Автор: IZ@TOP 22.5.2008, 11:49 | ||
А как насчет 2-3K qps, из которых 9/10 запросы на изменение/добавление данных? При этом 5-7 Slave и еще пара системных Master'ов (для поисковой индексации). Wowa, у нас архитектура БД разделена на несколько понятий: 1. Global - глобальная база данных (пользователи, view, денормализованные данные). 2. Серия серверов Application: contest, sms и т.п. 3. Сессии - отдельный master-сервер. Хранить сессии в Memcache не рекомендуется, так как он не гарантирует постоянного хранения данных. 4. Партиции - пользовательские данные разбросанные по разным сериям мастер-слейв,слейв2,слейв3 и т.п. Соответственно, все типы хранилищ являются серией серверов мастер-слейв,слейв1...слейвN. Запросы, которые стало невозможно выполнить в виду разделения данных по разным регионам (мастерам), кэшируем в Memcache; к примеру, пользователи-конкурсные фото. Но есть и минусы. Будут вопросы, обращайся в ICQ. Кстати, наш ведущий будет выступать на PHPConf 2008 и подробно расскажет про архитектуру PhotoFile (которая несколько схожа с flickr'ом). |
| Автор: Endeveit 22.5.2008, 15:21 |
| IZ@TOP, у меня там в сообщении есть последнее предложение ;) |