Web Application Proxy (часть 3)

Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 3)

В предыдущих статьях цикла о Web Application Proxy мы рассмотрели базовые понятия касаемо данной технологии и приступили к первому шагу ее практической реализации – развертывание служб федерации Active Directory. Это нам позволит сей час приступить к конфигурации Web Application Proxy.

Что необходимо будет сделать:

• Произвести подготовку сервера для развертывания 
• Импортировать SSL сертификата для Web Application Proxy 
• Выполнить развертывание WAP и проверить конфигурацию. 
• Подвести итоги

Подготовка сервера под развертывание:

В качестве сервера была выбрана виртуальная машина SRV-WAP Характеристики следующие:

• ОС: Server 2012 R2 Standard 
• 2 виртуальными процессора 
• 2 ГБ ОЗУ 
• Сетевые интерфейсы, DMZ: 192.168.1.5 /24 и LAN 172.16.20.4 /24 \

Размещение сервера на обобщенной топологии демо-стенда:

Web Application Proxy (часть 2)

Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 2)

Ранее мы познакомились с основным функционалом данной технологии. Сей час же перенесемся в сугубо практическую плоскость и произведем первый подготовительный шаг к публикации Exchange – установку роли Active Directory Federation Services (ADFS)

Что необходимо будет сделать:

1. Подготовить сервер для развертывание роли 
2. Определить требования к публикации 
3. Произвести развертывание службы ADFS 
4. Конфигурация службы ADFS 
5. Выводы

Подготовка сервера под ADFS

Службы федерации будут размещается на виртуальной машине SRV-ADFS которая является членом домена office365.local. Характеристики виртуальной машины:

• ОС: Server 2012 R2 Standard c 2-я виртуальными процессорами и 2-я ГБ ОЗУ 
• IP адрес сервера: 172.16.20.14 /24

Web Application Proxy (часть 1)

Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 1)

Операционная система Windows Server 2012 R2 предоставила в руки системных администраторов интересные изменения и дополнения к существовавшим ранее возможностям. Этим сообщением в своем блоге я открываю цикл из 5 статьей, которые ознакомят читателей с некоторыми из нововведений. Сегодняшняя речь пойдет о Web Application Proxy.

Web Application Proxy (далее просто WAP) используется как средство публикации внутрикорпоративных приложений, таких как Exchange, Lync и др. для внешних клиентов. Технология основывается на «реверс-проксировании» краткие сведения о котором будут изложены далее.

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

В результате тестирования на лабораторном стенде была успешно проделана публикация приложений OWA, ECP, PowerShell, OAB, RPC, EWS, Autodiscover, ActiveSync Отображение всего процесса будет показано в последующих статьях.

Содержание

• Немного теории
• Обзор Web Application Proxy
• Требования к развертыванию Web Application Proxy
• Описание лабораторного стенда

Немного теории

Web Application Proxy (WAP) – это reverse proxy server (сервер обратного проксирования). Если кратко, суть сводится к следующему:

Установка обновления для Exchange 2013

Exchange не стоит на месте. Команда Exchange постоянно разрабатывает новый функционал и исправляет найденные ошибки. В Exchange 2013 разработчики перешли на следующую схему выпуска и поддержки обновлений: обновления (Cumulative Update, CU) выходят каждый квартал и поддерживаются только текущее и предыдущее обновления (Servicing Exchange 2013).

В этом руководстве будет рассмотрен процесс установки CU для Exchange 2013.

Устанавливая обновление для Exchange 2013, необходимо помнить следующие моменты:

• Любое обновление для Exchange 2013 представляет собой полный дистрибутив Exchange 2013 

• Любое обновление Exchange 2013 требует подготовки Active Directory, в том числе и расширение схемы 
• Обновлять Exchange 2013 можно с любой версии на любую версию. Устанавливать какие-либо промежуточные обновления не нужно. Например, чтобы обновиться с Exchange 2013 SP1 до Exchange 2013 CU7 можно использовать сразу обновление CU7. Устанавливать CU5 и CU6 не нужно 
• Любое обновление для Exchang 2013 перезаписывает конфигурационные файлы и файлы web.config IIS: если вы вносили изменения в файлы web.config, например для интеграции с Lync, то необходимо заранее сохранить эти конфигурационные файлы. После установки обновления необходимо будет заново внести требуемые изменения в файлы web.config, но ни в коем случае не заменяйте эти файлы сохраненными ранее – могут быть проблемы 
• Перед установкой обновления у вас должен быть свежий бекап Active Directory 
• Перед установкой обновления у вас должен быть свежий бекап Exchange 2013 
• Если роли MBX и CAS установлены на разных серверах, то в первую очередь необходимо устанавливать обновление на сервер с ролью MBX 
• Установленное обновление нельзя удалить, чтобы вернуться к ранее установленному 

Если у вас всего один сервер в организации, один лес и один домен, то проще всего использовать стандартный мастер установки Exchange 2013, чтобы произвести обновление. Если же у вас сложная архитектура Exchange 2013, то для того, чтобы снизить время простоя сервиса, обновление необходимо выполнять этапами.

Чистим логи Exchange 2013

Перемещаем и чистим логи Exchange 2013

При внедрении Exchange возникает неприятная ситуация – мы вроде бы все требования по месту для Exchange выполнили, но оно неумолимо уменьшается… начинаем разбираться и понимаем что всевозможные логи растут быстрее чем мы предполагали, так как же с ними бороться? Далее описаны способы по усечению\перемещению различных логов, в общем все то, что поможет нам решить проблему. Отдельно замечу, что вся информация есть в технической библиотеке technet :) и здесь она всего лишь подобрана для определенной задачи: напомнить способы решения проблем с нехваткой места по причине разрастания логов.
 

Transaction logs

Журнал транзакций наиважнейший элемент Exchange. Приведем пример: при отправке сообщения транзакция сначала записывается в журнал. Пока транзакция не передалась в базу данных Exchange, эти данные существуют только в системной памяти и журналах транзакций. В случае аварии вы теряете содержимое памяти, и все, что у вас остается, это записи в журнале транзакций. Эти журналы важны для восстановления поврежденной базы. То же самое касается и других транзакций: полученных сообщений, удаленных элементов и сообщений, перемещенных в другие папки. Соответственно данные логи растут очень быстро, как же их уменьшить?

NLB в Windows Server 2012

Настройка NLB в Windows Server 2012

Компонент балансировки сетевой нагрузки  (Network Load Balancing, NLB) в Windows Server 2012 распределяет сетевой трафик по нескольким серверам с помощью протокола TCP/IP. Группируя два и более сервера в единый виртуальный кластер, NLB повышает доступность и масштабируемость серверных приложений.

NLB умеет выполнять балансировку нагрузки любых приложений и служб, использующих сетевой протокол TCP/IP и связанных с определенным TCP- или UDP-портом. Использовать балансировку сетевой нагрузки целесообразно для обеспечения работы приложений, выполняемых без учета состояния, например для веб-, FTP- или служб удаленных рабочих столов (Remote Desktop).

Также NLB может пригодиться и в менее очевидных ситуациях. К примеру, с помощью этого механизма можно обеспечить повышенную избыточность веб-серверов front-end на базе SharePoint 2010, а при использовании Exchange 2010 выравнивание сетевой нагрузки можно применять в целях создания CAS-массивов для роли сервера клиентского доступа (Client Access Server).

Создание и настройка DAG в Exchange 2013

Создание и настройка DAG в Exchange 2013

DAG (Database Availability Group) – позволяет обеспечить отказоустойчивость Баз Данных почтовых ящиков. Суть его работы заключается в том, что создаются копии базы и при выходе из строя одного сервера база автоматически активируется на другом.

Впервые DAG появился в Exchange 2010, а в Exchange 2013 он получил некоторые улучшения.

Итак, рассмотрим схему нашей инфраструктуры. Она очень простая.