В простейшем случае виртуализация базируется на одной очень хорошо оснащенной машине, как правило, обладающей несколькими процессорами и несколькими гигабайтами оперативной памяти. В зависимости от программного обеспечения для виртуализации на ней работает операционная система, хостовая или главная (Windows 2000/2003, Linux). Администратор инсталлирует на нее программное обеспечение для виртуализации (VMware GSX, Microsoft Virtual Server) или устанавливает VMware GSX непосредственно на аппаратное обеспечение (см. Рисунок 1).

РЕЗЕРВИРОВАНИЕ ЧЕРЕЗ ГЛАВНУЮ СИСТЕМУ

При помощи главной системы может быть осуществлено резервное копирование всех виртуальных машин как отдельных файлов, поскольку они размещаются на жестком диске главной системы в виде файла. Копирование файлов жесткого диска сравнимо с методами создания образов с помощью, к примеру, Acronis True Image или Symantec Ghost: системный администратор сохраняет виртуальную машину как единое целое, а не как отдельные файлы гостевой операционной системы, пользовательские данные и т. д.

В качестве пояснения приведем пример: на физическом сервере с жесткими дисками емкостью 100 Гбайт установлены Windows 2003 Server и VMware GSX, а также пять виртуальных машин (VM1 — VM5). Они расположены в домашнем каталоге d:vmaschinen, в подкаталогах от d:vmaschinenVM1 до d:vmaschinenVM5. Наряду с файлами конфигурации, где среди прочего описывается виртуальное программное обеспечение виртуальных машин, в домашних каталогах размещаются файлы виртуальных жестких дисков. Они соответствуют размеру жесткого диска, который уровень виртуализации виртуальной машины представляет в качестве обычных жестких дисков. В домашнем каталоге этот файл называется, к примеру, d:vmaschinenVM1vm1-hdd1-system.vmdk. Теперь с помощью средств VMware GSX и Microsoft Virtual Server их можно копировать через главную систему на свободное место в сети и таким образом полностью сохранить все файлы виртуальной машины на удаленной площадке. В обоих решениях эта процедура выполняется в автономном режиме, поэтому виртуальная машина должна быть отключена. Однако за счет правильно составленного сценария необходимое для копирования временное окно можно сделать столь небольшим, что виртуальная машина отключается лишь на несколько минут.

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

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

Копировать и создавать журналы повторного выполнения возможно без использования дополнительного программного обеспечения посредством стандартных команд сервисной консоли (vmsnap.pl, vmres.pl). Кроме того, при необходимости администратор может адаптировать и автоматизировать процесс по собственному желанию с помощью сценария на Batch, Shell, VB или Perl. На сайте итальянского консультанта Массимилиано Данери (http://www.vmts.net/vmbk.htm) доступен для копирования свободно распространяемый мощный сценарий на Perl. Кроме того, для резервного копирования виртуальных машин предлагаются дополнительные продукты. Поскольку программы на базе командной строки требуют хорошего знания администратором операционной системы и пунктуальности, эти дополнительные продукты облегчают его повседневную работу, повышая тем самым уровень безопасности в подразделении ИТ. Речь идет не только о специализированных инструментах для программного обеспечения виртуализации, вполне подойдут и программные средства защиты физического мира, к примеру IBM Tivoli TSM или Veritas Backup Exec.

Написанное специально для виртуальной инфраструктуры программное обеспечение для резервирования, конечно же, обладает своими преимуществами в обращении с решениями виртуализации: в частности, программы Aexia VS или Vizioncore ESX Ranger используют журналы повторного выполнения. Если VMware GSX или MS Virtual Server поддерживают практически любое работающее на главной операционной системе программное обеспечение для резервирования, то в случае VMware ESX Server необходимо обращать внимание на сертификацию ПО. Более подробную информацию можно получить на сайте VMware.

В этом контексте стоит упомянуть еще один продукт VMware — VMware Mount Utility, поскольку он позволяет просматривать сохраненные файлы жестких дисков и производить определенные действия над ними, в частности обмениваться отдельными файлами или копировать их. Этот инструмент может использоваться в среде Windows и Linux. Он добавляет в систему файл жесткого диска в качестве накопителя и связывает его с буквой диска (Windows) или с точкой монтирования (Linux). Однако следует учитывать, что из системы Linux нельзя описывать файлы жесткого диска виртуальных машин NTFS и наоборот. При помощи VMware Mount Utility можно смягчить недостатки полного копирования, по крайней мере, в случае обратного сохранения, поскольку он позволяет реконструировать отдельные файлы.

Полноты ради стоит упомянуть еще одну возможность резервного копирования, предоставляемую определенными системами SAN или NAS, - создание моментальных снимков. Они способны сохранять данные на конкретный момент времени.

СОХРАНЕНИЕ В ВИРТУАЛЬНОЙ МАШИНЕ

Наряду с сохранением через главную систему еще одна возможность состоит в резервном копировании и восстановлении данных в рамках виртуальной машины (также см. врезку «Методы резервного копирования»). Здесь перед администратором открыты все пути, хорошо знакомые ему из физического мира: к примеру, обычное инкрементальное резервное копирование посредством продуктов сторонних производителей (Veritas, Tivoli и т. д.) точно так же, как и сохранение образа (при помощи продуктов Acronis, Symantec и т. д.). Однако первый тип резервного копирования обладает значительным недостатком: администратор должен инсталлировать инструмент на каждой подлежащей резервированию машине. Это может повлечь за собой чрезмерные затраты на лицензии. Кроме того, придется следить за интервалами между процедурами копирования: если, например, главная система объединяет 20 виртуальных машин, то их одновременное резервное копирование повлекло бы за собой отказ всей системы.

Поскольку в случае программного обеспечения для создания образов чаще всего приходится работать с загрузочным компакт-диском или загрузочной дискетой, виртуальная машина имеет одно интересное преимущество: вместо того чтобы вставлять диск, пользователь делает с него файл ISO (WinISO) и затем передает виртуальной машине. Таким образом, администратору больше не нужно покидать свое рабочее место, а проблемы с неисправными или устаревшими дисководами уходят в прошлое.

ЗАЩИТА ГЛАВНОЙ СИСТЕМЫ ОТ ОТКАЗА

Резервное копирование - первый шаг к более надежному миру ИТ. Однако ответственные за ИТ чувствуют себя еще более уверенно, когда восстановление после полного отказа происходит просто и быстро. Как только отдел ИТ принял решение о виртуализации, ему необходимо разработать концепции решения на случай отказа, во-первых, главной системы, а во-вторых - виртуальной машины (см. Рисунок 2).

Администратор, возможно, сочтет, что наибольшие неприятности принесет отказ главной системы, однако это не совсем так. Главная система состоит из физического аппаратного обеспечения и создает, таким образом, обычные проблемы. Различия

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

Конечно, системному администратору стоить с самого начала задуматься о такой возможности: к примеру, о второй главной системе, которая благодаря своему надлежащему оснащению в случае ошибки была бы в состоянии взять на себя поддержку всех виртуальных систем. Она может быть даже несколько медленнее, если виртуальные машины становятся снова активными в максимально короткий срок. Кроме того, главную систему следует снабдить разнообразными механизмами избыточности, чтобы снизить вероятность отказа до минимума. Впрочем, это касается не только главной системы, но и периферии (коммутатор, подключение Fibre Channel, ИБП). Обязательным условием является отделение раздела главной системы от разделов данных виртуальных машин - системные данные должны находиться, по меньшей мере, на ином массиве RAID.

Для главной системы могут дополнительно использоваться инструменты восстановления после катастрофы, к примеру Acronis, Cristie или Symantec. Исключение составляет VMware ESX из-за его установки непосредственно на аппаратное обеспечение, поскольку для полного резервного копирования главной системы подходит лишь сертифицированное программное обеспечение. Но VMware ESX чаще всего применяется вместе с разделяемым хранилищем (сеть хранения данных - Storage Area Network, SAN), где размещают жесткие диски виртуальных машин. Благодаря этому можно очень быстро выполнить повторную инсталляцию сервера ESX и снова запустить виртуальные машины: администратору останется лишь сохранить или заново создать конфигурационные файлы, поскольку жесткие диски виртуальных машин находятся в разделяемом хранилище.

Построение кластера на базе главной системы сегодня возможно только в случае Microsoft Virtual Server 2005 Release 2 по iSCSI (см. Таблицу 1).

VMware GSX и ESX не предлагают пока официальных средств кластеризации. Однако они вот-вот появятся. Первые бесплатные инструменты для VMware ESX на бета-стадии уже существуют, в частности Onion. Однако в большинстве случаев администратор может справиться и без них — при условии, что данные находятся в разделяемом хранилище, и тогда на отказы можно быстро, причем автоматически, реагировать при помощи сценариев.

ОТКАЗОУСТОЙЧИВОСТЬ ВИРТУАЛЬНЫХ МАШИН

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

VMware ESX вместе с сетью хранения данных и программным обеспечением для управления VirtualCenter предлагает еще одну интересную функцию - VMotion. Эта технология позволяет перемещать активные виртуальные машины между двумя серверами ESX. Длительность простоя минимальна и составляет обычно - в зависимости от содержимого оперативной памяти — менее 3 с. Таким образом, системный администратор сможет проводить работы по обслуживанию и обновлению программного обеспечения на главной системе без остановки сервера. Поскольку VirtualCenter предлагает интерфейсы для программирования, VMotion и прочие функции можно также связать с выполнением определенных условий: к примеру, все виртуальные машины какой-либо главной системы следует распределить по другим серверам ESX, если на ней отказал вентилятор.

Кроме того, уже упоминавшиеся инструменты Aexia VSB и Vizioncore VSX Ranger позволяют проводить автоматизированное, а частично и версионированное резервное копирование. Если понадобится, администратор может восстановить виртуальную машину через интерфейс Web (Aexia VSB) или графический пользовательский интерфейс Windows (ESX Ranger). CBMR от Cristie или PowerConvert от PlateSpin обеспечивают даже восстановление физических серверов на виртуальном аппаратном обеспечении и наоборот.

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

ПЕРСПЕКТИВЫ

К описанным здесь инструментам и решениям в ближайшем будущем добавятся множество новых. VMware уже объявила о выходе дополнения к VirtualCenter 2, с помощью которого окажется возможным автоматический перенос вычислений между двумя серверами ESX: при отказе главной системы все находящиеся на ней виртуальные машины автоматически запускаются на одном или нескольких других серверах ESX. Начиная с VMware ESX 3 станет поддерживаться так называемое консолидированное резервное копирование, в результате инструменты для резервного копирования смогут проводить инкрементальное сохранение виртуальных машин через главную систему. Кроме того, эта технология предотвращает перегрузку главной системы вследствие резервирования виртуальных машин: используемая дополнительная система резервного копирования обращается непосредственно к файлам жестких дисков в сети хранения данных. Таким образом, консолидированное резервное копирование оказывается возможным только при использовании с VMware ESX вместе с сетью хранения данных. Microsoft уже сообщила о возможности доступа к файлам виртуальных жестких дисков через главную систему, и теперь независимые производители могут приступать к расширению своих решений резервного копирования.

Деннис Циммер администрирует сайт http://www.vmachine.de и является автором книги «VMware & Microsoft Virtual Server».

Методы резервного копирования

Резервирование через главную систему

Преимущества:

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

Недостатки:

  • резервирование/восстановление на уровне файлов в пределах виртуальной машины невозможно;
  • разница между физическими и виртуальными машинами при резервировании/восстановлении увеличивает сложность задачи для администраторов;
  • при использовании VMware ESX далеко не каждое программное обеспечение для резервного копирования может сохранять файлы в VMFS.

Сохранение в рамках виртуальной машины

Преимущества:

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

Недостатки:

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

? AWi Verlag