Главная Security, Без рубрики, Новое Exchange 2010, Forefront Security for Exchange, TMG, Конкурс, спам
  • Защита сервера Exchange от спама и вирусов

    image Согласно последним статистическим данным, доля спама в почтовом трафике Рунета составляет 85 процентов. Спам остается серьезной интернет-­угрозой, ущерб от которой из­меряется далеко не только потраченным трафиком. И не столько им. При стремящейся к нулю стоимости трафика ущерб российских пользователей и провайдеров, по некоторым оценкам, составляет 50 млн долларов в год, но это лишь прямой ущерб. Гораздо больше — косвен­ный. Со спамом все чаще распространяются вредоносные вложения (0,5–1% всего трафика), фишинговые письма (около 1%). В результате, компании теряют не только драгоценное время сотрудников, они рискуют быть зараженными вредоносным ПО и могут, сами того не подозревая, раскрыть конфиденциальные данные в результате фишинг-атак.

  • Главная Exchange/UC, Без рубрики, Новое ECP, Exchange 2010, Exchange Control Panel, Конкурс
    • Exchange Control Panel – средство управления для пользователя и администратора

      UserFriendlyНаверняка каждый администратор мечтал облегчить свой труд, переложив часть задач на конечных пользователе. С приходом Exchange 2010 эта мечта становится ближе. В Exchange 2010 появилась обновленная консоль управления сервером – Exchange Control Panel (ECP). ECP является самостоятельным веб-сервисом и доступна либо из Outlook Web App, либо по адресу https://yourCAS/ecp. Данная консоль предназначена как для администраторов Exchange, так и для конечных пользователей, причем уровень доступа пользователей к серверу Exchange по средствам ECP легко настраивается при помощи новой системы управления ролями – Role Based Authentication Control (RBAC) (подробнее про RBAC тут и тут).

    • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
      • Интернет почта через Edge Transport в Exchange 2010

        transport Недавно обнаружил, что в сети нет достаточно подробных инструкций по настройке сервера Exchange 2010 на работу с внешней почтой. В данной статье я постараюсь как можно более подробно и доступно описать процесс настройки Exchange Server 2010 для работы с внешней электронной почтой через Edge Transport Server.

        Для того чтобы сделать действительно полный Step-by-Step Guide, давайте рассмотрим процесс настройки внешней почты с самого начала. Как правило, данный процесс состоит из трех основных этапов:

        1. Регистрация доменного имени предприятия;
        2. Настройка MX записи на DNS сервере, обслуживающем доменное имя;
        3. Настройка Exchange сервера на работу с внешним доменом.

        На первом пункте мы останавливаться не будем, т.к. у подавляющего большинства компаний уже есть свое доменное имя в сети Интернет, а те, у кого ещё нет, могут легко его купить у любого регистратора (например, RU-CENTER www.nic.ru). Зарегистрировав доменное имя, вам нужно будет найти и прописать в настройках домена, по крайней мере, два DNS сервера, которые будут его обслуживать, это также можно сделать у регистратора, либо воспользоваться бесплатными DNS-серверами (например, http://freedns.ws/ru/).

        Первый этап пройден, теперь у провайдера нужно получить статический IP-адрес для своей организации и можно переходить ко второму этапу – настройке MX-записи на DNS сервере, обслуживающем внешний домен. Запись типа MX (Mail Exchange – почтовый сервер) определяет почтовый сервер, который будет обрабатывать почту для вашего домена.

        Редактируем зону на DNS сервере следующим образом:

        1. Регистрируем А-запись, например mail.firma.ru и указываем для неё внешний IP-адрес, на котором опубликован сервер Exchange;
        2. Регистрируем MX-запись и указываем для неё имя хоста – mail.firma.ru.

        Примечание: Если вы только что создали зону для вашего домена, то не думайте, что ping firma.ru будет сразу указывать на нужный IP, может потребовать довольно продолжительное время для того, чтобы все DNS сервера Интернета «узнали» о внесенных изменениях.

        Чтобы проверить правильность сделанных настроек нужно воспользоваться командой nslookup следующим образом:

        1. Проверяем MX-запись домена (к примеру, mail.ru):

        nslookup -type=mx mail.ru

        В результате, мы узнали, что почта на mail.ru ходит через хост mxs.mail.ru.

        1. Проверяем IP-адрес хоста mxs.mail.ru:

        nslookup mxs.mail.ru 8.8.8.8

        Примечание: В данном примере мы проверяем, что «знает» о хосте mxs.mail.ru не наш локальный DNS-сервер, а DNS сервере Google`a (8.8.8.8).

        Рис.1: Проверка MX-записи.

        Если все настроено правильно и MX-запись вашего домена резолвится во внешний IP-адрес вашего сервера, то можно приступать непосредственно к настройке Exchange`a.

        Публикация сервера Exchange.

        Есть два варианта публикации сервера Exchange в сети Интернет:

        1. Сервер с ролью Hub Transport находится в локальной сети предприятия и публикуется в Интернет через корпоративный Интернет шлюз;
        2. На шлюзе публикуется сервер с ролью Edge Transport, который располагается в DMZ-зоне и пересылает почту на локальный Hub Transport.

        В данной статье будет рассмотрен второй и наиболее правильный (на мой взгляд) вариант публикации сервера Exchange. Возможным минусом данной схемы является то, что вам необходимо будет приобрести дополнительную лицензию на Exchange Server 2010 и установить дополнительный Windows Server 2008.

        Примечание: Чтобы сэкономить на лицензии Windows Server и на аппаратном обеспечении, малые и средние организации могут поставить роль Edge Transport прямо на шлюз под управлением Threat Management Gateway (TMG), такая конфигурация официально поддерживается компанией Microsoft, поэтому так мы и сделаем (на ISA-сервер поставить Edge не получится). Подробнее про установку Exchange 2010 Edge Transport на TMG можно прочитать тут – http://www.alexxhost.ru/2010/04/exchange-server-2010-edge-server.html.

        В результате, схема нашей организации Exchange будет выглядеть следующим образом:

        Рис.2: Схема организации Exchange.

        Процесс инсталляции серверов и ролей Exchange 2010 я рассматривать в этой статье не буду, т.к. ни чего сложного в этом нет и данная тема, уже не однократно описывалась в других источниках. Давайте основное внимание уделим конфигурированию.

        Коммутация почты через Edge Transport

        Перед тем как начать настройку, давайте разберемся, как будет происходить взаимодействие пограничного транспортного сервера (Edge) с локальным транспортным сервером концентратором (Hub). Данная тема подробно описана в статье MS Exchange 2007/2010 – Edge Subscription (http://www.alexxhost.ru/2011/05/ms-exchange-20072010-edge-subscription.html) и из этой статье можно сделать вывод, что основой для взаимодействия данных транспортных серверов является пограничная подписка (Edge Subscription). О том, как она делается мы и поговорим далее.

        Настройка сетевых параметров Edge Transport сервера

        Перед тем, как оформлять подписку нужно правильно настроить сетевые параметры на сервере с ролью Edge Transport. Напомню, что в данном сценарии он не включён в доменную структуру предприятия, находится в DMZ-зоне и расположен на одном сервере с TMG (не забудьте правильно настроить правила на TMG для отправки/получения почты). Исходя из данного сценария, рекомендуется сделать следующие настройки:

        1. Получить у провайдера и установить на внешнем интерфейсе сервера IP-адрес (на который указывает ранее настроенная MX-запись), маску, шлюз и адреса DNS серверов провайдера;
        2. Если у вас в DMZ-зоне нет своего DNS-сервера, то нужно прописать в файл hosts в папке \%Systemroot%\System32\Drivers\Etc сопоставление имени Hub Transport сервера с его IP-адресом, т.е. добавить в конец файла строчку вида 192.168.0.10 hub.domain.local;
        3. На интерфейсе, смотрящем в локальную сеть предприятия установить IP-адрес и маску. Шлюз вписывать НЕ нужно;
        4. Настроить имя и DNS-суффикс компьютера, как показано на рис.4. (потом изменить эти настройки не получится);

        Рис.4: Настройка DNS-суффикса сервера.

        1. На локальном DNS сервере создать А-запись, указывающую на IP-адрес Edge-сервера.

        В результате Edge сервер должен уметь резолвить адреса Интернета и адрес сервера с ролью Hub Transport, а Hub Transport сервер, в свою очередь, должен знать, как найти Edge-сервер по его FQDN-имени (для проверки можно использовать команды ping и nslookup).

        Оформление Edge Subscription

        Как уже говорилось выше, компьютер, на котором установлена роль пограничного транспортного сервера, не имеет доступа к Active Directory. Все сведения о конфигурации и получателях хранятся в экземпляре служб облегченного доступа к каталогам (AD LDS) Active Directory. Данную службу заранее придется установить, как показано на рис.5.

        Рис.5: Установка службы облегченного доступа к каталогам (AD LDS).

        Для выполнения задач, связанных с поиском получателей, пограничному транспортному серверу требуются данные, которые находятся в Active Directory. Эти данные синхронизируются с пограничным транспортным сервером с помощью EdgeSync. EdgeSync представляет собой коллекцию процессов, выполняемых на компьютере с ролью транспортного сервера-концентратора (Hub Transport) для организации односторонней репликации сведений о получателе и конфигурации из Active Directory в AD LDS на пограничном транспортном сервере (Edge Transport).

        После установки AD LDS и правильной настройки сетевых параметров можно приступать к конфигурированию совместной работы Edge и Hub Transport серверов. Для этого оформим Edge Subscription следующим образом:

        1. На сервере c ролью Edge Transport выполним команду:

        New-EdgeSubscription –FileName c:\edge_subscr.xml

        Рис.6: Создание Edge Subscriprion.

        1. Полученный файл edge_subscr.xml скопируем на локальный Hub Transport сервер;
        2. Зайдем в консоль управления Exchange -> раздел Конфигурация организации -> действие New Edge Subscription

        Рис.7: Создание Edge Subscription на сервере Hub Transport.

        1. Выберем необходимый сайт AD и XML файл подписки. Не забудем оставить включенной галочку для автоматического создания отправляющих коннекторов.
        2. После завершения работы мастера, будут созданы коннекторы отправки, и через некоторое время будет выполнена синхронизация с сервером Edge Transport. Чтобы не дожидаться сеанса синхронизации, его можно выполнить вручную командой:

        Start-EdgeSynchronization

        После успешного создания пограничной подписки, необходимо настроить сам Exchange сервер на работу с получателями.
        Создание Accepted Domain и E-mail Address Policy
         

        Обслуживаемый домен (Accepted Domain) — это любое пространство имен SMTP, для которого организация Microsoft Exchange отправляет и принимает электронную почту. В связи с тем, что имя внешнего домена у нас отличается от локального (firma.ru и domain.local), необходимо на уровне организации добавить обслуживаемый домен firma.ru, с той целью, чтобы сервер Exchange смог с ним работать.

        Для этого перейдем на уровень конфигурирования организации -> Hub Transport -> Accepted Domain.

        Рис.11: Создание нового обслуживаемого домена.

        В мастере заполним отображаемое имя обслуживаемого домена, впишем сам домен и укажем, что домен будет Authoritative, т.к. почтовые ящики получателей будут находится в этом SMTP домене.

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

        E-mail Address Policy создаются на уровне организации в свойствах роли Hub Transport, выбором действия New E-mail Address Policy…

        Рис.12: Добавление E-mail Address Policy.

        Политику нужно применить ко всем типам получателей, без каких либо фильтров, привязать к нужному FQDN имени (как показано на рис.12) и указать в расписании немедленное выполнение (Immediately). В результате, политика адресов электронной почты (E-mail Address Policy), будучи привязанной к доверенному домену (Accepted Domain), автоматически создаст соответствующие адреса электронной почты всем получателям, к которым она применена.

        Примечание: Создание дополнительных адресов у получателей происходит не сразу, поэтому, чтобы не ждать, вы сами можете добавить e-mail адрес в свойствах почтового ящика, либо выполнить командлет Update-EmailAddressPolicy.

        Вы должны создать две политики – одну для домена firma.ru, другую для domain.local. В результате, каждый получатель в организации будет иметь по 2 e-mail адреса, причем в качестве обратного адреса, будет использоваться тот, который принадлежит политике с меньшим номером приоритета.

        На этом работа с сервером Hub Transport завершена и можно переместиться на Edge Transport.

        Переопределение адресов (Address Rewriting)

        В связи с тем, что у нас имена внешнего домена и домена AD отличаются, нам переписывать адреса во входящих и исходящих сообщениях (*.ru <-> *.local). В Microsoft Exchange Server 2010 для этих целей есть функция переопределения адресов (Address Rewriting), которая позволяет изменять адреса отправителей и получателей во входящих и исходящих сообщения. Подробнее про данную функцию можно почитать тут – http://technet.microsoft.com/ru-ru/library/aa996806.aspx.

        Для добавления политики переопределения адресов воспользуемся командлетом New-AddressRewriteEntry на сервере Edge Transprot:

        New-AddressRewriteEntry –Name “Lan – Internet” –InternalAddress “domain.local” – ExternalAddress “firma.ru”

        Рис.13: Добавление политики переопределения адресов.

        Примечание: Данная политика применяется не сразу, для немедленной её активации можно в ручную перезапустить службу Microsoft Exchange Transport.

        Возможные проблемы

        На этом базовая настройка Exchange Server 2010 на работу с внешней почтой через сервер Edge Transport, расположенный в DMZ-зоне предприятия, закончена. Следующим шагом будет проверка отправки и получения этой почты. Если по каким либо причинам почта не отправляется, либо не принимается, то я посоветовал бы для начала выполнить следующие шаги:

        1. Воспользоваться мастером Remote Connectivity Analyzer, расположенном в меню Toollbox. Данный мастер отправит вас на страничку http://testexchangeconnectivity.com/, с которой можно произвести тестирование многих сервисов Exchange`a.
        2. Посмотреть очередь сообщений Toolbox -> Queue Viewer с той целью, чтобы определить, на какой стадии зависло письмо. Данная утилита может показать не только очередь сообщений, но также текст последних ошибок, которые произошли с конкретной очередью и заголовки писем, находящихся в ней.
        3. Команда telnet YourServer 25 поможет вам проверить, доступны ли ваши сервера для приема почты.
        4. Если в Queue Viewer вы обнаружили проблемы связанные с DNS, то скорее всего вы не правильно настроили сетевые параметры интерфейсов, либо неверно отредактировали файл hosts.
        5. Также, для Edge Transport сервера можно указать адреса DNS-серверов, отличные, от тех, которые установлены на сетевых интерфейсах, делается это в меню Properties выбранного сервера – вкладки Internal DNS Lookups и External DNS Lookups.
        6. На коннекторах необходимо проверить вкладки Network, Authentication и Permission Group.
        7. После внесенных изменений на Hub Transport`e не забывайте выполнять синхронизацию (Start-EdgeSynchronization).
        8. Если ничего из выше озвученного не помогает, то можно посмотреть в сторону анализа логов системы, и включить Protocol Logging на вкладке General в свойствах коннекторов. Подробнее про анализ журналов транспорта можно почитать тут – http://technet.microsoft.com/ru-ru/library/aa998617.aspx.

        Заключение.

        Мы рассмотрели основные настройки, которые необходимо сделать, чтобы почтовая система вашей организации начала работать с внешним доменом через выделенный сервер с ролью Edge Transport. В следующих статьях мы поговорим про то, как защитить эту почту от спама и вирусов.

        Алексей Богомолов

      • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, TMG, Кон, Конкурс
        • Exchange Server 2010 Edge Server и Microsoft Threat Management Gateway

          usb-email Для повышения уровня безопасности в среде Exchange Server 2010 вы можете использовать Edge Transport Server, установленный в демилитаризованной зоне (DMZ) либо в сети периметра. По умолчанию в Edge Transport Server включена функция фильтрации спама, а после установки Forefront Protection for Exchange на Edge Transport Server вы также включаете и антивирусную защиту.

        • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
          • Role Based Access Control (RBAC) – новая модель управление доступом к Exchange 2010 (часть 2)

            logo В прошлой статье (http://itband.ru/2010/04/rbac/) мы рассмотрели основные механизмы работы RBAC. Теперь пришло время закрепить полученные знания на практике. Прежде чем приступать к решению конкретных задач, необходимо понять, как происходит процесс аутентификации пользователей на Exchange сервере.

          • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
            • Role Based Access Control (RBAC) – новая модель управление доступом к Exchange 2010

              loo

              До выхода Exchange 2010 наделение пользователей дополнительными возможностями осуществлялось при помощи функционала делегирования управления и списков управления доступом (ACL). В Exchange 2010 сердцем модели авторизации стала новая система разрешений Role Based Access Control (RBAC).

            • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
              • MS Exchange 2010 и Outlook 2010 – планирование встреч.

                kalendars В Microsoft Outlook 2010 есть новая функция – Расписание (Schedule View), которая делает процесс планирования собраний со своими коллегами и подчиненными более наглядным и быстрым.

                 

              • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
                • Аварийное восстановление сервера Exchange 2010

                  BackupRecovery UPDATE: Веб-каст по мотивам этой статьи: Теория, Практика.

                  Как правило, после успешной установки и настройки сервера, следующее, о чем задумывается системный администратор – это о том, как он его будет восстанавливать в случае аварии. В этой статье мы поговори о том, как можно восстановить полностью вышедший из строя Exchange Server 2010.

                • Главная Exchange/UC, Без рубрики, Новое DAG, Exchange 2010, NLB, Конкурс
                  • Отказоустойчивый Exchange 2010 (DAG + NLB)

                    exchange20102

                    UPD: Исправлен недочет в разделе организации NLB-массива.

                    Сегодня ни кто уже не будет спорить, что почтовая система в каждой организации является одним из самых важных и уязвимых мест. Сточки зрения бизнеса, корпоративная почта должна быть доступна в режиме 24/7, т.к. часто запоздалая отправка, либо несвоевременное получение всего одного письма может принести компании ощутимый финансовый и имиджевый урон. В связи с этим, ИТ-администраторы предпринимают всяческие меры по обеспечению отказоустойчивости почтовых серверов. До выхода Exchange 2007 это было достаточно не простой задачей. Затем в 2007-м Exchange`е компания Microsoft изменила эту ситуацию, введя две новые функции CCR и SCR, которые, надо заметить, были весьма успешными в деле организации безаварийной работы.

                    С выходом Exchange 2010, Microsoft пошла ещё дальше и улучшила функции CCR и SCR, соединив две функции в одном компоненте DAG (Database Availability Group), DAG стала новой функцией непрерывной доступности баз данных почтовых ящиков. Функция DAG, как и CCR, зависит от ограниченного набора компонентов отказоустойчивой кластеризации Windows (Failover Cluster), в основном, от базы данных кластера, файлового ресурса-свидетеля и функции импульса синхронизации. Группы DAG обеспечивают защиту на уровне базы, сервера и узла и делают развертывание решения высокой доступности и аварийного восстановления на уровне сайта гораздо проще, нежели в предыдущих версиях Exchange.

                    Но обеспечить отказоустойчивость баз данных это ещё пол дела, также нужно обеспечить непрерывный доступ самих пользователей к этим базам данных. Как известно, за работу с почтовыми клиентами в Exchange отвечает CAS (Client Access Service). Для организации отказоустойчивости этой службы существует Client Access Array, который позволяет объединить несколько CAS серверов в массив, а затем настроить доступ к FQDN этого массива при помощи стандартного Windows NLB (Network Load Balancing) кластера.

                    Кроме ролей Mailbox Server и Client Access Server существует ещё и роль транспортного сервера-концентратора (Hub Transport Server), как же быть с ней в плане отказоустойчивости? А с ней совсем делать ни чего не надо, достаточно установить на два или более сервера Exchange 2010 эту роль и отказоустойчивость будет обеспечена автоматически, т.к. транспортные серверы-концентраторы Exchange отказоустойчивы по умолчанию. То есть, при наличии более чем одного транспортного сервера-концентратора, развернутого на сайте Active Directory, и в случае недоступности одного из транспортных серверов-концентраторов в этом сайте Active Directory исходный транспортный сервер-концентратор, пытающийся доставить сообщение, перейдет к следующему транспортному серверу-концентратору в этом сайте Active Directory. Это проделывается с помощью механизмов циклического опроса DNS (если первый транспортный сервер-концентратор в списке не отвечает, переходим к следующему). Так что когда речь заходит о связи между двумя транспортными серверами-концентраторами или между сервером почтового ящика и транспортным сервером-концентратором (то есть внутренней), нам не нужно заботиться о высокой доступности (или балансировке, если на то пошло), поскольку это собственные функции Exchange 2010. Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения. Но данный факт не относится к серверам, включенным в DAG группу. В случае, если Hub Transport`ы установлены на сервера MailBox, входящие в DAG, то сервера почтовых ящиков будет предпочитать любой другой Hub Transport в сайте AD, и только в последнюю очередь будут обращаться к локальным.

                    Теперь перейдем от теории к практике и посмотрим, как обеспечить отказоустойчивость Exchange 2010.

                    Для этого построим принципиальную схему организации почтовой системы предприятия:

                    Рис.1. Принципиальная схема почтовой системы предприятия

                    Примечание: Настройку сервера EDGE Transport в этой статье рассматривать не будем (о ней можно почитать тут). Так же не будем рассматривать процедуру установки Exchange серверов (это совсем не сложно), единственное, в чем хочу вас предостеречь, так это в том, что не стоит пытаться устанавливать несколько серверов одновременно (даже в тестовой среде), необходимо дождаться окончания установки одного сервера, а затем приступать к инсталляции другого, в противном случае системные ошибки неизбежны.

                    Перейдем к настройке Database Availability Group

                    Важно отметить, что в каждую DAG группу может входить до 16 серверов почтовых ящиков, таким образом, вы сможете иметь до 16 копий каждой базы (хранение более одной копии базы почтовых ящиков на каждом сервере не поддерживается, а также активной может быть только одна копия), причем нужно не забывать, что каждый Exchange 2010 Standard может поддерживать только 5 баз данных, а Enterprise версия – до 100 баз. Время переключение между базами в Exchange 2010 заметно снижено, и теперь составляет порядка 30 секунд, а если учесть тот факт, что клиенты общаются с базами данных через Client Access Servers, то они совсем не заметят этого перехода. Также в Exchange 2010 предпринята попытка отказаться от публичных папок (Public Folders), и хотя они все ещё поддерживаются, но теперь их нельзя включить в группу DAG и обеспечивать их доступность придется при помощи стандартных механизмов репликации баз данных публичных папок.

                    Как уже говорилось выше, группы DAG в своей работе используют часть компонентов системы отказоустойчивых кластеров (Failover Clusters), таким образом, как и в классическом отказоустойчивом кластере, серверам нужно иметь по два сетевых интерфейса: один для MAPI-доступа клиентов, другой для трафика heartbeat/replication, по которому будет отслеживаться состояние узлов кластера. Хотя решения с одним сетевым интерфейсом на каждом сервере поддерживаются, но мы не будем экспериментировать и возьмем две сетевых карты, одна будет смотреть в локальную сеть предприятия и будет иметь адрес из диапазона 192.168.0.0/24, другая – в изолированную сеть с адресным пространством 192.168.1.0/24.

                    Рис.2: Принципиальная схема Database Availability Group

                    На интерфейсе для Heartbeat`ов можно отключить такие компоненты сетевого взаимодействия, как TCP/IPv6, Client for Microsoft Network, File and Printer Sharing и
                    даже QoS. Затем надо проверить что локальный сетевой интерфейс находится первым в списке порядка привязки, для этого пойдем в меню Advanced (Дополнительно) > Advanced Settings (Дополнительные параметры) и посмотрим в раздел Connections.

                    Что касается организации хранилищ для баз данных почтовых ящиков, то теперь вам не придется приобретать высокоскоростные, а, следовательно, и дорогие жесткие диски. В связи с изменениями в механизме расширяемого хранилища (ESE), с Exchange 2010 вы получаете вариант использования таких дисков с низкой производительностью, как диски SATA 7200! Фактически, вы можете размещать активную копию базы данных на одном SATA диске, а все остальные копии вместе – на другом, и ни каких проблема с производительность дисковой подсистемы у вас быть не должно. Правда тут надо заметить, что вместе с улучшениями в организации работы с жесткими дисками, у Exchange 2010 ещё более возрос аппетит к оперативной памяти сервера и теперь, Microsoft говорит, что !каждую роль! Exchange 2010 необходимо обеспечить 4 Гб оперативной памяти. Возможно это и некоторое преувеличение, но практика покажет, как дела обстоят на самом деле.

                    Для функционирования DAG, кроме самих серверов Exchange 2010 необходим ещё один сервер, не входящий в группу DAG, он будет выполнять роль сервера-свидетеля, это что-то вроде кворума в классическом отказоустойчивом кластере и именно с помощью него отслеживается состояние серверов, входящих в DAG. Для организации сервера-свидетеля подойдет любой сервер в сайте Active Directory, даже без установленного Exchange 2010, единственным условием его функционирования является то, что в группу его локальных администраторов должна входить доменная группа Exchange Trusted Subsystem.

                    Рис.3: Доменная группа
                    Exchange Trusted Subsystem в группе локальных администраторов сервера-свидетеля.

                    Итак, все подготовительные работы завершены, теперь давайте создадим новую DAG-группу. Для этого перейдем в раздел Organization Configuration (DAG находится именно на уровне организации), откроем вкладку Database Availability Groups и в меню Действия выберем New Database Availability Group… Откроется мастер конфигурирования DAG:

                    Рис.4: Мастер настройки DAG

                    Здесь нужно вписать имя группы, имя сервера-свидетеля (не забываем, что он не должен входить в DAG) и имя папки, где будет храниться информация о состоянии Exchange серверов (мастер создаст папку на удаленном сервере сам). Далее, если все настроено правильно, то мастер создаст группу и следующим шагом нам нужно будет добавить в неё сервера, для этого нажмем на группе правой кнопкой мыши и выберем пункт Manage Database Availability Group. В данном мастере необходимо добавить сервера с установленной ролью Mailbox, которым мы хотим обеспечить высокую доступность:

                    Рис.5: Добавление серверов в группу DAG

                    После нажатия кнопки Manage будет произведена настройка и конфигурирование выбранных серверов, в частности, на них будут установлены необходимые составляющие компонента Диспетчер отказоустойчивости кластеров и сконфигурирован сам кластер.

                    Примечание: Если что-то пошло не так и кластер не собрался, то часто бывает трудно оценить проблему по тексту ошибки, выданному Exchange`м, в такой ситуации может помочь функция проверки узлов кластера в Диспетчере отказоустойчивости кластеров, которая дает гораздо больше информации по присутствующим проблемам:

                    Рис.6: Проверка кластера.

                    Если у вас в сети нет DHCP сервера, то DAG соберется, но будет в неактивном состоянии, т.к. группе не будет назначен IP адрес (состояние кластера можно также посмотреть в Диспетчер отказоустойчивости), чтобы исправить эту неприятность, необходимо воспользоваться командлетом New-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIPAddresses, вот как-то так:

                    New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 192.168.0.5

                    Когда группа DAG у вас будет собрана и активна, необходимо сделать копии баз данных на «соседних» серверах (не забывайте, что каждый сервер может хранить только одну копию базы). Чтобы создать копию базы данных, нажмите правой кнопкой мыши на исходной базе и выберите пункт меню Add Mailbox Database Copy…, далее откроется мастер, в котором нужно указать на каком сервере будет размещена копия и приоритет её активации:

                    Рис.7: Создание копии базы данных.

                    Если вам не нравится GUI, то можно это сделать с помощью командлета:

                    Add-MailboxDatabaseCopy -Identity MDB2 -MailboxServer Server3 -ActivationPreference 2
                    

                    Создать копию базы данных с временем задержки воспроизведения и временем задержки усечения можно только из командной консоли Exchange (здесь 10 и 15 минут соответственно):

                    Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 00:10:00 -TruncationLagTime 00:15:00 -ActivationPreference 2
                    

                    Таким образом, мы получаем несколько копий исходной базы данных, расположенные на разных серверах и в разных хранилищах. Чтобы активировать одну из копий, нужно нажать на ней правой кнопкой мыши и из выпадающего меню выбрать Activate Database Copy, после чего в открывшемся окне решить стоит ли перезаписывать параметры базы и нажать ОК, далее база данных будет автоматически смонтирована на другом сервере и её состояние измениться с Healthy на Mounted:

                    Рис.8: Переключение баз почтовых ящиков.

                    Примечание: Если вам необходимо сделать заполнение (обновление) одной из копий баз данных, то перед этим нужно приостановить её работу командой Suspend Database Copy, а затем выбрать пункт Update Database Copy…

                    Рис.9: Обновление копии базы данных почтовых ящиков.

                    Перейдем к настройке массива серверов CAS

                     

                    Принципиальная схема взаимодействия серверов в массиве будет выглядеть следующим образом:

                    Рис.10: Принципиальная схема взаимодействия серверов в CAS массиве.

                    Смысл в том, что клиенты, вместо подключения непосредственно к CAS серверу, будут подключаться к FQDN CAS-массива и при «падении» одного из серверов клиентские запросы возьмет на себя другой.

                    Т.к. массив CAS используется только клиентами Outlook MAPI, то для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, необходимо решить, что именно у вас будет выполнять роль балансировщика сетевой нагрузки (NLB). Microsoft рекомендует использовать для этих целей внешние аппаратные устройства, но если у вас таковых нет, то служба Windows Network Load Balancing вполне подойдет. Здесь нужно иметь в виду, что службы Windows NLB и Failover Cluster на одном сервере не живут!

                    Для работы WNLB (как и других систем балансировки), необходимо иметь на DNS сервере запись, указывающую на виртуальный IP-адрес этой системы:

                    Рис.11: Настройка DNS сервера.

                    Далее давайте настроим Windows NLB кластер, для этого установим соответствующие компоненты в диспетчере сервера, затем откроем Диспетчер балансировки сетевой нагрузки в меню Администрирование и создадим новый кластер.

                    Рис.12: Создание нового кластера NLB.

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

                    Рис.12: Настройка параметров кластера.

                    Снова введем IP-адрес и FQDN имя, указанное ранее в DNS сервере. Следующим шагом, нужно будет определить, какой режим работы выбрать, если кратко, то в одноадресном режиме, МАС адрес сетевого адаптера каждого сервера будет заменен виртуальным МАС адресом кластера и будет использоваться всеми серверами кластера. В многоадресном режиме МАС адрес добавляется в адаптер кластера на каждом сервере и каждый сервер сохраняет свой МАС адрес. Рекомендуется использовать Одноадресный режим!

                    Подробнее про принцип работы NLB можно посмотреть здесь.
                     Отдельное спасибо Александру Станкевичу за детальное описание данного механизма!

                    Примечание: Если вы развертываете Exchange 2010 сервера в виртуальной среде, то при работе WNLB могут возникнуть проблемы, поэтому, если вы разворачиваете узлы кластера на платформе виртуализации VMware ESX Server, то вам придется использовать Многоадресный режим. Если же вы работаете с MicrosoftHyper-V, то лучше включить Одноадресный режим, но при этом внести некоторые изменения в настройки виртуального сетевого адаптера, а именно – настроить Статический МАС-адрес и включить функцию спуфинга МАС адресов.

                    Рис.14: Настройка сетевых интерфейсов в Hyper-V

                    В следующем окне мастера нужно определить какие порты будут использоваться в данном кластере. Вы можете по-умолчанию оставить открытыми все порты, а можете открыть следующие:

                    • TCP/135 – для работы CAS-массива (убедитесь, что в Filtering Mode свойство Affinity включено в Single);
                    • TCP/1024-65535 – диапазон RPC портов для MAPI-клиентов и CAS (если у вас не указаны статические порты);
                    • TCP/443 – для Outlook Anywhere, Exchange ActiveSync и Outlook Web App;
                    • TCP/993 – для Secure IMAP (Affinity включено в None);
                    • TCP/995 – для Secure POP (Affinity включено в None);
                    • TCP/80 – для внутреннего IIS перенаправления (HTTP > HTTPS).

                    Далее нажимаем Готово и добавляем ещё один узел к кластеру, нажав на созданном кластере правой кнопкой мыши и выбрав пункт Добавить узел к кластеру. У нового узла значение приоритета выставляем в 2 и все остальные параметры оставляем по-умолчанию.

                    Теперь осталось только собрать сам CAS массив.

                    Для этой цели воспользуемся командлетом New-ClientAccessArray:

                    New-ClientAccessArray -FQDN "mail.test-mail.local" –Site "Default-First-Site-Name"
                    

                    И подключить к массиву базы данных почтовых ящиков командлетом Set-MilboxDatabase:

                    Set-MailboxDatabase -RpcClientAccessServer "mail.test-mail.local"
                    

                    Рис.15: Создание CAS массива.

                    Проверить результат можно командлетом Get-MilboxDatabase.

                    На этом настройка массива CAS серверов заканчивается, проверить работоспособность массива можно запустив MS Outlook, служба Autodiscover должна разрешить имя сервера как FQDN массива.

                    Рис.16: Настройка MS Outlook.

                    Статьи для подробного изучения:

                     

                    PS. Нужно иметь ввиду, что отказоустойчивые решения для систем виртуализации, в частности Failover Cluster для Hyper-V, использующие Live Migration, нельзя комбинировать с решениями репликации Exchange (ССR или DAG). Рекомендуется настраивать CCR или DAG на узлах Hyper-V не включенных в Failover Cluster и, соответственно, не использующих Cluster Shared Volumes.

                    Запуск CCR или DAG на кластере с Live Migration не поддерживается!

                    PPS. Если вам потребуется изменить URL`ы таких служб, как OWA (Outlook Web App), ECP (Exchange Control Panel), Exchange ActiveSync (EAS) и Outlook Anywhere (OA), то об этом вы сможете почитать тут.

                    Алексей Богомолов (Alexx)