Репликация группы доступности Exchange 2013

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

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

Источник

1 ответ

Да, вы должны превратить ваш сервер аварийного переключения в сервер CAS/Mailbox.

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

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

Лучше всего убедиться, что ваш сайт DR разделен на сайты и службы. Это можно сделать через подсеть. 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 Arrays". Ваше автообнаружение и сертификат должны отражать новое имя массива CAS. В противном случае ваши клиенты не будут доверять серверу во время аварийного переключения. Лучший способ создать этот сертификат - создать сертификат с несколькими именами. По крайней мере, вы должны указать следующие имена в своем сертификате:

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

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

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

Источник
Другие вопросы по тегам