Один из возможных подходов к оптимизации вычислительных ресурсов, названный в свое время виртуализацией, уходит своими корнями в проект Multiple Access Computer, над которым в 50–60-е годы работали в Кембриджском центре корпорации IBM. (Уточним, это не тот Кембридж, что в Англии, к нему мы еще вернемся, говоря о Xen, а тот, что район Бостона, где расположен Массачусетский технологический институт.) Для развития этого проекта была написана управляющая программа CP-67 для операционной системы CP/CMS, она работала на мэйнфрейме IBM System/360-67. Еще позже был разработан монитор виртуальных машин (Virtual Machime Manager, VMM) для System/370 Extended Architecture (370-XA), но в 80-е годы из-за повального увлечения ПК и небольшими серверами в дальнейшем развитии виртуализации возник перерыв (рис. 1).

Рис. 1. Четыре фазы истории виртуализации

Об этой паузе в истории виртуализации говорил Мендель Розенблюм, научный руководитель компании VMware, в выступлении на недавней конференции VMWorld Europe 2008. В нем он разделил всю историю виртуализации на четыре фазы: нулевая — на мэйнфреймах, это предыстория, о которой речь уже шла выше. Остальные три можно назвать новейшей историей, первая фаза была экспериментальной, затем идет нынешняя — это активные работы, прежде всего в области консолидации серверов, и, наконец, следующая четвертая фаза будет более масштабной, ее итогом станет виртуализация ЦОД.

Впрочем, виртуализацию нельзя рассматривать как изолированное явление. О будущей конвергенции SOA, grid и виртуализации и о развитии по направлению от микровиртуализации к макровиртуализации рассуждает Ричард Вирт в статье, публикуемой в этом номере. Безусловно, представленная здесь картина эволюционного процесса является заведомым упрощением, поскольку и во время отмеченного разрыва работы продолжались, например, многое было сделано в этой области в Unix и Unix-подобных системах, например, в Solaris.

Определение виртуализации

Как ни странно, но несмотря на его полувековую историю, слова virtualization пока не найти ни в одном английском толковом словаре, даже в Internet-издании Merriam-Webster, зато его значение раскрыто в Wikipedia. «Виртуализация — это метод сокрытия физических характеристик компьютерных ресурсов от тех приемов, которыми другие системы, приложения или пользователи используют эти ресурсы. Существуют основные две версии этого метода, одна предполагает разделение какого-то единого физического ресурса (сервер, операционная система, приложение или система хранения данных) на множество логических, вторая обратная — множество физических ресурсов интегрируется в один логический». В русском же языке слово «виртуальность» ассоциируется с нереальным, но в приложении к компьютерам ничего мнимого. Значение, противоположное виртуализации, имеет слово transparency («прозрачность»). Сравним: виртуализованный объект видим и ощутим, но в реальности он не существует, а прозрачный — и невидим, и неощутим, но у него есть физическое соответствие.

Объекты виртуализации

Применительно к технологиям виртуализации существует множество классификаций, построено множество «карт виртуализации» (virtualization map). При желании можно найти еще несколько аналогичных генеалогических деревьев. Все они сходятся в том, что предметом виртуализации могут быть, операционные системы, выделив следующие категории: приложения, рабочие места на персональных компьютерах, системы хранения, данные или серверы.

Операционные системы. Виртуализация операционных систем — это метод размещения множества «гостевых» операционных систем (guest) поверх одной операционной системы-«хозяина» (host). Изолированные образы ОС называют «контейнерами», «виртуальными частными серверами» (Virtual Private Server, VPS) или «виртуальными средами» (Virtual Environment,VE). С точки зрения хоста VPS или VE выглядит как настоящий сервер. Этот тип виртуализации реализован во многих операционных системах: IBM AIX (технология WPARs), HP-UX (HP vPars), Sun Solaris (Container/Zone), FreeBSD(FreeBSD Jail), Linux (Linux-VServer, OpenVZ, Virtuozzo Containers), Windows (Virtuozzo Containers).

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

