Рассмотрение групп доступности баз данных Exchange 2010 (DAG)


Давайте начнем с истории. До выхода Exchange 2007 функции отказоустойчивости и восстановления после сбоев, включенные в продукты Exchange Server, были весьма ограничены. Предыдущие версии Exchange (Exchange 2003 и ранее) могли использовать сервисы кластеров Microsoft Cluster Services (MSCS), но эта функция обеспечивала избыточность только на аппаратном уровне, поскольку узлы совместно использовали одну и ту же подсистему хранения. Если активный узел кластера внезапно становился недоступным, то виртуальный сервер Exchange Virtual Server (EVS) и все соответствующие ресурсы кластера переводились на пассивный узел, после чего конечные пользователи могли продолжать работу.

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

Большинство из нас согласится с тем, что с выходом Exchange 2007 эти возможности стали реальными! Exchange 2007 предоставил нам целый ряд принципиально новых функций отказоустойчивости и восстановления после сбоев, таких как функция локальной непрерывной репликации (Local Continuous Replication — LCR), которая предназначалась для малых организаций, и непрерывная кластерная репликация (Cluster Continuous Replication — CCR), предназначенная для средних и крупных предприятий. Позже (с выходом Exchange 2007 SP1) появилась функция непрерывной резервной репликации Standby Continuous Replication (SCR), которая предназначена для предприятий всех размеров. Все три функции использовали новую технологию асинхронной репликации, которая работала путем передачи файлов логов в пассивную копию группы хранения и после осмотра преобразовывала их в эту пассивную копию.

Хотя LCR обеспечивала избыточность на уровне хранилища, эта функция так и не получила широкого распространения. Причиной тому стало то, что поскольку копии групп хранения нужно хранить на локальном томе сервера почтовых ящиков (Mailbox), такая конфигурация представляла собой единую точку сбоя на аппаратном уровне. С выходом Exchange 2007 функция CCR стала очень успешной. Интересным моментом в CCR было то, что она сочетала использование новой технологии асинхронной репликации, представленной в Exchange 2007, с технологией кластеров обхода отказа (Windows Failover Clustering), тем самым обеспечивая избыточность на аппаратном уровне, равно как и на уровне хранилища, что делало ее истинным решением отказоустойчивости, не имеющим единой точки сбоя.

Узлы кластера CCR могли быть расположены в различных центрах данных для обеспечения избыточности на уровне предприятия, но поскольку CCR разрабатывалась без учета устойчивости на уровне сайта, существовало множество сложностей с реализацией многосайтового CCR кластерного решения (для подробной информации об установке многосайтового CCR кластера обратитесь к одной из моих предыдущих статей). Это заставило группу разработчиков продукта Exchange задуматься над тем, как можно создать встроенную функцию, которая бы обеспечивала гибкость на уровне сайтов, в Exchange 2007.

С выходом Exchange 2007 SP1 мы получили именно эту функциональность. Функция под названием Standby Continuous Replication (SCR) сделала возможным передачу файлов логов на другой сервер почтовых ящиков Exchange 2007 Mailbox Server. Поскольку функции SCR не требовалось использование Windows Failover Clustering, файлы журналов могли передаваться с кластерных и не-кластерных серверов почтовых ящиков (источник SCR) на кластерные и не-кластерные серверы почтовых ящиков (SCR цель). Интересным моментом в SCR было то, что можно было задавать время запаздывания преобразования журнала до 7 дней, что позволяло исправлять большинство проблем, связанных с базами данных/хранением, прежде чем они могли нанести ущерб SCR цели, расположенной в другом центре данных.

Примечание: Exchange 2007 Service Pack 2 – это в большей степени пакет обновления, который подготавливает существующие Exchange 2007 организации к переходу на Exchange 2010, поэтому в этом пакете отсутствуют какие бы то ни было значительные изменения или усовершенствования в области отказоустойчивости или гибкости на уровне сайтов.

В силу того, что функции CCR и SCR уже доступны, можно подумать, что в каких-либо изменениях или улучшениях в области отказоустойчивости или надежности сайтов нет необходимости в новой и лучшей версии Exchange 2010, не так ли?

Надо признать, что последние пару лет группа разработчиков продукции Exchange потратила на разработку Exchange 2010, при этом большая часть времени была затрачена на значительное усовершенствование функций отказоустойчивости и устойчивости сайтов.

Изменения функций отказоустойчивости в Exchange Server 2010

В версии Exchange 2010 уже отсутствуют такие понятия, как Local Continuous Replication (LCR), Single Copy Clusters (SCC), Cluster Continuous Replication (CCR) или Standby Continuous Replication (SCR). ЧТО!? Скажут некоторые из вас! Да, я не шучу. Но если говорить точнее, только LCR или SCC были полностью убраны из продукта Exchange Server. CCR и SCR были объединены и преобразованы в более унифицированную инфраструктуру отказоустойчивости, в которой новая группа доступности баз данных (Database Availability Group — DAG) выступает в качестве базового компонента. Это означает, что вы будете использовать DAG независимо от того, собираетесь ли вы установить локальное решение отказоустойчивости и восстановления после сбоев, или же решение на уровне сайтов. Чтобы прояснить свои мысли скажу, что в Exchange 2010 вашим единственным способом защиты баз данных почтовых ящиков будет использование DAG.

Рисунок 1: Базы данных почтовых ящиков защищены с помощью DAG
Рисунок 1: Базы данных почтовых ящиков защищены с помощью DAG

Основным компонентом в DAG является новый компонент под названием активный диспетчер (Active Manager). Вместо Exchange кластерного ресурса DLL (exres.dll) и связанных с кластерными службами ресурсов, которые требовались для кластера Exchange 2007 и предыдущих версий Exchange, Exchange 2010 теперь полагается на Active Manager при управлении переходом между серверами почтовых ящиков DAG. Active Manager работает на серверах почтовых ящиков в определенной DAG. У нас есть две активные роли диспетчера, основной активный диспетчер (Primary Active Manager — PAM) и аварийный активный диспетчер (Standby Active Manager — SAM). Для подробной информации о ролях PAM и SAM обратитесь к соответствующей Exchange 2010 Online документации на Microsoft TechNet.

Так что же интересного в DAG? Есть много вещей; самые примечательные перечислены ниже:

Ограниченная зависимость от Windows Failover Clustering — группа DAG использует лишь ограниченный набор кластерных функций, предоставляемых компонентом Windows Failover Clustering. DAG использует кластерную базу данных, импульсные сигналы и функцию свидетеля файлового ресурса. Exchange 2007 (и более ранние версии) работали под управлением Windows Failover Cluster. Exchange 2010 не работает под управлением этого компонента. Кластерный ресурс DLL (exres.dll) и все ресурсы кластера, создаваемые им при регистрации, были удалены из программы Exchange 2010.

Рисунок 2: DAG все еще зависит от базы данных кластера, импульсного сигнала и репликации компонента Windows Failover Cluster
Рисунок 2: DAG все еще зависит от базы данных кластера, импульсного сигнала и репликации компонента Windows Failover Cluster
Рисунок 3: Нет никаких ресурсов кластера Exchange в Windows Failover Cluster Рисунок 3: Нет никаких ресурсов кластера Exchange в Windows Failover Cluster

Инкрементная установка — поскольку группы DAG все еще используют некоторые компоненты WFC, такие как база данных кластера, импульсный сигнал и свидетель файлового ресурса, Windows Server 2008 SP2 или R2 Enterprise версия необходима для настройки серверов Exchange 2010 Mailbox в DAG. Но Exchange 2010 поддерживает инкрементный подход установки, что означает, что нет необходимости в создании кластера до установки Exchange 2010. Можно установить серверы Exchange 2010 Mailbox, а затем создать DAG и добавить серверы и любые базы данных в DAG при необходимости.

Сосуществование с другими ролями Exchange — при использовании CCR у нас не было возможности установить другие роли сервера Exchange на серверы почтовых ящиков (узлы кластера), которые были защищены CCR. При использовании DAG на ее компонент серверов почтовых ящиков можно устанавливать другие роли Exchange. Это особенно полезно для малых предприятий. Поскольку теперь DAG защищенный сервер почтовых ящиков может работать совместно с другими ролями Exchange, это означает, что вы можете создавать полностью избыточное Exchange 2010 решение всего на двух машинах, выделенных под серверы Exchange. Конечно, вам придется настраивать свидетеля файлового ресурса, но им может стать любой в вашей среде. Свидетель файлового ресурса не обязательно должен работать под управлением той же версии Windows, что и серверы Exchange 2010. Он просто должен работать под управлением Windows сервер 2003 или выше. Еще одним моментом, который следует учитывать, является то, что если вы решите использовать два сервера Exchange 2010, и вам нужно полностью избыточное решение, вам необходимо использовать внешнее аппаратное оборудование или программное решение по компенсации нагрузки для служб Client Access.

Управляется на 100% посредством инструментов Exchange — с использованием CCR в Exchange 2007 нужно было настраивать и управлять кластерами CCR с помощью комбинации инструментов Exchange и инструментов управления кластерами. При использовании DAGs в Exchange 2010 вам больше не нужно использовать инструменты по управлению кластерами ни для начальной конфигурации, ни для управления. Вы можете управлять группами DAG, используя исключительно инструменты управления Exchange. Это означает, что администраторы Exchange на предприятии больше не нуждаются в опыте работы с кластерами (хотя этот опыт все еще полезен).

Рисунок 4: DAG, сети репликации и FSW настройки управляются с помощью инструментов Exchange Рисунок 4: DAG, сети репликации и FSW настройки управляются с помощью инструментов Exchange

