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

Общие требования для кластерной непрерывной репликации

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

  • Необходимо использовать одну базу данных для каждой группы хранения. Если группа хранения создана в среде кластерной непрерывной репликации, она может содержать только одну базу данных. Такой подход способствует созданию более управляемой топологии хранилищ Microsoft Exchange с улучшенными возможностями восстановления.

  • Должна быть запущена служба доменнах имен (DNS). В идеальном случае сервер DNS должен принимать динамические обновления. Если сервер DNS не принимает динамические обновления, необходимо создать запись узла DNS (A) для каждого кластерного сервера почтовых ящиков и одну запись для самого кластера. Иначе Exchange будет работать неправильно. Дополнительные сведения о настройке DNS для Exchange приведены в статье 322856 базы данных Майкрософт Настройка DNS для использования с сервером Exchange (на английском языке).

  • Если узлы кластера относятся к зоне службы именования каталогов с именем, отличающимся от доменного имени в службе каталогов Active Directory, к которому присоединен данный компьютер, то свойство DNSHostName по умолчанию не включает имя дочернего домена. В такой ситуации может потребоваться изменить DNSHostName, чтобы обеспечить правильную работу ряда служб, например службы репликации файлов. Дополнительные сведения см. в статье 240942 базы знаний Майкрософт Свойство DNSHostName службы каталогов Active Directory не включает дочерний домен (на английском языке).

  • Все узлы кластера должны быть серверами, входящими в один и тот же домен. Microsoft Exchange Server 2007 не поддерживается на узлах, которые также являются серверами Active Directory, или узлах, входящих в различные домены Active Directory.

  • До установки Exchange 2007 необходимо сформировать кластер. Дополнительные сведения о формировании отказоустойчивого кластера Windows Server 2008 см. в разделе Установка кластера с непрерывной репликацией в операционной системе Windows Server 2008. Дополнительные сведения о формировании отказоустойчивого кластера Windows Server 2003 см. в разделе Установка кластера единой копии.

  • Имена кластерных серверов почтовых ящиков не должны содержать более 15 знаков.

  • Кластер, в котором устанавливается Exchange 2007, не может содержать Exchange Server 2003, Exchange 2000 Server или любую версию Microsoft SQL Server, поддерживающую кластер. Работа Exchange 2007 в кластере с любым из этих приложений не поддерживается. Использование Exchange 2007 в кластере с экспресс-выпуском SQL Server 2005 или другим приложением базы данных (например Microsoft Office Access) допускается при условии, что приложение базы данных не является кластерным.

  • Перед установкой Exchange 2007 убедитесь в том, что папка, в которую будут установлены данные Exchange, пуста.

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

  • Учетная запись службы кластеров должна являться членом локальной группы администраторов на каждом узле, который может содержать кластерный сервер почтовых ящиков.

  • Не следует устанавливать создавать или перемещать какие-либо ресурсы из кластерной группы по умолчанию в группу ресурсов, содержащую кластерный сервер почтовых ящиков. Также не следует устанавливать создавать или перемещать какие-либо ресурсы из группы, содержащей кластерный сервер почтовых ящиков, в кластерную группу по умолчанию. Кластерная группа по умолчанию должна содержать только IP-адрес кластера, сетевое имя и ресурсы кворума. Перемещение ресурсов в кластерную группу или совмещение ресурсов с кластерной группой по умолчанию не поддерживается.

    Важно!
    Кластерам, использующим предыдущие версии Exchange, необходим кластеризованный экземпляр координатора распределенных транзакций (Майкрософт) (MSDTC). Exchange 2007 устраняет необходимость в кластеризованном ресурсе MSDTC. Кластерный сервер почтовых ящиков в кластере с непрерывной репликацией не использует ресурс MSDTC, установленный в отказоустойчивом кластере. Сторонним приложениям может требоваться ресурс MSDTC из-за зависимостей COM+. В Windows Server 2003 для ресурса кластера MSDTC требуется общее хранилище в кластере. Не рекомендуется добавлять общее хранилище в среду кластера с непрерывной репликацией. Windows Server 2008 предоставляет локальный некластеризованный экземпляр MSDTC, который не требует общего хранилища в отказоустойчивом кластере Windows Server 2008. Дополнительные сведения об изменениях MSDTC в Windows Server 2008 см. в справке Windows Server 2008.

Требования к оборудованию для кластера с непрерывной репликацией

Общие сведения о планировании оборудования см. в разделах Планирование конфигураций процессора и памяти и Планирование дискового хранилища. Среда кластера с непрерывной репликацией предъявляет к оборудованию следующие специальные требования.

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

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

    Примечание.
    Рекомендуется использовать двухузловый отказоустойчивый кластер, использующий либо кворум набора узлов большинства с файловым ресурсом-свидетелем, либо кворум большинства узлов и общих файловых ресурсов. При этом устраняется необходимость иметь в кластере третий голосующий узел.
  • Используемые серверы должны входить в каталог прошедших испытания продуктов Microsoft Windows Server для операционной системы, на которой они будут установлены. Однако если в кластере не используется общее хранилище, серверы не обязаны входить в категорию "Кластер".

  • Два сервера, на которых размещаются роли сервера почтовых ящиков, должны иметь схожие, но необязательно идентичные, характеристики по следующим компонентам:

    • процессор;

    • память;

    • Скорость ввода/вывода

    • сеть;

    • поставщик;

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