Еще два решения можно назвать подмножествами виртуализации приложений. Одно из них — «потоковые приложения» (Streaming). Второе — «специализированные виртуальные машины» (Virtual Appliance).

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

Системы хранения. Виртуализация систем хранения — отдельная тема, она известна давно и хорошо. В нашем журнале было опубликовано несколько обзорных статей по этой проблеме.

Данные. Для виртуализации данных существуют иные названия — Information-as-a-Service и Data-as-a-Service.

Рабочие места. Известно множество самых разнообразных способов виртуализации, предназначенных для виртуализации рабочих мест, среди них наибольшее распространение получили несколько основных. Во-первых, удаленный доступ по сети (Single Remote Desktop) с использованием технологий PCAnywhere, Windows Remote Desktop и других. Во-вторых, Shared Desktops, модель, при которой мощный сервер с использованием технологий Citrix, Ericom Software или Terminal Services превращается в среду, на которой можно выполнять сотни и больше терминальных сессий. В-третьих, рабочему месту может быть поставлена в соответствие «виртуальная машина» (Virtual Machine Desktop). И, наконец, обычный компьютер можно заменить удаленным лезвием.

Виртуализация серверов и центров обработки данных

Из всех виртуализационных решений именно виртуализация стандартных серверов и центров обработки данных — тема номер один. Чаще всего под серверами понимаются стандартные платформы x86 и x64, когда говорят о ЦОД, то имеют в виду центры обработки данных на основе таких серверов. Особое внимание к виртуализации именно этого типа оборудования объясняется тем, что она имеет низкий коэффициент полезного действия и, как следствие, — низкие экономические, экологические и прочие показатели.

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

В Wikipedia можно найти описание двух типов гипервизоров, Тип-1 работает на голом железе (bare-metal architecture hypervisor) и Тип-2 (hosted architecture hypervisor) использует базовую операционную систему. С этим определением трудно согласиться, поскольку Тип-2 есть ни что иное, как виртуализация операционной системы и в альтернативном наименовании это виртуализационное решение не нуждается.

Проблемы виртуализации архитектур x86

Рис. 2а. Традиционная схема выполнения приложений и работы операционной системы без виртуализацииВиртуализация может избавить стандартные серверы от их основного недостатка — низкой эффективности, его преодоление осложняется тем, что архитектура процессоров х86 малопригодна для виртуализации по двум причинам. Во-первых виртуализации мешают имеющиеся в x86 «иерархически защищенные домены» (hierarchical protection domain), которые еще называют «защитными кольцами» (Ring 0, Ring 1, Ring 2, Ring 3), обеспечивающие безопасность данных и функционирования в случае сбоев и ошибочного поведения. Эти кольца образуют иерархию, от наиболее привилегированного Ring 0, имеющего непосредственный доступ в память и ко всем ресурсам процессора, до наименее привилегированного Ring 3, на котором работают приложения. Наличие специальных шлюзов между кольцами ограничивает доступ с внешнего уровня на внутренний уровень. С точки зрения обеспечения безопасности эта архитектурная особенность полезна, но она создает барьер на пути к виртуализации.

Вторая сложность — несоответствие архитектуры x86 критерию достаточности виртуализации Попека-Гольдберга Еще в 70-е годы Попек и Гольдберг показали, что монитор виртуальных машин может быть создан для любого компьютера, если его команды, изменяющие состояние компьютера, входят в число привилегированных. Если условие удовлетворяется, то тогда команда, выполненная гостевой операционной системой, может быть перехвачена и перенаправлена в VMM. Но в системе команд IA-32 насчитывается 17 проблемных команд, которые подобным образом перехватить нельзя. При выполнении на разных уровнях такие команды имеют разную семантику.

Три подхода к виртуализации серверов стандартной архитектуры

Можно выделить три альтернативных базисных подхода для решения проблемы неприспособленности x86 и x64 к виртуализации: полная виртуализация с использованием бинарной трансляции, паравиртуализация и виртуализация, поддерживаемая на аппаратном уровне.

