Очередная эксплуатация коллективного разума

[redtigra]

Народ, помогите мне, пожалуйста, правильно поставить задачу, прежде чем я полезу с ней по спецкомьюнити.

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

В массиве очень много мелких файлов. Ежедневно при построении индекса отсматривается около 3,5 млн. файлов, при этом синхронизируется 5-6 тысяч.

Синхронизируем из Америки в Питер и обратно. С американской стороны данные представляют собой очень разветвленную структуру NIS-карт и линков на десятки NFS-серверов в сети.

В Питере на машине запускается rsync-демон, который и осуществляет синхронизацию.

Проблема в следующем.
При построении индекса он шерстит те самые 3,5 млн файлов, которые расположены в Штатах, каждый раз лезя к каждому из этих файлов. В итоге времени на построение индекса уходит туева хуча времени. Дефакто - около 70% времени всего процесса синхронизации в целом.

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

Если бы можно было составлять индекс локально в Америке, а потом передавать питерскому демону - это облегчило бы ситуацию в разы. Актуальность "раз в сутки" достаточна. Как научить так работать rsync - непонятно, кажется, без хака этого вообще не сделать.

Какие есть варианты решения? Может быть, я не вижу чего-то очевидного?

Насколько понятно задан вопрос?

Куда, кроме ru_root, имеет смысл этот вопрос задавать?

Спасибо заранее.

Comments

[yan.livejournal.com]

А если на той стороне запускать демона, это не лучше? рута для этого не нужно, и памяти тоже как будто идет не очень много.
Хотя вроде бы какая разница.

[redtigra.livejournal.com]

а какая разница, правда, я пока не поняла? Так он лазает из Питера в Штаты для сравнения, а так будет из Штатов в Питер. ЧТо совой об пень, что пнем об сову. Или я что-то не вижу?

[yan.livejournal.com]

Я не знаю, как он написан, но вот я несколько раз в день копирую rsync'ом жалкие 35 тысяч файлов оттуда сюда и между разными машинами тут, и от направления очень сильно зависит. Пусть лучше нам скажет знаток, впрочем, потому что я как нащупал быструю схему, так и бросил этим интересоваться.

[redtigra.livejournal.com]

я подумаю... можно даже попробовать, в принципе.

Концептуальное. ;-)

[fdv.livejournal.com]

Думать тут не надо. Надо пробовать, и если заработает быстрее - использовать. А думать можно потом!

(убегает обратно в норку) ;-)))

[blacklion.livejournal.com]

cvsup крайне эффективно решает такие задачи. Но
(1) Настраивается нетривиально
(2) Написан на Modula-3

[blacklion.livejournal.com]

(3) Демон строго на источнике. Т.е. не синхронизация, а передача апдейтов в ОДНУ сторону.

Может банальный ls -lR + diff + скрипт?

[redtigra.livejournal.com]

No chance сделать это на источнике. Какой источник для сотен nfs-вхождений.

Скрипт, который будет делать - что? Rsync пофайлово? И что даст diff? rsync, мне кажется, делает ровно то же, но эффективней. Нет? Я ошибаюсь?

[blacklion.livejournal.com]

No chance сделать это на источнике. Какой источник для сотен nfs-вхождений.
Ну, монтируем всё на ОДНУ машину в единое дерево, и там вешаем источник. Ему что с локальной FS что с NFS раздавать...

Ну да, всё сводится к ls -lR внутри ли rsync'а, снаружи ли (в виде ls'а настоящего). Если это bottle neck, то мне кажется, единственный путь -- параллелить получение списка файлов и пересылку изменённого, т.е. сравнили 100 штук, начали переслыать, а тем временем собираем информацию о следующих 100 штуках, и так далее (на деле -- мультитред). Именно так и написан cvsupd/cvsup -- там всё параллельно происходит и когда он читает последние куски дерева файлы из начала дерева изменённые давно переданы уже...

[zloy-homyak.livejournal.com]

если скажу глупость, можешь игнорировать. :-)
однако вопрос - а не можешь ли ты этот rsync заставить работать в Штатах, да еще и поставить перед ним какой-нибудь примитивный селектор по дате последнего изменения? Т.е. скармливать ему уже готовый список файлов, которые со вчерашней синхронизации точно поменялись. а?

[redtigra.livejournal.com]

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

В Штатах я могу заставить работать демон, то есть сервис. И я попробую это сделать. Но rsync проводит сравнение файлов 1:1, то есть как сейчас он за каждым сравнением бегает в Штаты из Питера, так будет наоборот. Правда, в Питере синхронизированное менее дисперсно по сетевой структуре. Возможно, это даст выигрыш.

[zloy-homyak.livejournal.com]

я чувствую себя немножко неудобно, давая тебе советы, в то время как мой источник вдохновения - статья в Википедии ;-)
если я правильно понимаю эту фразу из описания алгоритма - "The recipient splits its copy of the file into fixed-size non-overlapping chunks, say of size S, and computes two checksums for each chunk: the MD4 hash, and a weaker 'rolling checksum'. It sends these checksums to the sender." - то он не сравнивает файлы 1 к 1, а посылает хэш для каждого файла.
Что мне непонятно - почему recipient? В моем понимании управлять процессом должен сервер. Т.е. в твоем случае - заокеанская сторона. Или у тебя двунаправленная актуализация - вам из штатов и в штаты - от вас?
Насчет модиф.тайм - глупая возможно идея - предположим актуализация происходит раз в сутки в 1 ночи. Вначале стартует скрипт, которые создает например симв. линки к файлам, у которых мод.дата > вчера в 1 ночи. Эти сим.линки помещаются все в одну директорию, а rsync уже во втором шаге синхронизирует только эту директорию. А?

[redtigra.livejournal.com]

В этом и проблема, что нельзя rsyncху подсунуть промежуточную директорию. Не умеет он. Или мы не умеем.

[zloy-homyak.livejournal.com]

т.е. он из сим.линков не сможет потом с другой стороны восстановить правильно пути? тады ой конечно.

[redtigra.livejournal.com]

Нет, он просто не умеет работать со списком файлов.

[zloy-homyak.livejournal.com]

так я ж не список ему предлагаю скармливать, а какую-то вполне конкретную директорию. А вот ее ты будешь наполнять линками на те файлы, кот. изменились со вчера. Главное, чтобы rsync смог по линку пройти и взять собственно файл.

[redtigra.livejournal.com]

*стукаясь лбом о стену* Эдька! Я не умею писать или ты читать? Так как он написан - он работает file-to-file, ну набери man rsync, и сели ты найдешь там способ заставить rsync ходить по линку и брать собственно файл - я тебе должна ужин.

Можно в принципе попробовать похачить сишные исходники, мы вроде нашли функции, Которые можно было бы подправить. Но не хочется.

[zloy-homyak.livejournal.com]

один из нас точно ;-))
я именно и пытался у тебя выяснить, а умеет ли этот кудесник брать файлы по линкам. значит нет. :-(
похачить сишные исходники - это уже немножко навороты. я бы это уж на самый крайний случай оставил.

[redtigra.livejournal.com]

То есть ты РОВНО описал то, что мы бы хотели получить. Но не знаем как.

[redtigra.livejournal.com]

Слушай, я как всегда, блин, с офтопиком... Ты не посмотришь мне в осле Brideshead Revisited - аудиокнижку? Ну вдруг есть? Вероятность почти нулевая, но все-таки. Если есть - я местных ребят попрошу мне вытащить, чтоб тебя не дергать. Мне-то ни осла, ни торрента без реального IP не поставить, как я понимаю. :(

[zloy-homyak.livejournal.com]

[BBC广播剧--故园风雨后].Bbc.Drama.-.Evelyn.Waugh.-.Brideshead.Revisited.(Complete)-Mp3.zip

оно? пока всего 7 источников, это может продлиться.

насчет торрента точно не скажу, осел может работать без айпи. Там есть какая-то разница между HighID и LowID. Когда у меня на рутере не был прописан порт-форвардинг, то мой осел получал от серверов только лоу-айди, при этом качалось, но медленнее.
если хочешь попробовать - 2.5 метра инасталлятора могу тебе в гмейл кинуть.

[redtigra.livejournal.com]

Оно!!! Большое?

Присылай. С июня перейду на анлим, можно будет и ослика воткнуть... надеюсь :)

[zloy-homyak.livejournal.com]

счас пошлю, попробуй конечно. у меня терпения хватает. в конце концов, быстрее-медленнее - какая разница? ;-)

насчет Во - поправка. вчера пока писал коммент, нашлась в торре. не знаю или та же самая, просто с другим битрейтом сжатая, или другая.
сегодня к утру приползла. 276 метров. фтп бы вам девушка где-нить завести :-))
может rapidshare опробуем? я им никогда не пользовался, но говорят, что там можно вполне чего-нить большого выложить.

[redtigra.livejournal.com]

Рапидшарой можно запросто. Я пользовалась, только я клала, а не мне, и клала я тута полтора гига по кусочкам. Там ограничение на размер файл. но какое-то очень человеческое. Положишь?
*Горестно* Нету у меня ftp. У меня тут ничего нету, я сижу в огромной сети, от всех спрятанная. Вот доломаю провайдера не реальный IP - подыму дома.
Эдька, огромное тебе спасибо. Я эту книжку люблю не сказать как.

[zloy-homyak.livejournal.com]

я тебе в гмейл сбросил первые 2 линка на рапидшару (это не тома, каждый архив - отд. директория, т.е. диск).
всего 10 дисков, скажи как скачаешь, я еще парочку упакую и вылью туда. :-)

[redtigra.livejournal.com]

Ага, спасибо, Завтра с работы утащу. Блин, хочу нормального провайдера с нормальным IP... Спасибище!

[redtigra.livejournal.com]

Кстати, мне осел не пришел. Может, он экзешники не пускет?

[zloy-homyak.livejournal.com]

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

[fdv.livejournal.com]

Угу, угу...

Я понял, что мне не только твоё рычание нравится: в своём собственном журнале, где ты полная сама себе хозяйка, создать офтопик - это 5+. Хорошо, что модератор "+" не поставил! ;-)))

Буду читать дальше! ;-)

[ignik.livejournal.com]

Нафига он к файлам то лезет если достаточно modification time сравнить.

       -I, --ignore-times
              Normally  rsync  will  skip  any files that are already the same
              size and have the same  modification  time-stamp.   This  option
              turns  off  this "quick check" behavior, causing all files to be
              updated.

В конце концов, если и директории медленно качаются, а время тикает правильно, можно не думая на той стороне рожать ручками какой-нибудь find -daystart список и далее tgz scp.

[redtigra.livejournal.com]

Нафига он к файлам то лезет если достаточно modification time сравнить.

Простите, туплю. Каким образом можно сравнить modification time без обращения к файлам-папкам, для которых мы запрашиваем время?

Запускать find на той стороне - приведет к большой ресурсной нагрузке, этого я сделать не могу, машины все билдовые.

Однако rsync на той стороне мы попробуем запустить. Может, оно получится побыстрее. Еще один вариант - попробуем разработать мультитредную схему, написать соответствующий скриптик с использованием того же rsync. Спасибо.

[bigturtle.livejournal.com]

Странно как-то. rsync работает так:
http://en.wikipedia.org/wiki/Rsync

[redtigra.livejournal.com]

Спасибо.
Странно - что?

[bigturtle.livejournal.com]

Я просто первый раз прочел невнимательно. Если rsync запускать через NFS, это действительно убивает идею оптимизации протокола, которая в нем главная.
Еще, кстати, есть такое средство, как unison (open source). Он делает синхронизацию в обе стороны и находит конфликты (типа с момента синхронизации файл был изменен на обоих концах).
Еще интересная утилита - monotone - это распределенный CVS (можно базы синхронизировать).

[redtigra.livejournal.com]

NFS как раз и есть точка преткновения. Я поищу unison, спасибо, посмотрю, что за зверь. Синхронизация баз нас, к сожалению, не утешит, наверное - нам нужно сохранить NIS-структуру, чтобы работали билд-скрипты, то есть именно директории и файлы нужно тащить. Будем думать, спасибо большое.

[bigturtle.livejournal.com]

Под "базами" я имел в виду CVS repositories (хочется все-таки разговаривать условно-по-русски ;-). Скорее всего unison/rsync - самое простое решение.

С CVS идея была в том, что при наличии в Питере полной repository, последняя версия вытаскивается checkout-ом или merge-м (в терминах стандартной CVS).
Недостатки подхода:
1) Добавляется лишний шаг по извлечению версии.
Достоинства:
1) Достать можно любую версию, а не только последнюю.
2) CVS все равно в конторе есть. При обнволении repository как раз и определяется что именно изменилось - вся информация уже готова и сидит в одном месте.

Я естественно понимаю, что никто не будет менять работающую схему во большой организации. Поэтому могу предложить половинчатое решение - cvsup+cvs (если вы уже используете cvs). Половинчатое оно потому, что cvsup синхронизирует только в одну сторону.

[redtigra.livejournal.com]

Да я поняла, что репозитории.

В качестве вершн-контроля в этом конкретно проекте исп-ся teamware покойная, кстати :) Спасибо за участие всяко. Будем, видимо, обычный мультитред писать все-таки.

[bigturtle.livejournal.com]

Пардон тогда большой за занудство: а чем плох простейший вариант когда rsync живет в Palo Alto а rsyncd в Питере и каждый из них читает файлы по локалке, а между собой они говорят по-минимуму (о чем и протокол)?

[ignik.livejournal.com]

Всё же читать каталог и читать иноду это несколько разные вещи. Понятно что каталоги прочитать придётся. А вот к inodes лезть необязательно. Посмотри таки strace что реально читает и где тормозит, может таки какие sync/async настройки nfs крутить надо. Реально синхронизация rsync при правильной настройке nfs быстрая.

Есть ещё одна штука: mirrordir (ftp://sunsite.unc.edu/pub/Linux/system/backup/mirrordir-0.10.41.tar.gz) мощи необыкновенной. Нонче так не пишут, это настоящий одесский джаз. Автор перестал её трогать после того, как заработал ssl. Чудная софтинка. :-)

[redtigra.livejournal.com]

Пошла смотреть. Спасибо!