Назад | Перейти на главную страницу

Репликация Exchange 2013 DAG

Я настраиваю 2-й сервер Exchange Server 2013, а затем создаю группу DAG для аварийного восстановления. На данный момент у нас есть один сервер CAS / Mailbox Exchange 2013, установленный на основном сайте, и теперь они хотели бы иметь второй сервер Exchange на сайте аварийного восстановления. Основной сайт и локальная сеть DR-сайта имеют расширенный мост, поэтому они находятся в одной локальной сети.

У меня вопрос, можно ли передавать трафик репликации по той же сети, которая используется для почтовых ящиков / домена и т. Д.? и если да, то следует ли установить второй сервер с ролями CAS / почтового ящика?

Да, вы должны превратить свой резервный сервер обмена в сервер CAS / почтовых ящиков.

Помните, что это не специально для аварийного восстановления, это для аварийного переключения. Событие аварийного восстановления также должно включать возможное повреждение базы данных (которая в этом случае будет реплицирована и повреждена на двух серверах). DR выполняется ТОЛЬКО с автономными резервными копиями, предпочтительно хранящимися вне офиса.

Вам нужно будет сегментировать свои сайты и службы, чтобы пользователи не пытались подключиться к аварийному CAS. Проблема, с которой вы столкнетесь, заключается в том, что Exchange выбирает CAS на основе сайтов и сервисов, поэтому, если ваша WAN-ссылка (то есть мостовая) медленнее, чем ваша LAN (что является хорошим предположением), ваши пользователи будут жаловаться, что «Outlook работает медленно ... . ". Это связано с тем, что они подключаются через глобальную сеть к серверу DR Exchange, это потому, что они оба находятся на одном сайте и на одном сайте служб.

Лучше всего убедиться, что ваш сайт аварийного восстановления разделен на сайты и службы. Это можно сделать через подсеть. Exchange просмотрит сайты и службы, а затем примет решение о том, какой CAS использовать для клиентов.

Также убедитесь, что у вас есть один URL-адрес CAS для автообнаружения. Возможно, вам потребуется повторно сгенерировать все сертификаты SSL / TLS, используемые для CAS, если у вас уже нет записи CAS в DNS, которую могут использовать оба сервера. В противном случае DR не будет работать так, как вы ожидаете, и не будет автоматически обнаруживаться.

Обновить

На основании ваших вопросов:

  1. Да, можно разделить сайты и сервисы через подсеть. Даже если эта подсеть специально не маршрутизируется. Например:

    Routed Subnets:
    Site 1: 10.0.1.0/24
    DR Site Attched to Site 1 LAN: 10.0.1.0/24
    
    Sites and Services Subnet Configuration:
    Site 1: 10.0.1.0/24
    DR Site Attached to Site 1 LAN: 10.0.1.128/25
    

Видеть? Теперь все от 10.0.1.128 до 255 находится на втором сайте в разделе «Сайты и службы». Это не имеет ничего общего с IP-маршрутизацией. Сайты и службы фильтруют службы на основе сайтов и создают сайты на основе подсетей. Подсети в этом случае используются только как фильтр, а не как маршрут.

  1. Вам необходимо создать вторую запись DNS для массива CAS. Я бы рекомендовал поискать это и прочитать о «Массивах Exchange CAS». Ваше автообнаружение и сертификат должны отражать новое имя массива CAS. В противном случае ваши клиенты не будут доверять серверу во время аварийного переключения. Лучший способ создать этот сертификат - создать сертификат с несколькими именами. По крайней мере, вы должны включить в свой сертификат следующие имена:

    1. Autodiscover
    2. CAS Array Name
    3. OWA FQDN
    4. CAS Server Name(s) (add one entry for each)
    

Таким образом, вы можете создать единый сертификат для всех ваших нужд.

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