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

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

3oiai2hyznaclsh93ucv_c6sy3i.jpeg

Предлагаю рассмотреть простой вариант реализации данного сценария с помощью продукта Tiger Bridge и S3 совместимого хранилища Yandex Object Storage.

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

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


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

rur6chrebjv49fg9s1bgn0crzne.png

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

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

bq4tstouxgqkqwchwgsch1wpgro.png

byub9roput_0slk_dvil5xzg8_a.png

0cwed86jbe9rbvyct1iwae2khsc.png

mk_wee1txucsifwnjzmunm7bslo.png

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

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

a-1ybs1ih_qj7bxjhouacoo_ose.png

hcocsl_so57wqfwc9ensmpt0wjc.png

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

hhiu1yit6b2rnamspmohs4urdbe.png

ftirtlsowkfjy6rvk2pkj5cbzzg.png

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

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

auw6prv0ayxvcdkojyvsvzj3zfg.png

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

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

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

© Habrahabr.ru