none
Расширенные настройки CAS сервера RRS feed

  • Вопрос

  • Доброго времени суток!

    Знакомлюсь с версией 2013 и сколько не читал разлиную литературы так и не смог найти ответы на свои вопросы:

    Предварительно:

    Планируется 2 площадки для размещения CAS + MBX, оба имеют доступ к интернету и получают корреспонденцию. 2 сервера MBX в DAG. Клиенты и контроллеры только на одной площадке. Из этого вытекают несколько вопросов:

    1) Необходимо ли разделять на сайты и размещать контроллер еще и на другой площадке?

    2) Каким образом запретить клиентам использовать второй сервер CAS для работы? И в случае падения переключать хотя бы в ручную на работу со вторым CAS?

    3) Работает ли в 2013 HTTP REDIRECT в режиме сосуществования с 2007 сервером? Например клиенты на 2007, а ссылка OWA и Activesync опубликована на 2013, необходимо ли дополнительн опубликовать 2007? 

    Заранее спасибо за любую информацию или помощь.

    1 апреля 2015 г. 16:53

Ответы

  • Так же дополню.

    1. Точно не уверен, но в многосайтовой среде пользователи вроде как должны коннектиться к тем CAS, которые в одном с ними сайте, если они доступны.

    2. Репликация БД по узкому каналу это довольно сомнительное решение. А если он еще и не стабилен, то будет совсем плохо. Подумайте, надо ли оно. Может лучше все разместить на одной стабильной площадке? Даже бэкапы ложить на вторую площадку по узкому каналу будет довольно сложно. 

    3. Для обеспечения сохранности входящей почты можете настроить МХ серверы с разным приоритетом. Более низкий отдайте МХ на второй площадке. В качестве ПО можете использовать Exchange EDGE или Linux + postfix (exim, sendmail, qmail). Если основная площадка ляжет, входящая почта будет скапливаться на МХ второй площадки. Как только восстановитесь, можно будет протолкнуть почту из очереди.

    • Помечено в качестве ответа Nikolay_KZ 2 апреля 2015 г. 6:25
    • Снята пометка об ответе Nikolay_KZ 2 апреля 2015 г. 12:26
    • Помечено в качестве ответа Nikolay_KZ 3 апреля 2015 г. 8:57
    2 апреля 2015 г. 6:00
  • Если вы не делаете на второй площадке полноценный резервный ЦОД, то нет смысла туда тащить один сервер Exchange.

    Если будет серьезная катастрофа на основной площадке, то пользователи всё равно не смогут работать, т.к. они на той же разрушенной площадке. Если говорить о частичном отказе (почты) первой площадки, то одиночный сервер на второй площадке придется оживлять ручками, да и через относительно узкий канал пользователи не смогут нормально работать. А переключаться обратно будет вообще трудно и долго. Т.е. никакой автоматики и ее выгод тут нет и близко.

    Поэтому я бы не стал распылять ресурсы, а построил полноценную инфраструктуру на первой площадке.

    На вторую можно сливать бакапы почтовых баз.

    Что касается второго внешнего канала приема почты, то есть два варианта. Либо просто протащить трафик по туннелю через внутренний канал на первую площадку (на отдельный коннектор приема) - это самый дешевый вариант, либо поставить на второй площадке сервер пересылки - это дороже, т.к. нужно оборудование, антиспам. Почтовик можно бесплатный, можно Exchange конечно поставить без почтовых баз и без DAG как просто релей, но смысл тратить большие деньги на такой примитив? (если только рассмотреть вопрос выгод от унификации и отсутствия специалистов по альтернативным системам). Но я бы рекомендовал использовать эту лицензию на первой площадке и сделать не два, а три сервера в DAG - это даст больше плюсов. (особенно если у вас DNS RR для CAS)


    Сазонов Илья http://isazonov.wordpress.com/

    • Помечено в качестве ответа Nikolay_KZ 3 апреля 2015 г. 8:57
    3 апреля 2015 г. 5:56
    Модератор

