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

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

Пристегнитесь и поехали!

Приостановка и возобновление работы копий баз данных

В тех ситуациях, когда вы запланировали время на сбой/обслуживание или, возможно, вам необходимо ускорить работу базы данных, первым шагом будет приостановка такой используемой базы. Это можно сделать из консоли управления Exchange Management Console (EMC), либо из оболочки управления Exchange Management Shell (EMS). Чтобы выполнить эту задачу через консоль EMC, нужно просто нажать правой мыши на соответствующей копии(ях) базы данных и выбрать опцию приостановки из контекстного меню.

Чтобы сделать это через оболочку EMS, можно воспользоваться следующей командой:

Suspend-MailboxDatabaseCopy 'Identity MDB02\E14EX02

Чтобы возобновить работу копии из EMC, нужно просто нажать правой клавишей на этой базе и выбрать опцию Возобновить копию базы данных (Resume Database Copy).

Если же вы хотите возобновить ее работу через EMS, выполните следующую команду:

Resume-MailboxDatabaseCopy 'Identity MDB02\E14EX02

Перемещение копии активной базы на другого участника группы DAG (также известное как переключение (Switchover))

Когда вы распланировали сбой и вам нужно провести обслуживание члена группы DAG, который содержит одну или более активных копий баз данных, рекомендуется вручную перемещать все копии активных баз данных (то есть выполнять переключение (switchover)) на другой член группы DAG в DAG. Для перемещения копии активной базы на другой член группы DAG с помощью EMC просто нажмите правой клавишей на соответствующей базе (базах) и выберите опцию Переместить активную почтовую базу (Move Active Mailbox Database) в контекстном меню, как показано на рисунке 3.

Это вызовет мастера активации копии базы данных Activate a Database Copy (рисунок 4).

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

После выбора участника группы DAG, на котором будет активирована копия базы данных, нажимаем OK. Затем нужно решить, нужно ли изменять параметры дозвона для подключения базы данных на целевом сервере почтовых ящиков. Как видно на рисунке 6, параметром по умолчанию будет None (ничего не меняет). Можно изменить этот параметр (например, Максимальная доступность (Best Availability)) на параметры Без потерь (Lossless), Best Effort или Best Availability.

Вот описание каждого доступного параметра дозвона подключения баз данных:

• Lossless: (при выборе параметра Lossless база данных не будет подключена автоматически до тех пор, пока все журналы, сгенерированные в копии активной базы данных, не будут скопированы в копию пассивной базы)
• Good Availability: (при выборе параметра Good Availability база будет подключена автоматически тогда, когда длина очереди копии будет меньше или равна 6. Если в очереди копии содержится более шести файлов журналов, база данных не будет подключена)
• Best Effort: (при параметре Best Effort база будет подключена независимо от длины очереди копии. Будьте осторожны при выборе этого параметра, поскольку в этом случае можно потерять большой объем почтовых данных!)
• Best Availability: (при выборе параметра Best Availability база будет автоматически подключена, когда длина очереди копии меньше или равна 12. Если длина очереди копии больше 12, база не будет подключена)

Если нет определенных причин для выбора другого переопределения параметров дозвона подключения базы данных, то оставляем параметр None. Когда вы готовы активировать базу данных на указанном целевом сервере почтовых ящиков, нажмите Переместить (Move).

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

Move-ActiveMailboxDatabase MDB01 -ActivateOnServer E14EX02 -MountDialOverride:None

Заполнение копий баз данных

Возникают ситуации, когда нужно заполнить копию базы данных по тем или иным причинам. Это можно сделать из консоли Exchange Management Console (EMC) и из оболочки Exchange Management Shell (EMS). Давайте посмотрим, как это сделать в EMC.

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

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

После приостановки нажимаем правой клавишей на копии базы еще раз и выбираем опцию Обновить копию базы данных (Update Database Copy).

У нас открывается мастер Update Database Copy (рисунок 10).

Как вы видите, мастер предоставляет нам несколько опций на выбор. У нас есть возможность указать сервер источник, который должен использоваться для заполнения. Это действительно замечательная функция, поскольку мы больше не ограничены заполнением баз из активной копии базы данных, как это было в Exchange 2007 LCR/CCR/SCR.

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

Наконец, мы можем указать, какая сеть DAG будет использоваться для заполнения копии базы данных. Это еще одна замечательная возможность, которая, хотя и присутствовала в Exchange 2007 SP1, но была там довольно непродуманной.

После определения всех параметров нажимаем Обновить (Update), чтобы заполнить копию базы данных. После того, как заполнение завершено, нажимаем Готово (Finish).

