Создание масштабируемого резервного кластера с одним интерфейсом и сохранением
В настоящее время я использую несколько резервных серверов для резервного копирования других серверов, например, b01, b02, .., bn, все со своими IP-адресами, с собственными службами FTP / SSH. Тем не менее, я хотел бы создать только один интерфейс для хранения и извлечения резервных копий, упрощая для себя и клиентов постоянное подключение к одному и тому же хосту, в то время как фактические данные хранятся на нескольких внутренних серверах, а также улучшение масштабируемости система.
В настоящее время я использую ZFS со снимками (и сжатием / дедупликацией) для хранения резервных копий, каждый резервный сервер имеет свой собственный том (20-500G) на резервном сервере ZFS, который каждый день снимается для хранения.
Существует ли программа или методика для монтирования / имитации каталога с другого (резервного) сервера при входящем соединении FTP / SSH с "сервером (ами) соединений"? Он должен быть масштабируемым и, если возможно, избыточным, я не смог ничего найти.
Я также открыт для других решений и полностью изменяю текущую настройку резервного копирования, но у нее есть некоторые требования:
- Резервные копии снимков для сохранения, только различия магазина
- FTP / SSH (rsync) доступ
- Если возможно, примените некоторое сжатие и / или дедупликацию для экономии места на диске.
- Масштабируется до сотен туберкулезов
- Выполнить хорошо
- избыточный
Я изучал возможность использования хранилища объектов, такого как Openstack Swift, но снимок невозможен.
Поэтому мой вопрос заключается в том, как мне достичь своей цели создания некоторого резервного кластера с одним интерфейсом, чтобы заменить текущую настройку существующих автономных серверов.
1 ответ
Не уверен, что это именно то, что вы ищете, но в основном это звучит так, будто вы ищете распределенную файловую систему.
Существует несколько таких продуктов (начиная с drbd, through, ceph, lustre и gluster. Я уверен, что есть и другие). Из-за существующей инфраструктуры ZFS я бы посоветовал либо блеск (также см. Zol), либо любой распределенный fs, который позволяет другой fs поверх него.
Недостаток Luster заключается в том, что он предназначен в первую очередь для временных данных HPC - это означает высокую производительность, низкую надежность хранения и поэтому не оптимизирован как решение для резервного копирования.
Ceph может быть лучшим решением для ваших нужд, но поддержка zfs все еще отсутствует
Тем не менее, я бы посоветовал заглянуть в gluster, который поддерживает сообщества для такой настройки, хотя их маршрут является gluster поверх zfs (что означает, что моментальные снимки находятся на уровне отдельного пула, а не на уровне пространства имен файловой системы).
Я бы все же посоветовал не использовать drbd для чего-либо критически важного, но если резервное копирование ваших данных будет продолжено (например, на ленту), тогда drbd выше / ниже zfs также может быть жизнеспособным решением.
drbd поверх zfs, вероятно, достаточно безопасен, но вы все еще теряете снимки глобального пространства имен.