Репликация на уровне баз данных — для поддержки новой функции групп DAG базы данных в Exchange 2010 теперь перемещены на уровень организации, а не на уровень сервера, где они находились в предыдущих версиях Exchange. Это также означает, что Exchange 2010 более не использует концепцию групп хранения. Теперь это базы данных и поток журналов, связанный с каждой базой данных. Одним из слабых мест CCR было то, что даже если одна база данных давала сбой на активном узле кластера, все активные базы данных, расположенные на кластерном почтовом сервере, перемещались на пассивный CCR узел. Это влияло на всех пользователей, у которых почтовые ящики хранились на таком сервере CMS.

Рисунок 5: Базы данных на уровне организации Рисунок 5: Базы данных на уровне организации

Поддержка до 16 членов в каждой группе DAG — теперь вы можете добавлять до 16 серверов почтовых ящиков в группу DAG и иметь 16 копий каждой базы данных Mailbox, Exchange 2010 поддерживает больше баз данных почтовых ящиков, чем Exchange 2007. Теперь верхний предел был поднят с 50 до 100 баз данных Mailbox в Exchange 2010 версии Enterprise. Однако версия Standard поддерживает лишь до 5 баз данных для каждого сервера Mailbox.

Переходы Switch/Fail-overs гораздо быстрее — благодаря улучшениям, внесенным в Exchange 2010 DAG, мы получили гораздо более быстрое переключение и переход (switches and fail-overs (*-overs)) между копиями баз данных почтовых ящиков. Этот переход будет осуществляться менее чем за 30 секунд по сравнению с несколькими минутами при использовании CCR в Exchange 2007. К тому же, поскольку Outlook MAPI клиенты теперь подключаются к службе RPC Client Access на серверах Client Access Servers, конечные пользователи не будут замечать эти процессы перехода и переключения. Более подробную информацию о RPC Client Access сервисах вы можете найти в моей предыдущей серии статей здесь.

Минимальные резервные копии +3 копий баз данных — при наличии трех или более копий баз данных почтовых ящиков приложение запрограммировано на создание меньшего числа резервных копий. Это означает, что вы, как правило, включаете цикличную запись журналов на всех базах данных почтовых ящиков, защищенных группами DAG, и вам больше не нужно выполнять резервные копии в известной нам форме. Это требует пересмотра отношения к тому, как базы данных почтовых ящиков должны быть защищены в организациях.

Поддержка членов групп DAG в различных AD сайтах — в отличие от узлов CCR кластера, серверы-участники группы DAG могут располагаться на разных Active Directory сайтах. Это будет долгожданное дополнение для тех, у кого нет возможности использования одного AD сайта во всех офисах (центрах данных). Однако следует отметить, что вы не можете расположить серверы Mailbox, защищенные одной группой DAG, в разные домены вашего Active Directory леса.

Передача журналов через TCP — в Exchange 2007, служба репликации Microsoft Exchange Replication Service копировала файлы журналов в пассивную копию баз данных (LCR), на пассивный узел кластера (CCR) или SCR цель через Server Message Block (SMB), что означало, что вам нужно было открывать порт 445 на любой межсетевом экране между узлами кластера CCR (обычно при установке многосайтовых CCR кластеров) и/или SCR источником и целью. Те из вас, кто работает с или на большие предприятия, знает, что убедить сетевых администраторов открыть порт 445/TCP между двумя центрами данных было далеко непростой задачей. С использованием Exchange 2010 DAG технология асинхронной репликации больше не полагается на SMB. Exchange 2010 использует TCP/IP для копирования и передачи файлов журналов, более того, он дает возможность указывать, какой порт вы хотите использовать для репликации файлов журналов. По умолчанию, DAG использует порт 64327, но вы можете указать другой порт, если это нужно.

Сжатие файлов журналов — при использовании Exchange 2010 DAG вы можете включить сжатие передачи и репликации для одной или нескольких сетей в DAG. Это свойство самой группы DAG, а не сети DAG. Параметром по умолчанию будет InterSubnetOnly, здесь также доступны те же настройки, которые имеются в свойствах шифрования сети.

Шифрование файлов журналов — Exchange 2010 DAG поддерживает использование шифрования, в то время как в Exchange 2007 файлы журналов копируются по незашифрованному каналу (если не настроено IPsec). Если говорить точнее, DAG использует возможности шифрования Windows Server 2008, а именно, DAG использует Kerberos аутентификацию между всеми Mailbox серверами, принадлежащими к соответствующей группе DAG. Сетевое шифрование является свойством самой группы DAG, а не сети DAG. Параметры свойств сетевого шифрования DAG включают следующее: отключено — Disabled (сетевое шифрование не используется), включено — Enabled (сетевое шифрование включено для передачи и репликации для всех сетей, имеющихся в DAG), InterSubnetOnly (значение по умолчанию, которое означает, что сетевое шифрование используется для DAG сетей, расположенных в одной подсети), и SeedOnly (сетевое шифрование используется для передачи на всех сетях в DAG).

Копии с задержкой до 14 — с функцией Standby Continuous Replication, включенной в Exchange 2007 SP1, были представлены отсроченные копии баз данных. Благодаря этой функции мы могли осуществлять отсрочку того времени, после которого файлы журналов, копируемые в SCR цель, преобразовывались в базу данных на целевом сервере SCR. У нас также была возможность указания, так называемого, времени задержки усечения (truncation lag time), которая позволяла нам откладывать время, после которого файлы журналов, скопированные в SCR и преобразованные в копию базы данных, должны быть усечены. С помощью этих двух опций мы могли указывать время задержки до 7 дней. В Exchange 2010 DAG мы можем задавать время задержки усечения до 14 дней, что весьма полезно, если вы используете функцию минимального резервного копирования.

Передача из копии баз данных (DB copy) — в отличие от CCR в Exchange 2007 теперь мы можем выполнять передачу путем указания копии базы данных в качестве источника базы данных. Это означает, что новая передача или повторная передача существующих баз данных почтовых ящиков больше никак не влияет на копию активной базы данных.

Рисунок 6: Передача с выборочного сервера источника Рисунок 6: Передача с выборочного сервера источника

Базы данных публичных папок не защищены группами DAG — в отличие от CCR в Exchange 2007, мы не можем защитить базы данных публичных папок с помощью групп DAG. Базы данных публичных папок должны быть защищены с использованием традиционных механизмов репликации баз данных публичных папок. Положительным моментом в этом является то, что мы больше не ограничены только одним хранилищем публичной базы данных в организации Exchange, если она храниться на сервере участнике группы DAG. При использовании CCR у нас могло быть только одно хранилище базы данных.

Улучшенная транспортная корзина — транспортная корзина, которая известна нам из Exchange 2007, также была улучшена, поэтому сообщения могут быть повторно доставлены даже после того, как возникает ситуация обхода отказа с потерями между копиями баз данных, хранящихся на различных сайтах Active Directory. Вдобавок к этому, когда все сообщения реплицированы во все копии баз данных, они будут удалены из транспортной корзины.

На этом закончим первую часть нашего цикла статей. В следующей части мы начнем установку группы DAG в нашей тестовой среде и рассмотрим различные параметры и настройки, специфичные для DAG.

Тестовая среда

Тестовая среда, используемая в качестве основы для этого цикла статей, состоит из одного контроллера домена Windows 2008 R2, одного файлового сервера Windows Server 2008 R2 (будет использоваться в качестве сервера свидетеля), и двух серверов Windows 2008 R2 Enterprise версии, присоединенных к домену, на которые будет установлен Exchange 2010. Мы используем Enterprise версию, поскольку DAG требует использования версии Enterprise. Это является требованием, поскольку, как и в случае с CCR и SCR, группы DAG все еще используют часть компонентов Windows Failover Cluster (периодический сигнал, свидетель файлового ресурса и базу данных кластера). Роли серверов Exchange 2010 Client Access, Hub Transport и Mailbox будут установлены на оба сервера Windows Server 2008 R2. Более того, обратите внимание, что сама функция Exchange 2010 DAG не зависит от Exchange 2010 Enterprise версии (только от Windows Server 2008 R2 Enterprise версии). Это означает, что вы можете использовать версию Standard продукта Exchange 2010 (или пробную версию), если собираетесь проделывать все представленные здесь процедуры в своей тестовой среде. Стандартная версия просто ограничивает вас максимум 5 базами данных (включая активные и пассивные копии) на каждом сервере Exchange 2010.

На каждом сервере Exchange 2010 установлено по две сетевых карты, одна подключена к сети предприятия, вторая — к изолированной сети периодического сигнала/репликации (heartbeat/replication). Хотя рекомендуется использовать как минимум две сетевые карты на каждом участнике группы DAG (одна для MAPI доступа, вторая или несколько для репликации, заполнения и периодического сигнала), следует отметить, что Microsoft поддерживает использование одной сетевой карты для MAPI доступа, репликации, заполнения и пульса. Это полезно знать администраторам в мелких компаниях, которые желают использовать группы DAG.

Поскольку одной из моих целей в этой статье является демонстрация поддержки установки DAG инкрементным способом (более подробно об этом способе читайте в первой части), я не буду устанавливать компонент Windows Failover Cluster ни на один из серверов до создания группы DAG.

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

Как уже говорилось, на каждый сервер установлено по две сетевые карты. Давайте рассмотрим настройки каждой сетевой карты. Для этого открываем Сетевые подключения. Здесь у нас перечислены все сетевые адаптеры, и как вы видите, у нас есть PROD карта (подключенная к производственной сети и MAPI), а также интерфейс REPLICATION (подключенный к изолированной сети).

Рисунок 1: Сетевые подключения Рисунок 1: Сетевые подключения

Давайте откроем страницу свойств интерфейса PROD. Здесь, обычно, можно оставить все настройки по умолчанию. Вы также можете снять флажки с опций Планировщик пакетов QoS и Internet Protocol Version 6 (TCP/IP v6).

Рисунок 2: Свойства PROD интерфейса Рисунок 2: Свойства PROD интерфейса

Открываем страницу свойств Internet Protocol Version 4 (TCP/IPv4). Здесь у нас имеется статический IP адрес, а также все остальные необходимые параметры (основной шлюз, маска подсети и DNS сервер).

Рисунок 3: TCP/IP Version 4 свойства интерфейса PROD Рисунок 3: TCP/IP Version 4 свойства интерфейса PROD

Когда вы настроили сетевую карту должным образом, закройте страницу свойств, дважды нажав OK.

Теперь нужно настроить сетевые параметры для интерфейса ‘REPLICATION’, поэтому открываем страницу свойств карты ‘REPLICATION’. Убираем флажки с опций ‘Клиент для сетей Microsoft (Client for Microsoft Networks)’ и ‘Служба доступа к файлам и принтерам сетей Microsoft (File and Printer Sharing for Microsoft Networks)’, как показано на рисунке 4. Вы также можете снять флажки с опций Планировщик пакетов QoS и Internet Protocol Version 6 (TCP/IPv6).

Рисунок 4: Свойства интерфейса REPLICATION Рисунок 4: Свойства интерфейса REPLICATION

Теперь открываем страницу свойств ‘Internet Protocol Version 4 (TCP/IPv4)’ и вводим IP адрес и маску подсети для изолированной подсети репликации. Поскольку эта сетевая карта будет использоваться исключительно в целях репликации, заполнения и пульса, не нужно указывать основной шлюз или DNS серверы.

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

Рисунок 5: TCP/IP Version 4 свойства интерфейса REPLICATION Рисунок 5: TCP/IP Version 4 свойства интерфейса REPLICATION

Теперь жмем ‘Дополнительно (Advanced)’ и убираем флажок с опции ‘Зарегистрировать адреса этого подключения в DNS (Register this connection’s addresses in DNS)‘, затем жмем ‘OK‘ дважды.

Рисунок 6: Дополнительные свойства TCP/IP для интерфейса<br />
REPLICATION Рисунок 6: Дополнительные свойства TCP/IP для интерфейса REPLICATION

Теперь, когда мы настроили каждый сетевой адаптер, нам нужно убедиться, что интерфейс ‘PROD’ расположен первым в списке порядка привязки. Чтобы вызвать список порядка привязки сетевых карт, нужно нажать клавишу ALT, а затем выбрать Дополнительно (Advanced) > Дополнительные параметры (Advanced Settings).

Рисунок 7: Выбор дополнительных параметров в меню сетевых<br />
подключений Рисунок 7: Выбор дополнительных параметров в меню сетевых подключений

Если это еще не так, переместите адаптер PROD в верх списка, как показано на рисунке 8.

Рисунок 8: Порядок привязки сетевых карт Рисунок 8: Порядок привязки сетевых карт

Нажмите OK и закройте окно сетевых подключений.

Примечание: Обязательно нужно убедиться, что все вышеупомянутые шаги выполнены на обоих серверах.

Подготовка хранилища

В нашей тестовой среде, используемой в этой статье, я создал четыре виртуальных диска (2×30ГБ для логов и 2×100 для активных/пассивных копий баз данных) для каждого сервера. Чтобы разбить диски, используемые для баз данных почтовых ящиков и журналов, откройте диспетчер сервера Windows 2008 Server Manager и разверните контейнер Хранение (Storage), после чего выберите опцию Управление дисками (Disk Management). Теперь нажмите правой клавишей на каждом LUN и выберите команду Online из контекстного меню.

Назначьте каждый LUN (диск) одинаково на каждом сервере, как показано на рисунке 10 ниже.

Рисунок 9: LUNs (диск) на каждом сервере Рисунок 9: LUNs (диск) на каждом сервере

Установка ролей сервера Exchange 2010

Прежде чем мы установим роли сервера Exchange 2010 на два сервера Windows 2008 R2, нам нужно убедиться, что все требуемые функции и компоненты установлены. Следующие компоненты должны быть установлены на все роли сервера Exchange 2010:

  • NET-Framework
  • RSAT-ADDS
  • Web-Server
  • Web-Basic-Auth
  • Web-Windows-Auth
  • Web-Metabase
  • Web-Net-Ext
  • Web-Lgcy-Mgmt-Console
  • WAS-Process-Model
  • RSAT-Web-Server
  • Web-ISAPI-Ext
  • Web-Digest-Auth
  • Web-Dyn-Compression
  • NET-HTTP-Activation
  • RPC-Over-HTTP-Proxy

Чтобы установить вышеуказанные функции, нужно сначала открыть окно Windows PowerShell и ввести:

Import-Module ServerManager

Рисунок 10: Импортирование модуля диспетчера сервера в<br />
Windows PowerShell Рисунок 10: Импортирование модуля диспетчера сервера в Windows PowerShell

Затем введите следующую команду, чтобы установить необходимые функции:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy ‘Restart

