Резервная непрерывная репликация (Standby Continuous Replication, SCR) — это новая функция, появившаяся Exchange 2007 с пакетом обновления 1 (SP1). Эта модель репликации расширяет возможности репликации, присутствовавшие в окончательной первоначальной версии Exchange 2007, и позволяет реализовывать новые случаи повышения уровня доступности данных для серверов почтовых ящиков Exchange 2007. При резервной непрерывной репликации используются те же технологии доставки и воспроизведения журнала, что при локальной непрерывной репликации (LCR) и при кластерной непрерывной репликации (CCR). Это позволяет расширить возможности развертывания и настройки кластеров. Резервная непрерывная репликация в ждущем режиме похожа на локальную непрерывную репликацию и кластерную непрерывную репликацию, но имеет и некоторые особенности:

• резервная непрерывная репликация поддерживает несколько точек назначения для одной группы хранения. Локальная непрерывная репликация и кластерная непрерывная репликация поддерживают только одну точку назначения для группы хранения (пассивная копия);
  
  
• при резервной непрерывной репликации у администратора есть возможность указать время задержки репликации. Это бывает полезно во многих случаях. Например, в результате сбоя с потерей данных происходит передача управления от узла А узлу Б. Если потерянные файлы журнала были воспроизведены на удаленном узле М, нужно будет провести повторное начальное заполнение узла М. Если же файлы журнала были скопированы, но не были воспроизведены, их можно удалить, а затем скопировать и воспроизвести новые файлы журнала. В последнем случае выполнять повторное начальное заполнение узла М не потребуется;
  
  
• выполнить резервное копирование копии резервной непрерывной репликации невозможно, в отличие от кластерной непрерывной репликации и локальной непрерывной репликации. При использовании резервной непрерывной репликации обновляются заголовки копий резервной непрерывной репликации, а файлы журналов обрываются при создании резервных копий на основе исходных групп хранения.
  
  

Модель резервной непрерывной репликации позволяет выполнять непрерывную репликацию данных одного или нескольких серверов почтовых ящиков в средах с кластером с единым хранилищем или с кластерной непрерывной репликацией.

Активация копий данных сервера почтовых ящиков, создаваемых и поддерживаемых с помощью резервной непрерывной репликации, выполняется вручную и только в случае серьезных сбоев (к таким сбоям не относятся обычные остановки в работе серверов, устраняемые путем перезагрузки или с помощью других простых методов). Активировать созданную с помощью резервной непрерывной репликации копию можно путем переноса базы данных, с помощью параметра командной строки RecoverServer (Setup /m:RecoverServer) или же, если для хранения базы данных почтовых ящиков используется кластерный сервер, воспользовавшись параметром восстановления кластерных серверов почтовых ящиков (Setup /RecoverCMS). Выбор способа активации зависит от конфигурации среды и типа произошедшего сбоя.

Дополнительные сведения о резервной непрерывной репликации приведены в разделе Резервная непрерывная репликация.

В Windows Server 2008 входят новые функции высокой доступности, поддерживаемые Exchange 2007 с пакетом обновления 1 (SP1). Усовершенствованные функции работы с отказоустойчивыми кластерами в Windows Server 2008 (в Windows Server 2003 и более ранних версиях они назывались кластерами серверов) позволяют упростить принципы функционирования кластеров и делают кластеры более безопасными и устойчивыми к сбоям. Кроме того, установка кластеров и управление ими стали еще проще, а внутренние компоненты хранения данных, работы в сети и обеспечения безопасности кластеров также усовершенствованы. Полный список усовершенствованных функций отказоустойчивых кластеров приведен на странице Отказоустойчивые кластеры в Windows Server 2008 (на английском языке).

Помимо поддержки Windows Server 2008 в качестве операционной системы, сервер Exchange 2007 с пакетом обновления 1 (SP1) также поддерживает описанные ниже функции отказоустойчивых кластеров, реализованные в ОС Windows Server 2008. Эти функции также поддерживаются в программе установки Exchange 2007 — как в версии для командной строки (Setup.com), так и в версии с графическим интерфейсом (программе Setup.exe или мастере установки Exchange Server 2007).

Поддержка отказоустойчивых кластеров с несколькими подсетями

Новые сетевые функции отказоустойчивых кластеров Windows Server 2008 значительно отличаются от механизмов, использовавшихся в кластеризованных системах ранее. Например, в отказоустойчивых кластерах Windows Server 2008 появилась поддержка нескольких подсетей. При работе в отказоустойчивом кластере Windows Server 2008 Exchange 2007 с пакетом обновления 1 (SP1) позволяет двум географически распределенным кластерам в случае сбоя передавать управление между двумя подсетями. Поддержка такой функции распространяется как на кластеры с единым хранилищем, так и на серверы почтовых ящиков, работающие в среде кластерной непрерывной репликации.

Windows Server 2008 — это первая операционная система, механизм обеспечения отказоустойчивости кластеров которой позволяет размещать отдельные узлы кластера в различных маршрутизируемых сетях. Для реализации такой модели необходимо, чтобы ресурсы, зависящие от ресурсов IP-адресов (например, ресурсы сетевых имен) использовали логику на базе ИЛИ, поскольку маловероятно, что у каждого из узлов кластера будет прямое локальное подключение ко всем сетям, известным кластеру. В случае возникновения сбоев в работе служб или приложений для передачи управления удаленным узлам приходится обращаться к ресурсам IP-адресов или сетевых имен.

Важно!
Все узлы в кластерах с единым хранилищем и средах кластерной непрерывной репликации должны принадлежать одному и тому же сайту Active Directory. Хотя отказоустойчивые кластеры Windows Server 2008 поддерживают ситуации, в которых узлы кластера могут относиться к различным сайтам Active Directory, сервер Exchange 2007 такие конфигурации не поддерживает.

При использовании отказоустойчивых кластеров с несколькими подсетями IP-адреса, связанные с ресурсами сетевых имен, динамически регистрируются в системе DNS (если она настроена на динамические обновления) при подключении соответствующих устройств к сети. Поэтому клиенты получают IP-адреса только находящихся в сети устройств. Поскольку узлы кластера могут располагаться в различных маршрутизируемых сетях, а для взаимодействия между ними теперь используются надежно поддерживающие сеансы протоколы, реализованные на базе протокола UDP (одноадресная передача), требования к сети, действовавшие для географически распределенных кластеров Windows Server 2003, не применимы к Windows Server 2008. В результате организации получили возможность развертывать среды с кластерами с единым хранилищем или кластерной непрерывной репликацией в двух физических центрах хранения данных без необходимости объединять подсети с помощью виртуальных сетей.

Когда в географически распределенной по нескольким подсетям среде отказоустойчивых кластеров происходит передача управления, имя сервера почтовых ящиков сохраняется, а IP-адрес освобождается. Поэтому время возобновления доступа к серверу для клиентов и других серверов зависит от скорости распространения нового IP-адреса в системе DNS. В некоторых случаях распространение изменений DNS может происходить не очень быстро. Поэтому рекомендуется установить значение срока жизни (TTL) записи DNS для сервера почтовых ящиков в кластерной среде равным 10 минутам.

Хотя внутренним клиентам Microsoft Outlook не требуется обновление профилей для подключения по новому IP-адресу, им все равно нужно дождаться очистки локального кэша DNS, чтобы имя сервера почтовых ящиков было сопоставлено с новым IP-адресом. После распространения IP-адреса среди необходимых серверов DNS кэш DNS клиентов Outlook можно очистить с помощью следующей команды, выполненной на стороне клиента.

	Копировать код
ipconfig /flushdns

Поддержка DHCP-IPv4

Поддержка IPv6

Windows Server 2008 и служба кластеров поддерживают протокол IPv6, в том числе IP-адреса в формате IPv6 и IP-адреса в формате IPv4, причем в рамках одного кластера возможно одновременное использование ресурсов IP-адресов обоих форматов. Кроме того, отказоустойчивые кластеры поддерживают протокол ISATAP (Intra-site Automatic Tunneling Addressing Protocol), а также IP-адреса формата IPv6, допускающие динамическую регистрацию в DNS (записи узлов AAAA и зону обратного просмотра IP6.ARPA). В настоящее время имеется три типа адресов в формате IPv6: глобальный адрес, локальный адрес сайта и адрес канала. Динамическая регистрация DNS не работает с адресами каналов, поэтому такие адреса нельзя использовать в кластере.

Примечание.

IP-адреса и диапазоны IP-адресов версии 6 (IPv6) поддерживаются только в том случае, если на компьютере под управлением Windows Server 2008 развернут Exchange 2007 с пакетом обновления 1 (SP1) и включены протоколы IP версии 6 и IP версии 4, а сеть поддерживает IP-адреса обеих версий. Если в этой конфигурации развернут Exchange 2007 с пакетом обновления 1 (SP1), все роли сервера могут обмениваться данными с устройствами, серверами и клиентами, использующими IP-адреса версии 6. Если система Windows Server 2008 установлена в конфигурации по умолчанию, поддержка протоколов IP версии 4 и IP версии 6 включена. Если Exchange 2007 с пакетом обновления 1 (SP1) установлен на компьютер под управлением Windows Server 2003, IP-адреса версии 6 не поддерживаются. Дополнительные сведения о поддержке IP-адресов версии 6 в Exchange 2007 с пакетом обновления 1 (SP1) приведены в разделе Поддержка протокола IP версии 6 в сервере Exchange Server 2007 с пакетом обновления 1 (SP1) и пакетом обновления 2 (SP2).

Настройка отказоустойчивых кластеров и кластеров Exchange

При настройке кластеров с единым хранилищем или кластерной непрерывной репликации в среде Exchange 2007 с пакетом обновления 1 (SP1) следует помнить о следующих ограничениях:

• протоколы IPv6 и DHCP IPv4 поддерживаются только в Windows Server 2008. Ни один из них нельзя использовать при установке Exchange 2007 на компьютер под управлением Windows Server 2003;
  
  
• протокол DHCP IPv6 не поддерживается Windows Server 2008 и службой кластеров. Поэтому он также не поддерживается и Exchange 2007. Поддерживаются только назначенные системой IP-адреса версии 6;
  
  
• система Windows Server 2008 и служба кластеров поддерживают статические IP-адреса версии 6. Тем не менее использовать такие адреса не рекомендуется. Поэтому сервер Exchange 2007 не поддерживает настройку статических IP-адресов версии 6 во время установки;
  
  
• служба кластеров Windows Server 2008 поддерживает туннелирование IPv6 через IPv4, но программа установки Exchange не позволяет создавать ресурсы IP-адресов такого типа.
  
  

Программа установки Exchange 2007 с пакетом обновления 1 (SP1) изменена, и в нее включена поддержка описанных выше изменений. При запуске мастера установки Exchange Server 2007 можно заметить, что в нем появились новые страницы и поля, позволяющие настраивать ресурсы IP-адресов и сетевых имен кластера. Кроме того, были изменены параметры /NewCMS и /RecoverCMS команды Setup.com, и теперь они поддерживают несколько новых дополнительных свойств, перечисленных в следующей таблице.

Дополнительные параметры /NewCMS и /RecoverCMS, добавленные в Exchange 2007 с пакетом обновления 1 (SP1)

Параметр	Описание
CMSIPV4Addresses	Список разделенных запятыми значений для указания одного или двух статических IP-адресов версии 4 кластерного сервера почтовых ящиков. Если указываются два статических адреса, они должны относиться к различным подсетям.
CMSIPV4Networks	Список разделенных запятыми значений для указания одного или двух сетевых имен кластера IPv4. Эти имена будут использоваться при создании ресурсов DHCP-IPv4.
CMSIPV6Networks	Список разделенных запятыми значений для указания одного или двух сетевых имен кластера IPv6. Эти имена будут использоваться при создании ресурсов IPv6. Этот параметр не должен использоваться вместе с параметром CMSIPV4Addresses или CMSIPV4Networks.

