Comments 37
Как насчет code.google.com/p/lsyncd/?
Отслеживает изменения в папке и синхронизирует изменения. Единственно, нужно следить за тем, чтобы он не стал в другую сторону работать.
Со всякими rsync и им поробным проблема, что они хороши если есть всего два компьтера, а если много и все нужно синхронизировать со всеми это сложнее. или я не прав?
Да, простите я не увидел требование «синхронизация с любой точкой»
А обезопасить NFS рэйдом или кластером не хотите?..
Ну не знаю, хочется чегото попроще — у нас виртуальные сервера у хостера
Спасибо, посмотрю. А они по SSH работают? У нас элементы кластера — VPSы, которые общаются через SSH
1ое решение:
на application нодах csync2(у меня синхронизирует три ноды, на каждой ноде чуть более миллиона файлов);
перед application ставим nginx и настраиваем upstream, с перекидыванием на другую ноду если 404;
2ое решение:
на application ноды подключаем расшаренное блочное устройство, iscsi или другими способами;
на application нодах настраеивам OCFS2;
2ое решение работает сразу, только ocsf2 надо с опциями запускать, точно знаю хорошая опция индексация директорий.
У нас виртуальные сервера у хостера, так что физически что то подключать не можем, а вот csync2 выглядит интересно, посмотрю
если много файлов(миллион или более), то папки с большим кол-вом файлов разделяйте на отдельные базы, достигается это разделением csync2 групп на отдельные конфиги. Если не разделите это сулит вам большой базой sqlite3, её csync2 использует для хранения списка файлов.
Как я уже писал, мне надо синхрнизировать не две, а несколько машин. Как это делать через rsync? Все со всеми?
в любом случае операция синхронизирования запустится по кол-ву машин на которые нужно переписать, не важно через какую ютилиту, как вариант rsync -avzu на все машины, ну или замаунтить нужную папку на всех машинах…
не претендую на звание эксперта в области, это первое что пришло в голову.
Ну так замаунить — это NFS, так? А если накрылся именно компьютер с этой папкой?

не обязательно NFS, это один из многих вариантов шаринга (правда прийдется клиента на все машины устанавливать).
еще как вариант — использовать git для синхронизации, я когдато эксперементировал — вполне неплохо работает как backup tool.
Я не хочу single point of failure. Откуда гит будет тянуть апдейты? С какого то сервера, так? А если сервер умер?
а если ядерная война? от всего не защитишся. чтоб сервер пережил смерть настройте raid-ы, еже**** бэкапы итп.
GlusterFS очень(!!!!) не советую, работали с ней в режиме репликации пару лет, постоянные падения, два раза даже потери по 10ТБ на одной из нод.

Сейчас используем MooseFS (общий объем сейчас 80ТБ, через пару недель нарастим до 180ТБ) — падения машин с дисками даже не замечается.
Легкая замена дисков и подцепление дополнительных машин. Авторепликация работает на ура. Одна проблема была — самому пришлось делать скрипт автопереключения метасервера на металоггера при падении.

Если использовать число копий(goals) равное числу машин у вас, то копия будет у всех и сразу. При чтении рассчитывается расстояние до ближайшей ноды, и в этом случае данные будут браться локально(скорость чтения в два раза больше, чем с других машин)
Забыл добавить, что после мытарств с гластером, искал по всему интернету с упором именно на надежность
Спасибо за MooseFS.
Были те же грабли, использовали еще со 2ой версии = потом отказались.
Не пару лет назад, а пару лет работали, вот только месяц назад начали миграцию на музе. А с гластером спасибо, наелся, и с 2й веткой, и с последней 3.3.1
Странно, а можно поподробнее какие были именно проблемы?
ЗЫ. За MooseFS спасибо интреснная штука.
С второй версией:
1) частые падения клиентской части
2) как я уже писал — потеря на одной из зеркальных нод 10ТБ за несколько минут, пришлось восстанавливать из второй копии — внутренняя репликация не работала. Тикет делал когда они еще гластером были без редхата, ничего не решилось. Такое было 2 раза за два года, стоило больших нервов.
3) Падения при высоких параллельных нагрузках. Так как повторить было очень легко, то включив дебаг режим, отсылал в баг-репорт всё что мог, вплоть до корки. Также письмами туда-сюда с разработчиками, результат тот же — не решено.
С третьей версией хватило постоянных падений клиентской части и недоступности части контента, то он есть, то он есть только в мечтах.

Что мне в музе не хватает по сравнению с гластером — это чтобы к файлам можно было обращаться напрямую. Там файлы бьются на чанки по 64мб и раскидываются по дискам одного сервера.
Правда у этого решения есть ОЧЕНЬ большое преимущество — не надо (а даже и очень вредно) под систему делать рейды, а значит больше места под файлы вместо чексумм. При падении диска, данные которые на нем должны быть в фоне копируются с копий, при этом не надо насиловать все(!) диски как в рейде5/6, а происходит копирование только реальных кусков.

Если параллельное чтение разных файлов, то скорость больше, за счет того что они просто на разных дисках.

На самом дуле у музе много плюсов, которые с лихвой перекрывают для меня незначительные недостатки:
1) Наличие только одного метасервера и ручное/самописное переключение на один из металоггеров металоггер(как слейв)
2) Для метасервера надо много памяти. В памятке они пишут про 300мб/1млн файлов, в реальности народ говорит надо 500мб, у меня столько примерно и выходит. Сейчас 8.5млн файлов, процесс занимает почти 4ГБ. Также надо иметь реальную+своп по формуле сколько ест памяти*2, потому как форкается процесс каждый час для бекапа метаданных. И хотя реально он не потребляет столько, но ОС начитает тормозить если меньше двойной памяти. Сам не сталкивался, но в рассылке есть упоминания. Плюс желательно хранить файлы структур на ссд диске.

Может быть напишу небольшую статью, уже поподробней, настолько мне она понравилась после тестирования, особенно поведение при сбоях дисков/серверов (клиенты этого вообще не замечают)
Спаисбо за ответ.
Буду пристальней смотреть в сторону музи.
Скажите а сколько у вас сейчас клиентов которые реально пишут?
У нас клиенты — это 6 серверов, чтение/запись примерно 70/30.
Есть один юзер, которые на трех серверах генерирует за пару дней миллион файлов, на несколько ТБ, а потом их скопом удаляет.
Все это работает шустро, особенно файловые операции, так как удаление происходит в памяти метасервера, а он уже потом в бекграунде потихоньку чанки удалет на контентных серверах.
Делал тест на запись на уже рабочем кластере — 30-50мб/с, при двойной копии, при этом еще соседние сервера писали туда рсинком контент с гластера.
3 чанка, локальный гигабит. В основном все файлы по 3 копии, часть не особо важных по 2.
Общее место на серверах 156 TB, свободного места 36 TB, 14млн файлов +1млн сейчас кандидаты на удаление.
Мастер ест памяти 7.3 гига, скоростью довольны. Но тут зависит от применения — как весьма активное файлохранилище отлично, для образов виртуалок думаю не очень. Но тут я не особо спец.
За нескольок месяцев эксплуатации были как медленные так и мгновенные умирания дисков, падения чанк-серверов — все работало отлично. Вот мастер еще не падал, так, перестартовывали припереносе на другой сервер. При этом все файловые операции у клиентов фризились.
Нельзя. Сгорел сервер потеряли сторадж. Поставили два стораджа получили либо инконсистенси во времени либо сложную схему с залипанием при переключении.
Если это ваш проект/продукт, то посмотрите в сторону mongodb gridfs. Отлинчое решение, хороше скейлится, отличная конистентность данных и высокаая доступность достигается простыми средствами.
Only those users with full accounts are able to leave comments. Log in, please.