Новейшую историю виртуализации можно условно разделить на два периода. Первый начался в 1998 году и продолжался несколько лет. В эти годы наиболее характерным было распространение и проповедование (или, как теперь говорят, «евангелизм») идей виртуализации в широких массах; одновременно в нескольких компаниях шла активная разработка практических технологий. А когда сумма технологий достигла критической массы, начался нынешний, второй период — активное внедрение. О популярности виртуализационных решений сегодня можно судить хотя бы по такому факту: в 2006 году в мире работало более миллиона виртуализированных серверов. Не случайно годом раньше аналитики Gartner назвали виртуализацию мегатенденцией. Это был знаковый момент: с тех пор термин «виртуализация» не сходит со страниц печати, сайтов и блогов. Впрочем, для серьезного наблюдателя особой неожиданности и сенсационности во внимании к виртуализации нет. В области виртуализации многое делали еще во времена мэйнфреймов и мини-ЭВМ, но потом о ней почти на десять лет забыли. Однако в течение нескольких последних лет виртуализация восстановила свою былую популярность и ныне по частоте обсуждения уступает разве что сервис-ориентированным архитектурам (Service-Oriented Architecture, SOA). Чем же вызвано, казалось бы, это неожиданное возрождение, которое один из основоположников и столпов современной виртуализации, Мендель Розенблюм, создатель и технический руководитель компании VMware, назвал «ренессансом виртуализации»?
Как и в ряде других случаев, за явно избыточным маркетинговым шумом у происходящего вокруг виртуализации есть вполне объективные причины. Необычно заинтересованное отношение публики и к SOA, и к виртуализации можно объяснить прежде всего особым значением этих технологических направлений для будущего компьютерной отрасли в целом. Обратившись к истории, нетрудно убедиться в том, что все свои шесть десятилетий компьютерные системы совершенствовались, подчиняясь отдельным эмпирическим решениям, проще говоря, прогрессировали методом «проб и ошибок». Но любой сделанный выбор, вполне адекватен и актуален на момент принятия решения, по происшествии времени обнаруживает свойственные ему органические слабости. Относительно небольшие коррективы курса, компенсирующие такие слабости, принято обозначать термином «сдвиг парадигмы», заимствованным из трудов американского историка науки Сэмюэла Куна (1922-1995). По Куну, парадигма — это некая концептуальная схема, которая признается инженерным или научным сообществом в качестве основы его практической деятельности, но по мере накопления знаний она заменяется следующей парадигмой, происходит сдвиг парадигмы (заметим — не «отказ», а именно «сдвиг»). Такой естественный путь, состоящий из последовательно чередующихся этапов, специалисты по науковедению называют «нормальной наукой».
Но иногда складываются аномальные условия, из которых путем сдвига выйти невозможно; в таких случаях следует говорить о кризисе существующей парадигмы. Выход из подобного рода кризиса может быть осуществлен принятием более радикальных мер — не сдвигом, а полным или частичным вытеснением старой парадигмы новой парадигмой-преемником. Сервисные архитектуры и виртуализация, скорее всего, представляют собой примеры именно таких новых, вытесняющих парадигм.
Если рассмотреть в качестве примера SOA, то здесь ключевым моментом вытеснения стал переход от жестко связанных систем к системам со слабыми связями. В традиционной инженерии действительно ничего подобного прежде не было: ни мосты, ни самолеты на слабых связях построить невозможно, но, скажем, отказ от парадигмы в конструировании самолетов произошел тогда, когда нужно было перейти через звуковой барьер. Отказ от прежней парадигмы в пользу SOA вызван прежде всего непреодолимыми проблемами, связанными с той сложностью, которой достигают монолитные системы в процессе своего эволюционного развития. Новую парадигму, SOA, можно подвергать критике, но не признать ее неизбежность нельзя.
Примерно то же самое можно сказать и о виртуализации. В данном случае кризисная ситуация была вызвана множеством причин, но прежде всего, казалось бы, сугубо технической проблемой, а именно низкой эффективностью использования процессорных ресурсов серверов, особенно на платформе x86. Еще пять–семь лет назад о недоиспользовании вычислительных ресурсов ПК-серверов как о конкурентном недостатке чаще всего говорили представители мира RISC; они аргументировали преимущества своих продуктов, оценивая их загруженность десятками процентов, а CISC-альтернатив — единицами процентов. Сегодня общепризнанно, что загруженность серверов x86-архитектуры не превышает 5-15%. Для сравнения, известно, что паровозы, ставшие символами низкого коэффициента полезного действия, в среднем имели коэффициент, равный 8%. В лучших образцах этот показатель доходил до 15%. Ситуация и в самом деле фантастическая: самая современная техника имеет КПД «ниже паровоза». Пока не наступила эпоха коммодитизации и серверы не стали продуктами массового потребления, низкий КПД был хорошим аргументом в пользу принятия альтернативных решений; однако сегодня в большинстве приложений альтернативы серверам нет, с этим согласны даже самые яростные адепты RISC-идеи. Особенно остро проблема недозагрузки проявляется в центрах обработки данных, насчитывающих в своем составе сотни или тысячи серверов.
Единственным просматриваемым решением, которое позволит поднять КПД серверов «выше паровоза», представляется виртуализация, то есть замена физических машин виртуальными. На практике без особых усилий коэффициент загруженности серверов удается поднять до 85%, а то и выше. Приведем далеко не полный список преимуществ, которые обеспечивает виртуализация.
-
Виртуальная машина может быть использована для консолидации нагрузки отдельных недогруженных серверов на меньшем количестве серверов или даже на одном. Таким образом можно повысить КПД, сэкономить на стоимости аппаратуры и управлении, на затратах на поддержание окружающей среды и на администрирование.
-
Виртуализация позволяет сохранить аппаратную и программную среду для унаследованных приложений в тех случаях, когда появляются новые компьютеры; она облегчает условия миграции программного обеспечения и данных на новые платформы.
-
Средства виртуализации упрощают создание надежных платформ. Ненадежные приложения могут быть взаимно изолированы, разведены по своим «песочницам» (sandbox). Виртуализация помогает моделировать среду, где одновременно работают несколько операционных систем.
-
При разработке программы можно априорно определить ограничения той среды, в которой она будет работать.
-
Виртуальная машина может воплощать в себе реально не существующие, еще только разрабатываемые аппаратные средства и сетевые соединения.
-
Средства виртуализации могут стать важнейшим инструментом при более широком распространении многоядерных процессоров; за счет их использования можно масштабировать системы, увеличивая количество физических процессоров или процессорных ядер на порядки.
Объединение ресурсов в единый пул с последующим гибким распределением этих ресурсов открывает множество возможностей — это и создание отказоустойчивых конфигураций, и оптимизация резервного копирования, и управление жизненным циклом информации, и многое другое.
Предпосылки к виртуализации
В широком смысле под виртуализацией понимают разнообразные методы, служащие для абстрагирования от различных физических ресурсов компьютеров. Возможно, первым примером виртуализации стала замена физических адресов логическими или символическими адресами в языке ассемблера. Впоследствии активно развивались подходы к виртуализации оперативной памяти, как одного из самых дорогостоящих ресурсов. Иногда виртуализацию упрощенно интерпретировали как создание оболочек, скрывающих внутреннее устройство какого-либо ядра, называя такие подходы «луковичными» или «капустными». В Wikipedia можно найти следующее определение: «Виртуализация — это разнообразные методы сокрытия физических ресурсов компьютеров от тех систем, приложений и пользователей, которые взаимодействуют с этими ресурсами». Средствами виртуализации можно один физический ресурс (сервер, операционная система, приложение, накопитель) представлять в форме множества раздельных логически независимых ресурсов и, наоборот можно объединять множество отдельных физических ресурсов (серверов, накопителей) в единый логический ресурс.
Все разнообразие виртуализируемых компьютерных ресурсов делится на два подмножества. Одно из них можно условно назвать подмножеством пассивных ресурсов, к нему относится оперативная память, жесткие диски, каналы ввода/вывода. Обычно входящие в это подмножество компоненты не имеют свойств к самовиртуализации, они управляются «сверху»; для выполнения этой функции нужен специализированный контроллер. Пассивным может быть и процессор — в случае, если его ресурсы виртуализируются средствами операционной системы, которая выполняет задачу контроллера, используя механизмы логических разделов, контейнеров и т.п. Решения этого типа виртуализационных задач являются пусть и сложными, но в полном смысле этого слова инженерными.
Другое подмножество ресурсов — активное, это процессоры, способные виртуализировать самих себя, преобразуя физические машины в виртуальные машины (Virtual Machine, VM). Это уникальное свойство компьютеров, отличающее их от любых иных машин; оно, собственно, и делает возможным создание новой парадигмы.
Существует несколько технологий такого рода виртуализации — мониторы виртуальных машин (Virtual Machine Monitor, VMM), в том числе системные эмуляторы, гипервизоры, виртуализация на уровне операционных систем и др.
Граница между этим двумя подмножествами является размытой, некоторые методы виртуализации могут быть отнесены к обоим подмножествам.
Теоретическая возможность виртуализации процессоров обосновывается известным тезисом Черча—Тьюринга. Его основное содержание сводится к предположению о возможности моделировать на компьютере машину Тьюринга. Из этого предположения делается вывод о том, что с точки зрения своего потенциала как инструмента для решения алгоритмических проблем все компьютеры, вне зависимости от их конкретного исполнения, эквивалентны. Следовательно, решая некоторую задачу, мы можем заменить один компьютер другим, в том числе физический компьютер на виртуальный. Эти утверждения нельзя назвать строгими: тезис Черча—Тьюринга не является доказанной теоремой, но тем не менее он позволяет утверждать, что одна вычислительная среда может быть промоделирована другой средой.
Тезис Черча—Тьюринга открывает возможность для имитации или моделирования одного компьютера на другом, в частности физического компьютера средствами виртуальной машины. В прикладном смысле первым эту идею высказал Кристофер Стречи в 1959 году. Увы, он крайне неудачно назвал свой метод «разделением времени»; позже то же самое название стали использовать для разделения физических ресурсов процессоров в мэйнфреймах, это был простой процесс «нарезания» программам соответствующих их приоритету временных интервалов. Стречи же имел в виду совершенно иное: он хотел распределить время более изящно, путем моделирования разных заданий в одном потоке команд. Позже он подчеркивал это в письме Дональду Кнуту, автору «Искусства программирования». По идеям Стречи в начале 60-х годов в компьютере Atlas была реализована виртуальная машина, для чего в ней использовался специальный супервизор и команды его вызова, названные экстракодами.
Как бы ни была красива идея виртуализации, высказанная Стречи в конце 50-х, она не могла стать практическим средством для распределенного доступа к вычислительным ресурсам, пока электроники было мало, количество транзисторов в компьютерах исчислялось тысячами, а аппаратное обеспечение было существенно дороже, чем программы. Поэтому дальнейшее совершенствование систем разделения времени и мультипрограммирования пошло по пути развития операционных систем. В итоге сложилась довольно странная ситуация, когда процессоры развивались, подчиняясь своим закономерностям, а операционные системы — своим. Сливая два потока, все же каким-то образом удавалось строить компьютерные системы, в том числе серверы. Эффективность этих систем во многом зависит от степени согласованности архитектуры процессоров и серверов с операционной системой. Если она удачна, как исторически сложилось в паре RISC/Unix (особенно в тех случаях, когда операционная система и серверы поставляются одним вендором), серверы могут использоваться с эффективностью 25-30% и даже выше. Массовые же серверы на платформе x86 обычно используются с эффективностью не выше 5-15%.
Эти показатели означают, что классические операционные системы концептуально не в состоянии с достаточной эффективностью управлять вычислительными ресурсами. Иными словами, путь, которым развивались компьютерные системы, оказался в определенной мере тупиковым. Особенно очевидным этот тупик делают многоядерные процессоры, выявившие ограниченность поддержки многопроцессорных систем в современных ОС. Единственный выход заключается в создании промежуточного слоя между аппаратной и программной частью, виртуализирующей аппаратные ресурсы, и передаче ей полномочий на управление на физическом уровне. В этом состоит революционное значение новой парадигмы; это уже не сдвиг, а отказ от старой парадигмы.
Аппаратные ограничения
Важные теоретические исследования относительно возможности виртуализации процессоров были сделаны Джералдом Попеком и Робертом Гольдбергом и опубликованы в статье «Формальные требования для виртуализации архитектур третьего поколения» (Formal Requirements for Virtualizable Third Generation Architectures, 1974). В названии статьи упомянуты актуальные на тот момент компьютеры третьего поколения, однако она полностью сохранила свою значимость до настоящего времени; сделанные в ней выводы ничуть не устарели. Попек и Гольдберг определили ограничительные условия, при которых компьютерная архитектура может быть виртуализирована, сформулировав их в виде трех критериев виртуализации.
-
Эквивалентность. Монитор VMM должен следить за тем, чтобы программа выполнялась в среде, почти полностью соответствующей среде невиртуализированной машины, за несколькими исключениями. Исключения распространяются на доступность системных ресурсов, временную диаграмму процессов и подключенные периферийные устройства.
-
Полнота управления. VMM должна быть способной управлять всеми системными ресурсами, но не выходя за отведенные для нее границы ресурсов.
-
Эффективность. Значительная часть машинных команд должна выполняться без участия VMM, а те команды, которые не могут быть выполнены, должны интерпретироваться средствами VMM.
Большое внимание в работе Попека и Гольдберга уделено исследованию системы команд процессора на предмет возможности его виртуализации. За время, прошедшее с тех пор, когда Стречи сделал первые попытки виртуализации, системы команд существенно усложнились, в дополнение к классически арифметическим, логическим и командам управления типа условного или безусловного перехода появились специфические команды диспетчеризации. Эти команды усложняют состояние процессора и тем самым затрудняют виртуализацию. Попек и Гольдберг классифицировали все команды по трем группам:
-
привилегированные — команды, осуществляющие программное прерывание (trap), если они выполняются в пользовательском режиме работы процессора, и не вызывают программное прерывание, если работают в системном режиме;
-
чувствительные к управлению — команды, которые пытаются изменить конфигурацию ресурсов системы;
-
чувствительные к поведению — команды, чье поведение зависит от состояния ресурсов системы, например от содержимого системных регистров.
Далее Попек и Гольдберг показали, что построение VMM возможно, если набор чувствительных к поведению команд является подмножеством набора привилегированных команд, и сделали еще несколько полезных выводов, облеченных в форму теорем о виртуализации. Практически все современные процессоры — и особенно процессоры x86-архитектуры — не соответствуют сформулированным критериям. Но тем не менее виртуализировать их необходимо; следовательно, требуются специальные механизмы компенсации, адаптирующие процессоры к приведенным выше критериям. Первой эту работу выполнила компания VWware, за ней последовали еще несколько компаний, которые, как и она, смогли решить эту задачу программными средствами. Позже на этот путь вступили производители процессоров, AMD и Intel. То, что сейчас делают инженеры двух лидеров микропроцессорного рынка, можно назвать латанием виртуализационных дыр. Эти дыры сложились из-за того, что самые массовые процессоры, изначально задуманные как «бытовые приборы», проектировались без учета предполагаемой в будущем виртуализации. Между тем классическая школа проектирования компьютерных систем, уходящая корнями в системы IBM/360 и VAX, считала обеспечение виртуализации обязательным атрибутом.
Основные подходы к виртуализации серверов
Сегодня можно выделить три основных подхода к решению задачи виртуализации серверов.
-
Виртуальная машина эмулирует реальное аппаратное обеспечение, что позволяет использовать в качестве гостевых обычные, немодифицированные операционные системы, а команды, требующие себе особых привилегий, отрабатываются средствами VMM. В категорию естественной виртуализации попадают продукты VMware и Microsoft и компаний-«стартапов» наподобие QEMU.
-
Паравиртуализация. По существу, паравиртуализация отличается распределением функций между VM и VMM. В данном случае основная работа выполняется гостевыми ОС и только отдельные функции отставлены за операционной системой VMM. Это неполная виртуализация, добавление «пара» можно было бы с равным успехом заменить на «квази» или «псевдо», но в англоязычной литературе принят именно термин «паравиртуализация». Наиболее яркий пример — Xen и UML.
-
Виртуализация на уровне операционных систем. Этот тип виртуализации позволяет в рамках одной операционной среды выделить разделы для выполнения независимых гостевых операционных систем. Наиболее известные проекты: Linux-VServer, Virtuozzo, OpenVZ, Solaris Containers и FreeBSD Jails. Все они концептуально близки друг другу, так или иначе на физических серверах средствами операционной системы создаются частные виртуальные серверы (virtual private server), что, по существу, является разбиением ресурсов на независимые разделы, которые называют «контейнерами» или даже «тюремными камерами». Практически все производители операционных систем снабжают сегодня свои продукты виртуализационной функциональностью. Например, компания HP расширила функциональность и упростила развертывание и виртуализацию критичных бизнес-задач в окружении HP-UX 11i v3.
Отдельную область образуют задачи виртуализации приложений и виртуальные машины типа JVM (Java Virtual Machine).
Предложенная классификация виртуализации серверов носит условный характер, она не стандартизована и нет общепризнанной терминологии, даже на уровне названий. Скажем, естественную (native) виртуализацию иногда отождествляют с полной (full) виртуализацией, что не вполне точно. Полная виртуализация может быть достигнута средствами естественной, но в некоторых случаях естественную виртуализацию считают гибридом полной с виртуализированными ресурсами ввода/вывода.
Все три подхода различаются по сложности внедрения, по диапазону поддерживаемых операционных систем, производительности, глубине доступа к ресурсам. Как обычно, выбор в пользу того или иного подхода является инженерным компромиссом. Например, паравиртуализация несколько быстрее естественной, но за это требуется расплата в виде модификации гостевых ОС. Виртуализация на уровне операционных систем обладает лучшей масштабируемостью, но эффективно работает на серьезных серверах с SMP-архитектурой.
Естественная виртуализация
Самый распространенный подход к виртуализации серверов называют «естественным», поскольку в этом случае обеспечивается органичная и полноценная эмуляция основных функций процессора и остальных главных компонентов сервера. В упрощенном виде эта схема естественной виртуализации представлена на рис. 1, ее можно разделить на четыре или пять уровней. Идея естественной виртуализации прозрачна: поверх аппаратного уровня (физический сервер) располагается следующий уровень, уровень монитора виртуальных машин VMM; часто в качестве синонима VMM используют термин гипервизор (hypervisor). Гипервизор полностью эмулирует компьютер, но его основное отличие от обычного процессора состоит в способности поддерживать выполнение более чем одной операционной системы. На VMM выполняются так называемые гостевые операционные системы (guest OS) виртуальных машин, непосредственно поддерживающие работу приложений.
Рис. 1. Упрощенная схема естественной виртуализации
Гипервизоры, в свою очередь, можно классифицировать по их отношению к операционным системам физических и виртуальных машин. Два наиболее часто используемых решения признаны каноническими, это так называемые Type 1 hypervisor (Type 1 VMM) и Type 2 hypervisor (Type 2 VMM), соответственно они представлены на рис. 2а и 2в. Эти два типа представляют собой своего рода полюса, и здесь действует та общая закономерность, которая характерна для виртуализационных решений вообще, граница между этими двумя типами размыта, существуют «гибридные VMM», занимающие промежуточное положение (рис. 2б). В последние годы граница размывается и далее; производителями процессоров активно развиваются технологии, предназначенные для адаптации аппаратного обеспечения к требованиям виртуализации, это направление принято называть hardware assistance virtualization. Еще одно близкое направление разрабатывается небольшими компаниями-«стартапами», в его основе адаптация к виртуализации на уровне серверов. Примером такого решения являются разработки компании с символическим названием Virtual Iron, то есть «виртуальное железо».
Рис. 2. Классификация гипервизоров
Рис. 3. VMware ESX Server как пример Type 1 hypervisor
В решении Type 1 hypervisor (рис. 3), которое было исторически первым, виртуализационное программное обеспечение работает непосредственно на аппаратной платформе. Обычно в качестве самого первого примера такого решения называют операционную систему CP/CMS, разработанную Кембриджским исследовательским центром IBM совместно с Массачусетским технологическим институтом в 1967 году. В последующем она прошла несколько модернизаций, последовательно переходя на System/360 и System/370. Ее преемником стала система VM (VM/CMS), работающая на мэйнфреймах System/390, zSeries и System z9, позволяющая одновременно эмулировать тысячи виртуальных машин. Решение класса Type 1 еще называют «виртуализацией голого металла». Наиболее идеологически близкими к CP/CMS являются VMware ESX Server, Xen и Sun Hypervisor. Что касается последнего, то он в значительной мере ориентирован на процессор UltraSPARC T1, спроектированный с учетом гипервизорной технологии, в нем VMM обеспечивается средствами реализованного на уровне микропрограмм UltraSPARC Hypervisor.
В качестве примера современного классического решения Type 1 hypervisor можно назвать VMware ESX Server (рис. 4) -- по существу это еще одна операционная система, действующая непосредственно на аппаратной платформе x86 в чистом виде. Гостевыми операционными системами, работающими на ESX Server, могут быть Linux, Windows, FreeBSD, NetWare и Solaris. Как самостоятельная операционная система, VMware ESX Server интерпретирует аппаратную платформу в качестве пула логических ресурсов и динамически перераспределяет его между гостевыми операционными системами. Гостевые операционные системы взаимодействуют с виртуальными ресурсами точно так же, как они взаимодействовали бы с физическими ресурсами.
Рис. 4. Архитектура серверов VMware GSX Server и Microsoft Virtual Server 2005
Виртуализационный уровень, представленный ESX Server, отделяет логические ресурсы от физических; он позволяет распределять процессоры, память, диски и сетевые ресурсы. При установке ESX Server автоматически генерируется располагающаяся на отдельной, своей собственной виртуальной машине консоль управления, на ней работает инструментальный набор, которым комплектуется ESX Server, он позволяет оптимизировать распределение ресурсов. В дополнение к основным средствам имеется опция VMware VirtualCenter cо следующими функциями: VMware VMotion (миграция виртуальных машин по физическим серверам); VMware Distributed Resource Scheduler (распределение ресурсов в соответствии с бизнес-целями); VMware HA (создание отказоустойчивых конфигураций).
Решение Type 2 hypervisor отличается тем, что гипервизор работает поверх операционной среды, так называемого «хоста». Типичными представителями этого направления виртуализации являются VMware Server (его прежнее название — VMware GSX Server) и Microsoft Virtual Server. К примеру, Microsoft Virtual Server 2005 устанавливается как приложение на операционную систему Windows 2003 Server, выполняющую функцию «хоста». Таким образом создается виртуализационный уровень, обеспечивающий доступ к физическим ресурсам. Virtual Server 2005 доступен в двух версиях: Standard Edition и Enterprise Edition. Хостом для сервера VMware GSX Server могут быть операционные системы Windows 2000, Windows 2003 или Linux.
Основное различие между двумя типами гипервизоров заключается в том, что Type 1 hypervisor — это операционная система, а Type 2 hypervisor — приложение. Операционная система-хозяин может поддерживать не только гипервизор, но и другие приложения.
Рис. 5. Виртуализация, поддерживаемая аппаратными средствами
Усилиями корпораций AMD и Intel, предложивших технологии AMD-V и Intel VT соответственно, развивается третий подход, обеспечивающий перекрытие «виртуализационных дыр» в системе команд современных процессоров. На рис. 5 показано, что между VMM и гипервизором может быть расположен специализированный промежуточный слой, компенсирующий органическую неприспособленность традиционных процессоров к виртуализации.
Паравиртуализация
Нет ничего удивительного в том, что в Wikipedia паравиртуализация названа «новым словом со старым содержанием». Еще в операционной системе IBM VM на протяжении десятилетий использовался тот же принцип — специализированные команды, неисполняемые процессором и адресованные модулям операционных систем. В VM они предназначались для обслуживания аппаратуры, это были так называемые «диагностические коды». В программном продукте Parallels Workstation, выпускаемом компанией Parallels, являющейся дочерней по отношению к SWsoft, аналогичный вызов операционной системы называется гипервызовом (hypercall). В контексте полной виртуализации средствами паравиртуализации, то есть специализированными командами, осуществляется вызов гипервизора из гостевых операционных систем. Такое решение внедрения в гостевую операционную систему специальных кодов (hypervisor-specific code) позволяет назвать паравиртуализацию методом, обеспечивающим программный интерфейс между VM и VMM.
Впервые термин «паравиртуализация» был предложен профессором Вашингтонского университета Стивеном Гриббли, руководителем проекта Denali (так называется национальный парк на Аляске, а алеуты так называют пик Мак-Кинли). Позже термин «паравиртуализация» стали использовать в ряде проектов, среди которых наибольшую известность приобрел проект Xen, свободно распространяемый монитор виртуальных машин для архитектур IA-32, x86-64, IA-64 и PowerPC. Он работает на «голом железе» и поддерживает модифицированные версии Linux и NetBSD в качестве гостевых операционных систем. Инициатором и руководителем проекта является преподаватель Кембриджского университета Йен Пратт.
Рис. 6. Паравиртуализация по Xen
Каждая из гостевых операционных систем Xen работает в своем собственном домене (рис. 6). Домены равноценны, но один из них, Domain 0, отличается тем, что в нем точно так же работает гостевая ОС, которая в дополнение к своим обычным функциям управляет созданием новых доменов, поддерживает работу других гостевых систем и физических устройств. В Domain 0 работает «демон» xend, так называется специальная программа, написанная на Python, являющаяся центральным пунктом управления всеми ресурсами в гипервизоре Xen. Обрабатываемые команды разбираются, и часть из них, адресованная устройствам, попадает в соответствующие драйверы, а гипервызовы — в xend.
В отличие от естественной виртуализации, в случае паравиртуализации на VMM выпадает гораздо меньший объем работы: нет нужды виртуализировать BIOS, диски, процессор и т.д. Выигрыш по сравнению с естественной виртуализацией составляет от 5 до 15% производительности. Следовательно, эффективность будет выше, но за счет понижения гибкости и безопасности. Потеря гибкости происходит из-за того, что требуется модифицировать гостевую ОС, а это значит, что не всегда найдется необходимая операционная система. Степень безопасности снижается из-за большей близости гостевых систем к аппаратному уровню и, как следствие, возможности возникновения разного рода коллизий.
Виртуализация ЦОД. Virtual Iron
Как бы ни были важны задачи виртуализации на уровне отдельных серверов, их значение многократно увеличивается при необходимости консолидировать ресурсы серверов, размещенных в центрах обработки данных. Эта задача особенно актуализировалась в 2006 году. В частности, она вышла на первый план в производственной программе лидера рынка, компании Vmware, в виде инструментария Infrastructure 3. Но первым, кто вступил на этот путь, была компания Virtual Iron Software, основателем и техническим директором которой является Алекс Василевский.
Компания Virtual Iron Software расположена в Массачусетсе, и ее подъем служит еще одним признаком возрождения этой «старой компьютерной столицы». Компания относится к новому типу «стартапов», создаваемых не выпускниками университетов, как это было в эпоху Internet-бума, а, напротив, ветеранами отрасли. Василевский начинал в знаменитой некогда компании Thinking Machines, не преуспевшей в бизнесе, но внесшей колоссальный вклад не только в развитие современных компьютерных систем, но и в науку в целом. Чего стоят такие имена, как Мавин Минский, Даг Ленарт, Стивен Вольфрам… Именно выходцам из Thinking Machines компания Sun Microsystems в значительной мере обязана появлением своих серверов серии Sun Enterprise (кстати, нынешний технический руководитель Sun Грег Паподополос начинал свою карьеру там же).
Объектом виртуализации в проекте Virtual Iron является не один сервер, а множество серверов на платформе Intel или AMD, объединенных сетью Ethernet с подключенными к ним накопителями (NAS) и сетями хранения (SAN). Результатом виртуализации должны стать виртуальные узлы, представляющие некоторые наборы зарезервированных под них физических серверов, они также объединены в сеть Ethernet и подключены к виртуализированным системам хранения. Таким образом, физическая инфраструктура, состоящая из процессоров, памяти, дисков, сетевых адаптеров, каналов связи и других компонентов, преобразуется в виртуальную инфраструктуру, где большинство из них представлено виртуально, за исключением тех устройств, которые по определению не могут быть виртуальными, — это мониторы, клавиатуры и мыши.
На первых этапах на уровне процессоров в Virtual Iron придерживались идеи паравиртуализации и называли Xen своим основным партнером, но с появлением технологий аппаратной виртуализации Intel-VT и AMD-V компания полностью переключилась на это направление, надеясь одной из первых предложить решения, использующие данные технологии.
Преобразование физической инфраструктуры в виртуальную осуществляется средствами виртуализационных сервисов (Virtualization Service), распространяемых по виртуальным сетям (Virtual Network). За создание и поддержание виртуальных сетей отвечает Virtual Iron Virtualization Manager, он же управляет виртуализованными системами хранения (Virtual Storage). На виртуальных серверах, конфигурация которых может быть задана (число процессоров, размер памяти, сетевые адаптеры, диски, загрузочные устройства), могут работать немодифицированные операционные системы Linux и Windows.
Виртуализация, status quo
Несмотря на все видимые преимущества виртуализации, ее массовое внедрение происходит непросто. Приверженцы Windows испытывают определенный испуг перед продуктами типа VMware ESX Server с его Linux-подобным интерфейсом, делающим его непохожим на привычные им Windows-приложения. С другой стороны, те, кто привык к свободно распространяемому программному обеспечению, испытывают настороженность к тому же VMware ESX Server как к продукту коммерческому.
Лидер очевиден: 55% рынка принадлежит VMware, оборот компании вырос со 100 млн. долл. в 2003 году до 387 млн. долл. в 2006-м. По собственным оценкам компании, такой рост должен сохраниться на ближайшие годы. Ускорению должен содействовать выпуск во второй половине 2006 года инфраструктурного решения VMware Infrastructure 3 и покупка компании Akimbi Systems, что поможет в развитии инструментария VMware Lab Manager, упрощающего процедуры установки и обслуживания программного обеспечения.
Отсутствие собственного гипервизора, работающего на «голом железе», является очевидным сдерживающим фактом для Microsoft. Положение может изменить готовящийсяк выпуску в рамках проекта Longhorn гипервизор Veridian. Пока на долю Microsoft приходится 8,7%.
Компания Swsoft, имеющая российские корни, также демонстрирует рост, но ее доля на рынке пока остается равной 8%, как и 2005 году. Несмотря на множество разговоров о Xen, этот проект заработал в 2006 году 15,6 млн. долл., что соответствует доле менее 3% рынка.
Виртуализация по версии Solaris
Специфика подхода к виртуализации на уровне ОС заключатся в том, что либо на всей аппаратной платформе, либо в аппаратном разделе, если сервер делится на разделы, работает только одна операционная система. Этот экземпляр операционной системы осуществляет функцию виртуализации и поддерживает работу нескольких «вложенных» операционных окружений, каждая из которых имеет все или почти все атрибуты независимой ОС, хотя на самом деле пользуется ядром материнской ОС. Среди решений такого рода наибольшую известность приобрели OpenVZ/Virtuozzo, Linix-VServer, FreeBSD Jails, FreeVPS и Solaris 10 Containers (или Solaris 10 Zones).
Единственность ядра определяет одновременно и достоинства, и недостатки этой технологии. С одной стороны, поскольку ядро одно, минимизируются накладные расходы на виртуализацию, исчезают расходы на поддержку виртуальных устройств и более эффективно используется оперативная память. Но с другой стороны, все программные разделы работают под управлением ОС одной версии, исправленной одним набором заплаток (патчей), и в тех случаях, когда возникают проблемы на уровне ОС или когда требуется ее перезагрузка после обновления либо изменения конфигурации, затронутыми оказываются все разделы, работающие внутри этой ОС. Поэтому оказывается логичнее ограничить применение виртуализации на уровне ОС приложениями, способными работать в одном экземпляре ОС, но для большей эффективности ресурсы между ними предпочтительнее разделить. Если же приложения по своей природе требуют разных версий ОС, то их лучше запускать под управлением монитора виртуальных машин (гипервизора).
Контейнеры
В Solaris 10 появилось много нововведений, в том числе Solaris 10 Containers — технология, позволяющая запускать внутри одного ядра несколько независимых операционных окружений. Каждому экземпляру окружения (контейнеру) можно выделить только ему принадлежащее ограниченное подмножество аппаратных ресурсов, что позволяет выполнить одно из основных условий виртуализации — обеспечить изоляцию виртуальных сред. Контейнер — это ОС вложенная в другую ОС, он использует ядро материнской ОС, но имеет: изолированный от других контейнеров набор процессов; собственные файловые системы, включая корневую файловую систему, и как следствие собственные конфигурационные файлы; пакеты и патчи, не относящиеся к системным; свой набор сервисов SMF (за исключением NFS сервера); сетевые интерфейсы.
С точки зрения запущенных внутри контейнера процессов контейнер выглядит как полноценная ОС. В терминологии компании Sun материнская ОС называется глобальным контейнером, а остальные контейнеры, созданные внутри глобального, называются неглобальными. Глобальный контейнер управляет неглобальными и позволяет конфигурировать и инсталлировать новые неглобальные контейнеры; запускать, перезапускать и останавливать неглобальные контейнеры; управлять аппаратными ресурсами, выделенными неглобальным контейнерам; осуществлять мониторинг неглобальных контейнеров, например следить за процессорными ресурсами и памятью, используемыми неглобальными контейнерами.
В основе управления аппаратными ресурсами, выделяемыми неглобальным контейнерам, лежит появившейся еще в Solaris 8 менеджер Solaris Resource Manager (SRM), однако в Solaris 10 его функциональность стала частью ядра Solaris. В Solaris 10 ресурсы представлены в виде пула Resource Pool (RP), снабженного механизмом динамического изменения ресурсов Dynamic Resource Pool (DRP). Сведение ресурсов в пул позволяет разделить множества виртуальных процессоров между различными наборами приложений. Пока управление процессорами остается единственной задачей, за которую отвечает управление пулом ресурсов. В следующих версиях планируется добавить механизм для управления памятью. Виртуальные процессоры могут иметь как статическую привязку к тому или иному пулу, так и динамическую. Статическая предполагает, что процессор не может использоваться в других пулах без реконфигурации пулов. В случае динамической привязки процессоры выделяются и освобождаются по мере необходимости.
В Solaris 10 включено средство BrandZ (Branded Zones), позволяющее создавать контейнеры с операционными системами, отличными от ОС глобального контейнера, и переадресовывать системные вызовы из неглобальных контейнеров ядру ОС глобального контейнера. Подобным образом реализована поддержка первого «неродного» неглобального контейнера Solaris 10 для ОС Linux. Эта реализация получила название Solaris Containers for Linux Applications (SCLA). На данный момент в SCLA могут запускаться только 32-разрядные приложения, хотя сама ОС Linux может быть и 64-разрядной. Контейнер SCLA позволяет собрать под управлением ОС Solaris приложения двух ОС — Linux и Solaris.
Технология SCLA накладывает следующие ограничения на приложения, выполняющиеся в контейнере SCLA: приложение не должно использовать прямой доступ я ядру Linux и не должно содержать в себе или требовать специфичных модулей или драйверов Linux. Эти ограничения не мешают запускать в контейнерах SCLA такие приложения, как Oracle Server или Thunderbird. Запущенные под управлением SCLA, они работают в среднем примерно с той же скоростью, что и под управлением ОС Linux на том же аппаратном обеспечении.
OpenSolaris и Xen
Технология Solaris 10 Containers позволяет в виртуальной среде запускать приложения Solaris и Linux, однако существуют приложения, которые официально сертифицированы только для определенной версии Solaris или Linux, причем иногда для работы этих приложений требуется определенный набор патчей ОС. В контейнере ОС Solaris нельзя запустить приложения Windows. Для преодоления этих ограничений в ОС OpenSolaris введен механизм виртуализации на основе гипервизора XEN, который изначально разрабатывался для ядра Linux и NetBSD, свободно распространяемый на условиях лицензии GPL. XEN тесно интегрируется с ядром материнской ОС.?Кроме того, так как Xen изначально разрабатывался для поддержки паравиртуализации, он требует модификации ОС, запускаемой под своим управлением гостевой ОС. XEN позволяет запускать следующие гостевые ОС: Linux, Net/Free/OpenBSD, OpenSolaris, NetWare и GNU/Hurd/Mach.
В качестве материнской XEN может использовать различные дистрибутивы Linux, Net/Open/FreeBSD и OpenSolaris. На данный момент XEN перенесен в ОС OpenSolaris с некоторыми ограничениями: OpenSolaris поддерживается как материнская, так и как гостевая ОС начиная с OpenSolaris Nevada build 44; в качестве гостевых ОС поддерживается Linux и FreeBSD; на данный момент отсутствует поддержка немодифицированных гостевых ОС, например Windows.
--Валерий Безруков — системный архитектор компании Sun Microsystems.
Хронология виртуализации
1937. Алонзо Черч и Алан Тьюринг независимо друг от друга высказали утверждение, ставшее теоретическим обоснованием виртуализации и получившее название «тезис Черча—Тьюринга».
1959. Кристофер Стречи опубликовал статью Time Sharing in Large Fast Computers в трудах организованной ЮНЕСКО конференции International Conference on Information Processing.
1960. Манчестерский университет и компания Ferranti совместно построили компьютер, в котором реализованы предпосылки к виртуализации.
1964. В Кембриджском научном центре корпорации IBM разработан компьютер CP-40.
1965. В исследовательском центре IBM Watson Research Center построена экспериментальная модель IBM M44/44X со страничной организацией памяти и компьютер IBM System/360-67 с виртуальной памятью.
1972. IBM System/370 дополнена виртуальной памятью.
1977. DEC выпустила мини-ЭВМ VAX-11/780, название которой расшифровывается как Virtual Address eXtension.
1988. Insignia Solutions предложила программное обеспечение SoftPC 1.0 для выполнения Windows-приложений в среде ОС Uniх на платформах, отличных от Intel.
1988. Connectix подготовила свои продукты Virtual PC и Virtual Server для эмуляции программного обеспечения, разработанного для платформы x86.
1995. Вместе с дебютом языка программирования Java представлена виртуальная машина Java.
1999. VMware выпустила VMware Virtual Platform для архитектуры Intel IA-32.
2000. IBM анонсировала операционную систему z/VM для 64-разрядной архитектуры z/Architecture.
2001. Connectix выпустила Virtual PC for Windows. VMWare представила первый продукт для виртуализации серверов x86-архитектуры.
SWsoft выпустила инструментарий Virtuozzo для платформы Linuх (версия для Windows появилась в 2005 году).
2003. Microsoft купила технологию Virtual PC у Connectix, позже в том же году выпустив Microsoft Virtual PC. EMC купила компанию VMware.
