Exchange Server 2003 и VSS

Новые методы обеспечения восстановления и отказоустойчивости

Обмену сообщениями и средствам обеспечения совместной работы пользователей отводится в Microsoft Exchange Server все более важная роль, и это заставляет администраторов и проектировщиков искать новые пути расширения возможностей восстановления и увеличения отказоустойчивости своих систем. При этом изготовители аппаратного и программного обеспечения постоянно совершенствуют соответствующие технологии для достижения более оперативного восстановления серверных данных и приложений. Снимок тома (Volume Snapshot) и клонирование тома (Volume Cloning) — примеры таких технологий. Они присутствуют в решениях самых разных производителей аппаратного и программного обеспечения, от законченных продуктов типа Snapshot Manager для Exchange до интегральных утилит для восстановления Exchange. В недавнем прошлом, независимо от того, как эти технологии распространялись, в продуктах корпорации Microsoft ни технология snapshot, ни cloning не поддерживалась. В Таблице приведены статьи Microsoft, в которое обсуждались вопросы поддержки снимков и клонирования для серверов Exchange Server 2000, Exchange Server 5.5 и Exchange 4.0. Однако только после появления Exchange Server 2003 Microsoft вводит понятие службы Volume Shadow Copy Service (VSS), которая делает технологии snapshot и cloning неотъемлемой частью системы, а администраторы получают возможность использовать их. Рассмотрим VSS подробнее и выясним, что можно сделать с помощью этой службы.

Volume Snapshot и Volume Cloning

Хотя эти технологии нельзя назвать новыми, на платформе Windows они появились совсем недавно. Технологии Cloning и Snapshot связаны с Business Continuance Volumes (BCV) — техникой дублирования данных и создания моментальных (point-in-time) копий. На первый взгляд эти технологии могут показаться одинаковыми, но они очень различаются в исполнении.

Volume Snapshot. Volume Snapshot (или Copy-On-Write Snapshot) — это репрезентативное отображение метаданных определенных блоков тома в момент создания снимка. Например, при создании моментальной копии тома базы данных Exchange в ней будут представлены дисковые блоки, из которых состоит база данных Exchange и все остальные файлы тома на момент создания снимка. Следовательно, после создания моментальной копии необходимо каким-то образом поддерживать в неприкосновенности оригинальные блоки тома моментальной копии. Изменения блоков тома нужно копировать в другое место в пуле хранения. С точки зрения Exchange такое требование означает, что, если была создана мгновенная копия тома, на котором размещена база данных Exchange, а затем какая-либо страница базы данных Exchange была изменена, система хранения, поддерживающая VSS, скопирует измененные блоки в специальную область изменений (diff-область) в пуле хранения, выделенную из незанятого пространства. Система как бы «консервирует» оригинальное подмножество блоков тома, которые представлены в моментальной копии. После создания снимка бизнес-данные будут состоять из комбинации оригинальных неизмененных блоков снимка и новых блоков данных. Моментальная копия остается неприкосновенной и представляет данные в том состоянии, в котором они находились на момент создания снимка. Моментальные копии создаются относительно быстро и просто — система хранения VSS формирует отображение блока тома, и снимок готов. Но поскольку технология Copy-On-Write Snapshot не обеспечивает полностью зарезервированную копию данных и также подвержена дисковым сбоям, предпочтительно все же «клонирование». Восстановление с использованием моментальных копий может быть проблематичным, если базовый том разрушен или испорчен, так как для восстановления оригинального тома администратору придется выполнить определенную последовательность действий.

Volume Cloning. Как и Volume Snapshot, технология Volume Cloning появилась не сегодня. «Клонирование» пришло из технологии RAID уровня 0+1. Клон представляет собой дополнительный член зеркального набора RAID 0+1. Например, в распоряжении администратора имеется набор с тремя зеркальными дисками RAID 0+1, это двучленный набор RAID 0+1. Добавив еще три нормализованных диска к существующему набору RAID 0+1 из шести дисков, можно создать трехчленный зеркальный набор (т. е. тройное зеркало из девяти дисков). Добавление в зеркальный набор других членов можно продолжить. Создав многочленные зеркальные наборы, а затем отделив члены из набора, получаем клоны. Поскольку существующие бизнес-данные могут иметь несколько зеркальных копий, некоторые из них можно использовать для создания моментальных копий данных. В отличие от Snapshot, клон представляет собой полностью автономную копию данных. Для того чтобы создать клон, нужно просто выделить один или более членов зеркального набора RAID 0+1 из общего набора. В результате получится зеркальный набор данных, который используется действующим приложением (т. е. двучленный массив RAID 0+1), и клоны (одночленные наборы), образующиеся при отделении от общего набора (см. Рисунок 1). В случае потери или разрушения данных для восстановления системных данных применяется клон. Для этого его логический номер LUN делают основным. Поскольку клоны являются полной копией данных, эту технологию очень удобно использовать в качестве механизма быстрого восстановления данных.

Рисунок 1. Создание клона тома из массива RAID 0+1

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

Основы VSS

Поскольку Volume Snapshot и Volume Cloning имеют ограниченное применение в среде Windows, операционная система и приложения Windows не могут в полной мере использовать преимущества рассматриваемых технологий. Разработчики аппаратных и программных средств создавали свои Snapshot- и Cloning-решения с очень ограниченными возможностями интеграции с Windows и приложениями для нее. В результате основную работу по продвижению подобных решений взяли на себя независимые разработчики.

Microsoft вложила значительные средства в технологию хранения, в том числе VSS, в операционной системе Windows 2003. С помощью VSS предпринимается попытка решения ключевой проблемы — постоянно увеличивающийся период времени, отводимый под резервирование и восстановление данных. Учитывая недорогую по сегодняшним меркам дисковую память и растущие запросы приложений к системе хранения, администраторы систем постоянно вынуждены помнить о непрерывном росте наборов данных и о недостаточно быстро прогрессирующих возможностях восстановления в случае аварийных ситуаций. В распоряжении администратора имеется множество методов, позволяющих отслеживать ситуацию, например, с помощью программ мониторинга дискового пространства (архиваторы, иерархические системы хранения Hierarchical Storage Management, HSM, квотирование), однако, что действительно необходимо, так это повышение скорости резервирования и (особенно) скорости восстановления данных. Если удастся повысить скорость создания резервных копий с 10 до 20 Гбайт/ч, окно резервирования сократится на 50%.

VSS затрагивает один очень важный аспект — в настоящее время огромный объем данных находится в оперативном режиме. Например, рассмотрим файловый сервер, на котором хранятся тысячи файлов пользователей и который должен работать по схеме 24х7. Каждый раз при создании резервной копии некоторые файлы будут открыты. Чтобы выполнить резервное копирование, нужно воспользоваться одним из трех способов. Во-первых, можно остановить определенную службу или сессию и закрыть открытые файлы. Во-вторых, можно пропустить открытые файлы и понадеяться, что они не будут потеряны или испорчены до запуска следующего задания в процессе создания резервной копии. В-третьих, и это лучше всего, можно создать моментальный снимок данных и использовать его при необходимости в качестве базы для восстановления.

VSS обеспечивает условия для использования технологий снимка и клонирования на платформе Windows. Если говорить более конкретно, то VSS предоставляет службы, необходимые для построения инфраструктуры, на базе которой операционная система, приложения и фирмы-поставщики (Hewlett-Packard, EMC, VERITAS Software, LEGATO Systems) смогут внедрять свои технологические решения.

VSS выполняет три основные задачи: обеспечение синхронизации приложений, в том числе синхронизации данных приложения, распределенных по нескольким томам; обнаружение и нумерация снимков и клонов (соответствующий механизм носит название Shadow Copies); создание условий, при которых разработчики аппаратного и программного обеспечения могут включать собственные провайдеры (или Provider) для создания Shadow Copy. Имея в виду названные цели, VSS в Windows 2003 позволяет поставщикам программного и аппаратного обеспечения использовать свои провайдеры, а разработчикам приложений — свою копию Shadow Copy, которая содержит метаданные на основе XML (носит название Writer). Поставщикам программ резервирования VSS дает возможность создавать приложения (Requestor), которые смогут инициировать операции резервирования и восстановления, тем самым повышая уровень производительности этих компонентов до уровня общей инфраструктуры. На Рисунке 2 показана архитектура VSS Windows 2003.

VSS Provider. VSS предоставляет API, который позволяет производителям программного обеспечения приспосабливать свои решения к технологии VSS. Чтобы технологии клонирования или снимка смогли заработать в среде VSS, производитель программного обеспечения должен написать провайдер — компонент для обслуживания томов и создания клонов и моментальных копий в соответствии со специфическими особенностями технологии и ее конкретной реализацией у независимого поставщика. Обычно провайдер представляет собой процесс (часть которого работает в режиме ядра, часть — в режиме пользователя), отражающий физическую специфику создания теневой копии Shadow Copy и предоставляющий необходимые данные для операционной системы или приложений. Независимый поставщик должен написать свой провайдер независимо от того, на какой основе реализуется его решение — аппаратной или программной. Если провайдер реализует программное решение, то это обычно процесс, запущенный в режиме пользователя, и драйвер устройства, работающий в режиме ядра. Детали аппаратного и программного решения и реализации провайдера остаются на усмотрение поставщика, достаточно того, что он придерживается правил создания с учетом требований VSS. В состав Windows 2003 входит программный провайдер, реализованный в виде Copy-On-Write Snapshot.

VSS Requestor. Поставщики систем резервирования и аварийного восстановления могут создавать приложения, в которых учтены различные аспекты VSS — архитектура, API и правила написания программного кода. Для этого независимому поставщику необходимо разработать Requestor — автоматизированный процесс или же приложение, которое будет опрашивать один либо несколько наборов копий Shadow Copy с одного или нескольких томов. Requestor — это основной процесс, который связывается с интерфейсом копирования Shadow Copy, чья задача — координировать активность процессов Requestor, провайдера и Writer. Requestor, кроме того, связывается с Writer для получения информации о компонентах резервирования, файлах и метаданных, обслуживаемых Writer. Именно Requestor устанавливает, для каких томов следует создавать Shadow Copy в соответствии с процедурой резервирования. Requestor в состав Windows 2003 не входит.

VSS Writer. Наиболее важная составляющая VSS — приложения. В приложении необходимо очень внимательно описать процедуру восстановления, которая зависит от применяемой технологии, учесть особенности реализации самого приложения, а также требования и граничные условия процедуры аварийного восстановления. Так, например, из-за того, что Exchange использует процессор базы данных на основе обработки транзакций, его требования могут считаться уникальными, даже если сравнивать похожие между собой приложения (Microsoft SQL Server, Oracle). Writer — это код и относящиеся к нему данные, встроенные в приложения; компоненты этих приложений совместимы с VSS. Writer создается с учетом взаимодействия с интерфейсом Shadow Copy и позволяет приложениям подготавливать данные, отмечать ситуацию, связанную с операциями ввода/вывода, и обрабатывать ее. Writer гарантирует, что на томе не будет выполнена ни одна операция записи, пока провайдер создает копию Shadow Copy. Через интерфейс VSS Writer отвечает на запросы от Requestor, пересылая ему метаданные, в которые включено подробное описание процедуры Shadow Copy, проведение которой от имени конкретного приложения запросил Requestor.

Операция резервирования, в которой используются возможности VSS, — это тщательно организованный процесс взаимодействия различных компонентов в рамках архитектуры VSS. На Рисунке 3 показана структурная схема процедуры резервного копирования с использованием технологии VSS.

Exchange 2003 поддерживает VSS

Чтобы такое приложение, как Exchange, смогло использовать возможности VSS, необходимо, чтобы в состав приложения входил компонент Writer. Поскольку Microsoft не планирует разрабатывать Writer для Exchange 2000, Exchange 5.5 или Exchange 4.0, поддержка VSS в перечисленных версиях почтового сервера не предусмотрена. Однако сервер Exchange 2003, сервер-спутник Windows 2003, осуществляет поддержку VSS для процессов Store Backup и Store Recovery. Для Exchange 2003 специалисты Microsoft встроили функциональность Writer в процесс Store. Компонент Writer обеспечивает необходимое взаимодействие с Requestor для инициации процедуры резервного копирования Exchange 2003.

Exchange 2003 и резервное копирование с использованием VSS

Традиционный подход к резервному копированию в Exchange сфокусирован на создании резервной копии базы данных четырех возможных типов: полной (Full), инкрементальной (Incremental), разностной (Differential) и зеркальной (Copy). Однако компонент Exchange 2003 Writer поддерживает только один тип — Full Backup — на уровне группы хранения Storage Group (SG). VSS участвует в создании только полной резервной копии на уровне всей группы хранения, даже когда Exchange Writer обращается к индивидуальной базе данных как к отдельному объекту. VSS использует вызов AddComponent для добавления каждого компонента базы данных к набору Shadow Copy, что в случае Full Backup соответствует целой группе SG (т. е. база данных плюс файлы транзакций). При создании Full Backup группы SG компонент VSS участвует в создании полной версии Shadow Copy для всех томов — Shadow Copy будет содержать базы данных и файлы журналов транзакций, относящиеся к данной SG. Кроме того, происходит очистка журналов транзакций после успешного создания и резервирования Shadow Copy. Для очистки файлов транзакций в наборе Shadow Copy должны находиться все базы данных, поэтому Microsoft намеревается использовать описание метаданных Exchange Writer, чтобы Requestor приложений мог поддерживать в наборе Shadow Copy только полные копии, состоящие из всех компонентов SG (баз данных или журналов транзакций).

Exchange 2003 и восстановление с использованием VSS

Хотя VSS-резервирование для Exchange 2003 выполняется на уровне группы хранения, восстановить индивидуальные базы данных можно из набора Shadow Copy этой SG. Восстановление SG в Exchange 2003, основанное на VSS, удобно в том случае, когда информация в одной или нескольких базах данных SG утеряна или испорчена, но текущие файлы журналов транзакций на диске остаются; когда с диска пропадают журналы транзакций, но цела база; когда и файлы баз данных, и журналы транзакций в SG утеряны или испорчены.

В контексте Exchange 2003 и VSS только приложение резервного копирования несет ответственность за восстановление данных на диске. Именно процессор базы данных Exchange — не Requestor — отвечает за восстановление данных до непротиворечивого актуального состояния за счет повторного выполнения транзакций. Для этого процессор базы данных активизирует существующие процедуры восстановления. После того как VSS-приложение восстановит файлы транзакций и базы данных, Exchange 2003 повторно монтирует и перезапускает SG, и только после этого процессор базы данных инициирует запуск процедуры возврата системы в исходное состояние (процедуры Recovery). Процессор базы данных обнаруживает, что состояние базы не соответствует последним записям журнала транзакций, расположенного на диске, и начинает процедуру Recovery.

Всего существует три сценария восстановления данных Exchange 2003, но им соответствуют только две процедуры. Процедуры Roll-Forward Recovery и Point-In-Time Recovery — суть одно и то же, если рассматривается случай разрушения только журналов транзакций SG или же одновременно и баз данных, и журналов транзакций SG. Потеря файлов журналов транзакций — катастрофическое событие для Exchange 2003, требуется полное восстановление SG. Так или иначе, в процессе работы процедуры Recovery выполняются следующие шаги.

• Компонент Requestor приложения резервирования через Exchange Writer и соответствующие вызовы API переводит SG в автономное состояние.
• Приложение резервирования выполняет процедуру VSS Recovery для томов из набора SG Shadow Copy:
  • если для SG сконфигурирован только один номер логического устройства (LUN), Exchange восстанавливает все базы данных, кроме тех, которые не повреждены;
  • если для SG сконфигурировано несколько LUN, тогда Exchange восстанавливает из набора Shadow Copy только те LUN, чьи базы данных действительно нуждаются в восстановлении.
• Exchange выполняет восстановление Extensible Storage Engine (ESE) и повторно исполняет пригодные для использования транзакции с учетом восстанавливаемых баз данных и в зависимости от типа восстановления - Roll-Forward Recovery или Point-In-Time Recovery.
• Компонент Requestor приложения резервирования через Exchange Writer и соответствующие вызовы API переводит SG в активное состояние.

Roll-Forward Recovery. Во время работы Roll-Forward Recovery в SG одна или несколько баз данных могут оказаться поврежденными, тогда как журналы транзакций на сервере на момент запуска Recovery будут невредимы. В этом случае можно селективно восстановить каждую испорченную базу данных из SG Full Backup. В контексте VSS нужно выбрать из SG Backup только те компоненты базы данных, которые относятся к восстанавливаемым базам данных. Приложение резервирования проводит восстановление этих баз, а Exchange запускает процедуру Recovery и, повторно исполняя соответствующие транзакции, делает состояние баз таким, каким оно было, когда формировалась моментальная копия диска. Это процедура жесткого восстановления Exchange. Режим Roll-Forward Recovery позволяет восстановить резервную копию данных, как и данные (по существу — транзакции), которые были накоплены с момента последнего запуска процедуры резервирования.

Point-In-Time Recovery. Когда том SG, на котором расположен какой-либо файл транзакций, разрушается либо пропадает или же это происходит с файлами транзакций вместе с несколькими или сразу со всеми базами данных SG, приходится восстанавливать файлы транзакций из предыдущей резервной копии вместе со всеми базами данных, скопированными во время самого последнего полного резервирования SG. Поскольку нет возможности восстановить ситуацию на момент возникновения сбоя, так как после проведения последнего резервирования файлы транзакций и базы данных были утеряны или повреждены, можно вернуться только на момент самого последнего создания Full Backup. Этот процесс известен также под названием Point-In-Time Recovery. Данный режим процедуры Recovery не обеспечивает возможность повторного исполнения транзакций, поэтому часть данных будет утеряна. Для проведения Point-In-Time Recovery необходимо восстановить и базы данных, и файлы журналов транзакций из резервной копии Full Backup. Более того, придется восстановить все базы данных, связанные с SG. Нельзя ручаться, что какие-то базы данных не остались в непротиворечивом состоянии по транзакциям на момент пропажи последних изменений и не оказались в отключенном состоянии из-за того, что потеря транзакций сама по себе является фатальным сбоем и приводит к немедленной остановке хранилища Store (с необеспеченной непротиворечивостью). Следовательно, чтобы быть уверенным в том, что базы данных согласуются друг с другом после перезапуска SG, необходимо вернуть SG в состояние самой последней полной копии.

Выводы для администраторов Exchange

По мере перехода организаций на Windows 2003 и Exchange 2003 использование процедур резервного копирования и восстановления с учетом возможностей VSS будет постепенно становиться стандартом при выполнении аварийного восстановления. Однако про решения на базе VSS нельзя сказать, что они достаточно протестированы и готовы к применению. Кроме того, VSS привносит дополнительную сложность в сценарий аварийного восстановления, мы находимся еще только в самом начале пути изучения наилучших методик и замаскированных ловушек. Другие решения позволяют задействовать в Exchange технологии моментальных копий и клонов. И все же эти технологии не присущи операционной системе изначально и приложениями не поддерживаются. Организациям остается полагаться на поддержку поставщиками своих решений — это касается как уже готовых решений, созданных не на базе VSS, так и будущих решений, использующих VSS. В настоящее время Microsoft поставляет Windows 2003 и планирует выпустить Exchange 2003 уже в этом году, а поставщики, вероятно, последуют за Microsoft и начнут разрабатывать соответствующие компоненты — VSS-провайдер и VSS Requestor.

Статьи Microsoft с обсуждением Snapshot и Cloning для Exchange Server