Dfs windows server 2008 r2 настройка
Обновлено: 06.07.2024
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) в свойствах каждой шары - эта технология позволяет скрыть от пользователя папки, к которым у него нет доступа. полезно по многим причинам - и не раздражаем пользователя кучей папок, в которые он не сможет зайти (у него будут видны только те папки, к которым у него есть доступ), и не выдаем какую-либо косвенную информацию (мало кого не насторожит папка "План сокращения персонала в три раза") и делает навигацию по файлопомойке удобнее.
В этой статье приводится ряд сведений о службе имен DFS и данных о ее конфигурации.
Применяется к: Windows Server 2012 R2, Windows 2008 R2 Пакет обновления 1
Исходный номер КБ: 977511
Сводка
Служба распределенной файловой системы (DFS) Namespaces хранит данные конфигурации в нескольких местах. Если некоторые из этих данных отсутствуют или недоступны, могут возникнуть сбои и не удается создать пространство имен.
Введение
В этой статье обсуждаются следующие темы, которые помогут вам создать пространство имен:
Дополнительная информация
Расположения конфигурации DFS Namespaces
В следующих расположениях хранятся различные данные конфигурации для пространств имен распределенной файловой системы (DFS):
Active Directory Domain Services (AD DS) хранит данные конфигурации пространства имен на основе домена в одном или более объектах с именами серверов пространства имен, целями папок и различными другими данными конфигурации.
Серверы пространства имен поддерживают акции для каждого хозяйского пространства имен.
Клавиши реестра на серверах пространства имен на основе домена хранят членство в пространстве имен.
На автономных серверах пространства имен ключи реестра хранят все данные конфигурации пространства имен.
Примеры того, как данные конфигурации DFS Namespaces могут стать несовместимыми
- Команда dfsutil/clean выполняется на сервере пространства имен на основе домена. Эта команда удаляет данные реестра пространства имен. Данные конфигурации, хранимые в AD DS, остаются и будут засвещены оснасткой MMC DFS Namespaces.
- Для восстановления пространства имен DFS, которое было удалено с помощью средства управления DFS, такого как оснастка MMC MMC DFS или средство Dfsutil.exe, выполняется авторитетное восстановление AD DS DS. Хотя восстановление AD DS может быть успешным, пространство имен не работает, если не будут восстановлены или восстановлены другие данные конфигурации DFS Namespaces.
- Восстановление состояния системы для сервера пространства имен с помощью резервного копирования, созданного до того, как сервер стал сервером пространства имен.
- Сбои репликации Active Directory мешают серверам пространства имен от размещения данных конфигурации DFS Namespaces.
- Неправильное изменение или неправильное удаление доли для пространства имен на сервере пространства имен.
- Ручная манипуляция с реестром или данными конфигурации пространства имен AD DS.
Очистка и удаление конфигурации DFS Namespaces
Данные конфигурации DFS Namespaces управляются и поддерживаются средствами управления, которые используют API DFS. API DFS уведомляют контроллеры домена Active Directory и серверы имен DFS об изменениях конфигурации. Это поведение не позволяет осиротеть данные конфигурации и гарантирует согласованность данных конфигурации. Если процесс уведомления блокируется, или если данные в противном случае удаляются или теряются, выполните указанные здесь действия по очистке, чтобы удалить данные конфигурации. Эти изменения не могут быть восстановлены, если вы не сделаете резервное копирование состояния системы для контроллера домена или сервера пространства имен.
Дополнительные сведения о том, как сделать системный сервер, работающий Windows Server 2003, можно найти на следующем веб-сайте Microsoft:
Следующие действия следует использовать только в том случае, если восстановление данных конфигурации невозможно или не требуется.
Дополнительные сведения о процессе восстановления пространства имен DFS нажмите на следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
969382 восстановления пространства имен DFS в Windows 2003 и 2008 гг.
Для пространства имен на основе домена DFS проверьте удаление данных конфигурации пространства имен AD DS. Перед процессом удаления необходимо точно определить объект, связанный с неисправным или несогласованным пространством имен. Чтобы удалить данные конфигурации пространства имен AD DS, выполните следующие действия:
Откройте средство Adsiedit.msc. Этот инструмент включен в Windows Server 2008 и требует установки роли или инструментов AD DS. Этот инструмент доступен в Windows Server 2003.
Дополнительные сведения о средстве Adsiedit.msc можно получить на следующем веб-сайте Майкрософт:
Найдите раздел домена домена, где размещено пространство имен на основе домена. Перемещение в следующее расположение:
CN=Dfs-Configuration, CN=System,DC= <domain DN>
<domain DN> Местообладатель — это отличительное имя домена.
Пространства имен DFS хранят объекты конфигурации в этом расположении. Пространства имен Windows 2000 Server имеют объект класса fTDfs, который называется одинаково с пространством имен. Пространства имен "Windows Server 2008" имеют объект класса msDFS-NamespaceAnchor, который называется одинаково с связанным пространством имен и может содержать дополнительные детские объекты для любых настроенных папок.
Выберите соответствующий объект, например объект "fTDfs" или "msDFS-NamespaceAnchor", а затем удалите его вместе с любыми детскими объектами.
Задержки репликации Active Directory могут оттянуть эту операцию изменения от распространения на удаленные контроллеры домена.
На всех серверах пространства имен, на которые размещено пространство имен, проверьте удаление данных конфигурации реестра имен DFS. Если на сервере находятся другие функционируют пространства имен, убедитесь, что будет удален ключ реестра только несогласованного пространства имен. Чтобы удалить данные конфигурации реестра имен DFS, выполните следующие действия:
В редакторе реестра найдите ключ реестра конфигурации пространства имен на соответствующем пути с помощью одного из следующих путей:
Доменная DFSN в режиме "Windows Server 2008"
HKEY_LOCAL_MACHINE \Software\Microsoft\Dfs\Roots\domainV2
Автономный DFSN
HKEY_LOCAL_MACHINE \Software\Microsoft\Dfs\Roots\Standalone
Доменная DFSN в режиме "Windows 2000 Server"
HKEY_LOCAL_MACHINE\Software\Microsoft\Dfs\Roots\Domain
Местообладатель имени сервера — это имя сервера, на которого размещено пространство имен, а местообладатель имен — корневой доли. Или удалите ключ вручную.
На сервере пространства имен перезапустите службу DFS в Windows Server 2003 или службу имен DFS в Windows Server 2008 для регистрации изменений в службе.
Удалите файл, связанный с пространством имен, с серверов пространства имен. Несоблюдение этого шага может привести к сбою в работе пространства имен, так как пространства имен DFS могут блокировать создание пространства имен.
Windows Server 2003
"Система не может перестать делиться < \ сервером и>, так как общая папка является корнем пространства имен распределенной файловой системы (DFS) "
Windows Server 2008
Система не может прекратить общий доступ к < \ серверу и>, так как общая папка — это корневой корневой раздел пространства имен распределенной файловой системы (DFS).
Изменение данных конфигурации пространства имен DFS следует рассматривать только после оценки всех других вариантов восстановления. Рекомендуется регулярно получать резервные копии системного состояния для серверов пространства имен DFS и контроллеров доменных имен на основе домена DFS. Эти резервные копии могут использоваться для восстановления конфигурации пространства имен до полной работы без риска несогласованного использования данных конфигурации пространства имен DFS.
MMC управления DFS (Dfsmgmt.msc)
На указанном сервере уже размещено пространство имен с этим именем. Выберите другое имя пространства имен или другой сервер для хозяйского пространства имен.
На сервере уже существует имя общей папки "пространство <servername> имен". Если используется существующая общая папка, параметр безопасности, указанный в диалоговом окне Edit Параметры, не будет применяться. Чтобы создать общую папку с этими настройками, сначала необходимо удалить существующую общую папку.
Пространство имен не является уникальным в домене, в котором был создан сервер пространства имен. Необходимо вернуться, чтобы выбрать новое имя пространства имен или изменить тип пространства имен на автономный.
Ошибка произошла при попытке удалить долю <namespacefolder> . Перед удалением долю необходимо удалить из распределенной файловой системы.
MMC распределенной файловой системы (Dfsgui.msc)
Указанный корень DFS не существует.
Корневой "namespace1" DFS уже существует. Укажи другое имя для нового корня DFS.
Следующая ошибка произошла при создании корневого сервера DFS на имени сервера: невозможно создать файл, когда этот файл уже существует.
Указанный корень DFS не существует.
Не удается найти указанный файл.
Dfsutil.exe
Произошла ошибка системы 1168. Элемент не найден.
Dfscmd.exe
Произошла ошибка системы 1168. Элемент не найден.
Произошла системная ошибка 80. Файл существует.
Произошла ошибка системы 2. Не удается найти указанный файл.
Клиенты DFS
Сведения о конфигурации не могут быть прочитаны с контроллера домена либо из-за недоступности компьютера, либо отказано в доступе.
В инструкции описан процесс настройки распределенной файловой системы и репликации данных в домене Active Directory на серверах под управлением Windows Server.
Что это такое?
Наличие общих каталогов для доступа к определенным документам и файлам является важной проблемой в бизнес-среде. Системным администраторам необходимо найти удобное решение для обмена общими данными.
Distributed File System (DFS) (Распределенная файловая система) - это продукт Microsoft для упрощенного доступа пользователей к географически распределенным файлам. DFS позволяет создавать деревья виртуальных каталогов, объединяющих общие папки по всей сети.
Существует два типа DFS:
- Namespace DFS (Пространство имен DFS) - виртуальное дерево, объединяющее общие папки из всей сети. Возможно настроить несколько пространств имен DFS.
- Replication DFS (Репликация DFS) - создает реплицированную общую папку и отслеживает изменения в файлах.
Установка
В нашем случае установка производится на контроллер домена.
Откройте панель управления сервером Windows и найдите Add roles and features (Добавить роли и компоненты).
В качестве типа установки укажите Role-based or feature-based installation (Установка ролей и компонентов).
Выберете ваш сервер из пула серверов.
В следующем окне отметьте DFS Namespaces и DFS Replication.
Затем установите выбранные компоненты.
Настройка пространства имен DFS
В меню Start выберете Windows Administrative Tools -> DFS Managment.
Или в поиске введите команду dfsmgmt.msc.
Для создания нового пространства имен выберете в правой части экрана New Namespace.
Введите название сервера.
В открывшемся окне необходимо настроить права доступа к пространству имен для пользователей сети. Чтобы предоставить полный доступ, нажмите кнопку Customize.
Выберете полный контроль с помощью галочек и нажмите Apply -> Ok.
На следующем шаге выберете Domain-based namespace, т.к. используются доменные службы Active Directory (AD DS).
Domain-based namespace - обладает преимуществами, позволяет обеспечить доступность пространства имен с помощью нескольких серверов пространств имен, скрывает имя сервера пространства имен от пользователей, упрощает замену сервера пространства имен или перенос пространства имен на другой сервер.
Stand-alone namespace - позволяет создать распределенную файловую систему не используя доменные службы Active Directory (AD DS), увеличивает доступность namespace с помощью отказоустойчивого кластера.
Проверьте конфигурацию и нажмите Create.
Добавление нового каталога в существующее пространство имен DFS
Чтобы создать каталог в созданном namespace, откройте DFS Management, выберете нужное пространство и справа в вертикальном меню нажмите New Folder.
Введите удобное имя каталога и нажмите Add, для того чтобы связать созданный каталог с сетевым каталогом на вашем сервере.
Примечание: каталог должен быть сетевым, это можно сделать в свойствах каталога на вкладке Sharing.
Введите имя сетевого каталога и кликнете OK.
Нажмите OK для сохранения изменений.
Подключиться к данному пространству с другого сервера можно набрав в проводнике следующий адрес:
\\<доменное имя>\<имя пространства имен>
Настройка DFS-репликации на Windows Server
Чтобы настроить репликацию данных необходимо иметь сетевую папку на другом, включенном в домен, сервере. Откройте DFS Management, выберете нужное пространство и справа в вертикальном меню кликните Add Folder Target.
Введите имя сетевого каталога и нажмите OK.
Откроется окно с вопросом о создании новой группы репликаций. Нажмите Yes.
Откроется настройщик Replication DFS. Проверьте имя группы репликации и каталога, который вы собираетесь реплицировать.
На следующем шаге проверьте пути сетевых директорий.
Выберете основной узел, с которого будет производиться первичная репликация данных.
В качестве типа топологии выбираем Full mesh - чтобы изменения на одном узле, сразу же появлялись и на остальных.
На последнем шаге необходимо настроить расписания реплицирования данных. В первом случае репликация производится моментально, во втором можно настроить удобное расписание.
Проверьте настройки и нажмите Create.
Откройте каталог, в который будет происходить первоначальная репликация данных и нажмите Continue. Произойдет первоначальная репликация данных.
На этом настройка распределенной файловой системы и репликации данных в ней закончена.
Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.
Слишком маленький размер квоты для промежуточной папки
Увидели в журнале много событий с кодом 4202 и 4204? В таком случае размер для промежуточной папки задан неверно. Неприятным последствием неправильно заданного размера промежуточной папки является снижение производительности репликации, так как вместо того, чтобы реплицировать файлы, служба будет тратить время на очистку промежуточной папки.
Серверы DFSR, для которых настроен достаточный размер промежуточной папки, работают более эффективно, как минимум, по двум причинам:
Не игнорируйте события журнала для промежуточной папки.
Ознакомьтесь с этим постом, в котором описано, как использовать метод определения минимального размера промежуточной папки.
Ознакомиться с разделом «Увеличение промежуточной квоты» можно здесь.
Для получения информации о cross-file RDC можно почитать статью «Сведения об удаленном разностном сжатии», размещенную здесь.
Некорректная или не оттестированная preseeding-процедура
Preseeding-процедура — это копирование данных, которые будут реплицированы на новый сервер-член репликации до их добавления в конечную папку этого сервера, с целью сокращения времени, необходимого для завершения первичной репликации. Большинство сбоев preseeding-процедуры, с которыми я сталкивался, были вызваны тремя причинами.
- Несоответствие ACL у источника и назначения.
- После копирования на новый член репликации в файлы вносились изменения.
- Не проводилось предварительного тестирования, чтобы проверить, что используемая preseeding-процедура работает так, как ожидается.
Щелкните здесь, чтобы прочитать блог мистера Пайла о том, как правильно организовать preseeding-процедуру ваших серверов DFSR.
Большой размер очереди копирования в течение долгого времени
Помимо того, что большая очередь копирования, существующая длительное время, означает, что ваши данные не синхронизированы, это может привести к нежелательному разрешению конфликтов, когда файл со старым содержимым выигрывает в сценарии разрешения конфликтов. Самый распространенный сценарий, при котором я сталкивался с подобным поведением, — это массовое добавление новых папок репликации. Вместо того, чтобы делать поэтапное развертывание, некоторые администраторы разом добавляли 20 новых папок для репликации из 20 разных филиалов, перегружая тем самым узловой сервер. Выполняйте развертывание поэтапно, чтобы первичная репликация завершалась за разумный промежуток времени.
DFSR используется в качестве решения для резервного копирования
Хотите верьте, хотите нет, но некоторые администраторы внедряют DFSR без автономных бэкапов реплицируемых данных. DFSR не был спроектирован как решение для резервного копирования. Одна из целей разработки DFSR — быть частью стратегии резервного копирования на предприятии, поскольку DFSR позволяет собрать ваши географически распределенные данные на централизованной площадке для последующего резервного копирования, восстановления и архивирования. С помощью нескольких членов репликации реализована защита от сбоя сервера, однако это не защитит вас от случайных удалений. Чтобы быть полностью защищенным, необходимо делать резервные копии своих данных.
Односторонняя репликация: ее использование и неверные методы исправления
В попытке предотвратить появление нежелательных обновлений на серверах, где никогда не будут изменяться данные, (или при желании предотвратить изменения на них) многие заказчики настраивали одностороннюю репликацию путем удаления исходящих подключений для членов репликации. Односторонняя репликация не поддерживается ни в одной из версий DFSR до Windows Server 2008 R2. В Windows 2008 R2 поддерживается односторонняя репликация, которая дает возможность настроить для реплицируемых папок режим «только для чтения».
Использование членов репликации в режиме «только для чтения» позволяет достичь цели односторонней репликации, которая предотвращает нежелательные изменения в реплицируемых данных. Если необходимо использовать одностороннюю репликацию с помощью DFSR, используйте Windows 2008 R2 и для тех членов, на которых не должны вноситься изменения, укажите режим «только для чтения».
Нажмите здесь и здесь, чтобы узнать о режиме репликации DFSR «только для чтения».
Узловой сервер как единая точка отказа и перегруженные узловые серверы
Рано или поздно у администраторов возникает ситуация, когда становится слишком много серверов в филиалах, настроенных на репликацию с единственным узловым сервером. Это может привести к задержкам в репликации. Понять, сколько серверных офисных серверов может обслуживать один узловой сервер, можно с помощью отслеживания очереди копирования. Не существует магической формулы, так как каждая среда уникальна и существует много зависимостей.
Прочтите раздел «Настройка топологии» здесь, чтобы узнать о развертывании узловых серверов.
Нажмите здесь, чтобы узнать, как настроить DFSR на отказоустойчивом кластере Windows Server 2008.
Слишком много папок для репликации на одну базу данных Jet
DFSR использует одну базу данных Jet на том. В результате размещение всех реплицируемых папок на одном томе приводит к размещению их всех в одной базе данных Jet. Если в этой базе возникнет проблема, требующая исправления или восстановления базы данных, то она затронет все реплицируемые папки на этом диске. [Прим. переводчика. очевидно, имеется в виду не диск (disk), а том (volume).] Правильнее будет использовать как можно больше дисков и распределить реплицируемые папки между ними, обеспечив тем самым максимальное время доступности данных.
Развертывания на основе бюджетных iSCSI-решений
Я не раз видел развертывания DFSR, где использовалось самое дешевое оборудование iSCSI. Обычно, если вы используете DFSR, то делаете это для достижения критически важных целей, таких как избыточность данных, консолидация резервных копий, доставка приложений и обновлений ОС по расписанию. Поставить себя в зависимость от низкокачественного оборудования, у которого нет нормальной поддержки от вендора, — не лучшая идея. Если для вашего бизнеса важны данные, значит, для него будет важным и оборудование, на котором работает ОС и механизм репликации.
Для службы DFSR не устанавливаются актуальные патчи
DFSR активно поддерживается корпорацией Майкрософт и для нее по мере необходимости выпускаются обновления. Обновляйте DFSR, если на момент вашего очередного цикла установки обновлений для нее есть новый релиз. Убедитесь, что ваши серверы обновлены согласно статьям базы знаний, перечисленным ниже.
Обратите внимание, что, помимо DFSR.EXE/DFSRS.EXE, перечисленные обновления предназначены также для NTFS.SYS и других файлов. Для корректной работы репликации всегда проверяйте, что самые последние версии патчей установлены как минимум для DFSR и NTFS. Другие исправления из списка в основном касаются проблем пользовательского интерфейса, и вам потребуется их установить хотя бы на тех системах, где выполняются задачи настройки DFSR.
Рекомендуется заблаговременно устанавливать патчи на сервера DFSR, даже если все работает нормально, так как впоследствии это поможет вам избежать появления уже известных проблем.
Не поддерживаются в актуальном состоянии драйверы сетевого адаптера
DFSR сможет работать нормально лишь в том случае, если сеть, которую вы ему предоставите, также работает без проблем. Использование драйверов 5-летней давности — не самое разумное решение. Я имел опыт общения с несколькими заказчиками, для которых проблемы с репликацией DFSR решились обновлением устаревшего NIC-драйвера.
Отсутствует мониторинг DFSR
Несмотря на то, что DFSR используется для перемещения, как правило, критически важных данных, многие админы не имеют представления о том, что делает DFSR, пока не столкнутся с проблемой. Те, кто понаходчивее, создают свои собственные скрипты для мониторинга очередей копирования на своих серверах, но большинство просто надеется на авось. Пакет управления для DFSR был выпущен почти год назад (а другие версии появились еще раньше). Установите его и используйте – и тогда вы сможете обнаружить проблемы и отреагировать на них до того, как они превратятся в кошмар. Если у вас нет возможности использовать пакет управления Operations Management для DFSR, то хотя бы напишите скрипт для отслеживания очереди копирования на ежедневной основе, чтобы понимать, реплицирует DFSR файлы или нет.
Нажмите здесь, чтобы получить информацию о пакете управления Operations Management для DFSR.
Обновлено 19 января 2011:
Внесение изменений в дисковое хранилище без предварительной архивации данных
Если на сервере DFSR требуется заменить жесткий диск или добавить новый для увеличения пространства хранения, крайне важно иметь актуальную резервную копию данных на случай, если что-то пойдет не так. Пойти не так может всё что угодно, чаще всего возникают события конфликтов из-за неожиданных изменений в родительской папке или случайного удаления родительской папки, которая реплицируется на всех партнеров. Необходимо создать резервную копию своих данных перед началом изменений и хранить ее до завершения проекта.
Остановка службы DFSR для временного прекращения репликации
Иногда возникает необходимость временно остановить репликацию. Правильный способ для этого – отключить репликацию для нужной группы с помощью расписания. Служба DFSR должна работать, чтобы иметь возможность читать обновления в журнале USN. Не останавливайте службу DFSR на длительный срок (дни, недели), так как это может привести к переполнению журнала (если за это время было изменено, добавлено или удалено много файлов). DFSR восстановится после переполнения журнала, но в больших развертываниях это займет много времени, и на время восстановления журнала репликация работать не будет или будет очень медленно. Также вы скорее всего будете наблюдать очень большие очереди копирования до тех пор, пока не завершится восстановление журнала.
Надеюсь, этот список вам поможет. Удачной репликации!
Уоррен “wide net” Уильямс
[Прим. переводчика. Если будет интерес читателей, постараюсь позже перевести статьи, размещенные по указанным в тексте ссылкам, а также другие статьи автора оригинала]
Читайте также: