конфигурация WEB кластера

Может школу закончишь?

может научишься с людьми разговаривать?

А в этих 3х языках русский будет присутствовать? если да, то увы - ваш проект обречен на неудачу. :( Примите мои соболезнования.

я постараюсь подитожить и сказать мягко.
cbh1 - попробуй(-те) всё же выучить теорию. почитайте linux-ha.org.
погуглите термин single sign-on, посмотрите на реализацию расспределённых систем, определитесь с понатием и назначением кластерных систем.
А вообще - "созрейте" - поработайте ещё в linux, понаступайте на камни.
Тогда бедт хоть какая-то надежда, что ваш "сервис" не загнётся в первый же день работы.
В общем, не спешите ломать дров.

Люди которые это умеют на лоре не сидят (c) :)

Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть лесными эльфами, охраной дворца и злодеем...

спасибо всем кто ответил по теме,я не линуксоид,говорю сразу и честно,я проджект менеджер(хотя когда то и я был админом,правда сетевым),администратор предложил мне некую схему,я доверяю своим сотрудникам но проверяю,ведь он не может знать всего,поэтому и прошу у вас помощи. Вы считаете неправильно строить кластер LVS+heartbeat для WEB систем?я нашел много описаний,подобных проектов,как бы сделали вы? Большое спасибо за направление Single Sign On,я не прошу вас раписать мне конфиги и как это делать,я прошу вас дать мне вреное направление Заранее спасибо всем кто хоть раз побывал в моей шкуре и понимает о чем я.

Да, и чуть не забыл: И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы...)

А по теме - насчет отказоустойчивости и масштабируемости читать в сторону http://www.gentoo.org/proj/en/cluster/

Мужик, ты о построении кластеров не сказал ровным счётом ничего. lvs и drbd это просто красивые слова. Посмотри видео с, скажем, rit или rootconf(если оно выложено), почитай книжки и презентации(а ещё лучше доверь вопрос тем кто в нём разбирается). А пока я вижу что вы абсолютно ничего не понимаете и абсолютно ничего не сделали. Я тоже могу умных слов наговорить: шардинг, репликация, HA, high load, gigabit ethernet, cisco pix, juniper, oracle, hp proliant, online hot backup, load balancing, etc :). Я похож на твоего сисадмина? :)

Если вы действительно хотите забабахать большой проект а не наколеночное поделие то тебе потребуется системный архитектор и программисты. Одним сисадмином сыт не будешь. GO в в раздел job писать вакансии.

> А пока я вижу что вы абсолютно ничего не понимаете и абсолютно ничего не сделали.

Ну он как бы честно признался и почти что покаялся:

> говорю сразу и честно,я проджект менеджер

> я прошу вас дать мне вреное направление

1. Современный русский язык: Учебник для вузов (под ред.Валгиной Н.С.) Изд. 6-е, перераб., доп. ISBN 5-98704-040-X

> я доверяю своим сотрудникам

2. именно это и делай

> кто хоть раз побывал в моей шкуре и понимает о чем я.

3. Побывавши в твоей шкуре, я настоятельно советую тебе сменить профиль деятельности. No offense.

Да ну вас в болото,просто надоело уже,вот какая кому нафиг польза от того что вы есть на этом форуме?ну есть у вас знания в какой то области,ну работаете вы с линуксом (с открытым учебником) и что? если вы не можете ответить по теме? Для примера я тоже сижу на тематических форумах(дать ссылки?) и когда заходит человек и спрашивает: мля я совсем запутался,как отличать agile и non-agile,Существует ли вообще такой термин, как спецификация, в Agile? Какими метриками или показателями можно померить степень успешности внедрения Agile? Я не посылаю его далеко и надолго,хотя могу и по вашей тупой логике должен,а объясняю вкратце,с меня ведь не убудет.Мне не жалко пощелкать несколько раз по клаве.И как для вас не странно мне приятно делиться своим опытом,к тому же иногда люди ставят такие вопросы,что учусь уже я. А для чего нахер тогда этот форум?

Персонально для ламерка ты вообще пипец какой умный ламло,да?И я очень сильно сомневаюсь,что тебе удалось побывать в какой-либо другой шкуре,кроме как ламера. Если бы ты действительно побывал бы в чужой шкуре,а конкретно в моей,то ты бы так не тупил,и понял бы как сложно организовать и собрать грамотные людские ресурсы с ограниченным бюджетом,и что бывает когда за проект отвечаешь лично ты,а именно бывает пофиг какой знающий админ или архитектор у тебя в штате,все проверяется и перепроверяется 10 раз.Я хотя бы пытаюсь разобраться сам,а не сижу и яйца грею.No offense.

Личная просьба администрации не удалять это сообщение,это не оскорбление,а попытка помочь тем, кто придет сюда за оветами после меня.

Для тех кто пытался помочь,еще раз спасибо,в своих изысканиях опирался на вот эти статьи http://wiki.linuxformat.ru/index.php/LXF102:Hardcore_Linux http://www.ibm.com/developerworks/ru/library/l-linux-ha/index.html http://xgu.ru/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80_%D0%BD%D0%B0_%D... http://xgu.ru/wiki/DRBD http://www.netup.ru/articles.php?n=13

