Создание кластера (теория)

Сам сейчас занимаюсь этим вопросом, только у меня проще, сервера кластера будут в одном дата-центре, да и подключенные к своему же свитчу. Пока планируется две ноды (вместо одного сервака с RAID-10, который уже не справляется).

Сразу заюзал GlusterFS, т.к. судя по всему - подходит мне идеально. Сегодня весь день гонял на пропадание связи, вырубание одной из нод и т.д. Короче изголялся как мог.

Конфигурацию взял такую:

Режим - Distributed Replicatred, на каждом сервере - своя копия данных. Каждый сервер монтирует ФС у самого себя. Не знаю, правда, насколько это правильно, инфы на эту тему как-то маловато. Но штука оказалась живучая.

У меня выходило так: при пропадании одной из нод вторая минуту висела, потом раздуплялась, и работала как ни в чём не бывало. Файлики читались и писались. После старта пропавшей ноды она сразу видела все изменения на примонтированной ФС, но на своём локальном хранилище изменений не было. Чтобы они появились - надо на любой из нод запускать glusterfs volume rebalance nodeName start - и оно в фоне прогонит все изменения и синхронизирует ФС.

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

Кстати насчёт территориального распределения - вроде Gluster что-то такое умеет, но пока не копал, т.к. пока не надо. Думаю потом заюзаю для резервных копий.

Что ещё порадовало, так это то, что при наращивании количества нодов Gluster страйпит данные между ними. Правда количество нод должно быть кратно количеству зеркал, т.е. на зеркало-2 можно ставить 2,4,6 и т.д. серверов. 3,5,7 - никак не поставишь. Но зато - она сама занимается распределением файлов между серверами.

И ещё плюс - не требуется никакой «мастер-ноды». Управлять можно с ЛЮБОЙ ноды, а метаданные оно хранит где-то в самих файлах.

репликация стореджа должна проводится сторедж аррейем и точка. все эти дрдб, глистер и прочее - падучее медленное говно. при таком расстояниии между серверами делей будет огромен, все будет сходить с ума.

геоип балансировка это правильно, надо только учесть что твой днс сервер дожен также проводить мониторинг доступности ресурса.

репликация мускуля - ты про NDB чтоле? прийдется менять приложение и драйвер JDBC. а еще она очень ненадежно работает при большой write/update нагрузке, да еще и через латентный канал.. короче, ждет тебя много секса и разочарований. можешь попробовать постгрес с pgpool и wal репликацией, если твое приложение на нем заработает.

ну и, конечно, два сервера для чего-либо хоть сколько-то важного и нагруженного - катастрофически мало. я бы сделал по два в каждой локации, и вторую локацию как ДР к первой, переключатся на нее только при падении. при необходимости добавлять ноды.

а еще я тут подумал.

ты запускаешь, вебсервер, аппсервер и базу на одном хосте? что за приложение, что создает большинство нагрузки? может, лучше просто разнести компоненты на разное железо в пределах одного ДЦ?

Имхо если хочется хоть сколько нибудь надежное решение нужно пилить аппсервер так чтобы он корректно работал с несколькими серверами. Все эти drbd и мультимастер мускуля которые как кажется позволяют отделаться малой кровью(не перепиливать движек сайта) в итоге выливаются в огромный геморрой на нагрузке. val-amart совершенно разумное решение предлагает.

В принципе - правильно. У меня планируется отношение read/write где-то в районе 95/5. БД (Слон) на отдельном сервере.

Идеальным вариантом был бы, конечно, SAN, но мне тупо не дают на него денег. Да, вот так вот. Хотят из говна слепить конфетку, хотя я и предупреждаю. БД, конечно, ещё далёк до потолка, основное «бутылочное горлышко» сейчас - это имеено app-сервер, которому тупо не хватает мощностей процессора и памяти. Т.е. мощности на PHP и Memcached. Потому и решено его кластеризировать.

Тут бездумно делать ничего нельзя. БД на распределенную ФС класса того же гластера вешать ОЧЕНЬ стрёмно. Там если дурные нагрузки - то либо SAN, причём - хороший, либо - распределение на уровне логики.

gluster очень прилично работает если его монтировать как nfs, а не как glusterfs через fuse.

По хорошему так кластера не собирают)
А почему бы не обычный rsync в кроне , все равно решение звезд с неба не хватает.
А по хорошему берешь SAN, VCS и массивчик. Кстати, циско ACE довольно вкусное решение по лоадбалансу вебфигни.

По хорошему так кластера не собирают)

А как собирают?

А почему бы не обычный rsync в кроне , все равно решение звезд с неба не хватает.

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

А по хорошему берешь SAN, VCS и массивчик. Кстати, циско ACE довольно вкусное решение по лоадбалансу вебфигни.

Согласен, я бы так и делал, вот только стоит оно столько, что мне бабла не дадут столько.

Так а чем таки Gluster плох для этой задачи?

А как собирают?

По твоим требованиям единая база общие фс. Только выделенный канал под репликацию. И два массива в двух дц. Или если объемы маленькие то третий nfs-сервачек, если нужна еще отказоустойчивоть то и четверый. А репликация через zfs, VVR просто dd наконец, смотря какие требования к потери данных в случаи аварии.

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

Кеш пусть локальный. А банерку почему бы не сделать отдельной? С картинками проблема да.

Так а чем таки Gluster плох для этой задачи?

Тем что я это не видел рабочим, но я работаю с Ъ так, что для мелочи может и норм. Только спецов по нему не найдешь.

По твоим требованиям единая база общие фс. Только выделенный канал под репликацию. И два массива в двух дц.

Не совсем понял... БД у меня вообще на отдельном серваке (слабо загруженном, благодаря активному юзанию memcached).

Или если объемы маленькие то третий nfs-сервачек, если нужна еще отказоустойчивоть то и четверый.

А чем таки nfs лучше GlusterFS? И отказоучтойчивость на нём делать - ещё отдельные два сервака только под nfs ставить, да ещё и с rsyncом (который ну совсем не синхронную репликацию даёт)? Лишний гемор получается.

Кеш пусть локальный. А банерку почему бы не сделать отдельной? С картинками проблема да.

Ещё один сервер под банерку? А отказоустойчивость?

Да и вообще - не купят мне СТОЛЬКО серверов (см. про скупость начальства). И с картинками таки проблема, да.

Тем что я это не видел рабочим, но я работаю с Ъ так, что для мелочи может и норм. Только спецов по нему не найдешь.

Ну, у меня на devel работает отлично. На продакшн с высокой нагрузкой пока не тестил. Какие спецы? Он настраивается до рабочего состояния за 10 минут! Документация на оффсайте четкая и понятная. И как по мне - лучше чем NFS уж всяко.

Поскольку сервера находятся в разных ДЦ, думаю не рисковать юзая DRBD или Gluster. Попробую что-то нашаманить при помощи rsync в связке с app-server. При сохранении фоток или других статических ресурсов, будет запускаться процесс rsync на той ноде, на которой идет запись файлов. И rsync-ать с такими параметрами, чтоб он только добавлял недостающее на удаленный хост.

Забыл сказать. Всем большое спасибо за содержательные ответы!