Многосерверность

Кстати, Гугл, использует прунинг (эшелонирование). Страшный сон вебмастеров: страницы попали во второй эшелон (supplemental results)

alexf2000, так мы на другом форуме и многопоточность обсуждали... ;)

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

Если брать классический ИФ, то там действительно для эффективной работы, нужно чтобы все кешировалось. Примерно по гигабайту ОЗУ на один миллион средних веб-документов. Или даже больше, если индекс не очень хорошо сжат. Но, вообще, говоря вдруг есть что-нибудь более эффективное чем классический индекс? Это вроде как факт пока недоказанный.

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

Хотелось бы еще добавить про организацию storage, т.к. в реалии используются различные интерфейсы с хорошой пропускной способностью. В частности, если брать скайзи, то есть такая замечательная штука под названием FC-AL. Не буду затрагивать вопросы надежности при использовании единого хранилища. Главное это то, что можно расшарить гигантский сторадж между множеством серверов... скорость доступа к которому измеряется гигабайтами в секунду, а дальше все от хардов зависит.

Обычное SCSI-320 это 320 мегабайт в секунду.

Дальше всё упирается в сетевую файловую систему. У Oracle это своя система, т.е. там это как raw, со своими особенностями, но не суть. В задачи такой файловой системы входят различные блокировки и т.д... т.к. если все сервера начнут туда писать одновременно, то при отсутстсвии синхронизации начинается хаос.

Лабораторное подобие такой инфраструктуры можно сделать имея на руках один SCSI hdd... т.е. не терминировать интерфейс, а другим концом воткнуть в другой компьютер. Если hdd на r/o, то фактически ничего делать и не надо, а если на него надо писать, к примеру, только с одной ноды, то операционкам других серверов надо что-то сообщать дополнительно. Что-то можно решить на уровне отключения read cache/write cache, но не суть... под каким-то файловыми системами оно очень даже стабильно работает.

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

Готовых И СТАБИЛЬНЫХ продуктов по теме сейчас превеликое множество... жалко только то, что забили на FreeBSD, а ой как надо...

Когда речь идёт о какой-то заточенной под такой кластер FS, то такими вопросами заморачиваться вообще не стоит.

Если охота помедитировать на тему "на коленке", то на время записи нужную партицию от остальных серверов просто отмонтируйте. Представим, что у нас несколько баз, каждая из которых лежит на своей партиции. На время записи в какую-то базу от остальных серверов её просто отмонтируем, а потом, когда наполнили, то цепляем её на все остальные уже на RO. Собирается фактически под любой unix-like. Работало как часы. Обслуживалось простыми скриптами на sh.

1 Гб в стораджах Sata 2 SCSI сейчас стоит копейки. Даже если оверхид солюшена по месту 50%, то это всяко дешевле, чем городить огород из коммерческих продуктов с дополнительными интерфесами под interconnect-ы. Ну само собой если солюшен под задачу по требованиям проходит. На новую партицию ноды можно переводить по очереди... shutdown софта, потом ремаунты, а потом поднятие. Главное, что бы в партицию подключенную к остальным на r/o ничего не писалось, тогда есть 100% гарантия, что этот солюшен можно использовать практически под всеми unix-like.

Сейчас рейды копейки стоят... ~5k$ за рейдину SATA2SCSI на 15 или 16 хардов, а там уже чем её наполнишь... если по 400gb, то это почти 6Тб, а там уже сколько сам рейд сожрет... и пару гиг памяти под кешаки туда еще загнать, что бы совсем со свистом летало.

PS. На копирайты не прендую, но и чью-то военную тайну тоже не раскрываю... эта тема стара как solaris.

Интересная тема. Ну про 60-80 мегов в рейде это понятно. А вот 320 - это интересно. Это на интеле??? Или все-таки, на сане?

На интеле, на интеле... какая разница intel или еще что-то... SCSI оно и в африхе SCSI (в т.ч. и FC-AL). У меня была мысля собрать тест под GEOM, но он тогда еще сырой был. Ну что бы как-то поиграться с расшареным raw девайсом, а потом как-то вспомнил про Соляру и Ораклю, где народ спокойно подвешивает хард между серверами.

Был у меня период, когда я кластеризацией (за дешево) просто по 18 часов в сутки бредил. Но в случаях с хостингом, а я тогда этот рисерч для хостинга делал, такое решение не проходит, т.к. нужны read/write, а на linux мне не хотелось ради этого переходить.

Собственно у Бориса тогда спрашивал на эту тему (да и не только... всех достал), но его how-to есть на opennet -> http://www.opennet.ru/base/sys/2scsihdd.txt.html

Если нужен одновременный write со всех серверов, т.е. уже на файловую систему, то нужно сразу брать заточеную... я уже по названиям не помню, но к фриибсд такое привинтить очень сложно. Мне за портинг линуксового продукта зарядили порядка 7k$.. а там еще и debug какой-то нужен и т.д... т.е. времени надо убить большое количество.

