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

Во второй части этого цикла статей о рассмотрении групп доступности баз данных Exchange 2010 Database Availability Groups (DAG) мы подготовили два сервера и установили Exchange 2010 на оба сервера.

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

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

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

Увеличить

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

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

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

Увеличить

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

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

Увеличить

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

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

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

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

Рисунок 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: Поиск группы локальных администраторов на файловом сервере Windows Server 2008 R2

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

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

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

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

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

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

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

Увеличить

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

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

Увеличить

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

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

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

Увеличить

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

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

Увеличить

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

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

Увеличить

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

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

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

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

Увеличить

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

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

Увеличить

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

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

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

Увеличить

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

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

Рисунок 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

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

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

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

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

Увеличить

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

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

Увеличить

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

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

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

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

Увеличить

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

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

Увеличить

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

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

Увеличить

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

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

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

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

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

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