Рисунок 11: Установка необходимых функций Windows Server<br />
2008 R2 Рисунок 11: Установка необходимых функций Windows Server 2008 R2

После перезагрузки серверов нам нужно снова открыть окно Windows PowerShell, и задать автоматический запуск служб. Это можно сделать с помощью следующей команды:

Set-Service NetTcpPortSharing ‘StartupType Automatic

Рисунок 12: Настройка автоматического запуска службы<br />
NetTcpPortSharing Рисунок 12: Настройка автоматического запуска службы NetTcpPortSharing

Поскольку мы собираемся установить роли Hub Transport и Mailbox сервера на эти серверы, нам нужно установить пакетMicrosoft Filter Pack.

Теперь можно устанавливать роли Exchange 2010 на серверы. Итак, вставляем носитель с Exchange 2010 в привод и запускаем установку. У нас откроется начальное окно, где мы выбираем Шаг 3: Выбор языковых опций (Step3: Choose Exchange language option), чтобы можно было установить необходимые языки на серверы.

Рисунок 13: Выбор языка Рисунок 13: Выбор языка

По завершении шага 3 мы можем перейти к Шагу 4: Установка Microsoft Exchange (Step 4: Install Microsoft Exchange).

Рисунок 14: Выбор шага 4 – установка Microsoft Exchange Рисунок 14: Выбор шага 4 – установка Microsoft Exchange

На приветственной странице нажимаем Далее.

Рисунок 15: Приветственная страница Рисунок 15: Приветственная страница

Принимаем условия лицензионного соглашения и нажимаем Далее.

Рисунок 16: Страница лицензионного соглашения Рисунок 16: Страница лицензионного соглашения

Указываем, хотим ли мы отправлять отчеты об ошибках (‘Error Reporting’) или нет, и нажимаем Далее.

Рисунок 17: Страница отчетов об ошибках Рисунок 17: Страница отчетов об ошибках

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

Примечание: В отличие от Exchange 2007, больше нет необходимости указывать, устанавливаете ли вы кластерный почтовый сервер, поскольку функция DAG настраивается, когда вы создаете DAG по завершении установки.

Рисунок 18: Страница выбора типа установки Рисунок 18: Страница выбора типа установки

Теперь нам будет представлена новая страница, которая отсутствовала в мастере установки Exchange 2007. У нас есть возможность указать, будет ли этот сервер иметь выход в интернет. В больших организациях (LORGs) обычно используется один сайт Active Directory с выходом в интернет, и на всех Client Access серверах этого сайта данная опция должна быть включена. Поскольку оба сервера в нашей тестовой среде будут иметь выход в интернет, мы включим эту опцию и укажем FQDN имя, через которое клиентские службы Exchange, такие как Outlook Web App (OWA), Exchange activeSync (EAS) и Outlook Anywhere, будут получать доступ.

Когда все готово, нажимаем Далее.

Рисунок 19: Настройка внешнего домена сервера Client Access Рисунок 19: Настройка внешнего домена сервера Client Access

Теперь указываем, хотим ли мы участвовать в программе по улучшению качества ПО или нет, а затем нажимаем Далее.

Примечание: Вам также нужно установить сертификат SAN, чтобы ваши клиентские службы работали должным образом. Но это не рассматривается в данной статье.

Рисунок 20: Страница программы по улучшению качества ПО Рисунок 20: Страница программы по улучшению качества ПО

Теперь начнется проверка готовности, и надеюсь, вы не столкнетесь с ошибками, которые не позволят вам продолжить. Нажимаем Установить.

Рисунок 21: Страница проверки готовности Рисунок 21: Страница проверки готовности

Роли сервера Exchange теперь будут установлены.

Рисунок 22: Установка ролей сервера Exchange 2010 Рисунок 22: Установка ролей сервера Exchange 2010

После (надеюсь) успешной установки нажмите Готово.

Рисунок 23: Роли сервера Exchange 2010 успешно установлены Рисунок 23: Роли сервера Exchange 2010 успешно установлены

Смена пути базы данных Exchange

Итак, когда Exchange 2010 установлен на серверы, первым шагом будет перемещение и переименование каждой базы данных почтовых ящиков. Для этого запускаем консоль управления Exchange и переходим в узел Mailbox, расположенный под контейнером Конфигурация организации (Organization Configuration). Здесь первой закладкой будет Управление базами данных (Database Management), которую нужно выбрать. В этой закладке нажмите правой клавишей на каждой базе данных почтовых ящиков и выберите опцию пути перемещения базы данных (Move Database) в контекстном меню, как показано на рисунке 1.

Рисунок 1: Перемещение базы данных Рисунок 1: Перемещение базы данных

В мастере Move Database Path измените путь базы данных и журналов, чтобы они находились на дисках LUN, которые мы создали в первой части. Я также предлагаю вам изменить имя каждой базы данных на MDB01.edb и MDB02.edb, как показано на рисунке 2.

Когда все готово, нажмите Переместить.

Рисунок 2: Смена пути для файлов баз данных и журналов Рисунок 2: Смена пути для файлов баз данных и журналов

Когда эти файлы перемещены, нажмите Завершить (Finish), чтобы выйти из мастера (рисунок 3).

Рисунок 3: Путь файлов баз данных и журналов был успешно<br />
изменен Рисунок 3: Путь файлов баз данных и журналов был успешно изменен

Теперь нажмите правой клавишей на базе данных и на этот раз выберите опцию Свойства (Properties). Измените название на имя самого файла edb (в нашем случае MDB01 и MDB02), а затем нажмите OK.

Рисунок 4: Смена имени базы данных Рисунок 4: Смена имени базы данных

Так лучше. Так немного проще определить имена баз данных при использовании оболочки Exchange Management Shell.

Рисунок 5: Изменение путей и имен баз данных Рисунок 5: Изменение путей и имен баз данных

Добавление группы Exchange Trusted Subsystem в серверы Non-Exchange

Поскольку в нашей организации есть всего два сервера Exchange 2010, мы не будем использовать сервер Exchange 2010 Hub Transport (именно эта роль рекомендуется для использования в качестве сервера свидетеля) в качестве сервера свидетеля, а вместо этого воспользуемся традиционным файловым сервером Windows Server 2008 R2. Это означает, что нам нужно добавить группу доверенных подсистем Exchange Trusted Subsystem в группу локальных администраторов файлового сервера. Для этого входим на файловый сервер и открываем Диспетчер сервера (Server Manager). Разворачиваем закладку Конфигурация (Configuration) > Локальные пользователи и группы (Local Users and Groups), а затем открываем Свойства (Properties) для группы администраторов (Administrators).

Рисунок 6: Поиск группы локальных администраторов на<br />
файловом сервере Windows Server 2008 R2 Рисунок 6: Поиск группы локальных администраторов на файловом сервере Windows Server 2008 R2

Вводим группу Exchange Trusted Subsystem в текстовое поле, как показано на рисунке 7, а затем нажимаем OK.

Рисунок 7: Ввод группы Exchange Trusted Subsystem Рисунок 7: Ввод группы Exchange Trusted Subsystem

Еще раз нажимаем OK.

Рисунок 8: Страница свойств группы администраторов Рисунок 8: Страница свойств группы администраторов

Этот шаг необходим только в случае использования non-Exchange сервера в качестве сервера свидетеля. Кстати, не рекомендуется использовать контроллер домена в качестве сервера свидетеля, поскольку в этом случае вы предоставляете группе Exchange Trusted Subsystem многие разрешения в домене Active Directory.

Создание группы DAG

Итак, мы готовы создать саму группу DAG. Это можно сделать с помощью консоли EMC или оболочки EMS. В этой статье мы будем использовать консоль. В узле Mailbox выбираем закладку Database Availability Group, нажимаем правой клавишей где-нибудь в этой области. В контекстном меню выбираем New Database Availability Group, как показано на Рисунок 9.

Рисунок 9: Выбор опции создания новой группы доступности баз<br />
 данных в контекстном меню Рисунок 9: Выбор опции создания новой группы доступности баз данных в контекстном меню

В мастере создания групп Database Availability Group вводим название новой группы DAG. Также указываем сервер свидетеля и каталог свидетеля на этом сервере (рисунок 10). После этого нажимаем Новый (New).

Рисунок 10: Указание имени DAG, а также сервера и каталога<br />
свидетеля Рисунок 10: Указание имени DAG, а также сервера и каталога свидетеля

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

Нажимаем Готово (Finish), чтобы завершить работу мастера (рисунок 11).

Рисунок 11: Мастер Database Availability Group '<br />
заключительная страница Рисунок 11: Мастер Database Availability Group ‘ заключительная страница

Теперь, когда мы создали группу DAG, мы можем добавить два сервера Mailbox в эту группу. Для этого нажимаем правой клавишей на только что созданной группе DAG и выбираем Управление участниками группы (Manage Database Availability Group Membership) в контекстном меню, как показано на рисунке 12 ниже.

Рисунок 12: Выбор опции управления участниками группы DAG Рисунок 12: Выбор опции управления участниками группы DAG

В результате откроется мастер Manage Database Availability Group Membership, в котором мы выбираем опцию Добавить (Add).

Рисунок 13: Мастер Manage Database Availability Group<br />
Membership Рисунок 13: Мастер Manage Database Availability Group Membership

Теперь выбираем два сервера и нажимаем OK.

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

Нажимаем Управление (Manage).

Рисунок 15: Серверы добавлены в группу DAG Рисунок 15: Серверы добавлены в группу DAG

Компонент кластера обхода отказа будет установлен на оба сервера. Затем группа DAG будет создана и настроена должным образом. Это может занять несколько минут, так что запаситесь терпением.

Рисунок 16: Ожидание завершения работы мастера Manage<br />
Database Availability Group Membership Рисунок 16: Ожидание завершения работы мастера Manage Database Availability Group Membership

Если во время добавления серверов в группу DAG у вас в сети нет DHCP, вы получите уведомление, показанное на рисунке 17.

Примечание: Адреса, назначенные DHCP, полностью поддерживаются для целей DAG. На самом деле в группе разработчиков продуктов Exchange считают, что большинство пользователей сочтет удобным использование адресов, назначенных DHCP, для групп DAG. Лично я предпочитаю задавать статические IP адреса, но это мое субъективное мнение.

Рисунок 17: Серверы участники добавлены в группу DAG Рисунок 17: Серверы участники добавлены в группу DAG

Все нормально, мы зададим статический IP адрес для группы DAG прямо сейчас. Последствиями отсутствия IP адреса, настроенного для группы DAG, будут таковы, что ресурсы ядра кластера не смогут быть выведены в режим онлайн, как показано на рисунке 18.

Рисунок 18: Ресурсы ядра кластера находятся в автономном<br />
режиме в консоли Failover Clustering Рисунок 18: Ресурсы ядра кластера находятся в автономном режиме в консоли Failover Clustering

Одним из моментов, недостающих в графическом интерфейсе консоли, является возможность присвоения статического IP адреса группе DAG, поэтому нам нужно выполнить эту задачу с помощью оболочки Exchange Management Shell. Итак, запускаем оболочку и вводим следующую команду:

Get-DatabaseAvailabilityGroup | FL

Это показывает нам, как мы и ожидали, что IP адрес не задан для группы DAG.

Рисунок 19: IP адрес не задан для группы DAG

Чтобы задать статический IP адрес, нам нужно воспользоваться командой Set-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIpAddresses:

Set-DatabaseAvailabilityGroup DAG1 ‘DatabaseAvailabilityGroupIpAddresses 192.168.2.194

Рисунок 20: Статический IP адрес задан для группы DAG Рисунок 20: Статический IP адрес задан для группы DAG

Теперь, когда мы назначили IP адрес группе DAG, ресурсы ядра кластера могут быть выведены в режим онлайн.

Рисунок 21: Ресурсы ядра кластера в режиме онлайн в консоли<br />
Failover Clustering Рисунок 21: Ресурсы ядра кластера в режиме онлайн в консоли Failover Clustering

Добавление копий баз данных Mailbox

Итак, пришло время добавить копии баз данных в две базы данных почтовых ящиков, поскольку в противном случае группа DAG не имеет смысла. Для этого выбираем закладку Управление базами данных (Database Management) в узле Mailbox рабочего центра Organization Configuration. Здесь нажимаем правой клавишей на каждой базе данных и выбираем опцию Добавить копию базы данных почтовых ящиков (Add Mailbox Database Copy) в контекстном меню (рисунок 22).

Рисунок 22: Добавление копий баз данных в каждую базу данных<br />
 Mailbox Рисунок 22: Добавление копий баз данных в каждую базу данных Mailbox

В мастере Add Mailbox Database Copy нажимаем Обзор (Browse).

Рисунок 23: Мастер Add Mailbox Database Copy Рисунок 23: Мастер Add Mailbox Database Copy

Теперь выбираем сервер почтовых ящиков и нажимаем OK.

Рисунок 24: Выбор сервера почтовых ящиков, который будет<br />
хранить копию базы данных Рисунок 24: Выбор сервера почтовых ящиков, который будет хранить копию базы данных

В мастере Add Mailbox Database Copy wizard нажимаем Добавить (Add).

Рисунок 25: Добавление копии базы данных на другой сервер<br />
Mailbox Рисунок 25: Добавление копии базы данных на другой сервер Mailbox

Когда работа мастера успешно завершена, нажмите Готово (Finish) для выхода.

Рисунок 26: Копия базы данных успешно добавлена Рисунок 26: Копия базы данных успешно добавлена

Как видно в консоли Exchange Management Console (рисунок 27), теперь у нас есть здоровая копия активной базы данных.

Рисунок 27: Здоровая копия активной базы данных Рисунок 27: Здоровая копия активной базы данных

Если вы войдете на сервер Mailbox, на который добавили копию базы данных, вы также увидите, что база данных была заполнена (рисунок 28), а файлы журналов были реплицированы (рисунок 29).

Рисунок 28: Файлы журналов реплицированы на сервер Mailbox,<br />
содержащий пассивную копию баз данных Рисунок 28: Файлы журналов реплицированы на сервер Mailbox, содержащий пассивную копию баз данных

Рисунок 29: База данных заполнена на другом сервере Mailbox Рисунок 29: База данных заполнена на другом сервере Mailbox

Теперь выполняем те же шаги для другой базы данных Mailbox.

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

Автор: Генрик Валзер (Henrik Walther)

Генрик Валзер (Henrik Walther)

Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).

Источник: http://www.Redline-Software.com

Comments (0)

Skip to main content