Требования кворума для кластерной непрерывной репликации

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

  • В Windows Server 2008 для кластерной непрерывной репликации настоятельно рекомендуется использовать кворум большинства узлов и общих файловых ресурсов.

  • В Windows Server 2003 для кластера с непрерывной репликацией настоятельно рекомендуется использовать кворум большинства узлов и файловый ресурс-свидетель.

Если любой их этих типов кворума используется для кластерной непрерывной репликации, от узлов не требуется присутствия в каталоге прошедших испытания продуктов Microsoft Windows Server.

Если для кластерной непрерывной репликации используется кворум общего хранилища, вся система должна присутствовать в каталоге прошедших испытания продуктов Microsoft Windows Server.

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

Требования к программному обеспечению для кластера с непрерывной репликацией

Среда кластера с непрерывной репликацией предъявляет к программному обеспечению следующие требования.

  • На обоих узлах кластера должна быть установлена операционная система Windows Server 2008 Enterprise Edition или Windows Server 2003 Enterprise, с использованием одинаковых букв загрузочного и системного дисков для каждого узла в кластере. В кластере нельзя использовать Windows Server 2008 на одних узлах и Windows Server 2003 на других. Смешивание операционных систем в отказоустойчивом кластере не поддерживается.

  • Если кластер с непрерывной репликацией устанавливается в окончательной первоначальной версии (RTM) Exchange 2007 на Windows Server 2003, в отказоустойчивом кластере должна быть установлена либо Windows Server 2003 с пакетом обновления 2 (SP2), либо Windows Server 2003 с пакетом обновления 1 (SP1) и исправлением из статьи 921181 базы знаний Майкрософт Доступно обновление, добавляющее файловый ресурс-свидетель и настраиваемое подтверждение соединения кластера для кластеров, состоящих из серверов с Microsoft Windows Server 2003 с пакетом обновления 1 (SP1) (на английском языке). Это исправление входит в состав Windows Server 2003 с пакетом обновления 2 (SP2). Если среда кластера с непрерывной репликацией создается на основе Exchange 2007 с пакетом обновления 1 (SP1) в Windows Server 2003, на обоих узлах кластера должен быть установлен сервер Windows Server 2003 с пакетом обновления 2 (SP2).

  • Кластер может являться трехузловым кластером с обычным кворумом «Набор большинства узлов» или двухузловым кластером с кворумом «Набор большинства узлов» со свидетелем общего файлового ресурса. Как правило, предполагается, что на Windows Server 2003 будет использоваться двухузловый кластер, использующий кворум набора узлов большинства с файловым ресурсом-свидетелем, и что на Windows Server 2008 будет использоваться двухузловый кластер, использующий кворум большинства узлов и общих файловых ресурсов.

  • Файловый ресурс-свидетель для кворума набора узлов большинства или кворума большинства общих файловых ресурсов не обязательно должен находиться на специально выделенном компьютере. Он может быть размещен на любом компьютере под управлением Windows Server. Рекомендуется размещать файловый ресурс-свидетель на транспортном сервере-концентраторе (или другом сервере Exchange), который будет управляться администратором Exchange.

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

Требования к сети для кластера с непрерывной репликацией

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

  • Каждый узел должен содержать хотя бы два сетевых адаптера, доступных для кластеризации Windows. Клиенты и другие серверы должны получать доступ к узлам, используя только один из двух сетевых адаптеров. Другие сетевые адаптеры используются для обеспечения взаимодействия внутри кластера. Рекомендуемая конфигурация состоит из частной сети, выделенной для внутренней кластерной связи, и общедоступной сети, обозначенной как «смешанная».

  • Публичная сеть кластера должна обеспечивать подключение к другим узлам Exchange и службам, таким как Active Directory и DNS-служба. Чтобы избежать появления недублированных точек отказа, следует использовать группирование сетевых адаптеров или аналогичную технологию.

  • Необходимо создать отдельную частную сеть кластера. Эта частная сеть используется для синхронизации кластера. Частная сеть кластера не требует использования DNS.

  • Для конфигурации с двумя центрами обработки данных требования к синхронизации кластера могут и не быть определяющими требованиями к пропускной способности и задержке в общей сети. Чтобы определить необходимые требования к сети для конкретной среды, следует оценить общую загрузку сети, которая включает клиентский доступ, Active Directory, передачу данных, непрерывную репликацию и другой прикладной трафик.

  • В средах кластерной непрерывной репликации рекомендуется использовать гигабитную сеть Ethernet, чтобы максимально увеличить время повторного заполнения. Дополнительные сведения о причинах выбора Gigabit Ethernet см. в главе «Размер базы данных и кластер с непрерывной репликацией» далее в этом разделе.

  • В окончательной первоначальной версии (RTM) Exchange 2007 группа ресурсов, содержащая кластерный сервер почтовых ящиков, может иметь только один ресурс сетевого имени. Наличие более чем одного ресурса сетевого имени в группе ресурсов, содержащей кластерный сервер почтовых ящиков, не поддерживается окончательной первоначальной версией (RTM) Exchange 2007. Однако этого ограничения не существует в Exchange 2007 с пакетом обновления 1. Если кластерный сервер почтовых ящиков обновлен до Exchange 2007 с пакетом обновления 1, более чем один ресурс сетевого имени может существовать в группе ресурсов, содержащей кластерный сервер почтовых ящиков.

