Вопрос или проблема
В настоящее время я управляю рядом резервных серверов для резервного копирования других серверов, например, b01, b02, .., bn, все со своими IP, работающие со своими собственными FTP / SSH сервисами. Однако я хотел бы создать всего один интерфейс для хранения и извлечения резервных копий, облегчая процесс для себя и клиентов, подключаясь всегда к одному и тому же хосту, в то время как фактические данные хранятся на множестве серверов в бек-энде, а также улучшить масштабируемость системы.
В настоящее время я использую ZFS с снимками (и сжатием/дедупликацией) для хранения резервных копий, каждый сервер, который резервируется, имеет свой собственный том (20-500G) на сервере резервного копирования ZFS, который создается каждый день для сохранения.
Существует ли программа или техника, чтобы смонтировать/симулировать директорию с другого (резервного) сервера на входящее FTP / SSH соединение к “серверу соединения”? Она должна быть масштабируемой и, если возможно, избыточной, мне не удалось найти что-либо подобное.
Я также открыт для других решений и полного изменения текущей настройки резервного копирования, но есть некоторые требования:
- Снимки резервных копий для сохранения, хранение только различий
- FTP / SSH (rsync) доступ
- Если возможно, применять некоторое сжатие и/или дедупликацию для экономии дискового пространства
- Масштабируемость до сотен ТБ
- Высокая производительность
- Избыточность
Я исследовал возможность использования хранилища объектов, например, Openstack Swift, но создание снимков невозможно.
Поэтому мой вопрос заключается в том, как я могу достичь своей цели создания некоторого рода кластера резервного копирования с одним интерфейсом для замены текущей установки, состоящей из отдельных серверов.
Не уверен, является ли это именно тем, что вы ищете, но, по сути, похоже, что вы ищете распределенную файловую систему.
Существуют несколько таких продуктов, начиная с drbd, через ceph, lustre и gluster. Я уверен, что их больше.
Из-за существующей инфраструктуры ZFS я бы посоветовал либо lustre (см. также zol ), либо любую распределенную файловую систему, которая позволяет использовать другую файловую систему поверх ее.
Lustre имеет недостаток в том, что она в первую очередь разработана для hpc scratch данных – это означает высокую производительность, низконадежное хранилище, и поэтому она не оптимизирована как решение для резервного копирования.
Ceph может быть лучшим решением для ваших нужд, но ее поддержка zfs все еще недостаточна.
Тем не менее, ¯- я бы посоветовал обратить внимание на gluster, который имеет поддержку сообщества для такой настройки, хотя их вариант – gluster поверх zfs (что означает, что снимки находятся на уровне отдельных пулов, вместо уровня пространства имен файловой системы).
Я бы все же не рекомендовал использовать drbd для чего-либо критически важного, но если ваши данные дополнительно резервируются (например, на ленту), то drbd над/под zfs может быть жизнеспособным решением также.
drbd поверх zfs, вероятно, достаточно безопасен, но вы все равно теряете глобальные снимки пространства имен.
Ответ или решение
Создание масштабируемого кластера резервного копирования с единым интерфейсом и сохранением данных
Введение
В современном мире, где данные становятся все более ценными, создание надежной и масштабируемой системы резервного копирования является ключевой задачей для IT-специалистов. В данной ситуации описана текущая инфраструктура, состоящая из множества серверов резервного копирования (например, b01, b02 и т.д.), каждый из которых имеет свои IP-адреса и управляет собственными услугами FTP/SSH. Цель состоит в создании единого интерфейса для хранения и извлечения резервных копий, упрощения взаимодействия с клиентами и увеличения масштабируемости системы.
Теоретическая основа
Масштабируемость и надежность резервного копирования — это основные аспекты, которые должны быть учтены при проектировании данной системы. Масштабируемость предполагает возможность системы адаптироваться к увеличению объема обрабатываемых данных без существенной деградации производительности. Надежность подразумевает защиту данных от потерь и их доступность в случае аварий.
Пример — Использование распределенных файловых систем
Распределенная файловая система (DFS) представляет собой инженерное решение, которое может удовлетворять вышеуказанным требованиям. Например, системы Ceph и GlusterFS являются одними из наиболее распространенных решений для создания централизованных и масштабируемых хранилищ данных.
-
Ceph — Это объектная и блочная распределенная файловая система, которая предлагает высокую масштабируемость и надежность за счет распределенного хранения метаданных и данных. Однако её текущая поддержка ZFS может быть ограниченной, что стоит учитывать при интеграции с существующей инфраструктурой на базе ZFS.
-
GlusterFS — Это решение предоставляет возможность создания одного виртуального хранилища, объединяющего несколько физических устройств. GlusterFS может быть легко интегрирован с ZFS, предоставляя возможность создания резервных копий на уровне пула. Несмотря на то что снимки создаются на уровне пула, а не глобальной системы, GlusterFS предлагает значительную гибкость и производительность.
Применение — Реализация решения
При проектировании единого интерфейса резервного копирования с использованием распределенной файловой системы, следует учитывать ряд ключевых требований:
-
Единый интерфейс доступа: Создание виртуального хоста, который будет принимать соединения FTP/SSH и распределять их на соответствующие серверы резервного копирования на базе GlusterFS или Ceph. Это можно реализовать с помощью программного маршрутизации, которая направляет запросы на основание метаданных в глобальное пространство имен файловой системы.
-
Масштабируемость: Используя гетерогенное распределенное хранилище данных, можно легко добавить новые серверы в кластер, увеличивая емкость и производительность системы без серьезной модификации архитектуры.
-
Компрессия и дедупликация: Встроенная поддержка в ZFS может быть интегрирована для хранения резервных копий с уменьшением их объема за счет методов дедупликации и сжатия, сохраняя при этом целостность данных.
-
Снимки для фиксации изменений (snapshots): Благодаря использованию ZFS, можно создавать снимки для эффективной фиксации состояний системы в определенные моменты времени, что позволяет легко возвращаться к предыдущим состояниям в случае необходимости.
-
Отказоустойчивость и избыточность: Распределенное хранение данных с использованием Ceph или GlusterFS позволяет обеспечить устойчивость к отказам отдельных серверов, так как данные реплицируются и синхронизируются между узлами кластера.
Заключение
Создание масштабируемого кластера резервного копирования с единым интерфейсом требует комплексного подхода с учетом текущей IT-инфраструктуры и требований к надежности и производительности. Использование распределенных файловых систем, таких как GlusterFS и Ceph, позволяет создавать гибкие и мощные решения, обеспечивающие надежное хранение данных и доступ к ним. Придерживаясь современной практики и используя передовые технологии для интеграции с существующими системами, можно достичь значительного повышения эффективности и надежности системы резервного копирования.
Таким образом, внедрение распределенной файловой системы, интеграция с ZFS и эффективная маршрутизация запросов позволяет создать единый интерфейс для хранения и извлечения данных, масштабирующийся по мере роста объема данных и востребованности сервиса.