Есть два сервера в двух разных офисах на которых поднята файлопомойка samba. Стоит задача сделать их общими для двух офисов и что бы в случае потери связи файлы оставались доступными которые были до обрыва а при соединение обновлялись (как бы зеркала). Вот как это лучше всего реализовать?
Я пока думаю что объединять их буду с помощью openvpn(шифрование можно реализовать) а обмен данными с помощью glusterfs. Как вы думаете жизнеспособная идея или есть что получше?
Файло помойка для двух офисов? Как реализовать?
вполне жизнеспособная идея
Я пока думаю что объединять их буду с помощью openvpn(шифрование можно реализовать) а обмен данными с помощью glusterfs. Как вы думаете жизнеспособная идея или есть что получше?
При использовании glusterfs надо понимать, что это есть не прослойка между дисковым блочным девайсом и файловой состемой (например, drbd), а надстройка над файловой системой. Причем, надстройка не выполняющая некоторых обязательных фич файловой системы (по крайней мере - до версии 3.2.5 включительно). Например, там не поддерживается mandatory lock. И что имеем в результате:
1. Проблемы с множественным доступом к одному файлу (например, 1С в dbf-варианте просто завалится с разрушенными индексами...).
2. Проблемы с запуском офисных приложений, которые хотят принудительно залочить в монопольное использование открываемый на сети файл. Например, MS Office последних версий просто виснет (очень длинный таймаут с последующим сообщением об ошибке открытия) при открытии таких файлов. У меня Office XP еще работает, а Office 2007 - уже опаньки.
Возможно опаньки были по другой причине, но были они исключительно на том самбовом томе, который раздавался с томов glusterfs. Стоило эту раздачу перенести на обычный том (то есть убрать прослойку glusterfs между самбой и файловой системой) как всё начинало работать правильно и шустро.
Кроме этого - онлайновая репликация файлов (самая вкусность в glusterfs) по сети Internet есть мазохизм. Надо иметь очень толстый канал для этого. А geo-репликация от glusterfs, по сути своей есть вариация на тему rsync в схеме maser-slave сервера. То есть по любому данные потекут только от master к slave. Но никак не наоборот. Это удобно для тиражирования read-only файлов.
Я у себя реализовал распределенный файловый сервер немного иначе. А именно - вначале провел рестуруктуризацию данных, проанализировал - кому и что надо. И по результатам этого анализа и растащил файло на различные сервера. То есть реализовал правило, близко лежать должно то, что чаще всего нужно. А то, что нужно редко - можно и подождать несколько секунд, пока это файло к тебе через интернет приедет. Или - велкам в сервер терминалов.
Самый простой вариант, который приходит в голову - rsync.
Полснотью согласен с Cruiser78:
близко лежать должно то, что чаще всего нужно. А то, что нужно редко - можно и подождать несколько секунд, пока это файло к тебе через интернет приедет.
И исходя из этого правила, rsync-ом разруливать что и куда и в какую сторону сторону зеркалить.
Самый простой вариант, который приходит в голову - rsync.
Полснотью согласен с Cruiser78:близко лежать должно то, что чаще всего нужно. А то, что нужно редко - можно и подождать несколько секунд, пока это файло к тебе через интернет приедет.
И исходя из этого правила, rsync-ом разруливать что и куда и в какую сторону сторону зеркалить.
а как отслеживать изменения rsync'ом? может есть еще какие то варианты?
а как отслеживать изменения rsync'ом? может есть еще какие то варианты?
В realtime никак. Но!!! rsync не самая тупая программа. И она не станет синхронизировать идентичные файлы. А только различные. И, если мне не изменяет склероз, синхронизирует только измененные "блоки" этих файлов. То есть гигабайты трафика не порождаются.
А если есть нужда в синхронизации реального времени (точнее - по событию "close_file") то самое время посмотреть в сторону inotify (http://www.ibm.com/developerworks/ru/library/l-ubuntu-inotify/). И при пойманном событии заряжать скриптом измененный файл на ремутный сервер. У меня на этом "ядре" антивирусная защита на серверах крутится.