Я создаю приложение, которому необходимо распределить стандартный файловый сервер между несколькими сайтами через глобальную сеть. По сути, каждому сайту необходимо записать множество разных файлов разного размера (некоторые из них имеют размер порядка 100 МБ, но самые маленькие), и приложение написано таким образом, что коллизии не являются проблемой. Я хотел бы настроить систему, которая отвечает следующим требованиям:
По сути, что-то вроде центрального общего ресурса NFS отвечало бы большинству требований, однако это не позволяло бы локально записанным данным оставаться локальными. Все данные с удаленных сторон глобальной сети будут постоянно копироваться локально.
Я изучил Lustre и провел с ним несколько успешных тестов, однако, похоже, он довольно равномерно распределяет файлы по распределенному хранилищу. Я покопался в документации и не нашел ничего, что автоматически «предпочло бы» локальное хранилище удаленному хранилищу. Подойдет даже то, что идет с хранилищем с минимальной задержкой. Он будет работать большую часть времени, что соответствует требованиям этого приложения.
Некоторые ответы на некоторые вопросы, заданные ниже:
Позор по поводу требований Linux. Это именно то, что делает Windows DFS. Начиная с 2003 R2, он также делает это на блочной основе.
Некоторые вопросы:
Сколько «серверных» узлов вы думаете об участии в этом деле?
На что похожа топология подключения к глобальной сети - концентратор и спица, полная сетка? Насколько это надежно?
Ожидаете ли вы, что клиенты переключатся на географически нелокальный сервер в случае отказа локального сервера?
Windows DFS-R определенно будет тем, что вы ищете, хотя и за некоторые потенциально большие затраты на лицензирование.
Вы говорите, что коллизии не проблема и вам не нужен распределенный менеджер блокировок, поэтому вы можете сделать это с помощью таких инструментов, как rsync или Унисон и просто экспортируйте полученный корпус файлов с помощью NFS на локальные клиенты. Это уродливо, и вам придется справиться с созданием какой-то системы для создания топологии репликации и фактического запуска пользовательских инструментов, но это, безусловно, будет дешево с точки зрения затрат на лицензирование.
Вы считали AFS?
Файловая система Andrew File System (AFS) - это распределенная сетевая файловая система, которая использует набор доверенных серверов для представления однородного, прозрачного по местоположению пространства имен файлов для всех клиентских рабочих станций.
Насколько я понимаю, большая часть недавних разработок была связана с OpenAFS проект.
Я не могу притвориться, что достаточно хорошо знаком с проектом, чтобы знать, доступна ли функция «предпочтительная местность», но в остальном это звучит как хорошо.
Вы смотрели на OST бассейны в росписи?
Это не будет автоматически, но с пулами OST вы можете назначать каталоги / файлы определенным OST / OSS - в основном распределение хранилища на основе политик, а не циклический перебор / чередование по умолчанию для OST.
Таким образом, вы можете настроить каталог для каждого сайта и назначить этот каталог для локальных файлов OST для этого сайта, которые будут направлять весь ввод-вывод на локальные файлы OST. Это по-прежнему будет глобальное пространство имен.
Есть много работы по улучшению Lustre over WAN-соединений (локальные кэширующие серверы и тому подобное), но все это все еще находится в стадии интенсивной разработки AFAIK.
Возможно NFS, но с Кеши на серверах приложений выполнит вашу часть поставленной задачи. Насколько я понимаю, все написанное будет по-прежнему отправляться на центральный сервер, но, по крайней мере, чтение может в конечном итоге кэшироваться локально. Это потенциально может привести к значительной задержке чтения в зависимости от ваших шаблонов использования.
Также стоит изучить mabye UnionFS. При этом я думаю, что каждое местоположение будет экспортом NFS, а затем вы можете использовать UnionFS в каждом месте, чтобы это и все остальные монтирования NFS из этого местоположения отображались как одна файловая система. Однако у меня нет опыта в этом.
Вы можете заглянуть в DRBD для репликации дисков. http://www.drbd.org/. Это решение Linux High Availability, которое только что вошло в ядро.
Однако здесь есть некоторые ограничения:
Если вы хотите, чтобы это было просто, взгляните на rsync, он решает множество проблем и может быть написан сценарием.
Проверить Chironfs.
Возможно, он может делать то, что вы хотите, на основе файловой системы.
Btsync - еще одно решение, с которым у меня был хороший опыт. Он использует протокол BitTorrent для передачи файлов, поэтому чем больше у вас серверов, тем быстрее происходит синхронизация новых файлов.
В отличие от решения на основе rsync, оно определяет, когда вы переименовываете файлы / папки, и переименовывает их на всех узлах вместо удаления / копирования.
После этого клиенты btsync могут совместно использовать папки в локальной сети.
Единственный недостаток, который я обнаружил (по сравнению с MS DFS), заключается в том, что он не обнаруживает локальную копию файла. Вместо этого он будет интерпретировать его как новый файл, загруженный всем партнерам.
Пока что btsync кажется лучшим решением для синхронизации, и его можно установить на устройства Windows, Linux, Android и ARM (например, NAS).