Управление кластерной непрерывной репликацией
Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Последнее изменение раздела: 2009-06-10
Кроме задач ежедневного управления и администрирования организации Exchange существуют задачи, относящиеся к среде кластера с непрерывной репликацией. В общем случае административные задачи CCR группируются в две категории:
задачи, связанные с кластерным сервером почтовых ящиков;
задачи, связанные с группами хранения и базами данных на кластерном сервере почтовых ящиков.
Задачи, связанные с кластерным сервером почтовых ящиков
К административным задачам, связанным с кластерным сервером почтовых ящиков в среде кластера с непрерывной репликацией, относятся следующие задачи.
Управление томами диска
Просмотр параметров конфигурации
Наблюдение за операциями репликации
Просмотр и сбор данных о производительности
Управление кластерными серверами почтовых ящиков, к которому относится их подключение и отключение, а также перемещение кластерных серверов почтовых ящиков между узлами
Управление репликацией и преобразованием файлов журналов
Управление томами дисков
При управлении средой кластера с непрерывной репликацией может возникнуть необходимость управлять дисковыми томами, которые связаны с конкретным кластером с непрерывной репликацией. Например, может потребоваться временное отключение тома от системы для выполнения обслуживания или по другим причинам. Если эту операцию требуется выполнить для активной группы хранения или базы данных, следует отключить базы данных этой группы хранения. Если эту операцию требуется выполнить для пассивной копии группы хранения или базы данных, необходимо, остановив выполнение репликации, прекратить на этом томе все связанные с ней операции ввода и вывода.
Для получения дополнительных сведений об управлении дисковыми томами см. раздел Подготовка к действиям по управлению томами диска для копии непрерывной репликации кластера.
Просмотр параметров конфигурации
После включении кластера с непрерывной репликацией для сервера параметры настройки групп хранения и баз данных на сервере можно просматривать с помощью консоли управления Exchange и командной консоли Exchange.
Сведения о конфигурации содержат данные о местоположении группы хранения и файлов базы данных. Кроме того, с помощью командной консоли Exchange можно просматривать конфигурацию, связанную с кластерным сервером почтовых ящиков.
Подробное описание действий по просмотру сведений о параметрах управления переходом на другой ресурс при сбое в случае кластера с непрерывной репликацией см. в разделе Инструкции по просмотру конфигурации управления перемещением при сбое.
Наблюдение за операциями репликации.
Пассивная копия базы данных полезна только в случае поддержания ее в актуальном состоянии. Хотя кластер с непрерывной репликацией не требует особого наблюдения, рекомендуется регулярно просматривать каждую группу хранения, чтобы убедиться, что репликация файлов журнала осуществляется правильно. Пакет управления Microsoft Exchange Server 2007 Management Pack для Microsoft Operations Manager 2005 включает оповещения для нескольких критических неполадок, связанных со средами кластера с непрерывной репликацией.
На пассивном узле не запущена служба репликации Microsoft Exchange. Событие, создающее это оповещение, не возникает повторно после остановки службы, поэтому все оповещения, связанные с этим событием, будут потеряны в случае очистки события.
Пассивная копия находится в неисправном состоянии.
Пассивная копия находится в работоспособном состоянии, но значительно отстает в копировании или преобразовании журналов.
Также рекомендуется добавить в Microsoft Operations Manager настраиваемое правило события, которое срабатывает в случае, если не удается обнаружить работающий пассивный узел в кластере, содержащем активный узел. При выполнении этого условия служба кластеров записывает событие в журнал системных событий. Для правила события, которое будет частью события, записываемого в журнал службой кластера, рекомендуется использовать следующие критерии:
Источник события: ClusSvc
Код события: 1135
Дополнительные сведения о создании правил событий в Microsoft Operations Manager см. в статье Наблюдение за событиями безопасности с помощью MOM (на английском языке).
Необходимо как можно скорее исследовать и устранять причины любых из приведенных выше оповещений, созданных пакетом управления Exchange 2007 или настраиваемым правилом события.
Помимо использования пакета управления Exchange 2007 Management Pack для Microsoft Operations Manager 2005 можно регулярно запускать сценарий, выполняющий командлет Get-StorageGroupCopyStatus командной консоли Exchange. Командлет Get-StorageGroupCopyStatus предоставляет сведения о длине очередей, включая количество журналов, созданных активным узлом. По соображениям, связанным с производительностью, счетчики производительности длины очередей сообщают только сведения, известные службе репликации Microsoft Exchange. В крайне редких случаях эти сведения могут не соответствовать состоянию активного узла. Дополнительные сведения о командлете Get-StorageGroupCopyStatus см. в пункте «Просмотр состояния копий групп хранения» данного раздела.
Просмотр и сбор данных о производительности
За ходом выполнения репликации можно следить с помощью счетчиков производительности. Дополнительные сведения об использовании счетчиков производительности для кластера с непрерывной репликацией см. в разделе Инструкции по просмотру счетчиков производительности для непрерывной репликации кластера.
Управление кластерными серверами почтовых ящиков
Тремя основными административными задачами по управлению кластерными серверами почтовых ящиков является перевод кластерного сервера почтовых ящиков в оперативный режим, перевод в автономный режим и перемещение кластерного сервера почтовых ящиков между узлами кластера. Сюда также может входить отключение или перезапуск одного из узлов кластера в рамках управления исправлениями или других операций технического обслуживания.
Запуск и остановка кластерного сервера почтовых ящиков
Подключать и отключать ресурсы можно с помощью средства управления отказоустойчивым кластером (Windows Server 2008), программы «Администратор кластера» (Windows Server 2003) и средства командной строки Cluster.exe (в обеих операционных системах). Перевод кластерного сервера почтовых ящиков в автономный режим называется остановкой, а перевод кластерного сервера почтовых ящиков в оперативный режим называется запуском. Для запуска кластерного сервера почтовых ящиков рекомендуется использовать командлет Start-ClusteredMailboxServer. Останавливать кластерный сервер почтовых ящиков рекомендуется с помощью командлета Stop-ClusteredMailboxServer. Для запуска или остановки кластерного сервера почтовых ящиков в Exchange 2007 с пакетом обновления 1 (SP1) также можно использовать мастер управления кластерными серверами почтовых ящиков в консоли управления Exchange.
Подробные указания по переводу кластерного сервера почтовых ящиков в оперативный режим см. в разделе Инструкции по запуску кластерного сервера почтовых ящиков. Подробные указания по переводу кластерного сервера почтовых ящиков в автономный режим см. в разделе Инструкции по останову кластерного сервера почтовых ящиков.
Перемещение кластерного сервера почтовых ящиков между узлами
Ручное перемещение кластерного сервера почтовых ящиков между узлами называется перемещением вручную или запланированным отключением. Для перемещения кластерного сервера почтовых ящиков рекомендуется использовать командлет Move-ClusteredMailboxServer. В Exchange 2007 с пакетом обновления 1 (SP1) для перемещения кластерного сервера почтовых ящиков вручную также можно использовать мастер управления кластерными серверами почтовых ящиков в консоли управления Exchange. Хотя для перемещения кластерного сервера почтовых ящиков с активного узла на пассивный в можно использовать средство управления отказоустойчивым кластером (Windows Server 2008), программу «Администратор кластера» (Windows Server 2003) и средство командной строки Cluster.exe (в обеих операционных системах), рекомендуется применять для этого одного из средств управления Exchange, так как в них можно указать причину перемещения вручную. Кроме того, при этом обеспечиваются описанные ниже преимущества.
При использовании средств кластера пропускается проверка работоспособности или состояния пассивной копии, которую выполняют средства управления Exchange. Поэтому их использование может привести к длительному отключению во время выполнения узлом операций, необходимых для подключения базы данных.
При использовании средств кластера база данных может быть отключена на неопределенный срок из-за неработоспособности репликации. Кроме того, средства кластера, в отличие от средств управления Exchange, не могут определить состояние репликации перед перемещением группы ресурсов.
.gif "note")
Примечание.При перемещении кластерного сервера почтовых ящиков между узлами возникает короткий перерыв в обслуживании. Кроме того, будет отменено резервное копирование всех групп хранения на кластерном сервере почтовых ящиков.
Если репликация не является работоспособной или во время проверок обнаружится, что состояние пассивного узла недопустимо для перемещения вручную, средства управления Exchange не выполнят перемещение вручную. Если при этом необходимо переместить кластерный сервер почтовых ящиков, для этого можно использовать средства управления кластером.
При перемещении кластерного сервера почтовых ящиков в отказоустойчивом кластере с задержкой в сети между узлами рекомендуется выполнять операцию перемещения с пассивного узла.
Дополнительные сведения о перемещении кластерного сервера почтовых ящиков между узлами см. в разделе Перемещение кластерного сервера почтовых ящиков в среде кластера с непрерывной репликацией.
Обслуживание кластера
Обслуживание всегда следует выполнять на пассивном узле кластера. Обновления, исправления и другие приложения обычно не рекомендуется устанавливать на активном узле (узле, на котором в настоящее время размещен кластерный сервер почтовых ящиков). Дополнительные сведения об установке накопительных пакетов обновления Exchange в среде кластера с непрерывной репликацией см. в разделе Применение накопительных обновлений Exchange Server 2007 к кластерным серверам почтовых ящиков.
Если необходимо провести обслуживание активного узла, кластерный сервер почтовых ящиков необходимо сначала переместить на пассивный узел с помощью командлета Move-ClusteredMailboxServer. После перемещения кластерного сервера почтовых ящиков активный узел становится пассивным, а пассивный узел — активным. После этого можно провести обслуживание и выполнить перемещение вручную, в процессе которого кластерный сервер почтовых ящиков перемещается в обратном направлении.
В среде кластера с непрерывной репликацией можно планировать отключение системы конкретного узла без отключения кластерного сервера почтовых ящиков. В среде кластера с непрерывной репликацией можно одновременно отключать только один узел. При отключении нескольких узлов возникает перерыв в обслуживании.
Запланированное отключение выполняется командлетом Move-ClusteredMailboxServer командной консоли Exchange. Процедуру запланированного отключения см. в разделе Перемещение кластерного сервера почтовых ящиков в среде кластера с непрерывной репликацией.
Перед завершением работы или перезапуском любого узла в кластере с непрерывной репликацией рекомендуется проверить, на каком узле в настоящий момент размещен кластерный сервер почтовых ящиков. Эти сведения можно получить с помощью командлета Get-ClusteredMailboxServerStatus.
Обслуживание кластера
Техническое обслуживание всегда следует выполнять на пассивном узле кластера. Исправления, обновления и другие приложения как правило не следует устанавливать на активном узле (узле, на котором в настоящий момент запущен кластерный сервер почтовых ящиков). Дополнительные сведения об установке накопительных пакетов обновления Exchange в среде кластера с непрерывной репликацией см. в разделе Применение накопительных обновлений Exchange Server 2007 к кластерным серверам почтовых ящиков.
Если на активном узле необходимо провести техническое обслуживание, тогда кластерный сервер почтовых ящиков следует сначала переместить на пассивный узел с помощью командлета Move-ClusteredMailboxServer. После перемещения кластерного сервера почтовых ящиков активный ранее узел становится пассивным узлом, а ранее пассивный узел становится активным узлом. Затем можно провести техническое обслуживание и выполнить ручное перемещение, в процессе которого кластерный сервер почтовых ящиков перемещается в обратном направлении.
Остановка узлов кластера
Если необходимо отключить все узлы кластера, включая активный узел, следует сначала остановить кластерный сервер почтовых ящиков. Процесс завершения работы Windows не учитывает особенности сервера Exchange. Поэтому рекомендуется завершать работу только пассивных узлов. Если необходимо завершить работу активного узла или перезапустить его, рекомендуется переместить кластерный сервер почтовых ящиков на другой доступный узел. Дополнительные сведения о перемещении кластерного сервера почтовых ящиков с одного узла на другой см. в разделе Перемещение кластерного сервера почтовых ящиков в среде кластера с непрерывной репликацией.
Если кластерный сервер почтовых ящиков нельзя переместить на пассивный узел (возможно, из-за того что работа пассивного узла уже завершена), его следует остановить перед завершением работы активного узла.
Если необходимо перезапустить активный узел или завершить его работу, а перемещение кластерного сервера почтовых ящиков на пассивный узел невозможно, рекомендуется использовать групповую политику, чтобы гарантировать остановку кластерного сервера почтовых ящиков перед перезапуском или завершением работы активного узла. Windows Server предоставляет набор сценариев завершения работы компьютера на основе политик, которыми можно управлять с помощью оснастки групповой политики. Оснастка групповой политики включает в себя расширения, позволяющие задавать сценарий, который будет выполняться при завершении работы компьютера.
Например, можно создать сценарий завершения работы, который будет выполнять командлет Move-ClusteredMailboxServer или командлет Stop-ClusteredMailboxServer с соответствующими параметрами. Использовать сценарии завершения работы также рекомендуется по той причине, что таким образом можно предотвратить завершение работы или перезагрузку системы администратором, не знающим о необходимости перемещения или остановки кластерного сервера почтовых ящиков перед завершением работы активного узла.
.gif "important") Важно! |
|---|
| Эти сценарии выполняются с локальной системной учетной записью. Для успешного выполнения этих сценариев необходимо предоставить локальной системной учетной записи (учетной записи компьютера на локальном узле) разрешение на управление кластерным сервером почтовых ящиков. |
Управление репликацией и преобразованием файлов журналов
Управление репликацией в среде кластера с непрерывной репликацией включает следующие основные действия.
Обработка сбойных ситуаций при остановленной репликации
Остановка и перезапуск репликации в копии групп хранения
Настройка одной или нескольких избыточных сетей для репликации
Обработка сбойных ситуаций при остановленной репликации
Остановка репликации приводит к прекращению на время остановки распространения изменений из активной группы хранения в копию. Если в это время выполняется обработка отказа, в данной копии группы хранения будут отсутствовать последние изменения. В зависимости от объема изменений на активном узле отсутствие последних изменений с большей или меньшей вероятностью помешает системе подключить эту копию на пассивном компьютере. Таким образом, приходится использовать доступную на пассивном узле версию группы хранения или ждать завершения восстановления исходного сервера. Важно свести к минимуму время остановки репликации, чтобы свести к минимуму вероятность такой ситуации.
Если подключение версии данных на пассивном узле не выполняется, когда становится доступным исходный компьютер, система репликации копирует недостающие журналы и автоматически подключает копию базы данных на новом активном узле.
Обработка отказа, возникающая после возобновления репликации, происходит в том случае, если в пассивной копии по-прежнему не хватает журналов, или если в копии уже есть все журналы, но они еще не были воспроизведены. Если журналы скопированы, но не преобразованы, обработка отказа запускает воспроизведение в базу данных ожидающих журналов. В результате для данной группы хранения увеличивается время восстановления, выполняемого в процессе обработки отказа, хотя другие группы хранения не будут затронуты. Однако если доступно число журналов, достаточное для удовлетворения настроенным критериям автоматического подключения, система в итоге подключает базу данных с самыми новыми доступными данными. В этом процессе присутствует один фактор риска: один из журналов, которые требуется преобразовать, может быть поврежден, что не позволит успешно выполнить преобразование. В этом случае при преобразовании возникнет ошибка и дальнейшие действия будут заблокированы. После этого копия группы хранения перейдет в состояние ошибки («Сбой»). В состоянии ошибки можно выполнить восстановление с использованием текущей версии базы данных. В противном случае необходимо дождаться доступности исходного сервера и повторного копирования неповрежденного журнала.
Остановка и перезапуск репликации в копии групп хранения
Иногда может возникать необходимость в управлении действиями пассивной копии. Может потребоваться остановка и повторный запуск операций репликации. Управление репликацией осуществляется на уровне группы хранения. Поскольку в группе хранения может содержаться только одна база данных, репликация ограничивается одной базой данных.
Репликация происходит в том случае, если оба узла в кластере находятся в рабочем состоянии, на конечном узле выполняется служба репликации Microsoft Exchange, а для копии группы хранения активирован режим копирования. Если для кластера с непрерывной репликацией недоступно исходное или конечное местоположение, операцию репликации необходимо остановить. Кроме того, для выполнения некоторых задач администрирования кластера с непрерывной репликацией, например заполнения, выполнения проверок целостности или изменения конфигурации хранилища, необходимо остановить репликацию копии группы хранения. Если требуется полностью перекрыть доступ к файлам и каталогу журнала конечного местоположения, репликацию необходимо остановить.
Exchange 2007 требует остановки всех операций в рамках репликации, если осуществляется изменения местоположения группы хранения или базы данных.
Для получения дополнительных сведений о прекращении обновлений копии базы данных см. раздел Инструкции по остановке репликации копии при кластерной непрерывной репликации. Для получения дополнительных сведений о перезапуске операций по обновлению копии базы данных см. раздел Инструкции по перезапуску репликации в копии кластерной непрерывной репликации.
Дополнительные сведения о выполнении проверки целостности журналов транзакций кластера с непрерывной репликацией и файлов баз данных см. в разделе Инструкции по проверке копии непрерывной репликации кластера с помощью ESEUTIL.
Настройка одной или нескольких избыточных сетей для репликации
В Exchange 2007 с пакетом обновления 1 (SP1) можно настроить избыточные сети кластера, которые применяются для доставки журналов и заполнения в среде кластера с непрерывной репликацией. Избыточная сеть должна быть настроена как смешанная сеть кластера. Смешанная сеть кластера — это любая сеть кластера, настроенная и для трафика кластера (интервалов подтверждения), и для трафика доступа к клиенту.
Если в смешанной сети кластера настроены имена узлов и IP-адреса непрерывной репликации, Exchange 2007 использует ее для доставки журналов. Кроме того, настроенная сеть становится доступной для заполнения, запущенного администратором с помощью командлета Update-StorageGroupCopy. Можно указать несколько смешанных сетей. В этом случае Exchange 2007 выбирает одну из них случайным образом. Если текущая сеть становится недоступной, Exchange 2007 автоматически выбирает другую доступную сеть.
Поддержка доставки журналов через смешанную сеть настраивается с помощью командлета Enable-ContinuousReplicationHostName. Отключение этой функции также выполняется с помощью командлета Disable-ContinuousReplicationHostName. После создания кластерного сервера почтовых ящиков в среде кластера с непрерывной репликацией администратор может выполнить командлет Enable-ContinuousReplicationHostName на обоих узлах кластера и указать два IP-адреса и имени узлов. После этого система случайным образом выбирает смешанную сеть для копирования журналов после успешной настройки и проверки работоспособности смешанной сети.
Заполнение и повторное заполнение в среде кластера с непрерывной репликацией выполняется с помощью командлета Update-StorageGroupCopy. В Exchange 2007 с пакетом обновления 1 (SP1) к этому командлету был добавлен новый параметр DataHostNames. Этот параметр позволяет указать сеть, используемую для заполнения и повторного заполнения. Это значение представляет собой многозначный список из двух имен: полного доменного имени или имени узла. Одно из этих имен должно идентифицировать пассивный узел.
Дополнительные сведения о настройке избыточных сетей для доставки журналов и заполнения см. в указанных ниже разделах.
Кластер с непрерывной репликацией в Windows Server 2008:
Кластер с непрерывной репликацией в Windows Server 2003:
Задачи, связанные с группами хранения и базами данных на кластерном сервере почтовых ящиков
К административным задачам, связанным с группами хранения и базами данных на кластерном сервере почтовых ящиков в среде кластера с непрерывной репликацией, относятся указанные ниже.
Перемещение файлов группы хранения или базы данных
Просмотр состояния копий группы хранения
Подключение и отключение баз данных
Проверка целостности копии группы хранения
Восстановление после повреждения в рабочей группе хранения или копии группы хранения
Восстановление кластера с непрерывной репликацией после сбоя или повреждения данных
За исключением восстановления после сбоя группы хранения специального типа, все группы хранения и базы данных в среде кластера с непрерывной репликацией автоматически активируются для непрерывной репликации. Хотя приостановка репликации и преобразования возможна, отключение непрерывной репликации для одной или нескольких групп хранения в среде кластера с непрерывной репликацией невозможно, поскольку это требует перерыва в работе для предотвращения доступа к определенным базам данных.
Если в среде кластера с непрерывной репликацией создается новая группа хранения, заполнение копии базы данных на пассивном узле должно выполняться автоматически. Если по какой-либо причине автоматическое заполнение не выполняется, необходимо заполнить копию базы данных вручную. Подробное описание действий по заполнению копии базы данных см. в разделе Инициализация копии непрерывной репликации кластера.
Изменение местоположения файлов группы хранения или базы данных
Может возникнуть необходимость переместить файлы группы хранения или базы данных в среде кластера с непрерывной репликацией в новое местоположение. Период времени, требуемый для изменения местоположения файлов, зависит от размера перемещаемой базы данных, количества файлов журналов транзакций, а также параметров быстродействия хранилища. На время перемещения база данных всегда отключается.
В среде кластера с непрерывной репликацией для перемещения группы хранения необходимо обеспечить согласованное перемещение обеих копий, поскольку местоположение файлов на активном и пассивном узле должно быть одинаковым. Перед перемещением группы хранения или ее базы данных необходимо отключить базу данных и приостановить репликацию. Для активной копии эта операция выполняется в командной консоли Exchange с помощью командлета Dismount-Database. В случае службы репликации Microsoft Exchange используются командлеты Suspend-StorageGroupCopy и Resume-StorageGroupCopy.
| Примечание. |
|---|
| Служба репликации Microsoft Exchange постоянно отслеживает файлы в месте копирования и журналы на активном узле. Таким образом, при любых операциях с активными журналами необходимо приостановить работу данной группы хранения с помощью командлета Suspend-StorageGroupCopy, останавливающего репликацию. |
Дополнительные сведения о перемещении файлов группы хранения в среде кластера с непрерывной репликацией см. в разделе Перемещение группы хранения в среде кластера с единым хранилищем. Дополнительные сведения о перемещении базы данных в среде кластера с непрерывной репликацией см. в разделе Перемещение базы данных в среде кластера с непрерывной репликацией.
Просмотр состояния копий группы хранения
В окончательной первоначальной версии (RTM) сервера Microsoft Exchange 2007 сведения о состоянии кластера с непрерывной репликацией можно просмотреть только с помощью командной консоли Exchange. На сервере Exchange 2007 с пакетом обновления 1 (SP1) некоторые сведения о состоянии, приведенные в таблице ниже, можно просмотреть в консоли управления Exchange.
В Exchange 2007 публикуются различные сведения о состоянии копий группы хранения. В таблице ниже приведены доступные сведения о состоянии. В таблице ниже атрибуты перечислены в порядке их появления в выходных данных командлета Get-StorageGroupCopyStatus. Дополнительные сведения о просмотре сведений о состоянии см. в разделе Инструкции по просмотру состояния копии непрерывной репликации кластера с помощью среды управления Exchange.
Доступные сведения о состоянии групп хранения с включенной поддержкой кластера с непрерывной репликацией
| Атрибут | Описание |
|---|---|
Identity |
Идентификатор запрошенной группы хранения. Этот атрибут указывает значение параметра <ServerName>\<StorageGroupName>. |
StorageGroupName |
Имя запрошенной группы хранения. Этот атрибут сообщает имя группы хранения. |
SummaryCopyStatus |
Текущее общее состояние пассивной копии. Возможные значения:
На сервере Exchange 2007 с пакетом обновления 1 (SP1) появились перечисленные ниже дополнительные значения состояния.
|
Failed |
В процессе проверки базы данных или журналов обнаружена несогласованность, препятствующая выполнению репликации. Другой причиной может быть проблема с настройкой или доступом к активной или пассивной копии. Возможны значения True и False. |
FailedMessage |
Текстовое сообщение, которое указывает условие, являющееся причиной сбоя репликации. Это может быть не единственной областью неполадки репликации. |
Seeding |
Указывает на то, что выполняется заполнение. Возможны значения True и False. |
Suspend |
Указывает на то, что остановлено выполнение репликации для пассивной копии. Это состояние не позволяет продолжать операции с базой данных и операции копирования журналов. Возможны значения True и False. |
SuspendComment |
Дополнительная область с комментарием администратора, указывающим причину или пояснение к остановке операций репликации. |
CopySuspend |
Указывает на то, что остановлено копирование журнала пассивной копии. В этом состоянии невозможно внесение изменений в каталог копии журнала. Возможные значения: True и False. |
CopySuspendComment |
Дополнительный комментарий администратора, указывающий причину или пояснение к остановке операций копирования журнала. |
CopyQueueLength |
Число файлов журнала транзакций, ожидающих копирования в папку файлов журнала пассивной копии. Копия не считается завершенной до тех пор, пока она не проверена на наличие повреждений. |
ReplayQueueLength |
Число файлов журнала транзакций, ожидающих преобразования в пассивную копию. |
LatestAvailableLogTime |
Отметка времени для исходной группы хранения последнего обнаруженного нового файла журнала транзакций. |
LastCopyNotificationedLogTime |
Время создания активной группой хранения последнего нового журнала, известного копии. |
LastCopiedLogTime |
Отметка времени для исходной группы хранения последней успешной копии файла журнала транзакций. |
LastInspectedLogTime |
Отметка времени для целевой группы хранения последней успешной проверки файла журнала транзакций. |
LastReplayedLogTime |
Отметка времени для целевой группы хранения последнего успешного преобразования файла журнала транзакций. |
LastLogGenerated |
Номер версии последнего журнала в активной копии группы хранения. |
LastLogCopied |
Номер версии последнего журнала, который был успешно скопирован в папку журналов пассивной копии. |
LastLogNotified |
Номер версии последнего журнала, созданного активной группой хранения и известного копии. |
LastLogInspected |
Номер версии последнего журнала, который был проверен на согласованность и наличие повреждений. |
LastLogReplayed |
Номер версии последнего журнала, который был успешно преобразован в пассивную копию базы данных. |
LatestFullBackupTime |
Время последнего полного резервного копирования. |
LastestIncrementalBackupTime |
Время последнего добавочного резервного копирования. |
SnapshotBackup |
Указывает, было ли последнее полное резервное копирование проведено с помощью традиционного потокового резервного копирования или с помощью моментального снимка резервной копии службы теневого копирования томов. |
SnapshotLatestFullBackup |
Время последнего полного резервного копирования помощью моментального снимка. |
SnapshotLatestIncrementalBackup |
Время последнего добавочного резервного копирования с помощью моментального снимка. |
SnapshotLatestDifferentialBackup |
Время последнего разностного резервного копирования с помощью моментального снимка. |
SnapshotLatestCopyBackup |
Время последней копирующей архивации с помощью моментального снимка. |
OutstandingDumpsterRequests |
Ожидающие запросы и диапазон времени (низкий–высокий) для ожидающих запросов. |
DumpsterStatistics |
Статистика транспортной корзины со всех доступных транспортных серверов-концентраторов. Это значение отображается только в том случае,если для команды Get-StorageGroupCopyStatus используется параметр DumpsterStatistics. |
DumpsterStatisticsNotAvailable |
Список недоступных транспортных серверов-концентраторов. |
Значения атрибутов SummaryCopyStatus, CopyQueueLength, ReplayQueueLength и LastInspectedLogTime позволяют быстро оценить работоспособность копии группы хранения. Эти атрибуты показывают, правильно ли работает копия группы хранения и является ли эта копия достаточно свежей в плане копирования и преобразования журналов. При возникновении следующих условий необходимо определить причину их возникновения и устранить неполадку.
Копия не является работоспособной.
Длина очереди копирования более 5 элементов.
Длина очереди преобразования более 20 элементов.
Давнее время последней проверки журнала. Эта ситуация может возникнуть в результате бездействия группы хранения, но также может свидетельствовать об остановке службы репликации Microsoft Exchange.
Длины двух очередей рассчитываются в единицах времени следующим образом:
Очередь копирования, выраженная в единицах времени = LatestAvailableLogTime – LastCopiedLogTime
Очередь преобразования, выраженная в единицах времени = LatestCopiedLogTime – LastInspectedLogTime
Длина очереди преобразования и длина очереди копирования доступны в виде показаний счетчиков производительности. Это счетчики производительности CopyQueueLength и ReplayQueueLength в объекте производительности службы репликации Microsoft Exchange.
В некоторых редких случаях состояние репликации может не соответствовать действительности. Ниже перечислены такие случаи.
Группа хранения, не являющаяся активной (не изменяющаяся), может сообщать о том, что она работоспособна, хотя это не так. Такая ситуация может возникать из-за того, что неисправность нельзя определить до преобразования журнала.
Во время инициализации репликации ее состояние оценивается и может не быть точным. Состояние обновляется после завершения инициализации.
Значение поля LastLogGenerated может быть неверным при отключенной базе данных. Тем не менее, все журналы с содержимым конечных пользователей реплицируются, если реплицируется копия группы хранения.
Если в потоке журналов отсутствует один или несколько журналов, пассивная копия повторяет попытку восстановления. При этом состояние репликации указывает то на сбой, то на работоспособность. Очереди преобразования и копирования будут продолжать расти.
В очень редких случаях журнал может успешно пройти проверку, но вызвать сбой при преобразовании. В этой ситуации система будет поочередно сообщать о сбое и работоспособном состоянии при попытках восстановления. Очереди преобразования и копирования будут продолжать расти.
Примечание.На сервере Exchange 2007 с пакетом обновления 1 (SP1) для проверки состояния и работоспособности групп хранения с включенной непрерывной репликацией также можно использовать новый командлет Test-ReplicationHealth. Дополнительные сведения о командлете Test-ReplicationHealth см. в разделе Test-ReplicationHealth.
Подключение и отключение баз данных
Время от времени возникает необходимость в подключении и отключении базы данных в среде кластера с непрерывной репликацией. Это может потребоваться для изменения настройки или устранения неполадок в работе сервера или базы данных. Если база данных отключена, она блокируется для внесения дальнейших изменений. При отключении базы данных в файлы базы данных и журналов не вносятся изменения.
Для получения дополнительных сведений о подключении баз данных в среде кластера с непрерывной репликацией см. раздел Инструкции по подключению базы данных в среде непрерывной репликации кластера. Для получения дополнительных сведений об отключении баз данных в среде кластера с непрерывной репликацией см. раздел Инструкции по подключению и отключению баз данных в среде непрерывной репликации кластера.
Проверка целостности копии группы хранения
При использовании кластера с непрерывной репликацией рекомендуется периодически проверять целостность пассивной копии, выполняя проверку физической целостности файлов базы данных и журнала транзакций. При проверке физической целостности выполняется анализ файлов журналов транзакций и базы данных на наличие повреждений. Такая проверка выполняется с помощью программ для баз данных Exchange Server (Eseutil.exe). Для получения подробных указаний по применению программы Eseutil для поиска физических повреждений в файлах баз данных и журналов транзакций см. раздел Инструкции по проверке копии непрерывной репликации кластера с помощью ESEUTIL.
| Примечание. |
|---|
| Перед запуском проверки физической целостности базы данных необходимо временно приостановить все операции репликации для копии группы хранения. Временная остановка операций по преобразованию журнала транзакций выполняется в командной консоли Exchange с помощью командлета Suspend-StorageGroupCopy. После завершения проверки согласованности для возобновления преобразования журнала транзакций можно использовать командлет Resume-StorageGroupCopy. |
Восстановление после повреждения в среде кластера с непрерывной репликацией
Кластерная непрерывная репликация (CCR) позволяет выполнить восстановление в рабочей группе хранения после повреждений или сбоев с помощью запланированной остановки. Если файлы журналов не повреждены, восстановление не приводит к потерям данных. Однако если файлы журналов недоступны, восстановление может вернуть группу хранения только к состоянию на момент времени, соответствующий последнему неповрежденному набору изменений полученных копией. Дополнительное ограничение заключается в том, что до этого момента времени никакие изменения не должны быть пропущены или повреждены.
Для получения подробных указаний по восстановлению после повреждений или отказов в среде кластера с непрерывной репликацией см. следующие разделы:
Восстановление кластера с непрерывной репликацией после сбоя или повреждения
Функциональные возможности кластера с непрерывной репликацией обеспечивают автоматическое восстановление после сбоя в работе. Однако существуют ситуации, в которых восстановление необходимо выполнять вручную. К ним относятся следующие ситуации.
Поврежден файл базы данных на пассивной копии. Дополнительные сведения о восстановлении кластера с непрерывной репликацией после повреждения базы данных см. в разделе Инструкции по восстановлению после повреждения базы данных.
Возник сбой базы данных или тома журнала на пассивной копии. Дополнительные сведения о восстановлении кластера с непрерывной репликацией после сбоя тома см. в разделе Указания по восстановлению после сбоя тома.
Сбой базы данных, или в базе данных есть расхождения. Кластер с непрерывной репликацией определят и регистрирует расхождения в базе данных, возникающие в результате сбоя. В общем случае такая ситуация возникает, когда копия базы данных становится доступной и оказывается, что в сбойной копии базы данных имеется изменений больше, чем допускается критериями автоматического подключения. Подробные указания по восстановлению кластера с непрерывной репликацией после возникновения отклонений или сбоя в работе базы данных см. в разделе Восстановление функций кластера с непрерывной репликацией после сбоя или расхождения.