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

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

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

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

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

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

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

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

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

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

• На что похожа топология подключения WAN - хаб и спица, полная сетка? Насколько это надежно?

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

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

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

Вы рассматривали AFS ?

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

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

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

Вы смотрели на бассейны OST в Luster?

Это не будет автоматическим, но с помощью пулов OST вы можете назначать каталоги / файлы определенным OST / OSS - в основном это распределение на основе политик, а не циклический перебор по умолчанию / чередование по OST.

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

Есть много работы, направленной на улучшение Luster через WAN-соединения (локальные серверы кэширования и тому подобное), но все это находится в стадии интенсивной разработки AFAIK.

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

Также стоит обратить внимание на mabye UnionFS. При этом я думаю, что каждое расположение будет экспортом NFS, и тогда вы можете использовать UnionFS в каждом местоположении, чтобы это и все остальные монтирования NFS из этого местоположения отображались как одна файловая система. У меня нет опыта с этим, хотя.

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

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

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

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

Проверьте на chironfs .

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

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

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

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

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

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