Если нужен одновременный read, то маунтишь на все сервера на RO и не паришься. Как только захотел туда что-то записать, то от остальных лучше размоунтить, а то бывали какие-то panic... даже не лучше, а надо размаунтить. В случаях с примером Бориса, там лабораторный стенд как-бы, для всяких кластерных издевательств... если берешь корзину, то вешаешь к ней сколько тебе надо серверов.

Теперь еще про один дешевый способ лабораторного стенда. Под FreeBSD есть GEOM, вот на базе этих фич на несколько серверов можно подавать какой-то hdd с какого-то сервера. С точки зрения операционки это будет такой же там /dev/xxx не помню чего там будет, но это будет блочный девайс. GEOM-Gate это вроде как называлось, сейчас уже все тонкости не помню. Получается это аля iSCSI, так что один и тот же хард можно расшарить между серверами, но по сетке. Этот хард можно сколько угодно раз подцепить к себе и еще кому-то по сетке скормить. Ценность в том, что можно издеваться удаленно, а в случах со scsi надо рядом с серверами быть... какие-то panic на каких-то экспериментах бывают.

А там уже играться с набором утилит для синхронизации реманутов.

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

Solaris, FreeBSD, Linux... какая разница... драйвера из одного места растут короче. Главное, что бы FS, которая на RO, она под всеми операционками этими понималась. Если у тебя корзина позволяет ограничить девайс хардварным способом на RO, то можешь и винду в эту кучу цеплять... от неё на RO лучше сразу.

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

По производительности raw transfer это к SCSI контроллерам, по производительности хардов к хардовикам... у корзин какие-то тесты под разные FS есть, под single access к volume. Т.е. какие-то отправные точки есть... но если рейдина оптимизирована под bandwith (или как там сейлзы обычно говорят?), то в совокупности на все сервера почти 320 и получишь... по интерфейсным данным, а по софтовым, то надо учитывать какой-то оверхид самой файловой системы... ну а потом еще какую-то конкурентность запросов к хардам и т.д... там же если памяти в корзину натыкать, то и упреждающее чтение настроить можно и т.д. и т.п... не помню уже модели, но где-то и 4GB ECC можно запихнуть... представь себе как с такой работать... ты с сервака в неё write делаешь, гигового файла... со скоростью бешенной... память в ней там с батарейками и т.д... как питалово отключится, так после включения допишет, если не успело. Это даже не на столько актуальные технологии.... сейчас очень много новинок есть, просто надо читать про всё это, а если хочется пощупать, то многим это просто недоступно... ну не у всех есть железо и подручные руки, что бы собрать тестовый стенд и поиграться.

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

Вот это если хочется всё готовое, так что бы R/W и с локингом.

http://www.lustre.org/

http://www.clusterfs.com/ (вот эти гады весь епен сорц испортили)

На тему стабильности не знаю, но когда я этим интерисовался, то это было еще в зачатачных состояних.. т.е. что-то работало, но TODO там гигантский был. Сейчас вроде даже продавать начали и Support 24x7.

Operating Systems: Red Hat Enterprise Linux 3+, SuSE Linux Enterprise Server 9, Linux 2.4 and 2.6

Platforms: IA-32, IA-64, x86-64, PowerPC

Interconnects: TCP/IP; Quadrics Elan 3 and 4; Mellanox and Voltaire Infiniband (non-TCP interconnect drivers are not included in binary packages)

Вот interconnects там как раз для локинга и синхронизации кэшей... интерфейсы ппц, я когда заглянул, то как-то даже самые продвинутые сетевухи вообще всерьез перестал воспринимать.

В РФ с этим вроде как Антон Нехороших (он на валуе был когда-то) игрался -> 310.ru... или у него там что-то аналогичное, но говорилось что работает и даже на FC-AL. Все вокруг слов CFS, Lustre, CPFS и т.д. Военной тайны вроде в этом нет.

PS. Может еще какие-то есть. У Veritas как всегда надо глянуть, т.к. что-то там было готовое.

А что вы все военные тайны поминует всуе? :-)

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

Ну военные тайны это такие вот конкуретные преимущества... если все будут делать хостинг на Plesk и Virtuozzo, то это будет не рынок а спам какой-то. И т.д. и т.п. если все будут знать как устроен Google, то будут клоны.

320MB это производительность SCSI интерфейса, контроллера и т.д... т.е. SCSI-160 160mb/s, SCSI 320 320Mb/s, потом там оптика уже вроде идёт... сейчас уже до нескольких гигабайт в секунду где-то есть.. надо знания как-то освежить, а то как-то сейчас под другие задачи себя направляю.

По производительности сервера надо уже как-то более практически думать.. если речь идёт про online сервис, то проще от клиентских мегабит считать.. если надо выплевывать 1 гигабит в инет, то стораджа на SCSI 320 вполне достаточно, а там уже в харды упирается.

PS. Многие кстати NFS недооценивают, а если уметь готовить, то получается быстрее, чем SATA... а с неособо дорогим железом быстрее IDE это точно. Не особо напрягаясь можно выжать 30-40mb/s per server на самом пессимистичном R/W тесте... т.е. там самый плохой расклад уже учитывается. На каких-то простейших фокусах получалось и по 80mb/s на сервер... но это всё там от размера файлов зависит и т.д... т.е. надо под каждый конкретный случай оптимизировать.