ищу прогу для равноправной репликации N to N серверов

Glusterfs — именно то, что тебе надо.

А там, где у тебя

в частности когда ноды удаленные

Юзай обычный rsync между двумя кластерами gluster.

AnDoR к сожелению gluster нетянет ... он как и говрую несколько излишен в этой ситуации - нужна максимальная скорость и минимальное время отклика на локальной ноде при доступе к файлу и запись в файл
а с глумтером - особо когда настроены как replication - и ноды удаленные
скорость ужастно низка

а посуществу ВСЕ нода являются удаленными для соседей

Юзай обычный rsync

rsync каждый раз будет миллионы файлов на обоих хостах проверять при каждой синхронизации. Нужно или что-то на inotify/whatever или кластерную фс.

Или вообще какой-нить hadoop и fuse-fhds(но это решение полный ацтой по надёжности(из-за naming node) и тормозам).

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

Мне почему-то кажется что ты хочешь замутить мега распределенный бэкап скажем какого нибудь корпоративного /home причем чтоб в каждом удаленном подразделении хранился хомяк и всех остальных подразделений)))) Опиши конкретно для чего это нужно - мне интересно)))

при удалении с одного - после репликации он должен удалиться и на других репликах

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

то что я хотел схему уже работала - несколько дней - на glusterfs
и делало именно то что я и хотел

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

а при бальшом колве мелких файлов - это чудны тормазы

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


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

inosync - notification-based directory synchronization daemon
http://bb.xnull.de/projects/inosync/


lsyncd - daemon to synchronize local directories using rsync
http://code.google.com/p/lsyncd/


Оба используют inotify

к сожелению оба они master-slave
а мнеб кластерную - N to N

эх
вроде хочу сделать достаточно простую и очевидну чтуку - а вот и неполучаеться

вроде хочу сделать достаточно простую и очевидну чтуку - а вот и неполучаеться

Неее - кластерыне штуки N:N это самые непростые и неочевидные штуки в общем виде :D Думаешь почему все эти кластерные fs и пр решения - чаще все клиентсерверные.

Не думаю что тебе подойдет, кстати, но вот есть например

http://mayrhofer.eu.org/dvcs-autosync

dvcs-autosync is a project to create an open source replacement for Dropbox/Wuala/Box.net/etc. based on distributed version control systems (DVCS). It offers nearly instantaneous mutual updates when a file is added or changed on one side...

нужна максимальная скорость и минимальное время отклика на локальной ноде при доступе к файлу и запись в файл

а с глумтером - особо когда настроены как replication - и ноды удаленные скорость ужастно низка

А ты как хотел? При операциях с файлами одна нода обязана же оповестить другие и синхронизироваться с ними. Иначе при конфликтах у тебя файлы в фарш превращаться будут.

дак вот то и дело - что полнофункциональная файловая система и ненужна
нужна репликация

И что? В любом случае нужна синхронизация. Иначе хренота выйдет.