Синхронизация файловых систем двух серверов

Господа.
Есть организация, в которой я работаю... программистом.
И я ежедневно сталкиваюсь с таким маразмом:
Сначала контора была единой.
Потом отделился довольно большой филиал, который связан с основной конторой по узенькому интернет - каналу
(филиал в Иваново, там - adsl)

В работе используется папка на сервере (Windows Server 2008), с большим кол-вом файлов и значительным объемом. (около миллиона файлов и около терабайта объема)

Эта папка в филиале примеплена просто как сетевая шара (network share).
То есть каждый файл открывается секунд по сорок.

я как поклонник всяких BTSync'ов и вообще дропбоксов давно хочу перевести все на две синхронизируемые файловые системы.

И на этом пути есть такие проблемы:
1) я с удовольствием перешел бы на Linux, но тут Windows - связщенная корова. Даже, я бы сказал кАрова.

2) существенным требованием является вот что: если один пользователь в сети открывает с сетевого диска файл Word'ом, то у всех других, кто пытается это сделать, появляется сообщение "файл такой то занят, хотите открыть в режиме чтения?". И это используется в бизнес процессе ("Маша, закрой нафик график отпусков!")

3) поэтому я ограничен в средствах. после "протухания" BTSync я попробовал SyncThing.
Но SyncThing во первых, медленный (то есть он долго соображает, когда в папку добавляется новый файл, даже если он пустой или размером 1 байт. А все потому, что использует просто периодическое сканирование каталога, и там есть интервал сканирования. Причем при миллионе файлов это до-о-о-о-о-лгий процесс), во вторых - он точно не работает так, как написано в 2)

Подскажите мне, в какую сторону копать?
1)
Я думал про DFS (Windows DFS, Distributed File System) Но я ей не пользовался, и не знаю, насколько она хороша.
Учитывая предыдущий опыт от работы с Windows - что то я сомневаюсь.

2)
SyncThing доступен с исходниками и написан, по моему, на Go.
Можно попробовать его аккуратненько поломать, но скоре всего потеряется мультиплатформенность. Да и опыт в Go у меня нулевой.

3)
Конечно, у меня чешутся руки написать самому синхронизацию, пользуясь c# и таким классом FileSystemWatcher
(позволяет получать уведомления об изменениии файловой системы)

4)
Последний вариант - радикальный, отказываться от винды, но наружу из линукса все равно должна торчать самба.
Но и на эту тему - я не знаю, какой именно инструмент выбрать.

Жду ваших советов.
Спасибо!

С уважением,

Константин

0

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

0

Приветствую, и спасибо за ответ.
Но я нигде не писал, что проблема - в OS.
И я согласен, что terminal server можно вписать как пятый пункт в мой список.
Но, поверьте, я знаю, что при пинге 50 мс работа с текстовым редактором уже превращается в ме-е-едленное "плавание в акваланге".
Так что все таки хотелось бы им устроить синхронизированные файловые системы.
Неужели ситуация настолько уникальная?

0

Сообщение от SteeLHeaD ... думал про DFS...

Этот инструмент не имеет отношения к указанной задаче.

Сообщение от SteeLHeaD ... не знаю, насколько она хороша. Учитывая предыдущий опыт от работы с Windows - что то я сомневаюсь...

Напрасно. Хороший сервис, если с умом настроен.

0

а зачем ты написал про то, что работаешь программистом?

потому как первый же дельный совет, который приходит в голову

- "вот и продолжай программировать"



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

0

Сообщение от SteeLHeaD Но, поверьте, я знаю, что при пинге 50 мс работа с текстовым редактором уже превращается в ме-е-едленное "плавание в акваланге".

При таком пинге и то синхронизации ничего хорошего ждать не стОит.
Пример: имеем два сервера на которых лежит по аналогичному файлику, скажем "primer.doc".
Пользователь открывает этот файл на своем сервере в Иваново, файл при открытии (согласно Вашей задаче) должен заблокировать для редактирования свой аналог на другом сервере, а после завершения пользователем Иваново редактирования файла, последний должен заменить своего собрата на другом сервере.
При пинге 50 Мс это будет происходить куда дольше, нежели медленное плавание в акваланге.
На худой конец реализуйте в головной конторе FTP и пусть пользователи работают с документами в браузере.

0

Приветствую.
Заставлять пользователей работать с файлами в браузере - это утопия.
"При пинге 50 Мс это будет происходить куда дольше, нежели медленное плавание в акваланге." - отнюдь нет. Между работой с быстро меняющимся контентом на экране, когда ввод очередного символа приводит к обновлению набора подсказок (IntelliSense) и посылкой одной - единственной команды "заблокировать файл" - большая разница.
Я написал, что работаю программистом, именно потому, что у меня чешутся руки решить эту проблему. но я не хочу делать работу, которую уже кто то сделал. И если мне кто то скажет "смотри, вот на гитхабе бранч SyncThing, только использующий inotify, и он решает твою проблему!" (намек на Syncthing-GTK) - я был бы очень рад.
Поэтому я и написал этот пост, но пока никто имеющий опыт в решении проблемы именно синхронизацией - мне не ответил.

0

Сообщение от SteeLHeaD отнюдь нет

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

Сообщение от SteeLHeaD Заставлять пользователей работать с файлами в браузере - это утопия.

А почему нет?
Во многих холдинговых организациях имеются даже корпоративные порталы, на самых примитивнх и главное бесплатных движках.
По сути это массовая файлопомойка с веб-мордой.

0

> Вот тут Вам меня не переубедить: обмен данными в виде передачи файла будет дольше, чем обновление кадров в секунду.
Для того, чтобы ЗАБЛОКИРОВАТЬ файл от записи - не надо передавать много данных. Достаточно одного сигнального пакета - и файл на другой стороне заблокирован от изменений. Когда файл на моей стороне изменился и записан - тогда начинается блочная синхронизация. Мне все равно, что время синхронизации может быть заметным, мне важно, что файл быстро открывается. И, в общем то, быстро закрывается - синхронизация будет идти невидимо для пользователя.
Про утопию работы в браузере: это можно делать в простых, не требующих скорости и большого объема случаях. В настоящей работе десктопные приложения удобнее.

0

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

Никто не мешает Вам использовать любой файл-менеджер, например ToyalCMD.
Не нужно недооценивать пользователей: чему надо они научатся и без Вашей помощи.

0