Виртуализация переживает ренессанс, а реляционные базы данных обречены

Сергей Кузнецов

Обзор майского, 2005 г. номера журнала Computer (IEEE Computer Society, V. 38, No 5, May 2005).

Авторская редакция.
Также обзор опубликован в журнале "Открытые системы"

Наконец-то опять вышел настоящий тематический номер журнала, подготовленный специально приглашенными редакторами, с большой (пять статей) тематической подборкой. Тема номера стара, жива и безгранична – "Технологии виртуализации" ("Virtualization Technologies"). В номере три приглашенных редактора: Ренато Фигьюиредо, Питер Динда и Хосе Фортес (Renato Figueiredo, University of Florida, Peter A. Dinda, Northwestern University,  Jose Fortes, University of Florida). Свою вводную заметку они назвали "Ренессанс виртуализации ресурсов" ("Resource Virtualization Renaissance"). В 1992 г. в своей Тьюринговской лекции Батлер Лэмпсон (Butler Lampson) процитировал следующее замечание Дэвида Уиллера (David Wheeler): "Никакая проблема компьютерных наук не может быть решена без привлечения дополнительного уровня косвенности". И действительно, уровень косвенности, вводимый путем виртуализации ресурсов, все чаще используется при решении многих проблем компьютерных систем в областях безопасности, оптимизации производительности, системного администрирования, надежности и т.д. Хотя история подхода виртуализации ресурсов насчитывает десятилетия, в последние годы снова активизировался интерес к этому подходу. Успешные коммерческие продукты компаний VMware и Microsoft расширяют область применения виртуальных машин компьютерными платформами массового спроса. Потребности виртуализации приводят к расширению систем команд массовых микропроцессоров (примерами являются VT/Vanderpool от Intel и Pacifica от AMD). В сообществе Open Source разработаны стабильно работающие виртуальные серверы (VServer, Usermode Linux) и паравиртуальные машины (Xen). VM языкового уровня (Sun Java VM, Microsoft CLR) работают на разнообразных платформах, от встроенных до серверных систем. На предприятиях повсеместно используются виртуальные LAN или частные сети (VLAN, VPN). В системных сетях для упрощения управления сложными, неоднородными конфигурациями запоминающих устройств используется виртуализация запоминающих устройств.

Технологии виртуализации основываются на разнообразных механизмах и методах, используемых для разъединения архитектуры и ожидаемого пользователями поведения аппаратных и программных ресурсов и их физической реализации. Ключевым моментом виртуализации ресурсов является введение уровня косвенности ниже среды выполнения, видимой приложениями и операционными системами. Базовый компонент виртуальной машины, монитор виртуальной машины (VMM), обеспечивает уровень между программными средами и физической аппаратурой, являющийся программируемым, прозрачным для вышележащего программного обеспечения и поддерживающий эффективное использование нижележащей аппаратуры. На основе косвенности VMM и аналогичные методы виртуализации сетей и запоминающих устройств предоставляют возможность совместного использования одного физического ресурса многими виртуальными системами, изолированными одна от другой. Включение нового уровня абстракции ниже уровней существующих абстракций заметно отличается от традиционного подхода построения нового уровня абстракции поверх существующего уровня абстракции.

VMM, называемые также гипервизорами, впервые получили известность в начале 1970-х.-Коммерческий успех подхода был достигнут в серии мейнфреймов IBM 370. Применение виртуализации позволило запускать на мейнфреймах одновременно несколько операционных систем, что способствовало эффективному использованию дорогостоящей аппаратуры в режиме разделения времени без потребности в модификации унаследованных программных систем, включая однопользовательские ОС. Роберт Гольдберг в своем обзоре, опубликованном 30 лет тому назад (R.P. Goldberg, “Survey of Virtual Machine Research”, IEEE Computer Magazine, vol. 7, No 6, 1974), наряду с ключевым аспектом – укрупнением серверных платформ, выделял следующие преимущества подхода виртуальных машин: возможность смешивания пакетной и других видов обработки, поддержка интерактивных приложений и задач разработки, повышение уровня безопасности и надежности данных. С наступлением эпохи недорогих суперкомпьютеров и персональных компьютеров потребность в виртуализации уменьшилась. Хотя VMM (VM/386) и даже аппаратная поддержка VM (режим V8086) для PC существовали в 80-е и начале 90-х гг. прошлого века, только с появлением в конце 90-х Virtual PC и продуктов компании VMware стали доступны такие VMM для массовых компьютерных платформ, на которых можно запускать любую ОС. Хотя современные серверы намного дешевле и гораздо мощнее машин прошлых десятилетий, их полная стоимость владения включает техническое обслуживание, поддержку, администрирование, а также затраты, связанные с брешами в безопасности и сбоями системы. Поэтому укрупнение серверных платформ остается движущей силой виртуализации, несмотря на то, что исследовательские организации и коммерческие компании особенно заинтересованы в улучшении безопасности и доступности. Сегодня широко используются VMM от VMware и Microsoft, причем не только в серверных средах, но и на персональных компьютерах, позволяя использовать разные ОС, обычно Windows и Linux.

Заметка приглашенных авторов, на мой взгляд, является хорошим введением в тему, но по-настоящему фундаментальным техническим введением является первая статья тематической подборки. Она называется "Архитектура виртуальных машин" "The Architecture of Virtual Machines" и написана Джеймсом Смитом (James E. Smith, University of Wisconsin-Madison) и Рави Наиром (Ravi Nair, IBM T.J. Watson Research Center). Освобождая разработчиков и пользователей от традиционных ограничений интерфейсов и ресурсов, виртуальные машины улучшают интероперабельность программного обеспечения, снижают уровень уязвимости систем и снимают проблему изменчивости платформ. Однако, поскольку VM производятся различными группами и с разными целями, понятия VM относительно мало унифицированы. Поэтому авторы считают полезным отступить на шаг назад, рассмотреть многообразие архитектур VM и описать их единообразным способом, принимая во внимание как используемое понятие виртуализации, так и тип VM. Для понимания того, что из себя представляет виртуальная машина, необходимо, прежде всего, уяснить смысл термина "машина" с процессной и системной точек зрения. С точки зрения процесса, в котором выполняется некоторая пользовательская программа, машина состоит из логического адресного пространства, приписанного данному процессу, а также команд и регистров пользовательского уровня, позволяющих выполнять программный код. Единственный способ взаимодействия процесса с системой ввода/вывода основывается на вызовах ОС. Так что процесс "видит" машину через ABI (Application Binary Interface), а для программы, написанной на языке высокого уровня, характеристики машины определяются API (Application Programming Interface). С точки зрения ОС и поддерживаемых ей приложений вся система выполняется на соответствующей машине. Система распределяет между процессами память и ресурсы ввода/вывода, а также обеспечивает средства межпроцессного взаимодействия. С системной точки зрения машину определяют характеристики аппаратуры, и интерфейс между системой и машиной определяется ISA (Instruction Set Architecture). Соответственно, выделяются процессные и системные VM. Процессная VM – это виртуальная платформа, предназначенная для выполнения индивидуального процесса. В отличие от этого, системная VM обеспечивает полную, постоянно существующую среду, поддерживающую ОС и набор пользовательских процессов. Для ОС обеспечивается доступ к виртуальным аппаратным ресурсам, включающим процессор, память, средства ввода/вывода, а также, возможно, GUI. Виртуализирующее программное обеспечение VM обычно называют монитором виртуальной машины (VMM). Далее в статье описываются основные архитектурные особенности VM этих двух разновидностей. По поводу процессных VM обсуждаются эмуляторы и динамические двоичные трансляторы на уровне ISA; возможности оптимизации бинарного кода в случае, когда ISA виртуальной и реальной машин совпадают; особенности процессных VM, ориентированных на поддержку языков высокого уровня. Для системных VM приводится дальнейшая классификация на классические VM (VMM работает на "голой" аппаратуре, а над ним располагаются VM); "гостевые" VM (виртуализирующее программное обеспечение располагает поверху существующей ОС); полносистемные VM (VM, эмулирующие код и приложений, и операционной системы); мультипроцессорные VM (VM, разбивающие крупные симметричные платформы на несколько более мелких); наконец, VM, поддерживающие ISA, для которой еще отсутствует аппаратная реализация (codesigned VM). В завершение статьи приводится рисунок, изображающий общую таксономию VM.

Следующая статья развивает тему вглубь. Авторы статьи – Мендель Розенблюм (Mendel Rosenblum, Stanford University, VMware Inc.) и Тэл Гарфинкель (Tal Garfinkel, Stanford University), и она называется "Мониторы виртуальных машин: современная технология и тенденции будущего" ("Virtual Machine Monitors: Current Technology and Future Trends"). В 90-е годы прошлого века исследователи Стэнфордского начали изучать возможности подхода виртуальных машин для преодоления трудностей, вызываемых ограничениями аппаратуры и операционных систем. В это время проблемы порождались машинами массивно-параллельной обработки (MPP), для которых было трудно программировать, и на которых нельзя было использовать существующие ОС. Применив подход виртуальных машин, исследователи обнаружили, что они могут сделать эти неуклюжие архитектуры настолько похожими на существующие платформы, что на них можно будет запускать имеющиеся ОС. Из этого проекта вышли люди и идеи, послужившие основой компании VMware (www.vmware.com), основного поставщика VMM для компьютерной архитектуры массового спроса. В 90-е гг. стали проявляться проблемы, связанные с расширением возможностей ОС и удешевлением аппаратуры. Снижение стоимости привело к резкому увеличению числа машин, но эти машины часто недоиспользовались. Кроме того, росли накладные расходы, связанные с потребностями рабочих площадей и управлением. Расширяющаяся функциональность ОС одновременно увеличивала их уязвимость. Для снижения уровня последствий системных аварийных ситуация системные администраторы возвращались к вычислительной модели с одним приложением на машине. Это, в свою очередь, повышало требования к аппаратуре, что снова приводило к возрастанию накладных расходов. Перемещение приложений, выполняемых на многочисленных физических машинах, на VM и консолидация этих VM на небольшом числе физических платформ повышали эффективность использования и позволяли сократить накладные расходы. Таким образом, способность подхода VMM к мультиплексированию аппаратуры привела к возрождению его широкого применения в терминах укрупнения серверов и практичного компьютинга. Как полагают авторы, в будущем методы VMM станут в большей степени служить для повышения безопасности и надежности. Во многих случаях VMM дает дополнительную возможность разработчикам ОС по обеспечению функциональности, не свойственной современным ОС. Далее в статье рассматриваются вопросы реализации VMM: виртуализация центральных процессоров, основной памяти и ввода/вывода. По поводу каждой темы излагаются основные проблемы, описываются текущие методы и приводятся прогнозы на будущее. В заключительной части статьи обсуждаются варианты использования подхода VM в будущем (естественно, в контексте новых программных средств, разрабатываемых компанией VMware).

У статьи "Технология виртуализации Intel" ("Intel Virtualization Technology") десять авторов (все из компании Intel Corporation). Первый в списке Рич Улиг ( Rich Uhlig, адрес e-mail не указан). Ранее ограниченная рамками специализированных, высокопроизводительных платформ серверов и мейнфреймов, виртуализация становится теперь более широко доступной и поддерживается в готовых к использованию системах, основанных на IA (Intel Architecture). Отчасти это происходит благодаря постоянному повышению эффективности IA-систем, что позволяет снизить накладные расходы, связанные с виртуализацией. Другие факторы включают новые подходы к созданию программного обеспечения, позволяющие справиться с трудностями виртуализации IA. Содержательная часть статьи начинается именно с анализа проблем, с которыми приходится сталкиваться при виртуализации IA-32 и Itanium. Для решения этих проблем разработчики VMM обычно применяют подход паравиртуализации, при котором производится модификация программного обеспечения (в исходном тексте или бинарном представлении) до его запуска на VMM. Технология виртуализации Intel ориентирована на то, чтобы избежать потребности в подобных преобразованиях. Эта технология включает два компонента: VT-x для поддержки виртуализации IA-32 и VT-i – для виртуализации архитектуры Itanium. Приводится краткое описание обоих компонентов и поясняется, каким образом технология виртуализации Intel справляется с отмеченными ранее решениями.

Эндрю Витайкер, Ричард Кокс, Марианн Шоу и Стивен Гриббл (Andrew Whitaker, Richard S. Cox, Marianne Shaw, Steven D. Gribble, University of Washington) представили небольшую статью под названием "Пересмотр архитектуры мониторов виртуальных машин" ("Rethinking the Design of Virtual Machine Monitors"). Исследовательская группа Вашингтонского университета, изучая возможности применения VMM для решения проблем безопасности, надежности и системного администрирования, столкнулась с тем, что при традиционном подходе к построению VMM возникают ограничения масштабируемости и расширяемости. В течение нескольких последних лет группа разработала собственный VMM Denali (denali.cs.washington.edu), основанный на идеях паравиртуализации и вмешательства в аппаратуру (hardware interposition). Паравиртуализация в Denali означает отличие архитектуры виртуальной аппаратуры от архитектуры базовой физической аппаратуры. Соответствующая характеристика Denali позволяет поддерживать сотни одновременно выполняющихся VM с одним VMM. Возможность вмешательства в аппаратуру позволяет программистам расширять VMM за счет новых реализаций компонентов виртуальной аппаратуры, например, виртуальных дисков или устройств Ethernet. Эти новые аппаратные компоненты могут существенно отличаться от реальных устройств. Например, в новой реализации виртуального диска может поддерживаться шифрование или доступ к сетевому устройству хранения данных. Расширение возможностей VMM Denali производится путем использования инструментальной системы mDenali, поддерживающей соответствующий API.

Последняя статья тематической подборки называется "Виртуальные распределенные среды в совместно используемой инфраструктуре" ("Virtual Distributed Environments in a Shared Infrastructure"). Статью написали Пол Рат, Ксуксиан Джианг, Донгян Ксу и Себастайн Гоасгуен (Paul Ruth, Xuxian Jiang, Dongyan Xu, Sebastien Goasguen, Purdue University). Многие пользователи Grid знакомы с традиционной моделью предоставления и исполнения заданий, а также с моделью сервис-ориентированного доступа, определенной в спецификации OGSA (Open Grid Services Architecture). Основываясь на технологии GRAM (Grid Resource Allocation and Management), Grid обеспечивает единый, скрывающий детали интерфейс для запроса и использования сетевых ресурсов, на основе которых исполняются задания, предоставляемые пользователями. Модели заданий и сервисов обеспечивают приемлемую парадигму совместного использования ресурсов и исполнения программ. Однако некоторые приложения являются в большей степени операционными, а не функциональными, и их трудно отобразить на независимые задания или услуги. К таким приложениям относится, например, детальная эмуляция систем реального мира, таких как функционирующий аэропорт. Для многих других приложений требуется специальным образом конфигурированная и настроенная среда исполнения, включающая ОС, сервисы сетевого и прикладного уровней, пакеты и библиотеки. Например, для многих научных приложений требуются математические и коммуникационные библиотеки, а для Java-приложения может понадобиться конкретная версия Java VM. В совместно используемой инфраструктуре не всегда возможно удовлетворить такие требования. Кроме того, требования разных приложений могут конфликтовать. Наконец, невозможно предотвратить запуск пользователями потенциально ненадежных или ошибочных приложений. Ошибки или уязвимости могут появляться в приложениях как случайным, так и преднамеренным образом. Важно не допустить каскадного распространения последствий сетевой атаки на такое приложение на другие приложения или на совместно используемую инфраструктуру. Авторы предлагают парадигму для выполнения подобных приложений, основанную на интеграции и расширении технологий VM и виртуальных сетей. Разработанное программное обеспечение промежуточного уровня поддерживает взаимно изолированные виртуальные распределенные среды в совместно используемых инфраструктурах. В основе подхода лежит ранее созданная авторами технология виртуальных сетей Violin.

Единственная большая статья номера, не вошедшая в тематическую подборку, называется "Обманчивые архитектурные компромиссы" ("Misleading Architecting Tradeoffs") и написана Тоном Костелийком (Ton Kostelijk, Philips Applied Technologies, Netherlands). Ключевые архитектурные решения обычно принимаются на основе качественных рассуждений, которые должны базироваться на конкретных количественных аргументах и фактах. Плохо аргументированные качественные рассуждения могут привести к архитектуре, которая впоследствии оказывается ошибочной. К счастью, такие рассуждения можно выявить и исправить, как это произошло при разработке DVD-рекордера. При эволюции этого продукта обнаружилось несколько ошибок, в частности, необоснованное принятие компромиссного решения. Компромисс предполагает, что улучшение в одном измерении отрицательно влияет на другие измерения. Существуют обоснованные, правомерные компромиссы, но в них нуждаются не все решения. Серьезное усовершенствование в одном измерении проектного пространства может привести к совершенствованию других измерений, даже если эти возможности противоречат принятому мнению или общим эвристикам. Например, известный компромисс между скоростью ЦП и объемом памяти применим не всегда. В приложениях с ограниченной локальностью кода оптимизация с целью сокращения объема кода для экономии памяти заодно убыстряет обработку, поскольку сокращается работа по выборке кода. Проект разработки DVD-рекордера представляет яркий пример преобразования абстрактных мнений и конкретные, осязаемые аргументы. С точки зрения набора требований архитектурные решения затрагивают функциональность, надежность и стоимость продукта, время и стоимость разработки. В техническом отношении системное решение для DVD-рекордера требовало от разработчиков выбора варианта с одной или двумя интегральными схемами (ИС) с ЦП в каждой из них. Должны были учитываться последствия для программного обеспечения и общие требования. Рассуждения основывались на конкретных данных о нагрузке шины и ЦП. Эти показатели исследовались на модели архитектуры. Хотя вначале наиболее подходящим кандидатом казалась архитектура с двумя ИС, исследования показали преимущества архитектуры с одной ИС. Эта архитектура позволяет использовать больше компонентов существующих систем, требует меньших усилий от разработчиков и позволяет существенно снизить стоимость продукта.

Наконец, мне показалась интересной заметка Дэвида Кренке (David Kroenke, University of Washington) "За пределами реляционной модели данных" ("Beyond the Relational Database Model"), опубликованная в разделе "IT Systems Perspectives". Многим читателям, вероятно, знакомо это имя, потому что перевод девятого издания его книги под названием "Теория и практика построения баз данных" вышел в этом году в издательстве "Питер". В этом же году автор выпустил десятое издание своей книги ("Database Processing: Fundamentals, Design, and Implementation", Prentice Hall, 2005), в котором одна глава посвящена хранению XML-данных. В ней утверждается, что, в конце концов, хранилища XML-данных приведут к исчезновению реляционных баз данных. Шокированные рецензенты рекомендовали автора смягчить тон главы, но он предпочел написать эту заметку, чтобы публично разъяснить свое мнение об "обреченности реляционной модели баз данных" (автор действительно использует термин "relational database model", а не "relational data model"; одно это может позволить "заклевать" его сторонникам реляционной модели данных). Я впервые встречаюсь с подобным экстремизмом, и мне показалось забавным коротко пересказать доводы автора. Первый довод восходит к метафоре Эстер Дайсон (на которую автор не ссылается), которую она ввела в то время, когда многим казалось, что на смену реляционным придут объектно-ориентированные базы данных. Она сравнила нормализованную реляционную базу данных с гаражом, в котором хранятся полностью разобранные автомобили. Перед использованием машины нужно ее собрать, а перед установкой в гараж – полностью разобрать. По мнению автора, подоплека реляционной модели лежит в следующем. Реляционная модель является теоретико-множественной моделью для описания элементов данных, распространенных в бизнес среде. В 70-е гг. прошлого века наличие подобной теории требовалось для придания легитимности направлению управления данными. В реляционных базах данных минимизировалась избыточность данных, что обеспечивало целостность данных и сокращало требования к внешней памяти. В 70-е гг. особенно важным был второй фактор, поскольку возможности дисков были очень ограниченными. Реляционная модель обеспечивала способ представления элементов данных переменного размера путем использования компонентов фиксированного размера. Это было очень важно при переходе от магнитных лент к устройствам внешней прямого доступа. Теория нормализации вызвала появление сотен статей и многочисленных профессорских позиций. Это побуждало академическое сообщество к дальнейшему продвижению реляционной модели. Наконец, следуя открытым стандартам, включающим SQL, компании создали десятки реляционных СУБД. Далее автор утверждает, что хранилища XML-данных обладают многочисленными преимуществами перед реляционными базами данных (недостаточно убедительными, с моей точки зрения, чтобы о них говорить), а присущие им недостатки таковыми не являются (избыточность данных не страшна, поскольку дисковая память ничего не стоит; иерархичность и вовсе недостатком не является; высокая производительность систем управления XML-данными будет со временем достигнута). По мнению автора, для того, чтобы сделать хранилища XML-данных реальностью, нужны, прежде всего, методы и средства управления дублирующими данными, включая поддержку согласованности. Требуются новые подходы к проектированию структур данных. Нужны развитые средства управления версиями XML-документов. Требуется также механизм для разрешения двусмысленностей схем XML-документов. Должна иметься возможность определения степени из сходства любых двух документов встречающихся в кибер-пространстве. Опыт объектно-ориентированных СУБД учит нас, что ни одна организация не станет переходить на другую технологию, требующую преобразование миллиардов байт реляционных данных к другому формату, без понимания материальной выгоды. В настоящее время имеется средство позволяющее легко конвертировать реляционные баз данных в XML-документы. Осталось только найти место, куда их сложить.

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