Меню

application request routing iis настройка

Пошаговая инструкция по настройке публикации почтовых серверов Exchange Server 2013/2016 с помощью IIS ARR

Приветствую всех читателей нашего Блога! Сегодня я расскажу вам о том, как за несколько минут настроить публикацию почтового сервера Exchange Server 2013/2016 с помощью IIS ARR (Application Request Routing). Но для начала немного о том, что такое публикация и для чего она нужна.

Основная задача публикации это защита сервера от внешнего негативного воздействия. Сервер публикации Reverse Proxy (RP), располагается в сети периметра (DMZ) и передает (проксирует) запросы на почтовые сервера, в том случае, если запросы соответствуют определенным шаблонам. Логика работы RP на основе компонента ARR следующая: если поступает запрос с именем узла mail.contoso.com по протоколу HTTPS, тогда перенаправить запрос на ферму серверов mail.contoso.com . Все просто и понятно. Веб сервер используется по той простой причине, что в Exchange 2013/2016 ВСЕ подключения (кроме POP и IMAP конечно!) идут через HTTPS и неважно что вы используете, браузер или толстый клиент Outlook.

Некоторые особенности RP серверов на основе IIS ARR:

  1. Сервер RP может не быть членом домена.
  2. Сервер должен иметь доступ к внутренней сети организации (конкретно к почтовым серверам) и внешней сети Интернет. Один из вариантов реализации это два сетевых адаптера.
  3. RP должен разрешать FQDN (полное доменное имя ex1-srv.contoso.com , ex2-srv.contoso.com и т.д.) почтового сервера в его IP адрес. Если в сети периметра не используется DNS сервер, необходимо прописать имена серверов и IP в файле C:\Windows\System32\Drivers\etc\hosts .
  4. Убедитесь, что вы правильно настроили внутренние и внешние URL для виртуальных каталогов на почтовом сервере и правильно сконфигурировали сервера. Прежде чем приступать к публикации, проверьте, что все отлично функционирует в пределах локальной сети.
  5. DNS-суффикс сервера RP (в том случае, если он не включен в домен) нужно настроить вручную так, чтобы он был идентичен доменному (RP. contoso.com ).
  6. Убедитесь, что виртуальные каталоги (OWA, ECP, EWS и т.д.) опубликованы для внешних подключений с пространством имен mail.contoso.com

1) Запустить PowerShell с привилегиями Администратора и выполнить

Проверим что все получилось, введя в браузере сервера RP http://127.0.0.1

2) Устанавливаем Microsoft Web Platform Installer . В поиске Microsoft Web Platform Installer набираем ARR и устанавливаем пакет Application Request Routing 3.0 + дополнительные компоненты предложенные установщиком.

3) Экспортируем сертификат с CAS сервера и импортируем на сервер RP. Необходимо привязать этот сертификат для Default Web Site

4) Переходим в Server Farms и создаем новую ферму серверов. Назовем ее Contoso.com

Читайте также:  acpi compliant при установке винды

Добавим сервера в ферму (Если роли разнесены, то добавляем только CAS сервера). Вводим FQDN сервера и нажимаем ADD

Нажимаем Finish, затем YES на предложение создать правила.

5) Необходимо настроить ферму, в которую мы добавили наши почтовые сервера. Открываем ферму contoso.com и переходим в раздел Caching. Убираем чекбокс Enable Disk Cache и нажимаем Apply

Переходим в раздел Health Test. В качестве URL для проверки доступности серверов я укажу:

URL для проверки доступности имеет вид https:// /

/HealthCheck.htm это URL по умолчания для Exchange Server 2013/2016. Для каждого протокола существует свой URL и его нет необходимости настраивать дополнительно, это все часть компонента Managed Availability. Можно указать другие URL для соответствующих протоколов:

  • https://mail.contoso.com/EWS/HealthCheck.htm
  • https://mail.contoso.com/OAB/HealthCheck.htm
  • https://mail.contoso.com/OWA/HealthCheck.htm

Настройки для раздела Health Test (после внесения изменений, не забываем нажимать Apply)

После внесения всех настроек нужно проверить, что все работает. Нажмем Verify URL Test и убедимся, что все серверы прошли проверку, ответив Pass. Если сервер не будет доступен, то на него не будут пересылаться запросы от внешних клиентов. Компонент ARR выведет его из балансировки до тех пор, пока снова не “увидит” сервер клиентского доступа.

Переходим к разделу Proxy, выставляем настройки:

  • Time-Out: 200 seconds
  • Response Buffer threshold: 0

не забываем нажимать Apply после внесения изменений.

Переходим в раздел Routing Rules и убираем чекбокс Enable SSL Offloading

Load Balance, Monitoring and Management и Server Affinity не трогаем.

6) Переходим к созданию правил перенаправления запросов.

В оснастке IIS открываем URL Rewrite

Создаем правило для Autodiscover

Для добавления шаблона во вкладке “Conditions” нажать “Add” и ввести параметры:

Аналогично ввести ON”

В самом низу выбираем действие, которое необходимо выполнить, если запрос соответствует шаблону. В нашем случае, это перенаправление на ферму серверов (не забывайте выбрать https) и чекбокс запрещающий выполнение следующих (нижних) правил.

Аналогичным образом создаем правило для mail.contoso.com и, ели есть желание, для activesync.contoso.com .

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

Последний штрих. Перейдите в “Request Filtering”

и задайте значение 2147483648 для параметра “Maximum allowed content lenght”.

Всё готово! Теперь необходимо настроить внешние DNS сервера, для разрешения имен Autodiscover и mail (а если настраивали, то и activesync) в IP IIS ARR.

По просьбам трудящихся закрываем ECP

Читайте также:  наушники от dr dre настройка

источник

Ферма IIS и Application Request Routing

Совсем недавно мои коллеги написали несколько статей про shared-хостинг на базе Cloud Linux, а сегодня я расскажу вам про технологии Microsoft которые мы используем для услуги Windows-хостинга. Речь пойдет про связку IIS 8.5 и Application Request Routing (ARR).

ARR — это расширение для IIS которое позволяет собирать множество серверов IIS в единую ферму. Оно позволяет производить балансировку нагрузки HTTP-трафика, использовать правила маршрутизации и может выступать в роли кэширующего Reverse Proxy-сервера для разгрузки основных серверов предоставления контента.
ARR может распределять трафик различными способами:

  • Weighted round robin – самый простой тип балансировки. Запросы будут распределяться между всеми серверами по очереди.
  • Weighted total traffic – запросы будут распределяться на основе их размеров, и перенаправляться на менее загруженные узлы.
  • Least response time – запрос будет отправлен на любой откликнувшийся раньше всех сервер.
  • Sticky sessions – в этом режиме все запросы клиента в рамках сессии будут передаваться на один и тот же сервер.

Еще очень важной фичей является возможность использовать правила фильтрации URL. С помощью регулярных выражений можно перенаправлять запросы HTTP и HTTPS по отдельности на разные фермы IIS.
Внутри фермы постоянно происходит проверка «пульса» всех узлов. В случае если узел «умер», ARR перестанет направлять на него запросы.
Проверка узлов производиться двумя способами:

  • Проверка доступности сайта, расположенного в ферме, обычным GET-запросом. Опрос происходит по заранее определенному интервалу. Обычно для этого используется заранее развернутый сайт с техническим именем.
  • Мониторинг живого трафика к сайтам.

Разница между ними лишь в том, что в режиме мониторинга ARR не будет прекращать запросы на узлы фермы в случае выхода их из строя. А лишь делать пометку для администратора, давая таким образом возможность ручного управления. А уже при включенном опросе URL, в случае недоступности узла, он будет переведен в паузу.
ARR можно использовать не только для веб-хостинга, но и для балансировки нагрузки на другие сервисы, которые работают по протоколу HTTP. Пример тому, публикация Exchange OWA (Outlook Web Access), отлично подходит для организации доступа к почте для большого количества клиентов.
Начиная с Windows Server 2012 появилась возможность хранить все SSL-сертификаты в одном, доступном для всех узлов месте. Это значительно упрощает эксплуатацию всей фермы т.к. теперь не приходиться тратить кучу времени на установку и управление сертификатами.

Как это работает у нас?

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

Читайте также:  hp 1920 настройка ntp

Сейчас я расскажу вам, про минимальную отказоустойчивую конфигурацию которая используется в основе нашего shared-хостинга.

Все компоненты фермы размещены в облачной инфраструктуре, что уже на уровне оборудования сводит возможность отказа к минимуму. Одним из самых важных компонентов является хранение данных т.к. распределение нагрузки теряет всякий смысл если пользовательский контент будет недоступен, поврежден или что еще хуже безвозвратно утрачен. Для решения этой задачи, данные размещены на кластеризованном файловом хранилище.
Кроме сайтов клиентов на нем еще хранятся:

  • Общие конфигурационные файлы серверов IIS и ARR. Это является одним из условий работы фермы.
  • Общее хранилище SSL-сертификатов. С IIS 8.0 больше нет необходимости производить установку клиентских сертификатов на каждом узле ферм, как это было в предыдущих версиях.

В итоге получается, что вся конфигурация и пользовательские данные не хранятся на самих веб-серверах. Это значительно упрощает настройку серверов, хранение и резервное копирование данных. Ферма веб-серверов и балансировщиков нагрузки, может быть горизонтально масштабирована новыми узлами. Для доступа клиентов к своему контенту, организован отдельный хост, который выступает в роли FTP-сервера и сервиса Web Deploy. На нашем shared-хостинге одинаково комфортно чувствуют себя сайты, написанные на PHP и ASP.NET.

Хостингом наши клиенты управляют через личный кабинет. Все задачи, которые пользователь отправляет на выполнение ставятся в очередь и за дело берется оркестратор. Он-то и управляет всеми услугами Windows-хостинга с помощью PowerShell-сценариев.

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

На сегодня все, в следующей статье я постараюсь подробно описать как заставить все это жить в гармонии и бесперебойно выполнять свои обязанности.

источник

Добавить комментарий

Adblock
detector