Репликация Exchange 2 013 даг
Я нахожусь в процессе установки 2-го Exchange Server 2013 и затем Создаю DAG в целях аварийного восстановления. В данный момент у нас есть один Сервер Exchange CAS/почтового ящика 2013, установленный на основном сайте, и теперь они хотели бы иметь второй Exchange Server на сайте DR. Основной сайт и сайт DR, LAN расширяется соединенная мостом, таким образом, они находятся на той же LAN.
Мой вопрос состоит в том, если возможно передать Трафик репликации по этой той же сети, которая привыкла к Почтовым ящикам/Домену сервера и т.д.? и если так, 2-й сервер должен быть установлен с ролями CAS/почтового ящика также?
Да, вы должны сделать ваш отказоустойчивый Exchange-сервер в CAS/Mailbox-сервер.
Помните, что это не специально для DR, это для отказоустойчивости. Событие DR также должно включать возможное повреждение базы данных (в этом случае БД будет просто реплицироваться и повреждаться на двух серверах). DR выполняется ТОЛЬКО с помощью автономных резервных копий, предпочтительно хранимых вне сайта.
Вам нужно будет сегментировать свои сайты и службы, чтобы пользователи не пытались подключиться к CAS обхода отказа. Проблема заключается в том, что обмен выбирает CAS на основе сайтов и служб, поэтому если ваше WAN соединение (которое является мостом) медленнее, чем ваша LAN (что является хорошим предположением), ваши пользователи будут жаловаться на то, что "Outlook медленный ...". Это потому, что они соединяются через WAN с сервером DR Exchange, это потому, что они оба находятся на одном и том же Сайте и Сервисном сайте.
Лучшее, что нужно сделать, это убедиться, что ваш DR-сайт разделен на Сайты и Сервисные службы. Это можно сделать через подсеть. Exchange-сервер посмотрит на сайты и службы, а затем примет решение о том, какой CAS использовать для клиентов
Также убедитесь, что у вас есть один CAS URL для автообнаружения, вам, вероятно, придется восстанавливать любые SSL/TLS-сертификаты, используемые для CAS, если у вас уже нет записи CAS в DNS, которую могут использовать оба сервера. В противном случае DR будет работать не так, как вы ожидаете, и не будет производить автообнаружение.
Обновление
На основании ваших вопросов:
Да, можно разделить Сайты и Сайты служб через подсеть. Даже если эта подсеть специально не маршрутизирована. Например:
Маршрутизированные подсети: Сайт 1: 10.0.1.0/24 Сайт DR Присоединен к локальной сети сайта 1: 10.0.1.0/24 Настройка сайтов и служб подсети: Сайт 1: 10.0.1.0/24 Сайт ДР Прикреплен к локальной сети сайта 1: 10.0.1.128/25
Видишь? Теперь все от 10.0.1.128 - 255 находится на Втором сайте в Сайтах и Сервисах. Это не имеет никакого отношения к IP-маршрутизации. Сайты и сервисы фильтруют сервисы на основе Сайтов и создают Сайты на основе Подсетей. Подсети в этом случае используются только как фильтр, а не как маршрут.
Вам необходимо создать вторую запись DNS для массива CAS. Я бы порекомендовал взглянуть на это и прочитать о "Массивах Exchange CAS". Ваш автообнаружение и сертификат должны будут отражать новое имя массива CAS. В противном случае ваши клиенты не будут доверять серверу во время обхода отказа. Лучшим способом создания этого сертификата является генерация сертификата с несколькими именами. Как минимум, вы должны включить следующие имена в свой сертификат:
1. Автообнаружение . 2. Имя массива CAS 3. OWA FQDN 4. Имя(и) сервера CAS (добавить по одной записи для каждого)
Таким образом, вы можете сгенерировать один сертификат для всех своих нужд.
Это просто лучшая практика, на вашем месте я бы прочитал, нашел видео и протестировал, прежде чем делать это в производстве. Я говорю это только потому, что вы, кажется, не уверены в сайтах и службах, сначала узнайте, как это работает, топология Exchange и маршрутизация будут иметь гораздо больший смысл после того, как вы поймете сайты и службы
.