касательно же MySQL,вот на это http://dev.mysql.com/doc/refman/5.1/en/ha-overview.html http://www.webnext.ru/blog/2007/08/21/replication-mysql-master-slave.html

если бюджет позволяет, обрати внимание на l7 баллансеры от циско.
внешнее хранилище.
база, например Mysql, кластеризуется.

т.е. вариант с решением задачи обеспечения доступности поэтапно (на каждом из слоев приложения) мне видится более предпочтительным, нежели чем лепить все в одно место.

нет друг,на это денег мне не выбить я знаю,к тому же есть опенсорс программное решение http://l7-filter.sourceforge.net/

касательно базы,кластеризация и репликация как описано здесь http://www.webnext.ru/blog/2007/08/21/replication-mysql-master-slave.html это одно и то же?

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

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

только не на localDirector )))
как я понял, тут вопрос доверия к админам.
ситуация сама по-себе тупик, увы ((

Ты меня растрогал. Столь длинного поста на лоре я не видел давно.
Давай для начала стартанем с двух простейших переменных, без которых дальнейшая беседа может идти только о сферическом веб-кластере в вакууме:
1) количество реальных железок
2) пиковое количество запросов в период времени.

Есть еще третий и самый ключевой вопрос: как выделяется бабло - по мере прогресса или уже выделено сразу оптом, но на него можешь не отвечать.

вот это уже дело 1) я думаю тебе нужно не только количество реальных железок,но их их качество в первой стадии речь идет о 5-6 серверах,стандартной конфигурации Core 2 DUO около 2.2 / 2gb ram / SCSI либо SAS 10000 RPM / 2 карты Ethernet gigabit Desktop есть сейчас на другом проекте 6 серверов раков Делл два процессора,4 ядра,8 гб РАМ,то есть довольно мощные машинки,но мне надо сделать стенд с того что есть,покрутить на нем,показать,запустить а потом можно будет говорить о миграции. 2)пиковое количество запросов затрудняюсь ответить,дам чуть позже Планируемое количнство уникальных пользователей в сутки на первой стадии до 15000,суммарно на всех сервисах 3)бабло выделяется по мере прогресса,будет прогресс выбью деньги Если есть еще вопросы задавай

:))). Один сервер такое потянет если программисты не идиоты. Ставьте одну восьмиядерную дуру вместо пачки серваков что есть щас по которым вы с такими знаниями ни в жизни нагрузку не размажите. Потом, когда дело пойдёт и будут бабки, уволишь текущих прогеров, найдёшь нормальных, найдёшь архитектора и они всё перепишут.

PS нагрузку считают не уникальными посетителями а запросами. На некоторые сайты человек приходит и сразу уходит. А есть такие где каждый юзер по тыще раз динамические страницы дёрнет.

Эпичный тред, да.

45000-50000 просмотров,на первом этапе ,учитываю что сайт придется дорабатывать и количество сервисов будет небольшим в первое время

ну вот и посчитай сколько запросов будет в секунду. Понятное дело ночью активность в разы меньше, но всё равно это даст представление о том что хватит и стандартной мощной тачки.

А кластер нормальный вы не родите, либо это будет очень кривое решение. Многие пытались, но мало у кого вышло. Кроме того, многие решения это палка о двух концах.

> Один сервер такое потянет

Один физический х86 не может гарантировать п. 1 - отказоустойчивость.

Потянуть - сильно зависит от того, что на нем будет запущено. Если дажнго с наваротами - то может и не. ))

С железом всё хорошо. Если LVS берется исключительно для балансировки - смысла в этом особого нет. Балансировка легко делается раунд-робином на днс или раскидывается проксями по айпишникам запросов. Дальнейшее зависит от харакетра данных и того, чего там программисты наваяют.

"Тяжелые" данные есть смысл вынести на отдельный интерфейс.

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

По поводу джанги. Программисты яндекса разгоняли её до 50 запросов на четырёхядерной тачке на проекте "куда". А значит восьмиголовая(или шеснадцатиголовая :)) будет гораздо шустрее. Ну и там много уровней кэширования которое может очень сильно ускорить это всё дело.

Если бы я составлял ТЗ я бы явно включил туда перфоманс. Чтобы писали код до тех пор пока одна тачка всех не обслужит. И у меня есть уже два success story когда прогеры после подзатыльников реально ускоряли проекты в разы.

> Более крутые схемы просто непропорционально сложнее.

хз, но как по мне - держать второй сервак только в качестве фэйловера - непростительное расточительство. ))

> Программисты яндекса разгоняли её до 50 запросов

А пересчеты агрегатных полей по всей базе они как победили?

> 1. Современный русский язык: Учебник для вузов (под ред.Валгиной Н.С.) Изд. 6-е, перераб., доп. ISBN 5-98704-040-X

Нет пути! Только Розенталь!

:)

по поводу раунд робина,имеет смысл его использовать внутри кластера для балансировки например нагрузки от шлюзующих WEB серверов в коннекте к хранилищу или БД. Внешний RoundRobin от провайдера лишен смысла http://www.citforum.ru/internet/webservers/web_cluster/

А вот что мне посоветовали у крупного партнера интегратора Кластеризация на MySql на нынешний период времени оставляет желать лучшего. Если упор делаете на непрерывность обслуживания, рекомендую режим актив-пассив раздельных и не знающих друг о друге серверов с репликацией на блочном уровне например DRBD. Достойных и надежных решений с балансировкой нагрузки я не знаю (те что знаю либо морально устарели, либо не надежны). Можно использовать продукт, то что называется MySQL Cluster но для нормальной работы потребуется +1 сервер который будет заниматься арбитражем,

> хз, но как по мне - держать второй сервак только в качестве фэйловера - непростительное расточительство. ))

Если ты распаралелил запросы на два сервера и один из них слёг то второй захлебнётся запросами. Поэтому в случае двух серверов нагрузка должна быть такая чтобы один сервак мог всё вытянуть. Вообще любое резервирование это всегда лишние затраты. Это помимо того что добавление нод в кластер пропорционально увеличивает производительность только в простых случаях.

кто говорит что мускла репликация говно тот просто не видел как реплицируется постгрес :).

Вижу, теперь и ты понимаешь что с наскока у вас ничего не выйдёт. Короче, ваш единственный вариант на данном этапе это вертикальное масштабирование. Всё остальное просто будет не по зубам вашим специалистам, либо будет дико глючить, либо сорвёте все реальные и нереальные сроки.

то есть ты имеешь в виду смотреть в сторону увеличения мощности серверов а не их количества? возможно спорить не хочу,но есть таблица для каких систем рекомендуется горизонтальное а для каких вертикальное маштабирование http://www.bytemag.ru/articles/detail.php?ID=6670

что думаешь по поводу статьи?

Это и есть учебник Розенталя ))) Последнее переиздание.

> Если ты распаралелил запросы на два сервера и один из них слёг то второй захлебнётся запросами.

Только при условии, что он не может их вытянуть в одиночку.

> Это помимо того что добавление нод в кластер пропорционально увеличивает производительность только в простых случаях.

Ну так на фотки.*/знакомства.*/блоги.*/фигня.сайт.ру вряд ли кто-то будет делать расчеты физмоделей. Собственно задача создания высоконагруженного веб-приложения и сводится к тому, как граматно это всё распаралелить. И на двух серверах все косяки решения увидить легче, чем на одном. )))

> Внешний RoundRobin от провайдера лишен смысла

Нет никакой разницы между кэшем провайдера и кэшем конкретного хоста. И разумеется не надо выставлять ttl для записей в неделю.

> имеет смысл его использовать внутри кластера для балансировки например нагрузки от шлюзующих WEB серверов в коннекте к хранилищу или БД.

1. Твои шлюзующие прокси - уже часть кластера, если ты хочешь выполнить п.1
2. Распаралеливать зачастую гораздо легче и осмысленней именно запросы к софту, в идеальном случае паралелить запросы к хранилищу/бд просто не потребуется.

> то есть ты имеешь в виду смотреть в сторону увеличения мощности серверов а не их количества?

Не хотел расскрывать всех секретов, но раз уж спросил в лоб то отвечу. Чем меньше парк машин тем их (обычно)легче обслуживать(и тем больше проблем при поломки одного сервера). Да и из опыта оказалось удобным купить меганоду и на ней кучу виртмашин с сервисами создать, при необходимости перекидывая тазы и тем самым балансируя нагрузку. Даже не смотря на то что виртмашины дают очень хороший оверхед всё равно всё летает т.к. мощность ноды очень большая.

Кроме того, в зависимости от задачи и архитектуры применяются разные действия для генерации контента. Есть такие которые хорошо паралеляться, а есть такие которые нет. Если у вас в проекте много такого что нельзя раскидать по серверам то кластер не заработает в полную мощность. И пока вы не научитесь раскидывать задачки на несколько машин смысла начинать кластер не имеет вообще. Поэтому пока ваш путь тока один-мощный сервак.

Чтобы проникнуться всей сложностью задачи просто на одной тачке заведи несколько виртмашин и попроси прогеров и админов кластер поднять :))).

> что думаешь по поводу статьи? Это вводная обзорная статья которая не отвечает на вопрос "как это сделать". Считай, чистая теория(а тебе нужна практика). Но весьма полезная, она позволяет понять где искать проблемы.

> И на двух серверах все косяки решения увидить легче, чем на одном. )))

я и говорю, наипутся по полной. Когда всё говно вылезет наружу прогеры вешаться будут.

тоже фан реслинга ?
(это я по поводу ника ))) )
jeff hrady 4ever

> тоже фан реслинга ?

Был когда-то, немного, менять лень.

> (это я по поводу ника ))) )

Лиспер? :)

> jeff hrady 4ever

Kevin Nash - :)

ну если уже о старичках - то scott schteiner )))

спасибо всем за советы,буду ориентироваться на простоту

т.е. на старый-добрый, никем не опровержимый, почти юниксовый, принцип K.I.S.S. ?

этот старый принцип применим не только к юниксам))) а к любому проекту

K.I.S.S. вполне применим.