Виртуализация... В последнее время это слово обрело просто магические свойства. О виртуализации говорят везде, где не запрещают, и все, кто только может. Однако чего-то по-настоящему нового и интересного не говорит почти никто. Я восполню этот пробел и расскажу о трех новых самых интересных и полезных технологиях виртуализации.

 

Пингвин в контейнере

Всего за несколько лет виртуализация из средства для ознакомления с новыми ОС и отладки системных приложений превратилась в один из самых важных элементов в индустрии IT. Сегодня без нее не обходится ни один серьезный сервер, хостинг и даже десктоп. Это настоящий стандарт, но, как любому стандарту, ему нужна стандартная реализация, легко и повсеместно доступная. В таких ОС как FreeBSD и Solaris стандартная реализация  системы виртуализации уровня ОС есть прямо из коробки: это механизмы FreeBSD Jail и Solaris Zones. Виртуализация уровня машины также доступна почти из коробки, с помощью установки пакета qemu во FreeBSD или VirtualBox в Solaris (хотя сюда тоже можно поставить qemu). В Linux все несколько иначе. Честную виртуализацию тут принято делать с помощью qemu-kvm, который опирается на ядерный драйвер KVM, доступный практически в любом дистрибутиве, а виртуализацию уровня ОС — с помощью сторонних разработок, таких как Linux-VServer или OpenVZ. Это отличные системы, но у них есть серьезный изъян: для своей работы они требуют патчинга ядра, а это не нравится ни пользователям, привыкшим к простоте современных Linux-дистрибутивов, ни админам, для которых пересборка ядра на сервере сродни игре в русскую рулетку (никогда не знаешь, как это повлияет на стабильность системы).

Именно поэтому появился проект LXC, позволяющий получить полноценную виртуализацию уровня ОС на обычном ванильном ядре. LXC (LinuX Containers) очень похож на Linux-VServer и OpenVZ, за тем лишь исключением, что вместо сторонних механизмов, внедряемых в ядро с помощью патчей, он использует механизмы "пространства имен" (namespaces) и "группировки процессов" (cgroups), доступные в любом современном Linux-ядре. Технология Linux namespaces позволяет размещать выбранное подмножество процессов в изолированном окружении чего-либо. Это может быть файловое пространство имен, содержащее дерево файлов, видное только этим процессам (аналог chroot), пространство имен процессов, IPC и так далее. Процессы, помещенные в обособленные пространства имен, будут "думать", что находятся на другой машине и не смогут взаимодействовать с остальными процессами и файловой системой. В дополнение к пространствам имен в ядре также доступен механизм группировки процессов под названием cgroups, который позволяет объединить несколько процессов в одну группу и применить к ней особые установки ядра (изменить приоритет, назначить ограничения ресурсов, поместить в обособленное пространство имен и так далее). Помещенный в группу процесс уже никогда не сможет самостоятельно ее покинуть, поэтому cgroups оказывается мощнейшим механизмом ограничений процессов в ресурсах (для которого, кстати, есть удобный инструмент управления, распространяемый в пакете libcgroups). Работая вместе, эти технологии реализуют очень мощную и гибкую систему виртуализации, возможности которой использует LXC, выступая в роли простой и удобной в использовании обертки к namespaces и cgroups.

И это не просто слова. Пользоваться LXC действительно просто и приятно. Например, чтобы создать виртуальный сервер в свежеустановленном Ubuntu, достаточно выполнить всего шесть следующих шагов (причем первые четыре шага — это просто подготовка системы к LXC, которую нужно выполнить всего один раз):

  1. Установить LXC и утилиты управления сетевым мостом:

$ sudo apt-get install lxc bridge-utils

  1. Запустить чекер конфигурации ядра, который проверит, все ли необходимые LXC опции включены (к слову сказать, LXC может работать, даже если некоторые из них ядром не поддерживаются):

$ sudo lxc-checkconfi g

  1. Создать каталог для файловой системы cgroups и смонтировать ее:

$ sudo mkdir /var/cgroup
$ sudo mount -t cgroup cgroup /var/cgroup

  1. Создать интерфейс моста, который будет использован для сетевой коммуникации между виртуальными окружениями (по-хорошему его придется еще и настроить):

$ sudo brctl addbr br0

  1. Создать виртуальное окружение с Ubuntu (или другим дистрибутивом) внутри (LXC поставляется с набором "шаблонов", расположенных в каталоге /usr/lib/lxc/templates, каждый из них представляет собой скрипт, выполняющий скачивание, установку и конфигурирование виртуального окружения):

$ sudo apt-get install debootstrap
$ sudo lxc-create -n ubuntu -t ubuntu -f /usr/share/doc/lxc/examples/lxc-veth.conf

Здесь '-t' указывает на имя шаблона внутри, а '-f' — на файл начальных настроек.

  1. Запустить окружение и проверить его работоспособность:

$ sudo lxc-start -d -n ubuntu
$ sudo lxc-info -n ubuntu

Далее можно зайти в окружение с помощью команды "sudo lxcconsole -n ubuntu". На экран вывалится стандартный консольный getty с просьбой ввести логин и пароль (по дефолту это root:root). Какие-либо настройки и модификации можно внести в окружение с помощью редактирования его корневой системы, расположенной в каталоге /var/lib/lxc/имя/rootfs, и конфигурационного файла /var/lib/lxc/имя/config. В целом, LXC — это простой, последовательный и гибкий инструмент, с помощью которого можно создавать самые разнообразные конфигурации (подстраивая разделение пространств имен и настройки cgroups под ситуацию), но у него есть один существенный недостаток — невозможность указать лимит на процессорное время.

 

Виртуальные специи

Не за горами тот день, когда любая домашняя машина превратится в тонкий клиент, созданный лишь для того, чтобы подключиться к интернету и дать пользователю доступ к приложениям в облаке. В будущем почти все наши программы будут исполняться на удаленных серверах, а домашние компы превратятся в маленькие коробочки, практически бесполезные без подключения к интернету. Но чтобы будущее сбылось, нужны соответствующие наработки. Сегодня надежды принято возлагать на web-технологии, которые уже используются многими интернет-компаниями для переноса вычислений в облака: почтовый клиент gmail, rss-читалка google reader, google docs и огромное количество других продуктов поколения web 2.0. Со временем их будет становиться все больше, а локальных приложений — все меньше. Проблема только в том, что web-технологии, сколь далеко бы они ни продвинулись, никогда не смогут сравниться с нэйтивными аналогами в скорости работы. Поэтому в Сети нет и не будет полноценных Photoshop’ов, 3D Max’ов или, например, игры Crysis. С другой стороны, подобного добра полно для Windows и Linux, и его даже можно использовать удаленно, если подключиться к машине с помощью программы просмотра удаленного рабочего стола. Но и здесь есть засада: ни один из Remote Desktop протоколов никогда не был рассчитан на работу с ОС. Это инструменты администрирования, поэтому запустив на удаленной стороне Photoshop или 3D Max, пользователь не получит ничего, кроме тормозов, ужасной картинки и жутких счетов за интернет. Здесь нужен сетевой протокол, который бы изначально был рассчитан на полноценную работу с операционной системой.

Технология SPICE (Simple Protocol for Independent Computing Environment — простой протокол для независимых вычислительных окружений), открытая Red Hat в 2009 году, как раз и является таким протоколом. Основная идея SPICE заключается в том, что эффективный протокол доступа к удаленному рабочему столу должен быть чем-то большим, чем просто механизмом передачи текущей картинки к клиенту, а изменений состояния устройств ввода — к серверу. Поэтому клиентские и серверные реализации SPICE — это не просто два связанных компонента, а целая инфраструктура, построенная из многих кирпичиков.

Первый компонент этой инфраструктуры — виртуальная машина, внутри которой должна работать операционная система и ее графический интерфейс (который будет передан SPICE-сервером клиенту).

Второй компонент — псевдоустройство QXL, выполняющее роль видеоадаптера внутри виртуальной машины. Работая в виртуальной машине, ОС выполняет все операции вывода графики через это QXL-устройство (оно может прикидываться обычной VGA-картой), транслирующее операции SPICE-серверу, который передает их клиенту. Основной профит всего этого в том, что работая на самом низком уровне, QXL получает возможность всячески оптимизировать графические операции, чтобы, во-первых, по сети было передано как можно меньше информации, а во-вторых, чтобы не загружать сервер дополнительными вычислениями. В частности, QXL-драйвер может производить такие оптимизации как передача графических команд вместо целых участков буфера — например, команда "размыть прямоугольник" вместо отсылки буфера, содержащего уже размытую область экрана (но для большинства таких операций нужна установка QXL-драйвера в ОС); сжатие изображения с помощью алгоритмов, специально разработанных для этой цели (Quic, Lemel-Ziv, Global LZ), выбирая наиболее подходящий алгоритм эвристическим путем; сжатие видеопотоков с помощью M-JPEG и другие.

Третий компонент SPICE — это сервер, встроенный прямо в виртуальную машину. Его задача — поддерживать связь с клиентом и передавать данные от устройств ввода клиента к серверу, а результаты работы устройства QXL и аудиоустройства — клиенту. При этом передача осуществляется через несколько независимых каналов, каждый из которых отвечает за свой тип данных. Видеоканал используется для передачи команд и данных от QXL-устройства, канал входных данных — для событий от клавиатуры и мыши клиента. Курсорный канал — для передачи данных о положении курсора и так далее. Количество каналов не ограничено и возможно будет увеличено в будущих версиях протокола.

Четвертый компонент SPICE — клиентская программа, которая занимается отправкой состояния устройств ввода на сервер и формированием изображения из принятых команд устройства QXL. Все полученные графические объекты клиент аккуратно кэширует, так что если в будущем над одним из них произойдет какое-то действие, его не придется загружать с сервера повторно.

В совокупности все это делает SPICE очень гибким и эффективным протоколом. Если, например, пользователь просто подвигал мышь, то все, что будет передано по сети, это изменившиеся координаты курсора. При этом сама отрисовка движений мыши будет произведена на стороне клиента, без задействования мощностей сервера. Это возможно благодаря QXL, который еще перед отправкой изображения определил курсор как отдельный графический буфер и передал клиенту, который закешировал его на своей стороне. Операция перетаскивания окна также будет очень эффективна: клиенту передастся всего лишь одна команда изменения координат окна (точнее, графического буфера в терминах QXL).

SPICE-серверы обладают интеллектом и умеют адаптироваться под изменяющуюся ситуацию. Например, если один из серверов SPICE окажется слишком загружен, клиент будет прозрачно перенесен на другой сервер. То же относится и к возможностям клиентской стороны. Если, например, клиент отличается низкой производительностью, но широким каналом (например, планшет, работающий в WiMAX-сети), то SPICE автоматически перенастроит QXL-драйвер таким образом, чтобы тот отдавал клиенту уже готовую и обработанную картинку (графический буфер вместо команды по его отрисовке, несжатое видео и так далее). Это разгрузит клиентскую сторону.

Но самое замечательное в SPICE то, что его поддержка уже внедрена в виртуальную машину qemu, так что для настройки сервера и клиента не придется делать ничего, кроме ввода нескольких простых команд:

  1. На стороне сервера следует запустить qemu с аргументом '-spice':

$ qemu-kvm -spice port=1234,disable-ticketing hda /путь/образа/диска

  1. На стороне клиента запустить SPICE-клиент (он распространяется в пакете spice-client), указав адрес и порт сервера:

$ spicec -h localhost -p 1234

Соединение можно зашифровать и защитить паролем, убрав опцию 'disable-ticketing' и указав вместо нее 'password=пароль'.

 

Кооперативный Linux

Можно долго спорить о том, что лучше, Windows или Linux, а можно просто начать использовать обе операционные системы вместе. В современном мире сделать это не составляет труда — достаточно обзавестись машиной с более-менее современным процессором, поддерживающим аппаратную виртуализацию, установить виртуальную машину и поставить внутрь нужную ОС. Вуаля, на компе появилась новая ОС, доступная через щелчок мышкой по нужной иконке. Это отличный способ ознакомиться с новой ОС или держать под рукой инструмент, потребность в котором возникает нечасто. Однако как бы ни были удобны современные виртуалки, они слишком громоздки и навязчивы. Если, например, ты держишь виртуальную машину с Windows только для того, чтобы запускать на ней MS Office, это оказывается далеко не самым изящным и удобным решением. Гораздо проще воспользоваться возможностями "не эмулятора" Wine, который позволит запустить нужную программу без использования каких-то дополнительных оберток и мишуры в виде полноценного рабочего стола Windows и всех его сервисов. По многим параметрам Wine превосходит обычные средства виртуализации, и, наверное, есть желающие увидеть нечто подобное для Windows. Cooperative Linux (сокращенно CoLinux) разработана специально для них. Однако это далеко не Wine и даже не обычная виртуальная машина.

В отличие от Wine, который является простой программой, реализующей набор системных функций Win32 поверх Linux и виртуальных машин, воссоздающих весь комп в виде программы, система CoLinux остается все тем же ядром Linux, работающим на настоящем железе (с тем исключением, что существует оно скорее в качестве паразита, нежели полноценной операционной системы). Ядро CoLinux получает свое место под солнцем,  прикидываясь обычным Windows-драйвером. Это дает ему возможность работать на правах самого настоящего ядра, но в то же время не нарушать работу ядра Windows. Доступ к оборудованию (такому как видеоадаптер, аудиокарта, сетевая карта и так далее) у CoLinux в этом случае ограничен (все устройства уже заняты драйверами Windows). Поэтому он просто запрашивает все нужные ресурсы у других Windows-драйверов и компонентов родительской ОС. В CoLinux есть псевдодрайвер conet, который взаимодействует с сетевым драйвером Windows для того, чтобы получить доступ к сети. Драйвер cocon используется для реализации псевдоконсоли Linux, которая на самом деле представляет собой окно Windows, реализуемое специальным Windows-сервисом, работающим в паре с CoLinux-ядром-драйвером. Таким же образом внутри CoLinux реализован псевдодрайвер cobd, предоставляющий доступ к жесткому диску, который находится внутри файла на одном из дисков Windows. Для запуска графических приложений используется X-сервер Xming, работающий прямо в Windows (не забываем, что X — сетевой протокол, а доступ к сети и, следовательно, к любым сетевым приложениям, работающим внутри родительской Windows, у CoLinux есть). Вывод аудио осуществляется через звуковой сервер PulseAudio, точно так же работающий в Windows и принимающий звуковой поток через сеть.

Со стороны пользователя CoLinux выглядит чрезвычайно прозрачно. Linux-приложения запускаются и работают в отдельных Windows-окнах, исправно функционирует буфер обмена, консоль и даже трей. Единственная проблема заключается в том, что ядра Windows и Linux теперь работают в одном адресном пространстве, а это просто огромная брешь в безопасности и возможная причина нестабильной работы ОС. Но стоит ли волноваться по этому поводу на домашней/рабочей/учебной машине? Большинство пользователей Windows создают гораздо большую дыру, просто работая под аккаунтом администратора.

Несмотря на то, что CoLinux — это всего лишь ядро, на сайте проекта можно найти адаптированные сборки почти всех популярных дистрибутивов Linux. Огорчает только то, что большинство из них уже устарело (например, последняя версия Ubuntu для CoLinux имеет номер 9.04). Проект AndLinux  предлагает более свежую сборку Ubuntu от 22 мая 2009 года, да еще и в двух вариантах (KDE и XFCE-редакции, тогда как на официальном сайте CoLinux Ubuntu распространяется только в виде базовой системы размером 40 Мб).

Установить AndLinux очень просто, его можно скачать с сайта проекта в виде стандартного Windows-инсталлятора (goo.gl/jKhyZ) и, ответив на несколько вопросов, благополучно установить в свой Windows. Вопросы инсталлятор AndLinux задает довольно оригинальные, поэтому на них стоит остановиться подробнее. Первый вопрос касается версии ядра CoLinux: стабильное 0.7.4 против экспериментального 0.8.0. Существенной разницы между ними нет, поэтому выбрать можно любое. Второй вопрос касается памяти, выделяемой на нужды CoLinux: 128 Мб, 192 Мб и далее по возрастающей вплоть до 1 Гб. Это всего лишь барьер, все незанятые мегабайты останутся у Windows, поэтому можно смело выбирать максимум. Далее идут вопросы по поводу активации Xming, PulseAudio и режиму запуска. Последних у AndLinux целых пять, однако фактически их только два: вручную или NT-сервисом. Первый подойдет в тех случаях, когда CoLinux ставится "на всякий случай", второй — для повседневного использования. Далее следует ввести имя и пароль пользователя AndLinux (интересно, что вопреки традиции UNIX, имя может содержать только буквы алфавита и ничего больше), выбрать способ расшаривания файловой системы Windows для CoLinux: никакого, специальный драйвер CoFS или Samba (в последнем случае инсталлятор требует наличия хотя бы одного расшаренного диска в системе) и, наконец, согласиться на немедленную перезагрузку машины.

После загрузки на рабочем столе появятся два ярлыка CoLinux-консоли (обычная, в стиле командной строки Windows, и расширенная, со строкой состояния и диагностическим субокном). Трей также будет содержать ярлык AndLinux, реализующий не что иное, как меню freedesktop. В минимальной версии дистрибутива доступны только базовые программы XFCE-десктопа: терминал, текстовый редактор, файловый браузер Thunar и менеджер пакетов Synaptic. Расширенная KDE-версия AndLinux содержит почти полный комплект приложений KDE 3.5.

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

 

Выводы

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

 

Links

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии