В данном разделе описано, как организация Contoso, Ltd. использует резервную непрерывную репликацию в ситуации устойчивости сайта. В данной ситуации происходит отказ основного центра данных, и Contoso, Ltd. принимает решение активизировать дополнительный центр данных. После активации дополнительного центра данных основной центр данных перенастраивается и в конечном итоге восстанавливается в качестве основного при управляемом переключении. Contoso, Ltd. имеет два центра данных: основной центр данных, называемый Active Directory SITEA, и второй резервный центр данных, называемый Active Directory SITEB. SITEA расположен в Портленде, штат Орегон, а SITEB расположен в Сан-Хосе, штат Калифорния.

SITEA содержит следующие компоненты инфраструктуры.

SITEB содержит следующие компоненты инфраструктуры.

Все серверы на обоих сайтах Active Directory настроены на использование DNS-серверов, интегрированных с Active Directory. Для интервала репликации Active Directory для обоих сайтов Active Directory установлено 15 минут.

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

Копировать код
Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC
Примечание.
Для одновременной активации всех групп хранения на EXCMS1 для SCR выполните следующую команду: Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

Состояние SCR для всех групп хранения было проверено с помощью командлетов Test-ReplicationHealth и Get-StorageGroupCopyStatus командной консоли Exchange. Например:

Копировать код
Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

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

Сбой основного узла и активация резервного узла

Неожиданно без каких-либо предупреждений в Портленде происходит сильное землетрясение. И хотя никто серьезно не пострадал, SITEA причинен настолько значительный ущерб, что пришлось отключить критические коммунальные услуги, такие как электро- , водоснабжение и подача природного газа. Поскольку возможно, что Contoso, Ltd. сможет использовать SITEA только через несколько месяцев, было принято решение выполнить ручную активацию SITEB для работы со службами сообщений и данными.

Активация SITEB начинается с проверки служб каталогов и разрешение DNS. Поскольку SITEB уже содержит сервер каталогов, на котором также размещен DNS-сервер, интегрированный с Active Directory, эти службы исправны, актуальны и на них почти не повлияло отключение SITEA. После проверки служб каталогов и DNS-сервера начинается активация целей SCR и восстановление кластерного сервера почтовых ящиков. Для этого выполняются следующие действия в указанном порядке.

  1. Командная консоль Exchange открывается на узле NODEC, затем выполняются следующие команды для подготовки к подключению целей SCR.

    Копировать код
    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
    Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
    Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force
    
    Важно!
    При недоступности источника SCR должен быть указан параметр Force.
    Примечание.
    Кроме того, что можно выполнить три отдельные команды Restore-StorageGroupCopy, как показано в действии 1, также можно использовать новый сценарий под названием GetSCRSources.ps1, включенный в Microsoft Exchange Server 2007 с пакетом обновления 1 (SP1), и передать результат сценария одной задаче Restore-StorageGroupCopy следующим образом: GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force
  2. Использование оснастки «Управление DNS» для удаления существующей записи DNS для EXCMS1 из DNS.

    Примечание.
    Этот шаг необходим только для отказоустойчивых кластеров под управлением Windows Server 2008. Это связано с тем, что служба кластеров выполняется в контексте безопасности локальной системы. Этот шаг не требуется для отказоустойчивых кластеров под управлением Windows Server 2003 при использовании для обоих отказоустойчивых кластеров одной учетной записи службы кластеров.
  3. Резервная непрерывная репликация отключена для всех групп хранения с целью подготовки к процессу /RecoverCMS. Если резервная непрерывная репликация не отключена для всех групп хранения, при выполнении команды Setup /RecoverCMS произойдет сбой. Отключить резервную непрерывную репликацию можно, выполнив следующие команды:

    Копировать код
    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
    Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
    Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False
    
  4. Восстановление кластерного сервера почтовых ящиков (EXCMS1) осуществляется параметра RecoverCMS программы установки. Восстановление осуществляется на узле NODEC с помощью выполнения следующей команды:

    Копировать код
    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>
    
    Обратите внимание на следующие сведения:

    • Значение параметра CMSIPAddress в предыдущей команде скорей всего будет IP-адресом, отличающимся от исходного IP-адреса EXCMS1. Это объясняется тем, что восстановление EXCMS1 осуществляется вне узла. Т.е., изначально он размещался на SITEA и восстанавливается на SITEB.

    • Команда Setup /RecoverCMS будет успешно выполнена после репликации DNS и удаления кэша DNS сервера восстановления (NODEC). При сбое установки следует использовать NSLookup из основного контроллера домена (PDC) и NODEC, чтобы убедиться, что верный IP-адрес разрешается в NODEC, затем повторно запустить программу установки.

    • В отказоустойчивых кластерах под управлением Windows Server 2003 объект компьютера для EXCMS1 сбрасывается во время выполнения процесса Setup /RecoverCMS. Для успешного завершения программы установки этот сброс должен быть реплицирован на локальный сайт Active Directory. Если PDC находится не на локальном сайте Active Directory, убедитесь в наличие работающих связей сайта Active Directory между PDC и локальным узлом Active Directory.

    • После завершения процесса восстановления программы EXCMS1 восстанавливается на узле SITEB и теперь размещается на NODEC в SCC с одним узлом под названием DRCLUS1.

    • В результаты выполнения операции восстановления кластерного сервера почтовых ящиков для параметра TTL DNS для EXCMS1 снова устанавливается значение по умолчанию, 20 минут. Необходимо опять установить значение «пять минут», выполнив следующую команду, а затем остановив и снова запустив кластерный сервер почтовых ящиков.

      Копировать код
      Cluster.exe res EXCMS1 /priv HostRecordTTL=300
      
  5. Далее выполняется подключение баз данных в трех группах хранения с помощью задачи Mount-Database.

  6. Выполнение операции восстановления для других ролей сервера (то есть роли сервера клиентского доступа и роли транспортного сервера-концентратора) в этом сценарии не требуется, поскольку на узле SITEB уже существуют CAS2 и HUB2.

    Примечание.
    Как часть операции восстановления для сервера клиентского доступа, внешние URL-адреса должны быть перенастроены для указывания на серверы клиентского доступа в SITEB.
    Примечание.
    Этот примерный сценарий не включает восстановление пограничных транспортных серверов. Если на узле SITEA находились пограничные транспортные серверы, которые были потеряны при сбое, новые пограничные транспортные серверы должны быть переведены в оперативный режим на SITEB, а записи DNS почтового обменника (MX) для доменов SMTP Contoso должны быть обновлены для указания на новые пограничные транспортные серверы.
  7. Если организация Contoso включает дополнительные сайты Active Directory, сообщения будут поставлены в очередь основного сайта Active Directory. После реплицирования информации о членах сайта для EXCMS1 для всех остальных сайтов Active Directory для очередей SMTP с сообщениями для основного узла может быть выполнено повторное подключение. (При отсутствии повторения вручную модуль транспорта автоматически повторит подключение для очереди через 12 часов.) При этом сообщения будут повторно классифицированы. После выполнения классификации сообщения будут доставлены EXCMS1 на SITEB.

