Добрый день, друзья! Рано или поздно, при эксплуатации файловых серверов Windows любая организация сталкивается с задачей их расширения и масштабирования. Одним из классических способов решения данной задачи, который используется уже очень давно, является технология Distributed File System (DFS). Шло время и в тот момент, когда компания Microsoft полностью развернула всю свою разработку в сторону публичного облака, началось продвижение на рынок новой технологии — Azure Files. Суть данной технологии заключалась в том, что для расширения хранилища наземных серверов предлагается использовать облачное хранилище Azure Blob Storage. В данной статье постараемся рассмотреть данный сценарий на примере использования решений Tiger Bridge и Yandex Object Storage, а также пройтись по некоторым шагам настройки.
Предлагаю рассмотреть простой вариант реализации данного сценария на базе вышеуказанных продуктов.
Для реализации сценария нам понадобятся:
Принципиальная схема решения ниже:
Далее попробую описать по шагам весь процесс.
Для начала создадим «корзину» в Yandex Object storage и дадим доступ к ней сервисному аккаунту.
Все – хранилище готово!
Теперь переходим к файловому серверу. Процесс установки сервиса Tiger Bridge на файловый сервис я не стал записывать, т.к. он заключается в паре нажатий кнопки Next и перезагрузке сервера. В целом, этого достаточно для установки.
Далее, подключаем облачную корзину к нашей целевой файловой шаре.
Проверяем что все работает.
Теперь, в зависимости от задачи, необходимо настроить политики Tiger Bridge. Если все оставить по умолчанию, то сервер просто зальет в облако копию нашей файловой шары, и будет постоянно поддерживать ее в актуальном состоянии. Таким образом обеспечиваются два сценария – BackUp и Data Recovery.
Но нам же необходимо именно расширить наш файловый сервер за счет облачного хранилища, ведь так? Настраиваем политику. Для примера мы возьмем следующие параметры – 70% и файлы, обращение к которым было больше, чем месяц назад.
При достижении квоты по заполнению наземной шары в 70%, Tiger Bridge начнет «выкидывать» в облако файлы, к которым никто не обращался уже более месяца.
Важным моментом во всей этой схеме является то, что для пользователя это все очень прозрачно. В своем проводнике он всегда видит полную структуру всех папок и файлов. Да – почему-то старые файлы открываются с небольшой задержкой (Tiger Bridge в этот момент их загружает обратно на файловый сервер), но в подавляющем большинстве случаев этого никто даже и не заметит.
Что же у нас получилось в итоге: в данном сценарии нам удалось добиться расширения файлового хранилища и одновременное бэкапирование данных с земли в облако.
Как мне кажется, получается вполне себе очень изящный вариант без существенных трудозатрат а также без необходимости закупать дополнительное железо.
Спасибо Вам за внимание и хорошего дня!
Предлагаю рассмотреть простой вариант реализации данного сценария на базе вышеуказанных продуктов.
Для реализации сценария нам понадобятся:
- Файловый сервер под управлением OS Windows Server не ниже версии 2012.
- Tiger Bridge.
- Подписка Yandex.Cloud.
Принципиальная схема решения ниже:
Далее попробую описать по шагам весь процесс.
Для начала создадим «корзину» в Yandex Object storage и дадим доступ к ней сервисному аккаунту.
Все – хранилище готово!
Теперь переходим к файловому серверу. Процесс установки сервиса Tiger Bridge на файловый сервис я не стал записывать, т.к. он заключается в паре нажатий кнопки Next и перезагрузке сервера. В целом, этого достаточно для установки.
Далее, подключаем облачную корзину к нашей целевой файловой шаре.
Проверяем что все работает.
Теперь, в зависимости от задачи, необходимо настроить политики Tiger Bridge. Если все оставить по умолчанию, то сервер просто зальет в облако копию нашей файловой шары, и будет постоянно поддерживать ее в актуальном состоянии. Таким образом обеспечиваются два сценария – BackUp и Data Recovery.
Но нам же необходимо именно расширить наш файловый сервер за счет облачного хранилища, ведь так? Настраиваем политику. Для примера мы возьмем следующие параметры – 70% и файлы, обращение к которым было больше, чем месяц назад.
При достижении квоты по заполнению наземной шары в 70%, Tiger Bridge начнет «выкидывать» в облако файлы, к которым никто не обращался уже более месяца.
Важным моментом во всей этой схеме является то, что для пользователя это все очень прозрачно. В своем проводнике он всегда видит полную структуру всех папок и файлов. Да – почему-то старые файлы открываются с небольшой задержкой (Tiger Bridge в этот момент их загружает обратно на файловый сервер), но в подавляющем большинстве случаев этого никто даже и не заметит.
Что же у нас получилось в итоге: в данном сценарии нам удалось добиться расширения файлового хранилища и одновременное бэкапирование данных с земли в облако.
Как мне кажется, получается вполне себе очень изящный вариант без существенных трудозатрат а также без необходимости закупать дополнительное железо.
Спасибо Вам за внимание и хорошего дня!
