Создание "кластера" для изучения...
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Junior member
- Сообщения: 4
- Зарегистрирован: 06 апр 2005, 21:53
- Откуда: Saint-Peterburg
- Контактная информация:
Создание "кластера" для изучения...
Здравствуйте.
передо мной встала задача - создать "кластер" (не настоящий с распред. вычислениями, а просто балансирование нагрузки на несколько сервеов) для изучения вопроса балансировки нагрузки.
Интересует создание "дешевой" архитектуры "серверной фермы".
Эксперименты будут ставиться скорее всего на
1. Веб службе (хттп), так как наиболее распространенная.
2. Другие службы требующие больших выч-х мощностей (но которые представляют собой кучу мелких запросов), если таковые вообще имеются (пока над этим не думал - если есть идеи и если нужно что-либо посчитать - дайте знать - я попробую :) )
кол-во серверов - от 4х (машины класса пентиум 3 600-700 Мгц, 256 ОЗУ)
кол-во клиентов - в зависимости от возможностей серверов.
все что смог придумать это:
| mysql |
|
|
--------------------------------------------------
| | | |
|server| |server| |server| |server|
| | | |
--------------------------------------------------
|
|
|balancer|
|
|
--------------------------------------------------
| | | |
|client| |client| |client| |client|
в связи с подобной архитектурой возникают вопросы:
1. Годится ли вообще? (если у кого-то есть опыт построения подобных систем - поделитесь пожалуйста - накидайте ссылок :))
2. Хватит ли производительности Мускула для обеспечения данными серверов? Не станет ли база данных узким местом?
Как сильно нагружаются современные веб сервера (может не стоит дергаться, а посмотреть в сторону других более прожорливых служб и т.д.)
3. какого характера основное содержание совр. веб серверов? (как устоены совр. сайты? много ли статично информации. необходим ли серверу доступ к диску на запись? или он может хранить все в базе? и т.д.) То есть смогу ли я подключить статичную часть как сетевую папку? (нфс к примеру подрубить и забыть про синхронизацию и т.д.)
Есть еще вопросы, но пока наверное хватит :).
передо мной встала задача - создать "кластер" (не настоящий с распред. вычислениями, а просто балансирование нагрузки на несколько сервеов) для изучения вопроса балансировки нагрузки.
Интересует создание "дешевой" архитектуры "серверной фермы".
Эксперименты будут ставиться скорее всего на
1. Веб службе (хттп), так как наиболее распространенная.
2. Другие службы требующие больших выч-х мощностей (но которые представляют собой кучу мелких запросов), если таковые вообще имеются (пока над этим не думал - если есть идеи и если нужно что-либо посчитать - дайте знать - я попробую :) )
кол-во серверов - от 4х (машины класса пентиум 3 600-700 Мгц, 256 ОЗУ)
кол-во клиентов - в зависимости от возможностей серверов.
все что смог придумать это:
| mysql |
|
|
--------------------------------------------------
| | | |
|server| |server| |server| |server|
| | | |
--------------------------------------------------
|
|
|balancer|
|
|
--------------------------------------------------
| | | |
|client| |client| |client| |client|
в связи с подобной архитектурой возникают вопросы:
1. Годится ли вообще? (если у кого-то есть опыт построения подобных систем - поделитесь пожалуйста - накидайте ссылок :))
2. Хватит ли производительности Мускула для обеспечения данными серверов? Не станет ли база данных узким местом?
Как сильно нагружаются современные веб сервера (может не стоит дергаться, а посмотреть в сторону других более прожорливых служб и т.д.)
3. какого характера основное содержание совр. веб серверов? (как устоены совр. сайты? много ли статично информации. необходим ли серверу доступ к диску на запись? или он может хранить все в базе? и т.д.) То есть смогу ли я подключить статичную часть как сетевую папку? (нфс к примеру подрубить и забыть про синхронизацию и т.д.)
Есть еще вопросы, но пока наверное хватит :).
1. такое решение вполне годится. Есть опыт применения похожей схемы для webmail.
2.
А)производительности MySQL вполне хватит. К примеры, yahoo использует mysql на определенных задачах, если вы не собираетесь строить что-то большее чем yahoo, то тогда mysql вам вполне подойдет.
Б) современные сайты это в основном скрипты а не статичная информация.
Сервер со скриптами часто бывает CPU-bound а не IO-bound, поэтому перенос задач на несколько серверов очень даже помогает.
3. Сервер использует диск для записи, хотя-бы для хранения логов. А вот от идеи хранения данных в виде файлов/папок при описанной вами схеме придется отказаться, так как возникнут проблемы с синхронизацией данных. То есть: храните все данные в БД.
( про НФС вообще лучше забыть)
по поводу "балансинга", ключевые слова здесь такие:
reverse proxy cache почитайте тут http://squid.visolve.com/squid/reverseproxy.htm
и тут http://www.squid-cache.org/Doc/FAQ/FAQ- ... ccelerator
2.
А)производительности MySQL вполне хватит. К примеры, yahoo использует mysql на определенных задачах, если вы не собираетесь строить что-то большее чем yahoo, то тогда mysql вам вполне подойдет.
Б) современные сайты это в основном скрипты а не статичная информация.
Сервер со скриптами часто бывает CPU-bound а не IO-bound, поэтому перенос задач на несколько серверов очень даже помогает.
3. Сервер использует диск для записи, хотя-бы для хранения логов. А вот от идеи хранения данных в виде файлов/папок при описанной вами схеме придется отказаться, так как возникнут проблемы с синхронизацией данных. То есть: храните все данные в БД.
( про НФС вообще лучше забыть)
по поводу "балансинга", ключевые слова здесь такие:
reverse proxy cache почитайте тут http://squid.visolve.com/squid/reverseproxy.htm
и тут http://www.squid-cache.org/Doc/FAQ/FAQ- ... ccelerator
Последний раз редактировалось apelsin 08 апр 2005, 13:45, всего редактировалось 1 раз.
Вопрос: а вы использовали GFS? если да, то как и где, и каковы впечателния?gs писал(а):Для хранения файлов можно использовать расшириваемую файловую систему. В данном случае GFS.
+ для использования GFS надо строить общую файловую систему на FC или еще на чем; в вышеописанной схеме такого не предусмотренно
-
- Junior member
- Сообщения: 4
- Зарегистрирован: 06 апр 2005, 21:53
- Откуда: Saint-Peterburg
- Контактная информация:
apelsin писал(а):1. такое решение вполне годится. Есть опыт применения похожей схемы для webmail.
А не подскажете литературку по теме? Как вообще строятся эти "кластера" (архитектуры и схемы и почему именно такие?)
А какая машина нужна, чтобы обеспечить данными сервера? (имеется ввиду та, где будет мискуль) мне ведь нужно с большим запасом, чтобы сервера неждали. Мне сервера надо загрузить до отказа. Так как буду исследовать балансировку нагрузки (это работать никогда не будет ни на кого :)), то есть распределение нагрузки по серверам и т.д.apelsin писал(а):2.
А)производительности MySQL вполне хватит. К примеры, yahoo использует mysql на определенных задачах, если вы не собираетесь строить что-то большее чем yahoo, то тогда mysql вам вполне подойдет.
да нее, про логи и т.д. понятно - это служебное. На это не смотрим это делают все, а значит можно и "забить" (оценить стоит, но можно и не рассматривать). Хотя все зависит от конфигурации сервера (мало ли что там крутится).apelsin писал(а):3. Сервер использует диск для записи, хотя-бы для хранения логов. А вот от идеи хранения данных в виде файлов/папок при описанной вами схеме придется отказаться, так как возникнут проблемы с синхронизацией данных. То есть: храните все данные в БД.
( про НФС вообще лучше забыть)
Все, все, все хранить в базе не получится. Статический контент все равно будет присутствовать. (а так как он статический я подумал, а почему бы и не сетевая фс)
а балансировщик у меня уже есть :)apelsin писал(а):по поводу "балансинга", ключевые слова здесь такие:
reverse proxy cache почитайте тут http://squid.visolve.com/squid/reverseproxy.htm
и тут http://www.squid-cache.org/Doc/FAQ/FAQ- ... ccelerator
Спасибо за ответы :). . .пойду еще читать и спрашивать. .
-
- Junior member
- Сообщения: 4
- Зарегистрирован: 06 апр 2005, 21:53
- Откуда: Saint-Peterburg
- Контактная информация:
А почему именно GFS?gs писал(а):Для хранения файлов можно использовать расшириваемую файловую систему. В данном случае GFS.
у меня все вместе (весь сайт и т.д. - статичная часть) уместится на сотне килобайт. Зачем мне gfs или это технология дает какие-то преимущества в моем случае (перед нфс или даже самбой :))
Кластера бывают разные, способы построения зависят от задачи. Для веб-приложений часто применяется описанный вами способ: копия одного и того же приложения исполняется на нескольких машинах одновременно -- цели: повышения производительности (N машин обслуживают incoming requests быстрее чем одна), отказоустойчивости (если одна нода накроется, то N-1 останутся), маштабируемость (можно просто увеличить количество машин, что проще и зачастую дешевле чем upgrade одной большой машины)Dmitriy Khan писал(а):А не подскажете литературку по теме? Как вообще строятся эти "кластера" (архитектуры и схемы и почему именно такие?)apelsin писал(а):1. такое решение вполне годится. Есть опыт применения похожей схемы для webmail.
Так как все машины "кластера" между собой толком не связаны, то никакой специальной литературы по этому вопросу нет, да и не требуется. Так как речь видимо идет о каком-то серьезном веб-приложении, которое скорее всего будет работать с Apache, дополнительные знания, в дополнение к тому как править конфиг и пере запускать сервер, явно не будут лишними. Могу посоветовать эту книжку про Apache web server

подробности + download
Явно не будет лишней книга по языку на котором написано ваше веб-приложение, но так как про это мне ничего не известно, то советов дать не могу.
Не зная как работает ваше веб-приложение и не зная размеров и темпа роста вашей базы конкретный совет дать непросто. В общих чертах: сильный проц не нужен, памяти чем больше тем лучше (желательно чтоб все индексы влезли в память , плюс 64+KB на каждое соединение с базой) , очень возможно что потребуется сильная дисковая система.Dmitriy Khan писал(а):А какая машина нужна, чтобы обеспечить данными сервера? (имеется ввиду та, где будет мискуль) мне ведь нужно с большим запасом, чтобы сервера не ждали. Мне сервера надо загрузить до отказа. Так как буду исследовать балансировку нагрузки (это работать никогда не будет ни на когоapelsin писал(а):2.
А)производительности MySQL вполне хватит. К примеры, yahoo использует mysql на определенных задачах, если вы не собираетесь строить что-то большее чем yahoo, то тогда mysql вам вполне подойдет.), то есть распределение нагрузки по серверам и т.д.
В той системе webmail главная нагрузка была на IMAP сервер, а не MySQL базу. Все это сидело на вот такой машине, так что тормозов там не было.
статический контент это понятно. в том webmail'е с которым я имел дело, там веб-сервера загружались по сети, и image /var файловой системы тоже грузился через сеть, но монтировался локально. В случае сбоя машина просто перегружалась. Вся изменяемая информация (user prefrences, address book) была в MySQL.Dmitriy Khan писал(а):да нее, про логи и т.д. понятно - это служебное. На это не смотрим это делают все, а значит можно и "забить" (оценить стоит, но можно и не рассматривать). Хотя все зависит от конфигурации сервера (мало ли что там крутится).apelsin писал(а):3. Сервер использует диск для записи, хотя-бы для хранения логов. А вот от идеи хранения данных в виде файлов/папок при описанной вами схеме придется отказаться, так как возникнут проблемы с синхронизацией данных. То есть: храните все данные в БД.
( про НФС вообще лучше забыть)
Все, все, все хранить в базе не получится. Статический контент все равно будет присутствовать. (а так как он статический я подумал, а почему бы и не сетевая фс)
я понимаю что "балансировщик уже есть", но тем не мнение обращаю ваше внимание что указанный выше способ балансировки держит часть информации в кеше, что позволяет существенно ускорить работу всей системы. Этот способ еще называют http-accelerator ... Во общем советую почитать (в не зависимости от наличия балансировшика)Dmitriy Khan писал(а):а балансировщик у меня уже естьapelsin писал(а):по поводу "балансинга", ключевые слова здесь такие:
reverse proxy cache почитайте тут http://squid.visolve.com/squid/reverseproxy.htm
и тут http://www.squid-cache.org/Doc/FAQ/FAQ- ... ccelerator
Спасибо за ответы. . .пойду еще читать и спрашивать. .
За ответы -- Пожалуйста!
С уважением,
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя