В Win2000 легко настраивается репликация между двумя расшаренными ресурсами на двух серверах. При этом репликация получается двусторонней, любые изменения на одном ресурсе очень быстро отображаются на другом. Может использоваться как для цели создания online-бэкапа, так и для распределения нагрузки. По сути получается что-то вроде сетевого RAID 1.

Можно ли подобное организовать в Linux и если да, то какими средствами?
Где про это почитать?

nik_xhttp://rsync.samba.org/

Спасибо, но не совсем то. Если я правильно понял, rsync работает только в одну сторону. А DFS в Win во все стороны изменения отрабатывает. Хотя, для целей он-лайн бэкапа и это сойдет скорее всего.

правильный линуксоид> А DFS в Win во все стороны изменения отрабатывает

Я не знаю, что это за шняга, но телепатический модуль от этой фиговины куплю задорого.
Нет там никакого телепатического модуля. Элементарная двусторонняя репликация изменений. Никаких сложностей, если правятся разные файлы. А вот про тонкости отработки конфликтов при одновременной правке файла в разных местах не готов сейчас подробно рассказать.

правильный линуксоид> Нет там никакого телепатического модуля.

Как это нет? Даже системы контроля версий не умеют (точнее - не хотят (и правильно делают, кстати)) сливать изменения автоматом. А тут все в шоколаде. Значит, телепатический модуль у шняги по имени DFS должен быть обязательно.

Ты читать умеешь? Или лишь бы ляпнуть, не имея ни малейшего представления об обсуждаемом предмете? Не стоит задача сливать автоматом одновременные изменения одного и того же файла из разных мест. Да и бред это в большинстве случаев (например во всех случаях бинарных файлов). А в репликации изменений разных файлов нет никаких чудес. И для упомянутых систем контроля версий это штатное использование - изменение разными разработчиками одновременно разных файлов.
правильный линуксоид
Куплю. Дорого.
Ты повторяешься. Win 2003 server standard - около $700.
Dimitry Sibiryakov
правильный линуксоид
А тут все в шоколаде.

Какой, нафиг, телепатер? Тупо файл с новой датой переписывает старый.

Не совсем так. В частности дату файла можно и насильно другой выставить. Но смысл похожий. Правда в W2003 R2 заявлена более навороченная технология - новый алгоритм сжатия под названием Remote Differential Compression для передачи только изменений, для эффективной работы на тонких каналах.

В общем, навскидку достойных аналогов, как я понял, нет. Просто озаботился тут возможностью перевода части серверов под Linux. Но не все так сладко, как могло показаться.

nik_x
Я ссылку давал...
Внимательно читал, да?

Не досконально, но достаточно. И читал, и ответил, и поблагодарил.
nik_x
И о компресии, и о передачи только измененией в бинарных файлах и т.д. ...
Упорство в отстаивании продуктов M$ - ну просто поражает!

И про компрессию, и про передачу только изменений я прочитал. Здесь MS ничего нового не изобрели. Про rsync я слышал еще до того, как DFS в виндах появился. Но MS дальше продвинулись в этом вопросе: сделали именно многонаправленную репликацию. Можно распределять нагрузку, посадив половину народа на один сервер, другую - на другой. Можно организовать удобную работу с одним ресурсом из головного офиса и филиалов. Если я где-то при беглом просмотре упустил описание подобных возможностей rsync - ткни пальцем, пожалуйста. Пока что увидел только возможность однонаправленного слива изменений.

Упорства в отстаивании никакого нет. Наоборот - ищу наличие разумной альтернативы, на которую можно перейти с минимальными геморроями. Но если сервер БД, к примеру, съезжает с win элементарно, то вот с корпоративным файл-сервером все не так просто.

nik_x
Мы уже проходили то, что интернет M$ изобрели.
Типа история повторяется???
Не по адресу. Я сам бывший "линуксоид" почти :) По крайней мере несколько шлюзов (ipchains, squid, sendmail/qmail и т.д.) на линухе когда-то устанавливал, настраивал и поддерживал некоторое время

Dimitry Sibiryakov
Угу, ты это в виндовом форуме расскажи Подгорецкому. Заодно объясни ему
в чем же он облажался, настраивая эту самую DFS.
http://www.sql.ru/forum/actualthread.aspx?tid=404222

Это ответ по существу, про то, как организовать подобное в linux? Прям как дети малые. Я пришел сюда не доказывать, что круче, а спросить у более осведомленных коллег о возможных путях решения. Впрочем, меня это не удивило. Не в первый раз встречаю такие обиды в ответ на вопросы из разряда "а как бы в linux сделать подобное"?

Вот, нашел, кажется, что-то отдаленно похожее, но детально еще не вникал:
Distributed Replicated Block Device
Network block device

nik_x
При распределенной синхронизации файлов, когда каждый из узлов имеет одинаковый статус можно элементарно налететь на коллизии.

Можно. Только при чем тут равноправие и как оно относится к разнонаправленности репликации?
nik_x
И не преведи аллах, если это влетит в цикл...

Уж зацикливания то избежать более чем просто. Для этого достаточно лишь отличать изменения, совершенные непосредственно на хосте от изменений, пришедших по репликации. (Мне тут относительно легко проводить аналогии и строить догадки, не далекие от истины, т.к. реализую и поддерживаю репликацию баз данных в распределенных системах - принципы и проблемы во многом схожие. Нет смысла велосипеды изобретать.)
nik_x
Мне это чем-то напоминает двух базарных бабок. Будут биться до истощения сил.
"Равноправия" в распределенных системах стараются избегать даже при проектировании СУБД.
В крайнем случае запуская внешний монитор отслеживания изменений.

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

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

Может я недопонимаю, о каких приоритетах идет речь? Какие приоритеты нужны для отработки простейшей ситуации? Есть 3 сервера и одна реплицируемая на них папка. В папке 3 файла. На первом сервере правят первый файл, на втором - второй, на третьем - третий. В результате нужно на всех трех серверах получить актуальные все 3 файла. Ну обзовешь ты первый сервер главным. Что из этого? Чем это поможет решить задачу?
nik_x
Если дву-направлено, то стремятся разделить файлы по группам приоритетов "высокий"/"низкий"
Например ресурсы типа дирекории.
Соответственно будет работать параллельно 2 ведущих и 2 подчиненных.

Кажется, догадываюсь. Ты имеешь в виду скорее 2 отдельные ОДНОНАПРАВЛЕННЫЕ репликации двух разных ресурсов? Нет, это неприемлемо. А если 7 узлов? Или больше.

nik_x
Вообщем здесь задача больше грамотно спроектировать систему, а не уповать на супер-прогу с супер-телепатером, о чем и пытались дать понять...
Да нет же здесь никакой телепатии! Лежит у тебя в папке (таблице) куча файлов (записей). С момента последнего обмена что-то менялось. Что именно менялось, узнать легко. Отправляешь другому хосту изменения. Получаешь от другого хоста изменения и прикладываешь у себя. Проблемы возникают только тогда, когда правится одно и то же на разных хостах, но этот риск можно минимизировать как раз правильным проектированием структуры ресурса, а если уж случилось, тогда нужно отрабатывать согласно выбранной политике. Например не реплицировать такое, но писать лог. Реплицировать пришедшее позже. Реплицировать пришедшее с более главного сервера (вот тут можно и приоритеты использовать) и т.п. Но такие конфликты меньше всего интересуют, так как не должны быть регулярным явлением.