Вопрос: Географически распределенная файловая система с предпочтительным местоположением


Я создаю приложение, которое должно распространять стандартный файловый сервер на нескольких сайтах через WAN. В принципе, каждый сайт должен писать много разных файлов разного размера (некоторые из 100-мегабайтного диапазона, но самые маленькие), и приложение написано так, что столкновения не являются проблемой. Я хотел бы иметь систему, которая соответствует следующим требованиям:

  1. Каждый сайт может хранить файлы в общем «пространстве имен». То есть все файлы будут отображаться в одной и той же файловой системе.
  2. Каждый сайт не отправлял данные по глобальной сети, если это не было необходимо. I.e, на каждой стороне WAN будет локальное хранилище, которое будет «слито» в одну логическую файловую систему.
  3. Linux & Free ($$$) - это плюс

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

Я заглянул в Luster и провел с ним несколько успешных тестов, однако, похоже, он распределяет файлы довольно равномерно по распределенному хранилищу. Я прорыл документацию и не нашел ничего, что автоматически «предпочитает» локальное хранилище через удаленное хранилище. Даже то, что было с самым низким запасом памяти, было бы неплохо. Он будет работать большую часть времени, что будет соответствовать требованиям этого приложения.


Некоторые ответы на некоторые вопросы, заданные ниже:

  • Серверные узлы: 2 или 3 для запуска. Каждый сервер будет иметь десятки одновременных подключений для чтения / записи клиентов.
  • Топология WAN является полной сеткой и надежной. (большая корпорация, стоимость не такая ограничивающая, как волокита)
  • Откат клиента: я на самом деле не думал о переходе на резервный сервер (в основном потому, что наше текущее приложение не делает этого только на одном сайте). Я предположил, что практический ответ заключается в том, что серверы на каждом географически распределенном сайте, как ожидается, будут едиными точками сбоев для клиентов, которых они обслуживают. Хотя, если вы думаете о чем-то конкретном здесь, я думаю, что это было бы очень актуально для обсуждения.
  • Roll-my-own: Я подумал о rsync / unison, однако мне понадобится довольно много логики, чтобы сделать «динамическую» часть этой работы без проблем. I.e., файл представляется локальным, но доступен только по требованию.
  • MS-DFS: Это, безусловно, похоже на то, что я должен изучить. Моя основная проблема будет потенциально нестабильной в настройке / надежности / производительности сервера NFS в Windows, так как многие клиенты подключаются к клиентам NFS.

9
2018-03-25 00:36


Источник


Chaged hard req Linux и Free to a Plus. - dpb


Ответы:


Позор о требовании Linux. Это именно то, что делает Windows DFS. Начиная с 2003 R2, он делает это также на блочном уровне.


5
2018-03-25 00:43



Крис, спасибо за ответ. Я думаю, что DFS - это в значительной степени то, что я ищу, хотя и в Windows. Конечно, что-то для меня, чтобы заглянуть. - dpb
DFS не работает на уровне блоков. Служба репликации не является транзакционной на основе файлов. - eckes


Некоторые вопросы:

  • Сколько «серверных» узлов вы думаете о том, чтобы участвовать в этом?

  • Какова топология подключения WAN, например: хаб и спица, полная сетка? Насколько он надежный?

  • Ожидаете ли вы, что клиенты откажутся от переключения на географически нелокальный сервер в случае сбоя локального сервера?

Windows DFS-R, безусловно, будет то, что вы ищете, хотя и для некоторых потенциально значительных затрат на лицензирование.

Вы говорите, что коллизии не являются проблемой, и вам не нужен диспетчер распределенных блокировок, поэтому вы можете сделать это с помощью пользовательских инструментов, таких как rsync или унисон и просто экспортировать полученный пакет файлов с NFS для локальных клиентов. Это уродливо, и вам нужно будет сработать с какой-то системой, чтобы справляться с созданием топологии репликации и фактически запускать пользовательские инструменты, но это, безусловно, будет дешево, так как стоимость лицензирования будет.


3
2018-03-25 01:12



Спасибо за ответ Эван, я обновил свой вопрос с данными, которые вы просили. Я заинтересован в вашей идее unison / rsync, но не совсем понимаю, как будет обрабатываться динамический аспект. (У меня нет большого опыта работы с Unison, только rsync). - dpb
@dpb: Я не понял смысл этого требования в вашем первоначальном редактировании. Microsoft DFS-R тоже этого не сделает. Поведение поиска по требованию потребует что-то «активного» в файловой системе, чтобы перехватывать запросы на чтение для заглушек файлов, которые не имеют кэшированных локальных данных, переходят к данным и выполняют чтение. Я не знаю ни одного географически распределенного файла с этим поведением - это больше похоже на HSM. - Evan Anderson
Для тех, кто невежественный, как я: en.wikipedia.org/wiki/Hierarchical_storage_management, Еще раз спасибо @Evan. Я почти не заинтересован в том, чтобы изменить базовое хранилище динамическим способом, выбрав его изначально динамическим способом. Я думаю, что HSM звучит очень круто, но крутая часть его довольно переполнена тем, что я делаю. - dpb


Вы считали АФС?

Эндрская файловая система (AFS) представляет собой распределенную сетевую файловую систему, которая использует набор доверенных серверов для представления однородного пространства для определения местоположения на всех клиентских рабочих станциях.

Насколько я понимаю, большая часть недавнего развития OpenAFS проект.

Я не могу претендовать на то, чтобы быть достаточно знакомым с проектом, чтобы узнать, доступна ли функция «предпочтительного местоположения», но в остальном это звучит неплохо.


3
2018-03-25 05:57



Проверьте также CodaFS: en.wikipedia.org/wiki/Coda_%28file_system%29 - blank3


Вы посмотрели Бассейны OST в Ластер?

Он не будет автоматическим, но с пулами OST вы можете назначить каталоги / файлы для определенных OST / OSSes - в основном для распределения ресурсов на основе политик, а не для стандартного циклического разметки или чередования по OST.

Таким образом, вы можете настроить каталог на сайт и назначить этот каталог локальным OST для этого сайта, который направит все операции ввода-вывода на локальные OST. Он по-прежнему будет глобальным пространством имен.

Там много работы по улучшению Lustre по WAN-соединениям (локальные серверы кеширования и тому подобное), но все еще находится в тяжелом развитии AFAIK.


1
2018-03-25 13:20



Спасибо @James, Это почти то, что я ищу. Я не увлекаюсь пространством имен munged на верхнем уровне (назначаю определенные каталоги для пула OST), но, возможно, это будет нормально. По крайней мере, хорошо знать, что прецедент и ограничение в Luster. Еще раз спасибо! - dpb


Возможно, NFS, но с CacheFS на серверах приложений выполнит вашу часть вашей цели. Насколько я понимаю, все написанное будет по-прежнему идти на центральный сервер, но, по крайней мере, чтение может быть локально кэшировано. Это может потенциально задержать отсрочку чтения в зависимости от ваших шаблонов использования.

Кроме того, Mabye UnionFS стоит изучить. С этим я думаю, что каждое место будет экспортом NFS, а затем вы можете использовать UnionFS в каждом месте, чтобы это, а все остальные монстры NFS из местоположения отображались как одна файловая система. Однако у меня нет опыта в этом.


1
2018-03-25 13:21



Спасибо @Kyle, я не знал о UnionFS, наряду с агрессивным кешированием, NFS может быть хорошим решением для этого. Я думаю, что с ростом числа мест у вас может возникнуть больше проблем, но я собираюсь изучить его, прежде чем решиться. - dpb


Вы можете посмотреть в DRBD для репликации дисков. http://www.drbd.org/, Это решение с высокой доступностью Linux, которое только что превратилось в ядро.

Однако это имеет некоторые ограничения:

  1. Можно настроить только два узла
  2. WAN может быть слишком ненадежной, чтобы поддерживать DRBD.

0
2018-03-25 01:42



Интересная идея, однако, я не думаю, что это придало бы моему приложению что-либо по сравнению с другими распределенными файловыми системами. (блеск, glusterfs и т. д.). Спасибо за публикацию ... - dpb


Если вы хотите сохранить его простым, то посмотрите rsync, решает множество проблем и может быть написано сценарием.


0
2018-03-25 01:52





Проверить chironfs,

Возможно, он может делать то, что вы хотите, на основе файловой системы.


0
2018-03-25 11:34





Btsync - еще одно решение, с которым у меня был хороший опыт. Он использует протокол BitTorrent для передачи файлов, поэтому чем больше серверов у вас есть, тем быстрее синхронизация новых файлов.

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

Затем клиенты Yout btsync могут совместно использовать папки в локальной сети.

Единственный недостаток, который я нашел (по сравнению с MS DFS), заключается в том, что он не обнаружит локальную копию файла. Вместо этого он будет интерпретировать его как новый файл, загруженный всем сверстникам.

Пока что btsync представляется лучшим решением для синхронизации, и его можно установить на устройствах Windows, Linux, Android и ARM (например, NAS)


0
2017-07-31 23:25