какие есть системы виртуализации
Как упростить разработку с помощью виртуализации
Человек, работая за компьютером, постоянно запускает разные программы. У программистов количество приложений, необходимых для работы, может исчисляться десятками. Более того, иногда приходится запускать программы, которые работают только в другой операционной системе, отличной от той, в которой работает программист.
В качестве примера можно привести проекты на Хекслете, где в рамках задания студенту нужно записать, что происходит в терминале. Эта задача становится трудновыполнимой, если ваша основная система — Windows. Программа, которая записывает терминал — asciinema, работает только в Linux. Как можно решить эту проблему? И почему нельзя просто взять и запустить программу из одной ОС в другой операционной системе?
Начнём с того, что программы, которые мы пишем, не взаимодействуют напрямую с железом. Например, когда мы вводим символы на клавиатуре, их сначала обрабатывает специальный драйвер, встроенный в операционную систему, и только потом они попадают в поле ввода и отображаются. В данном случае обработка настолько быстрая, что мы даже не задумываемся о ней. То же самое в отображении: мы запускаем множество разных процессов, просто двигая курсор мыши. Одна из главных задач операционных систем — предоставить возможность программам взаимодействовать с железом компьютера, и в разных операционных системах для этого используются разные функции.
Операционные системы — одни из самых сложных программ, если не самые сложные. Они разрабатывались разными людьми и в разное время. Логично, что подходы к работе с устройствами в них кардинально отличаются. Это одна из основных причин, почему нельзя просто скопировать программу в другую операционную систему и запустить её там. В качестве примера, не связанного с железом, можно сказать, что графические оболочки разных ОС тоже полностью отличаются. Например, в Linux нет понятий «Кнопка пуск» или «трей». В некоторых реализациях отсутствуют даже привычные нам всем окна.
Но всё же у разработчиков часто возникает потребность запуска программ, работающих только в одной ОС, и эта проблема имеет решение.
Самый очевидный способ — купить второй компьютер, но это дорогое удовольствие. Второй вариант — поставить Linux рядом со своей основной операционной системой. Такая установка может завершиться неудачей, так как операционные системы, как правило, не ожидают, что рядом с ними будет работать другая похожая программа. Но если всё получилось, во время старта компьютера вы сможете выбрать ОС для загрузки. Существует также и третий путь — виртуализация, о ней и поговорим.
Узнайте больше об операционных системах
У нас есть курс по операционным системам. Зарегистрированные пользователи могут пройти его бесплатно. Другие бесплатные курсы можно найти по ссылке.
Что такое виртуализация
Виртуализация позволяет запускать в текущей операционной системе программы, созданные для другой операционной системы. Это возможно благодаря виртуальной машине, которая работает внутри текущей операционной системы. На виртуальную машину устанавливается любая нужная в данный момент ОС. Стоит сказать, что виртуальных машин может быть много, каждая из них при этом выглядит как отдельный компьютер со своими характеристиками.
Виртуализация имеет очень богатую историю, а первая операционная система с её поддержкой появилась еще в 1968 году. Тогда же программисты поняли, что если можно запустить одну виртуальную машину, значит можно запустить и вторую, и третью. Возникла потребность управлять множеством таких машин, и появился первый гипервизор. По сути, это операционная система для управления виртуальными машинами.
Например, у нас есть две виртуальные машины, которые мы хотим использовать одновременно. Каждая из них должна иметь свой виртуальный жесткий диск и оперативную память. Логично, что кто-то должен следить за тем, чтобы одна из операционных систем случайно не начала записывать данные в области памяти, которые использует другая виртуальная машина. Этим как раз и занимается гипервизор: он изолирует и разделяет ресурсы виртуальных машин.
Операционная система (или компьютер), внутри которой запускается виртуальная машина, называется хост-системой (host), а ОС, работающую в виртуальном окружении, называют гостевой (guest).
Гипервизоры, по большому счёту, делятся на два типа: которые работают внутри операционной системы хоста, и для запуска которых хостовая ОС не нужна. Последние умеют работать прямо на голом железе. На настольных компьютерах наибольшее распространение получил первый тип.
В качестве примеров гипервизоров первого типа можно привести: VMware Workstation, QEMU и VirtualBox. А ко второму типу относится, например, автономный гипервизор VMware ESX.
Какие существуют виды виртуализации
Виртуализацию делят на три вида в зависимости от подхода к её реализации.
Программная виртуализация
Этот вид также подразделяется на несколько подвидов. В статье мы не будем подробно рассматривать каждый из них, так как в настоящее время программная виртуализация используется не так широко. Виртуальные машины на её основе значительно менее производительные по сравнению с другими видами виртуализации. Если интересно с чем это связано, подробнее можно почитать в Википедии.
Аппаратная виртуализация
Для её работы требуется поддержка со стороны процессора. Наибольшее распространение получили технологии Intel-VT и AMD-V, в настоящее время большинство процессоров для домашних компьютеров поддерживают одну из них. Аппаратная виртуализация не получила бы такого широкого распространения, если бы не преимущества, которые обеспечивает данный подход. Эти преимущества описаны ниже.
Первое преимущество: при аппаратной виртуализации виртуальные машины управляются гипервизором напрямую, в отличие от программной виртуализации, где, например, решение о выделении памяти для виртуальной машины сначала принимает операционная система хоста, и только после подтверждения гипервизор может предоставить ей ресурсы. Благодаря этому производительность гостевых ОС значительно повышается и достигает эффективности, сравнимой с реальным компьютером с такой же конфигурацией.
Второе преимущество: так как конфигурация виртуальной машины полностью эмулируется гипервизором, установщик операционной системы не нужно модифицировать. Выбираем нужные устройства в настройках, подключаем любой стандартный установочный образ нужной операционной системы и запускаем виртуальную машину. Более того, если у вас ещё сохранился процессор с 32-битной архитектурой, с помощью аппаратной виртуализации можно настроить виртуальную машину с 64-битным процессором и установить соответствующую ОС. Независимость от платформы хоста открывает поистине бесконечные возможности для экспериментов.
Контейнеризация или контейнерная виртуализация
Это виртуализация на уровне операционной системы. Если аппаратная виртуализация полностью эмулирует оборудование и позволяет запускать любые ОС, внутри контейнера можно запустить только аналогичную хосту операционную систему. Преимуществом этого подхода является скорость, с которой создаётся контейнер — секунды, тогда как для запуска виртуальной машины счёт времени идёт на минуты. Так происходит потому, что полноценной виртуальной машине нужно сначала инициализировать всё оборудование, запустить эмуляцию и только после этого начать загружать операционную систему. При контейнеризации ОС по факту уже работает. Остаётся только создать замкнутую среду — тот самый контейнер, в котором будет запущен ещё один экземпляр операционной системы.
Контейнер представляет собой всего лишь один процесс, внутри которого выполняется операционная система. Она существует в своём собственном мире, со своей сетью, своим диском, своей файловой системой и так далее. Эту виртуализацию применяют на уровне сервисов, составляющих части программного продукта. Наиболее известные проекты: OpenVZ, Docker, LXC.Так как Docker очень широко применятся в разработке, у нас есть подробный гайд о том, что это такое, как с ним работать и какие он даёт преимущества — Как и для чего использовать Docker.
Дополнительные возможности виртуализации
В начале 2000-x компания VMWare быстро захватила корпоративный рынок, выпустив гипервизор ESX Server и создав тем самым конкурентную среду. Начиная с этого момента технологии виртуализации стали стремительно развиваться. Огромное количество предприятий начали использовать виртуализацию для решения разных задач.
Резервное копирование
Виртуальная машина по сути представляет из себя набор файлов конфигурации и жесткого диска, а оперативную память тоже можно сохранить в виде файла. Учитывая эти особенности и возможность «заморозить» работу виртуальной машины, стало возможным делать бэкапы виртуальных серверов целиком. Потом, в случае поломки сервера, можно восстановить его из резервной копии. При этом не важно, будет он работать физически на этом же железе или новом, главное, чтобы был установлен нужный гипервизор. Помните, что аппаратная виртуализация даёт независимость от хост-платформы?
Возможность «заморозить» (поставить на паузу) работу виртуальной машины можно использовать для быстрого переключения между окружениями. Допустим, вы разрабатываете приложение для Windows. У вас открыто окно соответствующего редактора, запущены вспомогательные процессы и так далее. Но в тоже время вам нужно работать над другим проектом с совершенно другим окружением и в другой операционной системе.
Работая в виртуальной среде, можно поставить виртуальную машину на паузу и поработать над другим проектом. А когда нужно будет вернуться к первому, достаточно просто оживить виртуальную машину и продолжить работу с того места, на котором вы остановились. Так сохраняется контекст и экономится время, так как всё нужное, вплоть до интерфейса окон, уже настроено и правильно расположено на экране.
Быстрое создание среды для разработки
Современные веб-проекты требуют установки и настройки большого количества инструментария, библиотек и их зависимостей, серверов баз данных и так далее. Контейнеризация позволяет свести множество действий к запуску пары команд в терминале.
Виртуализация серверов
Так как на одном физическом сервере может располагаться множество виртуальных машин, на которых запущены другие серверы, расходы на их содержание значительно упали. В данный момент можно очень дешево арендовать ресурсы такого виртуального сервера VPS. На таких серверах, например, часто хостятся сайты.
Резюме
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Сравниваем лучшее программное обеспечение для виртуализации в 2020 году: Hyper-V, KVM, vSphere и XenServer
Перевод статьи подготовлен в преддверии старта курса «Администратор Linux. Виртуализация и кластеризация»
Виртуализация сыграла важную роль в формировании отрасли веб-хостинга и центров обработки данных в их нынешнем виде. Цель этой статьи — обсудить виртуализацию серверов и лучшее варианты программного обеспечения для этой технологии, наряду с перечислением их функционала в одном месте.
Что такое виртуализация серверов?
Создание виртуальной или изолированной формы IT-среды называется виртуализацией. Обычно серверы могут запускать только одно приложение или операционную систему в один момент времени, что приводит к неэффективному использованию ресурсов. Когда серверы виртуализированы, это означает, что на одном сервере могут работать несколько приложений и операционных систем одновременно. Это повышает как общую эффективность, так и экономическую целесообразность. Программное обеспечение для виртуализации серверов обычно называется гипервизором.
Лучшее программное обеспечение/инструменты и поставщики для виртуализации серверов — Hyper-V vs KVM vs vSphere vs XenServer
Citrix XenServer, Microsoft Hyper-V, Red Hat KVM и VMware vSphere являются крупнейшими игроками на рынке виртуализации серверов. Зачастую предприятия испытывают затруднения в принятии решения, какой гипервизор лучше всего подойдет их бизнесу.
Сравнение лучшего программного обеспечения для виртуализации серверов на основе функционала и требований к оборудованию облегчит IT-специалистам и конечным пользователям выбор наиболее подходящего для них гипервизора.
Примечание: Инструменты расположены в алфавитном порядке по их названиям.
1. Hyper-V
Запущенный в 2008 году Microsoft Hyper-V помогает в расширении или создании приватной облачной среды. Он способствует эффективному использованию оборудования, улучшает непрерывность бизнес-процессов, а также повышает эффективность разработки и тестирования.
Функционал Microsoft Hyper-V для Windows Server 2019:
Подробнее о виртуализации серверов с Microsoft вы можете прочитать в этом PDF.
2. KVM
KVM (Kernel-based Virtual Machine), входящая в состав Red Hat Virtualization Suite, представляет собой комплексное решение для инфраструктуры виртуализации. KVM превращает ядро Linux в гипервизор. Он был введен в основную ветку ядра Linux с версии ядра 2.6.20.
Функционал Red Hat KVM:
Для получения более подробной информации прочтите это руководство по функционалу KVM.
3. vSphere
vSphere, платформа серверной виртуализации от VMware, представляет собой набор продуктов, который включает в себя не только виртуализацию, но и уровни управления и интерфейсов.
Она предоставляет ряд ключевых компонентов, включая инфраструктурные сервисы (vCompute, vStorage и vNetwork), сервисы приложений, vCenter Server, vSphere Client и т. д.
Функционал VMware vSphere:
Для получения дополнительной информации о виртуализации серверов с помощью VMware прочтите этот PDF-файл.
4. XenServer
Основанный на Xen Project Hypervisor, XenServer является платформой виртуализации серверов с открытым исходным кодом для платформ без операционной системы. Он состоит из функций корпоративного уровня, которые помогают предприятиям легко справляться с рабочими нагрузками, комбинированными ОС и сетевыми конфигурациями.
XenServer обеспечивает улучшенную виртуализированную графику с NIVIDA и Intel и позволяет запускать несколько компьютерных операционных систем на одном оборудовании.
Функционал Citrix XenServer:
Сводка по vSphere, XenServer, Hyper-V и KVM
Помогите нам улучшить эту статью. Поделитесь своим мнением с нами в комментариях ниже!
Дисклеймер: последний раз эта статья была обновлена 11 января 2020 года информацией, доступной на веб-сайтах поставщиков и ресурсов в открытом доступе. Целью данной статьи является предоставление информации о гипервизорах разных поставщиков только в общих информационных целях. Поставщики могут время от времени менять характеристики своего продукта. Хотя мы прилагаем все усилия, чтобы информация была точной и актуальной, мы не можем гарантировать ее 100% точность или актуальность.
Автоматизация Для Самых Маленьких. Часть 1.1. Основы виртуализации
Предыдущая статья рассматривала архитектуру виртуализированной сети, underlay-overlay, путь пакета между VM и прочее.
Роман Горге вдохновился ею и решил написать обзорный выпуск о виртуализации вообще.
В данной статье мы затронем (или попытаемся затронуть) вопросы: а как собственно происходит виртуализация сетевых функций, как реализован backend основных продуктов, обеспечивающих запуск и управление VM, а также как работает виртуальный свитчинг (OVS и Linux bridge).
Тема виртуализации широка и глубока, объяснить все детали работы гипервизора невозможно (да и не нужно). Мы ограничимся минимальным набором знаний необходимым для понимания работы любого виртуализированного решения, не обязательно Telco.
Содержание
Введение и краткая история виртуализации
История современных технологий виртуализации берет свое начало в 1999 году, когда молодая компания VMware выпустила продукт под названием VMware Workstation. Это был продукт обеспечивающий виртуализацию desktop/client приложений. Виртуализация серверной части пришла несколько позднее в виде продукта ESX Server, который в дальнейшем эволюционировал в ESXi (i означает integrated) — это тот самый продукт, который используется повсеместно как в IT так и в Telco как гипервизор серверных приложений.
На самом деле на сегодняшний момент вся функциональность KVM доступна в QEMU, но это не принципиально, так как бо́льшая часть пользователей виртуализации на Linux не использует напрямую KVM/QEMU, а обращается к ним как минимум через один уровень абстракции, но об этом позже.
Обсуждение что лучше, а что хуже выходит за рамки данной статьи.
Производители железа также должны были сделать свою часть работы, дабы обеспечить приемлемую производительность.
Пожалуй, наиболее важной и самой широко используемой является технология Intel VT (Virtualization Technology) — набор расширений, разработанных Intel для своих x86 процессоров, которые используются для эффективной работы гипервизора (а в некоторых случаях необходимы, так, например, KVM не заработает без включенного VT-x и без него гипервизор вынужден заниматься чисто софтверной эмуляцией, без аппаратного ускорения).
Наиболее известны два из этих расширений — VT-x и VT-d. Первое важно для улучшения производительности CPU при виртуализации, так как обеспечивает аппаратную поддержку некоторых ее функций (с VT-x 99.9% Guest OS кода выполняется прямо на физическом процессоре, делая выходы для эмуляции только в самых необходимых случаях), второе для подключения физических устройств напрямую в виртуальную машину (для проброса виртуальных функций (VF) SRIOV, например, VT-d должен быть включен).
Следующей важной концепцией является отличие полной виртуализации (full virtualization) от пара-виртуализации (para-virtualization).
Полная виртуализация — это хорошо, это позволяет запускать какую угодно операционную систему на каком угодно процессоре, однако, это крайне неэффективно и абсолютно не подходит для высоконагруженных систем.
Пара-виртуализация, если коротко, это когда Guest OS понимает что она запущена в виртуальной среде и кооперируется с гипервизором для достижения большей эффективности. То есть появляется guest-hypervisor интерфейс.
Подавляющее большинство используемых операционных систем сегодня имеют поддержку пара-виртуализации — в Linux kernel это появилось начиная с ядра версии 2.6.20.
Если вы хоть раз писали вопрос в RFP или отвечали на вопрос в RFP «Поддерживается ли в вашем продукте virtio?» Это как раз было о поддержке front-end virtio драйвера.
Типы виртуальных ресурсов — compute, storage, network
Из чего же состоит виртуальная машина?
Выделяют три основных вида виртуальных ресурсов:
Compute
Теоретически QEMU способен эмулировать любой тип процессора и соотвествующие ему флаги и функциональность, на практике используют либо host-model и точечно выключают флаги перед передачей в Guest OS либо берут named-model и точечно включают\выключают флаги.
По умолчанию QEMU будет эмулировать процессор, который будет распознан Guest OS как QEMU Virtual CPU. Это не самый оптимальный тип процессора, особенно если приложение, работающее в виртуальной машине, использует CPU-флаги для своей работы. Подробнее о разных моделях CPU в QEMU.
QEMU/KVM также позволяет контролировать топологию процессора, количество тредов, размер кэша, привязывать vCPU к физическому ядру и много чего еще.
Нужно ли это для виртуальной машины или нет, зависит от типа приложения, работающего в Guest OS. Например, известный факт, что для приложений, выполняющих обработку пакетов с высоким PPS, важно делать CPU pinning, то есть не позволять передавать физический процессор другим виртуальным машинам.
Memory
Далее на очереди оперативная память — RAM. С точки зрения Host OS запущенная с помощью QEMU/KVM виртуальная машина ничем не отличается от любого другого процесса, работающего в user-space операционной системы. Соотвественно и процесс выделения памяти виртуальной машине выполняется теми же вызовами в kernel Host OS, как если бы вы запустили, например, Chrome браузер.
Перед тем как продолжить повествование об оперативной памяти в виртуальных машинах, необходимо сделать отступление и объяснить термин NUMA — Non-Uniform Memory Access.
Архитектура современных физических серверов предполагает наличие двух или более процессоров (CPU) и ассоциированной с ней оперативной памятью (RAM). Такая связка процессор + память называется узел или нода (node). Связь между различными NUMA nodes осуществляется посредством специальной шины — QPI (QuickPath Interconnect)
Выделяют локальную NUMA node — когда процесс, запущенный в операционной системе, использует процессор и оперативную память, находящуюся в одной NUMA node, и удаленную NUMA node — когда процесс, запущенный в операционной системе, использует процессор и оперативную память, находящиеся в разных NUMA nodes, то есть для взаимодействия процессора и памяти требуется передача данных через QPI шину.
С точки зрения виртуальной машины память ей уже выделена на момент ее запуска, однако в реальности это не так, и kernel Host OS выделяет процессу QEMU/KVM новые участки памяти по мере того как приложение в Guest OS запрашивает дополнительную память (хотя тут тоже может быть исключение, если прямо указать QEMU/KVM выделить всю память виртуальной машине непосредственно при запуске).
Память выделяется не байт за байтом, а определенным размером — page. Размер page конфигурируем и теоретически может быть любым, но на практике используется размер 4kB (по умолчанию), 2MB и 1GB. Два последних размера называются HugePages и часто используются для выделения памяти для memory intensive виртуальных машин. Причина использования HugePages в процессе поиска соответствия между виртуальным адресом page и физической памятью в Translation Lookaside Buffer (TLB), который в свою очередь ограничен и хранит информацию только о последних использованных pages. Если информации о нужной page в TLB нет, происходит процесс, называемый TLB miss, и требуется задействовать процессор Host OS для поиска ячейки физической памяти, соответствующей нужной page.
Данный процесс неэффективен и медлителен, поэтому и используется меньшее количество pages бо́льшего размера.
QEMU/KVM также позволяет эмулировать различные NUMA-топологии для Guest OS, брать память для виртуальной машины только из определенной NUMA node Host OS и так далее. Наиболее распространенная практика — брать память для виртуальной машины из NUMA node локальной по отношению к процессорам, выделенным для виртуальной машины. Причина — желание избежать лишней нагрузки на QPI шину, соединяющую CPU sockets физического сервера (само собой, это логично если в вашем сервере 2 и более sockets).
Storage
Виртуальная машина нуждается в persistent storage, однако, как это сделать, если виртуальная машина «живет» в оперативной памяти Host OS? Если вкратце, то любое обращение Guest OS к контроллеру виртуального диска перехватывается QEMU/KVM и трансформируется в запись на физический диск Host OS. Этот метод неэффективен, и поэтому здесь так же как и для сетевых устройств используется virtio-драйвер вместо полной эмуляции IDE или iSCSI-устройства. Подробнее об этом можно почитать здесь. Таким образом виртуальная машина обращается к своему виртуальному диску через virtio-драйвер, а далее QEMU/KVM делает так, чтобы переданная информация записалась на физический диск. Важно понимать, что в Host OS дисковый backend может быть реализован в виде CEPH, NFS или iSCSI-полки.
Наиболее простым способом эмулировать persistent storage является использование файла в какой-либо директории Host OS как дискового пространства виртуальной машины. QEMU/KVM поддерживает множество различных форматов такого рода файлов — raw, vdi, vmdk и прочие. Однако наибольшее распространение получил формат qcow2 (QEMU copy-on-write version 2). В общем случае, qcow2 представляет собой определенным образом структурированный файл без какой-либо операционной системы. Большое количество виртуальных машин распространяется именно в виде qcow2-образов (images) и являются копией системного диска виртуальной машины, упакованной в qcow2-формат. Это имеет ряд преимуществ — qcow2-кодирование занимает гораздо меньше места, чем raw копия диска байт в байт, QEMU/KVM умеет изменять размер qcow2-файла (resizing), а значит имеется возможность изменить размер системного диска виртуальной машины, также поддерживается AES шифрование qcow2 (это имеет смысл, так как образ виртуальной машины может содержать интеллектуальную собственность).
Далее, когда происходит запуск виртуальной машины, QEMU/KVM использует qcow2-файл как системный диск (процесс загрузки виртуальной машины я опускаю здесь, хотя это тоже является интересной задачей), а виртуальная машина имеет возможность считать/записать данные в qcow2-файл через virtio-драйвер. Таким образом и работает процесс снятия образов виртуальных машин, поскольку в любой момент времени qcow2-файл содержит полную копию системного диска виртуальной машины, и образ может быть использован для резервного копирования, переноса на другой хост и прочее.
В общем случае этот qcow2-файл будет определяться в Guest OS как /dev/vda-устройство, и Guest OS произведет разбиение дискового пространства на партиции и установку файловой системы. Аналогично, следующие qcow2-файлы, подключенные QEMU/KVM как /dev/vdX устройства, могут быть использованы как block storage в виртуальной машине для хранения информации (именно так и работает компонент Openstack Cinder).
Network
Последним в нашем списке виртуальных ресурсов идут сетевые карты и устройства ввода/вывода. Виртуальная машина, как и физический хост, нуждается в PCI/PCIe-шине для подключения устройств ввода/вывода. QEMU/KVM способен эмулировать разные типы чипсетов — q35 или i440fx (первый поддерживает — PCIe, второй — legacy PCI ), а также различные PCI-топологии, например, создавать отдельные PCI-шины (PCI expander bus) для NUMA nodes Guest OS.
После создания PCI/PCIe шины необходимо подключить к ней устройство ввода/вывода. В общем случае это может быть что угодно — от сетевой карты до физического GPU. И, конечно же, сетевая карта, как полностью виртуализированная (полностью виртуализированный интерфейс e1000, например), так и пара-виртуализированная (virtio, например) или физическая NIC. Последняя опция используется для data-plane виртуальных машин, где требуется получить line-rate скорости передачи пакетов — маршрутизаторов, файрволов и тд.
Здесь существует два основных подхода — PCI passthrough и SR-IOV. Основное отличие между ними — для PCI-PT используется драйвер только внутри Guest OS, а для SRIOV используется драйвер Host OS (для создания VF — Virtual Functions) и драйвер Guest OS для управления SR-IOV VF. Более подробно об PCI-PT и SRIOV отлично написал Juniper.
Для уточнения стоит отметить что, PCI passthrough и SR-IOV это дополняющие друг друга технологии. SR-IOV это нарезка физической функции на виртуальные функции. Это выполняется на уровне Host OS. При этом Host OS видит виртуальные функции как еще одно PCI/PCIe устройство. Что он дальше с ними делает — не важно.
А PCI-PT это механизм проброса любого Host OS PCI устройства в Guest OS, в том числе виртуальной функции, созданной SR-IOV устройством
Таким образом мы рассмотрели основные виды виртуальных ресурсов и следующим шагом необходимо понять как виртуальная машина общается с внешним миром через сеть.
Виртуальная коммутация
Архитектура OVS на первый взгляд выглядит довольно страшно, но это только на первый взгляд.
Каким же образом сетевое устройство виртуальной машины оказывается в OVS?
Для решения данной задачи нам необходимо каким-то образом связать между собой виртуальный интерфейс, находящийся в user-space операционной системы с datapath OVS, находящимся в kernel.
В операционной системе Linux передача пакетов между kernel и user-space-процессами осуществляется посредством двух специальных интерфейсов. Оба интерфейса использует запись/чтение пакета в/из специальный файл для передачи пакетов из user-space-процесса в kernel и обратно — file descriptor (FD) (это одна из причин низкой производительности виртуальной коммутации, если datapath OVS находится в kernel — каждый пакет требуется записать/прочесть через FD)
Именно поэтому при запущенной виртуальной машине в Host OS можно увидеть созданные TAP-интерфейсы командой ip link или ifconfig — это «ответная» часть virtio, которая «видна» в kernel Host OS. Также стоит обратить внимание, что TAP-интерфейс имеет тот же MAC-адрес что и virtio-интерфейс в виртуальной машине.
TAP-интерфейс может быть добавлен в OVS с помощью команд ovs-vsctl — тогда любой пакет, скоммутированный OVS в TAP-интерфейс, будет передан в виртуальную машину через file descriptor.
Реальный порядок действий при создании виртуальной машины может быть разным, т.е. сначала можно создать OVS bridge, потом указать виртуальной машине создать интерфейс, соединенный с этим OVS, а можно и наоборот.
Теперь, если нам необходимо получить возможность передачи пакетов между двумя и более виртуальными машинами, которые запущены на одном гипервизоре, нам потребуется лишь создать OVS bridge и добавить в него TAP-интерфейсы с помощью команд ovs-vsctl. Какие именно команды для этого нужны легко гуглится.
На гипервизоре может быть несколько OVS bridges, например, так работает Openstack Neutron, или же виртуальные машины могут находиться в разных namespace для реализации multi-tenancy.
А если виртуальные машины находятся в разных OVS bridges?
Для решения данной задачи существует другой инструмент — veth pair. Veth pair может быть представлен как пара сетевых интерфейсов, соединенных кабелем — все то, что «влетает» в один интерфейс, «вылетает» из другого. Veth pair используется для соединения между собой нескольких OVS bridges или Linux bridges. Другой важный момент что части veth pair могут находиться в разных namespace Linux OS, то есть veth pair может быть также использован для связи namespace между собой на сетевом уровне.
Инструменты виртуализации — libvirt, virsh и прочее
В предыдущих главах мы рассматривали теоретические основы виртуализации, в этой главе мы поговорим об инструментах, которые доступны пользователю непосредственно для запуска и изменения виртуальных машин на KVM-гипервизоре.
Остановимся на трех основных компонентах, которые покрывают 90 процентов всевозможных операций с виртуальными машинами:
Конечно, существует множество других утилит и CLI-команд, которые позволяют управлять гипервизором, например, можно напрямую пользоваться командами qemu_system_x86_64 или графическим интерфейсом virt manager, но это скорее исключение. К тому же существующие сегодня Cloud-платформы, Openstack, например, используют как раз libvirt.
libvirt
libvirt — это масштабный open-source проект, который занимается разработкой набора инструментов и драйверов для управления гипервизорами. Он поддерживает не только QEMU/KVM, но и ESXi, LXC и много чего еще.
Основная причина его популярности — структурированный и понятный интерфейс взаимодействия через набор XML-файлов плюс возможность автоматизации через API. Стоит оговориться что libvirt не описывает все возможные функции гипервизора, он лишь предоставляет удобный интерфейс использования полезных, с точки зрения участников проекта, функции гипервизора.
И да, libvirt это де-факто стандарт в мире виртуализации сегодня. Только взгляните на список приложений, которые используют libvirt.
Хорошая новость про libvirt — все нужные пакеты уже предустановлены во всех наиболее часто используемых Host OS — Ubuntu, CentOS и RHEL, поэтому, скорее всего, собирать руками нужные пакеты и компилировать libvirt вам не придется. В худшем случае придется воспользоваться соответствующим пакетным инсталлятором (apt, yum и им подобные).
При первоначальной установке и запуске libvirt по умолчанию создает Linux bridge virbr0 и его минимальную конфигурацию.
Именно поэтому при установке Ubuntu Server, например, вы увидите в выводе команды ifconfig Linux bridge virbr0 — это результат запуска демона libvirtd
Этот Linux bridge не будет подключен ни к одному физическому интерфейсу, однако, может быть использован для связи виртуальных машин внутри одного гипервизора. Libvirt безусловно может быть использован вместе с OVS, однако, для этого пользователь должен самостоятельно создать OVS bridges с помощью соответствующих OVS-команд.
Любой виртуальный ресурс, необходимый для создания виртуальной машины (compute, network, storage) представлен в виде объекта в libvirt. За процесс описания и создания этих объектов отвечает набор различных XML-файлов.
Детально описывать процесс создания виртуальных сетей и виртуальных хранилищ не имеет особого смысла, так как эта прикладная задача хорошо описана в документации libvirt:
Сама виртуальная машина со всеми подключенными PCI-устройствами в терминологии libvirt называется domain. Это тоже объект внутри libvirt, который описывается отдельным XML-файлом.
Этот XML-файл и является, строго говоря, виртуальной машиной со всеми виртуальными ресурсами — оперативная память, процессор, сетевые устройства, диски и прочее. Часто данный XML-файл называют libvirt XML или dump XML.
Вряд ли найдется человек, который понимает все параметры libvirt XML, однако, это и не требуется, когда есть документация.
В общем случае, libvirt XML для Ubuntu Desktop Guest OS будет довольно прост — 40-50 строчек. Поскольку вся оптимизация производительности описывается также в libvirt XML (NUMA-топология, CPU-топологии, CPU pinning и прочее), для сетевых функций libvirt XML может быть очень сложен и содержать несколько сот строк. Любой производитель сетевых устройств, который поставляет свое ПО в виде виртуальных машин, имеет рекомендованные примеры libvirt XML.
virsh CLI
Утилита virsh — «родная» командная строка для управления libvirt. Основное ее предназначение — это управление объектами libvirt, описанными в виде XML-файлов. Типичными примерами являются операции start, stop, define, destroy и так далее. То есть жизненный цикл объектов — life-cycle management.
Описание всех команд и флагов virsh также доступно в документации libvirt.
virt-install
Еще одна утилита, которая используется для взаимодействия с libvirt. Одно из основных преимуществ — можно не разбираться с XML-форматом, а обойтись лишь флагами, доступными в virsh-install. Второй важный момент — море примеров и информации в Сети.
Таким образом какой бы утилитой вы ни пользовались, управлять гипервизором в конечном счете будет именно libvirt, поэтому важно понимать архитектуру и принципы его работы.
Заключение
В данной статье мы рассмотрели минимальный набор теоретических знаний, который необходим для работы с виртуальными машинами. Я намеренно не приводил практических примеров и выводов команд, поскольку таких примеров можно найти сколько угодно в Сети, и я не ставил перед собой задачу написать «step-by-step guide». Если вас заинтересовала какая-то конкретная тема или технология, оставляйте свои комментарии и пишите вопросы.