Comments 37
Как насчет code.google.com/p/lsyncd/?
Отслеживает изменения в папке и синхронизирует изменения. Единственно, нужно следить за тем, чтобы он не стал в другую сторону работать.
Отслеживает изменения в папке и синхронизирует изменения. Единственно, нужно следить за тем, чтобы он не стал в другую сторону работать.
0
<не туда ответил>
0
GlusterFS, GPFS и другие. Скорее всего первое вам подойдет
+4
1ое решение:
на application нодах csync2(у меня синхронизирует три ноды, на каждой ноде чуть более миллиона файлов);
перед application ставим nginx и настраиваем upstream, с перекидыванием на другую ноду если 404;
2ое решение:
на application ноды подключаем расшаренное блочное устройство, iscsi или другими способами;
на application нодах настраеивам OCFS2;
2ое решение работает сразу, только ocsf2 надо с опциями запускать, точно знаю хорошая опция индексация директорий.
на application нодах csync2(у меня синхронизирует три ноды, на каждой ноде чуть более миллиона файлов);
перед application ставим nginx и настраиваем upstream, с перекидыванием на другую ноду если 404;
2ое решение:
на application ноды подключаем расшаренное блочное устройство, iscsi или другими способами;
на application нодах настраеивам OCFS2;
2ое решение работает сразу, только ocsf2 надо с опциями запускать, точно знаю хорошая опция индексация директорий.
+2
У нас виртуальные сервера у хостера, так что физически что то подключать не можем, а вот csync2 выглядит интересно, посмотрю
0
если много файлов(миллион или более), то папки с большим кол-вом файлов разделяйте на отдельные базы, достигается это разделением csync2 групп на отдельные конфиги. Если не разделите это сулит вам большой базой sqlite3, её csync2 использует для хранения списка файлов.
0
UFO just landed and posted this here
BitTorrent Sync рассматривали?
+1
GlusterFS очень(!!!!) не советую, работали с ней в режиме репликации пару лет, постоянные падения, два раза даже потери по 10ТБ на одной из нод.
Сейчас используем MooseFS (общий объем сейчас 80ТБ, через пару недель нарастим до 180ТБ) — падения машин с дисками даже не замечается.
Легкая замена дисков и подцепление дополнительных машин. Авторепликация работает на ура. Одна проблема была — самому пришлось делать скрипт автопереключения метасервера на металоггера при падении.
Если использовать число копий(goals) равное числу машин у вас, то копия будет у всех и сразу. При чтении рассчитывается расстояние до ближайшей ноды, и в этом случае данные будут браться локально(скорость чтения в два раза больше, чем с других машин)
Сейчас используем MooseFS (общий объем сейчас 80ТБ, через пару недель нарастим до 180ТБ) — падения машин с дисками даже не замечается.
Легкая замена дисков и подцепление дополнительных машин. Авторепликация работает на ура. Одна проблема была — самому пришлось делать скрипт автопереключения метасервера на металоггера при падении.
Если использовать число копий(goals) равное числу машин у вас, то копия будет у всех и сразу. При чтении рассчитывается расстояние до ближайшей ноды, и в этом случае данные будут браться локально(скорость чтения в два раза больше, чем с других машин)
0
Спасибо, посмотрю
0
Спасибо за MooseFS.
Были те же грабли, использовали еще со 2ой версии = потом отказались.
Были те же грабли, использовали еще со 2ой версии = потом отказались.
0
Пару лет назад звучит как вечность. Новая верися GlusterFS рекомендуется RedHat www.redhat.com/summit/sessions/topics/glusterfs.html
0
Не пару лет назад, а пару лет работали, вот только месяц назад начали миграцию на музе. А с гластером спасибо, наелся, и с 2й веткой, и с последней 3.3.1
0
Странно, а можно поподробнее какие были именно проблемы?
ЗЫ. За MooseFS спасибо интреснная штука.
ЗЫ. За MooseFS спасибо интреснная штука.
0
С второй версией:
1) частые падения клиентской части
2) как я уже писал — потеря на одной из зеркальных нод 10ТБ за несколько минут, пришлось восстанавливать из второй копии — внутренняя репликация не работала. Тикет делал когда они еще гластером были без редхата, ничего не решилось. Такое было 2 раза за два года, стоило больших нервов.
3) Падения при высоких параллельных нагрузках. Так как повторить было очень легко, то включив дебаг режим, отсылал в баг-репорт всё что мог, вплоть до корки. Также письмами туда-сюда с разработчиками, результат тот же — не решено.
С третьей версией хватило постоянных падений клиентской части и недоступности части контента, то он есть, то он есть только в мечтах.
Что мне в музе не хватает по сравнению с гластером — это чтобы к файлам можно было обращаться напрямую. Там файлы бьются на чанки по 64мб и раскидываются по дискам одного сервера.
Правда у этого решения есть ОЧЕНЬ большое преимущество — не надо (а даже и очень вредно) под систему делать рейды, а значит больше места под файлы вместо чексумм. При падении диска, данные которые на нем должны быть в фоне копируются с копий, при этом не надо насиловать все(!) диски как в рейде5/6, а происходит копирование только реальных кусков.
Если параллельное чтение разных файлов, то скорость больше, за счет того что они просто на разных дисках.
На самом дуле у музе много плюсов, которые с лихвой перекрывают для меня незначительные недостатки:
1) Наличие только одного метасервера и ручное/самописное переключение на один из металоггеров металоггер(как слейв)
2) Для метасервера надо много памяти. В памятке они пишут про 300мб/1млн файлов, в реальности народ говорит надо 500мб, у меня столько примерно и выходит. Сейчас 8.5млн файлов, процесс занимает почти 4ГБ. Также надо иметь реальную+своп по формуле сколько ест памяти*2, потому как форкается процесс каждый час для бекапа метаданных. И хотя реально он не потребляет столько, но ОС начитает тормозить если меньше двойной памяти. Сам не сталкивался, но в рассылке есть упоминания. Плюс желательно хранить файлы структур на ссд диске.
Может быть напишу небольшую статью, уже поподробней, настолько мне она понравилась после тестирования, особенно поведение при сбоях дисков/серверов (клиенты этого вообще не замечают)
1) частые падения клиентской части
2) как я уже писал — потеря на одной из зеркальных нод 10ТБ за несколько минут, пришлось восстанавливать из второй копии — внутренняя репликация не работала. Тикет делал когда они еще гластером были без редхата, ничего не решилось. Такое было 2 раза за два года, стоило больших нервов.
3) Падения при высоких параллельных нагрузках. Так как повторить было очень легко, то включив дебаг режим, отсылал в баг-репорт всё что мог, вплоть до корки. Также письмами туда-сюда с разработчиками, результат тот же — не решено.
С третьей версией хватило постоянных падений клиентской части и недоступности части контента, то он есть, то он есть только в мечтах.
Что мне в музе не хватает по сравнению с гластером — это чтобы к файлам можно было обращаться напрямую. Там файлы бьются на чанки по 64мб и раскидываются по дискам одного сервера.
Правда у этого решения есть ОЧЕНЬ большое преимущество — не надо (а даже и очень вредно) под систему делать рейды, а значит больше места под файлы вместо чексумм. При падении диска, данные которые на нем должны быть в фоне копируются с копий, при этом не надо насиловать все(!) диски как в рейде5/6, а происходит копирование только реальных кусков.
Если параллельное чтение разных файлов, то скорость больше, за счет того что они просто на разных дисках.
На самом дуле у музе много плюсов, которые с лихвой перекрывают для меня незначительные недостатки:
1) Наличие только одного метасервера и ручное/самописное переключение на один из металоггеров металоггер(как слейв)
2) Для метасервера надо много памяти. В памятке они пишут про 300мб/1млн файлов, в реальности народ говорит надо 500мб, у меня столько примерно и выходит. Сейчас 8.5млн файлов, процесс занимает почти 4ГБ. Также надо иметь реальную+своп по формуле сколько ест памяти*2, потому как форкается процесс каждый час для бекапа метаданных. И хотя реально он не потребляет столько, но ОС начитает тормозить если меньше двойной памяти. Сам не сталкивался, но в рассылке есть упоминания. Плюс желательно хранить файлы структур на ссд диске.
Может быть напишу небольшую статью, уже поподробней, настолько мне она понравилась после тестирования, особенно поведение при сбоях дисков/серверов (клиенты этого вообще не замечают)
+1
Спаисбо за ответ.
Буду пристальней смотреть в сторону музи.
Скажите а сколько у вас сейчас клиентов которые реально пишут?
Буду пристальней смотреть в сторону музи.
Скажите а сколько у вас сейчас клиентов которые реально пишут?
0
У нас клиенты — это 6 серверов, чтение/запись примерно 70/30.
Есть один юзер, которые на трех серверах генерирует за пару дней миллион файлов, на несколько ТБ, а потом их скопом удаляет.
Все это работает шустро, особенно файловые операции, так как удаление происходит в памяти метасервера, а он уже потом в бекграунде потихоньку чанки удалет на контентных серверах.
Делал тест на запись на уже рабочем кластере — 30-50мб/с, при двойной копии, при этом еще соседние сервера писали туда рсинком контент с гластера.
Есть один юзер, которые на трех серверах генерирует за пару дней миллион файлов, на несколько ТБ, а потом их скопом удаляет.
Все это работает шустро, особенно файловые операции, так как удаление происходит в памяти метасервера, а он уже потом в бекграунде потихоньку чанки удалет на контентных серверах.
Делал тест на запись на уже рабочем кластере — 30-50мб/с, при двойной копии, при этом еще соседние сервера писали туда рсинком контент с гластера.
0
А сколько у вас чанк серверов и какая сеть между ними?
0
3 чанка, локальный гигабит. В основном все файлы по 3 копии, часть не особо важных по 2.
Общее место на серверах 156 TB, свободного места 36 TB, 14млн файлов +1млн сейчас кандидаты на удаление.
Мастер ест памяти 7.3 гига, скоростью довольны. Но тут зависит от применения — как весьма активное файлохранилище отлично, для образов виртуалок думаю не очень. Но тут я не особо спец.
За нескольок месяцев эксплуатации были как медленные так и мгновенные умирания дисков, падения чанк-серверов — все работало отлично. Вот мастер еще не падал, так, перестартовывали припереносе на другой сервер. При этом все файловые операции у клиентов фризились.
Общее место на серверах 156 TB, свободного места 36 TB, 14млн файлов +1млн сейчас кандидаты на удаление.
Мастер ест памяти 7.3 гига, скоростью довольны. Но тут зависит от применения — как весьма активное файлохранилище отлично, для образов виртуалок думаю не очень. Но тут я не особо спец.
За нескольок месяцев эксплуатации были как медленные так и мгновенные умирания дисков, падения чанк-серверов — все работало отлично. Вот мастер еще не падал, так, перестартовывали припереносе на другой сервер. При этом все файловые операции у клиентов фризились.
0
И с NFS можно сделать все достаточно надежно, но может быть поможет BitTorrent Sync, только это еще сырой продукт.
0
Если это ваш проект/продукт, то посмотрите в сторону mongodb gridfs. Отлинчое решение, хороше скейлится, отличная конистентность данных и высокаая доступность достигается простыми средствами.
0
starwind но дороговато. Решение простое под windows.
0
Sign up to leave a comment.
Синхронизация файлов между компьютерами в кластере