Опыт реализации хранилища с использованием Tiger Bridge и Yandex Object Storage

Добрый день, друзья! Рано или поздно, при эксплуатации файловых серверов Windows любая организация сталкивается с задачей их расширения и масштабирования. Одним из классических способов решения данной задачи, который используется уже очень давно, является технология Distributed File System (DFS). Шло время и в тот момент, когда компания Microsoft полностью развернула всю свою разработку в сторону публичного облака, началось продвижение на рынок новой технологии — Azure Files. Суть данной технологии заключалась в том, что для расширения хранилища наземных серверов предлагается использовать облачное хранилище Azure Blob Storage. В данной статье постараемся рассмотреть этот сценарий на примере использования решений Tiger Bridge и Yandex Object Storage, а также пройтись по некоторым шагам настройки.

Для начала давайте разберемся, что это за решения, о которых пойдет речь в данной статье.

Итак, Tiger Bridge это сервис, который позволяет расширять файловое хранилище за счет интеграции с любым облаком, с любым S3-хранилищем данных, как общедоступным, от известных вендоров, так и частным, развернутым в инфраструктуре конкретной компании. Решение обеспечивает возможности репликации, распределения по уровням и совместного использования неструктурированных данных с помощью функций блокировки файлов между различными файловыми системами.

Yandex Object Storage — это облачный сервис для хранения данных. Он подходит как для высоконагруженных сервисов, которым требуется надежный и быстрый доступ к данным, так и для проектов с невысокими требованиями к инфраструктуре хранения.

Предлагаю рассмотреть простой вариант реализации данного сценария на базе вышеуказанных продуктов.

Для реализации сценария нам понадобятся:

1. Файловый сервер под управлением OS Windows Server не ниже версии 2012.
2. Tiger Bridge.
3. Подписка Yandex Cloud.

Принципиальная схема решения ниже:

Далее попробую описать по шагам весь процесс.

Для начала создадим «корзину» в Yandex Object storage и дадим доступ к ней сервисному аккаунту.

Все – хранилище готово!

Теперь переходим к файловому серверу. Процесс установки сервиса Tiger Bridge на файловый сервис я не стал записывать, т.к. он заключается в паре нажатий кнопки Next и перезагрузке сервера. В целом, этого достаточно для установки.

Далее, подключаем облачную корзину к нашей целевой файловой шаре.

Проверяем что все работает.

Теперь, в зависимости от задачи, необходимо настроить политики Tiger Bridge. Если все оставить по умолчанию, то сервер просто зальет в облако копию нашей файловой шары, и будет постоянно поддерживать ее в актуальном состоянии. Таким образом обеспечиваются два сценария – BackUp и Data Recovery.

Но нам же необходимо именно расширить наш файловый сервер за счет облачного хранилища, ведь так? Настраиваем политику. Для примера мы возьмем следующие параметры – 70% и файлы, обращение к которым было больше, чем месяц назад.

При достижении квоты по заполнению наземной шары в 70%, Tiger Bridge начнет «выкидывать» в облако файлы, к которым никто не обращался уже более месяца.

Важным моментом во всей этой схеме является то, что для пользователя это все очень прозрачно. В своем проводнике он всегда видит полную структуру всех папок и файлов. Да – почему-то старые файлы открываются с небольшой задержкой (Tiger Bridge в этот момент их загружает обратно на файловый сервер), но в подавляющем большинстве случаев этого никто даже и не заметит.

Что же у нас получилось в итоге: в данном сценарии нам удалось добиться расширения файлового хранилища и одновременное бэкапирование данных с земли в облако.

Как мне кажется, получается вполне себе очень изящный вариант без существенных трудозатрат а также без необходимости закупать дополнительное железо.
Спасибо Вам за внимание и хорошего дня!