Рис. 2б. Полная виртуализация с использованием бинарной трансляцииПолная виртуализация с использованием бинарной трансляции. Авторство на полную виртуализацию принадлежит VMware. Суть технологии (рис. 2б), предложенной этой компанией, заключается в использовании бинарной трансляции, а именно в перемещении гостевых операционных систем на уровень Ring 1 и в переводе кодов исходящих из ядра этих систем с заменой тех самых инструкций, которые не удовлетворяют критерию Попека-Гольдберга. Команды гостевых ОС проходят через VMM, а пользовательские коды свободны от этой проблемы, поэтому они могут быть направлены в физический процессор без перевода, что ускоряет процесс выполнения. Монитор виртуальных машин обеспечивает каждую виртуальную машину сервисами от физической системы, в том числе он предоставляет BIOS, виртуальные устройства, виртуализированое управление памятью. Сочетание бинарной трансляции команд ОС с прямым выполнением команд приложений обеспечивает «полную виртуализацию» гостевых ОС.

Рис. 2в. Паравиртуализация или виртуализация, поддерживаемая ОСПаравиртуализация. Точному пониманию этого подхода немного мешает его название, хотя в русском и английском языках префикс «пара» звучит одинаково, но смысл имеет различный. В русском эта приставка означает еще и «нечто, выходящее за пределы», но с очевидным отрицательным оттенком. В английском языке para тоже имеет несколько значений, однако чаще всего его трактуют как «близкое, сопутствующее, обходное, но стоящее в одном ряду», не вкладывая никакого негативного звучания. Суть паравиртуализации состоит в замене невиртуализуемых команд гостевых ОС их аналогами-гипервызовами, адресованными монитору виртуальных машин (Рис. 3в). С точки зрения VMM это не сложно, нужны всего лишь специальные интерфейсы. С точки зрения гостевой ОС дело обстоит сложнее: для того, чтобы сформировать гипервызовы, требуется модификация ОС, то есть необходимо адаптировать гостевую ОС под паравиртуализацю. Этим паравиртуализация отличается от полной виртуализации, где используется немодифицированная ОС. В то же время паравиртуализационные решения проще и соответственно дешевле. Очевидно, что если не нужно переводить вызовы в динамике (то есть эмулировать), то производительность может быть выше, хотя расплатой служит необходимость специальным образом настраивать гостевые ОС.

Аппаратно поддерживаемая виртуализация. В 2006 году Intel и AMD предложили собственные аппаратные решения, упрощающие виртуализацию. Обе компании поступили одинаково, они ввели еще один уровень защиты, располагающийся между железом и Ring 0, теперь монитор виртуальных машин может работать на этом уровне. Дополнительный уровень еще называют Ring-1, а работу на этом уровне «корневым режимом» (Root Mode). По совокупности эти усовершенствования исключают необходимость в обоих искусственных приемах, и в прямой трансляции, и в паравиртуализации. Такая схема виртуализации чрезвычайно привлекательна, но пока она делает шаги, а мониторы виртуальных машин находятся в стадии адаптации к ней. Нередко при представлении виртуализации, поддерживаемой аппаратными средствами, упускается из внимания тот факт, что она упрощает VMM, но не исключает их необходимость.

Рис. 2г. Виртуализация с аппаратной поддержкой Каждый из производителей процессоров предлагает свою версию аппаратной виртуализации, AMD производит технологию AMD Virtualization (AMD-V), которую иногда по-прежнему по имени проекта называют Pacifica. Она реализована в процессорах Athlon 64 (F и G), Athlon 64 X2 (F и G), Turion 64 X2 и во всех более новых процессорах. AMD опубликовала спецификацию IO Memory Management Unit (IOMMU) для AMD-V, определяющую процедуру обработки прерываний и трансляцию обращений в память, позволяющие не использовать в виртуальных машинах прямые обращения в память (Direct Memory Access, DMA).

Технология виртуализации компании Intel для 32 и 64 разрядных архитектур х86 сейчас известна как Intel Virtualization Technology (IVT), на уровне проектирования ее называли Vanderpool. Существует спецификация IVT для процессоров IA-64 (Itanium) под названием VT-I (проект Silvervale). Технология IVT была анонсирована в 2005 году, она реализована в выборочно в некоторых версиях Pentium 4, Pentium D, Xeon, Core Duo и Core 2 Duo. Подобно AMD в Intel существует спецификация Virtualization for Directed I/O (VT-d) для обработки прерываний виртуальных машин и изоляции DMA.

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

«Ви-эм-веа»

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

Начав раньше, компания VMware смогла и уйти дальше. В ее предложениях собственно гипервизор, существующий в двух редакциях — ESX Server и ESX Server 3i, является нижним уровнем в инфраструктуре. Это проприетарный продукт, поэтому в конечном итоге то, как он устроен, значения не имеет, построен ли он на принципах бинарной трансляции или использует виртуализационные способности современных процессоров, суть не в этом, важнее его универсальность, способность поддерживать операционные системы без модификации и производительность. На рис. 3 показано то, как смещался фокус интересов компании, сначала был собственно гипервизор, затем к нему прибавилась инфраструктура, а сейчас еще и средства для автоматизации управления. Соответственно и предложения четырех продуктов отражают прогресс в этом направлении.

Рис. 3. Эволюция продуктов VMware

Вернемся к определению виртуализации из Wikipedia. Там представлены два альтернативных варианта, в одном физический ресурс представляется множеством логических, во втором наоборот, множество логических одним физическим. Но возможен и третий вариант, когда одно множество физических ресурсов представляется другим множеством логических ресурсов. Общая тенденция виртуализации направлена именно в эту сторону, она поддерживается движением по направлению к многоядерным процессорам, большим объемам памяти и повышением производительности коммутационных устройств. Объектом виртуализации становится и отдельный сервер, и ЦОД в целом. Поэтому третье поколение продуктов VMware поддерживает виртуализацию аппаратной экосистемы в общем.

Поставка осуществляется в четырех вариантах комплектации — собственно ESX Server 3i и три виртуальные среды — основная, стандартная и корпоративная.

В первом случае помимо гипервизора в состав комплекта входит технология VMware Virtual SMP, которая позволяет одной виртуальной машине использовать до четырех физических процессоров одновременно, эти процессоры разделяют общую память и могут работать на одну задачу. Основная среда отличается тремя инструментами. Технология консолидированного резервного копирования VMware Consolidated Backup позволяет разгрузить основные серверы от работ, связанных с сохранением данных и передать их на специализированный прокси-сервер. Для хранения данных виртуальных ESX Server использует специализированную файловую систему VMware Virtual Machine File System. Для обновления программного обеспечения используется VMware Update Manager, средство VirtualCenter позволяет образовывать из отдельных серверов объединения, называемые серверными фермами. Если такую ферму дополнить технологией высокой готовности VMware High Availability (HA), такой комплект получит название стандартный, а если его функциональность еще расширить средствами Distributed Resource Management (DRM) и Distributed Power Management (DPM), то такой комплект называется корпоративный. DRM служит для управления масштабированием серверных пулов, его можно рассматривать в качестве первого шага для создания инфраструктур типа grid, DPM оптимизирует энергопотребление кластерных конфигураций.

Гипервизор с британскими корнями

В родословной гипервизора Xen, как и у его главного конкурента VMware, обнаруживаются прочные университетские корни. Альма-матер этой программной технологии — Кембриджский университет. В его Компьютерной лаборатории зародилась британская национальная компьютерная школа, именно в ней под управлением Мориса Уилкса был собран первый в мире компьютер с хранимой программой EDSAC, и здесь в настоящее время работает один из величайших математиков современности, создатель теории π-вычислений Робин Милнер. В 2001 году преподаватель Кембриджа и сотрудник лаборатории Ян Пратт дал старт проекту Xen и на все последующее время он стал его главным идеологом. Два университетских проекта VMware и Xen не похожи ни идеологически, ни технологически. В отличие от своих коллег из Стэнфорда, возглавляемых Розенблюмом, Пратт не пошел по пути немедленной коммерциализации, при создании своего предприятия, известного как компании XenSource, он отдал предпочтение подходам сообщества Open Source. Следуя принципам открытости, компания поддерживала сообщество разработчиков и продавала корпоративную версию продукта. Первая редакция Xen 1.0 была выпущена в 2003 году, за ней последовали 2.0, 3.0. В октябре 2007 года XenSource была куплена Citrix Systems и, как обычно в таких случаях, был произведен ребрендинг всей продуктовой линейки, XenExpress переименовали в XenServer Express Edition, встраиваемый гипервизор — в XenServer OEM Edition, XenServer — в XenServer Standard Edition и Enterprise — в XenServer Enterprise Edition. Несмотря на появление у проекта нового владельца консультативный совет, осуществляющий наблюдение за ним, Xen Project Advisory Board (Xen AB), продолжает существовать: в состав помимо Citrix входят компании IBM, Intel, Hewlett-Packard, Novell, Red Hat и Sun Microsystems. Компания Citrix намеревается сохранить открытость кодов Xen AB, а правила лицензирования регламентирует Xen AB.

Свой метод виртуализации, единственную серьезную альтернативу бинарной трансляции VMware, Пратт назвал паравиртуализацией. Принципы этого метода изложены в основополагающей статье «Xen и искусство виртуализации» (Xen and the Art of Virtualization), опубликованной Праттом и его коллегами в 2003 году. Хотя с тех пор прошло почти пять лет, что больше половины новейшего периода в истории виртуализации, публикация не потеряла своей актуальности. 

С первых дней своей работы команда Xen избрала для себя роль оппонента VMware, что сквозит во всех статьях и выступлениях ее членов. Основным преимуществом паравиртуализации перед полной виртуализацией они считают более высокое быстродействие и меньшую стоимость. Этот аргумент имеет понятное объяснение, бинарная трансляция (в некоторых материалах Xen эту процедуру называют с оттенком презрительности binary patching) основывается на динамической замене кодов гостевой ОС, что требует значительных затрат ресурсов в процессе исполнения. Отсюда следует более высокая цена продуктов VMware, являющаяся объектом постоянной критики, что же касается быстродействия, то здесь не все так просто, как хотелось бы того приверженцам Xen. Справедливости ради, следует заметить, что первыми идею и термин «паравиртуализация» предложили ученые из Вашингтонского университета в проекте Denali. Суть его в том, что команды, не позволяющие виртуализировать процессор, в нем заменяются псевдокомандами. Авторы рассчитывали на создание облегченных гостевых ОС и поддержку «легковесных» (lightweight) процессов. Заметного развития проект Denali, осуществлявшийся силами нескольких человек, не получил, сейчас он остается в тени.

Отдав предпочтение виртуализации, разработчики Xen предпочли добиться повышения производительности за счет незначительной модификации гостевых ОС, при этом полностью сохраняются интерфейсы с приложениями (Application Binary Interface, ABI), следовательно, никакой модификации приложений не требуется. В первой версии архитектура Xen имела вид, показанный на рис. 4 (замысел создания модифицированной XenoXP остался нереализованным). Основа Xen, гостевой низкоуровневый интерфейс (low-level API) известный как интерфейс гипервызовов (hypercall API). Его наличие позволяет не эмулировать работу железа, как это делается при полной виртуализации, а сочетать работу гипервизора с функциями, выполняемыми операционной системой, что теоретически обещает значительное ускорение, дает возможность использовать те же самые драйверы, что используют ОС.

Рис. 4. Архитектура гипервизора Xen 1.0; в Домене 0 работает управляющее программное обеспечение под управлением модифицированной операционной системы XenoLinux, в остальных?— приложения под управлением модифицированных XenoLinux, XenoBSD и XenoXP

В версии Xen 3.0 сохранились основные черты первой версии, но добавилась поддержка технологий виртуализационных технологий Intel VT и AMD-V, что открывает возможность для поддержки немодифицированной ОС Windows XP. Благодаря этому в список поддерживаемых вошли 64-разрядные Windows Server 2003 Standard, Enterprise, Datacenter Edition SP2 и Windows Small Business Server 2003 SP2, 32-разрядные Windows Server 2003 Web, Standard, Enterprise, Datacenter SP0/ SP1/SP2/R2, Windows Small Business Server 2003 SP0/SP1/SP2/R2 и Windows XP SP2. Естественно, что XEN, как и прежде, поддерживает Red Hat Enterprise Linux, Novell SUSE Linux Enterprise Server и другие версии Linux. Текущая версия XenServer имеет индекс 4, следующая 4.1 находится на стадии бета-тестирования.

С Xen в груди

Открытость гипервизора XenSourse открыла возможность для его полного или частичного инкорпорирования в свои продукты многим вендорам, среди них: Sun Microsystems, Oracle, Novell, Virtual Iron и еще несколько других. В отдельных случаях с его помощью они дополняют потенциал своего ноу-хау, а иногда используют «в лоб», становясь прямыми конкурентами XenSource прежде и Citrix сегодня.

Sun Microsystems — ветеран виртуализации. Компания занялась виртуализационными технологиями 25 лет назад, предложив сетевую файловую систему NFS (Network File System), поддерживающую распределенный доступ к файлам, принтерам и другим ресурсам со стороны компьютеров, объединенных в сеть. Самый яркий пример виртуализационного решения язык Java, своим успехом он обязан главному отличию от большинства языков программирования — реализующей его виртуальной машине Java Virtual Machine (JVM). Сегодня эта идея двенадцатилетней давности переживает второе рождение в новом проекте Sun — мультиязыковой технологии «Машина да Винчи» (Da Vinci Machine). Цель проекта состоит в преодолении рассогласования различных языков с возможностями JVM. На этом грандиозном фоне возникла одна, может быть не столь заметная инициатива в области виртуализации. Собственный гипервизор для серверов на платформах х32 и х64, Sun xVM Server, рассчитан на поддержку в качестве гостевых операционных систем Windows, Linux и, конечно же, Solaris. Вместе с ним для пользователей Windows открывается возможность такие новации Sun, как Predictive Self-Healing и файловую систему ZFS, они встроены в Sun xVM Server. Что это им дает — пользователи других операционных систем получат то, что раньше им было недоступно? Допустим, Windows работает в качестве гостевой ОС под управлением Sun xVM на стандартном сервере и в процессе работы возникает сбой в памяти, в таком случае встроенная подсистема Predictive Self-Healing изолирует дефектную часть памяти и Windows продолжает работать без прерывания.

В основе этого гипервизора Sun xVM Server взят Xen, но компания добавляет свои наработки в области управления в виде Sun xVM Ops Center, полноценного, представляющего собой масштабируемый стек инструментов для управления аппаратными и программными ресурсами. Совместно Sun xVM Ops Center и Sun xVM Server будут первыми в ряду продуктов, образующих будущее семейство xVM.

Компания Oracle предлагает свою версию гипервизора Oracle VM, представляющую собой развитие идей кластеризации, которые были предложены в программе Grid Computing и реализованы в таких продуктах как Oracle Fusion Middleware Clustering, Oracle Automatic Storage Management и Oracle Enterprise Manager Grid Control. Поэтому с точки зрения Oracle, VM еще одна grid-технология, Oracle VM позволяет пользователям без особых сложностей и без лишних затрат воспользоваться преимуществами grid.

