Как организовать сетевое хранилище с дисками в разных точках России?
Есть два офиса. Один в Москве, другой в Барнауле.
Необходимо создать один общий раздел из дисков, которые находятся в обоих городах (что-то вроде сетевого хранилища), но чтобы файлы, которые принадлежат Барнаулу, физически лежали на диске Барнаула, а файлы, принадлежащие Москве, физически лежали на московском диске.
1. Данные какие (пользовательские файлы, базы данных ...)
2. Доступ к "что-то вроде сетевого хранилища" как хотите организовать iscsi, fc, smb ... т.е. поподробнее что должно получиться в результате.
3. Операционные системы какие?
Данные пользовательские. Пользователи работают под windows, на сервере предпочтительней gentoo. А вот c решением (iscsi, fc, smb ... ) хотелось бы услышать совета, как сделать лучше.
Логически, у клиента они будут находится в одной директории. Я же нарисовал, в каталоге /files/ на линуксовском серваке nfs-ом примапливается удаленная директория, сам каталог /files/ через самбу мапится виндовым клиентам (в данном примере как диск, можете замапить как директорию), в результате будет 1 директория в которой общие файлы. Ну или на линуксе сделайте путь /shara/files/остальные директории, замапите /shara/, у клиента будет /files/остальные директории, просто ведь :-)
Ставим хранилище в доступном месте, куда скорость доступа из Барнаула и Москвы одинаковая... Допустим в Германии.
Там держим свое добро, а между серверами и хранилищем настраиваем синхронизацию данных.
Первое что придумалось.
Дело в том, что в Барнауле с каналом Интернет явные проблемы. Скорость и качество оставляют желать лучшего. Оставить офис без документов в момент разрыва не представляется возможным.
ну держите значит и в Барнауле сервер(который синхронизируется с другими), при разрыве будет с ним только работать, после восстановления, что-то отдаст другим, а что-то заберет себе.
Если на серверах поставите windows, то схема следующая:
1. Создаете шару на сервере в Москве (где лежат документы Москвы).
2. Создаете шару на сервере в Барнауле (где лежат документы Барнаула).
3. Шары добавляете в пространство DFS, его мапите клиентам как сетевой диск.
По линуксу.
1. Схема та-же, но вместо DFS используем NFS (но с виндой тормознуто будет, не очень клиент nfs в винде).
2. Используем DFS в SAMBA, пусть меня поправят, вроде есть возможность создания стандэлон корня дфс.
P.S. Скорость открытия удаленных файлов будет ограничена скоростью подключения.
Если есть доменная структура, лучше использовать на серверах windows.
@bk0011m, объясните зачем синкать если в 95% случаев ребята из Барнаула работают только со своим контентом ?
Человек с DFS предложил здравую идею, в nix подобное тоже можно провернуть при помощь bind маунт пойнтов.
@bk0011m синк, по опыту, опасная штука - что будет при изменении файла одновременно с двух серверов? (печалька будет) если только один поставить в read-only, но тогда он будет только для катострофоустойчивости (+ трафик на синк).
@ptchol rsync меньше канал грузит, в отличии от dfs. С другой стороны, не нравится - не пользуй. Я предложил, как я бы сделал. Вы можете сделать иначе.
С nfs в общем-то понятно. Вопрос в том, возможно ли выставить приоритет, на какой физический носитель записывать данные из Барнаула, а на какой данные из Москвы?
@zutuch "приоритета в NFS" нет, NFS "предствляет удаленную директорию, как локальную", просто по вышеописанной топологии данные из Барнаула будут в Барнауле, а данные Москвы в Москве, но если Барнаул открывает Московский файл, то он открывается из Москвы. Наверное проще схему нарисовать, может нарисуете, что Вы хотите получить?
