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

• Для одного источника может быть определено несколько конечных объектов. Например, один из конечных объектов может быть размещен в том же центре обработки данных, что и источник, а второй — в отдельном центре обработки данных. Количество конечных объектов для одного источника не ограничено. Тем не менее рекомендуется использовать для одного источника не более четырех конечных объектов. При настройке более четырех конечных объектов следует оценить влияние такой конфигурации на работу сервера-источника и подойти к планированию инфраструктуры с особой тщательностью.
  
  
• Для каждого конечного объекта может быть настроено несколько серверов-источников. Как на компьютере-источнике, так ни конечном компьютере должен быть установлен сервер Exchange 2007 с пакетом обновления 1 (SP1). В качестве операционной системы можно использовать любую систему, поддерживаемую Exchange 2007 с пакетом обновления 1 (SP1) (например, Windows Server 2008 или Windows Server 2003). Тем не менее все конечные компьютеры резервной непрерывной репликации должны работать под управлением той же операционной системы, что и исходный компьютер. Использование различных операционных систем (например, если операционная система источника резервной непрерывной репликации — Windows Server 2003, а система конечного объекта резервной непрерывной репликации — Windows Server 2008, или наоборот) не поддерживается.
  
  
• На конечном компьютере резервной непрерывной репликации должна быть установлена роль сервера почтовых ящиков Exchange 2007 с пакетом обновления 1 (SP1). Если конечным компьютером резервной непрерывной репликации является узел кластера, он должен быть пассивным (например, на нем должна быть установлена роль пассивного кластерного почтового ящика), а кластер не может содержать никаких кластерных серверов почтовых ящиков.
  
  
• К планированию путей установки сервера Exchange для резервной непрерывной репликации следует подходить с особой тщательностью, если предполагается использовать резервный кластер и функцию восстановления кластерного сервера почтовых ящиков (Setup /RecoverCMS) в качестве одного из этапов активации конечного объекта. Для использования процесса восстановления сервера путь установки Exchange Server должен быть одинаковым как на компьютере-источнике, так и на конечном компьютере. Если сервер Exchange Server устанавливается на компьютере-источнике в папку %ProgramFiles%\Microsoft\Exchange Server, его следует также устанавливать в папку %ProgramFiles%\Microsoft\Exchange Server на всех конечных компьютерах, соответствующих этому источнику. Если эти пути будут различаться, выполнить процедуру Setup /RecoverCMS не удастся, поскольку хранящийся в реестре путь не будет соответствовать значению атрибута msExchInstallPath объекта сервера почтовых ящиков в службе каталогов Active Directory.
  
  
• Если процесс активации включает восстановление кластерного сервера почтовых ящиков, необходимо отключить резервную непрерывную репликацию для всех групп хранения на кластерном сервере почтовых ящиков перед использованием команды Setup /RecoverCMS в процессе активации. Если резервная непрерывная репликация не отключена для всех групп хранения, при выполнении команды Setup /RecoverCMS произойдет сбой.
  
  
• Пути к группам хранения и базам данных на исходном и всех конечных компьютерах резервной непрерывной репликации не должны конфликтовать с другими путями к группам хранения или базам данных. При использовании резервной непрерывной репликации необходимо более тщательно планировать пути для групп хранения или баз данных, так как путь к базе данных и группе хранения, используемый источником резервной непрерывной репликации, будет применяться для копии базы данных и группы хранения на всех конечных объектах резервной непрерывной репликации для источника.
  
  
• При резервной непрерывной репликации исходный и конечный компьютеры должны относиться к одному и тому же домену Active Directory. Тем не менее они могут принадлежать к разным сайтам Active Directory.
  
  
• Каждый конечный компьютер поддерживает не более 50 конечных объектов резервной непрерывной репликации (50 реплицированных групп хранения) при использовании Exchange 2007 Enterprise Edition и не более 5 конечных объектов при использовании Exchange 2007 Standard Edition.
  
  

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

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

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

Примечание.
Поскольку переносимость базы данных можно использовать только с базами данных почтовых ящиков, активировать приемник копирования резервной непрерывной репликации базы данных общих папок можно только в ходе операции восстановления сервера или кластерного сервера почтовых ящиков (например, Setup /m:recoverServer или Setup /recoverCMS).

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

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

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

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

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

В окончательной первоначальной версии (RTM) Exchange 2007 правила применяются таким образом, что файл журнала не удаляется до тех пор, пока он не будет выполнено его резервное копирование и преобразование в копию базы данных. Резервная непрерывная репликация работает иначе. Механизм резервной непрерывной репликации (подразумевающий наличие нескольких копий базы данных) допускает усечение файлов журнала источника, если эти файлы были проверены на всех целевых компьютерах. Процедура усечения журналов источника не дожидается преобразования журналов на всех конечных объектах, поскольку для конечных копий может быть настроено большое значение задержки преобразования. Однако усечение журналов на источнике резервной непрерывной репликации не выполняется, если один или несколько конечных объектов резервной непрерывной репликации для группы хранения недоступны. Чтобы усечение журналов на источнике резервной непрерывной репликации было возможно, конечные компьютеры резервной непрерывной репликации должны работать в оперативном режиме и быть доступны для источника.

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

• файл журнала был усечен на исходном компьютере резервной непрерывной репликации;
  
  
• номер версии файла журнала ниже контрольной точки для выбранной группы хранения;
  
  
• время, прошедшее с момента создания файла журнала, превышает значение ReplayLagTime + TruncationLagTime. (Описание этих параметров см. в подразделе "Изменения командлетов, связанные с резервной непрерывной репликацией" раздела Резервная непрерывная репликация.)
  
  

В средах с локальной непрерывной репликацией и кластера с непрерывной репликацией, дополненных резервной непрерывной репликацией, усечение файлов журналов активных и пассивных копий происходит при выполнении следующих трех условий:

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

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

Кроме того, если в среде используется протокол 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 Server 2007 блога команды разработчиков 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 и для операционной системы, и для каждого сетевого адаптера. Процедура их отключения описана ниже.

• Чтобы отключить функцию TCP Chimney, откройте окно командной строки и введите следующую команду: Netsh int ip set chimney DISABLED
  
  
• Для отключения других функций пакета SNP можно присвоить в реестре Windows параметрам TCP/IP EnableRSS и EnableTCPA значение 0. Дополнительные сведения о том, как это сделать, см. в статье 936594 базы знаний Майкрософт После установки пакета обновления 2 (SP2) или пакета Scalable Networking Pack на компьютере с системой Windows Server 2003 возможно возникновение проблем с сетью (на английском языке).
  
  
• Для получения сведений о том, как отключить эти функции на сетевом адаптере, обратитесь к инструкции, прилагаемой к нему, или свяжитесь с его изготовителем.
  
  

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