Все ответы

  • Что вы ожидаете от разнесения по разным площадкам? Что вторая будет полностью заменять первую при её отказе? Если так, то у вас будет два ЦОД и сервисы должны резервироваться в них полностью.

    Относительно Exchange это означает полное дублирование во втором ЦОД и  два пространства имен с ручным переключением на резервный ЦОД.


    Сазонов Илья http://isazonov.wordpress.com/

    1 апреля 2015 г. 17:44
    Модератор
  • 1. Согласен с Ильей. В случае разнесения по площадкам понадобится поднимать минимум 4 сервера с ролью CAS+MBX и еще 2 DC. Точно это необходимо? Каждая база будет иметь аж 3 пассивных копии. Если серверов будет меньше, то смысла разносить площадки нет.

    2. Разные варианты. Самый простой - запись в DNS с низким TTL. Но идея не самая хорошая. Лучше настроить roundrobin. В случае если ляжет один сервер, Outlook сам найдет второй и подключится к нему. А еще лучше - поднять HAProxy или использовать HNLB (железный балансировщик нагрузки). В общем, это отдельный очень серьезный вопрос.

    3. Для OWA - нет. Надо заходить по старому URL или публиковать дополнительно. Activesync и Outlook Anywhere работать будут.

    1 апреля 2015 г. 21:02
  • Я с Вами согласен полностью, что самая оптимальная конфигурация это минимум 3 сервера.

    Задачей не является сохранить полною функциональность, сохранить базы данных и поступающий из интернет SMTP. CAS можно восстановить в течении 1 часа.

    Касательно второго вопроса, это как раз запрет на обслуживание клиентов OUTLOOK, т.к. в первом варианте сайт один, но 2 разные площадки. Если я правильно понимаю, обнаружение происходит по Autodiscover сервису, которые он выбирает из Active Directory каталога. У клиентов в равной степени есть шанс получить оба сервера, как сделать так, чтобы клиенты подключившись к серверу второму, перенаправлялись на первый.

    (   Клиенты --->     (CAS01 + MBX01)  ) <---узкий канал----> ( (CAS02 + MBX02) )

    Пространство одно domanlocal.com, сайт ROGAANDKOPITA

    Канал нужен только для репликации баз данных, но как я понимаю, клиенты все равно будут находить CAS02 и к нему подключаться. Вот это и нужно запретить. Как? ))



    • Изменено Nikolay_KZ 2 апреля 2015 г. 3:28
    2 апреля 2015 г. 3:26
  • Exchange это программа, которая заточена на определенные сценарии работы. Это касается "высокой доступности" и "устойчивости". Поэтому ваши попытки заставить Exchange работать не "по написанному", погрязнут неведомых проблемах.

    Описание https://technet.microsoft.com/en-us/library/dd638137%28v=exchg.150%29.aspx

    По вашему описанию можно заключить, что вам достаточно иметь классическую схему на основной площадке, а базы просто бакапить на хранилище другой площадки.


    Сазонов Илья http://isazonov.wordpress.com/

    2 апреля 2015 г. 4:44
    Модератор
  • Так же дополню.

    1. Точно не уверен, но в многосайтовой среде пользователи вроде как должны коннектиться к тем CAS, которые в одном с ними сайте, если они доступны.

    2. Репликация БД по узкому каналу это довольно сомнительное решение. А если он еще и не стабилен, то будет совсем плохо. Подумайте, надо ли оно. Может лучше все разместить на одной стабильной площадке? Даже бэкапы ложить на вторую площадку по узкому каналу будет довольно сложно. 

    3. Для обеспечения сохранности входящей почты можете настроить МХ серверы с разным приоритетом. Более низкий отдайте МХ на второй площадке. В качестве ПО можете использовать Exchange EDGE или Linux + postfix (exim, sendmail, qmail). Если основная площадка ляжет, входящая почта будет скапливаться на МХ второй площадки. Как только восстановитесь, можно будет протолкнуть почту из очереди.

    • Помечено в качестве ответа Nikolay_KZ 2 апреля 2015 г. 6:25
    • Снята пометка об ответе Nikolay_KZ 2 апреля 2015 г. 12:26
    • Помечено в качестве ответа Nikolay_KZ 3 апреля 2015 г. 8:57
    2 апреля 2015 г. 6:00
  • Как раз хотел написать, тоже самое разъяснение.

    1) Разместить площадки по разным сайтам и регулировать подключение клиентов сервера CAS через Autodiscover Site Scope, понимаю что без контроллера домена в сайте на другой площадке не обойтись. Размещать все в одном сайте, не вижу смысла;

    2) Не так все плохо, канал стабильный и довольно широкий, по расчетам его хватать для репликации за глаза. Бакапы не кто не отменял, но есть конкретные требования, которые выполнить необходимо, с репликацией на вторую площадку возрастает показатель RPO;

    3) Да, я так и понял, нашел документацию с описание HTTP Redirect, но прошлый ваш пост меня убедил в этом еще больше. Осталось провести тестирование на стенде;

    Спасибо!

    2 апреля 2015 г. 6:13
  • Exchange это программа, которая заточена на определенные сценарии работы. Это касается "высокой доступности" и "устойчивости". Поэтому ваши попытки заставить Exchange работать не "по написанному", погрязнут неведомых проблемах.

    Описание https://technet.microsoft.com/en-us/library/dd638137%28v=exchg.150%29.aspx

    По вашему описанию можно заключить, что вам достаточно иметь классическую схему на основной площадке, а базы просто бакапить на хранилище другой площадки.


    Сазонов Илья http://isazonov.wordpress.com/

    Прошу меня извинить конечно, не хочу показаться грубым. Поймите я прекрасно понимаю для каких задач предназначен продукт Microsoft Exchange Server 2007/2010/2013 и способы его развертывания, а так же хорошо понимаю, что такое "Высокая доступность", но и Вы поймите меня правильно, я не писал о том, что требуется высокая доступность. Я указал конкретные вопросы по реализации определенных требований. Не всегда каждая компания обладает ресурсами по организации избыточности серверов по 2 на каждую площадку с железным NLB, но определенные требования выполнить необходимо, используя по максимуму те возможности, которыми она обладает. Мне самому не нравиться подобный вариант развертывания, но иногда выбора нет. 

    2 апреля 2015 г. 6:21
  • Собственно из ваших требований я вам и рекомендавал оптимальное решение: самое простое, самое надежное и самое дешевое.

    Вы в это не вдумались и пытаетесь развивать идею по разнесению узлов кластера (а DAG это кластер) по разным площадкам - георазнесенный кластер это плохое решение в вашей ситуации. Плюс это дорого: надо еще всю инфраструктуру развернуть на второй площадке. Плюс еще предполагаете, что DAG вам базы сохранит - опять ошибаетесь: в вашей конфигурации не сохранит. Плюс если вы считаете только трафик репликации, то опять ошибаетесь, потому что будет работать Safety Net. И это еще не все "плюсы" :-)


    Сазонов Илья http://isazonov.wordpress.com/

    2 апреля 2015 г. 9:59
    Модератор
  • Кстати Вы правы я не посчитал Sefety Net. Спасибо.

    Хотелось бы услышать Ваше мнение касательно такого варианта, если забыть о рекомендации от Ross Smith о минимум 4 серверах и порасуждать, чем может грозить такой вариант из 3 серверов?

    


    Если действительно рассмотреть такой вариант что развернуться больше не где. Заранее благодарю! 
    • Изменено Nikolay_KZ 2 апреля 2015 г. 11:04
    2 апреля 2015 г. 11:03
  • Если вы не делаете на второй площадке полноценный резервный ЦОД, то нет смысла туда тащить один сервер Exchange.

    Если будет серьезная катастрофа на основной площадке, то пользователи всё равно не смогут работать, т.к. они на той же разрушенной площадке. Если говорить о частичном отказе (почты) первой площадки, то одиночный сервер на второй площадке придется оживлять ручками, да и через относительно узкий канал пользователи не смогут нормально работать. А переключаться обратно будет вообще трудно и долго. Т.е. никакой автоматики и ее выгод тут нет и близко.

    Поэтому я бы не стал распылять ресурсы, а построил полноценную инфраструктуру на первой площадке.

    На вторую можно сливать бакапы почтовых баз.

    Что касается второго внешнего канала приема почты, то есть два варианта. Либо просто протащить трафик по туннелю через внутренний канал на первую площадку (на отдельный коннектор приема) - это самый дешевый вариант, либо поставить на второй площадке сервер пересылки - это дороже, т.к. нужно оборудование, антиспам. Почтовик можно бесплатный, можно Exchange конечно поставить без почтовых баз и без DAG как просто релей, но смысл тратить большие деньги на такой примитив? (если только рассмотреть вопрос выгод от унификации и отсутствия специалистов по альтернативным системам). Но я бы рекомендовал использовать эту лицензию на первой площадке и сделать не два, а три сервера в DAG - это даст больше плюсов. (особенно если у вас DNS RR для CAS)


    Сазонов Илья http://isazonov.wordpress.com/

    • Помечено в качестве ответа Nikolay_KZ 3 апреля 2015 г. 8:57
    3 апреля 2015 г. 5:56
    Модератор