Требования к сети для установки кластера с непрерывной репликацией в Windows Server 2008

Требования к сети для установки кластера с непрерывной репликацией в Windows Server 2008 немного отличаются от требований для Windows Server 2003. Как и в Windows Server 2003, для установки кластера с непрерывной репликацией в Windows Server 2008 необходимо достаточное количество IP-адресов для узлов и для кластерного сервера почтовых ящиков. Однако некоторые дополнительные возможности Windows Server 2008 не поддерживаются сервером Windows Server 2003.

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

  • При использовании нескольких подсетей в среде кластера с непрерывной репликацией репликация DNS может влиять на способность клиентов повторно подключаться после перехода на другой ресурс при сбое или перемещении кластерного сервера почтовых ящиков вручную между узлами. Клиенты и другие серверы, взаимодействующие с кластерным сервером почтовых ящиков, у которого изменился IP-адрес, не смогут повторно установить связь с кластерным сервером почтовых ящиков, пока в службе DNS не обновится IP-адрес и не обновятся локальные кэши DNS. Для минимизации времени, необходимого, чтобы изменения в системе DNS стали известны клиентам и другим серверам, рекомендуется присвоить сроку жизни DNS значение, равное пяти минутам для ресурса сетевого имени кластерного сервера почтовых ящиков. В большинстве сред рекомендуется задавать срок жизни DNS только для ресурса сетевого имени кластерного сервера почтовых ящиков. Однако в средах, содержащих средства управления, отличные от Exchange, в которых в процессе управления осуществляется подключение к кластеру по его имени, для ресурса сетевого имени кластера рекомендуется устанавливать более короткий срок жизни. Дополнительные сведения о настройке значений срока жизни DNS для ресурсов сетевого имени в среде кластерного сервера почтовых ящиков с несколькими подсетями или в среде резервного кластера см. в разделе Настройка значений срока жизни DNS для ресурсов сетевых имен.

  • Отказоустойчивые кластеры Windows Server 2008 поддерживают получение IP-адресов как от серверов DHCP, так и через статические записи. Если узлы кластера настроены на получение IP-адресов от сервера DHCP, то по умолчанию происходит автоматическая выдача IP-адресов для всех ресурсов IP-адресов кластера. Если же узлу кластера назначен статический IP-адрес, ресурсы IP-адресов кластера также необходимо настраивать с использованием статических IP-адресов. Таким образом, назначение IP-адресов для ресурсов IP-адресов кластера происходит после настройки физических узлов и всех интерфейсов этих узлов. Не рекомендуется использовать DHCP для кластерных серверов почтовых ящиков. Перед использованием DHCP для кластерных серверов почтовых ящиков обратите внимание на указанные ниже факты.

    • Служба кластеров не будет подключать ресурс IP-адреса с поддержкой DHCP после изменения IP-адреса.

    • DHCP-серверы необходимо настроить на предоставление неограниченной аренды всех адресов с поддержкой DHCP, которые используются кластерными серверами почтовых ящиков.

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

Требования к сети для установки кластера с непрерывной репликацией в Windows Server 2003

При установке кластера с непрерывной репликацией в Windows Server 2003 при создании кластерных серверов почтовых ящиков в двухузловой среде необходимо иметь достаточное число статических IP-адресов. IP-адрес требуется для кластера и для кластерного сервера почтовых ящиков. Кроме того, IP-адреса требуются как для общедоступных, так и для частных сетей каждого узла.

  • Адреса частной сети. Каждому сетевому адаптеру каждого узла, используемому для частной сети кластера, требуется один статический IP-адрес. Необходимо использовать статические IP-адреса, не входящие ни в одну подсеть или сеть, которая является частью одной из публичных сетей. Рекомендуется использовать IP-адреса частной сети 10.10.10.10 и 10.10.10.11 с маской подсети 255.255.255.0 для двух узлов соответственно. Если в общедоступной сети используются IP-адреса формата 10.x.x.x и маска подсети 255.255.255.0, рекомендуется использовать в частной сети другие IP-адреса и маску подсети. Если настраивается более одной частной сети, для каждого сетевого адаптера частной сети и каждой сети необходимы уникальные адреса и подсети.

  • Адреса публичной сети. Каждому сетевому адаптеру каждого узла, используемому для публичной сети кластера, требуется один статический IP-адрес. Кроме того, статические IP-адреса необходимы для кластера серверов и кластерного сервера почтовых ящиков, чтобы к ним могли получать доступ клиенты и администраторы. Следует использовать статические IP-адреса, не входящие ни в одну подсеть или сеть, которая является частью одной из частных сетей.

Частная сеть для всех узлов кластера должна находиться в одной подсети, однако для внутреннего соединения между двумя узлами можно использовать коммутаторы виртуальной локальной сети. При использовании этих коммутаторов общая задержка передачи не должна превышать 0,5 секунды. Кроме того, связь между двумя узлами должна восприниматься операционной системой Windows Server 2003, под управлением которой работают данные узлы, как одно прямое подключение. Чтобы избежать появления недублированных точек отказа, используйте независимое оборудование виртуальной локальной сети для разных путей между узлами. Это ограничение подсети неприменимо к отказоустойчивым кластерам, работающим на Windows Server 2008.

Общедоступные сети для всех узлов кластера должны находиться в одной подсети и должны использовать подсеть, отличную от подсети, которая используется частными сетями. Это ограничение подсети неприменимо к отказоустойчивым кластерам, работающим на Windows Server 2008.

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

Если кластер с непрерывной репликацией устанавливается в конфигурации с несколькими центрами обработки данных в Windows Server 2003:

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

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

  • Сети, используемые для синхронизации кластера, должны иметь возможность получать и отправлять пакет подтверждения соединения в пределах указанного при настройке количества повторов. Если кластер с непрерывной репликацией устанавливается на Windows Server 2003 с пакетом обновления 2 (SP2) или Windows Server 2003 с пакетом обновления 1 (SP1) и исправлением из статьи 921181 базы знаний Майкрософт, Доступно обновление, добавляющее файловый ресурс-свидетель и настраиваемое подтверждение соединения кластера для кластеров, состоящих из серверов с Microsoft Windows Server 2003 с пакетом обновления 1 (SP1) (на английском языке), то повторения синхронизации при потере интерфейса или узла представляются как параметры настройки кластера. Если кластерная непрерывная репликация устанавливается на Windows Server 2008, в этом обновлении нет необходимости. В обоих случаях, хотя пакеты синхронизации кластера, как и прежде, отправляются каждые 1,2 секунды, кластер может быть настроен таким образом, чтобы до действия по восстановлению должно было произойти больше потерь (вследствие потерянных пакетов, большой задержки, сбоя интерфейса или узла). Значения свойств указываются в единицах пропущенных пульсов, а не в единицах прошедшего времени. Таким образом, кластер нельзя настроить на обнаружение сбоя интерфейса через пять секунд. Его можно настроить на обнаружение сбоя интерфейса после пяти пропусков, и в зависимости от того, в какой момент периода пульса произошел сбой, пять пропусков будут соответствовать приблизительно пяти-шести секундам. Допустимый минимум для обоих этих параметров составляет 2 секунды, а допустимый максимум — 20 секунд.

Оптимизация сетевых технологий Windows 2003 для кластера с непрерывной репликацией

При использовании кластера с непрерывной репликацией на компьютере с Windows Server 2003 рекомендуется оптимизировать параметры TCP/IP в Windows Server в соответствии со скоростью и задержками конкретной сети. Возможно, следует настроить размер окна приема TCP и параметры масштабирования окна из документа RFC 1323 на активном и пассивном узлах. Кроме того, иногда полезно настроить параметры истечения срока действия кэша ARP и отключить расширенные параметры TCP/IP для пакета Windows Server 2003 Scalable Networking Pack (SNP) в реестре Windows.

Кроме того, если в среде используется протокол IPsec, рекомендуется согласованно настроить его во всей среде кластера с непрерывной репликацией. Либо оба узла должны использовать протокол IPsec, либо ни один узел не должен его использовать. Если только один узел настроен для использования IPsec, процесс сопоставления безопасности IPsec может вызвать задержку или потерю пакетов.

Окна приема TCP и параметры масштабирования RFC 1323

Размер окна приема TCP — это максимальный объем данных (в байтах), который может быть получен по подключению за раз. Отправляющий компьютер может отправить только этот максимальный объем данных перед ожиданием подтверждения и обновления окна TCP принимающим компьютером. Иногда полезно настроить этот параметр для увеличения пропускной способности во время доставки журналов.

Чтобы оптимизировать использование пропускной способности TCP, отправляющий компьютер должен передавать достаточно пакетов для заполнения канала между отправителем и получателем. Емкость сетевого канала определяется его пропускной способностью и задержкой (временем приема-передачи). Чем выше задержка, тем больше емкость канала, потому что имеется больше времени для отправки данных между подтверждениями. Увеличив размер окна TCP, можно использовать дополнительное время между подтверждениями для отправки дополнительных данных.

В соответствии со стандартом TCP/IP размер окна приема может достигать 65 535 октетов — максимального значения, которое может быть указано в 16-разрядном поле размера окна TCP. Для повышения производительности в сетях с высокой пропускной способностью и высокой задержкой стек TCP/IP в Windows Server поддерживает возможность объявления размера окна приема, превышающего 65 535 октетов. Это возможно благодаря использованию масштабируемых окон, описанных в документе RFC 1323 Расширения TCP для обеспечения высокой производительности. При использовании масштабирования окна узлы, участвующие во взаимодействии, могут согласовать такой размер окна, который допускает задержку крупных пакетов (используемых, например, протоколами передачи файлов) в буферах на стороне получателя. В документе RFC 1323 описан способ обеспечения поддержки более крупных размеров окна приема, основанный на согласовании коэффициента масштабирования размера окна приема при установлении соединения.

Чтобы оптимизировать размер окна приема TCP и параметры масштабирования окна RFC 1323 на компьютере с системой Windows Server 2003, измените два параметра реестра: TCPWindowSize и TCP1323Opts. Дополнительные сведения об этих возможностях см. в статье 224829 базы знаний Microsoft Описание возможностей TCP в Windows 2000 и Windows Server 2003 (на английском языке).

Для определения оптимальных значений этих параметров реестра на основе характеристик канала связи и задержки в сети рекомендуется использовать калькулятор требований к хранилищу для роли сервера почтовых ящиков Exchange 2007 версии 13 или более поздней. Загрузить этот калькулятор можно с веб-узла блога команды разработчиков Exchange здесь (на английском языке). К калькулятору прилагаются пошаговые инструкции по вводу значений реестра на серверах.

Примечание.
Содержимое и URL-адрес каждого блога могут изменяться без предварительного уведомления. Содержимое каждого блога предоставляется на условиях "как есть" без каких-либо гарантий, при этом никакие права не передаются. На использование предоставляемых примеров сценариев и кода распространяются Условия использования

Истечение срока действия кэша ARP

Кэш ARP — это хранящаяся в памяти таблица, которая сопоставляет IP-адреса с MAC-адресами. Записи в кэше ARP считываются каждый раз, когда исходящий пакет отправляется по IP-адресу, указанному в записи. По умолчанию Windows Server 2003 автоматически корректирует размер кэша ARP в соответствии с требованиями системы. Если запись не используется никаким исходящим пакетом в течение двух минут, она удаляется из кэша ARP. Используемые записи удаляются из кэша ARP через десять минут. Записи, добавленные вручную, не удаляются из кэша автоматически.

Внутреннее тестирование, проведенное ИТ-отделом корпорации Майкрософт, показало, что использование параметров истечения срока действия кэша ARP, действующих по умолчанию, приводит к потере пакетов в средах кластера с непрерывной репликацией и средах с резервной непрерывной репликацией. При потере пакета отправляющий сервер должен передать потерянные данные еще раз. В среде с непрерывной репликацией важно обеспечить скорейшее копирование файлов журналов на пассивный узел, при этом повторная передача потерянных пакетов может отрицательно сказаться на доставке журналов.

Для управления истечением срока действия кэша ARP можно изменить в реестре Windows параметр TCP/IP с именем ArpCacheMinReferencedLife. Он определяет, как долго используемые записи должны оставаться в таблице кэша ARP до их удаления. Результаты внутреннего тестирования Майкрософт показали, что лучше всего использовать значение параметра ArpCacheMinReferencedLife, используемое маршрутизаторами в сети, которое составляет 4 часа.

Перед изменением значения параметра ArpCacheMinReferencedLife в собственной среде воспользуйтесь сетевым монитором Майкрософт или аналогичным средством для сбора и анализа сетевого трафика в сетевом интерфейсе, используемом для копирования журналов с активного узла на пассивный. Дополнительные сведения об изменении значения реестра ArpCacheMinReferencedLife см. в документе Приложение А: параметры конфигурации TCP/IP (на английском языке).

Расширенные возможности TCP/IP, реализованные в пакете Scalable Networking Pack

Windows Server 2003 Scalable Networking Pack (SNP) — это отдельное обновление для Windows Server 2003, содержащее функции разгрузки с поддержкой и без поддержки сведений о состоянии, ускоряющие работу сетевого стека Windows. Оно включает функции TCP Chimney Offload, Receive Side Scaling (RSS) и Network Direct Memory Access (NetDMA).

Функция TCP Chimney работает с учетом сведений о состоянии. Она позволяет переместить обработку нагрузки TCP/IP на сетевые адаптеры, выполняющие это аппаратно.

Функции RSS и NetDMA не учитывают состояние протоколов. На многопроцессорном компьютере сетевой стек Windows ограничивает обработку "принимающего" протокола одним ЦП. Функция RSS устраняет эту проблему, позволяя распределить обработку пакетов, полученных от сетевого адаптера, между несколькими ЦП. Функция NetDMA обеспечивает возможность использования прямого доступа к памяти на шине PCI. Благодаря ей стек TCP/IP может задействовать механизм прямого доступа к памяти для копирования данных вместо того, чтобы использовать процессор. Связанный с ним компонент, TCPA, — это еще одна функция разгрузки, позволяющая использовать аппаратный модуль прямого доступа к памяти на шине PCI для обработки принимаемых данных.

Несмотря на то что эти функции могут обеспечить повышение производительности сети в некоторых средах, в ряде сценариев их использовать нельзя из-за применения других технологий. Например, функции TCP Chimney Offload и NetDMA нельзя использовать, если применяется какая-либо из следующих технологий:

  • брандмауэр Windows;

  • протокол IPsec;

  • преобразование сетевых IP-адресов (IPNAT);

  • сторонние брандмауэры;

  • промежуточные драйверы NDIS 5.1.

Кроме того, в некоторых средах, в том числе в средах с Microsoft Exchange, могут возникать проблемы, из-за которых при использовании данных функций производительность может снижаться. Сведения о некоторых из этих проблем см. в блоге команды разработчиков Exchange в сообщении Windows 2003 Scalable Networking Pack и его возможное влияние на Exchange Server (на английском языке).

Примечание.
Содержимое и URL-адрес каждого блога могут изменяться без предварительного уведомления. Содержимое каждого блога предоставляется на условиях "как есть" без каких-либо гарантий, при этом никакие права не передаются. На использование предоставляемых примеров сценариев и кода распространяются Условия использования.

Корпорация Майкрософт рекомендует отключить все описанные функции в средах кластера с непрерывной репликацией под управлением Windows Server 2003 и для операционной системы, и для каждого сетевого адаптера. Процедура их отключения описана ниже.

Дополнительные сведения о пакете SNP см. в статье 912222 базы знаний Выпуск пакета Scalable Networking Pack для Microsoft Windows Server 2003 (на английском языке) и на веб-узлеМасштабируемые сетевые технологии (на английском языке).

Поведение Microsoft Outlook после перемещения сервера кластерного почтового ящика при сбое в отказоустойчивом кластере, расположенном в нескольких подсетях

При перемещении или переходе на другой ресурс при сбое кластерного сервера почтовых ящиков, развернутого в географически распределенном отказоустойчивом кластере, расположенном в нескольких подсетях, имя кластерного сервера почтовых ящиков сохраняется. Однако IP-адрес, назначенный этому имени, не сохраняется. Доступность этого сервера клиентам и другим серверам зависит от скорости распространения нового IP-адреса в системе DNS. Распространение IP-адреса в системе DNS может занять некоторое время. По этой причине рекомендуется присвоить сроку жизни записи DNS-узла кластерного сервера почтовых ящиков значение, равное 5 минутам (300 секунд). Дополнительные сведения о настройке значения срока жизни DNS для кластерного сервера почтовых ящиков см. в разделе Настройка значений срока жизни DNS для ресурсов сетевых имен. После настройки значения срока жизни DNS для кластерного сервера почтовых ящиков необходимо остановить и снова запустить кластерный сервер почтовых ящиков, чтобы изменения вступили в силу.

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

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

В последующих разделах описано поведение Microsoft Outlook в различных конфигурациях.

Растянутый кластер с непрерывной репликацией в Windows Server 2003 (одна подсеть)

В этой конфигурации есть один ресурс сетевого имени и один ресурс IP-адреса, от которого зависит ресурс сетевого имени. В DNS сетевое имя связано с IP-адресом. Все ресурсы, включая ресурс IP-адреса, могут перемещаться между двумя узлами кластера. С точки зрения Outlook изменения IP-адреса не происходит, поскольку единственное, что изменяется в сети при переходе — это привязка IP-адреса к MAC-адресу компьютера, что прозрачно для клиентов.

Растянутый кластер с непрерывной репликацией в Windows Server 2008 (две подсети, протокол IPv4)

В этой конфигурации есть один ресурс сетевого имени и два IP-адреса, от которых сетевое имя зависит по правилу логической операции "ИЛИ". В DNS сетевое имя связано с текущим рабочим IP-адресом. Поскольку при переходе ресурс сетевого имени переходит в интерактивный режим, служба кластера заносит в запись DNS для сетевого имени второй IP-адрес, соответствующий другой подсети. Изменение записи должно распространиться в DNS. С точки зрения Outlook новый или измененный профиль для Outlook не требуется, но при этом необходимо дождаться очистки локального кэша DNS, чтобы стало возможным разрешение сетевого имени в другой IP-адрес. Это можно сделать вручную на клиенте с помощью следующей команды:

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

Локальный кластер с резервной непрерывной репликацией на удаленном сайте (одна или две подсети)

В этой конфигурации имеется один ресурс сетевого имени и один ресурс IP-адреса, от которого зависит сетевое имя. Все ресурсы, включая IP-адрес, могут перемещаться между двумя узлами кластера. При переключении сайта при сбое на другой ресурс, в котором с помощью команды Setup.com /recoverCMS включен целевой объект резервной непрерывной репликации, кластерный сервер почтовых ящиков перемещается на другой сайт или кластер. При выполнении этой команды указывается IP-адрес, который требуется связать с сетевым именем в удаленном сайте. При установке создаются ресурсы сетевого имени и IP-адреса, а служба кластера заносит в DNS новый IP-адрес. Изменение системы DNS должно распространиться в ней. С точки зрения Outlook новый или измененный профиль для Outlook не требуется, но при этом необходимо дождаться очистки локального кэша DNS, чтобы стало возможным разрешение сетевого имени в другой IP-адрес. Это можно сделать вручную на клиенте с помощью следующей команды:

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

Требования к хранилищу для кластера с непрерывной репликацией

Кластер с непрерывной репликацией предназначен для избавления от необходимости использования общего хранилища в кластере Windows. Наличие общего хранилища было обязательным требованием для предыдущих версий Exchange. Единственное требование, предъявляемое к хранилищу кластера с непрерывной репликацией — достаточное быстродействие и объем хранилища, поддерживаемого сервером Windows.

Кластер с непрерывной репликацией не предъявляет дополнительных требований к вводу-выводу хранилища, используемому группами хранения и базами данных. При разработке решения для хранилища кластера с непрерывной репликацией рекомендуется руководствоваться следующими правилами.

  • Расположение групп хранения и баз данных должно совпадать на всех узлах кластера.

  • Файлы базы данных и файлы журналов транзакций должны храниться на устройствах с различными номерами логических устройств (LUN).

  • Для подключения томов к операционной системе следует использовать точки подключения файловой системы NTFS.

  • Следует использовать понятные имена, которые могут быть непосредственно и явно привязаны к размещенной группе хранения или базе данных. Если для журналов и баз данных используются разные тома, их пути должны определять тип данных. Такой подход позволяет избежать ошибок, связанных с человеческим фактором, вызываемых ростом числа баз данных и групп хранения. При выполнении установки по умолчанию группа хранения и базы данных создаются в папке установки Exchange 2007.

    Примечание.
    Exchange 2007 не поддерживает размещение файлов журналов транзакций или файлов баз данных в корневом каталоге тома.

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

Размер базы данных и кластер с непрерывной репликацией

Первая линия защиты среды кластера с непрерывной репликацией от масштабных сбоев хранилища или повреждения физической базы данных — это возврат к пассивной копии данных без восстановления из резервной копии. Таким образом, короткое время восстановления из архива или с ленты становится гораздо менее важным. Вместо восстановления с ленты можно активировать пассивную копию базы данных, и данные станут доступными клиентам через несколько минут, а не часов. Поэтому кластер с непрерывной репликацией может считаться быстрым механизмом восстановления, таким же, как аппаратные снимки и клоны, созданные с помощью службы теневого копирования в Exchange Server 2003.

Достаточно часто администраторам приходится выполнять операции с автономной базой данных, такие как исправления последствий неудачного архивирования (например из-за повреждений пленки или неудавшегося восстановления). Кластерная непрерывная репликация позволяет избежать такого развития событий, а восстановление базы данных будет выполняться гораздо реже. Несмотря на то, что доля ситуаций, в которых необходимо восстановление, должно резко сократиться, могут возникнуть случаи, когда оно будет необходимо. Настраивая размер базы данных, обязательно учтите устойчивость базы данных к самим плохим вариантам выхода из строя.

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

Другая возможность Exchange 2007, называемая устойчивостью к потере журналов (LLR), радикально уменьшает вероятность несоглаcованности базы данных из-за потери журналов. Вообще говоря, чаще всего администратору приходится восстанавливать базу данных из-за необходимости вернуть ее в согласованное состояние при потере или повреждении требуемых журналов, что препятствует подключению базы данных. Устойчивость к потере журналов обеспечивает устойчивость во многих случаях потери или повреждения журналов, позволяя подключать базу данных без необходимости ее восстановления. Для получения дополнительных сведений о LLR см. раздел Устойчивость к потере журналов и действия с журналом транзакций в Exchange Server 2007.

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

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

В среде кластерной непрерывной репликации при условии отсутствия "узких мест", связанных с диском или процессором, следует ожидать следующих скоростей при использовании гигабитной сети Ethernet:

  • Повторное заполнение одной базы данных: примерно 25 мегабайт (МБ) в секунду

  • Повторное заполнение нескольких баз данных (параллельно): примерно 100 МБ/с (ограничено пропускной способностью сети)

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

  • базы данных, размещенные на сервере почтовых ящиков без непрерывной репликации: 100 гигабайт (ГБ)

  • базы данных, размещенные на сервере почтовых ящиков с непрерывной репликацией и технологией Gigabit Ethernet: 200 ГБ

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

Требования к службе Active Directory для кластера с непрерывной репликацией

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

Примечание.
Для серверов почтовых ящиков в географически разнесенном кластере требуется, чтобы один сайт Active Directory был растянут между центрами данных, так как все узлы кластера должны быть членами одного и того же сайта. Однако не требуется, чтобы все остальные серверы в обоих центрах обработки данных находились в одной и той же подсети или на одном и том же сайте Active Directory.

Требования к учетной записи службы для кластера с непрерывной репликацией

Если кластерная непрерывная репликация устанавливается на Windows Server 2008, служба кластеров будет работать, используя локальную системную учетныею запись (SYSTEM).

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

Учетная запись службы кластеров отвечает за создание и обслуживание учетной записи компьютера, которая определяется ресурсом сетевого имени отказоустойчивого кластера и сопоставляется с ним при подключении ресурса. Сведения о надлежащих разрешениях для учетной записи службы кластеров см. в статье 307532 базы знаний Устранение неполадок с учетной записью службы кластеров для изменения объектов компьютеров. Дополнительные сведения см. в статье 251335 базы знаний Майкрософт Не удается подключить к домену рабочую станцию или сервер.

