[ko4evneg]

Балансировку и отказоустойчивость можете реализовать так:
1) DNS RR - дешево и сердито. Создаете по две A записи на каждый сервис во внешней и внутренней зоне. Из минусов только неровное распределение нагрузки.
2) Дополнительный балансировщик. Нужен дополнительный сервак или железяка для него. Соответственно из минусов расходы на них и единственная точка отказа.
3) IIS ARR. Никогда не пробовал такой способ, насколько я знаю тоже нужен доп сервак. Соответственно минусы такие же как и во втором варианте.
4) Для полностью отказоустойчивого решения добавляем ко 2 или 3 варианту еще по серваку для избавления от единственной точки отказа. Из минусов - цена.
Если сервера более-менее мощные, а клиентов не больше 1000 я бы советовал ограничиться DNS RR. Т. к. CAS в 2013 выполняют в основном роль прокси, и основная балансировка будет определятся распределением баз по DAG.

Для переключения почтового потока с вашего сервера, если вы не рассматриваете сценарий сосуществования, настраиваете и проверяете exchange. Это accepted domains, send/receive connectors, autodiscover, outlook anywhere, virtual directories. Не забудьте прописать HELO, A и PTR записи для send коннекторов. По умолчанию почта принимается CAS серверами, так что в зависимости от выбранного способа балансировки нацеливаете MX запись вашего домена (предварительно добавленного в accepted) либо на IP балансировщика, либо на IP CAS при выборе DNS RR (тут надо будет создать две MX записи для обоих серверов). Если есть SPF запись, не забудьте туда добавить IP ваших CAS.

[osada]

1) " Создаете по две A записи на каждый сервис во внешней и внутренней зоне." - если у меня только один внешний IP адрес, то тогда и прописывать ничего не надо дополнительно во внешней зоне? Только во внутренней (там уже прописано, как указал в своем посте)?

2) Балансировщик не могу использовать по причине финансов. Уже ранее думал про этот момент.

4) Добавить еще по серверу также вряд ли получится по причине финансов.

"Если сервера более-менее мощные, а клиентов не больше 1000 я бы советовал ограничиться DNS RR." - да, сервера средней мощности и клиентов будет меньше 1000. Вот тут стопорю как дальше настроить роутинг внешней почты. Исходя из того, что не получится докупить что-то еще и у меня есть только эти пару серверов, как мне поступить?

Просьба большая объяснить детальнее что мне нужно делать.

Т.е., на данный момент на текущем почтовом сервере одна NIC содержит внешний IP 1.2.3.4 и внутренний IP 192.168.50.3.
Чтобы желательно ничего не менять во внешнем DNS при переходе на Exchange, что мне нужно доделать чтобы нормально шла внешняя почта в обе стороны?

Должен ли я менять внутрениий IP на серверах Exch1 или Exch2?

Ранее я описал самый простой вариант, когда просто поменять внутренний IP на exch1 на 192.168.50.3 и на второй NIC добавить внешний IP 1.2.3.4 наподобие сетевых настроек текущего почтового сервера. Тогда схема выглядит как 1CAS + 2 MBX. Она работоспособна?

Если да, то какие еще альтернативные варианты можно рассмотреть?

[osada]

Будет ли такой вариант работоспособный?

Внутренние IP адреса двух серверов не меняем, DNS RR создаем с именем mail.test.com с указанием на эти два IP адреса серверов (это уже настроено).

Затем создаем MX - запись с ссылкой на mail.test.com.
При этом настраиваем внешний IP 1.2.3.4 на сетевых картах обоих серверах, но на одном сервере просто вытаскиваем патч-корд или отключаем саму карту. В случае краха первого сервера втыкаем патч-корд и почта будет дальше работать?

[ko4evneg]

Тогда схема выглядит как 1CAS + 2 MBX. Она работоспособна? »

Да, но тогда вы теряете отказоустойчивость на уровне CAS.

При этом настраиваем внешний IP 1.2.3.4 на сетевых картах обоих серверах, но на одном сервере просто вытаскиваем патч-корд или отключаем саму карту. В случае краха первого сервера втыкаем патч-корд и почта будет дальше работать? »

Должен, но тестирование никто не отменял конечно!

Вообще я бы взял второй внешний IP (например с фтп) и сделал трансляцию 25,80,443 порта на внутренний IP второго сервера. Таким образом будет достигнута автоматическая отказоустойчивость на уровне CAS серверов. И на этот IP направить вторую внешнюю MX запись.

[osada]

"Вообще я бы взял второй внешний IP (например с фтп) и сделал трансляцию 25,80,443 порта на внутренний IP второго сервера. Таким образом будет достигнута автоматическая отказоустойчивость на уровне CAS серверов. И на этот IP направить вторую внешнюю MX запись." - я тоже про этот момент думал, но как тогда правильно указать MX запись для второго внешнего IP во внешнем DNS?

Например, mail.test.com, MX preference 5, IP 1.2.3.4 - т.е., мы тут указываем, что если на первом сервере настроить на внешней NIC внешний IP 1.2.3.4, то, все ok, почта будет работать. При это происходит трансляция с 1.2.3.4 на первый CAS exch1.test.com, IP 192.168.50.10.

А как правильно прописать второй внешний IP 1.2.3.5? Получается, что во внешнем DNS нужно указать второй хост, например, mail2.test.com, MX preference 10, IP 1.2.3.5. При это происходит трансляция с 1.2.3.5 на второй CAS exch2.test.com, IP 192.168.50.11.

Прав ли я?

Например, перестанет работать mail.test.com, т.е. exch1.test.com с IP 192.168.50.10, По идее внешняя почта должна увидеть, что есть mail2.test.com работает и начнет слать почту через mail2.test.com.

Если да, то как правильно публиковать внешние URL для виртуальных каталогов Exchange на обоих серверах в соответствии с mail.test.com и mail2.test.com?

[ko4evneg]

Прав ли я? »

просто сделайте две MX записи
MX preference 5, IP 1.2.3.4
MX preference 5, IP 1.2.3.5
У вас будет и отказоустойчивость и балансировка на уровне MX

Если да, то как правильно публиковать внешние URL для виртуальных каталогов Exchange на обоих серверах в соответствии с mail.test.com и mail2.test.com? »

Если мы считаем, что у вас с IP 1.2.3.4 и 1.2.3.5 проброшены 80 и 443 порты на CASы, то создаете две A записи, плюс две для автодискавера:
mail.test.com 1.2.3.4
mail.test.com 1.2.3.5
autodiscover.test.com 1.2.3.4
autodiscover.test.com 1.2.3.5
Затем указываете на всех виртуальных директориях URL доступа http[s]://mail.test.com/<имя директории>

[osada]

Понятно, спасибо!

Значит я переборщил тут с созданием еще одного DNS имени mail2.test.com. Все можно сделать на уровне одной записи mail.test.com

И как я понял, при публикации первого и второго серверов в EAC в виртуальных каталогах нужно указывать URL не как exch1.test.com и exch2.test.com соответственно, а сразу mail.test.com в обоих случаях.

Прав ли я?

И еще вопрос касательно рекомендаций по установке выделенных аппаратных или программных балансировщиков.

Если можно просто на уровне внешего DNS указывать несколько IP для одной записи и использовать DNS RR, то в каких случаях насоятельно рекомендуется покупать отдельно балансировщик траффика?

Тот же Kemp или F5, как пример.

[ko4evneg]

И как я понял, при публикации первого и второго серверов в EAC в виртуальных каталогах нужно указывать URL не как exch1.test.com и exch2.test.com соответственно, а сразу mail.test.com в обоих случаях. »

Верно. Так же и в остальных виртуальных директориях.

Если можно просто на уровне внешего DNS указывать несколько IP для одной записи и использовать DNS RR, то в каких случаях насоятельно рекомендуется покупать отдельно балансировщик траффика? »

При больших инсталляциях. Например нагрузка на CAS при 10000 юзерах уже будет весьма ощутимой. Плюс балансировщики 7 уровня могут мониторить отказ на уровне приложений, DNS RR такой возможности не дает. В 2013 роль CAS балансировщика сильно уменьшилась, поскольку теперь не нужна привязка (affinity) для сессий и множество задач перенесено с CAS на MBX (например генерация OWA).

[osada]

Спасибо, понятно.