Непрерывная репликация кластера
Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Последнее изменение раздела: 2008-03-21
Кластерная непрерывная репликация (CCR) - это функция обеспечения высокой доступности Microsoft Exchange Server 2007, сочетающее асинхронную доставку журналов и технологию преобразования, встроенные в Exchange 2007, с обработкой отказа и средствами управления, предоставляемыми службой кластера.
Задача кластерной непрерывной репликации — обеспечение высокой доступности данных для серверов почтовых ящиков Exchange 2007 посредством предоставления решения, удовлетворяющего следующим требованиям.
Отсутствие единственной точки отказа.
Отсутствие специальных требований к оборудованию.
Отсутствие требований к общему хранилищу.
Возможность развертывания в конфигурации с одним или двумя центрами данных.
Возможность снижения частоты полного резервного копирования, уменьшения общего объема данных в резервных копиях и сокращения времени восстановления после первого сбоя, указанного в соглашении об условиях обслуживания.
В кластерной непрерывной репликации для обеспечения непрерывного асинхронного обновления второй копии базы данных изменениями, внесенными в активную копию базы данных, используется возможность восстановления базы данных после сбоя сервера Exchange 2007. При установке пассивного узла в среде кластерной непрерывной репликации все группы хранения и их базы данных копируются с активного узла на пассивный. Эта операция называется заполнением. Она обеспечивает основу базы данных для репликации. После выполнения начального заполнения постоянно выполняется копирование и преобразование журнала.
В среде кластерной непрерывной репликации возможности репликации встраиваются в службу кластера, что обеспечивает высокую доступность решения. В дополнение к обеспечению доступности данных и службы кластерная непрерывная репликация обеспечивает запланированные отключения. При возникновении необходимости установки обновлений или проведения обслуживания администратор может вручную переместить кластерный сервер почтовых ящиков (называемый виртуальным сервером Exchange в предыдущих версиях сервера Exchange Server) на пассивный узел. После выполнения операции перемещения администратор может провести необходимое обслуживание.
Операция перемещения выполняется с помощью командлета Move-ClusteredMailboxServer в командной консоли Exchange. В Microsoft Exchange Server 2007 с пакетом обновления 1 (SP1) имеется также новый мастер управления кластерного сервера почтовых ящиков в консоли управления Exchange, который можно использовать для перемещения кластерных серверов почтовых ящиков. Логика, используемая этими задачами, выполняет необходимые операции для обеспечения сохранности данных почтовых ящиков при перемещении. Командлет также выполняет проверки перед перемещением, чтобы гарантировать, что репликация на пассивном узле готова к быстрой активации.
Ниже перечислены основные сведения о кластерной непрерывной репликации.
Непрерывная репликация является асинхронной Журналы не копируются, пока они не будут закрыты и не перестанут использоваться сервером почтовых ящиков. Это означает, что пассивный узел обычно не содержит копий всех файлов журналов, которые имеются на активном узле. Исключением является случай, когда администратор проводит запланированное отключение активного узла для установки обновления или проведения обслуживания.
При нормальной работе непрерывная репликация почти не создает дополнительной нагрузки на процессор и систему ввода-вывода на активном узле Кластерная непрерывная репликация использует пассивный узел для копирования и преобразования журналов. Пассивный узел получает доступ к журналам через защищенный общий файловый ресурс.
Смена активного и пассивного узлов при работе кластера происходит автоматически Например, после перехода на другой ресурс при сбое активный и пассивный узлы меняются местами. Это означает, что направление репликации меняется на обратное. Для этого не требуется никаких действий со стороны администратора. Система управляет инверсией репликации автоматически.
Переход на другой ресурс и запланированные отключения симметричны по функции и производительности Переход с узла1 на узел2 занимает столько же времени, что и переход с узла2 на узел1. Обычно на это нужно не более двух минут. На больших серверах запланированные отключения обычно занимают не более четырех минут. Разница по времени между переходом на другой ресурс и запланированным отключением связана со временем выполнения управляемого завершения работы активного узла при запланированном отключении. Это отличие в производительности может быть уменьшено в последующих пакетах обновления.
Пассивный узел не поддерживает резервное копирование с помощью службы теневого копирования томов Это позволяет администраторам разгрузить резервные копии с активного узла и расширить окно резервного копирования. Кроме того, большие конфигурации не связаны требованиями к производительности, согласно которым нужно иметь аппаратную поддержку службы теневого копирования томов для использования резервного копирования с помощью службы теневого копирования томов. Рабочая нагрузка на пассивный узел в основном заключается в копировании и преобразовании журнала. Обе эти операции не ограничены в реальном времени, как кластерный сервер почтовых ящиков на активном узле. Например, активный узел должен своевременно отвечать на запросы клиента. Окно резервного копирования можно расширить, поскольку пассивный узел не имеет ограничений на ответ в реальном времени, а значит позволяет использовать базы данных и почтовые ящики большего размера.
Общий объем данных на резервном носителе уменьшен Первый уровень защиты от повреждения и потери данных в кластерной непрерывной репликации представляет собой пассивное копирование. Таким образом, резервная копия будет задействована только в случае двойного сбоя. Восстановление работоспособности после первого сбоя может происходить достаточно быстро, поскольку восстановление данных при этом не требуется. Восстановление после второго сбоя может занять гораздо больше времени. Все это позволяет создавать полные резервные копии раз в неделю с ежедневными добавочными резервными копиями. Это уменьшает общий объем данных, которые необходимо размещать на резервном носителе.
Кластер с непрерывной репликацией может сочетаться с резервной непрерывной репликацией. Кластер с непрерывной репликацией может сочетаться с кластером с единым хранилищем для локальной репликации групп хранения в основном центре обработки данных (при этом кластер с непрерывной репликацией обеспечивает высокую доступность) и удаленной репликации в дополнительном или резервном центре данных (при этом кластер с единым хранилищем обеспечивает доступность сайта). Дополнительный центр данных может иметь пассивный узел в отказоустойчивом кластере для размещения целевых объектов резервной непрерывной репликации. Такой кластер называется резервным, поскольку он не содержит кластерных серверов почтовых ящиков, но в случае сбоя на нем можно быстро подготовить кластерный сервер почтовых ящиков. Если происходит сбой основного центра обработки данных или он становится недоступным по каким-либо другим причинам, целевые объекты резервной непрерывной репликации, размещенные в резервном кластере, можно быстро активировать.
Архитектура ядра кластерной непрерывной репликации
Кластерная непрерывная репликация объединяет следующие элементы:
Возможности перехода на другой ресурс при сбое и виртуализации, предоставляемые отказоустойчивыми кластерами Microsoft
Модель кворума отказоустойчивого кластера, основанная на большинстве, которая применяет файловый ресурс-свидетель для действий кластера
Средства репликации и преобразования журнала транзакций в Exchange 2007
Возможность очереди сообщений на транспортном сервере-концентраторе, называемая транспортной корзиной
Отказоустойчивый кластер Windows
На рисунке ниже видно, что в Exchange 2007 с пакетом обновления 1 (SP1) кластерная непрерывная репликация использует два компьютера (называемые узлами). Эти компьютеры объединены в отдельный отказоустойчивый кластер с Windows Server 2003 с пакетом обновления 2 (SP2) или Windows Server 2008. На узлах отказоустойчивого кластера размещается кластерный сервер почтовых ящиков. Узел, на котором в настоящий момент запущен кластерный сервер почтовых ящиков, называется активным узлом, а узел, на котором не запущен кластерный почтовый сервер, но который является частью кластера, называется пассивным узлом. В результате запланированного обслуживания или незапланированного отключения назначение узла в качестве активного или пассивного может меняться в течение срока жизни отказоустойчивого кластера.
Базовое развертывание кластерной непрерывной репликации
.gif "Архитектура непрерывной репликации кластера")
Отказоустойчивый кластер строится с пмощью службы кластера и конкретного типа модели кворума кластера:
В Windows Server 2008 рекомендуемый кворум называется кворумом большинства общих файловых ресурсов и узлов. Для получения подробных указаний по конфигурации отказоустойчивого кластера для использования модели кворума большинства общих файловых ресурсов и узлов см. раздел Настройка кворума большинства общих файловых ресурсов и узлов.
В Windows Server 2003 рекомендуемый кворум называется кворумом набора узлов большинства с файловым ресурсом-свидетелем. Эта модель кворума поддерживается в Windows Server 2003 с пакетом обновления 2 (SP1). Она также доступна в качестве исправления для Windows Server 2003 с пакетом обновления 1 (SP1), которое описывается в статье 921181 базы знаний Майкрософт Доступно обновление, добавляющее файловый ресурс-свидетель и настраиваемое подтверждение соединения кластера для кластеров, состоящих из серверов с Microsoft Windows Server 2003 с пакетом обновления 1 (SP1) (на английском языке). Тем не менее для Exchange 2007 с пакетом обновления 1 (SP1) требуется Windows Server 2003 с пакетом обновления 2 (SP2).
Файловый ресурс-свидетель
Обе из описанных выше моделей кворума используют общий файловый ресурс на третьем компьютере в качестве свидетеля. При этом общий файловый ресурс на третьем компьютере используется для того, чтобы избежать возникновения в кластере сетевого раздела, также известного как синдром расщепления мозга. Синдром расщепления мозга возникает, когда происходит отказ всех сетей, определенных для поддержки внутренних связей, в результате чего узлы не могут получить сигналы синхронизации друг от друга. Синдром расщепления мозга предотвращается установкой требования взаимодействия большинства из этих двух узлов и общего файлового ресурса для поддержки доступности кластерного сервера почтовых ящиков. Когда большинство узлов взаимодействует, говорят, что кластер имеет кворум. Свидетель общего файлового ресурса может находиться на любом компьютере, работающем под управлением операционной системы Windows Server. Версия Windows Server, на которой расположен общий файловый ресурс, не обязательно должна совпадать с версией операционной системы в среде кластера с непрерывной репликацией. Однако рекомендуется размещать его на транспортном сервере-концентраторе на сайте службы каталогов Active Directory, содержащем кластерный сервер почтовых ящиков, так как это упрощает управление.
.gif "note") Примечание. |
|---|
| Общий файловый ресурс для файлового ресурса-свидетеля может размещаться на любом компьютере, работающем в среде распределенной файловой системы (DFS). |
Свидетель общего файлового ресурса использует общий файловый ресурс на компьютере вне кластера, чтобы функционировать как свидетель операций двух узлов, являющихся кластером. Свидетель используется этими двумя узлами для отслеживания того, какой узел управляет кластером. Записная книжка требуется только в том случае, когда два узла не могут связаться друг с другом. Предположим, двухузловый кластерный сервер почтовых ящиков состоит из узла1 и узла2. В таком случае, узел1 — это узел, который может управлять записной книжкой, следовательно, управлять кластером и переводить кластерный сервер почтовых ящиков в оперативный режим. Если узел2 работоспособен, но не может связаться с узлом1, он попытается управлять записной книжкой, но не сможет этого сделать. Эта неспособность узла2 управлять записной книжкой означает, что он не должен пытаться переводить кластерный сервер почтовых ящиков в оперативный режим.
Если два узла способны взаимодействовать друг с другом, записная книжка не нужна и может находиться в автономном режиме. Однако последующий сбой любого узла выведет кластерный сервер почтовых ящиков из оперативного режима, если свидетель общего файлового ресурса недоступен.
Общий файловый ресурс не поддерживает другие состояния, кроме описанных выше. Поэтому обмен всеми сведениями о настройке кластера происходит между двумя узлами. Важно понимать следующее: так как узел1 доступен, а узел2 недоступен, узел2 не может стать доступным до тех пор, пока он не свяжется с узлом1, даже если он может связываться со свидетелем общего файлового ресурса.
Поддержка свидетеля общего файлового ресурса предоставляет периодическую проверку доступа к свидетелю общего файлового ресурса. Если проверка доступа заканчивается ошибкой, создается событие. Это событие может быть собрано, обнаружено и указано в отчете системы наблюдения. Это позволяет обслуживающему персоналу исправить неполадку перед возникновением ситуации, которая может вызвать отключение по причине второго последовательного сбоя.
Доступ к общему файловому ресурсу предоставляется при следующих условиях:
Если узел кластера переходит в оперативный режим, но доступен только один узел кластера;
Если неполадка с сетевым подключением препятствует с кластером связи узла, котороый ранее был доступным;
Если узел кластера покидает кластер;
Периодически с целью проверки. Частоту можно настроить.
Вследствие этого нагрузка на общий файловый ресурс небольшая. В результате отдельный сервер может предоставлять общий ресурс для нескольких сред кластера с непрерывной репликацией. Тем не менее для каждой среды кластера с непрерывной репликацией на этом сервере требуется собственная выделенная папка и общая папка.
Соглашения для свидетеля общего файлового ресурса
Кластер с непрерывной репликацией — это двухузловое решение, использующее либо кворум набора узлов большинства с файловым ресурсом-свидетелем, либо кворум большинства общих файловых ресурсов и узлов вместо третьего узла (или большего количества узлов) в кластере, который требуется в традиционных кластерах набора узлов большинства. Географически рассредоточенная среда кластерной непрерывной репликации подразумевает разворачивание двух центров данных, при которых активный узел разворачивается в основном центре данных, а пассивный узел разворачивается во вторичном центре данных. Таким образом, при географически рассредоточенной среде кластерной непрерывной репликации существует два варианта размещения общих файловых ресурсов: размещение в основном центре данных и размещение в третьем центре данных.
При первом варианте необходимо настроить общий файловый ресурс на транспортном сервере-концентраторе в основном центре данных. Рекомендуется использовать транспортный сервер-концентратор, потому что он позволяет администратору обмена сообщениями управлять и отслеживать отключения общего файлового ресурса. Опыт работы и отзывы пользователей показывают, что наиболее частые типы сбоев в сетевых службах происходят в топологиях глобальной сети (WAN). Размещение общего файлового ресурса в основном центре данных выгодно, поскольку это предотвращает прерывание работы служб вследствие сетевых сбоев между двумя центрами данных. При использовании этой конфигурации в случае отключения основного центра данных не произойдет автоматического перехода на другой ресурс. Однако она гарантирует, что большинство файлов в отказоустойчивом кластере не будут затронуты при возникновении сетевого сбоя между основным и вторичным центрами данных.
При втором варианте необходимо настроить общий файловый ресурс на роли управляемого сервера в третьем физическом сайте. Роль управляемого сервера - это сервер, который поддерживается и обслуживается точно так же, как другие серверы, необходимые для обеспечения работы службы обмена сообщениями. Примером роли управляемого сервера служит транспортный сервер-концентратор в основном центре данных. Третьим физическим сайтом может быть филиал или третий центр данных. Необходимым требованием в этой конфигурации является наличие сетевой инфраструктуры между третьим сайтом и основным центром данным и вторичным центром данных с низкой задержкой и высокой надежностью.
Репликация и воспроизведение журнала транзакций
Репликация и воспроизведение журнала транзакций используется для копирования измененных данных и обновления пассивной копии базы данных. Репликация использует журнал изменений, создаваемый механизмом расширяемого хранилища (ESE). Этот журнал изменений представляется в виде последовательности файлов журнала фиксированного размера, равного 1 мегабайту (МБ). При создании каждого журнала функция репликации копирует журналы на пассивный узел. Механизм репликации является асинхронным относительно оперативной базы данных. Когда журналы достигают пассивного узла, сначала проверяется отсутствие повреждений, затем они воспроизводятся на копии базы данных, которая хранится на пассивном узле. В процессе воспроизведения изменения, описанные в журнале изменений, заносятся в базу данных пассивного узла. В результате база данных пассивного узла соответствует рабочей базе данных лишь с небольшой задержкой по времени.
Поскольку данные реплицированы между узлами, кластерный сервер почтовых ящиков может работать на любом узле в кластере. Эта особенность обеспечивает повышенную доступность, поскольку отключения по расписанию и случайные сбои одного узла не вызывают обширного отказа кластерного сервера почтовых ящиков. Кроме того, отключения для обслуживания хранилища на одном узле не затронут доступность другого узла кластерного сервера почтовых ящиков. Если предположить, что общий файловый ресурс все еще доступен и может связываться с пассивным узлом, отключение активных узлов вызовет перемещение кластерного сервера почтовых ящиков на оставшийся узел с сохранением работоспособности.
В среде кластерной непрерывной репликации папка файла журнала транзакций на активном узле становится общей с помощью стандартного способа предоставления общего доступа к файлам Windows. Объект GUID группы хранения используется в качестве имени общего ресурса, а в конец имени общего ресурса добавляется знак доллара ($). Служба репликации Microsoft Exchange на пассивном узле подключается к общему ресурсу на активном узле и копирует или извлекает файлы журнала с помощью протокола SMB (Server Message Block). Затем пассивный узел проверяет файл журнала и воспроизводит его на копии базы данных на пассивном узле.
| Примечание. |
|---|
| Трафик репликации файла журнала транзакций по протоколу SMB не шифруется. При необходимости шифрования трафика можно использовать протокол IPsec. Только репликация файла журнала транзакций использует протокол SMB. Повторное заполнение пассивной копии происходит с использованием интерфейса API приложения резервного копирования ESE и представляет собой обмен данными без шифрования. Если необходимо шифровать данные, можно использовать протокол IPsec. |
Непрерывная репликация через избыточные кластерные сети
В окончательной первоначальной версии (RTM) Microsoft Exchange Server 2007 все копирование файлов журналов транзакций и начальное заполнение в среде кластерной непрерывной репликации происходит через общедоступную сеть. Эта конфигурация имеет следующие ограничения:
Если пассивный узел недоступен в течение нескольких часов, может возникнуть значительное количество журналов, которые необходимо передать. Когда пассивный узел доступен, перемещение этих журналов должно быть выполнено как можно быстрее. При копировании этих журналов в общей сети перемещение журналов совмещается с клиентским трафиком. Это оказывает влияние на клиентский трафик и замедляет повторную синхронизацию.
При сбоях общей сети происходит сбой с потерей данных, хотя данные журналов все еще остаются доступными.
Использование изолированной сети для обмена данными журналов позволяет обезопасить данные обмена сообщениями без шифрования и связанной с ним потерей производительности.
При некоторых обстоятельствах может происходить зацикливание журналов. В этих случаях система испытывает необычно высокую нагрузку репликации. Это может привезти к перегрузке клиента, если данные журналов необходимо передать по той же сети, которая используется для обмена сообщениями между клиентами.
Эти проблемы не будут возникать с одинаковой частотой. Однако первая из них будет гарантированно происходить раз в несколько месяцев, поскольку пассивные узлы переходят в автономный режим для запланированного обслуживания.
В Exchange 2007 с пакетом обновления 1 (SP1) последствия этих проблем сводятся к минимуму, что позволяет администраторам создавать одну или несколько смешанных сетей в кластере (например, кластерную сеть, поддерживающую трафик синхронизации внутреннего кластера и клиентский трафик) для доставки журналов. Exchange 2007 с пакетом обновления 1 (SP1) также позволяет администраторам указывать определенную сеть, которая будет использоваться для заполнения.
| Примечание. |
|---|
| Кластерные сети для доставки журналов и начального заполнения должны настраиваться как смешанные сети. Смешанной сетью является любая кластерная сеть, настроенная для кластерного (пульсового) трафика и трафика клиентского доступа. Дополнительно при настройке сетевого адаптера с именем узла непрерывной репликации администратор должен установить флажок Зарегистрировать адреса этого подключения в DNS в диалоговом окне Дополнительные параметры TCP/IP. Кроме того, необходимо использовать статические записи DNS или записи файла Hosts на каждом узле для поддержки разрешения имен для созданных имен узла. Сервер DNS, используемый сетевым адаптером, может быть расположен в общей или частной сети; однако вне зависимости от его расположения оба узла должны иметь к нему доступ для разрешения имен. Кроме того, в Windows Server 2008 на сетевых адаптерах, которые используются для доставки журналов или заполнения, должен быть включен NetBIOS. |
Поддержка копирования файлов журнала в смешанной сети настраивается с использованием нового командлета с именем Enable-ContinuousReplicationHostName. Аналогично, отключение этого свойства производится с использованием командлета Disable-ContinuousReplicationHostName .
После создания кластерного сервера почтовых ящиков в среде кластерной непрерывной репликации администратор может запустить Enable-ContinuousReplicationHostName на обоих узлах кластера и назначить дополнительные IP-адреса и имена, которые будут созданы в предназначенных для этого кластерных группах, соответствующих каждому из узлов. После выполнения этой операции служба репликации Microsoft Exchange будет использовать вновь созданную сеть для копирования журналов сразу же после успешной настройки и после подтверждения того, что новая сеть готова к работе. При создании нескольких новых сетей служба репликации Microsoft Exchange выберет одну из них случайным образом. Если выбранная сеть окажется недоступной, служба репликации Microsoft Exchange автоматически будет использовать другие сети репликации. Если ни одна из них не будет доступна, то в течение 5 минут служба репликации приступит к использованию общей сети для доставки журналов. (Служба репликации Microsoft Exchange проводит обнаружение сети каждые 5 минут.) Когда предпочитаемая сеть репликации вновь становится доступной, служба репликации Microsoft Exchange автоматически вернется к ней для доставки журналов.
Дополнительные сведения об этих командлетах приведены в разделах Enable-ContinuousReplicationHostName и Disable-ContinuousReplicationHostName.
Поддержка начального заполнения через резервную кластерную сеть настраивается при помощи командлета Update-StorageGroupCopy, обновленного в Exchange 2007 с пакетом обновления 1 (SP1) новым параметром DataHostNames. Этот параметр используется для указания того, какая именно кластерная сеть должна использоваться для начального заполнения. Дополнительные сведения об изменениях командлета Update-StorageGroupCopy в Exchange 2007 SP1 приведены в разделе Update-StorageGroupCopy.
После создания кластерной сети для непрерывной репликации можно использовать командлет Get-ClusteredMailboxServerStatus для просмотра обновленных сведений о кластерных сетях, задействованных в процессе непрерывной репликации. В состав новых выходных данных будут входить:
OperationalReplicationHostNames:{Host1,Host2,Host3}
FailedReplicationHostNames:{Host4}
InUseReplicationHostNames:{Host1,Host2}
Дополнительные сведения об изменениях командлета Get-ClusteredMailboxServerStatus в Exchange 2007 с пакетом обновления 1 (SP1) приведены в разделе Get-ClusteredMailboxServerStatus.
Транспортная корзина
Массив потерянных данных, возникающий во время автоматического восстановления, впоследствии автоматически восстанавливается с помощью возможности транспортного сервера-концентратора, которая называется транспортной корзиной. Транспортная корзина для определенной базы данных должна находиться на всех транспортных серверах-концентраторах на сайте Active Directory, который содержит кластерный сервер почтовых ящиков. При прохождении сообщения через транспортные серверы-концентраторы на пути к кластерному серверу почтовых ящиков в среде с кластерной непрерывной репликацией его копия хранится в очереди транспорта (mail.que) до завершения интервала репликации. Транспортная корзина является необходимым компонентом для развертывания кластерной непрерывной репликации. Транспортная корзина использует избыточность среды для восстановления некоторых данных, затронутых переходом на другой ресурс при сбое. В частности, транспортные серверы-концентраторы поддерживают очередь недавно доставленной почты. Эта очередь ограничена временем хранения почты и общим количеством используемого пространства. Если произошедший переход на другой ресурс не прошел без потерь, кластерная непрерывная репликация на кластерном сервере почтовых ящиков автоматически требует от каждого транспортного сервера-концентратора на сайте Active Directory повторно предоставить почту для очереди транспортной корзины. Хранилище данных автоматически удаляет дубликаты и повторно доставляет потерянную почту.
Транспортная корзина используется для кластерной непрерывной репликации и для локальной непрерывной репликации в Exchange 2007 с пакетом обновления 1 (SP1). Она не включена для резервной непрерывной репликации или в кластерах с единым хранилищем Для кластера с непрерывной репликацией необходимым условием сохранения сообщения электронной почты в транспортной корзине является наличие по крайней мере одного получателя, чей почтовый ящик находится на кластерном сервере почтовых ящиков в среде кластера с непрерывной репликацией или (для пакета обновления SP1) в базе данных почтовых ящиков с локальной непрерывной репликацией.
Транспортная корзина создана для защиты от потерь данных путем предоставления администратору возможности настройки кластерной непрерывной репликации для автоматического перехода сервера в оперативный режим на другом узле с ограниченным объемом потерянных данных. Если это происходит, система автоматически производит повторную доставку всех текущих сообщений электронной почты, отправляемых пользователям на этом сервере, с помощью транспортной корзины, в которой все еще хранятся эти сообщения. Это помогает предотвратить потерю данных в большинстве случаев. В среде кластера с непрерывной репликацией запрос на повторную доставку из корзины транспорта на всех транспортных серверах-концентраторах на сайте выполняется автоматически. В окончательной первоначальной версии (RTM) Exchange 2007 интервал повторной попытки задан жестко и равен 7 дням. В Exchange 2007 с пакетом обновления 1 (SP1) интервал задается параметром MaxDumpsterTime. В среде локальной непрерывной репликации запрос на повторную доставку из корзины транспорта на всех транспортных серверах-концентраторах на сайте является частью задачи Restore-StorageGroupCopy.
Ниже приведены случаи, при которых потери данных не устраняются при помощи транспортной корзины:
Папка «Черновики» любых клиентов Microsoft Outlook работает в оперативном режиме;
Встречи, обновления контактов, обновления свойств, задачи и обновления задач;
Исходящая почта, находящаяся в пути между клиентом и транспортным сервером-концентратором. Существует период времени, во время которого сообщение электронной почты находится только на сервере почтовых ящиков отправителя.
Развертывание кластерной непрерывной репликации
Развертывание кластерной непрерывной репликации похоже на развертывание изолированного сервера Exchange и на развертывание кластера единой копии. Дополнительные сведения о кластерах единой копии приведены в разделе Кластеры единой копии. Однако существуют большие отличия, о которых необходимо знать при развертывании кластерной непрерывной репликации. Рекомендуется ознакомиться со следующими разделами перед разработкой и развертыванием кластерной непрерывной репликации:
После подготовки к развертыванию кластерной непрерывной репликации можно начать выполнять этапы каждой фазы установки, описанные в следующих разделах:
Улучшения, внесенные в кластер с непрерывной репликацией в Exchange 2007 с пакетом обновления 1 (SP1)
В Exchange 2007 с пакетом обновления 1 (SP1) входит несколько улучшений для кластерной непрерывной репликации, включая добавленные элементы пользовательского интерфейса консоли управления Exchange, улучшенное отображение состояния и наблюдение, а также повышенную производительность.
Улучшения консоли управления Exchange
В Exchange 2007 с пакетом обновления 1 (SP1) было добавлено несколько новых элементов пользовательского интерфейса для улучшения управления свойствами высокой доступности, включая кластерную непрерывную репликацию. В число этих улучшений входят:
Пользовательский интерфейс транспортной корзины Новая вкладка Глобальные параметры добавлена к транспортному узлу-концентратору в рабочей области Конфигурация организации . На этой вкладке имеется страница Параметры транспорной настройки , при помощи которой настраиваются параметры транспортной корзины для организации:
Максимальный размер на группу хранения (МБ) Это поле определяет максимальный размер очереди транспортной корзины для каждой группы хранения.
Максимальный срок хранения (дней) Это поле определяет срок хранения сообщения электронной почты в очереди транспортной корзины.
Непрерывная репликация Дополнительные элементы управления интерфейса пользователя, которые добавлены к консоли управления Exchange и позволяют администратору приостанавливать, возобновлять, обновлять и восстанавливать непрерывную репликацию. Эти элементы управления эквиваленты по использованию следующим командлетам командной консоли Exchange :
Suspend-StorageGroupCopy
Resume-StorageGroupCopy
Update-StorageGroupCopy
Restore-StoreGroupCopy
Эти командлеты и соответствующие им задачи консоли управления Exchange можно использовать для управления непрерывной репликацией как в среде локальной непрерывной репликации, так и в среде кластерной непрерывной репликации.
Улучшения отображения состояния и наблюдения
В Exchange 2007 с пакетом обновления 1 (SP1) также внесены некоторые изменения, разработанные для улучшения управления Exchange 2007. Эти изменения улучшают свойства кластерной отчетности в Exchange 2007 RTM и содержат дополнительные функции, разработанные для профилактического наблюдения за средами непрерывной репликации. В частности, в результате изменений и улучшений исправлены известные недостатки командлета Get-StorageGroupCopyStatus, введен новый командлет Test-ReplicationHealth и обеспечено лучшее отображение окна потерь, покрываемых транспортной корзиной.
Улучшения командлета Get-StorageGroupCopyStatus
В окончательной первоначальной версии (RTM) сервера Exchange 2007 было обнаружено несколько ситуаций, при которых отчет о состоянии, созданный командлетом Get-StorageGroupCopyStatus, и показания счетчиков производительности непрерывной репликации были неточными или вводили в заблуждение.
Группа хранения, не являющаяся активной (например,не изменяющаяся), может сообщать о том, что она работоспособна, не являясь на самом деле работоспособной. Такая ситуация может возникать из-за того, что неисправность нельзя определить до воспроизведения журнала.
Во время инициализации репликации ее состояние оценивается повторно и может не быть точным. Состояние обновляется после завершения инициализации.
Значение поля LastLogGenerated может быть неверным при отключенной базе данных группы хранения.
Если в потоке журналов отсутствует один или несколько журналов, пассивная копия повторяет попытку восстановления, что вызывает переключение состояния репликации между состоянием сбоя и работоспособным состоянием. В этом случае очереди воспроизведения и копирования будут продолжать расти.
В очень редких случаях журнал может успешно пройти проверку, но вызвать сбой при воспроизведении. В этой ситуации система будет поочередно сообщать о сбое и работоспособном состоянии при попытках восстановления. В этом случае очереди воспроизведения и копирования будут продолжать расти.
Командлет Get-StorageGroupCopyStatus также улучшен путем добавлением новых сведений о состоянии для сред кластерной непрерывной репликации:
Командлет Get-StorageGroupCopyStatus сообщает о значении ServiceDown состояния SummaryCopyStatus, когда служба репликации Microsoft Exchange на целевом компьютере не доступна через сеть.
Командлет Get-StorageGroupCopyStatus сообщает о значении Initializing состояния SummaryCopyStatus, когда служба репликации Microsoft Exchange на целевом компьютере еще не завершила начальную проверку при запуске. Кроме того, создан новый счетчик производительности, показывающий это состояние как логическое значение.
Командлет Get-StorageGroupCopyStatus сообщает для состояния SummaryCopyStatus значение Synchronizing, если добавочное заполнение не завершено.
Новые значения состояния SummaryCopyStatus отображаются только при использовании версии средств управления Exchange из состава Exchange 2007 с пакетом обновления 1 (SP1). При использовании версии средств управления Exchange из состава Exchange 2007 RTM любое из предыдущих состояний будет отображено как "сбой".
Командлет Test-ReplicationHealth
В Exchange 2007 с пакетом обновления 1 (SP1) введен новый командлет Test-ReplicationHealth. Этот командлет разработан для профилактического наблюдения за непрерывной репликацией и конвейером непрерывной репликации. Командлет Test-ReplicationHealth проверяет все аспекты репликации, кластерные службы, репликацию группы хранения и состояние преобразования, чтобы составить полный обзор системы репликации. В частности, при работе в узле кластера командлет Test-ReplicationHealth выполняет проверки, указанные в таблице ниже.
Проверки, выполняемые командлетом Test-ReplicationHealth
| Проверка | Описание |
|---|---|
Состояние сети кластера |
Проверяет, что все управляемые кластером сети, имеющиеся на локальном узле, запущены. Эта проверка выполняется только в среде кластерной непрерывной репликации. |
Состояние группы кворума |
Проверяет работоспособность кластерной группы, содержащей ресурс кворума. Эта проверка выполняется только в среде кластерной непрерывной репликации. |
Состояние кворума общих файловых ресурсов |
Проверяет доступность значения FileSharePath, используемого кворумом набора большинства узлов со свидетелем общего файлового ресурса. Эта проверка выполняется только в среде кластерной непрерывной репликации. |
Состояние кластерного сервера почтовых ящиков |
Проверяет работоспособность кластерного сервера почтовых ящиков, подтверждая, что все ресурсы группы находятся в сети. Эта проверка выполняется только в среде кластерной непрерывной репликации. |
Состояние узла |
Проверяет, чтобы ни один из узлов кластера не находился в состоянии паузы. Эта проверка выполняется только в среде кластерной непрерывной репликации. |
Состояние регистрации в DNS |
Проверяет успешность прохождения регистрации в DNS всеми интерфейсами управляемой кластером сети, для которых флажок Для успешного выполнения требуется регистрация в DNS установлен. Эта проверка выполняется только в среде кластерной непрерывной репликации. |
Состояние службы репликации |
Проверяет работоспособность службы репликации Microsoft Exchange на локальном узле. |
Приостановка копии группы хранения |
Проверяет приостановку непрерывной репликации для всех групп хранения, участвующих в процессе непрерывной репликации. |
Сбой копии группы хранения |
Проверяет нахождение какой-либо копии группы хранения в состоянии сбоя. |
Длина очереди репликации группы хранения |
Проверяет, не превосходит ли длина очереди репликации какой-либо группы хранения рекомендованные пороги. В настоящее время этими порогами являются:
|
Отключение баз данных после сбоя |
Проверяет отключение или сбой каких-либо баз данных при переходе на другой ресурс после сбоя. Проверяются только базы данных, для которых произошел сбой при переходе на резервный ресурс. |
Улучшения производительности
В Exchange 2007 с пакетом обновления 1 (SP1) выполнены улучшения производительности, эффективно влияющие на развертывание систем с высокой доступностью. В число этих улучшений входят:
Сокращение операций ввода-вывода на дисках, содержащих пассивные копии групп хранения в средах непрерывной репликации В Exchange 2007 с пакетом обновления 1 (SP1) архитектура непрерывной репликации изменена таким образом, что кэш базы данных теперь сохраняется на пассивном узле между пакетами действий по воспроизведению журналов. Сохранение кэша базы данных между пакетами действий по преобразованию журналов позволяет службе репликации Microsoft Exchange использовать свойства кэширования баз данных ESE, что, в свою очередь, сокращает количество дисковых операций ввода-вывода, совершающихся в отношении логических номеров устройств (LUN) пассивной копии. Напротив, в Exchange 2007 RTM создается новый кэш базы данных для каждого пакета действий по преобразованию журналов, что в некоторых случаях увеличивает количество дисковых операций ввода-вывода в пассивном узле в два-три раза по сравнению с дисковыми операциями ввода-вывода в активном узле.
Более быстрое перемещение кластерных серверов почтовых ящиков между узлами в среде кластерной непрерывной репликации Эти улучшения позволяют кластерным серверам почтовых ящиков перемещаться между узлами за две или менее минуты. Сюда относятся перемещения, выполняемые администратором (использующим командлет Move-ClusteredMailboxServer ), и переходы на другие ресурсы в случае сбоя, управляемые службой кластеров. Для выполнения быстрых перемещений в среде кластерной непрерывной репликации базы данных переводятся в автономный режим без очистки кэша баз данных. Такой подход сокращает время простоя, который происходит, когда кластерный сервер почтовых ящиков перемещается на другой узел.
Использование резервной непрерывной репликации с кластерной непрерывной репликацией
Резервная непрерывная репликация - это новая функция, введенная в Exchange 2007 с пакетом обновления 1 (SP1). Резервная непрерывная репликация расширяет существующие свойства непрерывной репликации и предоставляет новые ситуации доступности данных для серверов почтовых ящиков Exchange 2007 . Резервная непрерывная репликация использует ту же технологию доставки журналов и воспроизведения, которую используют локальная непрерывная репликация и кластерная непрерывная репликация для обеспечения дополнительных функций развертывания и настройки.
Резервная непрерывная репликация позволяет использовать непрерывную репликацию для репликацию данных сервера почтовых ящиков с отдельного сервера почтовых ящиков (с или без локальной непрерывной репликации) или с кластерного сервера почтовых ящиков в среде резервной непрерывной репликации или кластерной непрерывной репликации.
Процесс активации копий данных сервера почтовых ящиков, которые создаются и поддерживаются резервной непрерывной репликацией, выполняется вручную и разработан для использования в случаях значительных сбоев (а не для незначительных отключений сервера, которые решаются методом перезапуска или другими быстрыми способами). Можно активировать цель резервной непрерывной репликации, используя переносимость базы данных, средство восстановления сервера (Setup /m:RecoverServer) или, если сервер почтовых ящиков является кластерным, средство восстановления кластерного сервера почтовых ящиков (Setup /RecoverCMS). Выбранный вариант будет зависеть от настройки и типа произошедшего сбоя.
Дополнительные сведения о резервной непрерывной репликации привелены в разделе Резервная непрерывная репликация.
Дополнительные сведения
Вопросы использования кластерной непрерывной репликации как части плана обеспечения высокой доступности данных и устойчивости к отказам рассматриваются в следующих разделах: