[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]
Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.
Увидели в журнале много событий с кодом 4202 и 4204? В таком случае размер для промежуточной папки задан неверно. Неприятным последствием неправильно заданного размера промежуточной папки является снижение производительности репликации, так как вместо того, чтобы реплицировать файлы, служба будет тратить время на очистку промежуточной папки.
Серверы DFSR, для которых настроен достаточный размер промежуточной папки, работают более эффективно, как минимум, по двум причинам:
Неверно настроенный размер для промежуточной папки также может привести к возникновению «петли» репликации. Это случается, если реплицируемый файл уже был скопирован в промежуточную папку на принимающем сервере, но механизм очистки промежуточной папки удаляет этот файл до того, как он успеет переместиться в целевую папку. Удаленный файл будет снова реплицирован на сервер и снова будет удален этим сервером из промежуточной папки, в результате чего сервер никогда не сможет принять файл. Этот процесс будет повторяться до тех пор, пока сервер не примет файл.
Не игнорируйте события журнала для промежуточной папки.
Ознакомьтесь с этим постом, в котором описано, как использовать метод определения минимального размера промежуточной папки.
Ознакомиться с разделом «Увеличение промежуточной квоты» можно здесь.
Для получения информации о cross-file RDC можно почитать статью «Сведения об удаленном разностном сжатии», размещенную здесь.
Preseeding-процедура — это копирование данных, которые будут реплицированы на новый сервер-член репликации до их добавления в конечную папку этого сервера, с целью сокращения времени, необходимого для завершения первичной репликации. Большинство сбоев preseeding-процедуры, с которыми я сталкивался, были вызваны тремя причинами.
Если кратко, то файлы должны быть скопированы определенным образом, и их нельзя изменять после того, как они были скопированы в промежуточную папку, а также весь процесс должен быть вами предварительно протестирован.
Щелкните здесь, чтобы прочитать блог мистера Пайла о том, как правильно организовать preseeding-процедуру ваших серверов DFSR.
Помимо того, что большая очередь копирования, существующая длительное время, означает, что ваши данные не синхронизированы, это может привести к нежелательному разрешению конфликтов, когда файл со старым содержимым выигрывает в сценарии разрешения конфликтов. Самый распространенный сценарий, при котором я сталкивался с подобным поведением, — это массовое добавление новых папок репликации. Вместо того, чтобы делать поэтапное развертывание, некоторые администраторы разом добавляли 20 новых папок для репликации из 20 разных филиалов, перегружая тем самым узловой сервер. Выполняйте развертывание поэтапно, чтобы первичная репликация завершалась за разумный промежуток времени.
Хотите верьте, хотите нет, но некоторые администраторы внедряют DFSR без автономных бэкапов реплицируемых данных. DFSR не был спроектирован как решение для резервного копирования. Одна из целей разработки DFSR — быть частью стратегии резервного копирования на предприятии, поскольку DFSR позволяет собрать ваши географически распределенные данные на централизованной площадке для последующего резервного копирования, восстановления и архивирования. С помощью нескольких членов репликации реализована защита от сбоя сервера, однако это не защитит вас от случайных удалений. Чтобы быть полностью защищенным, необходимо делать резервные копии своих данных.
В попытке предотвратить появление нежелательных обновлений на серверах, где никогда не будут изменяться данные, (или при желании предотвратить изменения на них) многие заказчики настраивали одностороннюю репликацию путем удаления исходящих подключений для членов репликации. Односторонняя репликация не поддерживается ни в одной из версий DFSR до Windows Server 2008 R2. В Windows 2008 R2 поддерживается односторонняя репликация, которая дает возможность настроить для реплицируемых папок режим «только для чтения».
Использование членов репликации в режиме «только для чтения» позволяет достичь цели односторонней репликации, которая предотвращает нежелательные изменения в реплицируемых данных. Если необходимо использовать одностороннюю репликацию с помощью DFSR, используйте Windows 2008 R2 и для тех членов, на которых не должны вноситься изменения, укажите режим «только для чтения».
Нажмите здесь и здесь, чтобы узнать о режиме репликации DFSR «только для чтения».
Еще одна распространенная проблема возникает тогда, когда администратор обнаруживает, что односторонняя репликация не поддерживается, и пытается исправить ситуацию, но делает это не так, как надо. Простое включение двухсторонней репликации обратно может иметь нежелательные результаты.
Нажмите здесь, чтобы узнать, как исправить проблему односторонней репликации.
Я видел много развертываний с единственным узловым сервером. Если этот узловой сервер выйдет из строя, то риску подвергнется все развертывание. Если вы используете Windows Server 2003 или 2008, у вас должно быть не менее двух узловых серверов, и если один из них выйдет из строя, то другой должен справиться с нагрузкой на время восстановления первого с минимальным влиянием на конечных пользователей. Начиная с Windows Server 2008 R2, можно развернуть DFSR на отказоустойчивом кластере Windows, что обеспечит высокую доступность при уменьшенной вдвое потребности в хранилище.
Рано или поздно у администраторов возникает ситуация, когда становится слишком много серверов в филиалах, настроенных на репликацию с единственным узловым сервером. Это может привести к задержкам в репликации. Понять, сколько серверных офисных серверов может обслуживать один узловой сервер, можно с помощью отслеживания очереди копирования. Не существует магической формулы, так как каждая среда уникальна и существует много зависимостей.
Прочтите раздел «Настройка топологии» здесь, чтобы узнать о развертывании узловых серверов.
Нажмите здесь, чтобы узнать, как настроить DFSR на отказоустойчивом кластере Windows Server 2008.
DFSR использует одну базу данных Jet на том. В результате размещение всех реплицируемых папок на одном томе приводит к размещению их всех в одной базе данных Jet. Если в этой базе возникнет проблема, требующая исправления или восстановления базы данных, то она затронет все реплицируемые папки на этом диске. [Прим. переводчика. очевидно, имеется в виду не диск (disk), а том (volume).] Правильнее будет использовать как можно больше дисков и распределить реплицируемые папки между ними, обеспечив тем самым максимальное время доступности данных.
Я не раз видел развертывания DFSR, где использовалось самое дешевое оборудование iSCSI. Обычно, если вы используете DFSR, то делаете это для достижения критически важных целей, таких как избыточность данных, консолидация резервных копий, доставка приложений и обновлений ОС по расписанию. Поставить себя в зависимость от низкокачественного оборудования, у которого нет нормальной поддержки от вендора, — не лучшая идея. Если для вашего бизнеса важны данные, значит, для него будет важным и оборудование, на котором работает ОС и механизм репликации.
DFSR активно поддерживается корпорацией Майкрософт и для нее по мере необходимости выпускаются обновления. Обновляйте DFSR, если на момент вашего очередного цикла установки обновлений для нее есть новый релиз. Убедитесь, что ваши серверы обновлены согласно статьям базы знаний, перечисленным ниже.
Исправления DFSR для Windows 2003 R2
Исправления DFSR для Windows 2008 и Windows 2008 R2
Обратите внимание, что, помимо DFSR.EXE/DFSRS.EXE, перечисленные обновления предназначены также для NTFS.SYS и других файлов. Для корректной работы репликации всегда проверяйте, что самые последние версии патчей установлены как минимум для DFSR и NTFS. Другие исправления из списка в основном касаются проблем пользовательского интерфейса, и вам потребуется их установить хотя бы на тех системах, где выполняются задачи настройки DFSR.
Рекомендуется заблаговременно устанавливать патчи на сервера DFSR, даже если все работает нормально, так как впоследствии это поможет вам избежать появления уже известных проблем.
DFSR сможет работать нормально лишь в том случае, если сеть, которую вы ему предоставите, также работает без проблем. Использование драйверов 5-летней давности — не самое разумное решение. Я имел опыт общения с несколькими заказчиками, для которых проблемы с репликацией DFSR решились обновлением устаревшего NIC-драйвера.
Несмотря на то, что DFSR используется для перемещения, как правило, критически важных данных, многие админы не имеют представления о том, что делает DFSR, пока не столкнутся с проблемой. Те, кто понаходчивее, создают свои собственные скрипты для мониторинга очередей копирования на своих серверах, но большинство просто надеется на авось. Пакет управления для DFSR был выпущен почти год назад (а другие версии появились еще раньше). Установите его и используйте – и тогда вы сможете обнаружить проблемы и отреагировать на них до того, как они превратятся в кошмар. Если у вас нет возможности использовать пакет управления Operations Management для DFSR, то хотя бы напишите скрипт для отслеживания очереди копирования на ежедневной основе, чтобы понимать, реплицирует DFSR файлы или нет.
Нажмите здесь, чтобы получить информацию о пакете управления Operations Management для DFSR.
Обновлено 19 января 2011:
Если на сервере DFSR требуется заменить жесткий диск или добавить новый для увеличения пространства хранения, крайне важно иметь актуальную резервную копию данных на случай, если что-то пойдет не так. Пойти не так может всё что угодно, чаще всего возникают события конфликтов из-за неожиданных изменений в родительской папке или случайного удаления родительской папки, которая реплицируется на всех партнеров. Необходимо создать резервную копию своих данных перед началом изменений и хранить ее до завершения проекта.
Иногда возникает необходимость временно остановить репликацию. Правильный способ для этого – отключить репликацию для нужной группы с помощью расписания. Служба DFSR должна работать, чтобы иметь возможность читать обновления в журнале USN. Не останавливайте службу DFSR на длительный срок (дни, недели), так как это может привести к переполнению журнала (если за это время было изменено, добавлено или удалено много файлов). DFSR восстановится после переполнения журнала, но в больших развертываниях это займет много времени, и на время восстановления журнала репликация работать не будет или будет очень медленно. Также вы скорее всего будете наблюдать очень большие очереди копирования до тех пор, пока не завершится восстановление журнала.
Надеюсь, этот список вам поможет. Удачной репликации!
Уоррен “wide net” Уильямс
[Прим. переводчика. Если будет интерес читателей, постараюсь позже перевести статьи, размещенные по указанным в тексте ссылкам, а также другие статьи автора оригинала]
Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.
Слишком маленький размер квоты для промежуточной папки
Увидели в журнале много событий с кодом 4202 и 4204? В таком случае размер для промежуточной папки задан неверно. Неприятным последствием неправильно заданного размера промежуточной папки является снижение производительности репликации, так как вместо того, чтобы реплицировать файлы, служба будет тратить время на очистку промежуточной папки.
Серверы DFSR, для которых настроен достаточный размер промежуточной папки, работают более эффективно, как минимум, по двум причинам:
- Гораздо эффективнее лишь единожды поместить файл в промежуточную папку, после чего отправить его всем принимающим партнерам по репликации, чем создавать файл, реплицировать его, а затем удалять его копию для каждого принимающего партнера.
- Если хотя бы на одном члене установлена Enterprise-редакция операционной системы, серверы могут использовать технологию cross-file RDC [прим. переводчика: начиная с Windows Server 2012, данная технология доступна и в Standard-редакции]
Неверно настроенный размер для промежуточной папки также может привести к возникновению «петли» репликации. Это случается, если реплицируемый файл уже был скопирован в промежуточную папку на принимающем сервере, но механизм очистки промежуточной папки удаляет этот файл до того, как он успеет переместиться в целевую папку. Удаленный файл будет снова реплицирован на сервер и снова будет удален этим сервером из промежуточной папки, в результате чего сервер никогда не сможет принять файл. Этот процесс будет повторяться до тех пор, пока сервер не примет файл.
Не игнорируйте события журнала для промежуточной папки.
Ознакомьтесь с этим постом, в котором описано, как использовать метод определения минимального размера промежуточной папки.
Ознакомиться с разделом «Увеличение промежуточной квоты» можно здесь.
Для получения информации о 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 «только для чтения».
Еще одна распространенная проблема возникает тогда, когда администратор обнаруживает, что односторонняя репликация не поддерживается, и пытается исправить ситуацию, но делает это не так, как надо. Простое включение двухсторонней репликации обратно может иметь нежелательные результаты.
Нажмите здесь, чтобы узнать, как исправить проблему односторонней репликации.
Узловой сервер как единая точка отказа и перегруженные узловые серверы
Я видел много развертываний с единственным узловым сервером. Если этот узловой сервер выйдет из строя, то риску подвергнется все развертывание. Если вы используете Windows Server 2003 или 2008, у вас должно быть не менее двух узловых серверов, и если один из них выйдет из строя, то другой должен справиться с нагрузкой на время восстановления первого с минимальным влиянием на конечных пользователей. Начиная с Windows Server 2008 R2, можно развернуть DFSR на отказоустойчивом кластере Windows, что обеспечит высокую доступность при уменьшенной вдвое потребности в хранилище.
Рано или поздно у администраторов возникает ситуация, когда становится слишком много серверов в филиалах, настроенных на репликацию с единственным узловым сервером. Это может привести к задержкам в репликации. Понять, сколько серверных офисных серверов может обслуживать один узловой сервер, можно с помощью отслеживания очереди копирования. Не существует магической формулы, так как каждая среда уникальна и существует много зависимостей.
Прочтите раздел «Настройка топологии» здесь, чтобы узнать о развертывании узловых серверов.
Нажмите здесь, чтобы узнать, как настроить DFSR на отказоустойчивом кластере Windows Server 2008.
Слишком много папок для репликации на одну базу данных Jet
DFSR использует одну базу данных Jet на том. В результате размещение всех реплицируемых папок на одном томе приводит к размещению их всех в одной базе данных Jet. Если в этой базе возникнет проблема, требующая исправления или восстановления базы данных, то она затронет все реплицируемые папки на этом диске. [Прим. переводчика. очевидно, имеется в виду не диск (disk), а том (volume).] Правильнее будет использовать как можно больше дисков и распределить реплицируемые папки между ними, обеспечив тем самым максимальное время доступности данных.
Развертывания на основе бюджетных iSCSI-решений
Я не раз видел развертывания DFSR, где использовалось самое дешевое оборудование iSCSI. Обычно, если вы используете DFSR, то делаете это для достижения критически важных целей, таких как избыточность данных, консолидация резервных копий, доставка приложений и обновлений ОС по расписанию. Поставить себя в зависимость от низкокачественного оборудования, у которого нет нормальной поддержки от вендора, — не лучшая идея. Если для вашего бизнеса важны данные, значит, для него будет важным и оборудование, на котором работает ОС и механизм репликации.
Для службы DFSR не устанавливаются актуальные патчи
DFSR активно поддерживается корпорацией Майкрософт и для нее по мере необходимости выпускаются обновления. Обновляйте DFSR, если на момент вашего очередного цикла установки обновлений для нее есть новый релиз. Убедитесь, что ваши серверы обновлены согласно статьям базы знаний, перечисленным ниже.
Исправления DFSR для Windows 2003 R2
Исправления DFSR для Windows 2008 и Windows 2008 R2
Обратите внимание, что, помимо 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” Уильямс
[Прим. переводчика. Если будет интерес читателей, постараюсь позже перевести статьи, размещенные по указанным в тексте ссылкам, а также другие статьи автора оригинала]
Only registered users can participate in poll. Log in, please.
Нашли ли Вы у себя ошибки, описанные в статье?
5.56% Да, одну1
16.67% Да, несколько3
33.33% Нет6
44.44% Не использую DFSR8
18 users voted. 5 users abstained.
