Создание масштабируемого резервного кластера с одним интерфейсом и хранением
В настоящее время я выполняю много серверов резервного копирования для резервирования других серверов с, например, b01, b02.., миллиард, все с их собственным IP, выполняя их собственный FTP / сервисы SSH. Однако я хотел бы создать всего один интерфейс, чтобы сохранить и получить резервные копии, помогающие мне и клиентам всегда подключением к тому же хосту, в то время как фактические данные хранятся на нескольких серверах бэкэнда и также улучшают масштабируемость системы.
Я в настоящее время использую ZFS со снимками (и compression/dedup) для хранения резервных копий, каждый сервер, который поддерживается, имеет свой собственный объем (20-500G) на сервере резервного копирования ZFS, который создается снимки каждый день для хранения.
Там существует, программа или техника для монтирования / моделируют каталог с другого (резервного) сервера на входящем FTP / соединение SSH к "серверу (серверам) соединений"? Это должно быть масштабируемо и если возможный избыточный, я не мог найти что-нибудь.
Я также открыт для других решений и полностью изменения установки актуальной резервной копии, но это имеет некоторые требования:
- Снимок копирует для хранения, различия в хранилище только
- FTP / SSH (rsync) доступ
- Если возможно, примените некоторое сжатие и/или дедупликацию для сохранения дискового пространства
- Масштабируемый к сотням ТБ
- Выполните хорошо
- Избыточный
Я исследовал возможность использования объектно-ориентированной памяти как OpenStack Быстро, но снимок не возможен.
Поэтому мой вопрос, как я могу достигнуть своей цели создания некоторого резервного кластера с одним интерфейсом, для замены текущей установки, существующей из автономных серверов.
Не уверен, что это именно то, что вы ищете, но в основном это звучит так, как будто вы ищете распределенную файловую систему.
.
Существует несколько таких продуктов (начиная от drbd, через, цеф, блеск и глянец). Я уверен, что их больше).
Из-за существующей инфраструктуры ZFS я бы посоветовал либо lustre (также см. zol ), либо любые распределенные fs, которые позволяют использовать другие fs поверх него.
Lustre имеет недостаток в том, что он предназначен в первую очередь для данных hpc scratch - это означает высокую производительность, низкую надежность хранения, и поэтому не оптимизирован в качестве решения для резервного копирования.
Ceph может быть лучшим решением для ваших нужд, но в этом случае поддержка zfs все еще отсутствует
- я бы посоветовал поискать gluster, который имеет поддержку сообщества для такой установки, хотя их маршрут - gluster поверх zfs (что означает, что снэпшоты находятся на уровне отдельного пула, а не на уровне пространства имен файловой системы).
Я бы все еще не советовал использовать drbd для чего-либо критичного для миссии, но если ваша резервная копия данных хранится дальше (например, на ленте), то drbd выше/под zfs также может быть жизнеспособным решением.
drbd поверх zfs, вероятно, достаточно безопасен, но вы все еще теряете снимки в глобальном пространстве имён.
.