Продолжаем цикл постов об «опытных мелочах». Предыдущие части можно почитать тут: раз, два.
Сегодня я расскажу как я выстраивал более-менее стройную систему внутреннего файлохранилища для компании и что из этого вышло.
Напомню, для тех кто забыл, что речь в моем случае идет о небольших компаниях, 30-500 человек, и это накладывает некоторый отпечаток на принимаемые решения.
Итак, была поставлена задача как-то упорядочить все сетевые файловые ресурсы, которые были в компании. Для удобства, для системы, для учета, для надежности (нужное подчеркнуть).
Не буду утомлять долгим описанием поисков и метаний, расскажу что родилось в конце, и какие плюсы из этого получились.
Сразу отказались от схемы \\servername\sharename. В домене AD подняли доменный DFS корень, который сам по себе лежит на нескольких серверах, для большей отказоустойчивости (2-3, если сайт один — то больше не надо, хуже будет).
В DFS корне линками была построена система как на картинке:
. Назначение папок запланировали такое:
Дальше когда определились со структурой, были сделаны ряд «допиливаний напильником»:
В итоге система стала более менее структурированной, можно было разобраться где что лежит, как это все бэкапить, где чья зона ответственности, и частично даже исчезли многочисленные дубликаты, когда пользователям наконец сказали что где хранить. Вдобавок можно было не переживать за поломку какого либо сервера, данные восстанавливались из бэкапов, а сама структура оставалась, достаточно было только поправить линки на новый сервер в консоли DFS.
Продолжение следует.
Сегодня я расскажу как я выстраивал более-менее стройную систему внутреннего файлохранилища для компании и что из этого вышло.
Напомню, для тех кто забыл, что речь в моем случае идет о небольших компаниях, 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.
Продолжение следует.