Виртуализация как основа облачной инфраструктуры
Облачные вычисления, рассмотренные в предыдущей теме, опираются на способность предоставлять вычислительные ресурсы по запросу, динамически распределять их между потребителями и обеспечивать логическую изоляцию нагрузок. Все эти свойства предполагают наличие промежуточного программного уровня, который отделяет прикладные задачи от физического оборудования. Таким уровнем является виртуализация.
Виртуализация не является изобретением облачной эпохи. Первые практические реализации виртуальных машин появились ещё в 1960-х годах в контексте мэйнфреймов IBM, где требовалось одновременно исполнять несколько независимых операционных сред на одном дорогостоящем вычислительном узле. Однако именно в сочетании с облачной моделью виртуализация приобрела массовое промышленное значение: она стала технологической основой, на которой строятся центры обработки данных, платформы IaaS и большинство управляемых облачных сервисов.
Настоящая тема раскрывает назначение виртуализации, типы гипервизоров и подходов к виртуализации, ресурсную модель виртуальной машины, а также механизмы изоляции и управления ресурсами, реализуемые на уровне ядра операционной системы. Каждый из этих вопросов важен не только теоретически, но и практически: без понимания механизмов виртуализации невозможно корректно оценить ни возможности облачных платформ, ни ограничения различных подходов к изоляции вычислительных сред.
Назначение виртуализации
Абстрагирование физических ресурсов и формирование управляемых вычислительных сред
Основная идея виртуализации состоит в создании программной абстракции над физическим оборудованием. Вместо того чтобы предоставлять приложению прямой доступ к процессору, оперативной памяти, дисковому хранилищу и сетевому интерфейсу конкретного сервера, виртуализация формирует промежуточный уровень, который представляет эти ресурсы в виде логических сущностей. Приложение и операционная система, работающие внутри виртуальной машины, взаимодействуют с виртуальным оборудованием так, как если бы оно было физическим, но в действительности все обращения транслируются программным слоем виртуализации.
Такое абстрагирование решает несколько фундаментальных задач. Во-первых, оно позволяет разместить на одном физическом сервере несколько независимых вычислительных сред, каждая из которых содержит собственную операционную систему, собственный набор приложений и собственную конфигурацию. Во-вторых, оно обеспечивает логическую изоляцию между этими средами: сбой или компрометация одной виртуальной машины не затрагивает другие, размещённые на том же оборудовании. В-третьих, абстрагирование делает вычислительные ресурсы управляемыми программно: виртуальную машину можно создать, остановить, клонировать, перенести на другой физический узел или уничтожить через программный интерфейс, без физического доступа к оборудованию.
Именно программная управляемость превращает виртуализацию из механизма разделения ресурсов в инструмент построения масштабируемой инфраструктуры. Без неё облачная модель — с её требованиями к самообслуживанию, эластичности и измеряемости — была бы практически нереализуема. Каждый раз, когда потребитель облачного сервиса создаёт виртуальный сервер через веб-консоль или API, он фактически инициирует процесс создания виртуальной машины на одном из физических узлов центра обработки данных.
Консолидация нагрузок и повышение коэффициента использования оборудования
Одним из наиболее осязаемых практических эффектов виртуализации является консолидация нагрузок (workload consolidation). В традиционной модели каждому приложению или сервису нередко выделяется отдельный физический сервер. Такой подход мотивирован соображениями изоляции и совместимости: различные приложения могут требовать разных версий операционной системы, конфликтующих библиотек или несовместимых настроек среды. Однако следствием этого является крайне низкий коэффициент использования оборудования. Исследования показывают, что средняя загрузка физических серверов в традиционных центрах обработки данных составляет от 5 до 15 процентов вычислительной мощности. Остальные ресурсы простаивают, но продолжают потреблять электроэнергию и занимать место.
Виртуализация позволяет разместить на одном физическом сервере десятки виртуальных машин, каждая из которых функционирует как изолированная вычислительная среда. Это повышает коэффициент использования оборудования до 60–80 процентов и более, что даёт значительный экономический эффект: сокращается количество физических серверов, снижаются затраты на электроэнергию, охлаждение, размещение и обслуживание.
Вместе с тем консолидация нагрузок не является безусловно позитивным явлением. Размещение слишком большого числа виртуальных машин на одном физическом узле приводит к конкуренции за ресурсы: процессорное время, пропускную способность памяти и дисковую подсистему. Если совокупная потребность виртуальных машин систематически превышает возможности оборудования, возникает деградация производительности, которая может затронуть все размещённые нагрузки. Поэтому планирование ёмкости (capacity planning) является обязательной дисциплиной при эксплуатации виртуализированной инфраструктуры.
Роль виртуализации в построении центров обработки данных и облачных платформ
Современный центр обработки данных (ЦОД), обслуживающий облачную платформу, представляет собой не просто совокупность серверов, а управляемую среду, в которой физические ресурсы объединены в единый пул и предоставляются потребителям через программные интерфейсы. Виртуализация является ключевым компонентом этой архитектуры. Она обеспечивает абстрагирование оборудования, изоляцию потребителей друг от друга (multi-tenancy), управление жизненным циклом виртуальных сред и динамическое перераспределение ресурсов.
На уровне облачной платформы виртуализация реализует несколько критически важных функций. Миграция виртуальных машин между физическими узлами (live migration) позволяет проводить обслуживание оборудования без остановки пользовательских нагрузок. Моментальные снимки состояния (snapshots) обеспечивают возможность отката к предыдущему состоянию в случае сбоя. Шаблонизация ускоряет массовое развертывание однотипных сред. Автоматизированное управление ресурсами позволяет платформе перераспределять нагрузки в зависимости от текущего потребления.
Следует, однако, учитывать, что виртуализация не является единственной технологией, используемой в облачных платформах. Современные платформы дополняют её программно-определяемыми сетями (Software-Defined Networking, SDN), программно-определяемым хранилищем (Software-Defined Storage, SDS) и системами оркестрации, которые координируют работу всех компонентов. Тем не менее именно виртуализация вычислительных ресурсов остаётся фундаментальным слоем, без которого остальные надстройки не имеют основания.
Гипервизоры и типы виртуализации
Понятие гипервизора
Гипервизор (hypervisor), или монитор виртуальных машин (Virtual Machine Monitor, VMM), представляет собой программный компонент, обеспечивающий создание и управление виртуальными машинами. Гипервизор располагается между физическим оборудованием и гостевыми операционными системами, выполняя функции распределения ресурсов, изоляции и трансляции обращений гостевых систем к аппаратуре. Именно гипервизор определяет, какие ресурсы доступны каждой виртуальной машине, каким образом обращения к оборудованию транслируются и как обеспечивается взаимная независимость виртуальных сред.
С точки зрения архитектуры гипервизоры принято разделять на два типа, различающихся способом взаимодействия с аппаратным обеспечением.
Гипервизор первого типа (type 1 hypervisor)
Гипервизор первого типа, называемый также «bare-metal hypervisor», устанавливается непосредственно на физическое оборудование, без промежуточной операционной системы общего назначения. Он берёт на себя функции управления аппаратными ресурсами и предоставляет их гостевым операционным системам. Фактически гипервизор первого типа сам является минимальной операционной средой, специализированной на задачах виртуализации.
Примерами гипервизоров первого типа являются VMware ESXi, Microsoft Hyper-V (в режиме серверной роли), Xen и KVM. Последний заслуживает отдельного пояснения. KVM (Kernel-based Virtual Machine) встроен в ядро Linux и превращает операционную систему Linux в гипервизор первого типа. Хотя Linux при этом продолжает функционировать как операционная система общего назначения, с точки зрения архитектуры виртуализации KVM классифицируется как гипервизор первого типа, поскольку модуль виртуализации работает на уровне ядра и взаимодействует с аппаратными средствами виртуализации процессора напрямую.
Гипервизоры первого типа применяются в центрах обработки данных и облачных платформах, где требуется высокая производительность, надёжная изоляция и возможность управления большим количеством виртуальных машин. Отсутствие промежуточной операционной системы общего назначения снижает накладные расходы и уменьшает поверхность атаки.
Гипервизор второго типа (type 2 hypervisor)
Гипервизор второго типа устанавливается как обычное приложение поверх существующей операционной системы. Хостовая операционная система управляет аппаратными ресурсами, а гипервизор работает в её пользовательском пространстве, создавая виртуальные машины как процессы хостовой среды. Обращения гостевых систем к аппаратуре проходят через два программных уровня: сначала через гипервизор, затем через хостовую операционную систему.
Примерами гипервизоров второго типа являются Oracle VirtualBox и VMware Workstation. Такие решения широко используются для разработки, тестирования и обучения, поскольку не требуют выделенного оборудования и позволяют запускать виртуальные машины на обычном рабочем компьютере наряду с другими приложениями.
Основным недостатком гипервизоров второго типа являются более высокие накладные расходы. Дополнительный программный уровень в виде хостовой операционной системы вносит задержки при обработке обращений к аппаратуре. Кроме того, гостевые операционные системы конкурируют за ресурсы не только друг с другом, но и с приложениями хостовой системы. Поэтому для задач промышленной эксплуатации гипервизоры второго типа, как правило, не используются.
Полная виртуализация, паравиртуализация и аппаратная поддержка
Помимо архитектурной классификации гипервизоров по типу размещения, существует классификация по способу обработки привилегированных инструкций гостевых операционных систем. Этот вопрос связан с тем, что операционная система, исполняющаяся внутри виртуальной машины, полагает себя единственным владельцем аппаратных ресурсов и пытается выполнять привилегированные операции — управление таблицами страниц памяти, обращения к устройствам ввода-вывода, управление прерываниями, — которые в действительности должны быть перехвачены гипервизором.
При полной виртуализации (full virtualization) гостевая операционная система не модифицируется. Она исполняется в неизменённом виде, а гипервизор перехватывает и эмулирует привилегированные инструкции. Это обеспечивает максимальную совместимость: внутри виртуальной машины можно запустить практически любую операционную систему без её адаптации. Однако эмуляция привилегированных операций создаёт вычислительные накладные расходы, которые могут быть заметны при интенсивных операциях ввода-вывода или при работе с памятью.
Паравиртуализация (paravirtualization) предполагает модификацию гостевой операционной системы. Вместо выполнения привилегированных инструкций напрямую гостевая система использует специальные программные интерфейсы (hypercalls) для обращения к гипервизору. Это позволяет избежать затратного перехвата и эмуляции, повышая производительность. Однако паравиртуализация требует изменений в ядре гостевой операционной системы, что ограничивает набор совместимых систем и усложняет сопровождение. Наиболее известной реализацией паравиртуализации является гипервизор Xen в его раннем варианте.
Аппаратная поддержка виртуализации (hardware-assisted virtualization) появилась в процессорах Intel (технология VT-x) и AMD (технология AMD-V) в середине 2000-х годов. Она вводит специальный режим работы процессора, в котором гостевые операционные системы могут безопасно исполнять привилегированные инструкции, а процессор аппаратно обеспечивает перехват тех операций, которые должны обрабатываться гипервизором. Аппаратная поддержка существенно сократила накладные расходы полной виртуализации, сделав её производительность сопоставимой с паравиртуализацией. В результате аппаратная виртуализация стала доминирующим подходом в современных системах. KVM, VMware ESXi и Microsoft Hyper-V опираются на аппаратную поддержку процессора как на обязательное условие работы.
Влияние выбранного подхода на практику
Выбор типа гипервизора и подхода к виртуализации определяется конкретными требованиями. Для промышленной облачной инфраструктуры стандартом де-факто являются гипервизоры первого типа с аппаратной поддержкой виртуализации, обеспечивающие оптимальное соотношение производительности, совместимости и изоляции. Для учебных и исследовательских задач гипервизоры второго типа остаются удобным и доступным инструментом.
Важно осознавать, что производительность виртуальной машины всегда несколько ниже, чем производительность приложения, исполняющегося непосредственно на физическом оборудовании. Даже при наличии аппаратной поддержки виртуализации существуют накладные расходы на трансляцию обращений к памяти, эмуляцию устройств ввода-вывода и управление переключениями контекста между гостевыми системами. В большинстве прикладных сценариев эти расходы составляют единицы процентов и несущественны, однако для задач с высокими требованиями к производительности — высоконагруженные базы данных, системы реального времени, ресурсоёмкие вычисления — они могут стать значимым фактором.
Ресурсная модель виртуальной машины
Виртуальные процессоры, оперативная память, дисковые образы и виртуальные сетевые интерфейсы
Виртуальная машина представляется гостевой операционной системе как полноценный компьютер с определённым набором аппаратных ресурсов. Эти ресурсы являются виртуальными, то есть предоставляются гипервизором на основе физических ресурсов хоста, но с точки зрения гостевой системы они неотличимы от реального оборудования.
Виртуальные процессоры (virtual CPU, vCPU) соответствуют логическим ядрам физического процессора, выделяемым виртуальной машине. Количество виртуальных процессоров определяет, сколько потоков вычислений гостевая система может выполнять параллельно. Гипервизор планирует исполнение виртуальных процессоров на физических ядрах, обеспечивая разделение процессорного времени между виртуальными машинами. При этом суммарное количество виртуальных процессоров всех виртуальных машин на одном хосте может превышать количество физических ядер — это называется переподпиской (overcommitment) процессорных ресурсов. Умеренная переподписка допустима, если нагрузки не являются одновременно интенсивными, но при чрезмерной переподписке неизбежна деградация производительности.
Оперативная память виртуальной машины выделяется из общего объёма физической памяти хоста. Гипервизор обеспечивает изоляцию адресного пространства: каждая гостевая система видит собственный непрерывный диапазон адресов, хотя в действительности эти адреса могут быть размещены в различных физических областях. Некоторые гипервизоры поддерживают механизмы оптимизации памяти, такие как дедупликация одинаковых страниц (memory deduplication) и динамическое перераспределение памяти (memory ballooning), однако эти технологии имеют свои ограничения и не всегда применимы.
Дисковые ресурсы виртуальной машины представлены в виде образов дисков (disk images) — файлов или блочных устройств, которые гипервизор предоставляет гостевой системе как виртуальные жёсткие диски. Распространёнными форматами образов являются VMDK (VMware), VHD и VHDX (Microsoft), QCOW2 (QEMU/KVM) и RAW. Выбор формата влияет на производительность, возможность создания снимков состояния и эффективность использования дискового пространства. Формат RAW обеспечивает наименьшие накладные расходы, но занимает полный объём выделенного пространства. Формат QCOW2 поддерживает динамическое выделение (thin provisioning), при котором файл образа увеличивается по мере фактической записи данных, а также позволяет создавать снимки состояния.
Виртуальные сетевые интерфейсы обеспечивают подключение виртуальной машины к сети. Гипервизор эмулирует сетевой адаптер, который гостевая система использует для передачи и приёма данных. Виртуальные интерфейсы могут быть подключены к различным типам виртуальных сетей: мостовым (bridged), обеспечивающим доступ к физической сети хоста, внутренним (internal), связывающим только виртуальные машины на одном хосте, или изолированным (host-only), ограничивающим связность виртуальной машиной и хостом. Для повышения производительности сетевого ввода-вывода используются паравиртуализированные сетевые драйверы (например, virtio в среде KVM), которые снижают накладные расходы на эмуляцию полноценного аппаратного адаптера.
Шаблоны, снимки состояния и клонирование
Помимо основных вычислительных ресурсов, виртуализация предоставляет ряд инструментов, существенно упрощающих управление вычислительными средами.
Шаблон (template) виртуальной машины представляет собой предварительно настроенный образ, содержащий операционную систему, базовое программное обеспечение и конфигурацию. Шаблоны используются для быстрого развертывания новых виртуальных машин: вместо установки операционной системы с нуля администратор создаёт экземпляр на основе шаблона, что сокращает время подготовки среды с десятков минут до нескольких секунд. В контексте облачных платформ шаблоны лежат в основе каталогов готовых образов (например, Amazon Machine Images в AWS или образов в Yandex Cloud).
Снимок состояния (snapshot) фиксирует полное состояние виртуальной машины в определённый момент времени: содержимое дисков, состояние оперативной памяти и конфигурацию виртуального оборудования. Снимки позволяют оперативно вернуться к зафиксированному состоянию, что особенно полезно при тестировании обновлений, экспериментах с конфигурацией и в учебных сценариях. Однако снимки не являются полноценной заменой резервного копирования. Длительное накопление снимков увеличивает объём занимаемого дискового пространства, усложняет управление и может негативно сказаться на производительности дисковой подсистемы, поскольку каждая операция записи должна учитывать цепочку зависимых снимков.
Клонирование (cloning) создаёт полную копию существующей виртуальной машины, включая её дисковые образы и конфигурацию. Клон представляет собой независимый экземпляр, который после создания существует и развивается отдельно от оригинала. Клонирование используется для масштабирования однотипных сред, создания тестовых копий и подготовки учебных лабораторий.
Ограничения виртуальной машины
При всех достоинствах виртуализации виртуальная машина обладает рядом ограничений, которые необходимо учитывать при проектировании инфраструктуры.
Первое ограничение — накладные расходы на гостевую операционную систему. Каждая виртуальная машина содержит полноценный экземпляр операционной системы со всеми её компонентами: ядром, системными службами, библиотеками и конфигурационными файлами. Это означает, что значительная доля ресурсов — оперативной памяти и дискового пространства — расходуется не на прикладную задачу, а на поддержание операционной среды. Если на одном физическом сервере размещено двадцать виртуальных машин с одной и той же операционной системой, ядро этой системы загружено в память двадцать раз, и двадцать экземпляров системных служб потребляют процессорное время.
Второе ограничение — длительность запуска. Создание и загрузка виртуальной машины включает инициализацию виртуального оборудования, загрузку ядра операционной системы и запуск системных служб. Этот процесс занимает от десятков секунд до нескольких минут в зависимости от конфигурации. Для задач, требующих быстрого масштабирования и мгновенного развертывания экземпляров, такая задержка может быть неприемлемой.
Третье ограничение — объём артефакта. Образ виртуальной машины, включающий операционную систему и прикладное программное обеспечение, может занимать гигабайты дискового пространства. Передача таких образов по сети, их хранение и версионирование требуют значительных ресурсов.
Перечисленные ограничения не делают виртуализацию непригодной — напротив, для широкого спектра задач она остаётся оптимальным решением. Однако именно эти ограничения стали одной из предпосылок появления контейнеризации как альтернативного, более легковесного подхода к изоляции приложений.
Механизмы изоляции на уровне ядра операционной системы
Помимо аппаратной виртуализации, реализуемой гипервизорами, современные ядра операционных систем предоставляют собственные механизмы изоляции и управления ресурсами. Эти механизмы позволяют разделять процессы и группы процессов на уровне операционной системы, обеспечивая логическое разграничение без создания полноценных виртуальных машин. Понимание этих механизмов важно в контексте виртуализации, поскольку они составляют основу легковесных форм изоляции, широко применяемых в современных облачных платформах.
Пространства имён (namespaces)
Пространства имён (namespaces) обеспечивают логическое разделение глобальных ресурсов ядра между процессами. Каждое пространство имён создаёт для входящих в него процессов изолированное представление определённого ресурса, скрывая существование одноимённых ресурсов в других пространствах. Linux реализует несколько типов пространств имён, каждый из которых изолирует отдельную категорию ресурсов.
Пространство имён процессов (PID namespace) скрывает от группы процессов все остальные процессы системы. Внутри пространства имён нумерация процессов начинается заново с единицы. Первый процесс, запущенный в изолированной среде, получает идентификатор PID 1 в пределах своего пространства имён, хотя хостовая система видит его под иным глобальным идентификатором.
Сетевое пространство имён (network namespace) предоставляет изолированный сетевой стек: собственные сетевые интерфейсы, таблицы маршрутизации, правила сетевого экрана и диапазон портов. Благодаря этому несколько групп процессов на одном хосте могут одновременно использовать одни и те же номера портов, не конфликтуя друг с другом.
Пространство имён точек монтирования (mount namespace) изолирует файловую систему: каждая группа процессов видит собственное дерево каталогов, независимое от основной файловой системы хоста и от файловых систем других изолированных сред.
Пространство имён узла (UTS namespace) позволяет группе процессов иметь собственное имя хоста (hostname) и доменное имя, независимое от хостовой системы. Это важно для приложений, которые используют имя хоста для идентификации узла в распределённой системе.
Пространство имён межпроцессного взаимодействия (IPC namespace) изолирует механизмы взаимодействия между процессами: разделяемую память, очереди сообщений и семафоры POSIX. Процессы внутри изолированной среды могут взаимодействовать через эти механизмы, не затрагивая процессы за её пределами.
Пространство имён пользователей (user namespace) позволяет отображать идентификаторы пользователей и групп внутри изолированной среды на иные идентификаторы снаружи. Практически значимым следствием этого является возможность предоставить процессу привилегии суперпользователя (UID 0) в пределах пространства имён, тогда как на уровне хостовой системы он будет работать с ограниченными правами непривилегированного пользователя. Данный механизм снижает риски эскалации привилегий при нарушении изоляции.
Группы управления ресурсами (control groups, cgroups)
Группы управления ресурсами (control groups, cgroups) решают задачу, принципиально отличную от пространств имён. Если пространства имён определяют, какие ресурсы видит процесс, то cgroups определяют, сколько ресурсов он может потребить. С их помощью можно задать верхние пределы потребления процессорного времени, оперативной памяти, пропускной способности дисковой подсистемы и сетевого интерфейса. При достижении лимита памяти, например, ядро может завершить наиболее ресурсоёмкий процесс группы или ограничить его выполнение — в зависимости от настроенной политики. Без количественных ограничений одна неконтролируемая группа процессов способна исчерпать все ресурсы хоста, нарушая работу остальных.
Соотношение аппаратной и программной изоляции
Механизмы изоляции ядра и гипервизорная виртуализация решают схожую задачу — разграничение вычислительных сред — но на разных уровнях абстракции и с различными гарантиями. Гипервизор создаёт аппаратную границу между гостевой и хостовой системой, опираясь на поддержку процессора. Пространства имён и cgroups — это программные средства одного и того же ядра операционной системы, а не аппаратные барьеры. Уязвимость в ядре хостовой системы потенциально затрагивает все изолированные среды, работающие на этом ядре. Поэтому изоляция средствами ядра считается менее строгой по сравнению с изоляцией, обеспечиваемой гипервизором.
В сценариях с высокими требованиями к безопасности дополнительно используются специализированные механизмы: seccomp-профили, ограничивающие набор доступных системных вызовов; политики AppArmor и SELinux, реализующие мандатный контроль доступа; а также изолирующие среды исполнения, добавляющие промежуточный уровень между процессами и ядром.
Итоги темы
Виртуализация является фундаментальной технологией, обеспечивающей абстрагирование физических ресурсов и формирование управляемых вычислительных сред. Она позволяет размещать на одном физическом сервере множество независимых виртуальных машин, каждая из которых содержит полноценную операционную систему и работает в изолированном окружении. Консолидация нагрузок повышает коэффициент использования оборудования, а программная управляемость виртуальных сред делает возможным построение облачных платформ с их требованиями к эластичности, самообслуживанию и автоматизации.
Гипервизоры первого типа, работающие непосредственно на оборудовании, обеспечивают производительность и изоляцию, необходимые для промышленной эксплуатации. Гипервизоры второго типа остаются удобным инструментом для разработки и обучения. Аппаратная поддержка виртуализации в современных процессорах существенно сократила накладные расходы и стала обязательным компонентом всех актуальных решений.
Ресурсная модель виртуальной машины включает виртуальные процессоры, оперативную память, дисковые образы и сетевые интерфейсы, а инструменты шаблонизации, создания снимков и клонирования ускоряют управление вычислительными средами. Вместе с тем виртуальные машины обладают ограничениями: значительные накладные расходы на гостевую операционную систему, длительное время запуска и большой объём артефактов.
Помимо аппаратной виртуализации, ядро операционной системы предоставляет собственные механизмы изоляции — пространства имён и группы управления ресурсами, — которые позволяют разграничивать процессы и ограничивать их потребление ресурсов на программном уровне. Эти механизмы обеспечивают менее строгую, но значительно более легковесную изоляцию по сравнению с гипервизором и составляют технологическую основу для подходов, рассматриваемых в последующих темах курса.