Простой и гибкий способ восстановления после аварии

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

Благодаря свойствам инкапсуляции (полная вычислительная среда содержит операционную систему, BIOS, приложения и виртуализованные аппаратные средства) виртуальные машины (VM) можно восстанавливать на любых совместимых серверах с процессорами AMD и Intel, не обращая внимания на различия в базовом физическом оборудовании. Таким образом, устраняется необходимость восстановления на физически идентичном (по сборке, модели и конфигурации) сервере: исключены проблемы системной совместимости между аппаратными средствами и операционной системой по месту восстановления, повышается надежность восстановления. Еще одно преимущество виртуализации — возможность консолидировать серверы по месту восстановления, разместив несколько VM на одном физическом сервере. В случае аварийного перехода на другой ресурс обычно допускается временное снижение производительности приложений. Благодаря возможности возложить на оборудование несколько функций при минимальном снижении производительности данная модель восстановления становится экономически эффективной. В ходе повседневной работы серверы можно использовать для тестирования и разработки, а после аварии закрыть эти задачи и запустить восстановительные VM. Таким образом обеспечивается полнота использования ресурсов, а потребность в реконфигурации системы сводится к минимуму.

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

Начало

Предположим, что в компании используется несколько приложений Windows, каждое на выделенном сервере с локальным хранилищем данных SCSI. Совместно используемые устройства хранения данных (Fibre Channel SAN, NAS или ISCSI) отсутствуют. Приложения ранжированы в зависимости от важности для компании. Внимание сконцентрировано прежде всего на приложениях второго уровня с менее строгими требованиями к точке (Recover Point Objective, RPO) и времени (Recovery Time Objective, RTO) восстановления. Текущие требования информационной инфраструктуры и производства определят механизмы репликации данных с производственного сайта в сайт восстановления.

Ведущие продукты серверной виртуализации — Microsoft Virtual Server и ESX Server компании VMware. Их функциональность сопоставима, и, хотя в данной статье рассматривается платформа виртуализации ESX Server, основные этапы здесь те же, что и для Virtual Server. Virtual Server устанавливается на существующей базовой операционной системе Windows, такой как Windows Server 2003 или Small Business Server (SBS) 2003, а ESX Server устанавливается непосредственно на аппаратных средствах сервера (на «голом железе») и формирует слой виртуализации между аппаратными устройствами и отдельной гостевой операционной системой. ESX Server делит физический сервер на несколько защищенных и переносимых VM, которые функционируют параллельно на одном физическом сервере. Слой виртуализации абстрагирует базовые процессор, память, устройства хранения данных и сетевые ресурсы для нескольких VM.

Завершив подготовку платформы виртуализации, необходимо рассмотреть три основных способа перемещения данных из исходного сайта в сайт восстановления: резервное копирование/восстановление, серверная или хост-репликация либо репликация на основе массива хранения данных. В табл. 1 показаны варианты репликации, соответствующие различным требованиям к восстановлению. Объекты применения механизмов защиты данных также зависят от местоположения системы ESX Server и файлов VM (см. табл. 2). В нашем примере используются только локальные SCSI-накопители, поэтому варианты для разделяемых устройств хранения данных неприменимы. В статье рассматриваются только сценарии резервного копирования/восстановления и хост-репликации.

Таблица 1 . Восстановление и способы репликации данных

Таблица 2 . Механизмы восстановления для локальных и общих хранилищ данных

Чтобы сделать виртуализацию частью плана восстановления после аварии, можно применить две базовые архитектуры — физическую-виртуальую и виртуальную-виртуальную. Рассмотрим поэтапную реализацию обеих архитектур. Начнем со сценария резервного копирования/восстановления.

Физическая-виртуальная архитектура

В физической-виртуальной архитектуре исходные (производственные) приложения продолжают работать на существующих физических серверах. На восстановительной платформе приложения будут выполняться в виртуальных машинах на ESX Server. В механизме репликации используется метод резервного копирования/восстановления.

Чтобы сформировать среду, в первую очередь необходимо определить приложения, которые войдут в план восстановления после аварии. Затем следует подтвердить, что текущая политика резервного копирования на уровне файлов (например, полная, инкрементная, дифференциальная, частичная) для каждого физического сервера соответствует целям восстановления. В качестве объекта восстановления выбирается физический сервер, на котором предстоит установить ESX Server. Прежде чем совершить этот шаг, следует проверить информацию о совместимости в документе VMware Systems Compatibility Guide for ESX Server 3.x (http://www.vmware.com/pdf/vi3_systems_guide.pdf). Теперь все готово для установки ESX Server 3.x Standard на физическом сервере.

После завершения установки необходимо преобразовать выбранные физические серверы в виртуальные машины. Для этого можно использовать VMware Converter 3.0, который преобразует физические компьютеры Windows и образы сторонних форматов в виртуальные машины VMware. Виртуальная машина VMware, созданная Converter, содержит точную копию состояния диска из исходного физического компьютера, за исключением некоторых аппаратно-зависимых драйверов (и иногда согласованных символьных обозначений дисков). Среди параметров исходного компьютера, которые остаются идентичными, — настройки операционной системы (например, имя компьютера, код безопасности, учетные записи пользователей, профили и предпочтения), приложения и файлы данных, а также серийный номер тома каждого раздела диска.

После того как будет загружен VMware Converter, его можно установить на преобразуемом или отдельном компьютере. Предстоит преобразовать несколько физических компьютеров, поэтому рекомендуется установить Converter на отдельном компьютере — тогда придется выполнить только одну установку.

В VMware Converter нужно щелкнуть на кнопке Import Machine, а затем выбрать физический компьютер в качестве исходного. Следуйте указаниям мастера, выбрав удаленный или локальный компьютер. Если выбрать удаленный компьютер, необходимо ввести имя компьютера или IP-адрес и учетные данные для проверки подлинности. Выберите диски, которые предстоит импортировать, и укажите предпочтительный размер тома. Размер диска можно оставить прежним, уменьшить до минимума или указать точный размер. Выберите место назначения для новой VM и следуйте указаниям мастера, чтобы выбрать систему ESX Server. Необходимо зарегистрироваться в системе и назначить имя VM, а затем указать хранилище данных, чтобы сохранить файлы конфигурации и диски VM.

Затем выполняется настройка гостевой операционной системы новой VM. Можно задать удостоверение VM (имя компьютера, имя владельца, организацию, новый код безопасности), информацию о лицензии сервера, временную зону и свойства каждого сетевого интерфейса. После того как создание задачи импорта будет завершено, можно повторить процесс VMware Converter для всех серверов, которые требуется преобразовать.

Теперь все готово, чтобы запустить вновь созданную VM и протестировать приложения. Можно выполнить пробное восстановление из прошлой резервной копии исходного физического сервера на подходящей VM. Если проверка прошла успешно, систему ESX Server можно перенести в место восстановления. Для обеспечения корректного обслуживания необходимо всегда синхронизировать версии и исправления между исходными серверами и соответствующими VM в восстановительной системе. Рекомендуется периодически выполнять пробные восстановления.

Виртуальная-виртуальная архитектура

В виртуальной-виртуальной архитектуре как производственные, так и восстановительные приложения выполняются в VM. Поэтому первоначально необходимо преобразовать исходные серверы в VM, и как исходная, так и восстановительная платформы будут основаны на ESX Server. Очевидное преимущество такого подхода — полностью виртуализованная архитектура с повышенной гибкостью и управляемостью. Для миграции VM можно просто скопировать нужную конфигурацию и файлы виртуального диска из источника на целевую платформу. К этой архитектуре можно применить резервное копирование/восстановление или механизм хост-репликации. Существует два варианта резервного копирования/восстановления.

Создание копии VM как физического сервера. Такой метод применяется для копирования на файловом уровне данных, сохраненных в образе диска VM. В этом случае требуется установить агент резервного копирования на каждой VM. По возможности следует убедиться, что копируемая VM заморожена. При этом приложение находится в стабильном состоянии и не теряет никаких незавершенных транзакций. Операция делится на две фазы: консолидация сервера, в ходе которой существующие исходные физические серверы преобразуются в виртуальные машины на основе ESX Server, и подготовительная фаза для объектов восстановления.

Первая задача — преобразовать существующие физические исходные серверы в виртуальные машины. Для этого достаточно следовать приведенным выше инструкциям по выбору серверов, установке ESX Server и преобразованию исходных компьютеров в виртуальные машины. Затем нужно настроить системы ESX Server, которые предполагается использовать в качестве объектов восстановления. После применения VMware Converter для импорта существующих виртуальных машин из источника в восстановительные системы ESX Server следует установить любой подходящий агент резервного копирования на каждой VM, которую предстоит копировать (т. е. на исходных серверах ESX). Список совместимых агентов резервного копирования приведен в документе Backup Software Compatibility for ESX Server 3.x (http://www.vmware.com/pdf/vi3_backup_guide.pdf) компании VMware.

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

  1. Настроить сервер резервного копирования для использования устройства архивирования и установить соответствующие драйверы и любое подходящее программное обеспечение сервера.
  2. Убедиться, что сеть настроена для доступа между сервером резервного копирования и виртуальными машинами, которые предстоит копировать. Если и копируемая VM, и сервер находятся на одной системе ESX Server, их следует подключить через частный виртуальный коммутатор.
  3. Составить расписание сеансов копирования и управлять архивными носителями.

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

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

ESX Server хранит виртуальные машины в файловой системе VMware File System (VMFS). VMFS — простая высокопроизводительная файловая система на физических SCSI-дисках и разделах, обеспечивающая хранение больших файлов, таких как образы виртуальных дисков для виртуальных машин ESX Server и образы памяти приостановленных VM.

В ESX Server 3.x VMFS поддерживает каталоги. Обычно для каждой VM в VMFS существует один каталог. Этот каталог содержит все файлы, составляющие VM. Полный список файлов, образующих VM, приведен в табл. 3.

Таблица 3 . Файлы виртуальной машины VMware

При данном способе резервного копирования невозможно восстановить отдельные файлы для каждой VM. Чтобы восстановить единственный файл, требуется восстанавливать всю VM. Размер файлов виртуального диска нередко превышает 1 Гбайт, что может ограничить выбор программы резервного копирования. Из-за потенциально большого размера файла виртуального диска время восстановления наверняка увеличится.

Архивный образ будет содержать состояние VM в определенное время. В нем нет незафиксированных изменений данных или состояния памяти. Поскольку в процессе резервного копирования виртуальный диск рассматривается как целое и не связан с приложениями, созданные архивные копии согласованы только с файловой системой. В результате архивная копия может находиться в аварийном состоянии. Чтобы избежать подобной ситуации, можно отключить VM или заморозить приложение (если возможно) перед резервным копированием. Другой способ — использовать утилиты из состава ESX Server на уровне образа, подробнее об этом рассказано во врезке «Специализированный инструмент архивирования для VMware».

Чтобы сформировать среду, следует настроить источник установки и восстановительные сайты, как описано выше. Установите совместимый агент резервного копирования на служебной консоли каждого компьютера ESX Server (как на исходной, так и на восстановительной системе ESX Server). На исходной стороне нужно настроить сервер и устройство резервного копирования (на диске или магнитной ленте) следующим образом:

  1. Настроить сервер резервного копирования для использования архивного устройства и установить соответствующие драйверы и архивную программу по собственному выбору.
  2. Сетевые функции должны быть настроены для доступа между сервером резервного копирования и виртуальными машинами, которые предстоит архивировать. Если архивируемые VM и сервер резервного копирования находятся на одном компьютере ESX Server, то для их соединения требуется частный виртуальный коммутатор.
  3. Необходимо подготовить график архивирования на основе рекомендованной политики, как показано в табл. 4. Велика вероятность частой смены дисков, приписанных к каждой VM. Поэтому рекомендуется ежедневно выполнять инкрементное копирование. Образ загрузочного диска изменяется не столь часто, и его следует копировать по крайней мере один раз в неделю. Изменения служебной консоли ESX Server минимальны, поэтому в данном случае политику архивирования целиком определяет администратор. Если возможно, следует отключить VM перед резервным копированием. Не забудьте скопировать каждую папку, содержащую VM.

Таблица 4 . Приоритеты политики резервного копирования 

Затем требуется выполнить пробное восстановление машины ESX Server. Обязательно восстановите набор файлов в соответствующем каталоге на восстановительной системе ESX Server. Далее необходимо зарегистрировать VM. С помощью клиента VMware VI нужно подключиться к восстановительному компьютеру ESX Server. Следует выбрать компьютер, перейти на вкладку Configuration и выбрать пункт Storage. Щелкните правой кнопкой мыши в списке на хранилище данных и выберите пункт Browse Datastore для доступа к диалоговому окну Datastore Browser. В правой стороне окна отображается файловая система хранилища данных. Нужно перейти по иерархии хранилища данных на вкладку Folders. Чтобы зарегистрировать VM, следует перейти к файлу конфигурации (.vmx), щелкнуть на нем правой кнопкой мыши и выбрать пункт Add to inventory. При необходимости можно изменить сетевую конфигурацию виртуальной машины. Теперь все готово для запуска VM.

Важно иметь в виду, что из служебной консоли ESX Server можно просматривать и манипулировать файлами в каталогах /vmfs/volumes монтированных томов VMFS с использованием обычных файловых команд, таких как ls и cp. Монтированные тома VMFS могут быть похожи на любую другую файловую систему (например, ext3), но VMFS ориентирована в основном на хранение больших файлов, таких как образы диска размером около 2 Тбайт. Можно использовать команды ftp, scp и cp для копирования файлов в тома VMFS и из этих томов (если базовая файловая система поддерживает большие файлы).

Серверная и хост-репликация

Как правило, механизмы репликации на основе файлов реплицируют файлы асинхронно через IP-сеть при сохранении порядка записи. Существует два основных способа репликации на основе файлов. В одном случае необходимо загрузить агент в VM. Этот метод допускает изменения на файловом уровне в операционной системе, а также репликацию данных через IP-сеть на заранее подготовленный виртуальный узел в восстановительном сайте. Затем обновляются дубликаты файлов на целевом компьютере. Таким образом, только байтовые изменения передаются через IP-соединение в реальном времени. Другой способ основан на репликации собственно набора файлов, составляющих VM (например, виртуальный диск, конфигурация). При любой реализации обязательно помните, что, если активность диска не заморожена для репликации, копия будет уязвима в случае сбоя. Благодаря таким продуктам, как Double-Take компании Double-Take Software и RepliStor компании EMC со службой Microsoft Volume Shadow Copy Service (VSS), возможно создание согласованных с приложениями моментальных снимков на вторичном сервере. Это позволяет восстановить данные и приложения Windows в случае порчи или аварии на исходном сервере.

Чтобы сформировать среду, следует настроить сайты источника установки и восстановления, как описано выше. Затем требуется установить приложение репликации и агента как на исходной VM, так и на соответствующих VM в целевой системе ESX Server. Нужно создать задачу репликации, указав файлы и каталоги для репликации и частоту операций. После начальной репликации следует выполнить простое тестирование и убедиться, что выбранные файлы, каталоги и изменения пересылаются, а данные корректны.

Обязательное тестирование

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

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

Крис Бенсон - Независимый автор. Специализируется на новых технологиях, сетевых решениях, хранилищах данных и всеобъемлющей связи на предприятии Имеет сертификаты MCSE, MCP и CNE. crisban@gmail.com

Рекомендации Microsoft по резервному копированию виртуальных серверов

Каковы возможности преобразования для Microsoft Virtual Server? Чтобы упростить процесс, преобразование физических компьютеров в виртуальные машины автоматизируется с помощью набора инструментов Virtual Server 2005 Migration Toolkit (VSMT). Чтобы воспользоваться VSMT, необходим контроллер Automated Deployment Services (ADS) 1.0, функционирующий на Windows Server 2003, Enterprise Edition, а также Virtual Server 2005. VSMT обеспечивает миграцию Windows 2003, Windows 2000 Server Service Pack 4 (SP4) и Windows NT 4.0 Server SP6.

С помощью функций управления виртуальным диском утилиты Administration продукта Virtual Server можно создать копию физического диска для использования в качестве виртуального жесткого диска. Эта процедура предназначена только для дисков данных. Можно создать виртуальный жесткий диск, связанный с физическим диском данных. Следует отметить, что связанный виртуальный диск не содержит копии содержимого физического диска. Он только ссылается на него. Чтобы скопировать содержимое диска в файл виртуального жесткого диска, необходимо преобразовать связанный диск в динамически расширяемый виртуальный жесткий диск.

Существует ряд особенностей, которые нужно учитывать при архивировании. Важные файлы виртуальной машины Virtual Server — .vmc (конфигурация VM), .vhd (виртуальный жесткий диск), .vsv (сохраненное состояние VM) и .vnc (конфигурация виртуальной сети). Чтобы скопировать конфигурацию VM и файлы ресурсов, рекомендуется копировать только .vmc, .vsv и связанные .vhd-файлы для виртуальных машин, которые отключены или находятся в сохраненном состоянии. В противном случае, скорее всего, они будут несогласованными.

Специализированный инструмент архивирования для VMware

Еще один вариант — использовать встроенные утилиты ESX Server компании VMware для резервного копирования на уровне образов. С помощью утилиты vcbMounter можно получить архивную копию всей VM в служебной консоли. Инструмент скрыто создает моментальный снимок VM и экспортирует его в набор файлов, которые впоследствии можно использовать, чтобы восстановить VM. Сделать копию набора файлов можно с помощью совместимой программы архивирования или применить scp для простой пересылки файлов.

На исходных компьютерах ESX Server следует получить резервные копии файлов VM с помощью утилиты vcbMounter. Синтаксис следующий:

vcbMounter -a -r

где VM identifier — уникальный идентификатор копируемой VM, а backup destination указывает место для хранения архивных данных. Типичный способ идентифицировать виртуальные машины — использовать имя DNS или IP-адрес. Scp можно задействовать для копирования VM в локальный каталог или на удаленный сервер. Например, чтобы архивировать VM w2k3vm.acme.com в локальный каталог /home/vmbackup/w2k3vm, следует ввести команду

vcbMounter -a ipaddr:w2k3vm.acme.com -r /home/vmbackup/w2k3vm

Чтобы восстановить файлы в заданном каталоге в консоли ESX Server, необходимо использовать файл каталога VM. Утилита vcbMounter создает этот файл для каждой архивируемой VM. Требуется сделать копию этого файла. В данном примере нужно сделать копию файла каталога VM /home/vmbackup/w2k3m. Для этого можно ввести команду

cp /home/vmbackup/w2k3m/catalog /tmp/catalog-w2k3m

В копии файла каталога следует указать новые параметры для хранилищ данных и путь папки. Хранилище данных указывает, где хранить все файлы, которые составляют VM. Список корректных имен хранилищ данных можно получить из браузера хранилищ данных в клиенте VI или взглянув на ярлыки файловой системы тома VMFS в служебной консоли под /vmfs/volumes. Путь указывает папку, в которой будет храниться VM.

Изменив параметры файла каталога VM, следует использовать этот файл для восстановления VM. Чтобы восстановить VM, нужно указать альтернативный файл каталога с помощью ключа -a. Например, чтобы восстановить VM, копия которой находится в /home/vmbackup/w2k3m, с использованием альтернативного файла каталога /tmp/catalog-w2k3m, следует ввести команду

vcbRestore -s /home/vmbackup/w2k3m -a /tmp/catalog-w2k3m.

Крис Бенсон