В основном у нас есть главный сайт Exchange 2013 с ролями CAS и почтовых ящиков, и предположительно все пользователи подключаются к этому обмену из своего Outlook.
Теперь мы установили другой Exchange 2013 на сайте аварийного восстановления. Наш главный офис и сайт аварийного восстановления соединены с помощью моста Layer2, поэтому два коммутатора присоединены к одному домену и также находятся в одной сетевой подсети. Таким образом, два сервера Exchange имеют по одной сетевой карте на каждом из них, которая является локальной / доменной сетью.
Мы создали DAG, и репликация баз данных работает нормально ... но проблема, с которой мы сейчас сталкиваемся, заключается в том, что некоторые пользователи подключаются напрямую к DR Exchange из нашего главного офиса со своим Outlook, что не то, что мы хотели бы иметь. Мы хотим, чтобы DR размещал копию БД и активировался только в том случае, если на основном сайте возникают какие-то проблемы, и мы должны переключать все на сайте DR вручную.
Мы заметили эту проблему, когда пошли проверять статус подключения в их Outlook и заметили, что прокси-сервер, к которому они подключены, является обменом аварийного восстановления.
Есть идеи, как мы можем решить эту проблему?
Exchange поддерживает сайт AD. Вам нужно поместить два сайта в отдельные сайты AD. Затем создайте уникальные URL-адреса для каждого сайта. Затем клиенты будут подключаться к серверу, расположенному на том же сайте AD, что и их почтовый ящик, а не через глобальную сеть. На данный момент Exchange не знает, что он находится на двух разных сайтах, поэтому рассматривает все как одну большую локальную сеть. Я ожидаю, что вы также обнаружите, что компьютеры Windows используют контроллеры домена и в другом месте - если вы не применили некоторые уловки с брандмауэром, чтобы остановить его (вместо того, чтобы правильно использовать сайты и службы).
Как очень хорошо объяснено в эта статья из блога группы разработчиков Exchange, в Exchange 2013 сервер CAS действует как прокси-сервер без сохранения состояния для сервера базы данных почтовых ящиков, на котором в настоящее время активен запрошенный почтовый ящик. Таким образом, даже если CAS, отвечающий на запрос ваших клиентов, находится на сайте аварийного восстановления, соединение всегда проксируется с серверами почтовых ящиков на первичном сайте (при условии, что все ваши копии базы данных активированы на основном сайте).
Если вы хотите предотвратить любые «случайные» подключения к CAS на вторичном сайте, вам придется развернуть модель «привязанного» пространства имен с отдельными пространствами имен для каждого сайта.
Но если это нормально, если примерно половина ваших подключений будет проксироваться сервером DR CAS (и поскольку вы используете растянутую VLAN, я предполагаю, что задержка и пропускная способность не являются большой проблемой), то, сохраняя единое пространство имен, вы значительно упрощая вашу среду.
В качестве альтернативы, если вы не хотите использовать вторичный сервер CAS, кроме DR, и при необходимости хотите обновить конфигурацию вручную, вы можете указать DNS-запись на сервер (ы) CAS только на основном сайте, установите его с помощью низкий TTL и обновите его, чтобы он указывал на сервер (ы) CAS во вторичном DNS, когда это необходимо. В этом случае вы, вероятно, также можете захотеть предотвратить активацию базы данных почтовых ящиков на вторичном сайте:
Set-MailboxServer <secondary mailbox server> –DatabaseCopyAutoActivationPolicy Blocked
Но опять же, это удаляет любую автоматизацию из механизма аварийного переключения, поэтому, если у вас есть только один почтовый ящик или серверы CAS на первичном сайте, и любой из них выйдет из строя, ваши пользователи не смогут подключиться, пока вы не обновите конфигурацию вручную.
Я также хотел бы убедиться, что все ваши базы данных в настоящее время активны в основном центре обработки данных, только запустив:
Get-MailboxDatabaseCopyStatus -Identity <Main Exchange Database Server> | Format-List
Если Status отличается от установленной для любой данной базы данных, тогда эта БД активна на другом сервере, возможно на вторичном сайте.
В конечном счете, это во многом зависит от того, сколько серверов Exchange Server вы развернули (и являются ли они мультиролевыми или нет), используемой модели пространства имен и механизма, который вы приняли для распределения нагрузки между ними (циклический перебор DNS, оборудование балансировщик нагрузки и т. д.)
В качестве последнего замечания, если вы еще этого не сделали, вам следует взглянуть на настройку Режим координации активации центра обработки данных