Географически распределенная файловая система с предпочтительной местностью
Существуют некоторые (я столкнулся, возможно, с двумя из них), сравнительные тесты изображения файла по сравнению с разделами LVM в сети (дело не в этом трудно для поиска с помощью Google их). Хотя несколько датированный, казалось бы, что LVM обычно быстрее (если крошечным полем). Это было достаточно для меня, таким образом, я пошел со схемой LVM. Насколько копирование идет, все еще можно смонтировать логический том LVM, targzip оно и передать его другому местоположению. Дело не в этом намного тяжелее. И LVM делает намного легче развернуть Ваше серверное хранилище.
Позор о требовании Linux. Это точно, что делает Windows DFS. С 2003 R2, это делает это на основе блочного уровня, также.
-
1Chris, спасибо за ответ. Я думаю, что DFS в значительной степени что I' m поиск, хотя в Windows. Конечно, что-то, чтобы я изучил. – dpb 25 March 2010 в 03:47
Некоторые вопросы:
Сколько узлов "сервера", Вы думаете о наличии, участвует в этой вещи?
Какова топология возможности соединения WAN как - концентрируют и говорил, полная сетка? Насколько надежный это?
Вы ожидаете клиенты к обработке отказа к географически нелокальному серверу в конечном счете сбои локального сервера?
Windows DFS-R, конечно, был бы, что Вы ищете, хотя для некоторого потенциально значительного лицензирования стоит.
Вы говорите, что коллизии не являются проблемой, и Вам не нужен распределенный менеджер блокировок, таким образом, Вы могли сделать это с инструментами пространства пользователя как rsync или Унисон и просто экспортировать получающийся корпус файлов с NFS локальным клиентам. Это ужасно, и необходимо было бы обработать сталкивание некоторой системы для обработки генерации топологии репликации и на самом деле рабочий инструменты пространства пользователя, но это, конечно, будет дешево, когда лицензирование стоимости идет.
-
1Спасибо за ответ Evan я обновил свой вопрос с данными, которые Вы просили. I' m заинтересованный Вашей unison/rsync идеей, но don' t вполне видят, как динамический аспект был бы обработан. (Я don' t имеют большой опыт с Унисоном, только rsync). – dpb 25 March 2010 в 03:45
-
2@dpb: Я wasn' t получение смысла того требования в Вашем исходном редактировании. Microsoft DFS-R won' t делают это, также. Поведение извлечения по запросу собирается потребовать чего-то " active" в файловой системе для прерывания запросов чтения на тупики файла это don' t кэшировали их локальные данные, пойдите, получают данные и выполняют чтение. I' m не знающий о любой географически распределенной файловой системе с тем поведением - that' s больше как HSM. – Evan Anderson 25 March 2010 в 13:48
-
3Для столь же невежественных как я: en.wikipedia.org/wiki/Hierarchical_storage_management . Еще раз спасибо @Evan. I' m совсем не столь же интересующийся реконструкцией местоположения базовой системы хранения динамическим способом как выбор его первоначально динамическим способом. Я думаю, что HSM звучит очень прохладным, но прохладная часть его является симпатичным излишеством для какой I' m выполнение. – dpb 26 March 2010 в 17:17
Вы рассмотрели AFS?
Файловая система Эндрю (AFS) является распределенной сетевой файловой системой, которая использует ряд доверенных серверов для представления гомогенного, прозрачного для местоположения пространства имен файлов всем клиентским рабочим станциям.
Насколько я понимаю большая часть последней разработки была позади проекта OpenAFS.
Я не могу симулировать быть достаточно знакомым с проектом знать, доступна ли "предпочтительная местность" функция, но иначе это походит на хорошую подгонку.
-
1
Вы посмотрели на пулы OST в Блеске?
Это не будет автоматически, но с пулами OST можно присвоить каталоги/файлы определенному OST/OSSes - в основном основанное на политике выделение ресурсов хранения, а не циклический алгоритм/чередование по умолчанию через OSTs.
Таким образом, Вы могли установить каталог на сайт и присвоить тот каталог локальному OSTs для того сайта, который направит весь ввод-вывод к локальному OSTs. Это все еще будет глобальное пространство имен.
Существует большая работа, входящая в улучшающийся Блеск по соединениям WAN (локальные серверы кэширования и подобные вещи), но это находится в процессе все все еще тяжелого развития AFAIK.
-
1Спасибо @James, Который является почти точно что I' m поиск. I' m не увлеченный портившим пространством имен на верхнем уровне (присваивают конкретные каталоги пулу OST), но возможно который был бы в порядке. It' s, по крайней мере, хороший для знания то, что вариант использования и ограничение находятся в Блеске. Еще раз спасибо! – dpb 26 March 2010 в 17:20
Возможно, NFS, но с Cachefs на серверах приложений выполнит Вашу часть Вашей цели. Насколько я понимаю все записанное все еще пойдет центральный сервер, но по крайней мере читает, мог закончить тем, что кэшировался локально. Это могло потенциально снять много задержки чтений в зависимости от Ваших шаблонов использования.
Кроме того, mabye UnionFS стоит изучить. С этим я думаю, что каждое местоположение было бы экспортом NFS, и затем Вы могли использовать UnionFS в каждом местоположении, чтобы иметь это и все другие, NFS монтируется от местоположения, появляются как одна файловая система. У меня нет опыта с этим все же.
-
1Спасибо @Kyle, я didn' t знают о UnionFS, наряду с агрессивным кэшированием, NFS мог быть хорошим решением для этого. I' m думающий, что это могло добраться, чтобы быть большей проблемой для поддержания, поскольку количество местоположений выросло, но I' m собирающийся изучать это, прежде чем я решу. – dpb 26 March 2010 в 17:37
Вы могли изучить DRBD для тиражирования дисков. http://www.drbd.org/. Это - Высокодоступное решение Linux, которое сейчас превратило его в Ядро.
Однако это имеет некоторые ограничения:
- Могут быть настроены только два узла
- WAN могла бы быть слишком ненадежной для хранения DRBD устойчивый.
-
1Интересная идея, однако я don' t думают, что это дало бы моему приложению что-либо по другим распределенным файловым системам. (блеск, glusterfs, и т.д.). Спасибо за регистрацию... – dpb 25 March 2010 в 03:49
Если Вы хотите сохранить это простым, затем взглянули rsync, решает много проблем и может быть задан сценарием.
Проверьте chironfs.
Возможно, это может сделать то, что Вы хотите на основе файловой системы.
Btsync - еще одно решение, с которым у меня был хороший опыт. Он использует протокол BitTorrent для передачи файлов, поэтому чем больше у вас серверов, тем быстрее выполняется синхронизация новых файлов.
В отличие от решения на основе rsync, он определяет, когда вы переименовываете файлы / папки, и переименовывает их на всех узлах вместо удаления / копирования.
Теперь ваши клиенты btsync могут совместно использовать папки в локальной сети.
Единственный недостаток, который я обнаружил (по сравнению с MS DFS), заключается в том, что он не обнаруживает локальную копию файла. Вместо этого он будет интерпретировать его как новый файл, загруженный всем партнерам.
Пока что btsync кажется лучшим решением для синхронизации, и его можно установить на устройствах Windows, Linux, Android и ARM (например, NAS)