2

У всех моих друзей и у меня туберкулез в нашей системе (ах). Однако ни у кого из нас нет полных резервных копий, которые географически распределены, потому что при таком количестве данных такие решения, как Dropbox, S3 и др. являются дорогостоящими для нас. Однако у каждого из нас есть локальное хранилище в избытке. Каждый туберкулез фактически не используется.

Мы начали думать: если бы мы могли объединить наши хосты в какую-либо форму распределенной файловой системы, каждый из нас мог бы получить географически распределенные резервные копии наших полных наборов данных, одновременно добиваясь более высокого использования имеющейся у нас емкости хранения. Идеальное решение ... мы думаем.

  1. Нас как минимум 3. Конечно, 6 или больше, если проект приносит плоды.
  2. У каждого из нас есть 1-2 ТБ данных, и, по крайней мере, столько, чтобы сэкономить.
  3. Мы все разбросаны по WAN.
  4. Нам потребуется возможность любого хоста (ов) входить и выходить из облачного сервиса произвольно.
  5. Реальная (ish) временная синхронизация. В противном случае мы бы просто встречались раз в неделю за пивом и торговали вокруг кучи внешних жестких дисков.
  6. Требуется F/OSS, но у нас много смазки для локтя.
  7. Если мы сможем использовать / изучить / использовать распределенную вычислительную платформу в этом процессе, тем лучше.

Мы начали думать о создании интерфейса Dropbox-esque поверх OpenStack или Hadoop, но я хотел бы услышать, есть ли другие альтернативы, которые мы игнорируем. Возможно, для нашего случая есть еще более простое решение? Возможно ли что-то подобное, учитывая малое количество узлов в кластере?

NB. Естественно, что первоначальная синхронизация / балансировка / передача / и т.д. Займет как минимум несколько дней, но это приемлемо.

|источник

2 ответа2

2

Я использовал sshfs на сервере Ubuntu и простой скрипт rsync через cron. Каждый хост сохраняет свою автономность (даже несмотря на то, что у меня есть root-доступ в моей конфигурации на 3 хостах) и как часто выполняется репликация между узлами, и с какими узлами также можно полностью управлять. Объем хранилища можно контролировать с помощью раздела или квоты, я выбрал раздел просто потому, что контролирую все 3 хоста. Недостатком является отсутствие контроля частоты репликации (синхронизации). Если хост синхронизируется часто, это может привести к чрезмерному использованию полосы пропускания, особенно если снимки используются через wan. Необходима хорошая игра с другими и использование ограничений kbps на команды rsync.

|источник
1

Это не FOSS, но crashplan - довольно хороший вариант для этого. Просто установить и запустить, но он отлично справится с 3, 4 и 5. Его также очень просто настроить - установить клиент, установить полезное пространство и добавить людей, которым вы хотите разрешить использовать это пространство.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .