Чем хорошо использование пространства имен DFS? Тем, что все ресурсы для пользователей лежат в одном едином каталоге, который не привязан к именам серверов и все вопросы касающиеся физического расположения файловых ресурсов не касаются пользователей. Для них путь до рабочей папки всегда остается неизменным. Еще DFS позволяет использовать репликацию данных между несколькими сетевыми папками и равномерное распределение пользователей между файловыми серверами.
Есть некая программа, которая использует базу данных и файловую папку. В базе – пути до файлов, файлы соответственно, в сетевой папке.
Папка суммарно размером более терабайта, файлов много. Файлы являют собой сжатый звук и иногда имеют не маленькие размеры.
Работа программы критична для функционирования бизнеса, а значит есть необходимость в организации определенного запаса прочности на случай отказа оборудования или программного обеспечения.
Отказоустойчивость базы данных достигнута посредством использования функционала Always On Availability Groups на MS SQL 2012.
Отказоустойчивость сетевой папки проще всего достигнуть посредством репликации папки средствами DFS.
Отдельно хочу заметить, что коренную папку пространства имен DFS (DFS root) тоже необходимо защитить от отказа. В Windows Server 2008 и выше это достигается без использования технологий кластеризации. Просто после создания корня, добавляем еще один сервер пространства имен. Например – два контроллера домена, они же серверы пространства имен DFS. В случае перезагрузки или поломки одного из них, пользователи продолжат пользоваться пространством имен DFS и ни чего не заметят.
И так, создаем коренную папку DFS. Создаем виртуальную структуру папок для отделов компании. В папках отделов создаем папки указывающие на конечные файловые ресурсы на файловых серверах.
Теперь переходим к настройке репликации DFS для нужной нам папки.
Для включения репликации нам нужно заранее установить на сервера где будет находиться папка, роль “Репликация DFS” (DFS replication) и Компонент “Удаленное разностное сжатие” (Remote Differential Compression).
Затем, заходим в MMC консоль “Управление DFS” (DFS Management), выбираем папку и запускаем мастер репликации:
Указываем сервер:
Папку назначения:
Создаем группу репликации:
Выбираем сервер с основной копией данных (это актуально на время первичной репликации):
Выбираем топологию (если сервера два, то вариантов нет):
Можем выбрать скорость репликации и расписание: 
Заканчиваем:
Теперь ждем завершения первичной синхронизации.
И так, репликация настроена, потираем руки и в течение суток получаем жалобу, что папки на серверах отличаются, а значит репликация не работает.
Тратим кучу времени на сравнение папок и копируем вручную отличающиеся куски информации.
Собственно поэтому не любят использовать репликацию DFS.
Всё произошло потому, что ни кто не читал руководство настройке DFS. Как я сказал, папка занимает около терабайта. Там множество файлов, с которыми работают пользователи посредством программы.
Репликация папки происходит путем использования скрытого каталога DfsrPrivate\Staging, а там задействован механизм квот. Квота кэша репликации (Staging Folder) или “Промежуточной квоты” по умолчанию равна 4 гигабайта, что катастрофически мало при объемах данных указанных выше. Потому не работает репликация.
Как повышать? Гадать не наш метод. Смотрим что пишут на Technet .
2003 сервер – Staging quota должна быть размером в девять самых больших файлов в папке репликации.
2008 и 2008 R2 – Staging quota должна быть размером в 32 самых больших файлов в папке репликации.
Тут нам поможет PowerShell.
Пишем команду (заменяем <путь> на путь до нужной папки):
“{0:N0}” -f((get-childitem <ПУТЬ> -recurse | sort-object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb)
Получаем суммарный объем 32-х самых больших файлов в гигабайтах, округленный до целого. Идем в настройки репликации:
Применяем. Как вариант, увеличиваем еще и квоту для конфликтов и удаленных файлов.
Не забываем повторить настройку для второго сервера.
P.S: В моём случае, DFSR оказалась не применима, так как приложение выбирает мастера из рабочих машин, где запущено, путём изменения определенного файла, который лежит в файловом хранилище, вместе с данными приложения. Файл обновляется чаще чем раз в секунду незначительной информацией. В файл пишется время и имя машины-мастера. В итоге файл обновляется одновременно на всех серверах и репликация его не проходит, так как DFSR не может определить какая версия файла правильная. В добавок несколько машин одновременно считают себя мастером операций, что приводит к проблемам в приложении.
Если бы разработчики придерживались идеи “сервер-свидетель” и вынесли файл на отдельный ресурс, не совмещая его с данными приложения, то смогли бы сэкономить десятикратно на упрощении аппаратной инфраструктуры.
В итоге придется держать папку с помощью MSFT-кластера или Fault Tolerance в VSphere.
Ну а теперь пост про одну из самых важных новых технологий в релизе Windows Server 2003 R2.
Как известно, администраторы файловых серверов тратят много усилий на синхронизацию Фазиловых серверов в организации. Какие только приемы не используются – от ручного копирования новых файлов или xcopy, до скриптов, которые выполняются по определенному расписанию.
Представьте, что есть возможность автоматизировать этот процесс, и сделать его более удобным для администратора. Звучит заманчиво, не так ли? В Windows Server R2, такая возможность есть – все это можно сделать с помощью DFS Replication.
DFS Replication позволяет синхронизировать реплицируемые файловые директории (replicated folders) между серверами, которые входят в репликационную группу (replication group). Серверы в репликационной группе связаны между собой соединениями (connections), так что существует путь между любыми двумя серверами.
Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания. Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась. Поэтому DFSR – это очень полезный инструмент для синхронизации данных между дата-центром компании и удаленными офисами в регионах.
К тому же репликация может происходить в удобное для организации время, чтобы не занимать сеть тогда, когда она нужна для других целей. Для этого можно устанавливать расписание синхронизации, и для каждого слота в расписании можно существовать лимит использования сети. Например: днем передавать данные со скоростью не более 128Кб/сек, а ночью передавать данные со скоростью 1Мб/сек.
DFSR это мульти-мастерная система репликации. Это означает, что реплицируемый файл может быть изменен на любой машине, и эти изменения будут распостранены на все машины, участвующие в репликации.
Одним из главных достоинств DFSR является компрессия данных при репликации. Используется два вида компрессии:
Обычное сжатие данных, похожее на то, которое применяется в архиваторах
Алгоритм дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации.
Кроме того, модификация алгоритма RDC, cross-file RDC, используется и для репликации различных файлов, похожих между собой. Например, если у нас есть текстовый документ, который получен путем изменения другого документа, то cross-file RDС перешлет по сети ссылку на исходный файл вместе с информацией о различиях между файлами.
Таким образом, во многих ситуациях DFSR дает значительную экономию сетевого трафика, по сравнению с обычным копированием, за счет выигрыша от компрессии данных.
Хотя в названии технологии DFSR присутствует упоминание распределенной файловой системы, репликация может использоваться и без добавления реплицируемых директорий в пространство имен какого-либо DFS корня. Однако в большинстве случаев, DFSR используется вместе с пространством имен DFS. Это позволяет обеспечить прозрачный доступ к файловым ресурсам и безотказную работу (так как если один из серверов становится недоступным, то пользователь будет автоматически перенаправлен на другой сервер).
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\" соответственно.
Набор альтернативных общих ресурсов, связанных с одним логическим именем DFS, называется набором реплик. В зависимости от того, в каких условиях работает распределенная файловая система, синхронизация реплик в наборе осуществляется различными методами. Распределенная файловая система сама не пытается проанализировать, отличаются ли данные, находящиеся на различных репликах. Их идентичность должна быть достигнута с помощью сторонних средств. Если альтернативные общие ресурсы созданы в файловой структуре с автономным корнем DFS, автоматическая репликация становится невозможна. В этом случае синхронизация данных между членами набора реплик должна выполняться вручную. Если альтернативные общие ресурсы находятся в пространстве имен доменного корня DFS и располагаются на серверах Windows 2000 или Windows Server 2003, то для них можно настроить автоматическую синхронизацию (репликацию) информации.
Для того чтобы настроить репликацию между альтернативными ресурсами (репликами), связанными с доменным корнем или ссылками DFS:
Рис. 8.33. Окно настройки репликации альтернативных общих ресурсов
2. Нажав кнопку Customize, вы сможете перейти в окно настройки топологии репликации, где можно управлять соединениями между серверами и их приоритетами.
3. Кнопка Schedule позволяет открыть окно, в котором указывается время репликации. По умолчанию репликация разрешена круглосуточно 7 дней в неделю.
4. В поле File filter перечислены (групповые) имена файлов, которые исключены из процесса репликации. Нажав кнопку
Edit, можно изменить этот перечень.
5. В поле Subfolder filter перечислены папки, не участвующие в репликации. Если вам нужно запретить репликацию для каких-то папок, нажмите кнопку
Edit и введите нужные имена.
По завершении конфигурации репликации данные, находящиеся на общих ресурсах, входящих в набор реплик, будут периодически синхронизироваться. По умолчанию период синхронизации равен 15 мин. Настроив репликацию, можно проверить ее текущее состояние с помощью команды
Check status из контекстного меню. Результат проверки может зафиксировать одно из трех состояний:
- процесс репликации завершен нормально - на значке ссылки DFS и на значках реплик появятся зеленые галочки (см. рис. 8.31);
- реплика недоступна - около имени реплики появляется крестик в красном кружке (статус - Offline) (рис. 8.34);
- некоторые альтернативные реплики проверяемой ссылки недоступны - на значке ссылки DFS появляется характерный восклицательный знак в желтом треугольнике.
