Материал из eSyr's wiki.

Предыдущая лекция | Следующая лекция

Авторский вариант: ...

[править] Виртуализация

При внимательном прочтении это две темы:

• Изоляция
• Виртуализация

Есть две темы разговора:

• Что это такое
• Почему это нужно, и почему это нужно именно сейчас

Раньше вирт. была уделом матёрых профессионалов, а тут внезапно эта теория приобрела горячую востребованность.

Как обычно, не хочется разговаривать о технологиях, а поговорим сначала о задачах, зачем это надо. Можно сколько угодно нахваливать инструмент, но пока не скажешь, зачем он нужен, его смысл останется тайной. Задачи

• Самая старая, существовала ещё 10---20 лет назад. Задача собственной изоляции, ограничения доступа. Когда-то давным-давно это была проблема. Был компьютер, был процессор, была память, были программы и была задача этим программам работать.

ОС

• организация ресурсов
• распределение и унификация ресурсов
• разграничение доступа

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

Появляется три уровня:

• Железо
• Окружение
• Среда

(вместо двух — железо и среда)

• Возможна другая ситуация: потребовалось изобразить компьютер, которого у нас нет — эмуляция
  • Когда другая архитектура
  • Когда их нужно несколько штук, и производительность их при этом не критична, например, для тестирования сетевых приложений

Если мы забудем про слово виртуализация, то вспомним, что для решения этих задач были свои вещи: от досбокса до СВМ (система виртуальных машин — внутри неё организовывалась куча виртуальных машинок, у которых не было нормальных ОС, которые не решали указанных выше задач). Была виртуализация, но на предыдущем уровне.

Что сейчас:

• Есть потребность разделить три пункта (ограничение доступа, распределение, унификация) по уровням. То есть сделать так, чтобы, например, унификация происходила до всего остального. То есть из кривого железа делаем виртуальное нормальное железо. Или мы занимаемся распределением времени процессора, нам всё равно, какая ОС, какие процессоры, но есть конкретная задача, которую надо решить. Ещё мы например хотим сделать так, чтобы приложения не могли обмениваться информацией, даже по сговору.

То есть задача следующего уровня не знает ничего о решении задачи предыдущего. Но ОС это монолитная система, а нам нужно независимость.

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

Это тоже будет ОС, понятие ОС не изменилась, но она будет не монолитная, а раздельная.

Решения подобного рода задач могут быть организованы не то, чтобы двумя способами, но двумя разными подходами, перетекающими друг в друга:

• Изоляция — манипуляция доступом к реальным ресурсам. То есть, доступ проходит фильтрацию. Многие из фильтров уже реализованы в юниксе: права файлов, процессорное время, память.... Тем не менее возникает ситуация, когда мы должны насильственно ограничить группу задач поверх того, что уже есть в юниксе.
• Виртуализация — когда ресурсы виртуальные, синтетические. В этом случае фильтрация либо совсем не нужна, либо решается средствами ОС. Например, SNES, которая полнотью виртуальная, нет ни процессора, ни картриджа, но есть программа и файл, которые ими притворяются.

В. Если несколько виртуальных машин гоняют нативный код?

Вот. На самом деле никакого жёсткого ограничения нет, то есть, ситуации, когда мы можем чётко разграничить. Именно поэтому приведён пример с нинтендо.

Paravirtualization — когда виртуализация и изоляция ходят парой, часть задач решают первое, часть — второе.

Перечисление названий.

• ОС. Например, виртуальная память. Что не удовлетворяет: в юникс действует принцип всё, что не запрещено, разрешено.
• Мы знаем хороший инструмент изоляции по части ФС: мы можем сделать так, что процесс может видеть только ту часть ФС, который мы знаем. Это chroot. Тем самым мы накладываем дополнительное изоляционное ограничения на процессор. Что мы этим добиваемся: мы сначала ограничиваем доступ к ФС, а потом запускаем процесс, который может делать там. что хочет.
• Дальше идёт вот что: чрут это изоляция только по ФС, например если два процесса запущены, то они могут послать друг другу сигнал, и они пошлют, или через shared memory несмотря на то, что работают в разных кусках ФС. Тогда нужно разграничить их и по всем системным вызовам друг от друга. Для этого есть V Server (Jail). То есть каждый заперт в свою тюрьму. В солярисе аналогичные вещи называаются зонами, правда, они чуть более крутые.

У нас общее всё, но мы ограничиваем процессы в общении между собой.

Путём патченья ядра добились того, что два процесса не могут друг друга увидеть.

Потихоньку можнео начать задачу распределения ресурсов. Например, чтобы 10 процессов, запущенные на одном вирт сервере, не сожрали все ресурсы, и чтобы что-нибудь осталось другим 10 процессам. Помимо огранич доступа на след этапе иерархизируется распределение ресурсов.

• OVZ (бывший правовладельческий продукт). У них есть собственная ФС закрытая, которая позоляет изолировать ФС частично. С этим справляется unionfs, но это академический проект, и исполнители каждый год меняются. Процессу передаётся синтетический квант времени. Например, этой вирт машине выдаётся 10к квантов, на другой — 5к, и если запустить на первой страшную счётную задачу, на пример, пустой цикл, то она будет кушать 10к квантов
• UML (user-mode linux) Здесь начинает идти разговори о паравиртуализации. Например, есть виртуальная сетевая карта. Это непопулярный проект.

Изоляция она быстрая, виртуализация медленная, поэтому то, что uml виртуализует, делается медленно. UML — программа, которая запускается, и некоторые процессы видят её как ядро. Это линух внутри линуха. Фактически, скомпилировано ядро под специальную архитектуру.

Проблемы UML:

• Двойная буферизация
• Двойной планировщик
• Виртуализуется только ядро, и, например, нет видеокарты, вообще, почти нет ввода-вывода.

• Где-то между ними лежат решения на основе гипервизора. Можно написать очень маленькую ОС, которая решала бы три задачи, причём не ко всем, а только к самым главным — процессор и оперативная память. Поэтому это и называется гипервизор — визор, который управляется супервизорами. А под гипервизорами запускаятся почти любая ОС. Примеры: L4 (тут была другая задача — сделать микроядерную ОС, то етсь идею, что все Настоящие ОС должны выполнять ровно эту функцию по отношению к одному ресуру, всю остальную логику нужно выносить в юзерспейс. То есть при запуске регистрируется специальный процесс, который реализует логику раздачи страниц, а потом уже ядро делает по необходимости запрос к нему). Самый старый — HURD. Есть L4 linux, который сделан чтобы показать, что оно работает, и оно работает. Ещё один проект — Lquest. XEN. У XEN есть домены, есть нулевой домен, у которого ресурсы настоящие, и есть другие домены с синт ресурсами. Оверхед у Зена очень низкий. Ибо он реализован в виде гипервизора. У OVZ фактически все программы пользуются одним ядром. У зена ядер может быть много. И XEN, и OVZ очень внимательно относятся к появившиейся аппаратной виртуализации.

• Осталось сделать вирт машину как она есть, то есть программу, которая всем рассказывает, что она — компьютер. У неё есть своё оборудование: ком-порт, видеокарта. И когда нужно загрузиться, то можно сказать, что этот файл не файл а образ, и можно с него загрузиться, и ось, которая с него грузится, видит виртуальное оборудование. Которого не существует, но которое может взаимодействовать с реальным миром. В первую очередь это VMWare, QEmu. Но VMWare подгружает ядрёные модули и валит иногда этим систему. Ещё есьт kvm, который позволяет задействовать апп виртуализацию. Ещё kqemu — модуль для Qemu, который позволяет исполнять нативный код и использовать апп виртуализацию.

(в начале были вещи, котроые давно, в середине новые, в конце опять давно)

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

Зачем нам иерархия? Есть частная задача, для которой она нужна — хостинг. Долго ГК считал, что это есть главная движущая сила. Задача хостинга: есть мнение, что существует закон Мура, есть мнение, что это коммерческий трюк. Так или иначе, он пока наблюдается, и это означает, что рост производительности и индекс производительности экспоненциальный. А программные продукты растут линейно. Так что то, объём передаваемых данных человеку расти не может.

Один отдельно взятый процессор нельзя полностью нагрузить своими задачами. За исключением игр. Так что если мы не отмороженые геймеры, то нам не нужно покупать новый компьютер.

Раньше мы не могли пускать несколько задач на одном процессоре. Раньше мы не могли пустить двух админов за одну машину, а теперь можем.

Зачем нам нужно изолированное окружение: как сисадмин решает свои задачи. Посадили его за компьютер, сказали «это будет сервер». «Какой сервер?» «Веб-сервер». Соответственно, это не портал, поэтому достаточно будет Апача и движка. Получается решение задачи. Задача более-менее типовая, она описывается в виде входных требований (см. выше). Инструменты, которые мы подбираем это пакеты. Если их перечислять, то их будет довольно много:

• apache
• mod-php
• php-...
• mysql
• ...

Существует набор пакетов, которые надо ставить и настраивать. В этом состоял спор между ГК и одним товарищем, который говорил, что вирт окруж не нужны.

Это довольно частое решение. И когда в след раз возникнет такая задача, то поставятся те же пакеты, и так же настроить. Это не проблема. Проблема возникает, когда таких установок по 10 штук, или делать их какому-то оператору. Процесс воссоздания требует наблюдения специалиста. Надо автоматизировать. Но если машина не чистая, то может вохникнуть много проблем.

Так что можно держать своё окружение, а скрипт, который будет накладывать окружение, на виртуализованной машине.

И только в этом случае можно брать неквалифицированных сотрудников, когда реализрован изолированный deployment в качестве основного инструмента. И можно брать студента, которому платить по 10$ за инсталяцию, вместо зарплаты специалисту, который всё сам это придумает и настроит. Исключения будут, но это внештатные ситуации. Удельная стоимость деплоймента снижается в разы.

Если посмотреть на документацию OVZ, то она на 80 процентов написано для таких инженеров. Аналогично устроен XEN.

И нет необходимости делать дистрибутив.

Третье замечание: в идеале получаем решение которое не зависит от аппаратного окружения, особенно в случае с XEN'ом. То есть, туда не будет входит специальных модулей ядра и всего такого.

В случае зена есть такая ручка «переползи мне, окружение, с этого сервера, на тот». Это решает проблему с простоем. И балансировкой.

Этот сектор живой.

Есть прогноз, что в будущем все ОС будут поддерживать средства виртуализации.