Создание "кластера" для изучения...

Технологии постороения кластеров (вычислительных и отказоустойчивых), настройка терминал серверов,
SAN , NAS, FibreChannel, Infiniband

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
Dmitriy Khan
Junior member
Сообщения: 4
Зарегистрирован: 06 апр 2005, 21:53
Откуда: Saint-Peterburg
Контактная информация:

Создание "кластера" для изучения...

Сообщение Dmitriy Khan » 08 апр 2005, 12:16

Здравствуйте.

передо мной встала задача - создать "кластер" (не настоящий с распред. вычислениями, а просто балансирование нагрузки на несколько сервеов) для изучения вопроса балансировки нагрузки.

Интересует создание "дешевой" архитектуры "серверной фермы".

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

кол-во серверов - от 4х (машины класса пентиум 3 600-700 Мгц, 256 ОЗУ)
кол-во клиентов - в зависимости от возможностей серверов.

все что смог придумать это:

      | mysql |
            |
            |
--------------------------------------------------
    |               |               |                 |
|server|    |server|     |server|      |server|
    |               |               |                 |
--------------------------------------------------
             |
             |
      |balancer|
             |
             |
--------------------------------------------------
   |             |              |               |
|client|    |client|     |client|      |client|


в связи с подобной архитектурой возникают вопросы:
1. Годится ли вообще? (если у кого-то есть опыт построения подобных систем - поделитесь пожалуйста - накидайте ссылок :))
2. Хватит ли производительности Мускула для обеспечения данными серверов? Не станет ли база данных узким местом?
Как сильно нагружаются современные веб сервера (может не стоит дергаться, а посмотреть в сторону других более прожорливых служб и т.д.)
3. какого характера основное содержание совр. веб серверов? (как устоены совр. сайты? много ли статично информации. необходим ли серверу доступ к диску на запись? или он может хранить все в базе? и т.д.) То есть смогу ли я подключить статичную часть как сетевую папку? (нфс к примеру подрубить и забыть про синхронизацию и т.д.)

Есть еще вопросы, но пока наверное хватит :).

Аватара пользователя
apelsin
Advanced member
Сообщения: 470
Зарегистрирован: 09 окт 2004, 12:32

Сообщение apelsin » 08 апр 2005, 13:37

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
Последний раз редактировалось apelsin 08 апр 2005, 13:45, всего редактировалось 1 раз.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 08 апр 2005, 13:40

Для хранения файлов можно использовать расшириваемую файловую систему. В данном случае GFS.

Аватара пользователя
apelsin
Advanced member
Сообщения: 470
Зарегистрирован: 09 окт 2004, 12:32

Сообщение apelsin » 08 апр 2005, 13:53

gs писал(а):Для хранения файлов можно использовать расшириваемую файловую систему. В данном случае GFS.
Вопрос: а вы использовали GFS? если да, то как и где, и каковы впечателния?

+ для использования GFS надо строить общую файловую систему на FC или еще на чем; в вышеописанной схеме такого не предусмотренно

Dmitriy Khan
Junior member
Сообщения: 4
Зарегистрирован: 06 апр 2005, 21:53
Откуда: Saint-Peterburg
Контактная информация:

Сообщение Dmitriy Khan » 08 апр 2005, 14:28

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
а балансировщик у меня уже есть :)

Спасибо за ответы :). . .пойду еще читать и спрашивать. .

Dmitriy Khan
Junior member
Сообщения: 4
Зарегистрирован: 06 апр 2005, 21:53
Откуда: Saint-Peterburg
Контактная информация:

Сообщение Dmitriy Khan » 08 апр 2005, 14:30

gs писал(а):Для хранения файлов можно использовать расшириваемую файловую систему. В данном случае GFS.
А почему именно GFS?  
у меня все вместе (весь сайт и т.д. - статичная часть) уместится на сотне килобайт. Зачем мне gfs или это технология дает какие-то преимущества в моем случае (перед нфс или даже самбой :))

Аватара пользователя
apelsin
Advanced member
Сообщения: 470
Зарегистрирован: 09 окт 2004, 12:32

Сообщение apelsin » 11 апр 2005, 10:40

Dmitriy Khan писал(а):
apelsin писал(а):1. такое решение вполне годится. Есть опыт применения похожей схемы для webmail.
А не подскажете литературку по теме? Как вообще строятся эти "кластера" (архитектуры и схемы и почему именно такие?)
Кластера бывают разные, способы построения зависят от задачи. Для веб-приложений часто применяется описанный вами способ: копия одного и того же приложения исполняется на нескольких машинах одновременно -- цели: повышения производительности (N машин обслуживают incoming requests быстрее чем одна), отказоустойчивости (если одна нода накроется, то N-1 останутся), маштабируемость (можно просто увеличить количество машин, что проще и зачастую дешевле чем upgrade одной большой машины)

Так как все машины "кластера" между собой толком не связаны, то никакой  специальной литературы по этому вопросу нет, да и не требуется. Так как речь видимо идет о каком-то серьезном веб-приложении, которое скорее всего будет работать с Apache, дополнительные знания, в дополнение к тому как править конфиг и пере запускать сервер, явно не будут лишними.  Могу посоветовать эту книжку про Apache web server

Изображение

подробности + download

Явно не будет лишней книга по языку на котором написано ваше веб-приложение, но так как про это мне ничего не известно, то советов дать не могу.    
Dmitriy Khan писал(а):
apelsin писал(а):2.
А)производительности MySQL вполне хватит. К примеры, yahoo  использует mysql на определенных задачах, если вы не собираетесь строить что-то большее чем yahoo, то тогда mysql вам вполне подойдет.
А какая машина нужна, чтобы обеспечить данными сервера? (имеется ввиду та, где будет мискуль) мне ведь нужно с большим запасом, чтобы сервера не ждали. Мне сервера надо загрузить до отказа. Так как буду исследовать балансировку нагрузки (это работать никогда не будет ни на кого :)), то есть распределение нагрузки по серверам и т.д.
Не зная как работает ваше веб-приложение и не зная размеров и темпа роста вашей базы конкретный совет дать непросто. В общих чертах: сильный проц не нужен, памяти чем больше тем лучше (желательно чтоб все индексы  влезли в память , плюс 64+KB на каждое   соединение с базой) , очень возможно что потребуется сильная дисковая система.

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

Спасибо за ответы :). . .пойду еще читать и спрашивать. .
я понимаю что "балансировщик уже есть", но тем не мнение обращаю ваше внимание что указанный выше способ балансировки держит часть информации в кеше, что позволяет существенно ускорить работу всей системы. Этот способ еще называют http-accelerator ... Во общем советую почитать (в не зависимости от наличия балансировшика)

За ответы -- Пожалуйста!
С уважением,

Ответить

Вернуться в «Кластеры, Аппаратная часть»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 8 гостей