В настоящее время я использую несколько резервных серверов для резервного копирования других серверов, например b01, b02, .., bn, все со своими IP-адресами, с собственными службами FTP / SSH. Однако я хотел бы создать только один интерфейс для хранения и извлечения резервных копий, что упростило бы мне и клиентам, всегда подключаясь к одному и тому же хосту, в то время как фактические данные хранятся на нескольких внутренних серверах, а также улучшить масштабируемость система.
В настоящее время я использую ZFS со снимками (и сжатием / дедупликацией) для хранения резервных копий, каждый сервер, для которого выполняется резервное копирование, имеет свой собственный том (20-500 ГБ) на сервере резервного копирования ZFS, который каждый день снимается для хранения.
Существует ли программа или методика для монтирования / моделирования каталога с другого (резервного) сервера при входящем FTP / SSH-соединении с «сервером (-ами) соединений»? Он должен быть масштабируемым и, если возможно, избыточным, я ничего не смог найти.
Я также открыт для других решений и полностью меняю текущую настройку резервного копирования, но у нее есть некоторые требования:
Я изучаю возможность использования хранилища объектов, такого как Openstack Swift, но создание моментальных снимков невозможно.
Поэтому у меня вопрос: как я могу достичь своей цели - создать какой-то резервный кластер с одним интерфейсом, чтобы заменить текущую настройку, существующую на автономных серверах.
Не уверен, что это именно то, что вы ищете, но в основном это похоже на то, что вы ищете распределенную файловую систему.
Таких продуктов несколько (начиная с drbd, through, ceph, lustre и gluster. Я уверен, что их больше). Из-за существующей инфраструктуры ZFS я бы посоветовал либо блеск (также см зол ) или любой распределенной fs, которая позволяет использовать другую fs поверх себя.
У Lustre есть недостаток, заключающийся в том, что он предназначен в первую очередь для рабочих данных hpc, что означает высокую производительность, низкую надежность хранилища и, следовательно, не оптимизирован в качестве решения для резервного копирования.
Ceph может быть лучшим решением для ваших нужд, но это поддержка zfs все еще не хватает
Тем не менее - я бы посоветовал посмотреть на глиттер, у которого поддержка сообщества для такой настройки, хотя их маршрут - это gluster поверх zfs (что означает, что моментальные снимки находятся на уровне отдельного пула, а не на уровне пространства имен файловой системы).
Я бы по-прежнему не советовал использовать drbd для чего-либо критически важного, но если ваши данные дополнительно копируются (например, на ленту), то drbd выше / ниже zfs также может быть жизнеспособным решением.
drbd поверх zfs, вероятно, достаточно безопасен, но вы по-прежнему теряете снимки глобального пространства имен.