Имеем 2 географически разнесенных файлсервера, у каждого сервера 1.5Тб пространства под данные (RAID5)Время работы серверов заранее не спрогнозировать (но большую часть времени работают одновременно)
На серверах поднята самба. Юзеры одновременно работают с двумя серваками (читают,пишут,изменяют файлы). Требуется online репликация файлов по дате изменения (т.е. в случае конфликтов оставляем однозначно более поздний файл) При этом нет гарантии доступности двух серверов одновременно. Например, сегодня первым вырубили сервер №1, а на втором серваке юзеры еще час файлы ковыряли, а на завтра первым врубили сервак №1 со старой инфой и юзеры опять ковыряют файлы. Главное, чтобы после старта 2-го сервера репликация прошла в обе стороны так, чтобы остались более поздние файлы. Ну и соответственно, если юзер файлик изменил, то он должен тут же скопироваться на второй сервер.
Собстно нужна система, которая выполняла бы все вышеперечисленные функции
Может быть стоит использовать решения для терминального доступа к файлам?
>Может быть стоит использовать решения для терминального доступа к файлам?Подробнее? что ты имеешь ввиду?
>[оверквотинг удален]
>Требуется online репликация файлов по дате изменения (т.е. в случае конфликтов
>оставляем однозначно более поздний файл) При этом нет гарантии доступности двух
>серверов одновременно. Например, сегодня первым вырубили сервер №1, а на втором
>серваке юзеры еще час файлы ковыряли, а на завтра первым врубили
>сервак №1 со старой инфой и юзеры опять ковыряют файлы. Главное,
>чтобы после старта 2-го сервера репликация прошла в обе стороны так,
>чтобы остались более поздние файлы. Ну и соответственно, если юзер файлик
>изменил, то он должен тут же скопироваться на второй сервер.
>
>Собстно нужна система, которая выполняла бы все вышеперечисленные функцииА более подробно - что за файлы, в которых вы так готовы терять изменения ?
>[оверквотинг удален]
>>серваке юзеры еще час файлы ковыряли, а на завтра первым врубили
>>сервак №1 со старой инфой и юзеры опять ковыряют файлы. Главное,
>>чтобы после старта 2-го сервера репликация прошла в обе стороны так,
>>чтобы остались более поздние файлы. Ну и соответственно, если юзер файлик
>>изменил, то он должен тут же скопироваться на второй сервер.
>>
>>Собстно нужна система, которая выполняла бы все вышеперечисленные функции
>
>А более подробно - что за файлы, в которых вы так готовы
>терять изменения ?В основном документы, которые постоянно правят, перевыпускают и прочая, прочая... Конечно было бы неплохо держать и старые версии документов (на всякий пожарный, благо место позволяет), но это не обязательное условие.
Странно, вообще-то на серваках как раз по ночам (когда юзеры спят) вся основная работа и начинается ... :) раб.станции выключать можно а сервак выключать на ночь - однако :)
>Странно, вообще-то на серваках как раз по ночам (когда юзеры спят) вся
>основная работа и начинается ... :) раб.станции выключать можно а сервак
>выключать на ночь - однако :)Учитывая, что предприятие режимное и на ночь все обесточивается... Сервера круглосуточно не могут работать по определению. Так что последний уходящий тушит сервер.
Может конечно не совсем репликация.
Может посмотреть в сторону Subversion (SVN)
Заодно получите версионный контроль файлов.Если пользователи не со всеми документами одновременно работают то думаю не плохое решение при хороших каналах.
При плохом как вариант:
на обоих серваках Subversion(SVN) и система репликации между ними SVK
csync?
>csync?Пробовал. не понравилось тем, что отсутствует мониторинг изменения файлов, т.е. измененный файл не перекидывается тут же на другой сервер, а если csync дергать по cron'у постоянно, то при большом количестве файлов это будут тормоза
>по cron'у постоянно, то при большом количестве файлов это будут тормозаВ линуксах можно попытаться вывернуться гоняя хоть тот же rsync сугубо на основе мониторинга изменений ФС по inotify. В принципе - наверное работоспособно, хотя я сам так не делал - просто то что в голову пришло.
>>по cron'у постоянно, то при большом количестве файлов это будут тормоза
>
>В линуксах можно попытаться вывернуться гоняя хоть тот же rsync сугубо на
>основе мониторинга изменений ФС по inotify. В принципе - наверное работоспособно,
>хотя я сам так не делал - просто то что в
>голову пришло.Была такая мысль, но inotify мониторит только одну директорию не рекурсивно :(
inotify-tools решает эту проблему (обходит все дерево каталогов и создает inotify-watch на каждую дирректорию), но лишь частично: если создать новую директорию - она не мониторится :(
>>csync?
>
>Пробовал. не понравилось тем, что отсутствует мониторинг изменения файлов, т.е. измененный файл
>не перекидывается тут же на другой сервер, а если csync дергать
>по cron'у постоянно, то при большом количестве файлов это будут тормоза
>пробовал csync или csync2 http://oss.linbit.com/csync2/ ?
>>>csync?
>>
>>Пробовал. не понравилось тем, что отсутствует мониторинг изменения файлов, т.е. измененный файл
>>не перекидывается тут же на другой сервер, а если csync дергать
>>по cron'у постоянно, то при большом количестве файлов это будут тормоза
>>
>
>пробовал csync или csync2 http://oss.linbit.com/csync2/ ?csync2
>>>>csync?
>>>
>>>Пробовал. не понравилось тем, что отсутствует мониторинг изменения файлов, т.е. измененный файл
>>>не перекидывается тут же на другой сервер, а если csync дергать
>>>по cron'у постоянно, то при большом количестве файлов это будут тормоза
>>>
>>
>>пробовал csync или csync2 http://oss.linbit.com/csync2/ ?
>
>csync2сдаётся, мне что на какую-нить distributed fs надо смотреть.
http://www.opennet.me/opennews/art.shtml?num=19263
>http://www.opennet.me/opennews/art.shtml?num=19263Это все гуишные приложения... и хоть Unison и может работать в консоли, это все-таки End-user приложение, а никак не серверное, не требующее постоянного контроля со стороны администратора...
>>http://www.opennet.me/opennews/art.shtml?num=19263
>
>Это все гуишные приложения... и хоть Unison и может работать в консоли,
>это все-таки End-user приложение, а никак не серверное, не требующее постоянного
>контроля со стороны администратора...http://www.linuxawy.org/node/13
http://inotify-tools.sourceforge.net/
>>>http://www.opennet.me/opennews/art.shtml?num=19263
>>
>>Это все гуишные приложения... и хоть Unison и может работать в консоли,
>>это все-таки End-user приложение, а никак не серверное, не требующее постоянного
>>контроля со стороны администратора...
>
>http://www.linuxawy.org/node/13
>http://inotify-tools.sourceforge.net/Inotify-tools - хорошая штука, особенно после доработки напильником -))
Похоже проще будет свое написать -)
>Похоже проще будет свое написать -)как это, специфические требования
отпишитесь, может как и что получилось - интересно
>Требуется online репликация файлов по дате изменения (т.е. в случае конфликтов
>оставляем однозначно более поздний файл) При этом нет гарантии доступности двух
>серверов одновременно. Например, сегодня первым вырубили сервер №1, а на втором
>серваке юзеры еще час файлы ковыряли, а на завтра первым врубили
>сервак №1 со старой инфой и юзеры опять ковыряют файлы. Главное,
>чтобы после старта 2-го сервера репликация прошла в обе стороны так,
>чтобы остались более поздние файлы. Ну и соответственно, если юзер файлик
>изменил, то он должен тут же скопироваться на второй сервер.
>
>Собстно нужна система, которая выполняла бы все вышеперечисленные функцииоднострочник на перле рекурсивно обходящий каталоги?
>однострочник на перле рекурсивно обходящий каталоги?А дальше?Если юзер отредактировал 20Мб файл - пропихивать 20Мб?Как бы rsync в этом случае бойко покажет большую фигу однострочнику, да и рекурсивно проходить по каталогам он умеет :)
На самом деле я вижу тут только 1 стоящую внимания проблему: что делать если 1 и тот же файл с обоих сторон отредактируют до синхронизации.Это "коллизия редактирования" и однострочником на перле опять же не отделаетесь(а что он будет делать при этом?).
>>однострочник на перле рекурсивно обходящий каталоги?
>
>А дальше?Если юзер отредактировал 20Мб файл - пропихивать 20Мб?Как бы rsync в
>этом случае бойко покажет большую фигу однострочнику, да и рекурсивно проходить
>по каталогам он умеет :)
>
>На самом деле я вижу тут только 1 стоящую внимания проблему: что
>делать если 1 и тот же файл с обоих сторон отредактируют
>до синхронизации.Это "коллизия редактирования" и однострочником на перле опять же не
>отделаетесь(а что он будет делать при этом?).вообще это наверное следует решать административными способами - построить работу с файлами таким образом, чтобы изменения в документ вносились только локальными для этого сервера юзерами...
> так, чтобы остались более поздние файлы.А что делать если юзеры на одном сервере поколупали файл пока второй сервер не работал а потом 1-й сервер затушили, так что репликация не произошла зато на 2-м сервака юзеры поколупали тот же файл но с иными изменениями.Что делать при включении 1-го сервака?Чьи изменения прибить - юзеров сервака 1 или юзеров сервака 2?
А так можно нечто типа периодически пинаемого кроном раз в несколько минут rsync поюзать (быстрая синхронизация содержимого каталога с посылкой по сети только отличий) но что делать с "коллизиями редактирования" - лично я не знаю.Для совсем уж крутых и только в линуксе - можно попытаться к inotify прикрутить чтобы rsync дергался только по факту изменения файлов в каталоге.
P.S. это всего лишь идеи а не готовое решение и вообще оно может быть далеко не лучшим.
>> так, чтобы остались более поздние файлы.
>Чьи изменения прибить
>- юзеров сервака 1 или юзеров сервака 2?
>Можно одну версию файла (более старую по дате) переименовать, так, чтобы работа человека не пропала, но приоритет однозначно на стороне более позднего файла (по дате)
>А так можно нечто типа периодически пинаемого кроном раз в несколько минут
>rsync поюзать (быстрая синхронизация содержимого каталога с посылкой по сети только
>отличий) но что делать с "коллизиями редактирования" - лично я не
>знаю.Как быстро rsync пройдет по куче вложенных директорий с миллионом файлов?
>[оверквотинг удален]
>Требуется online репликация файлов по дате изменения (т.е. в случае конфликтов
>оставляем однозначно более поздний файл) При этом нет гарантии доступности двух
>серверов одновременно. Например, сегодня первым вырубили сервер №1, а на втором
>серваке юзеры еще час файлы ковыряли, а на завтра первым врубили
>сервак №1 со старой инфой и юзеры опять ковыряют файлы. Главное,
>чтобы после старта 2-го сервера репликация прошла в обе стороны так,
>чтобы остались более поздние файлы. Ну и соответственно, если юзер файлик
>изменил, то он должен тут же скопироваться на второй сервер.
>
>Собстно нужна система, которая выполняла бы все вышеперечисленные функцииМожет конечно не в тему, но все же. попробовать использовать пакет drbd вместе с heartbeat. Тем более как новая версия вообще поддерживает актив- актив. Тогда и вопрос резервирования и доступности решится сам собой. Только вот трафик, хотя раньше когда поднимал довольно быстро все реплицировалось.