Если вы хотите использовать EMS для заполнения копии базы данных, вышеуказанный процесс можно выполнить, сначала приостановив репликацию с помощью команды:

Suspend-MailboxDatabaseCopy 'Identity MDB02\E14EX02

Затем выполните следующую команду для заполнения копии базы данных:

Update-MailboxDatabaseCopy -Identity MDB02\E14EX02

Изменение порта для репликации файлов журналов

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

Get-DatabaseAvailabilityGroup DAG1 'Status | fl

Чтобы изменить используемый порт, нужно воспользоваться Exchange Management Shell (EMS), поскольку данная опция не включена в консоль Exchange Management Console (EMC). Поскольку данный параметр настраивается для каждой группы DAG, нужно воспользоваться командой Set-DatabaseAvailabilityGroup.

Например, чтобы сменить порт для DAG в нашей тестовой среде на TCP порт 7580, нужно воспользоваться следующей командой:

Set-DatabaseAvailabilityGroup DAG1 -ReplicationPort 7580

Когда порт изменен, мы можем проверить новые параметры с помощью:

Get-DatabaseAvailabilityGroup DAG1 'Status | fl ReplicationPort

Теперь при обновлении копии базы данных мы видим, что используется порт TCP/7580 (ниже я выполнил команду Netstat 'an во время обновления копий баз данных.

Сетевое сжатие файлов журналов

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

Доступными значениями здесь будут следующие параметры:

• Отключено (Disabled) (отключено для всех сетей)
• Включено (Enabled) (включено для всех сетей)
• InterSubnetOnly (включено только для взаимодействий между подсетями)
• SeedOnly (включено только для заполнения)

Если мы, например, захотим включить сетевое сжатие для копирования и заполнения файлов журналов во всех сетях группы DAG в нашей тестовой среде, нам нужно воспользоваться следующей командой:

Set-DatabaseAvailabilityGroup DAG1 -NetworkCompression Enabled

Когда сжатие включено для заполнения и репликации файлов журналов, следует ожидать примерно 30% сжатия. Как вы видите, нет причин для отключения сетевого сжатия, если только вы не используете WAN/сетевой оптимизатор стороннего производителя, который не поддерживает сетевое сжатие DAG.

Сетевое шифрование файлов журналов

С помощью групп DAG в Exchange 2010 теперь есть собственная поддержка шифрования действий заполнения и репликации файлов журналов. В Exchange 2007 файлы журналов копируются по незащищенному каналу, если не настроен IPsec. DAG использует возможности шифрования сервера Windows Server 2008/R2, то есть группа DAG использует Kerberos аутентификацию между каждым участником группы DAG. Сетевое шифрование является свойством самой группы DAG, а не сети DAG. Доступными параметрами свойств сетевого шифрования являются следующие опции:

• Отключено (Disabled) (сетевое шифрование не используется),
• Включено (Enabled) (сетевое шифрование включено для заполнения и репликации на всех сетях, связанных с DAG),
• InterSubnetOnly (параметр по умолчанию, означающий, что сетевое шифрование используется только в подсетях)
• SeedOnly (сетевое шифрование используется для заполнения во всех сетях DAG).

Параметром по умолчанию является InterSubnetOnly.

Если вы хотите изменить параметры сетевого шифрования, можно воспользоваться командой Set-DatabaseAvailabilityGroupcmdlet. Например, если нужно включить сетевое шифрование для копирования и заполнения логов во всех сетях, нужно воспользоваться следующей командой:

Set-DatabaseAvailabilityGroup -identity DAG1 -NetworkEncryption Enabled

Настройка времени запаздывания воспроизведения и усечения (Replay & Truncation Lag Time)

Функция Standby Continuous Replication (SCR), впервые представленная в Exchange 2007 SP1, дала нам возможность репликации одной или нескольких баз данных с отдельного сервера почтовых ящиков, кластера CCR, или кластера SCC в целевой отдельный сервер почтовых ящиков или аварийный кластер (CCR или SCC кластер, где установлена только роль пассивного кластерного сервера почтовых ящиков). SCR можно было использовать для локальной репликации групп хранения в центр данных, или удаленной репликации на серверы, расположенные во второстепенном или резервном центре данных.

Помимо возможности репликации данных в несколько целей для каждой группы хранения, SCR также представила концепцию времени запаздывания воспроизведения и усечения (replay lag time и truncation lag time). С помощью времени запаздывания воспроизведения можно было настраивать службу репликации Microsoft Exchange Replication на ожидание в течение определенного периода времени, прежде чем файлы журналов, которые были скопированы с источника SCR в SCR цель, воспроизводились. По умолчанию этот параметр принимал значение 24 часа, и это значение можно было увеличивать до 7 дней (если значение составляло 0 секунд, время запаздывания включало 50 файлов журналов, чтобы перезаполнение не требовалось в случае обхода отказа с потерями). Идея времени запаздывания воспроизведения заключалась в том, чтобы брать базу данных из прошлого, которую можно было затем использовать для восстановления в том случае, если активная копия базы данных на исходных серверах SCR подвергалась логическому повреждению. В этом случае можно было остановить репликацию до того момента, как логическое повреждение будет скопировано в целевой сервер SCR, и тем самым предотвратить потерю данных.

Время запаздывания усечения можно было использовать для указания того, как долго должна служба репликации Microsoft Exchange Replication ждать, прежде чем усекать (удалять) файлы журналов, которые копировались в целевой сервер SCR и воспроизводились в копии базы данных. Максимально разрешенным значением было 7 дней, а минимальным - 0 секунд, что полностью убирало задержку усечения. С помощью времени запаздывания усечения можно было восстанавливаться после сбоев, влиявших на файлы журналов на исходных серверах SCR.

DAG также поддерживает время запаздывания воспроизведения и усечения, которые известны нам из SCR в Exchange 2007 SP1. Принцип их работы очень похож, хотя управляются эти параметры через новую команду (Set-MailboxDatabaseCopy).

Эти функции были немного усовершенствованы в Exchange 2010. Например, время задержки воспроизведения теперь может принимать максимальное значение до 14, а не до 7 дней, как это было в Exchange 2007 SP1. Также следует помнить, что в отличие от SCR в Exchange 2007 SP1, время задержки воспроизведения в Exchange 2010 не имеет жестко прописанного в коде времени задержки 50 файлов журналов (даже когда это значение установлено на 0 секунд).

Как видно из рисунка 23, по умолчанию время запаздывания воспроизведения и усечения отключены.

Цель этих параметров в Exchange 2010 практически такая же, что и в SCR в Exchange 2007 SP1, а именно защита от логических повреждений базы данных и хранилища. Интересным и новым в Exchange 2010 является то, что эти параметры можно использовать в сочетании с функцией legal hold и т.д.

Я не буду вдаваться в дальнейшие подробности об отсроченных копиях баз данных в этой статье. Вместо этого я напишу отдельную статью на эту тему здесь на MSExchange.org.

Блокирование копии базы данных от активации

Возникают ситуации, когда вам требуется заблокировать пассивную копию базы данных (или даже сервер) в группе DAG от изменений активации (изменений в активной копии базы данных). Хорошим моментом является то, что группа Exchange Product продумала такой тип ситуаций. Теперь вы можете это сделать с помощью, так называемой, политики активации. Для этого невозможно использовать консоль EMC, но можно воспользоваться оболочкой EMS, для этой цели нужно использовать следующую команду Suspend-MailboxDatabaseCopy. Да, все верно, эта команда обычно используется для приостановки репликации копии базы данных, но при ее выполнении со специальным ActivationOnly параметром, вы можете заблокировать базу данных от изменения активной копии базы во время обхода отказа. Например, если вам нужно заблокировать MDB01 на E14EX02 от активации во время обхода отказа, нужно воспользоваться следующей командой:

Suspend-MailboxDatabaseCopy 'Identity MDB01\E14EX02 -ActivationOnly

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

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

Resume-MailboxDatabaseCopy 'Identity MDB01\E14EX02

Итак, что если я хочу заблокировать все базы данных на сервере в группе DAG? Придется ли мне в таком случае выполнять вышеуказанную команду для всех копий баз данных на этом сервере? К счастью, нет. У нас есть подобная команда, которая работает на уровне сервера. Если вы хотите заблокировать участника группы DAG, воспользуйтесь командой Set-MailboxServer с параметром DatabaseCopyAutoActivationPolicy Blocked.

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

Set-MailboxServer 'Identity E14EX02 - DatabaseCopyAutoActivationPolicy Blocked

Чтобы разблокировать копии баз данных, я заменю 'Blocked' на 'Unrestricted':

Set-MailboxServer 'Identity E14EX02 - DatabaseCopyAutoActivationPolicy Unrestricted

Также есть опция 'IntrasiteOnly', которая позволяет копиям баз данных активироваться на одном сайте Active Directory .

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

Однако страхи в сторону, это, конечно же, не последняя статья о группах DAG.