Опытные мелочи-3, или «Центральное Файлохранилище»

    Продолжаем цикл постов об «опытных мелочах». Предыдущие части можно почитать тут: раз, два.

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

    Напомню, для тех кто забыл, что речь в моем случае идет о небольших компаниях, 30-500 человек, и это накладывает некоторый отпечаток на принимаемые решения.

    Итак, была поставлена задача как-то упорядочить все сетевые файловые ресурсы, которые были в компании. Для удобства, для системы, для учета, для надежности (нужное подчеркнуть).

    Не буду утомлять долгим описанием поисков и метаний, расскажу что родилось в конце, и какие плюсы из этого получились.

    Схема файлохранилища

    Сразу отказались от схемы \\servername\sharename. В домене AD подняли доменный DFS корень, который сам по себе лежит на нескольких серверах, для большей отказоустойчивости (2-3, если сайт один — то больше не надо, хуже будет).
    В DFS корне линками была построена система как на картинке:. Назначение папок запланировали такое:
    • Bases — тут складируются различные базы данных, с которыми работают в компании, причем это могут быть не обязательно 1С или подобные БД, но и файловые базы, например архив фотографий товара, которым торгует компания, архив видеоуроков и т.д. Доступ в эти папки раздается исключительно на основе групп в AD. Вообще доступ в папку (даже если это нужно одному человеку) лучше делать на основе группы, а не конкретного пользователя. Дальше будет проще управлять.
    • Common — тут находятся папки, доступ в которые назначается неоднозначно. Например сотрудники из разных отделов должны иметь общую папку для работы (финансисты и бухгалтера, продажи, склад и транспортники, и т.д.). Доступ к этим папкам опять-таки назначается на основе групп в AD
    • Users — тут лежат папки пользователей, например перенаправленные Мои Документы и Рабочие столы. Доступ только конкретному сотруднику.
    • Departments — тут все понятно. Есть отдел — у него есть папка для внутренних документов. Доступ только сотрудникам отдела, которые входят в группу этого отдела
    • Public — общая для всех папка. Доступ разрешен всем. Раз в день\неделю очищается. Для пущей сохранности можно перед очисткой делать бэкап (у нас скриптом WinRar загонял все содержимое в архив с удалением из места-источника)

    Наведение красоты

    Дальше когда определились со структурой, были сделаны ряд «допиливаний напильником»:
    • т.к. домен был уровня 2003 (и DFS соответственно тоже), то на все сервера которые хранили наши данные, скачали и поставили Access-based Enumeration, которая позволила скрывать от сотрудников те папки, доступ к которым у них нет, чтоб особо глаза не мозолили.
    • Все папки 1 уровня (кроме users) были сделаны вирутальными, т.е. реальными шарами были папки 2 уровня. Это позволило довольно гибко распределять нагрузку по серверам. Например 1С Базы могли лежать на одном сервере, а медиаархив — на другом, при этом путь для конечного пользователя оставался одинаковым.
    • Для папки Users сделали особые права (оставили права Creator owner для подпапок, а Domain users разрешили только создавать папки внутри Users и все.) и написали коротенький скрипт, который при входе пользователя проверял наличие ЕГО папки по пути \\domain\root\users\ и если не находил — то создавал ее там, называя по имени пользователя. После чего в эту папку политикой перенаправлялись рабочие столы и документы, а если перенаправление не требовалось (были такие) то просто мапил ее как сетевой диск. В результате у пользователя автоматически появлялось его место хранения, куда не мог попасть никто другой, и где он мог хранить свои данные.
    • С правами вообще поступали так: убирали все из ACL, кроме Domain Admins, Adm_FileStorage, Dep_Topmanagers, System плюс дополнительно созданные группы (например Dep_Finance, Dep_Sklad или там Com_Reklama_RW и т.д.). В некоторых ситуациях все же пришлось чуть повозиться, например в папке Common\INFO изьявили желание иметь свои каталоги ряд отделов, и соответственно им туда был дан RW доступ, а всем остальным только чтение
    • были введены квоты на объем данных, внутри Users. пробовали играться с FileScreening (запрет хранения данных по типам, например нельзя в папку класть *.mp3), но не прижилось, т.к. особой нужды не было.
    • В названиях папок использовали латинский алфавит и без пробелов (это упростит жизнь в дальнейшем, хоть скрипты писать хоть ссылки на файлы пересылать), группы в AD старались создавать относительно «говорящими», чтобы хотя бы примерно можно было понять зачем эта группа нужна.
    • Сами шары делали с $ в конце, и доступ пользователям в сеть (сетевые диски, пути настроек в программах и т.п.) назначали исключительно через DFS-пути

    В итоге система стала более менее структурированной, можно было разобраться где что лежит, как это все бэкапить, где чья зона ответственности, и частично даже исчезли многочисленные дубликаты, когда пользователям наконец сказали что где хранить. Вдобавок можно было не переживать за поломку какого либо сервера, данные восстанавливались из бэкапов, а сама структура оставалась, достаточно было только поправить линки на новый сервер в консоли DFS.

    Продолжение следует.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 37

      +2
      Какие серверы непосредственно хранят файловые ресурсы (железо, дисковая система, сетевые интерфейсы)?
      Какая-то СХД используется или всё на локальных дисках? Дисковые полки? RAID-массивы?

      Правильно ли я понимаю, что DFS у вас используется только для того, чтобы выстроить единое дерево из распределённых в сети SMB-шар? А резервирование путём дублирования данных на несколько серверов с DFS-репликацией между ними у вас не используется? Тема резервирования/кластеризации в статье не раскрыта.

      > оставили права Creator owner для подпапок

      Оставлять права по умолчанию Full control для Creator/Owner — это дурной тон. Обязательно среди юзеров найдётся какой-нибудь продвинутый умник, который полезет настраивать права на созданную им папку и выкинет оттуда вообще всех кроме себя. В итоге потом не пройдёт бэкап этой папки или скрипт по переносу данных на другой сервер споткнётся на этой папке.

      Вернуть права админы, разумеется, смогут, но это потерянное время и лишние заботы — лучше их себе не создавать и не давать юзерам полных прав никогда. Всегда раздавать юзерам права не выше Modify и только конкретным доменным группам (а на юзерские папки конкретным доменным юзерам). Creator/Owner вообще на самом верхнем уровне иерархии расшаренных папок удалить из ACL.

      Кстати, тема бэкапов в статье тоже не раскрыта.
        +4
        Каждый раз начиная пост, я понимаю, что можно писать и писать. И пост тогда будет километровой длины, скучным и нудным. Поэтому пытаюсь сокращать, выбирая ограниченные темы или вопросы. Отсюда видимо и куча ваших вопросов.
        По порядку:
        — перечисление железной составляющей на мой взгляд излишне, т.к. цель была рассказать про систему организации файлохранилища, именно логическую, структурную его часть. По части железа — это можно еще не одну простыню наваять.
        — DFS, вы правильно заметили, здесь используется только для структуризации данных. Для резервирования с репликацией, необходимо как минимум иметь еще столько же дискового места «про запас», а в данной компании с этим пока туговато. Резервирование средствами DFS я впервые попробовал уже на 2008 server, понравилось, и думаю посвятить этому отдельный пост. Там кстати ABDE интересно встроен на уровне самой DFS ну да вы наверняка и сами об этом знаете.
        — Creator Owner в ACL для Users мы оставили с одной единственной целью: ради предельно простого и автоматического создания сетевой папки для конкретного пользователя. Еще раз опишу механизм: на корневую папку (и только на нее, без наследования) у доменных пользователей есть права «Обзор папок\создание папок», и стоят права Creator Owner на все нижеследующие объекты, причем права уровня Write\Modify, а не FullControl. Логин скрипт от имени пользователя проверяет наличие папки вида %username%, если ее нет — то создает ее и монтирует в сетевой диск.
        В итоге пользователь на все нижележащее имеет нормальные права (не Full Control! а Write\Modify), а админы не парятся по поводу «создать папку для еще одного пользователя»

        В остальных корневых папках Creator Owner убран, и оставлены только нужные группы — я об этом писал.

        — по поводу бэкапа — это будет еще один пост, причем хочется коснуться именно системы, принципа бэкапа, которой я придерживаюсь, не расписывая прелести той или иной конкретной программы.
          0
          а опишите плиз как именно подключаете папку?
            0
            Можно чем то вроде вот такого скрипта:
            On Error Resume Next
            Set Network = WScript.CreateObject(«Wscript.network»)
            Set oShell = CreateObject(«Shell.Application»)
            Set FSO = CreateObject(«Scripting.FileSystemObject»)

            '==================================================
            'Создаем папку пользователю с именем его логина
            '==================================================
            UName = Network.UserName
            If Not fso.FolderExists("\\domain\root\Users\" & UName) Then
            Set objFolder = FSO.CreateFolder("\\domain\root\Users\" & UName)
            End If

            '==================================================
            'Подключаем диск и даем ему имя
            '==================================================
            Network.RemoveNetworkDrive «Z:»
            DiskPath = "\\domain\root\Users\" & UName
            Network.MapNetworkDrive «Z:», diskpath
            oShell.NameSpace(«z:\»).Self.Name = «UsersFolder»

            WScript.Quit
        +1
        «Все папки 1 уровня (кроме users) были сделаны вирутальными, т.е. реальными шарами были папки 2 уровня.» Поясните, пожалуйста, что Вы имели ввиду данной фразой? И как реализовали это?
          0
          Отвечу картинкой
          Это не рабочая среда, это просто пример. Здесь:
          root — корень DFS
          Department, Level1 — это виртуальные папки уровня 1 (т.е. они нигде не рсшарены, они есть только в структуре DFS)
          HR, Marketing, Level2 — это линки(ссылки) DFS, которые ссылаются на реальные сетевые папки. Это видно на примере папки marketing.

          таким образом система остается
          — структурированной (четко видно где что лежит. департаменты, пользовательские папки, общие папки и т.п.)
          — постоянной (например путь в каталог HR всегда будет вида \\domain\root\deprtment\HR) независимо от того на каком сервере эта папка находится.
          — гибкой (можно увеличить свободное пространство в папке Marketing, просто перенеся его на сервер с большими дисками и поправив линк в DFS, пользователи ничего не заметят)
          — централизованной (для изменения ее достаточно изменить линк в консоли DFS, дальше все автоматически, не нужно бегать по пользователям и менять им сетевые диски и заниматься подобной ерундой)

          Достаточно подробно и понятно?
            0
            Последний вопрос, а у вас ОС какая? Win2003 или Win2003R2?
              0
              Этот скриншот с 2003R2, но виртуальные папки вполне себе поддерживаются и в голом 2003. Достаточно при создании линка написать Department\HR и вуаля, у вас уже есть виртуальная папка Department в которой лежит линк на HR
        0
        Если не сложно ответьте на один вопрос по поводу DFS и репликации.
        Когда пробовали на 2003, получили большие странности с 1C, да и вообще с обычными документами. Создалось впечатление, что каждое подключение само выбирало откуда физически брать файлы или куда писать из двух подключенных сетевых шар. При чем при работе 1человека замечено не было, а когда пустили в бой сразу же посыпались жалобы. Типа только что файл сохранили, а теперь его нет. В 1С вообще магические вещи происходили.
          0
          Вероятно вы использовали DFS уровня 2003, в выпуске 2003 R2 служба DFS, была очень серьезно переработана, что сделало ее использование уже приемлемым. В компании где работаю я (500+ сотрудников) используется DFS для совместной работы пользователей в 7 офисах, которые находятся в разных странах. Могу сказать, что для документов которые реплицируются через VPN например в Аргентину могут быть серьезные задержки, поэтому приходится пользоваться прямыми ссылками. Если же два ваших сервера будут стоять в одном сайте, да еще и соединены по гигабиту скажем — то никаких серьезных проблем быть не должно. Кстати рекомендую очень полезную статью 10 causes of slow replication
            0
            Спасибо.
            И еще ньюанс второй сервер с DFS был 2000, после небольшого апгрейда дисковой был отведен в резерв как файлохранилище.
            +2
            Репликация в DFS это довольно своеобразная штука. По опыту могу сказать следующее:
            — DFS сама выбирает куда, на какую реплику послать запрос. Критерии выбора довольно туманны, возможно по скорости ответа сервера-хранилища.
            — Ни о каких кластерных технологиях тут речь не идет. DFS — это НЕ ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР!!! Основная цель репликации — это дублирование содержимого папки в другие места (например в филиалы, в другие отделы и т.д.)
            — по разным причинам репликация папок может задерживаться на некоторое время, т.е. происходить не моментально.

            Соответственно реплицировать любую используемую (не статическую) базу данных средствами DFS бессмысленно. Вы свою ситуацию описали очень точно: 1с-ка в один момент времени обращалась в одну реплику в другой момент времени — в другую. От чего и происходили разные веселые странности :)

            на мой взгляд вообще есть два реальных применения репликации DFS:
            1. репликация каких то общих, редко изменяемых папок в филиалы, другие отделы и т.п. (например в главном офисе есть папка с приказами\инструкциями\списками, эта папка реплицируется в удаленные филиалы. Соответственно когда в филиале обращаются по DFS пути, их автоматически пробрасывает на ближайшую реплику)
            2. своего рода онлайн-бэкап, без особых усилий. я сам в 2003 так не делал, а в 2008 — делал, получалась вполне рабочая схема. Это когда содержимое папки реплицируется, но одна из реплик, т.н. запасная, «выключается», т.е. DFS на нее не ссылается, а просто реплицирует туда данные как может и когда может, и все. В критический момент, когда основная шара упала (сломался сервер) вы в консоли DFS ВЫКЛючаете основную реплику, и ВКЛючаете запасную, и у пользователей становятся видны относительно свежие данные (состояние от 1-2 сек, до получаса назад).
              0
              Пользователь получает доступ к тому серверу, который находится в его сайте и который быстрее всего откликнулся на запрос.
              DFS можно и нужно использовать для отказоустойчивости. В случае падения одного сервера пользователи прозрачно перенаправляются на реплику, практически ничего не замечая.
                +2
                Вы точно уверены что БД стоит реплицировать средствами DFS в пределах одного сайта?
                Я бы лично не рекомендовал.
                Кроме того, насколько мне известно в механизме репликации DFS любой редакции нет способа выбрать какой документ «правильнее». по умолчанию принимается последний отредактированный. А это вполне может создать ситуацию, когда скажем два сотрудника открыли один документ, причем один на одной реплике, другой — на второй. Оба поработали, оба сохранили в разное время. После репликации останется только одна версия, так которая была изменена последней.
                Я все таки считаю, что отказоустойчивость лучше реализовывать кластерными технологиями, либо если уж есть только DFS то схемой с выключенной репликой (я чуть выше описал).
                  0
                  Вот-вот. От DFS в 2003 остались одни отрицательные впечатления, логика работы абсолютно непредсказуемая, синхронизация медленная.
                    0
                    БД — нет, не стоит :)
                    А ситуация которую вы описали с документами возможна если пользователи работают даже с одной реплики, так что две реплики тут не сильно что то меняют. У нас по семь реплик в семи офисах, люди работают — все нормально.
                      0
                      так и что делать в случае подобных конфликтов? Пользователи терпят пропажу своей работы?
                  0
                  > по разным причинам репликация папок может задерживаться на некоторое время,
                  > т.е. происходить не моментально.

                  Особенно когда юзеры понаоткрывают офисные документы из DFS-папок на редактирование и так и не закрывают их целый день или по несколько дней. Пока он его не закроет репликация этого заблокированного файла не начнётся.
                    +1
                    > DFS сама выбирает куда, на какую реплику послать запрос.

                    Некоторая настройка порядка выбора DFS-реплики там всё же есть:
                    — Random order (случайный выбор DFS-реплики).
                    — Lowest cost (перенаправлять запрос на наиболее близкую к клиенту DFS-реплику).
                    — Exclude targets outside of the client's site (перенаправлять запрос только на DFS-реплики внутри сайта клиента).
                  0
                  Описанная вами схема достаточно очевидная,
                  а за Windows Server 2003 Access-based Enumeration спасибо.
                    0
                    Спасибо, очень интересная и полезная статья.

                    Как вы смотрите на такой вариант для папок пользователей:
                    — папка пользователей хранится локально на компьютере;
                    — используется aerofs или что-то что обеспечивает синхронизацию с сервером.

                    Для чего это нужно:
                    — «дешевое» резервирование, если отказал файловый сервер то пользователь может продолжить работу, в том время как ИТ поднимает резервный сервер или восстанавливает работоспособность;
                    — отсуствие различных колизий при открытие файлов по сети;

                    Какие вижу проблемы:
                    — безопасность, нужно сделать так чтобы директория была с прозрачным шифрованием, а ключ для расшифровки использовался был бы паролем от входа (иначе для пользователя это будет несколько сложно).

                    Какие видите проблемы у этого варианта?
                      0
                      Проблема на мой взгляд только одна — я не знаю что такое aerofs :)

                      Возможно вы говорите про оффлайновые папки (так это, или очень похожее на это, называется в Windows), но если так, то мне лично оффлайновые папки не нравятся по многим причинам. При красивой на первый взгляд идее, они довольно тяжко реализованы, что по мере роста объемов данных приводит к тормозам, порче кэша, и прочим неприятностям. Нервирует.
                      дешевое резервирование можно реализовать с помощью DFS, я чуть выше писал про это в комментариях, и в одном из постов опишу подробнее. Там переключение будет не полностью автоматическим, но зато быстрым и глобальным, и данные будут лежать в сети.

                      Шифрование же — вещь обоюдоострая. По крайней мере не забывайте про агента восстановления (ну или как он называется, чтоб можно было восстановить, если пользователь забыл-пароль\потерял-ключ). В Windows-среде есть возможность использовать EFS, с сертификатами на уровне домена, что в принципе вы и описываете, но на практике в большинстве случаев достаточно грамотных NTFS прав.
                        0
                        aerofs.com — вещь интересная, пока в пре-альфе, но основную функцию синхронизирования p2p выполняет на 5 из 5. Могу дать инвайт.

                        Шифрование больше для мобильных клиентов, где большая вероятность что пользователь потеряет ноутбук.
                      0
                      Шары с включенным АВЕ быстро открываются? Какое количество файлов, папок в них?
                        0
                        Заметной разницы не увидел по отношению к шаре с выключенным ABE.
                        По числу папок-файлов рекордов думаю не было, честно говоря, даже не задавался этим вопросом. Общий объем данных колебался от 100 до 1200 гб, если это чем то поможет.
                          0
                          Общий объем не влияет. Количество файлов в папке, да, если верить документу. Хотя такую кучу надо еще умудриться накидать.
                        0
                        Интересует вопрос, про использование DFS с ноутбуками. Сталкивались ли вы с проблемами при использовании DFSс мобильными пользователями? Настраивали ли синхронизацию или всем пользователям можно подключаться по VPN откуда угодно?
                        Очень интересует этот вопрос. Количество мобильных устройств на фирмах растёт и что им делать «в поле», когда их документы перенаправляются на сервер не совсем понятно. Синхронизацию папок, вроде бы, советуют отключать при использовании DFS, а VPN тоже всем давать жирно.
                          0
                          DFS работает одинаково что на ноутбуках что на рабочих станциях. Я не вижу принципиальной разницы между ними. Главное — это чтобы они находились в одной среде, были доступны DNS сервера домена, файловые сервера и.тд.
                          Оффлайн синхронизацию я сколько раз делал — столько раз потом и плевался. Мне очень не нравится то что получается, то как оно реализовано, хотя идея в общем неплохая.
                          Вообще вопрос «что делать когда нотбуков много», это отдельный интересный вопрос, и боюсь своего рецепта я вам не дам, т.к. его нет. В моем опыте те организации, с которыми я работал, либо не использовали ноутбуки принципиально, либо не использовали на нотбуках перенаправления папок, оставляя все данные физически на ноутбуке. А если пользователю срочно было нужно то, чего у него нет на рабочем столе — то вопрос решался почтой. Как то так.
                          VPN всем — на мой взгляд тоже жирновато, хотя, конечно, все зависит от специфики организации, были компании где это практиковалось, и все были довольны.
                            0
                            Может быть имелась в виду схема имен?
                            т.е. по умолчанию DFS создается не-FQDN. После небольшой правки реестра, ресурсы DFS принудительно прописываются как FQDN. Например, \\company\ROOT -> \\company.local\ROOT.

                            Соответственно, снимается проблема разрешения «коротких» имен и доступа к ресурсам.

                            Автономные папки же, очень не рекомендуется включать с общими ресурсами. Но вот с папками пользователя (мои документы/рабочий стол) вкупе с их перенаправлением на сервер, получается весьма удобно для случаев порчи ноутов в поездках. Если этого не делать, возникает очень острый вопрос резервной копии данных юзера.
                          0
                          просто для файлов помоек с вами согласен, DFS и ваша древовидная структура оправдывается себя. Но для работы с для работы с документами между пользователями надо уже использовать SharePoint.
                            0
                            я бы (да думаю и не только я) с удовольствием почитали ваш про опыт работы с SharePoint. тема интересная. Напишите?
                            +1
                            могу попробовать написать, просто тема огромнейшая ))
                              0
                              разбивайте на главы, упрощайте, пишите только «самый сок» — главное пишите :)
                                0
                                пишите, пишите!
                                0
                                А как DFS работает с MacOSX?
                                  0
                                  в Lion поддерживается.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое