none
Организация файлового хранилища Cifs или SOFS ? RRS feed

  • Вопрос

  • Доброго времени суток уважаемые коллеги.

    Что существует

    1.Есть СХД и на данной хранилке развернули хранение шар, а так же доступ к ним через cifs,то бишь получается обычный NAS. 

    2.Есть исходное файловое хранилище- очень большое и жирное, с кучей прав и групп.

    3.Всем пользователям это отдано через GPO как ярлык в их окружение.

    Задача: Максимально прозрачно перенести все это счастье на СХД и при этом пользователь бы обычным образом открывал данный ярлык- допустим 24x7- то есть перерывов практически-нельзя/критично!!.

    Возможные принципы решения:

    Если можно было бы подружить СХД с DFS- то все решилось бы на раз,два- репликацией с одного места в другое.

    Вопросы:

    1.Если исходить из текущего и на мой взгляд странного решения (использовать полку для NAS ), то есть ли еще способы прозрачно отмигрировать  всю иерархию папок и прав на СХД, практически на лету без простоя ?

    2.Если этот подход поломать и отдать СХД в блочный доступ на гипервизор с виртуалками и построить SOFS хранилище с уже встроенными возможностями дедубликации, VSS, а так же DFS реплики ?

    Был ли у кого такой печальный опыт ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 26 октября 2016 г. 8:16
    26 октября 2016 г. 8:14

Ответы

  • У вас задача реально распадается на несколько.

    1. Определиться, как именно вы будете хранить данные и предоставлять к ним доступ - использовать хранилище в режиме SAN с файл-сервером(ами) под Windows Server или в режиме NAS. Если первое, то определиться с реализацией файл-сервера. В данном случае это - скорее обычный кластерный сервер. SoFS для вашей задачи подходит плохо - он предназначен для сценариев, когда приложения долго работают с постоянно открытыми и достаточно большими файлами. Например - для хранения виртуальных дисков или баз данных.

    2. Обеспечить доступ к данным по одному и тому же пути независимо от места их хранения. Стандартное средство для этого в Windows Server - DFS Namespace. Целевые папки в пространстве имён при этом могут быть где угодно - и на NAS, и на Widnows Server. Как именно перейти на доступ через DFS Namespace - зависит от того, надо ли сохранять имя "сервера" или достаточно его поменять в ярлыке - второе, как понимаете, сильно проще, но первое тоже реализуемо.

    3. Перенести данные так, чтобы это минимально повлияло на пользователей. Тут всё зависит от допустимого времени простоя. Одно дело, если за это время можно скопировать одну целевую папку целиком, другое - если придётся копировать сначала основную часть, потом изменения. Если DFS Replication у вас использовать невозможно, то есть на это и другие средства - robocopy, например.

    PS Мне данные с сервера на сервер, не сильно нарушая работу пользователей, таскать приходилось неоднократно. Но мне было сильно легче, потому что во-первых практически изначально была использована DFS (которая нынче DFS Namespace), а, во-вторых, перерывы в работе пользователей позволяли без проблем переносить данные сразу целыми папками, так что достаточно было xcopy.


    Слава России!

    26 октября 2016 г. 12:10
  • DFS namespaces и DFS Replication - это совсем разные технологии, общего в них - только первое слово в названии (ну, и один из параметров в свойстве реплицируемой папки - имя в DFS Namespace, которое может и отсутствовать).

    Так вот, для использования NAS с DFS Namespaces в качестве хранилища целевых папок не нужно ничего, кроме поддержки SMB/CIFS: всю необходимую работу делают сервер пространства имён и клиент.

    А вот для поддержки DFS Replication необходимо, чтобы она была реализована непосредственно на NAS.


    Слава России!

    26 октября 2016 г. 12:31
  • Да я вас понял.Скорее второго функционала нет.

    Попробуем капнуть DFS Namespaces + robocopy


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    26 октября 2016 г. 12:50

Все ответы

  • У вас задача реально распадается на несколько.

    1. Определиться, как именно вы будете хранить данные и предоставлять к ним доступ - использовать хранилище в режиме SAN с файл-сервером(ами) под Windows Server или в режиме NAS. Если первое, то определиться с реализацией файл-сервера. В данном случае это - скорее обычный кластерный сервер. SoFS для вашей задачи подходит плохо - он предназначен для сценариев, когда приложения долго работают с постоянно открытыми и достаточно большими файлами. Например - для хранения виртуальных дисков или баз данных.

    2. Обеспечить доступ к данным по одному и тому же пути независимо от места их хранения. Стандартное средство для этого в Windows Server - DFS Namespace. Целевые папки в пространстве имён при этом могут быть где угодно - и на NAS, и на Widnows Server. Как именно перейти на доступ через DFS Namespace - зависит от того, надо ли сохранять имя "сервера" или достаточно его поменять в ярлыке - второе, как понимаете, сильно проще, но первое тоже реализуемо.

    3. Перенести данные так, чтобы это минимально повлияло на пользователей. Тут всё зависит от допустимого времени простоя. Одно дело, если за это время можно скопировать одну целевую папку целиком, другое - если придётся копировать сначала основную часть, потом изменения. Если DFS Replication у вас использовать невозможно, то есть на это и другие средства - robocopy, например.

    PS Мне данные с сервера на сервер, не сильно нарушая работу пользователей, таскать приходилось неоднократно. Но мне было сильно легче, потому что во-первых практически изначально была использована DFS (которая нынче DFS Namespace), а, во-вторых, перерывы в работе пользователей позволяли без проблем переносить данные сразу целыми папками, так что достаточно было xcopy.


    Слава России!

    26 октября 2016 г. 12:10

  • 2. Обеспечить доступ к данным по одному и тому же пути независимо от места их хранения. Стандартное средство для этого в Windows Server - DFS Namespace. Целевые папки в пространстве имён при этом могут быть где угодно - и на NAS, и на Widnows Server. Как именно перейти на доступ через DFS Namespace - зависит от того, надо ли сохранять имя "сервера" или достаточно его поменять в ярлыке - второе, как понимаете, сильно проще, но первое тоже реализуемо.


    День добрый коллега. А вот здесь по подробнее, если можно. Как бы я забыл упомянуть одно- если будет возможно нацелить СХД на DFS Namespaces, то в принципе проблема решается репликацией всего содержимого, так как на исходном сервере DFS уже имеется. После репликации исходный сервер выключаем- ярлык остается на месте.Просто пока нет понятия, как именно без самой службы DFS на СХД сделать репликацию ?

    Просто странный выбор- использовать хранилище высокого уровня для какого то CIFS...


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 26 октября 2016 г. 12:21
    26 октября 2016 г. 12:20
  • DFS namespaces и DFS Replication - это совсем разные технологии, общего в них - только первое слово в названии (ну, и один из параметров в свойстве реплицируемой папки - имя в DFS Namespace, которое может и отсутствовать).

    Так вот, для использования NAS с DFS Namespaces в качестве хранилища целевых папок не нужно ничего, кроме поддержки SMB/CIFS: всю необходимую работу делают сервер пространства имён и клиент.

    А вот для поддержки DFS Replication необходимо, чтобы она была реализована непосредственно на NAS.


    Слава России!

    26 октября 2016 г. 12:31
  • Да я вас понял.Скорее второго функционала нет.

    Попробуем капнуть DFS Namespaces + robocopy


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    26 октября 2016 г. 12:50