Oracle VM состоит из двух компонентов: Oracle VM Manager обеспечивает среду для разработки Web-приложений Application Development Framework, возможность для управления виртуальными машинами, построенными на основе Oracle VM, и программный интерфейс API для Oracle VM Server. Компания создает собственную виртуализационну среду на основе Xen; возникает естественный вопрос: «Зачем?» Ответ представителя Oracle, вице-президента Чака Розвата можно было бы предугадать: «С Oracle VM пользователи, перемещаясь с машины на машину, не будут ощущать изменений, они будут пользоваться базами данных, выполнять приложения в прозрачном для них режиме». Но аналитики в дополнение к этим аргументам говорят, что, вводя в оборот свой гипервизор, компания хочет уменьшить зависимость не только от производителей операционных систем, но и от производителей других гипервизоров.

Компания Novell поставляет платформу SUSE Linux Enterprise 10, интегрированную с гипервизором Xen 3.0. Со своей стороны компания дополняет XEN средством для управления YaST, оно имеет графический интерфейс и может распознавать, обладает ли сервер, на котором оно установлено поддержкой для аппаратной виртуализации и в зависимости от конфигурации сервера выбирает автоматически режим паравиртуализации или виртуализации, использующей аппаратные возможности.

Virtual Iron Software, небольшая компания из Массачусетса, в отличии от Novell, ориентируется только на процессоры с технологиями Intel VT и AMD-V. Она предложила платформу для виртуализации класса на «голом железе», состоящую из нескольких основных компонентов. Virtualization Manager — основное средство для управления виртуальными машинами, устанавливаемое на выделенный сервер, оно развертывает виртуальные машины по сети, используя среду PXE (Preboot Execution Environment). Это своего рода аналог VMware Virtual Center. Второй компонент Virtualization Services является поддерживающим, а ядром служит гипервизор Xen. Его паравиртуализационные не используются, поэтому гостевыми могут быть немодифицированные операционные системы.

Гипервизор от Microsoft

Гипервизор Microsoft Hyper-V, известный в период проектирования под именем Viridian, радикально отличается от тех виртуализационных продуктов Microsoft Virtual Server, которые не являются гипервизорами, в них, как, например, в VMWare Workstation, Parallels, Linux KVM реализована виртуализация на уровне операционной системы. В новом решении Microsoft предпочтение отдано гипервизору потому, что таким образом обеспечивается более высокая производительность и шире возможности для масштабирования. Если использовать деление гипервизоров на три категории — динамическая трансляция, паравиртуализация и аппаратно поддерживаемая виртуализация, то можно сказать, что Hyper-V сочетает в себе элементы двух последних. Он рассчитан на использование процессоров со встроенной технологией Intel TV или AMD-V и одновременно в нем есть элементы паравиртуализации, необходимые для генерации гипервызовов из VMM, работающих под Linux.

Таким образом, Hyper-V способен работать практически на любой современной машине, которая может поддерживать 64-разрядную Windows 2008 и в то же время есть в нем механизм, осуществляющий функции операционной системы-хозяина, поддерживающей ядро Linux. Гипервизор имеет один корневой раздел, где выполняется Windows Server 2008 «подчиненные ему разделы» (child partition), где работают гостевые ОС. Эти разделы создаются с использованием гипервызовов API, они не имеют прямого доступа к физическим ресурсам, только к их виртуальным аналогам по специальной шине VMBus.

Кто быстрее и дешевле?

Ответы на эти вопросы интересуют большинство пользователей, и в ответ на них аналитические компании предлагают массу публикаций со сравнительными материалами. Область нова, поэтому нередко выводы, к которым приходят аналитики, не совпадают. Заинтересованный читатель может самостоятельно найти нужные ему материалы. Для качественного сравнения можно рекомендовать сайт www.itcomparison.com, а для ценового сравнения — отчет Virtualization Price War: VMware’s Little Big Horn?, опубликованный аналитиками Yankee Group в феврале 2008 года.


SaaS – конец начала 


Специализированные виртуальные устройства 


Ренессанс виртуализации – вдогонку за паровозом 


Репликация виртуальных машин

Одним из преимуществ виртуализации, является возможность реализации бесперебойной работы критических для бизнеса приложений и систем независимо от самих приложений или подлежащего аппаратного обеспечения. С массовым развитием и применением виртуализации на базе VMware Infrastructure 3, многие компании осознали, что у них появились простые способы резервного копирования данных. Действительно, при наличии виртуальной инфраструктуры можно без остановки работы сохранить виртуальную машину вместе с операционной системой и данными и, в случае сбоя, восстановить ее в целостном состоянии без какого-либо вмешательства в конфигурацию приложений или операционной системы. Конечно, для этого требуется специализированное программное обеспечение, предназначенное для работы с виртуальными машинами, например VMware Consolidated Backup (VCB) или Veeam Backup.

Резервное копирование само по себе не решает задачу обеспечения сохранности данных — его главная задача состоит в обеспечении возможности восстановления данных за установленное время (RTO, Recovery Time Objective) и с минимальными потерями (RPO, Recovery Point Objective). В мире решений виртуализации существует несколько способов резервного копирования, отличающихся стоимостью, скоростью и сложностью восстановления:

  • резервное копирование на файловом уровне (File-level backup);
  • резервное копирование образов виртуальных машин (Image-level backup);
  • репликация образов виртуальных машин (Image-level replication).

Резервное копирование данных на файловом уровне является традиционным способом обеспечения сохранности данных, однако он не всегда удобен в виртуальном мире из-за сложности планирования и отсутствия гарантии быстрого восстановления данных, в случае если была повреждена виртуальная машина с самой операционной системой и приложением. Также, стоит обратить внимание и на затраты, связанные с программным обеспечением резервного копирования — большинство производителей требуют отдельной лицензии на каждую виртуальную машину (агента), для которой будут создаваться резервные копии, а также на каждую физическую машину, на которой работают виртуальные машины. Ряд крупных производителей традиционных решений реализовали поддержку технологии VCB, например Symantec Net Backup, что позволило осуществлять резервное копирование виртуальных машин без установки агентов и покупки дополнительных лицензий. Преимуществом резервного копирования на файловом уровне является то, что системным администраторам это решение хорошо знакомо, поскольку они много лет используют его для резервного копирования физических машин.

Резервное копирование образов виртуальных машин предоставляет наиболее оптимальное соотношение стоимости и скорости восстановления данных. Эта технология позволяет сохранить на любой носитель виртуальную машину целиком (операционную систему, приложения и данные), без ее остановки. Для восстановления поврежденных данных достаточно будет скопировать и запустить резервную копию машины, а, если потребуется, восстановить на файловом уровне из сохраненного образа машины. Конечно, учитывая размер виртуальной машины, данный способ восстановления не самый быстрый, однако обеспечивает достаточную скорость для восстановления не критичных для бизнеса приложений. Реализация данного способа не требует установки программных агентов внутри виртуальной машины и поэтому, как правило, нет необходимости покупки отдельных лицензий для каждой машины. Согласно политике VMware, лицензирование большинства продуктов базируется на количестве физических процессоров используемых VMware ESX Server.

Репликация образов виртуальных машин — создание копии машины на резервном сервере обеспечивает минимальное время восстановления виртуальных машин. Данный способ является самым дорогим видом резервного копирования, но и самым эффективным для критически важных виртуальных машин, работа которых не должна прерываться никогда. В зависимости от типа и важности приложения репликация виртуальной машины может производиться несколько раз в день, гарантируя актуальность резервной копии. И в случае сбоя, для восстановления виртуальной машины требуется лишь запустить ее резервную копию. Высокая стоимость этого метода объясняется тем, что для создания реплики необходим резервный ESX Server и место в хранилище SAN/iSCSI, а зачастую требуется также покупка лицензий для каждой виртуальной машины.

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

Булат Латыпов (Bulat.Latypov@veeam.com) — сотрудник компании Veeam Software (Москва).

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF