11 ноября 2013 г.

Настройка DFS (Distributed File System) и репликации в Windows Server 2008. FAQ


Q зачем нужна DFS?
A для организации единого структурированного отказоустойчивого файлопомоечного пространства в организации. вместо зоопарка непонятных шар
и дисков имеем единый корень (который можно мапить пользователям как диск, например), в котором мы можем создавать удобную нам структуру в виде виртуальных папок (хоть вложенных, хоть вперемешку с реальными), к которым, в удобном нам виде, мы и цепляем сетевые шары, физически расположенные на разных серверах. люди, человеки, один сетевой диск - это пипец как удобно по сравнению с колхозом, что есть у большинства!

Q интегрировать ли пространство имен в Active Directory (Domain Based DFS Namespace) или использовать автономные (stand-alone DFS namespace)?
A интегрированное пространство имен DFS хранится в AD (бэкапится, соответственно, "за компанию". вы ведь делаете резервные копии Active Directory? ;) и позволяет иметь несколько namespace серверов, т.е. имеет встроенный механизм отказоустойчивости (fault tolerance). Stand Alone DFS NS встроенных механизмов не имеет (отказоустойчивость в них достигается с помощью использования кластеризации). Microsoft рекомендует использовать domain based DSF в случае, если количество линков (виртуальных папок) не больше 5,000. Stand Alone DFS же рекомендуют ограничивать 50,000 линков. это не жесткое ограничение, это рекомендации (после превышения цифры, вроде как должна начать падать производительность). т.е. в итоге получаем, что stand alone выгодно использовать в маленькой сети, например, если нет AD или, наоборот, в случае экстремально большой файлопомойки, в остальных же случаях выгоднее использовать интегрированное пространство имен DFS.
PS: еще некоторые несознательные буржуи пишут "Standalone DFS root do not have any DFS shared folders in the root level and only one level of DFS link is possible", но я не совсем понимаю что это означает.

Q какие механизмы отказоустойчивости в domain based DFS?
A информация корня DFS хранится в Active Directory (в случае, если у вас нескольких контроллеров домена резервирование получается и тут) и реплицируется на серверы пространств имен DFS (которых тоже может быть много). линки (вируальные папки, которые вы создаете в DFS Root и к которым монтируете физические шары) могут иметь несколько (не обязательно 2, можно и больше) источников-шар, данные в которых реплицируются между собой.

Q что такое репликация DFS и какая она бывает
A механизм синхронизации содержимого нескольких источников DFS.
бывает: FRS (File Replication Service) - обычная репликация ;)
DFSR (Distributed File System Replication) - модная репликация, появившаяся в Windows Server 2003R2 и 2008. использует RDC (разностное сжатие, т.е. передается только изменения в файле, а не изменившийся файл целиком, как это было в FRS. в общем, для наших дохлых каналов очень полезная штука). замечу, что репликация DFS асинхронная, т.е. некоторое время источники не согласованы.

Q на что нужно обратить внимание после развертывания DFS
A на расположение и безопасность папки DFSRPrivate в каждом источнике (служит для хранения реплицируемой информации, удаленных и конфликтных с точки зрения репликации файлов). по умолчанию хранится в самой папке-источнике с правами, наследуемыми "сверху" (вообще странно, на technet'е написано, что только администраторы будут иметь доступ. может в 2008R2 что-то поправили). если у вас в пределах папки-источника права безопасности разные (что само по себе с точки зрения архитектуры файлопомойки несколько коряво), то люди могут получить доступ туда, куда не надо. плюс, шаловливые ручонки кулибиных радости не добавят.

Q что за папка "DFSRPrivate\Staging" и как правильно выбрать ее размер?
A это папка, где хранятся временные копии файлов для репликации, через которую они, по сути, передаются. есть во всех источниках. размер, хотя бы на время первичной репликации, лучше выставить чуть больше размера максимального встречающегося файла в реплицируемой папке (если у вас нет экстремалов, хранящих гигазы вареза одним терабайтным архивом, конечно). важно: файл, больший по размеру, чем Staging-папка нормально реплицируется и нигде не застрянет, как думают некоторые, просто процесс репликации пройдет в несколько этапов (файл будет резаться на несколько частей и передаваться по частям), что несколько замедлит процесс.

Q что за папка "DFSRPrivate\Conflict and Deleted"
A так как одновременно несколько пользователей могут изменить один и тот же файл, работает принцип "кто последний записал файл, того и тапки". файл-неудачник отправляется в эту папку, а в ConflictandDeletedManifest.xml появится соответствующая запись. так же, при наличии галки "хранить удаленные файлы в папке конфликтов" там будут храниться файлы удаленные пользователями  (очень удобно восстанавливать). так что на размер я бы не скупился.

Q какие основные проблемы с репликацией DFS?
A Большинство проблем с репликацией DFS у меня возникали из-за File Screening (ограничение на разрешенные расширения файлов) и Disk Quotas (ограничение на размер папки). особенно в случае первичной репликации. с дисковыми квотами всё понятно, за ними надо следить (учитывая что директория DFSRPrivate вместе со "Staging" и "Conflict and Deleted" по умолчанию находится в самой папке источнике), то с File Screening полный гемор - нужно или выносить папку DFSRPrivate в место, где нет ограничений (что не удобно) или пытаться делать исключения на папки "DFSRPrivate" (а она скрытая. гыгы) или временно отключать запреты (в первичном источнике тоже! иначе файл не попадет в Staging на источнике и не реплицируется) или удалять все файлы пользователей, попадающие под запрещающие фильтры (напомню, что файл скрининг запрещает только создание новых файлов определенных расширений, а не их наличие. т.е. если файлы уже есть и мы включаем запрещающие правила в screening, то файлы, подпадающие под фильтры, нельзя создать-изменять, но можно читать-удалять. вот мы и получим при попытке репликации ошибку, когда служба попытается записать в папку Staging запрещенный реплицируемый файл, file screening ругнется ошибкой "нет места на диске", на чем вся репликация и встанет).

Q где хранятся подробные логи репликации?
A кроме eventlog'a в %windir%\debug\DFSR*.log.gz - архивные, и %windir%\debug\DFSR*.log - актуальный.

Q Какие есть тонкости в работе DFS?
A1 хотя и допускается монтировать одно пространство имен, как папку в другое пространстве имен, на практике при монтировании stand alone DFS Windows Server 2003 в папку другого, интегрированного в AD DFS Windows Server 2008, сей авангардизм приводил к BSOD'у при заходе в такую папку с компа с Windows XP ;) видимо, буржуи имели в виду, что можно сращивать только разные domain based DFS namespaces.
A2 когда выпадает первичный из источников папки в DFS, при заходе на него с Windows XP происходит задержка, равная времени кэширования структуры DFS (по дефолту 300 секунд, насколько я помню). если зайти с Windows Vista/7/2008, то задержки нет. как пишут буржуи, связанно с переписанными в новых windows'ах сетевых протоколах. так что полноценный auto failover, при наличии клиентов XP, не получится, нужно пользоваться немножко другими средствами или отключать источники вручную (например, на случай плановой остановки одного из серверов).
A3 так как репликация в DFS асинхронная, какие-либо базы данных держать в папке с двумя и более реплицируемыми источниками не стОит. в момент перехода между источниками она рассинхронизируется.

Q что бы еще такого сделать с DFS?
A включить ABE (Access Based Enumeration) в свойствах каждой шары - эта технология позволяет скрыть от пользователя папки, к которым у него нет доступа. полезно по многим причинам - и не раздражаем пользователя кучей папок, в которые он не сможет зайти (у него будут видны только те папки, к которым у него есть доступ), и не выдаем какую-либо косвенную информацию (мало кого не насторожит папка "План сокращения персонала в три раза") и делает навигацию по файлопомойке удобнее.

Q как вообще войти в DFS после создания? ;)
A в случае Doman Based DFS Namespace - "\\DomainName\DFSRootName" в адресной строке Explorer'a, в случае Stand Alone - как в обычную шару - "\\ServerName\DFSRootName". мапить можно как обычную шару - "net use Z: \\DOMAIN.Local\MyCoolDFS\" и "net use Z: \\Server\MyCoolDFS\" соответственно.

Подробнее

Ярлыки: