Диспетчер Data Protection Manager как средство защиты виртуализованных рабочих нагрузок

Включите в свой арсенал полезный компонент пакета System Center 2012 SP1

Диспетчер Microsoft System Center 2012 Data Protection Manager (DPM) используется реже всех прочих компонентов пакета программных продуктов System Center — и это при том, что в большинстве организаций он может быть весьма полезен. Сказанное относится к компаниям, применяющим такие службы Microsoft, как Exchange Server, SharePoint и SQL Server — и в первую очередь касается организаций, где в качестве технологии виртуализации применяется система Hyper-V (доля таких организаций постоянно растет с момента выхода на рынок версии Windows Server 2012). В данной статье рассматриваются возможности DPM в контексте взаимодействия с Hyper-V. Кроме того, я выскажу некоторые соображения относительно использования протокола Server Message Block (SMB) для хранения виртуальных машин и кластеров, а также общих томов кластера cluster shared volume (CSV) и динамической миграции виртуальных машин с применением наиболее эффективных механизмов защиты рабочих нагрузок.

Защита Hyper-V с помощью DPM

Перед тем как перейти к DPM и Hyper-V, я хотел бы сказать несколько слов о собственных средствах резервного копирования Hyper-V. Для обеспечения согласованности резервных копий с используемым приложением в системе Windows применяется служба теневого копирования томов Volume Shadow Copy Service (VSS). Поэтому защищенные данные можно будет задействовать в случаях, когда требуется восстановление данных. Без службы VSS процессу резервного копирования, который только что зарезервировал выполняемый файл данных (скажем, базу данных SQL Server), пришлось бы первым делом снять копию с заблокированного файла. Но тогда у нас не было бы возможности установить, что на диск были записаны данные в согласованном состоянии. Ведь нет никакой гарантии, что SQL Server не выполнил процесс записи данных только наполовину, так что файл мог быть испорчен и непригоден для восстановления. VSS решает эту проблему за счет активного подключения приложения в процессе резервного копирования.

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

Но почему же мы вспоминаем об этом в контексте взаимодействия с Hyper-V? Рассмотрим такую ситуацию: если виртуальная машина резервируется с узла Hyper-V, копированию подвергаются файлы виртуального жесткого диска (VHD или более новой версии VHDX). Если моментальный снимок текущего состояния диска VHD или VHDX был просто получен, а затем зарезервирован, вероятность того, что текущее состояние этого диска является согласованным, невелика. Операционная система, выполняемая внутри виртуальной машины, не в состоянии определить, осуществляется ли в данный момент процесс резервного копирования. Единственный способ, гарантирующий получение качественной резервной копии, состоит в том, чтобы зарезервировать соответствующую виртуальную машину в автономном режиме. К счастью, разработчики Hyper-V предусмотрели такую ситуацию.

Если операционная система выполняется в «продвинутой» виртуальной машине, она «знает», что является виртуализованной и может взаимодействовать с узлом виртуализации. Это взаимодействие осуществляется главным образом через службы интеграции Hyper-V, и надо отметить, что таких служб существует несколько. Одна из них — служба интеграции Backup (Volume Snapshot) integration service. Она является ключевым звеном процесса интегрального резервирования приложений виртуальных машин Hyper-V.

При выполнении резервного копирования виртуальной машины Hyper-V запрос VSS направляется через службу Backup integration service операционной системе, выполняемой внутри виртуальной машины. В процессе передачи запроса VSS вызываются все модули записи VSS, зарегистрированные в операционной системе соответствующей виртуальной машины. Данные виртуальной машины, размещенные на дисках VHD или VHDX, готовятся к процессу копирования, поэтому когда на уровне узла снимается копия VHD или VHDX с помощью модуля записи Hyper-V, содержимое находится в состоянии, согласованном с приложением.

Диспетчер DPM полностью использует возможности этой «сквозной» функции Hyper-V для организации оперативной защиты виртуальных машин Hyper-V. Однако при осуществлении оперативного резервирования виртуальных машин необходимо обеспечить выполнение ряда требований.

• Служба интеграции Backup integration service должна быть активирована, а это означает, что операционная система, выполняемая внутри виртуальной машины, должна быть совместимой со службами интеграции Hyper-V.
• Гостевая операционная система Windows должна поддерживать службу VSS (Windows 2003 или более новой версии).
• Виртуальная машина не должна содержать динамических дисков.
• Все тома должны быть отформатированы под файловую систему NTFS — даже при использовании платформы Microsoft Application Virtualization (App-V), которая может создавать файлы, не соответствующие формату NTFS.
• Виртуальная машина должна быть запущена.
• Указанные хранилища VSS для этих томов не подлежат модификации.
• Если виртуальная машина представляет собой часть кластера, должна быть активирована соответствующая группа кластерных ресурсов.

Если какое-либо из перечисленных требований не удовлетворяется, что может произойти при использовании виртуальной машины Linux или системы Windows 2000, резервное копирование выполняется в автономном режиме. При осуществлении этой процедуры виртуальная машина переводится в сохраненное состояние на время выполнения моментального снимка, после чего ее работа возобновляется. В результате в ходе осуществления резервного копирования доступность виртуальной машины на некоторое время теряется. Однако в большинстве сетей этот период будет составлять всего лишь порядка 30 секунд.

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

1. Запустите консоль DPM Administrator и выберите рабочее пространство Protection.
2. Выберите пункт New action.
3. Нажатием кнопки Next откройте окно мастера Introduction.
4. В качестве типа группы защиты укажите Servers и нажмите кнопку Next.
5. Укажите сервер Hyper-V, который хотите защитить, а затем откройте узел навигации Hyper-V, чтобы увидеть все подлежащие защите виртуальные машины, как показано на экране 1.

Экран 1. Выбор защищаемых виртуальных машин, которые войдут в группу защиты

Для выполнения резервного копирования вам предлагается два варианта:

• резервирование с использованием моментального снимка дочернего раздела — оперативное копирование (для виртуальных машин, удовлетворяющих перечисленным требованиям);
• резервирование с использованием сохраненного состояния — автономное резервное копирование.

     6. Выберите виртуальные машины, которые хотите зарезервировать, и нажмите кнопку Next.

     7. Выберите имя для группы защиты. Пользователи пакета System Center 2012 Service Pack 1 (SP1) DPM могут также сохранить резервные данные виртуальной машины в сетевом хранилище, таком, как хранилище Windows Azure.

     8. Выполните оставшиеся операции: укажите время хранения, время для установки точек восстановления, метод формирования исходной реплики (например, по сети или с помощью съемных носителей) и распределение памяти.

При использовании средств защиты на базе Hyper-V вы можете восстанавливать либо всю виртуальную машину целиком, либо отдельные файлы виртуальной машины. Эта функция полезна, поскольку собственные средства установки виртуальных жестких дисков реализованы только в системах Windows Server 2008 R2 и более новых версиях. Используйте рабочее пространство Recovery, выберите интересующую вас виртуальную машину, задайте дату и время, после чего дважды щелкните на виртуальном жестком диске виртуальной машины в разделе подробностей. Продолжайте перебор томов, папок и файлов виртуальной машины, восстанавливая нужные вам компоненты.

Дополнительные соображения о защите средствами Hyper-V

Пользователям, осуществляющим защиту виртуальных машин Hyper-V с помощью диспетчера DPM, особенно если они работают с продуктами платформы Hyper-V, необходимо принять во внимание ряд дополнительных соображений. Представьте себе, как осуществляется защита типичного сервера. Агент выполняется внутри его операционной системы, а сервер DPM может в любое время вступить во взаимодействие с упомянутым агентом с целью защиты данных, таких, как файлы для базы данных SQL Server. Сказанное справедливо и для виртуальных машин, выполняемых на платформе Hyper-V. Сервер DPM может взаимодействовать с агентом DPM на узле Hyper-V с целью считывания данных для защищенной виртуальной машины.

А как быть в случае осуществления динамической миграции виртуальной машины внутри того или иного кластера? Ведь виртуальная машина может сегодня размещаться на сервере А, а завтра — на сервере В; как в подобных условиях диспетчер DPM будет определять механизм защиты виртуальной машины? Для виртуальных машин, размещенных в кластере Windows Server 2012, продолжение защиты обеспечивается — даже если виртуальные машины перемещаются с одного узла на другой, но при том условии, что до начала защиты виртуальных машин администратор выполнит следующие действия:

    1. Установит агент DPM на всех узлах кластера.

    2. Установит консоль System Center 2012 Virtual Machine Manager (VMM) на сервере DPM. Консоль VMM должна быть той же версии, что и сервер VMM, управляющий кластером Hyper-V.

    3. Выполнит следующую команду Windows PowerShell из окна DPM PowerShell с более высоким уровнем разрешений

runSet-DPMGlobalProperty -DPMServerName  -KnownVMMServers 

    4. Запустит службу DPMVMMHelper.

Кстати, о кластерах. Если в крупном кластере (состоящем из 8 или более узлов) с большим числом виртуальных машин (порядка 400) используются общие тома кластера, на выполнение полной процедуры сканирования в процессе настройки средств защиты может уйти несколько часов. Однако если вы работаете с системой Windows Server 2012 и диспетчером Service Center 2012 SP1 DPM, необходимость в активации средств сериализации отпадает. Однако по возможности все еще следует пользоваться аппаратным провайдером VSS — для того, чтобы избежать ухудшения рабочих характеристик защищаемых виртуальных машин.

Еще одна новая функция Windows Server 2012 — обеспечение возможности сохранения виртуальных машин на файловых ресурсах общего доступа SMB 3.0, что приводит к повышению уровня сложности механизма защиты DPM. В рамках программы по превращению SMB в протокол на уровне корпоративных средств качества специалисты Microsoft обеспечили средствами VSS файловые ресурсы общего доступа SMB. Для обеспечения должной защиты таких виртуальных машин агент DPM должен быть установлен на файловом сервере SMB (или на нескольких серверах, если ресурс SMB общего доступа входит в состав кластера); при этом File Server VSS Agent Service (роль службы Windows Server 2012) должна быть активирована.

Кроме того, система Windows Server 2012 поддерживает динамическую миграцию в режиме «ничего общего» (shared-nothing live migration), который обеспечивает перемещение виртуальных машин между узлами Hyper-V, не входящими в один и тот же кластер (или являющимися компонентами различных кластеров). Пока исходный и целевой узлы Hyper-V управляются с помощью одного и того же сервера VMM, защита средствами DPM будет продолжена. Отметим важное обстоятельство: в ситуациях, когда виртуальные машины перемещаются от узла к узлу, решающую роль в обеспечении защиты играет диспетчер VMM. При выполнении динамической миграции в режиме «ничего общего» на результат защиты виртуальных машин могут влиять два обстоятельства:

• Виртуальная машина сохраняется на файловом ресурсе общего доступа SMB, так что перемещению подлежат только содержимое памяти и состояние виртуальной машины (а не хранилище). Компоненты, подлежащие защите средствами DPM, в сущности, не подвергаются изменениям, а защита продолжается без остановки.
• Виртуальная машина размещается в хранилище, не предназначенном для общего доступа, поэтому в рамках процедуры динамической миграции в режиме «ничего общего» необходимо осуществить миграцию хранилища. И хотя DPM может в любом случае выявить факт перемещения виртуальной машины, возникает необходимость в проверке согласованности (то есть поблочного сопоставления исходных защищаемых данных и реплики DPM на предмет выявления возможных несогласованностей) данных в хранилище; только по результатам проверки защита может быть продолжена. Выполнение этого требования оборачивается повышением непроизводительных затрат на эксплуатацию системы.

Хотя для обеспечения защиты данных в определенных сложных ситуациях необходимо принимать дополнительные меры, вас может примирить с этим то, что здесь возможно применение всех сценариев. В любом случае диспетчер DPM может обеспечить полную защиту вашей среды Hyper-V.

Защита виртуальных машин Hyper-V

Как защитить свои виртуальные машины Hyper-V? Возможно, кто-то скажет, что простейшее решение — включить эти машины в группу защиты на уровне узла Hyper-V. Но нельзя утверждать, что данный метод является наилучшим.

Представим себе, что DPM обеспечивает на уровне приложений защиту рабочих нагрузок, таких, как SQL Server, Exchange и SharePoint, и позволяет восстанавливать на уровне приложений базы данных, почтовые ящики или объекты SharePoint. Следует ли защищать сервер SharePoint, выполняемый внутри виртуальной машины Hyper-V, путем защиты виртуальной машины на уровне узла Hyper-V? Если вам нужно восстановить данные, вы можете восстановить всю виртуальную машину или файлы из файловой системы, но ни одно из этих действий не будет восстановлением в терминах SharePoint, а восстановление элементов SharePoint напрямую невозможно. Но если тот же самый сервер SharePoint защищен посредством установки агента DPM внутри виртуальной машины и посредством защиты SharePoint изнутри виртуальной машины, что является частью механизма группы защиты, вы сможете восстанавливать индивидуальные элементы SharePoint.

На экранах 2 и 3 отображена одна и та же виртуальная машина. На экране 2 показаны возможности восстановления данных в ситуации, когда виртуальная машина защищена на уровне узла Hyper-V; на экране 3 — в ситуации, когда компонент SharePoint защищен внутри виртуальной машины. Как видите, различие в показателях весьма существенное.

Экран 2. Степень детализации восстановления данных на уровне узла Hyper-V

Экран 3. Степень детализации восстановления данных на уровне приложения виртуальной машины Hyper-V

Резервное копирование виртуальных машин на уровне узла Hyper-V не всегда можно считать наилучшим вариантом. Решение относительно того, каким образом следует резервировать виртуальные машины, должно базироваться на выборе метода восстановления данных. Если вы хотите восстанавливать данные с учетом выполняемых приложений, вам следует запускать агент DPM внутри виртуальной машины и использовать его для защиты рабочих нагрузок внутри нее. В противном случае можно обойтись резервированием на уровне узла Hyper-V.

Не только для Hyper-V

Я настоятельно рекомендую читателям рассмотреть возможность применения DPM не только для Hyper-V, но и для других рабочих нагрузок Microsoft. Не выбирайте путь наименьшего сопротивления, который в данном случае состоял бы в том, чтобы просто защитить все виртуальные машины на уровне узла Hyper-V. По возможности используйте более тонко настраиваемые средства защиты с учетом выполняемых приложений, для чего нужно устанавливать агент DPM внутри виртуальных машин и задействовать механизм защиты на уровне узла Hyper-V лишь в качестве запасного варианта.