Если на данном этапе DNS-серверы, используемые клиентами и другими серверами, имеют верный IP-адрес для EXCMS1, все клиенты должны иметь доступ к своим почтовым ящикам с помощью исходных методов доступа (например, Microsoft Outlook Web Access, Exchange ActiveSync и Microsoft Office Outlook).

Повторная настройка основного узла

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

  1. Сначала переведите службы каталогов и службы разрешения DNS-имени в оперативный режим, подключив DC1.

  2. После перевода DC1 в оперативный режим подключите CAS1 и HUB1.

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

    Копировать код
    Retry-queue [queue name] -Resubmit $True
    
  3. Переведите в оперативный режим узлы, на которых размещается кластерный EXCLUS1. Для целей этого сценария сначала подключается NODEA, затем NODEB.

  4. После подключения обоих узлов кластерный сервер почтовых ящиков останется в автономном состоянии. Это относится ко всем ресурсам, составляющим кластерный сервер почтовых ящиков, а особенно к ресурсу имени сети. Этот ресурс не может быть переведен в оперативный режим, поскольку EXCMS1 уже подключен и использует это же имя сети. Перевод EXCMS1 в оперативный режим на NODEA или NODEB приведет к конфликту имен сети.

  5. На узле, на котором в настоящий момент размещается группа ресурсов, включающая кластерный сервер почтовых ящиков, администратор удалить кластерный сервер почтовых ящиков и его ресурсы из отказоустойчивого кластера. Для этого администратор сначала удаляет из группы кластеров, содержащей кластерный сервер почтовых ящиков, любые ресурсы, которые не являются ресурсами Exchange. Затем администратор выполняет на NODEA следующую команду:

    Копировать код
    Setup.com /ClearLocalCMS /CMSName:EXCMS1
    
    Обратите внимание на следующее.

    • После удаления кластерного сервера почтовых ящиков и его ресурсов из EXCLUS1 рекомендуется использовать оснастку «Администратор кластера» или оснастку управления отказоустойчивыми кластерами для проверки удаления всех ресурсов кластерного сервера почтовых ящиков.

    • Теперь EXCLUS1 является отказоустойчивым кластером с двумя пассивными узлами, NODEA и NODEB, на каждом из которых установлена роль пассивного сервера почтовых ящиков. На этом этапе на EXCLUS1 отсутствует кластерный сервер почтовых ящиков.

  6. Так как узлы кластера работают под управлением Windows Server 2008, после выполнения команды Setup /ClearLocalCMS объект виртуального компьютера будет отключен. Чтобы снова включить его, нажмите кнопку Пуск, последовательно выберите пункты Программы и Администрирование, а затем выберите пункт Active Directory  — пользователи и компьютеры. Разверните узел домена и узел Компьютеры, щелкните правой кнопкой мыши элемент EXCMS1 VCO и выберите пункт Включить учетную запись.

  7. Для подготовки к управляемому переключению с SITEB на SITEA узел NODEA будет установлен в качестве цели SCR для групп хранения, размещенных на EXCMS1 на SITEB. Это осуществляется с помощью выполнения следующих команд на NODEC:

    Копировать код
    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
    Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
    Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA
    
    Примечание.
    Если на хранилище, используемое исходным отказоустойчивым кластером, не повлиял сбой SITEA, и если исходные базы данных и их журналы транзакций для трех групп хранения все еще размещаются на NODEA, они могут быть использованы для целей непрерывной репликации без необходимости выполнения полного повторного заполнения для каждой группы хранения на NODEA. Если существующие файлы не пригодны для использования или если для исходного кластерного сервера почтовых ящиков было настроено циклическое ведение журнала, для всех групп хранения должно быть выполнено полное повторное заполнение с помощью командлета Update-StorageGroupCopy.

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

  • Приостановка непрерывной репликации для всех трех целей SCR и последующее копирование файлов групп хранения и баз данных с NODEA в соответствующее место на NODEB.

  • Установка NODEB в качестве цели SCR EXCMS1.