Кластер с непрерывной репликацией и базы данных общих папок

Кластер с непрерывной репликаией и репликация общих папок — два принципиально различных способа репликации, встроенных в Exchange. Если в организации Exchange несколько серверов почтовых ящиков имеют базы данных общих папок, включается репликация общих папок, а базы данных общих папок не должны располагаться в среде кластера с непрерывной репликацией. Это объясняется ограничениями взаимодействия между непрерывной репликацией и репликацией общих папок

При использовании баз данных общих папок и кластера с непрерывной репликацией в организации Exchange рекомендуется применять описанные ниже конфигурации.

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

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

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

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

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

  • При успешном запланированном отключении без потери данных база данных общих папок будет включена и репликация общих папок должна быть продолжена в соответствии с ожиданиями.

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

Резервное копирование и восстановление и кластер с непрерывной репликацией

Резервное копирование с поддержкой Exchange поддерживается как для производственных групп хранения и их копий, так и для баз данных, использующих технологию VSS. Потоковое резервное копирование поддерживается только на активном узле.

Примечание.
Типичной задачей при создании резервных копий Exchange является усечение файлов журналов транзакций после успешного выполнения резервного копирования. Функция репликации в конфигурации кластера с непрерывной репликацией гарантирует, что журналы, которые не были реплицированы, не удаляются. Такое поведение приводит к тому, что резервное копирование в режиме удаления журналов может фактически не освобождать место, если в процессе репликации скопирована достаточно большая часть журналов.

Восстановление резервных копий Exchange в активную копию может быть выполнено с помощью решений потокового резервного копирования или службы теневого копирования. Восстановление резервных копий Exchange для пассивной копии не поддерживается.

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

После восстановления базы данных из резервной копии в группу хранения в среде кластера с непрерывной репликацией необходимо приостановить и затем возобновить непрерывную репликацию для группы хранения с помощью командлетов Suspend-StorageGroupCopy и Resume-StorageGroupCopy соответственно. Это необходимо для обновления службы репликации Microsoft Exchange правильными сведениями о версиях журналов. Если не приостановить и не возобновить непрерывную репликацию, служба репликации Microsoft Exchange получит устаревшие сведения о версиях журналов и прекратит репликацию файлов журналов.

Проверка контрольных сумм и очистка страниц баз данных при оперативном обслуживании в Exchange 2007 SP1

Проверка контрольных сумм - это процесс проверки целостности базы данных. Очистка страниц - это процесс обнуления баз данных в конце потокового резервного копирования. Окончательная первоначальная версия Exchange 2007 проверяет контрольные суммы всей базы данных при выполнении полного оперативного потокового резервного копирования. Как упомянуто ранее, в среде непрерывной репликации потоковые резервные копии могут быть сняты только с активной копии базы данных. Их нельзя делать с пассивной копии. Службу теневого копирования можно использовать для снятия полных снимков или создания полных клонов пассивной копии, и контрольные суммы клонов также могут быть вычислены. Но, как правило, в среде непрерывной репликации без вмешательства администратора и некоторого простоя можно провести вычисление контрольных сумм только одной из копий базы данных (либо активной, либо пассивной). Причины этого:

  • Создание потоковых резервных копий с активной копии базы данных с одновременным созданием теневых копий с пассивной копии той же базы данных является обременительным.

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

  • Устойчивость может быть временно нарушена, поскольку ручное выполнение проверок целостности с использованием служебных программ базы данных Exchange Server (Eseutil) требует приостановки непрерывной репликации.

Для обеспечения очистки страниц и проверки контрольных сумм баз данных на всех копиях баз данных без необходимости обходить вышеописанные проблемы Exchange 2007 с пакетом обновления 1 представляет две новых функции: Проверка контрольных сумм баз данных при оперативном обслуживании и Очистка страниц баз данных при оперативном обслуживании. Эти функции позволяют администратору включать как фоновую очистку страниц, так и фоновое вычисление контрольных сумм базы данных. Этих функции можно включить отдельно или вместе, вручную настроив параметры реестра на сервере почтовых ящиков, содержащем подлежащие проверке базы данных, и затем перезапустив службу банка сообщений Microsoft Exchange. Параметры реестра настраиваются на уровне службы банка данных Microsoft Exchange. Таким образом, после включения настроенной фоновой активности она будет выполняться на всех базах данных сервера почтовых ящиков. Возможные записи реестра описаны ниже в этом разделе.

Внимание!
Неправильное изменение реестра может вызвать серьезные неполадки, требующие переустановки операционной системы. Корпорация Майкрософт не гарантирует разрешения неполадок, вызванных неправильным изменением реестра. Перед изменением реестра создайте резервную копию всех важных данных.

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

Место: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Имя: Контрольная сумма оперативного обслуживания

Тип: REG_DWORD

Значение: 0x00000001

Включение очистки страниц баз данных при оперативном обслуживании

Место: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Имя: Очистка страниц баз данных в ходе контрольной суммы

Тип: REG_DWORD

Значение: 0x00000001

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

Место: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Имя: Контрольная сумма регулирования

Тип: REG_DWORD

Значение: 0x00000000 (миллисекунды)