none
Отказоустойчивость Exchange Server 2013 SP1 RRS feed

  • Вопрос

  • Здравствуйте, коллеги!

    Планирую к развертыванию в организации Exchange Server 2013. До сих пор мой опыт с Exchange касался только Standalone-редакций, когда один сервер несет в себе все роли, и самая последняя редакция, с которой я работал, была MS Exchange 2007.

    Однако, в настоящее время меня попросили развернуть отказоустойчивую конфигурацию таким образом, чтобы при сбоях интернета в офисе почта куда-нибудь принималась, а не отбрасывалась. Соответственно, работа электронной почты критически важна для работы организации.

    Прошу совета, как поступить. Мне мыслится разместить один сервер на колокейшене у провайдера, и некие сервера в офисе.

    Соответственно, как я понимаю текущую ситуацию, мне нужно поставить Edge Transport на хостинге, еще один Edge Transport в организации, и с него кластер из двух серверов с ролями CAS и MB. Но я не уверен, что это схема экономна и правильна. Наверняка кто-нибудь сталкивался с подобными задачами, подскажите, пожалуйста, как их обычно решают?

    15 июля 2014 г. 8:02

Ответы

  • День добрый.

    Рекомендую начать от сюда.

    High availability and site resilience

    Примеры с 3 сайтами и DC.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.


    15 июля 2014 г. 8:19
    Модератор
  • Олег привел топологию довольно таки сложной организации. Так сказать, общий случай. Вам же, насколько я понимаю, нужна схема попроще. Одна организация - один сайт AD и отказоустойчивость ПС. Что касается отказоустойчивости серверного ядра Exchange 2013, то минимум что необходимо - два сервера с объединенными ролями, обязательно DAG и желательна балансировка клиентских подключений вынесенная в отдельное решение (как показала практика, поддерживаемый метод балансировки DNS Round Robin) не всегда отвечает требованиям к отказоустойчивости в части времени восстановления сервиса). Далее. Поток почты. При наличии одного канала интернет отказоустойчивости добиться сложно без задействования внешних серверов пересылки (SMTP Relay). Но если поднять второй канал (от другого провайдера), то можно разместить в DMZ второй Edge (соответственно у него будет другой IP) и настроить MX запись для второго сервера с большим приоритетом. Соответственно, при падении основного канала, почта пойдет на второй Edge. Думается, это решение выгоднее и безопаснее, нежели размещение транспортных серверов вне вашей организации. Кстати, не обязательно использовать именно Exchange Edge, можно применять решения и других вендоров, например Cisco Iron Port.

    Do not multiply entities beyond what is necessary

    • Помечено в качестве ответа Lizard_tula 15 июля 2014 г. 9:07
    15 июля 2014 г. 8:46

Все ответы

  • День добрый.

    Рекомендую начать от сюда.

    High availability and site resilience

    Примеры с 3 сайтами и DC.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.


    15 июля 2014 г. 8:19
    Модератор
  • Спасибо!

    Вторая схема вроде бы ближе к моей ситуации. А не подскажите - это из какой-то публичной документации в интернете схема? Интересно было бы почитать описание.

    На приведенной схеме в Datacenter 2 используется только Edge Transport - у меня как раз такой случай, в принципе, оптимален. Если с отправкой все понятно, Edge transport при недоступности интернета просто сложит письма у себя и будет ждать, пока интернет не появится, то что будет происходить при получении письма и недоступности офиса? Edge Transport сложит их у себя и будет ждать, пока не поднимется канал, чтобы перекинуть письма в MBX?

    15 июля 2014 г. 8:45
  • Олег привел топологию довольно таки сложной организации. Так сказать, общий случай. Вам же, насколько я понимаю, нужна схема попроще. Одна организация - один сайт AD и отказоустойчивость ПС. Что касается отказоустойчивости серверного ядра Exchange 2013, то минимум что необходимо - два сервера с объединенными ролями, обязательно DAG и желательна балансировка клиентских подключений вынесенная в отдельное решение (как показала практика, поддерживаемый метод балансировки DNS Round Robin) не всегда отвечает требованиям к отказоустойчивости в части времени восстановления сервиса). Далее. Поток почты. При наличии одного канала интернет отказоустойчивости добиться сложно без задействования внешних серверов пересылки (SMTP Relay). Но если поднять второй канал (от другого провайдера), то можно разместить в DMZ второй Edge (соответственно у него будет другой IP) и настроить MX запись для второго сервера с большим приоритетом. Соответственно, при падении основного канала, почта пойдет на второй Edge. Думается, это решение выгоднее и безопаснее, нежели размещение транспортных серверов вне вашей организации. Кстати, не обязательно использовать именно Exchange Edge, можно применять решения и других вендоров, например Cisco Iron Port.

    Do not multiply entities beyond what is necessary

    • Помечено в качестве ответа Lizard_tula 15 июля 2014 г. 9:07
    15 июля 2014 г. 8:46
  • У нас как раз два провайдера в офисе, оба с белыми адресами, режим active/passive. Переключение будет осуществляться циской аса, которую планируем приобрести (для надежности, сейчас програмнный брэндмауэр используется). Да, одна организация, один сайт, пока что даже один контроллер домена (но будет два).

    В офисе можно поднять, как мне кажется, один Edge transport и сделать на него две MX-записи с разными IP и с соответствующими приоритетами (на основной канал приоритет выше, на запасной - ниже).

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


    • Изменено Lizard_tula 15 июля 2014 г. 8:57
    15 июля 2014 г. 8:54
  • Это часть схем созданых мной, примеры схем из прошлых проектов или сложных технологических запросов по траблешутингу. Для разработки архитектуры и анализа требуется достаточно много информации, а также проведения архитектурных сессий для выработки решения под ваши запросы. 

    Просто вы затронули одну из самых сложных тем Exchange: Обеспечени высокой доступности почтовой организации Exchange.

    По этому я и привел примеры вариантов решения. Схемы существуют или были реализованы.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    15 июля 2014 г. 9:00
    Модератор
  • Понял. Спасибо большое!
    15 июля 2014 г. 9:01