Устранение неполадок кластера с непрерывной репликацией
Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Последнее изменение раздела: 2008-01-14
В данном разделе рассматриваются вопросы, связанные с устранением неполадок кластера с непрерывной репликацией. Дополнительные сведения о средствах, помогающих устранить неполадки кластера с непрерывной репликацией, см. в разделе Средства устранения неполадок для сред с высоким уровнем доступности.
Процедуры, описанные в этом разделе, устраняют следующие неполадки в среде кластера с непрерывной репликацией:
Командлет Get-StorageGroupCopyStatus сообщает о сбое базы данных и о том, что она не заполнена.
Командлет Get-StorageGroupCopyStatus сообщает о сбое базы данных. Значение FailedMessage указывает на то, что копия группы хранения отличается от оригинала.
Командлет Get-StorageGroupCopyStatus сообщает о сбое базы данных. Значение FailedMessage предоставляет конкретные сведения об источнике сбоя.
Оповещения, счетчики производительности или Get-StorageGroupCopyStatus указывают на то, что для копии группы хранения произведено резервное копирование очередей копирования или преобразования.
Командлет Get-StorageGroupCopyStatus сообщает время ожидания для значения LastInspectedLogTime.
Переход на другой ресурс при сбое или командлет Move-ClusteredMailboxServer выполняется успешно, но базы данных не подключаются.
Переход на другой ресурс при сбое выполнен, но некоторые базы данных не подключаются вручную или автоматически. Или же командлет Get-ClusteredMailboxServerStatus сообщает о сбое одной или нескольких баз данных.
В среде кластера с непрерывной репликацией база данных не подключается при запуске.
Регистрируется событие MSExchangeRepl 2073, предупреждающее о том, что службе репликации Microsoft Exchange не удается найти каталог.
Командлет Move-ClusteredMailboxServer не запускает запланированное отключение из-за проблем с репликацией.
Репликация не выполняет повторную синхронизацию после перехода на другой ресурс при сбое для одной или нескольких групп хранилищ.
Не удается выполнить заполнение.
Если возникла неполадка, которой нет в приведенном выше списке, просмотрите журналы событий на обоих узлах, чтобы определить причину неполадки, и используйте сведения в журналах, чтобы определить, что необходимо сделать для устранения неполадки. После определения времени сбоя можно просмотреть другие журналы — это поможет разобраться в проблеме. Если этих сведений недостаточно, время сбоя можно использовать для сужения области анализа и уменьшения окна проверки в журнале кластера. Журнал кластера содержит информацию уровня отслеживания по действиям, выполняемым системой управления кластерами.
Приступая к работе
Для выполнения описанных ниже действий используемой учетной записи необходимо делегировать роль администратора Exchange Server и членство в локальной группе администраторов целевого сервера. Дополнительные сведения о разрешениях, делегировании ролей и правах, необходимых для администрирования сервера Microsoft Exchange Server 2007, см. в разделе Вопросы, связанные с разрешениями.
Процедура
Командлет Get-StorageGroupCopyStatus сообщает о сбое базы данных и о том, что она не заполнена
Возможные причины Проблема, связанная с конфигурацией, или копия репликации не имеет допустимой основной базы данных. Эта проблема может возникнуть, если не заполнить копию группы хранения при добавлении пассивного узла.
Решение
Проверьте правильность настройки хранилища для данной копии и его работоспособность. При обнаружении ошибки необходимо запустить новую проверку копии: приостановить, а затем возобновить работу группы хранения.
Проверьте, правильно ли настроены пути группы хранения и базы данных относительно хранилища на пассивном сервере. Это можно сделать с помощью командлета Get-StorageGroup в консоли управления Exchange.
Используйте командлет Update-StorageGroupCopy для заполнения копии группы хранения.
Командлет Get-StorageGroupCopyStatus выдает сообщение о сбое базы данных, а значение FailedMessage указывает на то, что копия группы хранения отличается от оригинала
Возможные причины Такая проблема возникает, если при переходе на другой ресурс при сбое теряется значительное число журналов, что не позволяет повторно синхронизировать базу данных на предыдущем активном сервере с текущей активной базой данных без полного повторного заполнения. В случае локальной непрерывной репликации такая ситуация возникнуть не может.
Решение Используйте командлет Update-StorageGroupCopy для заполнения копии группы хранения.
Командлет Get-StorageGroupCopyStatus сообщает о сбое базы данных, а значение FailedMessage предоставляет конкретные сведения об источнике неполадки
Возможные причины Существует множество причин, которые могут привести к обнаружению сбоя копии группы хранения. Примерами могут служить описанные выше случаи, когда база данных не заполнена или существуют различия между копиями. Значение FailedMessage указывает на обнаруженную проблему.
Решение Выполните командлет Get-StorageGroupCopyStatus, чтобы получить полное значение FailedMessage, которое указывает на конкретную обнаруженную проблему. Проанализируйте значение FailedMessage и исправьте обнаруженные ошибки. Если сообщается о том, что журнал поврежден или отсутствует, найдите неповрежденный журнал с подходящим номером версии. Если такой журнал найти не удается, выполните повторное заполнение с помощью командлета Update-StorageGroupCopy. Если в сообщении говорится о том, что журналы для источника недоступны, запретите совместное использование каталога, в котором хранится журнал источника, и перезапустите службу репликации на этом узле.
Оповещения, счетчики производительности или Get-StorageGroupCopyStatus указывают на то, что для копии группы хранения произведено резервное копирование очередей копирования или преобразования
Возможные причины Создания журнала ожидания при копировании или преобразовании журналов может указывать либо на наличие некоторой неполадки, либо на переходную ситуацию в процессе восстановления. Переходная ситуация возникает, когда подключается пассивный узел, который находился в автономном режиме, или когда возобновляется работа копии группы хранения, которая до этого долгое время была приостановлена. Остановка службы репликации Microsoft Exchange на пассивном узле действует аналогично приостановке всех копий группы хранения на этом узле. Если речь не идет о переходной ситуации, причиной может быть следующее:
проблема настройки;
приостановка копии группы хранения;
остановка службы преобразования;
сбой или отключение хранилища;
переход узла в автономный режим.
Решение. Определите, существует ли проблема на самом деле или же возникла временная ситуация.
Определите, работает ли служба репликации Microsoft Exchange на обоих узлах. Это можно сделать с помощью оснастки «Службы». Если на одном из узлов служба остановлена, ее необходимо запустить.
Запустите командлет командной консоли Exchange Get-StorageGroupCopyStatus с параметром fl (форматированный список) и проверьте, не приостановлена ли работа пассивной копии. Если она приостановлена, проверьте наличие всех необходимых файлов пассивной копии и возобновите работу копии группы хранения с помощью командлета Resume-StorageGroupCopy.
Выполните командлет Get-StorageGroupCopyStatus с параметром fl и проверьте состояние копии (должно быть указано «Healthy» — работоспособна). Если копия имеет состояние «Failed» (сбой), просмотрите список полей состояния и определите, что необходимо сделать.
Понаблюдайте за счетчиками производительности репликации в течение нескольких минут, чтобы определить, изменяется ли что-либо. Обратите внимание на номер преобразуемой и проверяемой версии. Если длина очереди копий продолжает увеличиваться, но при этом очередь преобразования короткая или уменьшается, возможно, возникла проблема в сетевой общей папке на активном сервере или на самом активном сервере. Убедитесь в том, что каталог журналов активной копии группы хранения имеет общую папку, заданную с помощью команды «net share», используя проводник Windows или оснастку «Управление компьютером». Идентификатор GUID группы хранения можно определить, выполнив командлет Get-StorageGroup с параметром fl в командной консоли Exchange.
Командлет Get-StorageGroupCopyStatus выводит старое время для параметра LastInspectedLogTime
Возможные причины. Эта проблема может быть вызвана тремя причинами.
отключена база данных активной копии группы хранения;
активная копия группы хранения подключена, но изменяется слишком медленно. Это приводит к тому, что активная копия группы хранения не создает журналы.
На пассивном узле не запущена служба репликации Microsoft Exchange.
Решение Определите, какая из трех причин вызвала неполадку:
С помощью консоли управления Exchange или командлета Get-StorageGroupStatus в командной консоли Exchange определите, не отключена ли база данных. Если база данных отключена, необходимо подключить ее; изменения в базе данных (например действия в ней) необходимо выполнить до изменения параметра LastInspectedLogTime.
Убедитесь в том, что на пассивном узле работает служба репликации Microsoft Exchange. Если служба остановлена, ее необходимо запустить.
Убедившись в том, что база данных подключена, проверьте, создает ли она журналы. Зайдите в каталог журналов активной базы данных и найдите файл журнала с самым большим номером версии. Проверьте отметку времени для этого журнала; она должна соответствовать значению LastInspectedLogTime.
Переход на другой ресурс при сбое или командлет Move-ClusteredMailboxServer выполняются, но базы данных не подключаются
Возможные причины Обычно причина состоит в том, что прав учетной записи службы кластеров недостаточно для подключения базы данных. Или же при переходе на другой ресурс при сбое было утеряно слишком много журналов, и поэтому автоматическое подключение параметров конфигурации невозможно. Другая частая причина состоит в том, что в случае перехода на другой ресурс при сбое пассивные копии при переходе были неисправны.
Решение Проблемы, связанные с правами учетной записи кластеров, обычно возникают при установке. Если базы данных не подключаются в конце установки, это обычно означает, что учетной записи службы кластера не были предоставлены соответствующие разрешения. Чтобы устранить эту проблему, предоставьте учетной записи службы кластера соответствующие разрешения, выполните плановое отключение и перезапустите весь кластер. Это можно сделать следующим образом: 1) перевести кластерный сервер почтовых ящиков в автономный режим; 2) отключить пассивный узел; 3) отключить активный узел; 4) запустить активный узел; 5) запустить пассивный узел; 6) перевести кластерный сервер почтовых ящиков в оперативный режим.
- Просмотрите журнал событий, чтобы определить, не утеряно ли при переходе на другой ресурс при сбое слишком много журналов для автоматического подключения параметров конфигурации. Определив состояние базы данных копии группы хранения, можно явным образом подключить ее, выполнив командлет Restore-StorageGroupCopy в командной консоли Exchange. Наконец, выполните командлет Get-StorageGroupCopy и проверьте значение SummaryCopyStatus, чтобы определить, не возникло ли проблем с копией, которая до этого была активна, которые могли бы препятствовать подключению. Если проблемы есть, просмотрите журнал событий, чтобы определить причину, и выполните действия для их устранения.
Переход на другой ресурс при сбое выполнен, но некоторые базы данных не подключаются вручную или автоматически. Кроме того, командлет Get-ClusteredMailboxServerStatus может сообщать о сбое одной или нескольких баз данных
Возможные причины При переходе на другой ресурс при сбое было утеряно слишком много журналов, и поэтому автоматическое подключение параметров конфигурации невозможно. Другая частая причина состоит в том, что в случае перехода на другой ресурс при сбое пассивные копия при переходе была неисправна.
.gif "note")
Примечание.Базы данных могут на некоторое время помечаться как неисправные или работающие в автономном режиме при запланированном или незапланированном отключении. Это состояние является переходным и возникает, когда служба репликации пытается создать окончательную копию любого из доступных журналов. Решение Просмотрите журнал событий, чтобы определить, почему база данных не подключилась. Причиной могут быть поврежденные файлы журналов или базы данных. Если вы найдете сообщение об этом в журнале событий, восстановите доступ к базе данных, перенеся активный сервер на другой узел. Наличие сбоя в базе данных можно определить, просмотрев журнал событий. Определив состояние базы данных копии группы хранения, можно явным образом подключить ее, выполнив командлет Restore-StorageGroupCopy в командной консоли Exchange. Затем выполните командлет Get-StorageGroupCopyStatus и проверьте значение SummaryCopyStatus, чтобы определить, не возникло ли проблем с копией, которая до этого была активна, которые могли бы препятствовать подключению. Если сообщается о том, что копию группы хранилищ невозможно активировать из-за того, что она устарела, ее можно будет восстановить, когда неисправный узел снова заработает и будет доступно большее количество журналов. Журналы копируются автоматически, никаких действий не требуется.
В среде кластера с непрерывной репликацией база данных не подключается при запуске
Возможные причины База данных может не подключаться из-за каких-то явных действий администратора. Если база данных была отключена явным образом, а затем кластерный сервер почтовых ящиков был переведен в автономный режим, при следующем запуске база данных не будет переводиться в оперативный режим. Другая возможная причина заключается в том, что при переходе на другой ресурс при сбое было утеряно слишком много журналов.
Решение Можно выполнить командлет Get-ClusteredMailboxServerStatus в командной консоли Exchange, чтобы проверить, работоспособно ли хранилище на узле. При помощи консоли управления Exchange или командной консоли Exchange попытайтесь подключить необходимую копию базы данных. Для получения дополнительных сведений о подключении копии базы данных см. раздел Инструкции по подключению базы данных в среде непрерывной репликации кластера. После подключения просмотрите журнал событий, чтобы узнать, нет ли сообщений об ошибках.
Регистрируется событие кластера MSExchangeRepl 2073, предупреждающее о том, что службе репликации Microsoft Exchange не удается найти указанный каталог
Возможные причины. Событие ошибки указывает на то, что службе репликации Microsoft Exchange не удается создать каталог, определенный в событии. Служба репликации Microsoft Exchange пытается создать несколько требуемых каталогов, если они уже не существуют (включая пути к каталогам для исходных файлов журналов, конечных файлов журналов, конечных системных файлов и путь для инспектора файлов журнала).
Службе репликации Microsoft Exchange может не удаваться создать указанный каталог из-за проблем с разрешениями, сбоя оборудования или ошибки конфигурации.
Решение. Просмотрите код ошибки, возвращенный событием. Убедитесь в том, что расположение каталога доступно и к нему можно получить доступ. Проверьте разрешения файловой системы. Убедитесь в том, что хранилище правильно настроено, а оборудование работает правильно.
Командлет Move-ClusteredMailboxServer не запускает запланированное отключение из-за проблем с репликацией
Возможные причины Командлет Move-ClusteredMailboxServer командной консоли Exchange выполняет проверку для предупреждения запланированного отключения пассивного узла, если репликация не является полностью работоспособной на всех копиях групп хранения. Такие проверки гарантируют, что запланированное отключение не будет выполняться слишком долго.
Решение Определите проблемные группы хранения и устраните все неполадки. Сообщение об ошибке, которое выдает командлет Move-ClusteredMailboxServer, указывает на проблемную копию группы хранения. Если необходимо выполнить перемещение и пропустить проверку, убедитесь в том, что отключена только база данных неисправной копии группы хранения. Повторите попытку переноса и используйте параметр -IgnoreDismounted. Параметр IgnoreDismounted указывает на то, что отключенные группы хранения будут пропускаться при проверке работоспособности репликации.
Репликация не выполняет повторную синхронизацию после перехода на другой ресурс при сбое для одной или нескольких групп хранения
Возможные причины Сообщение о сбое, возвращенное командлетом Get-StorageGroupCopyStatus, указывает на то, что база данных отличается от оригинала. Такая ситуация возникает, если при переходе на другой ресурс при сбое на предыдущем активном сервере не была выполнена репликация достаточного количества журналов.
Решение Повторно заполните базу данных, используя командлет Update-StorageGroupCopy в командной консоли Exchange.
Не удается выполнить заполнение
Возможные причины Выполняется резервное копирование на активном сервере, или возникли неполадки со связью.
Решение Проверьте, не выполняется ли резервное копирование соответствующей копии группы хранения или базы данных. Убедитесь в том, что активный узел находится в оперативном режиме.
Дополнительные сведения
Дополнительные сведения о командлетах командной консоли Exchange, описанных в этом разделе, см. в следующих разделах:
Дополнительные сведения об устранении неполадок, связанных с локальной непрерывной репликацией, см. в разделе Указания по устранению неполадок локальной непрерывной репликации.