Я создаю приложение, которое должно распределять стандартный файловый сервер по нескольким сайтам по глобальной сети. По сути, каждому сайту нужно написать много разных файлов разного размера (некоторые в диапазоне 100 мегабайт, но большинство меньше), и приложение написано так, чтобы столкновения не были проблемой. Я хотел бы настроить систему, которая отвечает следующим требованиям:
- Каждый сайт может хранить файлы в общем «пространстве имен». То есть все файлы будут отображаться в одной файловой системе.
- Каждый сайт не будет отправлять данные через глобальную сеть без необходимости. Т.е. на каждой стороне WAN будет локальное хранилище, которое будет «объединено» в одну и ту же логическую файловую систему.
- 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 ?
Насколько я понимаю, большая часть последних разработок была за проектом 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 для высокой доступности, которое только что превратилось в ядро.
Однако это имеет некоторые ограничения:
источник
Если вы хотите, чтобы все было просто, взгляните на rsync, он решает множество проблем и может быть заскриптован.
источник
Проверьте на chironfs .
Может быть, он может делать то, что вы хотите, на основе файловой системы.
источник
Btsync - еще одно решение, с которым у меня был хороший опыт. Он использует протокол BitTorrent для передачи файлов, поэтому чем больше у вас серверов, тем быстрее выполняется синхронизация новых файлов.
В отличие от решения на основе rsync, оно определяет, когда вы переименовываете файлы / папки, и переименовывает их на всех узлах вместо удаления / копирования.
Клиенты Yout btsync могут совместно использовать папки в локальной сети.
Единственный недостаток, который я обнаружил (по сравнению с MS DFS), это то, что он не обнаружит локальную копию файла. Вместо этого он будет интерпретировать его как новый файл, загруженный для всех пиров.
Пока что btsync кажется лучшим решением для синхронизации, и его можно установить на Windows, Linux, Android и ARM-устройства (например, NAS)
источник