Pull to refresh

Comments 37

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

UFO just landed and posted this here
Я не хочу single point of failure. Откуда гит будет тянуть апдейты? С какого то сервера, так? А если сервер умер?
UFO just landed and posted this here
Не рассматривал. Сейчас гляну. Спасибо
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 гига, скоростью довольны. Но тут зависит от применения — как весьма активное файлохранилище отлично, для образов виртуалок думаю не очень. Но тут я не особо спец.
За нескольок месяцев эксплуатации были как медленные так и мгновенные умирания дисков, падения чанк-серверов — все работало отлично. Вот мастер еще не падал, так, перестартовывали припереносе на другой сервер. При этом все файловые операции у клиентов фризились.
И с NFS можно сделать все достаточно надежно, но может быть поможет BitTorrent Sync, только это еще сырой продукт.
Нельзя. Сгорел сервер потеряли сторадж. Поставили два стораджа получили либо инконсистенси во времени либо сложную схему с залипанием при переключении.
Если это ваш проект/продукт, то посмотрите в сторону mongodb gridfs. Отлинчое решение, хороше скейлится, отличная конистентность данных и высокаая доступность достигается простыми средствами.
starwind но дороговато. Решение простое под windows.
Sign up to leave a comment.

Articles