Примечание.
Параметры CMSIPV4Addresses и CMSIPV4Networks являются взаимоисключающими.

Параметр CMSIPAddress, который был обязательным параметром /NewCMS и /RecoverCMS в окончательной первоначальной версии Microsoft Exchange Server 2007, по-прежнему можно использовать для указания одного статического IP-адреса версии 4 для кластерного сервера почтовых ящиков. Однако в Exchange 2007 с пакетом обновления 1 (SP1) параметр CMSIPAddress является дополнительным, поскольку для выполнения установки достаточно любого из четырех доступных параметров.

Перечисленные в таблице параметры можно использовать только в Windows Server 2008.

Новые модели кворума в Windows Server 2008

В средах кластерной непрерывной репликации окончательной первоначальной версии Exchange 2007 копирование журналов транзакций и начальное заполнение выполняются по общей сети. У такой конфигурации есть следующие ограничения:

• если пассивный узел недоступен в течение нескольких часов, может накопиться достаточно большое число журналов, которые необходимо передать. Когда узел снова становится доступным, журналы нужно передать как можно быстрее. Копирование журналов по общей сети сильно загружает ее. Это влияет на скорость передачи клиентского трафика и повторной синхронизации;
  
  
• сбой в работе общей сети приводит с серьезным последствиям, даже если доступны данные журналов;
  
  
• использование изолированной сети для пересылки журналов позволяет обеспечить безопасный обмен данными без шифрования и связанных с ним ограничений производительности;
  
  
• в некоторых случаях поток пересылаемых журналов может быть очень велик. Когда это происходит, система активно выполняет репликацию. В таких случаях клиенты могут долго ожидать ответа от сервера, поскольку журналы передаются по той же сети, по которой происходит взаимодействие с пользователями.
  
  

Не все описанные ситуации происходят с одинаковой частотой. Но, например, первая проблема стабильно возникает каждые несколько месяцев, поскольку пассивные узлы периодически отключаются на плановое обслуживание.

Использование Exchange 2007 с пакетом обновления 1 (SP1) позволяет снизить влияние описанных проблем за счет того, что администраторы могут создавать в кластере одну или несколько смешанных сетей для передачи журналов (например, кластерную сеть, пропускающую как внутренний трафик кластера, так и и клиентский трафик). Exchange 2007 с пакетом обновления 1 (SP1) также позволяет администраторам настроить отдельную сеть для начального заполнения.

Примечание.

Сети кластеров, использующиеся для пересылки журналов и начального заполнения, должны настраиваться в виде смешанных сетей. Смешанная сеть — это кластерная сеть, настроенная как для внутреннего трафика (синхронизация кластера и т. д.), так и для клиентского трафика. Кроме того, для сетевого адаптера, настраиваемого с именем узла непрерывной репликации, администратор должен установить в окне Дополнительные параметры TCP/IP флажок Зарегистрировать адреса этого подключения в DNS. Сервер DNS, используемый сетевым адаптером, может находиться как в общей, так и в частной сети. Тем не менее, независимо от этого, сервер должен быть доступен обоим узлам, чтобы разрешение имен выполнялось.

Для настройки параметров копирования файлов журнала в смешанной сети с помощью командной консоли Exchange служит командлет 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 с пакетом обновления 1 (SP1) см. в разделе Update-StorageGroupCopy.

После создания сети кластера для непрерывной репликации можно воспользоваться командлетом Get-ClusteredMailboxServerStatus, чтобы получить обновленные сведения о сетях кластера, настроенных для участия в непрерывной репликации. Выходные данные обновленного командлета включают следующие сведения:

• OperationalReplicationHostNames:{узел_1,узел_2,узел_3}
  
  
• FailedReplicationHostNames:{узел_4}
  
  
• InUseReplicationHostNames:{узел_1,узел_2}
  
  

Дополнительные сведения об изменениях, коснувшихся командлета Get-ClusteredMailboxServerStatus в Exchange 2007 с пакетом обновления 1 (SP1), приведены в разделе Get-ClusteredMailboxServerStatus.

Дополнительные сведения о настройке сетей кластеров для участия в непрерывной репликации в Windows Server 2003 приведены в разделе Включение избыточных сетей кластера для доставки и заполнения журналов в Windows Server 2003.

Дополнительные сведения о настройке сетей кластеров для участия в непрерывной репликации в Windows Server 2008 приведены в разделе Включение избыточных сетей кластера для доставки и заполнения журналов в Windows Server 2008.

Дополнительные сведения об отключении непрерывной репликации для сети кластера приведены в разделе Отключение непрерывной репликации для сети кластера.

В Exchange 2007 с пакетом обновления 1 (SP1) вошли несколько изменений, повысивших управляемость сервера Exchange 2007. Эти изменения позволили усовершенствовать функции создания отчетов о работе кластеров окончательной первоначальной версии Exchange 2007, а также включают возможности профилактического наблюдения за средами непрерывной репликации. В частности, в результате изменений и улучшений исправлены известные недостатки командлета Get-StorageGroupCopyStatus, введен новый командлет Test-ReplicationHealth и предоставляются более точные сведения об интервале потерь для транспортной корзины. Дополнительные сведения об этих функциях контроля и создания отчетов приведены в разделе Отслеживание непрерывной репликации.

Сервер Exchange 2007 с пакетом обновления 1 (SP1) включает множество изменений, повышающих производительность системы, что положительно сказывается на работе инфраструктур высокой доступности. К числу улучшений, коснувшихся производительности, относятся следующие.

• Снижение числа операций ввода-вывода на дисках с пассивными копиями групп хранения в средах с непрерывной репликацией. В Exchange 2007 с пакетом обновления 1 (SP1) архитектура непрерывной репликации была изменена таким образом, чтобы между сеансами воспроизведения журнала на пассивных узлах создавался кэш базы данных. Наличие такого кэша позволяет службе репликации Microsoft Exchange воспользоваться функциями кэширования баз данных расширяемого механизма хранилищ (ESE), что в свою очередь снижает количество операций ввода-вывода на логических номерах устройства (LUN) пассивных копий. В окончательной первоначальной версии Exchange 2007 ситуация была прямо противоположной — кэш базы данных создавался при каждом сеансе воспроизведения журнала, в результате чего количество операций ввода-вывода на пассивном узле иногда в два-три раза превышало количество операций ввода-вывода на активном узле.
  
  Более быстрое перемещение кластерных серверов почтовых ящиков между узлами в среде кластерной непрерывной репликации. Эти усовершенствования позволяют переместить сервер почтовых ящиков с одного узла на другой за две минуты или даже быстрее. Это относится к перемещениям, выполняемым администратором с помощью командлета Move-ClusteredMailboxServer, а также к передачам управления при сбое, управляемым службой кластеров. Для быстрого перемещения в среде кластерной непрерывной репликации база данных отключается от сети без очистки кэша базы данных. В кластерах с единым хранилищем перемещение кластерного сервера почтовых ящиков занимает примерно пять минут. Очистка кэша перед перемещением сервера почтовых ящиков все равно выполняется. Это гибкая очистка кэша, позволяющая клиентам не терять подключение к базе данных. В результате время простоев, связанное с переносом кластерного сервера почтовых ящиков на другой узел, сокращается.
  
  В ходе процесса переключения в журнале два раза регистрируется событие с кодом 9868, указывая на состояние операции очистки, а регистрируемое событие с кодом 113 указывает на состояние репликации. Эти события выглядят примерно следующим образом:
  
  

  Код события: 9868 Источник: MSExchangeIS Категория: общие Тип: Сведения Описание: Попытка очистки кэша для сервера "<Название_сервера_почтовых_ящиков>" привела к тому, что не удается для достичь требуемой глубины контрольной точки для групп хранения (количество групп: 0).

  
  
  

  Код события: 9868 Источник: MSExchangeIS Категория: общие Тип: Сведения Описание: Попытка очистки кэша для сервера "<Название_сервера_почтовых_ящиков>" привела к тому, что не удается для достичь требуемой глубины контрольной точки для групп хранения (количество групп: 2).

  
  
  

  Код события: 113 Источник: MSExchangeRepl Категория: перемещение Тип: Сведения Описание: Очистка кэша банка данных перед перемещением кластерного сервера почтовых ящиков "<Название_сервера_почтовых_ящиков>" не завершена. Данные: группа хранения "<Название_сервера_почтовых_ящиков>\<Название_группы_хранения>": начало глубины контрольной точки — 19, конец — 17. группа хранения "<Название_сервера_почтовых_ящиков>\<Название_второй_группы_хранения>": начало глубины контрольной точки — 19, конец — 13.

  
  
  