Управляемое переключение на исходный основной узел

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

  1. Первый этап предназначен для отключения всех баз данных на EXCMS1. Это необходимо для остановки ведения файла журнала транзакций и подготовки к активации целей SCR на NODEA. Базы данных могут быть отключены с помощью консоли управления Exchange или командлета Dismount-Database в командной консоли Exchange.

  2. На NODEA администратор подготавливает все группы хранения к подключению. Эта задача выполняется с помощью следующих команд:

    Копировать код
    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
    Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
    Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA
    
    Обратите внимание на следующее.

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

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

    • Если NODEB также был настроен в качестве цели SCR, перед продолжением он должен быть отключен и восстановлен. В этом сценарии рекомендуется использовать командлет Restore-StorageGroupCopy сначала на NODEB, потом на NODEA, а затем выполнить Setup /RecoverCMS на NODEA.

  3. Кластерный сервер почтовых ящиков (EXCMS1) на DRCLUS1 должен быть остановлен. Эта задача должна быть выполнена с NODEC с помощью мастера управления кластерными серверами почтовых ящиков в консоли управления Exchange или с помощью командлета Stop-ClusteredMailboxServer в командной консоли Exchange.

  4. Запись A для EXCMS1 должна быть удалена из DNS с помощью оснастки «Управление DNS».

    Примечание.
    Запись A для EXCMS1 должна быть удалена, только если отказоустойчивый кластер работает под управлением Windows Server 2008. Если отказоустойчивый кластер работает под управлением Windows Server 2003, выполнение этого этапа не требуется.
  5. Восстановление кластерного сервера почтовых ящиков (EXCMS1) осуществляется параметра RecoverCMS программы установки. Восстановление осуществляется на узле NODEA с помощью выполнения следующей команды:

    Копировать код
    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>
    
    Обратите внимание на следующее.

    • Значение параметра CMSIPAddress в предыдущей команде скорей всего будет исходным IP-адресом для EXCMS1. Это связано с тем, что выполняется восстановление EXCLUS1 в исходное местоположение.

    • После завершения процесса восстановления программы EXCMS1 восстанавливается на узле SITEA и теперь размещается на NODEA в SCC с двумя узлами под названием EXCLUS1.

    Примечание.
    И снова, в этом сценарии SCC используется для целей примера. Если же в сценарии восстановления используется кластерный сервер почтовых ящиков в среде CCR, может потребоваться выполнение дополнительных действий. Операция /RecoverCMS приостанавливает непрерывную репликацию, В этом случае с NODEA на NODEB. Администратор должен выполнить командлет Resume-StorageGroupCopy для групп хранения, чтобы снова установить репликацию и действия повторения. Затем администратор должен проверить возобновление операций репликации. Если описанное ранее промежуточное сохранение NODEB выполнить не удалось, потребуется повторное заполнение пассивных копий групп хранения.
    • В результаты выполнения операции восстановления кластерного сервера почтовых ящиков для параметра TTL DNS для EXCMS1 снова устанавливается значение по умолчанию, 20 минут. Необходимо опять установить значение «пять минут», выполнив следующую команду, а затем остановив и снова запустив кластерный сервер почтовых ящиков:

      Копировать код
      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300
      
  6. Подключение баз данных в трех группах хранения осуществляется с помощью командлета Mount-Database.

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

    Примечание.
    Как часть операции восстановления для сервера клиентского доступа, внешние URL-адреса должны быть перенастроены для указывания на серверы клиентского доступа в SITEA.
    Примечание.
    Этот примерный сценарий не включает восстановление пограничных транспортных серверов. При использовании транспортных серверов-концентраторов записи DNS почтового обменника (MX) для домена SMTP Contoso должны быть обновлены для указания на верные пограничные транспортные серверы.
  8. Если организация Contoso включает дополнительные сайты Active Directory, сообщения будут поставлены в очередь основного сайта Active Directory. После реплицирования информации о членах сайта для EXCMS1 для всех остальных сайтов Active Directory для очередей SMTP с сообщениями для основного узла может быть выполнено повторное подключение. (При отсутствии повторения вручную модуль транспорта автоматически повторит подключение для очереди через 12 часов.) При этом сообщения будут повторно классифицированы. После выполнения классификации сообщения будут доставлены EXCMS1 на SITEA.

  9. Если на данном этапе DNS-серверы, используемые клиентами и другими серверами, имеют верный IP-адрес для EXCMS1, все клиенты должны иметь доступ к своим почтовым ящикам с помощью исходных методов доступа (например, Outlook Web Access, Exchange ActiveSync и Outlook). Кроме того, после репликации изменений DNS на SITEB, а также членства в сайте EXCMS1 транспортные серверы-концентраторы будут маршрутизировать сообщения на правильный сайт Active Directory. Администратор также может принудительно выполнить повторную передачу сообщений, которые могут находиться в очередях на HUB1 или HUB2. Эта задача может быть выполнена с помощью следующей команды:

    Копировать код
    Retry-queue [queue name] -Resubmit $True
    

