Microsoft Exchange Server 2010: Управление копиями баз данных

Термин «копия базы данных» говорит сам за себя — это и есть копия активной базы данных. Однако она часто хранится на другом Exchange Server, но в той же группе доступности баз данных (database availability group, DAG). При первоначальном конфигурировании Exchange происходит отправка файла базы данных на другой сервер. После ее завершения Exchange Server 2010 начинает реплицировать файлы журнала этой базы данных по сети на другой сервер.

Относительное местонахождение пассивной копии базы данных идентично местонахождению активной копии. Например, исходная база данных Exchange Server 2010 Mailbox Server может находиться в каталоге C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1444276156. Если активизировать эту копию базы данных на сервере, то на втором сервере создастся такой же каталог.

Процесс копирования базы данных во второе местонахождение называют «посевом» (seeding). Наилучший подход, как с точки зрения производительности, так и с точки зрения аварийного восстановления, — использовать для баз данных Exchange отдельные диски. Чтобы после настройки Mailbox Database 1444276156 для хранения ее информации использовался отдельный диск G:\, сконфигурируйте копию базы данных следующим образом:

1. Убедитесь, что на целевом сервере (сервере, который будет содержать копию базы данных) имеется столько же места, сколько на исходном сервере. Кроме того, в нашем примере целевой сервер должен иметь отдельный диск G:\.
2. Откройте Exchange Management Console (EMC), раскройте узел Microsoft Exchange On-Premises (EXMBX01), затем раскройте контейнер Organization Configuration и щелкните узел Mailbox. Выберите вкладку Database Management.
3. Выберите Mailbox Database 1444276156. В нижней части панели результатов вы увидите одну (активную) копию, расположенную на первом Exchange Server EXMBX01. Щелкните Mailbox Database 1444276156 правой кнопкой и выберите Add Mailbox Database Copy…
4. В мастере Add Mailbox Database Copy выберите Browse, чтобы задать Mailbox Server, который будет содержать копию базы данных. Activation Preference Number задает порядок, в котором Exchange будет превращать пассивные копии в активные при сбоях предыдущих активных копий. Конечно, это имеет смысл, только если у вас задано несколько пассивных копий. Щелкните Add для продолжения. (В дальнейшем вы можете подробнее прочитать об Activation Preference Number и о том, что происходит, когда база данных становится активной.)
5. Exchange скопирует файл базы данных Mailbox Database 1444276156.edb на целевой сервер и запустит репликацию. Это займет определенное время, зависящее от размера файла базы данных.
6. Когда копирование базы данных и активизация репликации завершатся, щелкните Finish.

По окончании процесса зайдите на целевой сервер Exchange. Вы увидите, что на этом сервере (в нашем примере на диске G:\) создался каталог Mailbox Database 1444276156, в котором хранится копия базы данных. Также вы увидите, что файлы журнала базы данных реплицируются в этот каталог.

Если Exchange Server использует много баз данных, допустимый альтернативный вариант — применение точек монтирования (mount points). В этом случае Server Manager монтирует все диски данных в каталоги сервера, например, F:\DB01, F:\DB02, F:\DB03 и т.д.

В среде Exchange Server 2007 Cluster Continuous Replication (CCR) активный сервер, кроме того, доставляет файлы журнала на пассивный сервер. Пассивный сервер, в свою очередь, загружает файлы журнала в свою копию базы данных. Однако пассивный сервер пассивен по-настоящему. Сервис, отвечающий за функционирование базы данных и файлов журнала (store.exe), не выполняется. Выполняется только сервис репликации. При восстановлении после сбоя пассивный узел должен запустить все сервисы Exchange. Перед этим вы должны смонтировать все базы данных.

В Exchange Server 2010 сервис уже выполняется и базы данных уже смонтированы на всех компьютерах DAG. Поэтому восстановление базы данных после сбоя гораздо идет быстрее, а значит, время простоя при сбое гораздо короче.

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

1. Войдите на Exchange Server и откройте EMC.
2. Раскройте узел Exchange On-Premises (SERVER). Раскройте лист Organization. Щелкните Mailbox, а затем щелкните вкладку Database Management.
3. Все базы данных вашей среды Exchange Server 2010 будут показаны в верхней части панели результатов. Щелкните правой кнопкой базу данных, которую вы собираетесь переместить (конечно, это база данных с несколькими копиями).
4. Выберите Move Active Mailbox Database в контекстном меню.
5. В мастере Move Active Mailbox Database выберите Browse, чтобы задать другой сервер, на который вы перенесете Active Copy.
6. Щелкните кнопку Move, чтобы перенести активную копию (Active Copy) базы данных на выбранный вами сервер.

Онлайновая операция Move-Mailbox

Онлайновая операция Move-Mailbox — новая возможность Exchange Server 2010. В предыдущих версиях Exchange Server почтовый ящик при перемещении с одного сервера на другой переходил в офлайновый режим. Из-за этого пользователи не могли обращаться к своим данным и извлекать из очереди входящие сообщения. Возникали ситуации, когда очень большие (5 ГБ и более) почтовые ящики при переносе оставались в офлайновом режиме более часа. Конечно, все это не делало систему особо удобной.

Теперь появилась новая онлайновая операция Move-Mailbox— она называется New-MoveRequest — время нахождения почтового ящика в офлайновом режиме сократилось до секунд. Это существенно облегчит жизнь пользователям.

Вот, что происходит при выполнении New-MoveRequest, когда почтовый ящик переносится с одного сервера (EXBMX01) на другой сервер той же организации (EXMBX11):

1. Exchange создает на Mailbox Server EXMBX11 пустую копию почтового ящика пользователя, действуя просто как наследник операции Move-Mailbox. Но текущий почтовый ящик (на EXMBX01) вместо перехода в офлайн остается в онлайновом режиме. Это по-прежнему основной почтовый ящик клиента. Новые сообщения, как и раньше, поступают в этот почтовый ящик.
2. Содержимое старого почтового ящика копируется в почтовый ящик на сервере EXMBX11, и этот почтовый ящик синхронизируется со старым.
3. Когда в старый ящик поступают сообщения, они сразу же копируются в новый почтовый ящик.
4. Когда оба почтовых ящика синхронизированы, старый почтовый ящик переводится в офлайновый режим и последние оставшиеся сообщения копируются в новый почтовый ящик.
5. Active Directory обновляет местонахождение почтового ящика на новое, и почтовый ящик снова переводится в онлайновый режим. Возможно, пользователю придется перезапустить клиент Outlook, но Client Access Server должен автоматически определить, что почтовый ящик перенесен, и начать работать с новым местонахождением. В любом случае, пользователь сможет продолжить работу буквально через несколько секунд.

Онлайновая операция online Move-Mailbox работает не только между серверами Exchange Server 2010 Mailbox, но и при переносе почтовых ящиков с Exchange Server 2007 SP2 на Exchange Server 2010. К сожалению, перенос с Exchange Server 2010 на Exchange Server 2007 остался офлайновым. Аналогично перенос почтовых ящиков с Exchange Server 2003 на Exchange Server 2010 всегда офлайновый.

Резервирование и восстановление

Exchange Server 2010 работает только под управлением Windows Server 2008 и Windows Server 2008 R2. Значит, вы не можете использовать бесплатную утилиту NTBackup для Windows Server 2003, чтобы резервировать Mailbox Databases, с которыми работает Exchange Server 2010.

В любом случае NTBackup будет создавать лишь «потоковые резервные копии» (streaming backups) данных Exchange, но не резервные копии Volume Shadow Copy Service (VSS) баз данных Exchange. Exchange Server 2010 содержит подключаемый модуль для Windows Server Backup (WSB), что делает возможным резервирование баз данных Exchange Server 2010 с помощью VSS.

VSS или резервирование снимка

С выпуском Exchange Server 2010 Microsoft перешла от традиционного онлайнового потокового резервирования к резервированию с помощью VSS (или «резервированию снимка» — snapshot backup). Снимок — это просто образ базы данных, созданный в определенный момент. Можно задействовать его для отката базы данных назад в случае аварии. VSS (в Windows Server 2003 и более поздних версий) предоставляет инфраструктуру для создания таких моментальных образов — так называемых теневых копий (shadow copies). Существует два вида теневых копий:

• Clone (Full Copy или Split Mirror): полное зеркало, поддерживаемое до тех пор, пока приложение или администратор не «разобьет» его. С этого момента оригинал и его клон становятся полностью независимыми друг от друга и копия, по сути, замораживается во времени.
• Copy on Write (Differential Copy): теневая копия создается как разностная (differential), а не полная копия исходных данных. При использовании Copy on Write перед перезаписью исходных данных делается их теневая копия. Резервная копия состоит из данных теневой копии в сочетании с данными, находящимися на старом месте. Для восстановления исходных данных нужно и то, и другое.

Инфраструктура VSS состоит из следующих компонентов:

• Инициатор запросов (requestor) — ПО, которое вызывает VSS и создает, отделяет от оригинала (breaks) или удаляет теневую копию. Как правило, инициатор запросов — это приложение, выполняющее резервирование.
• Компонент записи (writer) — часть ПО, предоставляемая производителем приложения. В нашем случае он предоставляется Microsoft Exchange Server. Компонент записи отвечает за создание целостного моментального образа, «замораживая» состояние Exchange Server в этот момент. Заметьте: компонент записи для Exchange входит в стандартную поставку Exchange Server 2003 и более поздних версий.
• Провайдер (provider) — интерфейс к моментальному образу. Это может быть массив хранения (аппаратный провайдер) или ОС (программный провайдер). В Windows Server 2003 и более поздних версий функционал программного провайдера для VSS включен в стандартную поставку.

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

• Инициатор запросов (приложение, выполняющее резервирование) отправляет VSS команду создать теневую копию Storage Groups.
• Сервис VSS отправляет компоненту записи Exchange команду подготовитьcя к резервированию снимка.
• Сервис VSS отправляет соответствующему провайдеру хранения команду создать теневую копию Exchange Storage Group. Провайдером хранения может быть как аппаратный провайдер хранения, так и стандартный провайдер хранения Windows.
• Компонент записи Exchange временно останавливает Storage Group и переводит их в режим «только для чтения». Кроме того, сохраняются изменения из файла журнала, чтобы обеспечить включение всех данных в резервный набор. В результате перед созданием теневой копии (следующей операцией) происходит задержка на пару секунд. Все запросы ввода-вывода, требующие запись, ставятся в очередь.
• Теперь Exchange создает теневую копию.
• Сервис VSS освобождает Exchange Server, позволяя ему продолжить свою обычную работу, и все запросы записи, поставленные в очередь, выполняются.
• Сервис VSS запрашивает у компонента записи Exchange подтверждение, что все запросы записи были успешно приостановлены во время создания теневой копии. Если это не так, значит, целостность теневой копии потенциально может оказаться нарушенной, поэтому теневая копия удаляется и инициатор запросов уведомляется об этом. Инициатор запросов может повторить создание теневой копии или сообщить, что операция потерпела неудачу.
• Если все прошло успешно, инициатор запросов создает разностный или полный снимок и затем проверяет целостность резервного набора (копии-клона). Если с целостностью копии-клона все в порядке, инициатор запросов информирует Exchange Server о том, что  резервная копия успешно создана и файлы журнала можно удалить.

Операции 1 – 7 обычно занимают около 10 секунд — это время необходимо для создания снимка. Однако это не время создания резервной копии. Приложение, выполняющее резервирование, все равно должно создать резервную копию на другом диске или ленте, и на это могут потребоваться часы, в зависимости от размера баз данных.

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