Журнал Компьютерра - Журнал «Компьютерра» №32 от 06 сентября 2005 года
В самом деле: представим на минуту, что мы можем запустить на одном и том же компьютере (персоналке, рабочей станции, сервере) несколько виртуальных взаимодействующих, но непересекающихся машин. Что это нам дает?
Появляется возможность создания сложных «гибридных» систем, вбирающих в себя все преимущества разных операционных систем и наработанного для них программного обеспечения. Хотите поручить управление сетью Windows-машин основанному на Linux серверу, но вас почему-либо не устраивает пакет Samba? Желаете организовать роутер и прокси-сервер на базе *BSD-системы, но для других целей она вам совершенно не подходит? Нет проблем: создаем столько виртуальных систем, сколько нужно, и сочетаем в одном компьютере все их преимущества.
Зачем покупать отдельный сервер, требующий непростого и зачастую дорогостоящего обслуживания, когда с теми же обязанностями может неплохо справиться и десяток персоналок? Минимальная адаптация современных пиринговых сетей - и в локальной сети появляется надежное и дешевое виртуальное хранилище данных, «размазанных» и продублированных на компьютерах самых обычных пользователей. А «виртуальность» образующих эту устойчивую к повреждениям группу машин обеспечит сети надежную защиту от действий пользователей или каких-либо случайных «внешних факторов». Даже если пользовательский ПК, скажем, зависнет, будет взломан хакером, заражен вирусом или перезагружен, - на функционировании работающего на той же самой машине виртуального «сервера» это не скажется.
На сервере работает несколько десятков пользователей с довольно широкими правами и нужно обеспечивать их взаимную безопасность и совместимость? Можно тщательно оптимизировать настройки системы, добиваясь тончайшего и почти неуловимого баланса между обеспечением разнообразных (зачастую экзотических) пожеланий пользователей и ограничением их прав в пределах, гарантирующих, что программы юзера А не будут по субботам вечером «ронять» программы юзера Б. Можно поставить отдельный Windows-сервер, отдельный Linux-сервер, отдельный FreeBSD-сервер, отдельный NetBSD-сервер, отдельный сервер на Solaris или вообще два десятка серверов, по штуке на брата. Но проще и дешевле поставить один сервер, на котором выделить каждому пользователю по «независимой» машине, принципиально непересекающейся с другими.
На предприятии стоит один и только один сервер на базе процессоров Itanium, на котором работает корпоративное ПО, а программисты, за неимением лучшей тестовой платформы, отлаживают свеженаписанные программы и заплатки прямо на «живой» системе? Создадим им виртуальную копию корпоративного «сервера на Itanium», и проблема решится сама собой.
Появляется возможность создания «дешевых» резервных серверов, служащих для замены основного сервера в случае его отказа. Скажем, можно на одном сервере продублировать роутер предприятия четырьмя разными программами.
Уже хорошо, не так ли? А что, если мы добавим к сказанному возможности «ставить на паузу», «сохранять» и «загружать» состояния наших виртуальных машин?
Радикально упрощается процедура бэкапа и процедура переноса рабочего места (или сервера) с одного компьютера на другой (при переезде или замене оборудования). Сохранил - загрузил - все работает, причем с сохранением всех настроек, вплоть до любимого пользователем расположения ярлычков в такой-то папке.
Более того, появляется замечательная возможность, например, без каких-либо проблем загружать виртуальные машины (со всеми документами и настройками) прямо по локальной сети с сервера. Обычно для обеспечения «не-фиксированного рабочего места» (сел за любой компьютер и работаешь с ним, как со своим собственным) применяют разнообразные терминальные решения, обладающие здоровенным перечнем недостатков и ограничений. Загрузка виртуальных компьютеров по сети эту проблему решает.
Ну и, наконец, появляется чудесная возможность всюду носить свое рабочее место и домашний компьютер с собой. Вечером синхронизировал ноутбук с рабочим компьютером - и твое рабочее место словно «переселилось» на ноутбук. А затем, точно так же - на домашний компьютер. И не нужно никакого постоянного широкополосного защищенного подключения.
Впечатляет? На мой взгляд, направление чрезвычайно многообещающее и во многом революционное (ну не зря же им заинтересовалась даже Microsoft). А вот используется оно сегодня крайне редко и в основном энтузиастами, нежели массовыми корпоративными и частными пользователями. Первых отпугивает обилие разнообразных проблем, связанных с существующими софтверными виртуальными ПК[На запрос «VMWare» Google выдал порядка 1 290 000 ссылок, а на «VMWare problem» - 612 000 ссылок. Выводы делайте сами. Желающие могут поставить тот же эксперимент, заменив «VMWare» на «Windows XP», «Linux», «Apache», «MySQL» либо иное другое популярное ПО, и убедиться, что «проблемных» страничек в этом случае получается в несколько раз меньше (15-18%)]; вторых - высокая цена (от 130-300 до пары тысяч долларов за комплект ПО) и общая «тормознутость» и «примитивизм» получающейся на выходе системы. К сожалению, корень зла здесь кроется отнюдь не в «безруких программистах», не умеющих толком отладить свои продукты, нет. Вся загвоздка - в непомерной сложности точного и полного софтверного решения проблемы виртуализации.
***Проблемы виртуализацииЧто такое современный x86-совместимый компьютер? Если кто-то скажет вам, что это довольно простая штука, - не верьте: он просто не знает о чем говорит. Примерное представление о масштабах этой, хм, технологии дает разве что техническая документация - четыре многосотстраничных тома краткой документации по архитектуре IA-32 (The IA-32 Intel Architecture Software Developer’s manual: vol. 1, 2A, 2B amp; 3) и еще два - по ее 64-битным расширениям (The Intel Extended Memory 64 Technology Software Developer’s guide, vol. 1 amp; 2). Впрочем, о последних лучше почитать в первоисточнике - пятитомном издании AMD64 Architecture Programmer’s Manual. Реализовать по этим здоровенным талмудам даже простую имитацию современного x86-процессора - огромная работа; и еще труднее - сделать такую имитацию, которая бы умела более или менее эффективно задействовать для исполнения виртуального кода ресурсы центрального процессора. Даже куда более простая и специально оптимизированная виртуальная машина Java, как известно, работает довольно медленно; надеяться же на чистую эмуляцию средствами центрального процессора чего-либо принципиально более мощного, нежели какой-нибудь ZX Spectrum на процессоре Z80, и вовсе не приходится. Поэтому все современные виртуальные компьютеры идут другим путем - не эмулируя в прямом смысле слова несколько виртуальных ПК, а запуская на одном персональном компьютере несколько операционных систем и ловко «дурача» их, с помощью разных приемов защищая от взаимного «членовредительства» и заставляя «поверить» в то, что кроме них в системе никого нет (рис. 1). Беда в том, что каких-либо приспособлений для подобного рода «надувательства» у этих «виртуализаторов» нет - им приходится выкручиваться, используя для своих целей стандартные методы (IA-32 aka 32-разрядный x86 - весьма гибкая архитектура, и во многих отношениях сделать это оказывается возможным). Однако предусмотреть все ситуации и найти ответы на все возникающие при этом вопросы - практически нереально. Разные ухищрения, на которые приходится пускаться программистам, к сожалению, являются скорее латанием дыр в ветхом днище корабля: для того чтобы кое-как, с половинным ходом доплыть до дока, такого «ремонта» хватает, а вот для длительных морских походов или бурных морей - нет.
Рассмотрим суть возникающих неприятностей на примере так называемой проблемы нулевого кольца исполнения. Кольца (rings, они же уровни приоритета - PLs, Priority Levels) - это такая хитрая система, защищающая центральный процессор от выполнения «посторонними» программами «глубоко системных» инструкций и операций, эдакий «уровень доступа» запущенной программы к системным ресурсам. В IA-32 четыре кольца, от Ring 0 до Ring 3. Чем больше номер кольца - тем меньше приоритет и тем меньше доступно работающей программе. В нулевом кольце запущенный процесс может делать все, что заблагорассудится, - ему предоставлен карт-бланш на любые операции; так что именно в этом кольце «обитает» ядро операционной системы и непосредственно взаимодействующие с оборудованием драйверы. Третье кольцо - сильно упрощенный и ограниченный мирок, в котором запущенный процесс может свободно «жить», но изменить который он не в состоянии. Здесь «живут» всяческие прикладные программы. Кольца 1 и 2 ни Windows, ни *nix-системами принципиально не используются.
В чем же проблема? Оказывается, когда мы «дурачим» виртуальную операционную систему, то не совсем понятно, в какое из колец ее следует помещать. В Ring 0, очевидно, поместить ОС нельзя - проконтролировать ее действия в этом случае не сумеет ни одна живая душа, ибо «воля» исполняющегося в этом кольце кода обсуждению или критике со стороны процессора не подлежит. Поместить операционную систему в «непривилегированные» первое, второе или третье кольца тоже нельзя: любая ОС проектируется, исходя из расчета, что выполняться она будет в нулевом кольце привилегий, а значит, отсутствия необходимого минимума маленьких, но жизненно важных для работы ее ядра инструкций не простит. Вот и приходится программистам либо заблаговременно проверять код на предмет «неблагонадежных» инструкций, ставя на их место вызовы «правильных заменителей», либо отлавливать возникающие при исполнении «неправильных» инструкций ошибки и пытаться их на лету исправлять. Легко догадаться, что реализация и того и другого выливается в большую головную боль для программистов, причем на вроде бы совершенно пустом месте. К примеру, часто «гостевую» операционную систему размещают в неиспользуемом первом кольце… но в расширенном 64-битном режиме процессор не поддерживает кольца 1 и 2, так что все соответствующие наработки «виртуализатор», естественно, отправляет в корзину. Рано или поздно количество проблем переходит в качество - и виртуальные машины становятся не только крайне сложными с программной точки зрения, но и громоздкими, медленными и ненадежными.
