Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
На сколько пользователей вы рассчитали эту конфигурацию? На сколько ящиков? На сколько ориентировочно почты в ящике?
Сколько лицензий и CAL будет нужно?
Будете ли вы использовать антиспам решения? и какие?
Сколько лицензий и CAL будет нужно?
Будете ли вы использовать антиспам решения? и какие?
Я рассчитывал данную конфигурацию на ~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.
Главное следить за «толщиной» канала между офисом и ДЦ, чтобы хватало и на работу пользователей, и на репликацию.
Если рассчитывать лицензии, то я опущу необходимые Windows Server, т.к. у всех по-разному (я к примеру использовал виртуализацию на базе VMWare ESX).
Касательно лицензий, связанных непосредственно с Exchange:
Тут все очень просто, сколько видите, столько и считаете — 8 шт Exchange Std No Level. При этом я сделал выбор на Standard, т.к. возможности Enterprise (>5 БД) меня не интересовали. Но тут все зависит от количества пользователей и сайтов.
И по CAL на каждого пользователя (в моем случае 200 шт.). Я использовал UsrCal, т.к. если у 1 пользователя есть ActiveSync устройство и также он работает с Outlook, то 1 UsrCal покроет оба устройства.
По поводу антиспама — использую Forefront for Exchange.
Разносить роли это конечно красиво и правильно но не дороговато для 200 юзеров + еще Forefront.
Хотя Office 365 тоже удовольствие не дешевое, а для почты Google не рассматриваете 150 руб в мес + не надо оборудование брать. Хотя пока у нас ставят миллион серверов, а лицензируют 1-2 облачным сервисам тягаться тяжело ;-)
Хотя Office 365 тоже удовольствие не дешевое, а для почты Google не рассматриваете 150 руб в мес + не надо оборудование брать. Хотя пока у нас ставят миллион серверов, а лицензируют 1-2 облачным сервисам тягаться тяжело ;-)
Ну, Forefront в конкретном случае использовался еще до внедрения Exchange в качестве шлюза.
А по поводу SaaS и других сервисов:
У меня было несколько причин, по которым все внедрялось именно в такой схеме:
1. Функциональность. Все таки все то, что так старается быть похожим на Exchange (как в случае с Google Apps Sync) — не Exchange. У Гугла «из коробки» нет даже такого функционала как «расшаривание» контактов и редактирование Global Adress Book. А чтобы это работало — будьте добры купите еще приложение на Marketplace.
Поэтому такие решения (Exchange) в перспективе — дешевле.
2. Безопасность. Это очень важный фактор. Хочется иметь данные на своих (!) серверах со своими (!) паролями и своими (!) бекапами.
3. Соотношение Цена/Необходимость. В той компании где я внедрял данное решение все бизнес-процессы базировались на работе почты. Как быстро она ходит, как стабильно и т.п. Полагаться на «чужие» сервисы, когда из-за простоя в 5-10 минут могут теряться крупные суммы — не вариант.
Я замечу, что даже тут я старался экономить — не делал полную избыточность для внешних клиентов (т.к. от этого бизнес-процессы зависят не так сильно)
И просто добавлю — за последние 3 месяца сервис Google (платный, естественно) ложился 2 раза — на 3 и 1 час соответственно. Это — критично!
А по поводу SaaS и других сервисов:
У меня было несколько причин, по которым все внедрялось именно в такой схеме:
1. Функциональность. Все таки все то, что так старается быть похожим на Exchange (как в случае с Google Apps Sync) — не Exchange. У Гугла «из коробки» нет даже такого функционала как «расшаривание» контактов и редактирование Global Adress Book. А чтобы это работало — будьте добры купите еще приложение на Marketplace.
Поэтому такие решения (Exchange) в перспективе — дешевле.
2. Безопасность. Это очень важный фактор. Хочется иметь данные на своих (!) серверах со своими (!) паролями и своими (!) бекапами.
3. Соотношение Цена/Необходимость. В той компании где я внедрял данное решение все бизнес-процессы базировались на работе почты. Как быстро она ходит, как стабильно и т.п. Полагаться на «чужие» сервисы, когда из-за простоя в 5-10 минут могут теряться крупные суммы — не вариант.
Я замечу, что даже тут я старался экономить — не делал полную избыточность для внешних клиентов (т.к. от этого бизнес-процессы зависят не так сильно)
И просто добавлю — за последние 3 месяца сервис Google (платный, естественно) ложился 2 раза — на 3 и 1 час соответственно. Это — критично!
Как ни пытался, но так и не смог найти сферу в которой бизнесс-процессы завязаны и бывают большие потери из-за простоя. Разве что у специализированных типа mail.ru/hotmail/gmail ;-)
Или почта ходит на строго ограниченных получателей по выделенным каналам, а не через интернет? И по ней решаются судьбы мира?
Или почта ходит на строго ограниченных получателей по выделенным каналам, а не через интернет? И по ней решаются судьбы мира?
почта все-таки может не дойти, если интернет пропадет сразу и в датацентре, и в офисе (на двух каналах!) более чем на 30 минутОткуда взялся промежуток в 30 минут?
Это минимальный период, на протяжении которого почтовые сервера продолжат отправлять почту, в случае если с первой попытки ни один из MX серверов не ответил.
Обратимся к первоисточнику — RFC 5321.
The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however...То есть, 30 минут — это рекомендуемый интервал перед повторной попыткой доставить письмо. Однако, эта повторная попытка не единственная:
Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.Если письмо не может быть доставлено прямо сейчас, оно должно находиться в исходящей очереди сервера несколько дней. По истечению этого времени недоставленное письмо должно вернуться отправителю. Прямо как в настоящей «бумажной» почте:
If an SMTP server… finds that… mail cannot be delivered for some other reason, then it MUST construct an «undeliverable mail» notification message and send it to the originator of the undeliverable mail.Таким образом, письма не должны теряться вообще. Они либо задерживаются, либо возвращаются отправителю.
«Напомню, что в Exchange 2010 элементами DAG-массива могут быть не только Mailbox-сервера, поэтому это сильно упрощает работу в сравнении с версией 2007.» — а какие еще сервера могут быть элементами DAG кластера?
«В случае, если в датацентре пропадает интернет/выходит из строя сервер – вся входящая почта приходит на сервер в офисе.»
Ну в этом случае лучше использовать 2 датацентра, где разные провайдеры.
«На данном этапе возникает вопрос: «Но в Outlook у всех же прописан определенный сервер Client Access?! И если он станет offline, то куда будут подключаться клиенты?».
Именно для того, чтобы не допустить такой ситуации используется Network Load Balancing Services (службы балансировки нагрузки на сеть). Я использовал возможности, которые имеются у ОС Windows Server 2008 R2 с ролью Cluster Services, однако Microsoft настоятельно рекомендует использовать «железные» NLB.
В качестве серверов NLB я использовал File Witness сервера для экономии ресурсов.»
Гораздо проще сделать CAS массив для Ваших серверов с ролью Client Access / Hub Transport
«В случае, если в датацентре пропадает интернет/выходит из строя сервер – вся входящая почта приходит на сервер в офисе.»
Ну в этом случае лучше использовать 2 датацентра, где разные провайдеры.
«На данном этапе возникает вопрос: «Но в Outlook у всех же прописан определенный сервер Client Access?! И если он станет offline, то куда будут подключаться клиенты?».
Именно для того, чтобы не допустить такой ситуации используется Network Load Balancing Services (службы балансировки нагрузки на сеть). Я использовал возможности, которые имеются у ОС Windows Server 2008 R2 с ролью Cluster Services, однако Microsoft настоятельно рекомендует использовать «железные» NLB.
В качестве серверов NLB я использовал File Witness сервера для экономии ресурсов.»
Гораздо проще сделать CAS массив для Ваших серверов с ролью Client Access / Hub Transport
Службы Autodiscover активны и там, и там.
Скажите, правильно ли я понял, что фактически в Вашей схеме в конкретный момент времени как снаружи (из Интернет) так и изнутри сети присутствует по 2 активных доменных имени для клиентов Outlook? На сколько я понял, и в датацентре и в офисе присутствует свой CAS Array и каждая из autodiscover записей в каждом сайте ссылается на свой (для нее локальный) NLB кластер из CAS серверов?
Скажите, правильно ли я понял, что фактически в Вашей схеме в конкретный момент времени как снаружи (из Интернет) так и изнутри сети присутствует по 2 активных доменных имени для клиентов Outlook? На сколько я понял, и в датацентре и в офисе присутствует свой CAS Array и каждая из autodiscover записей в каждом сайте ссылается на свой (для нее локальный) NLB кластер из CAS серверов?
Нет, доменное имя одно — exchange.contoso.com, но оно ссылается на 2 разных IP-адреса, которые возвращаются клиентам по технологии round robin.
Т.к. у меня не было достаточно ресурсов поднимать по 2 CAS-сервера на каждом сайте, каждый autodiscover ссылается на CAS-сервер в своей подсети (офисный — в офисе и т.д.).
Я обспечил НЕ полную отказоустойчивость клиентов ActiveSync, но делать еще 2 CAS-сервера и организовывать 2 кластера из CAS — слишком дорого было бы.
Т.к. у меня не было достаточно ресурсов поднимать по 2 CAS-сервера на каждом сайте, каждый autodiscover ссылается на CAS-сервер в своей подсети (офисный — в офисе и т.д.).
Я обспечил НЕ полную отказоустойчивость клиентов ActiveSync, но делать еще 2 CAS-сервера и организовывать 2 кластера из CAS — слишком дорого было бы.
Ага, теперь понял, т.е. NLB просто описан был для примера, но конкретная реализация была без него.
А у Вас эта схема работает вообще? Я имею в виду именно так, как Вы описали. Спрашиваю потому, что делал нечто подобное несколько раз по очень хорошему описанию отказо и катастрофоустойчивости Exchange 2010. Дело в том, что для любой почтовой базы (будь она в DAG группе или нет) существует атрибут RpcClientAccessServer:
Here is how things work in regards to CAS arrays. An Exchange 2010 mailbox database has an attribute called RpcClientAccessServer. When creating a new mailbox database in an Active Directory site where a CAS array has not been created, this attribute will be set to the first CAS server installed in the AD site.
который в конкретный момент времени может содержать только одно значение. Это значит, что для любой почтовой базы может быть только один CAS сервер (или array из CAS серверов). Если этот CAS сервер (или array) по каким-то причинам становится недоступным, то это свойство для базы необходимо менять руками командой.
Это я к тому, что вот, допустим, клиенту на очередной DNS запрос (допустим, внешний) отдался по Round Robin IP адрес сайта, в котором находится CAS сервер не от его почтовой базы. В этом случае он подключиться не сможет ни Outlook-ом ни OWA. Таких проблем у Вас не было?
А у Вас эта схема работает вообще? Я имею в виду именно так, как Вы описали. Спрашиваю потому, что делал нечто подобное несколько раз по очень хорошему описанию отказо и катастрофоустойчивости Exchange 2010. Дело в том, что для любой почтовой базы (будь она в DAG группе или нет) существует атрибут RpcClientAccessServer:
Here is how things work in regards to CAS arrays. An Exchange 2010 mailbox database has an attribute called RpcClientAccessServer. When creating a new mailbox database in an Active Directory site where a CAS array has not been created, this attribute will be set to the first CAS server installed in the AD site.
который в конкретный момент времени может содержать только одно значение. Это значит, что для любой почтовой базы может быть только один CAS сервер (или array из CAS серверов). Если этот CAS сервер (или array) по каким-то причинам становится недоступным, то это свойство для базы необходимо менять руками командой.
Это я к тому, что вот, допустим, клиенту на очередной DNS запрос (допустим, внешний) отдался по Round Robin IP адрес сайта, в котором находится CAS сервер не от его почтовой базы. В этом случае он подключиться не сможет ни Outlook-ом ни OWA. Таких проблем у Вас не было?
Нет, вы все-таки не поняли.
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.
Так, кажется начинаю понимать. Наверное, меня смутила фраза «NLB сервер». Видимо, в этом контексте я ожидал увидеть слово «узел» или «нода».
То есть, у Вас растянутый NLB кластер, один из узлов которого в офисе, второй — в ДЦ? Раз офис и ДЦ соединены VPN-ом, это разные IP подсети, а не растянутый VLAN. NLB с узлами в разных подсетях? Раньше думал, что такое невозможно. Фича windows server 2008 R2?
То есть, фактически NLB Вы использовали только для возможности использования Port Rules Filtering? Сам VIP Вы нигде не привязывали в DNS к сервисам Exchange — только отдельные CAS серверы?
Далее, Вы написали, что CAS массива у Вас нет, таким образом, должно быть 2 независимых CAS сервера и описанная мною проблема с RpcClientAccessServer должна иметь место. Скажу сразу, я не нападаю и не хочу развязать очередной срач в камментах, просто самому очень интересно. Видимо, я чего-то не понимаю. Было бы здорово понять до конца :)
То есть, у Вас растянутый NLB кластер, один из узлов которого в офисе, второй — в ДЦ? Раз офис и ДЦ соединены VPN-ом, это разные IP подсети, а не растянутый VLAN. NLB с узлами в разных подсетях? Раньше думал, что такое невозможно. Фича windows server 2008 R2?
То есть, фактически NLB Вы использовали только для возможности использования Port Rules Filtering? Сам VIP Вы нигде не привязывали в DNS к сервисам Exchange — только отдельные CAS серверы?
Далее, Вы написали, что CAS массива у Вас нет, таким образом, должно быть 2 независимых CAS сервера и описанная мною проблема с RpcClientAccessServer должна иметь место. Скажу сразу, я не нападаю и не хочу развязать очередной срач в камментах, просто самому очень интересно. Видимо, я чего-то не понимаю. Было бы здорово понять до конца :)
По поводу растянутого 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 секунд один из серверов недоступен, меняет данные на нужные через:
Оба узла считают, что они в одной подсети, а 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>
Только сейчас осознаю, что все было не так просто и было много нюансов, о которых просто забываешь, после того как победишь проблему :)Оказывается как много интересных вещей было реализовано, которые при этом не были отражены в статье.
На мой взгляд, Ваше решение с раскидыванием по CAS серверам в разных сайтах в зависимости от принадлежности пользователя группе безопасности и растянутым на 2 сайта NLB кластером куда более интересные детали, чем те общие слова про DAG, которые можно прочитать без исключения в любой статье по отказоустойчивости Exchange 2010.
Мне кажется, если бы Вы все эти детали включили в статью с подробным рисунком, она была бы на порядок интереснее. А то комментарии какие-то вялые надо сказать, а меж тем решение нестандартное, интересное и определенно заслуживает внимания.
На мой взгляд, Ваше решение с раскидыванием по CAS серверам в разных сайтах в зависимости от принадлежности пользователя группе безопасности и растянутым на 2 сайта NLB кластером куда более интересные детали, чем те общие слова про DAG, которые можно прочитать без исключения в любой статье по отказоустойчивости Exchange 2010.
Мне кажется, если бы Вы все эти детали включили в статью с подробным рисунком, она была бы на порядок интереснее. А то комментарии какие-то вялые надо сказать, а меж тем решение нестандартное, интересное и определенно заслуживает внимания.
Нет, вы все-таки не поняли.
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.
DNS RR используют для балансировки, не для отказоустойчивости. Будет глючить.
Будет не глючить, а при отказе будет НЕ работать у части клиентов.
К сожалению я был ограничен в ресурсах и не мог идти по другому пути.
К сожалению я был ограничен в ресурсах и не мог идти по другому пути.
Решение Heartbeat. NLB это балансировка. Будет именно глючить, т.к. Поведение системы рассчитать невозможно. На одном компе будет то работать то нет.
Почта от других, если не доступен ваш mx, будет пытаться доставиться к вам несколько дней, примерно каждые полчаса-час.
Edge у вас перед файрволом?
Какой смысл в cas в датацентре вообще не ясно. При отсутствии канала он не спасет, при падении cas в офисе запасной лучше держать в офисе.
Вы тестировали систему свою?
Почта от других, если не доступен ваш mx, будет пытаться доставиться к вам несколько дней, примерно каждые полчаса-час.
Edge у вас перед файрволом?
Какой смысл в cas в датацентре вообще не ясно. При отсутствии канала он не спасет, при падении cas в офисе запасной лучше держать в офисе.
Вы тестировали систему свою?
Для минималистов:
Минимальное решение с HA — 2 сервера со всеми ролями DAG и CAS array, NLB идет железкой или снаружи.
Минимальное решение с Failover — одна vm со всеми ролями внутри vm-кластера.
На 200 человек приведенное решение на 8 серверов отдает нефтяным бизнесом)
Edge роль полностью решается HT с исправлением прав на receive connector и forefront на нее садится так же хорошо.
Минимальное решение с HA — 2 сервера со всеми ролями DAG и CAS array, NLB идет железкой или снаружи.
Минимальное решение с Failover — одна vm со всеми ролями внутри vm-кластера.
На 200 человек приведенное решение на 8 серверов отдает нефтяным бизнесом)
Edge роль полностью решается HT с исправлением прав на receive connector и forefront на нее садится так же хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение отказоустойчивых систем на базе Exchange 2010