Тестировал.
Edge доступен.
По поводу почты от других — действительно, я для себя неправильно перевел стандарт…
А смысл для CAS в ДЦ я пояснил в комментариях повыше.
И как я сделал чтобы НЕ глючило тоже есть в моих ответах выше.
Очень большую роль в этом играет TMG.
Это минимальный период, на протяжении которого почтовые сервера продолжат отправлять почту, в случае если с первой попытки ни один из MX серверов не ответил.
По поводу растянутого NLB кластера — это не фича Server 2008 R2, а фича TMG.
Оба узла считают, что они в одной подсети, а TMG когда нужно подменяет адреса (но для работы этого, пришлось отказаться от обычного IpSec, данную проблему мне удалось победить только когда поднял между сайтами L2TP. Так и не разобрался из-за чего это)
NLB я также использовал для того, чтобы отсылать все запросы из внутренней сети к ближайшему CAS (по факту это я для себя и обозвал «VIP»)
И по поводу проблемы с RpcClientAccessServer — тут вы абсолютно правы, я наткнулся на данную проблему. И решил ее следующим образом:
В ActiveDirectory у меня создана OU, в которой находятся пользователи, которые работают ТОЛЬКО локально, и еще 1 OU — пользователи, которые работают еще и снаружи.
Также, в зависимости от того, в какой OU пользователь находится, он еще и помещается в соответствующую группу.
Сразу скажу — авторизация пользователя проходит не на CAS, а на TMG. TMG просто отдает данные вперед на CAS после авторизации.
Итак, в зависимости от того, в какой OU находится пользователь — если Only Local — то ящик создается в базе, которая активна в офисе, если Local and Remote — то ящик создается в базе, которая активна в ДЦ.
TMG же, основываясь на группе, в которой состоит пользователь, отдает запрос на нужный CAS (который прописан для каждой БД).
Ну а в случае сбоя, есть скрипт, который проверяет доступность серверов, и в случае того, если 120 секунд один из серверов недоступен, меняет данные на нужные через: Set-MailboxDatabase -RPCClientAccessServer <internal_only_CAS_Array_FQDN>
Только сейчас осознаю, что все было не так просто и было много нюансов, о которых просто забываешь, после того как победишь проблему :)
Нет, вы все-таки не поняли.
NLB есть. NLB-кластер — это 2 сервера CAS, один — в ДЦ, другой в офисе.
Но через NLB с балансингом как таковым ходят ТОЛЬКО клиенты Outlook.
Но все попадают на CAS через NLB.
Чтобы было понятно — если это внутренний запрос (любой: owa, outlook, activesync), то он ВСЕГДА попадет на NLB (благодаря доменному DNS) и с него на нужный
Если запрос внешний, к примеру ActiveSync — то клиент получит любой из 2х IP-адресов, TMG направит его на ближайший NLB, а NLB по NLB Port Rules Filtering определит что это за трафик, и отправит его по правилу для данного типа:
1) Согласно общему правилу балансировки нагрузки
2) Согласно частному правилу на ближайший CAS.
Нет, вы все-таки не поняли.
NLB есть. NLB-кластер — это 2 сервера CAS, один — в ДЦ, другой в офисе.
Но через NLB с балансингом как таковым ходят ТОЛЬКО клиенты Outlook.
Но все попадают на CAS через NLB.
Чтобы было понятно — если это внутренний запрос (любой: owa, outlook, activesync), то он ВСЕГДА попадет на NLB (благодаря доменному DNS) и с него на нужный
Если запрос внешний, к примеру ActiveSync — то клиент получит любой из 2х IP-адресов, TMG направит его на ближайший NLB, а NLB по NLB Port Rules Filtering определит что это за трафик, и отправит его по правилу для данного типа:
1) Согласно общему правилу балансировки нагрузки
2) Согласно частному правилу на ближайший CAS.
Нет, доменное имя одно — exchange.contoso.com, но оно ссылается на 2 разных IP-адреса, которые возвращаются клиентам по технологии round robin.
Т.к. у меня не было достаточно ресурсов поднимать по 2 CAS-сервера на каждом сайте, каждый autodiscover ссылается на CAS-сервер в своей подсети (офисный — в офисе и т.д.).
Я обспечил НЕ полную отказоустойчивость клиентов ActiveSync, но делать еще 2 CAS-сервера и организовывать 2 кластера из CAS — слишком дорого было бы.
Ну, Forefront в конкретном случае использовался еще до внедрения Exchange в качестве шлюза.
А по поводу SaaS и других сервисов:
У меня было несколько причин, по которым все внедрялось именно в такой схеме:
1. Функциональность. Все таки все то, что так старается быть похожим на Exchange (как в случае с Google Apps Sync) — не Exchange. У Гугла «из коробки» нет даже такого функционала как «расшаривание» контактов и редактирование Global Adress Book. А чтобы это работало — будьте добры купите еще приложение на Marketplace.
Поэтому такие решения (Exchange) в перспективе — дешевле.
2. Безопасность. Это очень важный фактор. Хочется иметь данные на своих (!) серверах со своими (!) паролями и своими (!) бекапами.
3. Соотношение Цена/Необходимость. В той компании где я внедрял данное решение все бизнес-процессы базировались на работе почты. Как быстро она ходит, как стабильно и т.п. Полагаться на «чужие» сервисы, когда из-за простоя в 5-10 минут могут теряться крупные суммы — не вариант.
Я замечу, что даже тут я старался экономить — не делал полную избыточность для внешних клиентов (т.к. от этого бизнес-процессы зависят не так сильно)
И просто добавлю — за последние 3 месяца сервис Google (платный, естественно) ложился 2 раза — на 3 и 1 час соответственно. Это — критично!
Я рассчитывал данную конфигурацию на ~200 пользователей (~250 ящиков) c ростом до 600, но работать она должна будет и с большим количеством. Я не использовал общие папки! (т.к. у меня нет клиентов Outlook 2003)
Главное следить за «толщиной» канала между офисом и ДЦ, чтобы хватало и на работу пользователей, и на репликацию.
Если рассчитывать лицензии, то я опущу необходимые Windows Server, т.к. у всех по-разному (я к примеру использовал виртуализацию на базе VMWare ESX).
Касательно лицензий, связанных непосредственно с Exchange:
Тут все очень просто, сколько видите, столько и считаете — 8 шт Exchange Std No Level. При этом я сделал выбор на Standard, т.к. возможности Enterprise (>5 БД) меня не интересовали. Но тут все зависит от количества пользователей и сайтов.
И по CAL на каждого пользователя (в моем случае 200 шт.). Я использовал UsrCal, т.к. если у 1 пользователя есть ActiveSync устройство и также он работает с Outlook, то 1 UsrCal покроет оба устройства.
По поводу антиспама — использую Forefront for Exchange.
Edge доступен.
По поводу почты от других — действительно, я для себя неправильно перевел стандарт…
А смысл для CAS в ДЦ я пояснил в комментариях повыше.
И как я сделал чтобы НЕ глючило тоже есть в моих ответах выше.
Очень большую роль в этом играет TMG.
К сожалению я был ограничен в ресурсах и не мог идти по другому пути.
Оба узла считают, что они в одной подсети, а TMG когда нужно подменяет адреса (но для работы этого, пришлось отказаться от обычного IpSec, данную проблему мне удалось победить только когда поднял между сайтами L2TP. Так и не разобрался из-за чего это)
NLB я также использовал для того, чтобы отсылать все запросы из внутренней сети к ближайшему CAS (по факту это я для себя и обозвал «VIP»)
И по поводу проблемы с RpcClientAccessServer — тут вы абсолютно правы, я наткнулся на данную проблему. И решил ее следующим образом:
В ActiveDirectory у меня создана OU, в которой находятся пользователи, которые работают ТОЛЬКО локально, и еще 1 OU — пользователи, которые работают еще и снаружи.
Также, в зависимости от того, в какой OU пользователь находится, он еще и помещается в соответствующую группу.
Сразу скажу — авторизация пользователя проходит не на CAS, а на TMG. TMG просто отдает данные вперед на CAS после авторизации.
Итак, в зависимости от того, в какой OU находится пользователь — если Only Local — то ящик создается в базе, которая активна в офисе, если Local and Remote — то ящик создается в базе, которая активна в ДЦ.
TMG же, основываясь на группе, в которой состоит пользователь, отдает запрос на нужный CAS (который прописан для каждой БД).
Ну а в случае сбоя, есть скрипт, который проверяет доступность серверов, и в случае того, если 120 секунд один из серверов недоступен, меняет данные на нужные через:
Set-MailboxDatabase -RPCClientAccessServer <internal_only_CAS_Array_FQDN>
Только сейчас осознаю, что все было не так просто и было много нюансов, о которых просто забываешь, после того как победишь проблему :)
NLB есть. NLB-кластер — это 2 сервера CAS, один — в ДЦ, другой в офисе.
Но через NLB с балансингом как таковым ходят ТОЛЬКО клиенты Outlook.
Но все попадают на CAS через NLB.
Чтобы было понятно — если это внутренний запрос (любой: owa, outlook, activesync), то он ВСЕГДА попадет на NLB (благодаря доменному DNS) и с него на нужный
Если запрос внешний, к примеру ActiveSync — то клиент получит любой из 2х IP-адресов, TMG направит его на ближайший NLB, а NLB по NLB Port Rules Filtering определит что это за трафик, и отправит его по правилу для данного типа:
1) Согласно общему правилу балансировки нагрузки
2) Согласно частному правилу на ближайший CAS.
В итоге запрос все равно приходит от NLB.
NLB есть. NLB-кластер — это 2 сервера CAS, один — в ДЦ, другой в офисе.
Но через NLB с балансингом как таковым ходят ТОЛЬКО клиенты Outlook.
Но все попадают на CAS через NLB.
Чтобы было понятно — если это внутренний запрос (любой: owa, outlook, activesync), то он ВСЕГДА попадет на NLB (благодаря доменному DNS) и с него на нужный
Если запрос внешний, к примеру ActiveSync — то клиент получит любой из 2х IP-адресов, TMG направит его на ближайший NLB, а NLB по NLB Port Rules Filtering определит что это за трафик, и отправит его по правилу для данного типа:
1) Согласно общему правилу балансировки нагрузки
2) Согласно частному правилу на ближайший CAS.
В итоге запрос все равно приходит от NLB.
Т.к. у меня не было достаточно ресурсов поднимать по 2 CAS-сервера на каждом сайте, каждый autodiscover ссылается на CAS-сервер в своей подсети (офисный — в офисе и т.д.).
Я обспечил НЕ полную отказоустойчивость клиентов ActiveSync, но делать еще 2 CAS-сервера и организовывать 2 кластера из CAS — слишком дорого было бы.
Только платить за колокейшн надо 1 раз, а не 2.
А в случае с CAS-массивом у меня не было бы возможности указывать VIP-адреса.
Особенно все то, что касается бизнеса-в-интернете.
А по поводу SaaS и других сервисов:
У меня было несколько причин, по которым все внедрялось именно в такой схеме:
1. Функциональность. Все таки все то, что так старается быть похожим на Exchange (как в случае с Google Apps Sync) — не Exchange. У Гугла «из коробки» нет даже такого функционала как «расшаривание» контактов и редактирование Global Adress Book. А чтобы это работало — будьте добры купите еще приложение на Marketplace.
Поэтому такие решения (Exchange) в перспективе — дешевле.
2. Безопасность. Это очень важный фактор. Хочется иметь данные на своих (!) серверах со своими (!) паролями и своими (!) бекапами.
3. Соотношение Цена/Необходимость. В той компании где я внедрял данное решение все бизнес-процессы базировались на работе почты. Как быстро она ходит, как стабильно и т.п. Полагаться на «чужие» сервисы, когда из-за простоя в 5-10 минут могут теряться крупные суммы — не вариант.
Я замечу, что даже тут я старался экономить — не делал полную избыточность для внешних клиентов (т.к. от этого бизнес-процессы зависят не так сильно)
И просто добавлю — за последние 3 месяца сервис Google (платный, естественно) ложился 2 раза — на 3 и 1 час соответственно. Это — критично!
Главное следить за «толщиной» канала между офисом и ДЦ, чтобы хватало и на работу пользователей, и на репликацию.
Если рассчитывать лицензии, то я опущу необходимые Windows Server, т.к. у всех по-разному (я к примеру использовал виртуализацию на базе VMWare ESX).
Касательно лицензий, связанных непосредственно с Exchange:
Тут все очень просто, сколько видите, столько и считаете — 8 шт Exchange Std No Level. При этом я сделал выбор на Standard, т.к. возможности Enterprise (>5 БД) меня не интересовали. Но тут все зависит от количества пользователей и сайтов.
И по CAL на каждого пользователя (в моем случае 200 шт.). Я использовал UsrCal, т.к. если у 1 пользователя есть ActiveSync устройство и также он работает с Outlook, то 1 UsrCal покроет оба устройства.
По поводу антиспама — использую Forefront for Exchange.