Транспортная корзина — это возможность роли транспортного сервера-концентратора. Транспортная корзина служит для хранения очереди сообщений, недавно доставленных получателям, почтовые ящики которых хранятся на серверах в среде кластерной непрерывной репликации. Эта очередь ограничена временем хранения почты и общим количеством используемого пространства. Если в результате сбоя, повлекшего потерю данных, происходит передача управления другому ресурсу, сервер почтовых ящиков автоматически отправляет каждому транспортному серверу-концентратору на сайте Active Directory запрос на повторную отправку сообщений, находящихся в очереди транспортной корзины.

В Exchange 2007 с пакетом обновления 1 (SP1) транспортная корзина усовершенствована следующим образом.

• Поддержка локальной непрерывной репликации. Транспортная корзина поддерживает развертывние локальной непрерывной репликации. В отличие от сред кластерной непрерывной репликации, в которых запрос на повторную доставку сообщений из очереди транспортной корзины автоматически отправляется в рамках процесса по восстановлению данных, в средах локальной непрерывной репликации эта процедура выполняется вручную. В Exchange 2007 с пакетом обновления 1 (SP1) командлет Restore-StorageGroupCopy обновлен, и теперь он позволяет отправлять запросы на повторную доставку сообщений транспортной корзины. Таким образом, когда администратор активирует пассивную копию группы хранения в среде локальной непрерывной репликации, используя командлет Restore-StorageGroupCopy, запрос на передачу для транспортной корзины выполняется в рамках процесса активации.
  
  
• Статистика транспортной корзины. Чтобы администраторы располагали более подробной информацией перед началом восстановления сервера в случае нехватки файлов журнала, транспортная корзина усовершенствована, и теперь в ней хранятся статистические сведения о текущем состоянии всех транспортных серверов-концентраторов, содержащих сообщения, которые относятся к пострадавшей группе хранения. К таким статистическим сведениям относятся число сохранившихся сообщений и время хранения самого старого сообщения на каждом транспортном сервере-концентраторе сайта Active Directory. Эти сведения можно просмотреть, воспользовавшись новым параметром DumpsterStatistics командлета Get-StorageGroupCopyStatus. При запуске командлета Get-StorageGroupCopyStatus с этим параметром выходные данные будут содержать статистику транспортных корзин всех транспортных серверов-концентраторов, а также список недоступных транспортных серверов-концентраторов. Доступные серверы будут перечислены в виде многозначной структуры DumpsterStatistics, а недоступные серверы — в виде многозначной строки DumpsterStatisticsNotAvailable, как показано ниже:
  
  DumpsterStatistics: {концентратор_1 (самая старая отметка времени; число элементов в корзине; размер корзины), концентратор_2 (самая старая отметка времени; число элементов в корзине; размер корзины), концентратор_3 (самая старая отметка времени; число элементов в корзине; размер корзины)}
  
  DumpsterStatisticsNotAvailable: {концентратор_4,концентратор_5}
  
  В приведенном примере «самая старая отметка времени» — это время, когда сообщение было получено транспортным сервером-концентратором, а не время первой доставки сообщения на сервер почтовых ящиков.
  
  В командлет Get-StorageGroupCopyStatus также была добавлена новая многозначная структура OutstandingDumpsterRequests, включающая список транспортных серверов-концентраторов с ожидающими запросами и временным интервалом (низкий–высокий) для ожидающих запросов, как показано в следующем примере:
  
  OutstandingDumpsterRequests: {концентратор_1 (время_низк;время_выс), концентратор_5 (время_низк;время_выс)}
  
  

В Exchange 2007 с пакетом обновления 1 (SP1) у консоли управления Exchange появились новые элементы графического интерфейса, облегчающие управление кластерными серверами почтовых ящиков. К числу таких улучшений относятся следующие.

• Мастер управления кластерным сервером почтовых ящиков. Этот мастер предназначен для перемещения, запуска и остановки кластерного сервера почтовых ящиков в средах с кластером с единым хранилищем и с кластерной непрерывной репликацией. Функции перемещения и остановки также поддерживают дополнительные поля администратора, позволяющие указать причину перемещения или остановки сервера. Использование мастера равносильно выполнению следующих командлетов командной консоли Exchange:
  
  
  • Move-ClusteredMailboxServer
    
    
  • Stop-ClusteredMailboxServer
    
    
  • Start-ClusteredMailboxServer
    
    
• Управление непрерывной репликацией. В консоль управления Exchange были добавлены дополнительные элементы, позволяющие администратору приостановить, возобновить, обновить и восстановить непрерывную репликацию. Использование этих элементов равносильно выполнению следующих командлетов командной консоли Exchange:
  
  
  • Suspend-StorageGroupCopy
    
    
  • Resume-StorageGroupCopy
    
    
  • Update-StorageGroupCopy
    
    
  • Restore-StoreGroupCopy
    
    
  Эти командлеты и соответствующие функции консоли управления Exchange позволяют управлять непрерывной репликацией в средах локальной и кластерной непрерывной репликации.
  
  

  Примечание.
  В среде кластерной непрерывной репликации мастер обновления копии группы хранения доступен только для пассивного узла, мастер восстановления копии группы хранения доступен только для активного узла.

• Вкладка кластерного сервера почтовых ящиков. В окно Свойства сервера для имеющихся в кластере серверов почтовых ящиков была добавлена новая вкладка. Она доступна как в среде кластерной непрерывной репликацией, так и в кластерах с единым хранилищем. На новой вкладке содержится подробная информация о кластерном сервере почтовых ящиков. Кроме того, она позволяет администратору настраивать значение свойства AutoDatabaseMountDial серверов почтовых ящиков с среде кластерной непрерывной репликации. Большую часть сведений, отображаемых на этой вкладке, можно также получить с помощью командлета Get-ClusteredMailboxServerStatus. Дополнительные сведения о вкладке «Кластерный сервер почтовых ящиков» приведены в разделе Свойства сервера > Вкладка «Кластерный сервер почтовых ящиков».
  
  
• Страница кластерной непрерывной репликации. В окно Свойства группы хранения для серверов почтовых ящиков в среде кластерной непрерывной репликации добавлена новая страница. На ней приводятся подробные сведения о состоянии непрерывной репликации в кластере. Дополнительные сведения о странице «кластерной непрерывной репликации приведены в разделе Свойства группы хранения > Страница «Кластер с непрерывной репликацией».
  
  

В операционной системе Windows Server 2008 некоторые возможности усовершенствованы или переименованы. Дополнительные сведения о различиях между Windows Server 2003 и Windows Server 2008 приведены в разделе Изменения в терминологии.