Повторная настройка резервного узла

После завершения ручного управляемого переключения с SITEB на SITEA может быть возвращено рабочее состояние SITEB как резервного центра данных. Для этого необходимо удалить резервный кластерный сервер почтовых ящиков из отказоустойчивого кластера на SITEB и снова установить NODEC в качестве цели SCR для трех групп хранения на EXCMS1. Для этого выполняются следующие действия в указанном порядке.

  1. Во время управляемого переключения кластерный сервер почтовых ящиков, работающий на DRCLUS1 на SITEB, был остановлен для возможности перевода в оперативный режим на EXCLUS1 на SITEA. После успешного ввода EXCMS1 в эксплуатацию на EXCLUS1 сведения о конфигурации EXCMS1 должны быть удалены с DRCLUS1. Можно удалить сведения о конфигурации и полностью удалить EXCMS1 с DRCLUS1. Для этого необходимо удалить из группы кластеров, содержащей кластерный сервер почтовых ящиков, любые ресурсы, которые не являются ресурсами Exchange, а затем выполнить следующую команду:

    Копировать код
    Setup.com /ClearLocalCMS /CMSName:EXCMS1
    
  2. Так как узел кластера работает под управлением Windows Server 2008, после выполнения команды Setup /ClearLocalCMS объект виртуального компьютера будет отключен. Чтобы снова включить его, нажмите кнопку Пуск, последовательно выберите пункты Программы и Администрирование, а затем выберите пункт Active Directory — пользователи и компьютеры. Разверните узел домена и узел Компьютеры, щелкните правой кнопкой мыши элемент EXCMS1 VCO и выберите пункт Включить учетную запись.

  3. После удаления кластерного сервера почтовых ящиков и его ресурсов из DRCLUS1 администратор должен использовать оснастку «Администратор кластера» или оснастку управления отказоустойчивыми кластерами для проверки удаления всех ресурсов кластерного сервера почтовых ящиков.

  4. SCR настроена на реплицирование файлов журналов транзакций из трех групп хранения на EXCMS1 в цели SCR на узле NODEC. Настройка осуществляется с помощью следующих команд:

    Копировать код
    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
    Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
    Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC
    
    Примечание.
    Перед включением резервной непрерывной репликации для репликации групп хранения с узла EXCMS1 на узел NODEC необходимо убедиться в отсутствии конфликтов путей к группам хранения или базам данных. Необходимо также убедиться, что любые старые и ненужные файлы групп хранения и баз данных удалены из папок, на которые указывают исходные пути.
  5. Затем выполняется проверка состояния SCR для всех групп хранения с помощью командлетов Test-ReplicationHealth и Get-StorageGroupCopyStatus. Также необходимо проверить правильность работы перемещений кластерного сервера почтовых ящиков между узлами, а также операций резервного копирования и усечения журнала. После выполнения всех проверок для основного и дополнительного центров данных восстановлены исходные режимы работы в отношении системы обмена сообщениями Exchange 2007.