Устранение неполадок, возникающих при репликации общедоступной папки. Часть 2. Устранение неполадок, возникающих при репликации существующих данных
Исходная статья опубликована 28 ноября 2011 г.
Исходная публикация в блоге: 20.01.06
Это вторая запись блога, посвященная устранению неполадок, возникающих при репликации общедоступных папок. В первой записи мы описали устранение неполадок, возникающих при репликации новых изменений. В этой записи описывается устранение неполадок, возникающих при репликации существующих данных, а в последней записи обсуждается исправление ошибок с удалением реплик и описываются распространенные проблемы. Чтобы получить общее представление, прочитайте все указанные материалы.
Устранение неполадок, возникающих при репликации существующих данных
Если выполняется репликация новых изменений, но старые данные не реплицируются, у вас проблема с обратной засыпкой. Наиболее распространенная ситуация с выполнением обратной засыпки иерархии — создание нового хранилища общих данных. Типичный сценарий обратной засыпки содержимого — добавление хранилища общих данных в список реплик папки.
При возникновении подобной проблемы с обратной засыпкой вы уже могли понять, что есть простой способ ее устранить — просто внести изменения во все элементы. Так можно обойти поврежденный процесс обратной засыпки и реплицировать все как новые изменения. Хотя я и написал, что для этого используются оба инструмента (PFDAVAdmin и ModifyItems), обычно лучше всего исправить процесс обратной засыпки и устранить основную причину ошибки. Если вы просто изменили все данные для репликации, такая же проблема с обратной засыпкой может возникнуть в будущем, когда реплики опять будут рассинхронизированы. Итак, перейдем к обсуждению обратной засыпки. Чтобы понять процесс обратной засыпки, сначала необходимо понять, как отслеживаются изменения.
Каждая папка и каждое сообщение в хранилище получает номер изменения (CN) при создании и изменении. При выполнении репликации CN каждого объекта используются, чтобы определить, нужно ли реплицировать этот объект. Группа CN называется CNSet. CNSet определенной папки на конкретном сервере называется сведениями о состоянии. Эта информация включается в каждое сообщение репликации. Каждый тип сообщения с типом 0x2 содержит состояние иерархии для сервера, отправляющего сообщение. Аналогично, каждое сообщение с типом 0x4 содержит сведения о состоянии для определенной папки на сервере, отправляющем сообщение. Все другие типы сообщений репликации содержат сведения о состоянии для соответствующих им папок.
Когда хранилище общих данных подключается в первый раз, оно отправляет запрос состояния (тип 0x20) иерархии всем существующим хранилищам общих данных. Аналогично, при добавлении нового хранилища в список реплик папки это хранилище отправляет запрос 0x20 всем другим репликам этой папки. Как и любое сообщение репликации, запрос состояния содержит CNSet для всех CN данной папки (или иерархии) в исходном хранилище и запрашивает ответ у других хранилищ, если у них есть значения CN, которых нет в исходном хранилище. Учтите, что до Exchange 2003 с пакетом обновления 2 (Sp2) все реплики не должны были отвечать на запрос состояния, поэтому некоторые хранилища игнорируют запрос состояния, даже если у них есть изменения, отсутствующие в исходном хранилище. Сервер 2003 с пакетом обновления 2 (Sp2) запрашивает ответы у всех реплик и отвечает, даже если исходный сервер не запрашивал ответ (если на нем есть изменения, отсутствующие на исходном сервере). Это может значительно улучшить решения, принимаемые в процессе обратной засыпки. Уникальная характеристика запроса состояния заключается в том, что они не содержит данные, которые нужно реплицировать, а только список номеров изменений. Другие хранилища отвечают сообщениями о состоянии (тип 0x10), в которых указываются их собственные CNSet для этой папки (или иерархии). Когда исходный сервер получает сообщения типа 0x10, он сравнивает CNSet в сообщении с собственным CNSet. Если сообщение типа 0x10 содержит изменения, отсутствующие в хранилище, начинается процесс обратной засыпки.
Первый шаг процесса обратной засыпки — добавление записей в массив обратной засыпки для рассматриваемой папки. Эти записи содержат CNSet, описывающий отсутствующие изменения, и значение периода ожидания, указывающее на время, когда хранилище запрашивает отсутствующие данные. Период ожидания обратной засыпки зависит от ситуации. Когда новое хранилище общих данных переводится в оперативный режим или добавляется новая реплика папки, начальный период ожидания составляет 15 минут.
Записи обратной засыпки могут быть добавлены в массив обратной засыпки и при нормальном режиме работы. Рассмотрим ситуацию, в которой определенное хранилище общих данных выполнило широковещательную рассылку двух изменений в двух отдельных сообщениях типа 0x2. Предположим, что администратор удаляет первое сообщение типа 0x2 из очереди, но второе сообщение сохраняется. Когда другие серверы получат его, они обнаружат, что CNSet в сведениях о состоянии содержит номера изменений, которые они никогда не получали. В результате они создадут записи обратной засыпки для этих данных. Начальный период ожидания записей обратной засыпки для отсутствующих данных, обнаруженных при нормальной репликации, составляет 6 часов, если данные доступны в той же группе маршрутизации (RG), или 12 часов, если они доступны только в другой группе маршрутизации. При каждой отправке запроса обратной засыпки следующий период ожидания будет составлять 12 часов и затем 24 часа для запросов внутри группы маршрутизации или 24 часа и 48 часов для запросов вне группы маршрутизации.
Каждые пять минут хранилище проверяет, превышен ли период ожидания записей обратной засыпки. Если это так, запрос обратной засыпки (тип 0x8) отправляется для отсутствующих CN, а период ожидания становится равным следующему интервалу. Запрос обратной засыпки не является широковещательным, он направляется на один сервер (один из серверов, указавший ранее, что на нем нет отсутствующих CN в сведениях о состоянии, отправленных запрашивающему серверу). Когда этот сервер получает входящее сообщение типа 0x8, он сразу обрабатывает запрос и отправляет одно или несколько ответов обратной засыпки (0x80000002 для иерархии и 0x80000004 для содержимого), которые содержат фактические данные для запрошенных номеров изменений. Как и запросы обратной засыпки, ответы не являются широковещательными и отправляются только на запрашивающий сервер.
Если запрашивающий сервер успешно обрабатывает входящий ответ обратной засыпки, номера изменений в нем удаляются из массива обратной засыпки в этом хранилище. В действительности любое входящее сообщение, содержащее невыполненные номера изменений в массиве обратной засыпки, приведет к удалению этих CN из массива.
Устранение неполадок
Как можно увидеть, при устранении проблем с процессом обратной засыпкой нужно ответить на много вопросов.
1. Хранилище знает о том, что в нем не хватает данных?
Сначала нужно определить, известно ли серверу, что другие хранилища содержат изменения, которые нужно запросить. К сожалению, поддерживаемого средства или служебной программы, которые позволяют просмотреть массив обратной засыпки, чтобы узнать о наличии изменений, нет. Но существуют другие косвенные способы, чтобы сделать это.
Первый способ — просто ждать. Если сервер знает, что данных не хватает, он отправляет запрос каждые 24 часа или каждые 48 часов. Это значит, что можно просто включить ведение журнала и посмотреть, отправляется ли сообщение типа 0x8. Если для рассматриваемой папки сообщения типа 0x8 нет, но вы видите сообщения тип 0x8 для других папок, возможно, превышен предел невыполненных операций обратной засыпки, который мы обсудим далее.
Другой вариант — убедиться, что сервер получает последние сведения о состоянии. Помните, что сервер отправляет запрос состояния только один раз после добавления новой реплики. После этого в нормальном процессе репликации передаются только полученные сведения о состоянии. Поэтому если попытка получить состояние была неудачной, так как сообщение типа 0x20 или 0x10 в ответе было утеряно или удалено, сервер может даже не знать о том, что данные отсутствуют. Существует несколько способов убедиться, что сервер получил сведения о состоянии папки.
- Перейти на сервер, содержащий все данные, и внести изменение в папку, добавив, удалив или изменив сообщение. В случае с иерархией создайте, удалите или измените свойства папки. Получившееся сообщение типа 0x4 или 0x2 будет содержать сведения о состоянии папки или иерархии соответственно. Когда сервер, на котором отсутствуют данные, успешно обработает входящее сообщение репликации, вы будете знать, что он добавил все необходимые записи в массив обратной засыпки.
- Используйте параметр "Синхронизация содержимого" в Exchange 2003 ESM. Это хорошо спрятанный, но очень полезный параметр. Чтоб найти его, перейдите к дереву "Общедоступные папки" и откройте нужную папку. Выделите папку в левой области. В правой области откройте вкладку "Состояние". Щелкните правой кнопкой сервер со всеми данными и выберите параметр "Синхронизация содержимого". Так можно добиться двух целей — сервер отправит запрос состояния 0x20 для папки, а период ожидания всех записей обратной засыпки будет сразу же завершен. Помните, что я сказал, что следует синхронизировать содержимое на сервере, который уже содержит все данные. Вы можете удивиться, зачем это делать, когда записи обратной засыпки, период ожидания которых нужно завершить, содержатся на другом сервере. Помните, что в данный момент мы просто пытаемся убедиться в том, что сервер, на котором не хватает данных, ЗНАЕТ, что требуется выполнить обратную засыпку. Поэтому мы можем использовать параметр "Синхронизация содержимого" на сервере со всеми данными, чтобы отправить запрос 0x20 на сервер, на котором данных нет. В этом случае нас на самом деле не интересует ответ 0x10 на сообщение типа 0x20. Мы просто хотим сохранить отсутствующие данные, чтобы получить сообщение репликации для папки из хранилища с содержимым, чтобы оно смогло добавить соответствующие записи в массив обратной засыпки. Сообщение типа 0x20 от сервера с данными служит для этой цели. Учтите, что в Exchange 2003 с пакетом обновления 2 (Sp2) параметр "Синхронизация содержимого" теперь доступен и для иерархии — щелкните правой кнопкой сам узел "Общедоступные папки".
- Используйте значение реестра "Флаги репликации" (KB813629). Если правильно использовать это значение вместе со значением "Включить репликацию сообщений при запуске" из KB321082, хранилище будет отправлять запрос состояния 0x20 для каждой папки при запуске. Опять же, их нужно использовать на сервере с требуемым содержимым, так как цель этого шага — заставить сервер с содержимым отправить сведения о состоянии на сервер, где содержимого нет.
- Используйте 2003 ESM для отправки ответа обратной засыпки. В 2003 Sp1 можно использовать параметр "Отправить иерархию", чтобы отправить ответ обратной засыпки иерархии, и параметр "Отправить содержимое", чтобы отправить ответ обратной засыпки содержимого папки. В 2003 Sp2 оба этих параметра превратились в "Отправить изменения повторно". Он позволяет отправить ответ обратной засыпки для указанного диапазона данных, но при этом не следует задавать весь диапазон, так как в него могут попасть все незавершенные записи обратной засыпки, а это приведет к устранению изначальной проблемы. Вместо этого укажите диапазон в один или два дня. Так сообщения типа 0x80000002 или 0x80000004 будут отправлены на целевой сервер, который, опять же, предоставляет свои сведения о состоянии хранилищу с данными.
После использования одного из этих параметров для принудительной отправки сведений о состоянии и проверки того, что хранилище с отсутствующими данными получило входящее сообщение (просмотрев журнал приложений), вы узнаете, что именно в нем не хватает данных.
2. Хранилище запрашивает отсутствующие данные?
Убедившись, что хранилище знает о том, что нужно обновить данные, следует проверить, отправляет ли оно запрос обратной засыпки? Вспомните, что после нескольких попыток обновить данные придется подождать 24 часа или 48 часов до следующего запроса обратной засыпки, так как это самый длительный интервал для внутренних и внешних запросов соответственно. Есть только один способ ускорить этот процесс — еще раз использовать параметр "Синхронизация содержимого", но на этот раз на сервере, на котором отсутствуют данные. Так период ожидания записей обратной засыпки для этой папки будет сразу же завершен. Но при этом хранилище опять может не отправить запрос обратной засыпки для нужной папки. В этом случае изучите журнал приложений для следующих 24-48 часов. Если хранилище отправляет запросы для других папок, но не для нужной папки, возможно, превышен предел обратной засыпки.
Если вы добавили реплики для множества папок в новое хранилище и репликация по началу идет нормально, но в течение следующих одного-двух дней прекращается, скорее всего превышен предел обратной засыпки. Предел обратной засыпки — это механизм, предназначенный для регулирования репликации. По умолчанию хранилище допускает отправку 50 незавершенных запросов обратной засыпки за один раз. После накопления 50 запросов оно запрашивает следующие 50 опять и опять до их выполнения. После отправки всех записей в OBL появляется возможность для запроса нового набора данных. Это значит, что если по какой-то причине не удается выполнить 50 запросов, репликация не будет продолжаться.
В этой ситуации следует изучить журнал приложений и узнать, что запрашивает хранилище. Вы увидите периодические сообщения типа 0x8 для текущих 50 запросов и обнаружите, что ответ обратной засыпки не получен, поэтому эти запросы не выполнены. В этот момент следует сконцентрироваться на устранении неполадок с одной из папок, данные для которой хранилище пытается получить, так как это позволит перейти к другим папкам.
Существует еще один вариант — увеличить предел незавершенных запросов обратной засыпки (OBL). Это можно сделать, создав значение реестра Replication Oustanding Backfill Limit в разделе реестра для этого хранилища. Максимальное значение — 5000 в десятичном формате. Но после этого откроются врата для репликации и будет трудно опередить, какие 50 папок вызвали проблему. Необходимо отложить устранение неполадок, пока весь процесс опять не застопорится. Обычно я рекомендую оставить предельное значение, равное 50, и исправить проблему вместо того, чтобы устранить ее, увеличив предел.
Если проблема не в OBL и исходящие сообщения типа 0x8 для рассматриваемой папки все так же нет, см. раздел "Распространенные проблемы" в последней статье этой серии.
3. Другое хранилище отвечает на запрос?
После определения запроса обратной засыпки, на который нужно обратить внимание, следует определить, получило ли конечное хранилище запрос. Проверьте журнал приложений на этом сервере на наличие входящих сообщений типа 0x8. Вы также можете поискать в журнале код сообщения, указанный в исходящем событии на сервере, отправившем запрос. Если в журнале сообщения нет, используйте средство отслеживания сообщений, чтобы узнать, куда оно дошло. Если сервер получил сообщение 0x8, он должен ответить почти незамедлительно одним или несколькими сообщениями 0x80000002 или 0x80000004 (вы часто будете видеть множество ответов обратной засыпки для одного запроса, так как не все изменения отправляются в одном сообщении). Конечно, время, необходимое для создания ответов обратной засыпки будет разным в зависимости от данных в папке и предела размера сообщения репликации. Например, если задать максимальный размер сообщения репликации как 1 ГБ, отвечающий сервер попытается запаковать всю иерархию в одном ответе обратной засыпки. Только на упаковку может уйти час и более времени!
4. Запрашивающий сервер получает ответ?
Теперь время проверить журнал приложений на запрашивающем сервере, чтобы узнать, получил ли он ответ обратной засыпки. Если не получил, отследите сообщение и узнайте, куда оно дошло. Если сервер получил ответ и записал его в журнал сообщений, запрос обратной засыпки был выполнен и репликация может продолжаться.
Как я упоминал ранее, если отслеживание сообщений показало, что одно из сообщений было доставлено в хранилище, но в журнале приложений нет входящего сообщения репликации, см. раздел "Распространенные проблемы" в последней статье этой серии.
В следующей записи блога: Устранение неполадок с удалением реплик и распространенные проблемы.
Это локализованная запись блога. Исходная статья доступна по адресу: Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data