Добавлен: 29.10.2018
Просмотров: 47997
Скачиваний: 190
96
Глава 1. Введение
понадобиться для выполнения этого вызова. Эти команды ввода-вывода перехватыва-
ются VM/370, которая выполняет их в рамках моделирования реального оборудования.
При полном разделении функций многозадачности и предоставления машины с рас-
ширенной архитектурой каждая из составляющих может быть намного проще, гибче
и удобнее для обслуживания.
В своем современном перерождении z/VM обычно используется для запуска несколь-
ких полноценных операционных систем, а не упрощенных, однопользовательских си-
стем вроде CMS. Например, на машинах zSeries можно запустить одну или несколько
виртуальных машин Linux, а наряду с ними — обычные операционные системы IBM.
Повторное открытие виртуальных машин
Хотя в IBM виртуальные машины используются уже четыре десятилетия и ряд других
компаний, включая Oracle и Hewlett-Packard, недавно добавили поддержку вирту-
альных машин к своим высокопроизводительным промышленным серверам, тем не
менее, по большому счету, идея виртуализации в мире персональных компьютеров
до последнего времени практически игнорировалась. Но сейчас сочетание новых по-
требностей, нового программного обеспечения и новых технологий придало этой теме
особую актуальность.
Сначала о потребностях. Многие компании традиционно запускали свои почтовые сер-
веры, веб-серверы, FTP-серверы и все остальные серверы на отдельных компьютерах,
иногда имеющих различные операционные системы. Виртуализация рассматривается
ими как способ запуска всех этих серверов на одной и той же машине с возможностью
избежать при этом отказа всех серверов при отказе одного из них.
Виртуализация популярна также в мире веб-хостинга. Без нее клиенты вынуждены
выбирать между общим хостингом
1
(который дает им только учетную запись на веб-
сервере, но не позволяет управлять его программным обеспечением) и выделенным
хостингом (который предоставляет им их собственную, очень гибкую, но не оправ-
дывающую затрат машину при небольших или средних по объему веб-сайтах). Когда
компания, предоставляющая услуги веб-хостинга (хостинг-провайдер), сдает в аренду
виртуальные машины, на одной физической машине может быть запущено множе-
ство виртуальных машин, каждая из которых превращается в полноценную машину.
Клиенты, арендовавшие виртуальную машину, могут запускать на ней какие угодно
операционную систему и программное обеспечение, но за часть стоимости выделен-
ного сервера (поскольку та же самая физическая машина одновременно поддерживает
множество виртуальных машин).
Другой вариант использования виртуализации предназначен для конечных пользо-
вателей, которым необходима возможность одновременного запуска двух или более
операционных систем, например Windows и Linux, поскольку некоторые из любимых
ими приложений работают под управлением только одной из этих операционных си-
стем. Такая ситуация показана на рис. 1.25, а, при этом термин «монитор виртуальной
машины» заменен на «гипервизор первого типа» (type 1 hypervisor), который широко
используется в наши дни из-за краткости при наборе по сравнению с первым вариан-
том. Но для многих авторов они являются взаимозаменяемыми.
1
За ним закрепилось название «виртуальный хостинг». — Примеч. пер.
1.7. Структура операционной системы
97
...
Linux
Windows
Excel Word Mplayer Apollon
Модель машины
Модуль
ядра
в
Гостевая ОС
Процесс гостевой ОС
Процесс гостевой ОС
Процесс
основной
ОС
Гостевая ОС
Основная операционная
система
Основная операционная
система
Рис. 1.25. Гипервизор: а — тип 1; б — чистый гипервизор, тип 2;
в — практический гипервизор, тип 2 (перевод)
Привлекательность виртуальных машин сомнениям не подвергалась, проблема заклю-
чалась в их реализации. Чтобы запустить на компьютере программное обеспечение вир-
туальных машин, его центральный процессор должен быть готов к работе в этом режиме
(Popek and Goldberg, 1974). Проблема заключается в следующем. Когда операционная
система, запущенная на виртуальной машине (в режиме пользователя), выполняет при-
вилегированные инструкции, например изменение слова состояния программы — PSW
или операцию ввода-вывода, необходимо, чтобы оборудование осуществило перехват
данных инструкций и вызов монитора виртуальных машин, который выполнит их про-
граммную эмуляцию. На некоторых центральных процессорах, особенно на Pentium, его
предшественниках и их клонах, попытки выполнения привилегированных инструкций
в режиме пользователя просто игнорируются. Эта особенность исключает создание
виртуальных машин на таком оборудовании, чем объясняется недостаточный интерес
к ним в мире x86. Конечно, существовали интерпретаторы для Pentium, такие как Bochs,
которые запускались на этом процессоре, но при потере производительности обычно
в один-два порядка они не подходили для серьезной работы.
В 1990-х годах и в первые годы нового тысячелетия был реализован ряд научно-ис-
следовательских проектов, в частности Disco в Стэнфорде (Bugnion et al., 1997) и Xen
в Кембридже (Barham et al., 2003). Эти исследования привели к появлению нескольких
коммерческих продуктов (например, VMware Workstation и Xen), и интерес к вир-
туальным машинам снова вырос. Сегодня в число популярных гипервизоров кроме
VMware иXen входят KVM (для ядра Linux), VirtualBox (от Oracle) и Hyper-V (от
Microsoft).
Некоторые из этих ранних исследовательских проектов улучшили производитель-
ность по сравнению с интерпретаторами типа Bochs путем трансляции блоков кода
на лету, сохранения их во внутреннем кэше и повторного использования результата
трансляции в случае их нового исполнения. Это существенно повысило производи-
тельность и привело к созданию того, что сейчас называется моделями машин (machine
simulators) (рис. 1.25, б). Но хотя эта технология, известная как двоичная трансляция
(binary translation), помогла улучшить ситуацию, получившиеся системы, несмотря
на то что они неплохо подходили для публикаций на академических конференциях,
по-прежнему не отличались быстротой для использования в коммерческих средах, где
производительность имеет весьма большое значение.
Следующим шагом в улучшении производительности стало добавление модуля ядра
(рис. 1.25, в) для выполнения ряда трудоемких задач. Сложившаяся сейчас прак-
тика показывает, что все коммерчески доступные гипервизоры, такие как VMware
98
Глава 1. Введение
Workstation, используют эту гибридную стратегию (а также имеют множество других
усовершенствований). Все их называют гипервизорами типа 2, поэтому и мы (хотя
и не вполне охотно) последуем этой тенденции и будем использовать данное назва-
ние далее в этой книге, даже при том, что лучше бы было назвать их гипервизорами
типа 1.7, чтобы отразить тот факт, что они не являются в полном смысле програм-
мами пользовательского режима. В главе 7 будет дано подробное описание того, как
работает VMware Workstation и чем занимаются его компоненты.
На практике действительным различием между гипервизорами типа 1 и типа 2 явля-
ется то, что в типе 2 для создания процессов, сохранения файлов и т. д. используется
основная операционная система
(host operating system) и ее файловая система. Ги-
первизор типа 1 не имеет основной поддержки и должен выполнять все эти функции
самостоятельно.
После запуска гипервизор типа 2 считывает установочный компакт-диск (или файл
образа компакт-диска) для выбора гостевой операционной системы (guest operation
system) и установки гостевой ОС на виртуальный диск, который является просто
большим файлом в файловой системе основной операционной системы. Гипервизор
типа 1 этого делать не может по причине отсутствия основной операционной системы,
в которой можно было бы хранить файлы.
Во время своей загрузки гостевая операционная система делает все то же самое, что
и на настоящем оборудовании, как обычно запуская некоторые фоновые процессы, а за-
тем графический пользовательский интерфейс. С точки зрения пользователя, гостевая
операционная система ведет себя точно так же, как при запуске непосредственно на
оборудовании, хотя в данном случае ситуация совсем иная.
Другим подходом к обработке управляющих инструкций является модификация
операционной системы с целью их удаления. Этот подход не является настоящей
виртуализацией, он относится к паравиртуализации. Более подробно виртуализация
будет рассмотрена в главе 7.
Виртуальная машина Java
Виртуальные машины используются, правда, несколько иным образом и в другой об-
ласти — для запуска программ на языке Java. Когда компания Sun Microsystems изо-
брела язык программирования Java, она также изобрела и виртуальную машину (то
есть архитектуру компьютера), названную JVM (Java Virtual Machine — виртуальная
машина Java). Компилятор Java создает код для JVM, который затем обычно выполня-
ется программным интерпретатором JVM. Преимущество такого подхода состоит в том,
что код для JVM может доставляться через Интернет на любой компьютер, имеющий
JVM-интерпретатор, и запускаться на этом компьютере. Если бы компилятор создавал
двоичные программы, например для SPARC или x86, их нельзя было бы так же легко
куда угодно доставлять и где угодно запускать. (Разумеется, Sun могла бы создать ком-
пилятор, производящий двоичные файлы для SPARC, а затем распространить SPARC-
интерпретатор, но у JVM намного более простая для интерпретации архитектура.) Дру-
гим преимуществом использования JVM является то, что при правильной реализации
интерпретатора, что не является такой уж простой задачей, полученные JVM-программы
могут быть проверены с точки зрения безопасности, а затем выполнены в защищенной
среде, не имея возможности похитить данные или нанести любой другой вред.
1.8. Устройство мира согласно языку C
99
1.7.6. Экзоядра
Вместо клонирования настоящей машины, как это делается в виртуальных машинах,
существует иная стратегия, которая заключается в их разделении, иными словами,
в предоставлении каждому пользователю подмножества ресурсов. При этом одна
виртуальная машина может получить дисковые блоки от 0 до 1023, другая — блоки от
1024 до 2047 и т. д.
Самый нижний уровень, работающий в режиме ядра, — это программа под названием
экзоядро
(Engler et al., 1995). Ее задача состоит в распределении ресурсов между вир-
туальными машинами и отслеживании попыток их использования, чтобы ни одна из
машин не пыталась использовать чужие ресурсы. Каждая виртуальная машина может
запускать собственную операционную систему, как на VM/370 и на Pentium в режиме
виртуальных машин 8086, с тем отличием, что каждая машина ограничена использо-
ванием тех ресурсов, которые она запросила и которые были ей предоставлены.
Преимущество схемы экзоядра заключается в том, что она исключает уровень ото-
бражения. При других методах работы каждая виртуальная машина считает, что она
имеет собственный диск с нумерацией блоков от 0 до некоторого максимума. Поэтому
монитор виртуальных машин должен вести таблицы преобразования адресов на диске
(и всех других ресурсов). При использовании экзоядра необходимость в таком пере-
назначении отпадает. Экзоядру нужно лишь отслеживать, какой виртуальной машине
какие ресурсы были переданы. Такой подход имеет еще одно преимущество — он отде-
ляет многозадачность (в экзоядре) от пользовательской операционной системы (в про-
странстве пользователя) с меньшими затратами, так как для этого ему необходимо
всего лишь не допускать вмешательства одной виртуальной машины в работу другой.
1.8. Устройство мира согласно языку C
Операционные системы, как правило, представляют собой большие программы, на-
писанные на языке C (иногда на C++), которые состоят из множества фрагментов,
написанных разными программистами. Среда, которая используется для разработки
операционных систем, существенно отличается от той среды, которую используют от-
дельные люди (например, студенты) для написания небольших программ на языке Java.
В этом разделе будет предпринята попытка весьма краткого введения в мир написания
операционной системы для малоопытных Java-программистов.
1.8.1. Язык С
Это не руководство по языку С, а краткое изложение некоторых ключевых отличий
языка C от таких языков, как Pyton и особенно Java. Язык Java создан на основе C,
поэтому у них много общего. Pyton, при всех своих отличиях, также похож на С. Но
для удобства мы все же сконцентрируем свое внимание на языке Java. И Java, и Pyton,
и С относятся к императивным языкам с типами данных, переменными и оператора-
ми управления. Элементарными типами данных в C являются целые числа — integer
(включая короткие — short и длинные — long), символы — char и числа с плавающей
точкой — float. Составные типы данных могут быть созданы с использованием масси-
вов, структур и объединений. Операторы управления в C подобны тем, что исполь-
зуются в Java, и включают в себя if, switch, for и while. Функции и параметры в обоих
100
Глава 1. Введение
языках примерно одинаковые. Одно из средств, имеющееся в C, но отсутствующее
в Java и Pyton, — явные указатели. Указатель — это переменная, которая указывает на
переменную или структуру данных (то есть содержит их адрес). Рассмотрим пример:
char c1, c2, *p;
c1 = 'c';
p = &c1;
c2 = *p;
Оператор в первой строке объявляет c1 и c2 символьными переменными и p — перемен-
ной, которая указывает на символ (то есть содержит его адрес). Первое присваивание
сохраняет ASCII-код символа «c» в переменной c1. Во втором адрес переменной c1
присваивается переменной-указателю p. А в третьем значение переменной, на которую
указывает переменная p, присваивается переменной c2, поэтому после выполнения
этих операторов c2 также содержит ASCII-код символа «с». Теоретически указатели
типизированы, поэтому присвоение адреса числа с плавающей точкой указателю на
символ не допускается, но на практике компиляторы позволяют подобные присваи-
вания, хотя некоторые из них и выдают предупреждения. Указатели являются очень
мощной конструкцией, но при невнимательном использовании являются источником
большого количества ошибок.
В C отсутствует встроенная поддержка строковых объектов, потоков, пакетов, клас-
сов, объектов, обеспечения безопасности типов и сборки мусора. Последнее является
серьезной проблемой для операционных систем. Все хранилища данных в языке C
либо имеют статический характер, либо явно размещаются и освобождаются про-
граммистом, при этом часто используются библиотечные функции malloc и free. Это
последнее свойство — полный контроль программиста над памятью — наряду с явными
указателями и делает язык C привлекательным для написания операционных систем.
Операционные системы по сути являются системами, которые работают в реальном
масштабе времени. Когда происходит прерывание, у операционной системы может
быть лишь несколько микросекунд для осуществления какого-нибудь действия, чтобы
не допустить потери важной информации. В такой ситуации произвольное включение
в работу сборщика мусора абсолютно неприемлемо.
1.8.2. Заголовочные файлы
Как правило, проект операционной системы состоит из определенного количества
каталогов, в каждом из которых находится множество файлов с именами, заканчива-
ющимися символами
.c
(файлов с расширением
.c
,
.с
-файлов). Эти файлы содержат
исходный код определенной части системы. Также эти каталоги содержат некоторое
количество заголовочных файлов с именами, заканчивающимися символами
.h
(фай-
лов с расширением
.h
,
.h
-файлов). В заголовочных файлах содержатся объявления
и определения, используемые одним или несколькими
с
-файлами. Заголовочные
файлы могут также включать простые макросы, например:
#define BUFFER_SIZE 4096
которые позволяют программисту присваивать имена константам. Если константа
BUFFER_SIZE использована в коде, то на этапе компиляции она будет заменена чис-
лом 4096. При программировании на C хорошим тоном считается давать имена всем
константам, кроме 0, 1 и −1, но иногда имена даются даже им. У макросов могут быть
параметры, например: