Виртуализация — неотъемлемая часть IT-инфраструктуры. Она лежит в основе всех облачных систем, обеспечивает изоляцию ресурсов и гибкость управления. Такие возможности, конечно, появились не сразу. Технология прошла долгий путь: начавшись с одного системного вызова в 1980-х, она переросла в большие инженерные решения.
В этой статье я расскажу про развитие гипервизоров: от появления системного вызова chroot(2) до возникновения идеи о виртуализации в браузере.
Содержание
→ Системный вызов chroot(2)
→ Виртуальные окружения
→ Полная виртуализация
→ Виртуальные окружения наносят ответный удар
→ Микро виртуальные машины
→ Заключение
Системный вызов chroot(2)
История начинается на рубеже 1970-х и 1980-х годов, когда в операционной системе Unix v7 появился chroot(2). Этот системный вызов решал всего одну задачу: «переносил» корень файловой системы в указанный каталог для запущенного процесса.
В Unix-подобных операционных системах нет явного перечисления дисков. Основой служит единый корень (/). От него уже и «произрастает» иерархическая система каталогов, в которую монтируются любые физические накопители. Таким образом, фрагмент файловой системы может выглядеть, как на примере ниже:
/
├── bin
├── home
│ ├── user
│ ├── admin
│ ├── superadmin
│ ├── uberadmin
│ │ └── secret
│ └── hecker
│ └── notsosecret
├── root
├── tmp
│ ├── 212002
│ ├── 391485
│ ├── 393171
│ └── 400012
├── usr
└── varСистемный вызов chroot(2) позволяет для текущей программы и всех ее дочерних процессов назначить корнем другой каталог. Например, если выполнить chroot("/home/hecker"), то для программы файловая система примет вид:
/
└── notsosecretИными словами, все элементы файловой системы, которые оказались по иерархии выше нового корня, становится недоступными. У такого подхода есть как минимум два применения.
«Переход в ОС на диске» — системные администраторы применяют этот метод для возвращения работоспособности операционной системе с помощью образа для восстановления (rescue image). В таком сценарии запускается утилита
chroot(1), которая обращается к системному вызовуchroot(2), после чего открывает интерактивную оболочку.Изоляция программ в целях безопасности. Например, FTP-сервер
vsftpпозволяет ограничивать пользователей их домашним каталогом, чтобы те не скачали ничего лишнего, даже если права доступа выставлены верно. :)
Руководство по системной утилите
chrootпорой оказывается в разных секциях документации — в зависимости от дистрибутива и времени его выпуска.На онлайн‑ресурсе man7.org она расположена в разделе 1 — пользовательских утилит. В man-страницах Debian мы ее еще встречаем в традиционном разделе 8 — инструментов системного администрирования.
Системный вызов chroot(2) можно назвать прародителем виртуализации: он незаметно ограничивает видимость файловых ресурсов для выполняемой программы. Этого хватит, чтобы переиграть хакера, который лезет на сервер, но может быть недостаточно для полноценной взаимной изоляции запущенных процессов.
Четыре года назад я написал статью, в которой исследовал причины появления такого неочевидного решения — историю системного вызова chroot и его применение в наши дни. А если хотите увидеть заметки по готовящимся статьям, то подписывайтесь на мой Telegram‑канал.
Достоинства:
хоть какая-то изоляция программ на уровне файловой системы.
Недостатки:
недостаточная надежность — с правами суперпользователя программа имеет слишком большой контроль над системой.
Публичное облако на базе VMware
Знакомый интерфейс VMware Cloud Director®. Масштабирование под нагрузку и оплата по факту потребления.
Виртуальные окружения
Следующий шаг навстречу виртуализации сделал Пол-Хэннинг Кэмп (Poul-Henning Kamp) в 1999 году, работая у хостинг‑провайдера. Для бизнеса было важно отделить внутренние сервисы от приложений клиентов, а также надежно изолировать пользовательские среды друг от друга.
В теории задача могла быть решена тонкой настройкой операционной системы и программного обеспечения. Однако Пол-Хэннинг действовал иначе и реализовал во FreeBSD механизм «тюрем» (jail).
Каждая «тюрьма» — это виртуальное окружение, практически неотличимое от реальной системы. Оно имеет свою файловую систему, отдельный набор запущенных процессов и даже независимый аккаунт суперпользователя.
Процессы, запущенные в одной «тюрьме», не могут взаимодействовать с процессами других «тюрем» или хостовой машины.
Администратор хостовой системы получает возможность делегировать некоторые задачи, которые выполняются с правами суперпользователя, без передачи контроля над всей системой. Например, пользователь внутри «тюрьмы» оказывается способен самостоятельно устанавливать пакеты и управлять службами (демонами).
Сперва этот механизм был обкатан на работе Пола-Хэннинга, а в 2000 году технология FreeBSD Jails стала публично доступна в версии 4.0. Аналогичные решения вскоре появились и в других операционных системах:
2001, Linux-VServer — проект сообщества, ныне устарел;
2004, Solaris Containers — реализация для Oracle Solaris;
2007, IBM AIX Workload Partitions (WPAR) — решение для IBM AIX;
2008, Linux Containers (LXC) — реализация для Linux;
В сообществе встречается разная терминология, но обобщенно все подобные решения называются виртуализацией на уровне операционной системы (OS-level virtualization). При таком подходе ядро хостовой операционной системы создает виртуальное окружение, которое для процессов выглядит точь-в-точь как самостоятельная ОС.
Если во FreeBSD «тюрьмы» сразу стали цельной функцией ядра, то изоляция в Linux — это комбинация из нескольких взаимодополняющих технологий. Первая из них, пространство имен (namespaces), изолирует окружение от основной системы: скрывает другие процессы, точки монтирования, сетевые интерфейсы. Вторая технология, контрольные группы (cgroups), ограничивает потребление вычислительных ресурсов: ядер процессора, оперативной памяти, устройств ввода-вывода.
Достоинства:
виртуальные окружения максимально схожи с основной системой, при этом изолированы от нее и друг друга;
пользователям виртуальных окружений можно смело выдавать права суперпользователя без риска для хостовой ОС;
виртуальные окружения требуют относительно небольшие накладные расходы на вычислительные ресурсы.
Недостатки:
со стороны хостовой операционной системы требуется поддержка механизмов изоляции;
в виртуальном окружения невозможно запустить ОС, ядро которой отличается от хостовой системы.
По сути, виртуальные окружения — это защищенные «копии» текущей операционной системы, в которых не страшно дать пользователям максимальные права. Однако главный недостаток такого подхода виден уже в самом определении — жесткая привязка к хостовой ОС. Если на сервере работает Linux, а запустить требуется FreeBSD, то виртуальное окружение уже не поможет.
Вот здесь пора знакомиться с аппаратной виртуализацией.
Полная виртуализация
Пока Unix-подобные системы развивали изоляцию компонентов на программном уровне, мейнфреймы IBM «прокачивали» аппаратную виртуализацию. Первый шаг был сделан в 1967 году в исследовательской ОС IBM CP-40. Впервые разработчикам удалось создать виртуальное окружение, поддерживающее все возможности хостовой платформы System/360.
Важно отметить, что мейнфреймы использовались в крупных организациях, поэтому их операционная система изначально проектировалась для многопользовательского режима. Аппаратная виртуализация добавила еще одну степень свободы: один вычислительный комплекс обслуживает несколько пользователей одновременно, при этом у каждого из них — своя операционная система.
Вплоть до 1998 года полная виртуализация оставалась привилегией мейнфреймов. Главным препятствием для ее переноса на персональные компьютеры была архитектура их процессоров, абсолютно не предназначенная для виртуализации. Ситуацию переломила компания VMware, начав разработку гипервизора, способного программно обойти аппаратные ограничения архитектуры x86, мешающие виртуализации.
В 1999 году вышла первая версия VMware Workstation — гипервизора, который эмулировал архитектуру x86 и позволял запускать Windows поверх Linux и наоборот. Целевая аудитория нового продукта — разработчики и тестировщики, которым приходилось работать с несколькими операционными системами за одним компьютером.
Ограничения архитектуры процессоров нельзя было преодолеть без поддержки Intel и AMD, поэтому VMware пришлось разработать эмулятор процессора, так что гипервизор создавал полноценный виртуальный ПК. Получился хороший способ выполнять инструкции гостевой ОС без риска обрушить хостовую систему. Однако программная эмуляция такого уровня — задача крайне ресурсоемкая.
Тем не менее VMware не остановились на гипервизоре для персональных компьютеров и в 2001 году смело шагнули в корпоративный сегмент. Выпущенный гипервизор VMware ESX Server мог работать не только как программа внутри другой ОС, но и быть самостоятельной операционной системой — устанавливаться непосредственно на оборудование (bare-metal). Всего через два года появилась технология vMotion, которая позволяла переносить запущенные виртуальные машины между физическими хостами без остановки.
Гипервизоры, работающие как программа в операционной системе называют гипервизорами второго типа. Если же гипервизор устанавливается непосредственно на физическое оборудование, по сути являясь операционной системой, то относится к первому типу.
В 2003 году появился эмулятор QEMU (Quick Emulator), который решал задачу эмуляции систем с архитектурой, отличной от x86. Появилась возможность запускать «экзотические» операционные системы на персональных компьютерах. Сейчас QEMU не просто эмулятор, а полноценный монитор виртуальных машин (VMM), работающий в связке с аппаратными гипервизорами.
В том же 2003 году, вместе с гипервизором Xen, появилась альтернатива эмуляции — паравиртуализация. При классическом подходе гипервизор воссоздает полноценную виртуальную машину, внутри которой работает гостевая ОС, ничего не подозревающая о действительной среде выполнения. В паравиртуализации же гостевая ОС не просто знает, что работает в виртуальном окружении, а напрямую общается с интерфейсами гипервизора. Хотя такой подход требует модификации ядра гостевой системы, он позволяет значительно уменьшить накладные расходы на переключения и вычислительные операции.
Годом позже, в 2004‑м, появилась альтернатива VMware Workstation — гипервизор VirtualBox от компании InnoTek. Спустя три года, в 2007‑м, разработчики изменили модель распространения, и VirtualBox стал открытым ПО. В 2008 году InnoTek была поглощена Sun Microsystems, которая в свою очередь, перешла под контроль Oracle в 2010‑м.
Виртуализация хорошо прижилась в дата-центрах: возможность размещать разные гостевые операционные системы повысила среднюю утилизацию вычислительных мощностей, а возможность переносить виртуальные машины существенно облегчает техническое обслуживание физических хостов.
Разработчики гипервизоров проделали колоссальную работу, однако программная эмуляция по‑прежнему потребляла непозволительно много ресурсов. Лишь только в ноябре 2005‑го в ситуацию вмешалась Intel, представив технологию аппаратной виртуализации Intel VT-x на двух моделях Pentium 4 — она добавляла 13 новых инструкций, которые позволяли управлять режимом виртуализации и выполнять привилегированные команды (кольцо защиты 0) в гостевой ОС без угроз для хостовой системы. Спустя полгода, в мае 2006‑го, AMD представили свой аналог — AMD-V.
Переход от эмуляции процессора к выполнению инструкций непосредственно на физическом кристалле существенно увеличил быстродействие виртуальных машин. От эмуляции, тем не менее, разработчики гипервизоров не отказались: ни Intel VT-x, ни AMD-V не помогут запустить виртуальную машину на архитектуре, отличной от хостовой.
Аппаратное ускорение дало толчок к появлению новых гипервизоров — KVM (Kernel-based Virtual Machine) в 2007‑м и Microsoft Hyper-V в 2008‑м. В дальнейшем аппаратная виртуализация развивалась в сторону уменьшения накладных расходов при работе изолированных сред. В 2013‑м Intel внедрили аппаратную поддержку вложенной виртуализации, позволяющей запускать одни гипервизоры внутри других.
В итоге полная виртуализация хорошо себя зарекомендовала по целому ряду причин:
можно запускать практически любые операционные системы на различных аппаратных платформах;
если архитектуры гостевой и хостовой платформ совпадают, становятся доступны механизмы аппаратного ускорения, что увеличивает быстродействие;
гостевая операционная система полностью изолирована от хостовой, что гарантирует защиту от любых ситуаций внутри виртуальной машины.
Казалось бы, прекрасное решение: максимальная изоляция и безопасность. Что же в нем может быть плохого?
Запуск полной операционной системы даже с аппаратной виртуализацией — это ресурсоемкий процесс. В некоторых задачах — избыточный. Вот тут пути развития технологий вновь пересекаются с концепцией виртуальных окружений.
Виртуальные окружения наносят ответный удар
Полная виртуализация хороша, когда требуется запустить иную операционную систему или эмулировать компьютер другой архитектуры. Цена — долгая загрузка и большие накладные расходы. Виртуализация на уровне ОС, напротив, отлично справляется с быстрым созданием легковесных окружений, но ей как будто не хватает удобства.
В 2013 году на сцену выходит Docker — решение для изоляции отдельных приложений. В нем не было сложной магии виртуализации: в первых версиях он опирался на Linux Containers (LXC) для создания изолированных сред. Однако уже спустя год проект перешел на собственный компонент libcontainer, который напрямую взаимодействует с ядром операционной системы.
Docker не принес новых способов изоляции, но поменял отношение к существующим технологиям виртуализации. Он предложил контейнеры — новый высокоуровневый интерфейс для управления изолированными средами. Теперь вместо «админской магии» можно выполнить одну команду, а Docker настроит виртуальное окружение с нужным приложением.
По своей сути Docker — это именно виртуализация на уровне ОС, которая работает исключительно на Linux.
Здесь уместно задаться вопросом: «Как же тогда Docker функционирует и на macOS, и на Windows?» Что ж, ловкость рук и никакого мошенничества. Секрет в том, что Docker Desktop запускает виртуальную машину с Linux самостоятельно, либо использует подсистему WSL 2 (Windows Subsystem for Linux). А уже внутри этой неявно развернутой Linux‑среды создаются контейнеры.
Появление Docker, очевидно, было лишь началом. Если есть контейнеры, то для них нужен и управляющий. Так в 2014 году в Google появился Kubernetes — оркестратор контейнеров. Оркестратор знает где, сколько и каких Docker-контейнеров нужно запустить и следит за их «здоровьем».
В 2015 Docker Inc. совместно с другими лидерами индустрии предложили стандартизировать технологию виртуализации — под эгидой Linux Foundation родился проект Open Container Initiative. Спустя три года, в 2018‑м у Docker появился серьезный конкурент — Podman от компании Red Hat.
Контейнеры решают свои задачи, виртуальные машины — свою. Однако прогресс неостановим: разработчики нуждаются в виртуальных машинах с легковесностью контейнеров.
Микро виртуальные машины
Ранее мы отмечали, что виртуализация очень прижилась у провайдеров инфраструктуры: повышение средней утилизации серверов позволяет меньше терять доступные вычислительное мощности из‑за фактического простоя.
Продолжение пути уплотнения — сдача в аренду услуг, в которых пользователь абстрагируется от управления инфраструктурой — Platform-as-a-Service (PaaS) и Software-as-a-Service (SaaS). Клиент получает уже настроенное и готовое к работе приложение, а провайдер самостоятельно разворачивает все необходимые службы, но оптимальным для всех образом.
В 2007–2008 годах появились зачатки нового направления — serverless. Несмотря на название (serverless — дословно «безсерверные»), серверы все еще в деле, просто теперь обслуживанием всей инфраструктуры занимается провайдер.
На платформах Heroku и App Engine, можно развернуть свое приложение, не разбираясь с тонкостями виртуализации и не перебирая услуги провайдера. Внутри удобной абстракции — обычные виртуальные машины с предустановленной ОС и необходимыми зависимостями.
В 2014 году появилась модель Function-as-a-Service (FaaS), в которой приложение работает не постоянно, а вызывается отдельная требуемая функция при возникновении события — HTTP-запросе, сообщении в очереди или по таймеру.
У такого подхода есть очевидные плюсы: приложение расходует вычислительные ресурсы не постоянно, а только при необходимости. В масштабе провайдера инфраструктуры освобождаются значительные мощности. Выгодно и клиентам — они платят только за время работы приложения. Такая модель принесла новую техническую задачу: запускаться приложения должны быстро.
Изначально FaaS работал на контейнерах, но желание бизнеса ускорить процесс запуска и уплотнить виртуальные машины на одном хосте привели к созданию микроВМ (microVM).
MicroVM — это виртуальные машины на базе KVM, в которых из виртуализации исключены ненужные устройства и драйверы. Получается настоящая полная виртуализация с запуском самостоятельного ядра ОС, но но сама виртуальная машина существенно облегчена, что сокращает потребление оперативной памяти и ускоряет запуск гостевой ОС.
Заключение
Все описанные технологии виртуализации так или иначе используются до сих пор. Даже chroot, который не дает полноценную изоляцию, тем не менее, применяется в задачах администрирования.
Технологии, разработанные в 2000-х, прошли ряд улучшений и теперь повсеместно встречаются в красивых автоматизирующих обертках, которые в несколько команд позволяют выполнять сложные действия.
Виртуализация стала неотъемлемой частью современного интернета: облачные серверы живут на полной виртуализации, микросервисы — в контейнерах, функции — в микроВМ. Однако, до конечного пункта в развитии виртуализации еще далеко — например, WebAssembly позволяет запускать старые операционные системы прямо в браузере. Но это уже совершенно другая история…