что не относится к виртуализации
Анализ современных технологий виртуализации
В настоящее время все большую популярность набирают технологии виртуализации. И это не случайно – вычислительные мощности компьютеров растут. В результате развития технологий, появляются шести-, восьми-, шестнадцатиядерные процессоры (и это еще не предел). Растет пропускная способность интерфейсов компьютеров, а также емкость и отзывчивость систем хранения данных. В результате возникает такая ситуация, что имея такие мощности на одном физическом сервере, можно перенести в виртуальную среду все серверы, функционирующие в организации (на предприятии). Это возможно сделать с помощью современной технологии виртуализации.
Технологии виртуализации в настоящее время становятся одним из ключевых компонентов современной ИТ-инфраструктуры крупных предприятий (организаций). Сейчас уже сложно представить построение нового серверного узла компании без использования технологии виртуализации. Определяющими факторами такой популярности, несмотря на некоторые недостатки, можно назвать экономию денег и времени, а также высокий уровень безопасности и обеспечение непрерывности бизнес-процессов.
В данной статье приведен анализ современной технологии виртуализации, ее преимуществ и недостатков. Также рассмотрены современные системы виртуализации и подходы к созданию виртуальных сред.
Современную визуализацию можно понимать по-разному. Например, виртуализировать означает, что можно взять нечто одной формы и сделать так, чтобы оно казалось похожим на другую форму. Виртуализация компьютера означает, что можно заставить компьютер казаться сразу несколькими компьютерами одновременно или совершенно другим компьютером.
Виртуализацией также называется ситуация, когда несколько компьютеров представляются как один отдельный компьютер. Обычно это называют серверным кластером или grid computing.
Виртуализация тема не новая, фактически ей уже более четырех десятилетий. IBM признала важность виртуализации еще в 1960-х вместе с развитием компьютеров класса «мэйнфрэйм». Например, System/360™ Model 67 виртуализировала все интерфейсы оборудования через программу Virtual Machine Monitor (VMM). На заре вычислительной эры операционную систему называли супервизор (supervisor). Когда стало возможным запускать одну операционную систему на другой операционной системе, появился термин гипервизор (hypervisor) (был введен в 1970-х).
VMM запускается непосредственно на основном оборудовании, позволяющем создавать множество виртуальных машин (VM). При этом каждая виртуальная машина может обладать своей собственной операционной системой.
Другое использование виртуализации заключается в симуляции процессора. Это, так называемая, P-code (или pseudo-code) машина. P-code – это машинный язык, который выполняется на виртуальной машине, а не на реальном оборудовании. P-code стал известен в начале 1970-х. С помощью него происходило компилирование программы на Pascal в P-code и потом выполнение ее на P-code виртуальной машине.
Новый аспект виртуализации был назван командной виртуализацией или бинарной виртуализацией. В этом случае виртуальные команды переводятся (транслируются) на физические команды основного оборудования. Обычно это происходит динамически. Поскольку код исполняемый, переводится в сегмент кода. Если происходит разветвление, то новый сегмент кода забирается и переводится.
Когда производится виртуализация, существует несколько способов ее осуществления, с помощью которых достигаются одинаковые результаты через разные уровни абстракции. У каждого способа есть свои достоинства и недостатки, но главное что каждый из них находит свое место в зависимости от области применения.
Можно считать, что самая сложная виртуализация обеспечивается эмуляцией аппаратных средств. В этом методе VM аппаратных средств создается на хост-системе, чтобы эмулировать интересующее оборудование.
Другое интересное использование эмуляции – это эмуляция оборудования, которая заключается в совместном развитии встроенного программного обеспечения и аппаратных средств. В этом методе VM аппаратных средств создается на хост-системе, чтобы эмулировать интересующее оборудование.
Эмуляция оборудования использует VM, чтобы моделировать необходимые аппаратные средства.
Вместо того чтобы дожидаться, когда реальные аппаратные средства будут в наличии, разработчики встроенного программного обеспечения могут использовать виртуальное оборудование для разработки и тестирования программного обеспечения.
Главная проблема при эмуляции аппаратных средств состоит существенном замедлении выполнения программ в такой среде. Поскольку каждая команда должна моделироваться на основных аппаратных средствах, при этом замедление в 100 раз при эмуляции является обычным делом. Однако эмуляция аппаратных средств имеет существенные преимущества. Например, используя эмуляцию аппаратных средств, можно управлять неизмененной операционной системой, предназначенной для PowerPC® на системе с ARM процессором. также можно управлять многочисленными виртуальными машинами, каждая из которых будет моделировать другой процессор.
Полная (аппаратная) виртуализация, или «родная» виртуализация, является другим способом виртуализации. Эта модель использует менеджер виртуальных машин (гипервизор), который осуществляет связь между гостевой операционной системой и аппаратными средствами системы.
Полная виртуализация использует гипервизор, чтобы разделять основные аппаратные средства.
Взаимодействие между гостевой операционной системой (ОС) и оборудованием осуществляется посредством гипервизора. Внутри гипервизора должна быть установлена и настроена определенная защита, потому, что основные аппаратные средства не принадлежат ОС, а разделяются гипервизором. При построении крупных корпоративных систем, как правило, используется именно аппаратная виртуализация. При этом крупные вендоры такие как VMware, IBM и Microsoft разрабатывают свои платформы виртуализации на базе технологий аппаратной виртуализации Intel VT (VT-x), AMD-V.
Паравиртуализация — это другой популярный способ, который имеет некоторые сходства с полной виртуализацией. Этот метод использует гипервизор для разделения доступа к основным аппаратным средствам, но объединяет код, касающийся виртуализации, в непосредственно операционную систему. Этот подход устраняет потребность в любой перекомпиляции или перехватывании, потому что сами операционные системы кооперируются в процессе виртуализации.
Паравиртуализация разделяет процесс с гостевой операционной системой.
Паравиртуализация требует, чтобы гостевая ОС была изменена для гипервизора, и это является недостатком метода. Однако, паравиртуализация предлагает высокую производительность, почти как у реальной системы. При этом, как и при полной виртуализации, одновременно могут поддерживаться различные операционные системы. Но определенным недостатком паравиртуализации можно считать ограниченное количество поддерживаемых ОС. Поскольку есть необходимость вносить изменения в код ядра ОС, что не всегда представляется возможным в силу закрытости некоторых ОС.
Из известных гипервизоров паравиртуализацию наравне с аппаратной виртуализацией использует Xen и его ответвления (Citrix XenServer, XCP).
Виртуализация уровня операционной системы. Эта техника виртуализирует серверы непосредственно над операционной системой. Этот метод поддерживает единственную операционную систему и, в самом общем случае, просто изолирует независимые виртуальные серверы (контейнеры) друг от друга. Для разделения ресурсов одного сервера между контейнерами, данная виртуализация требует внесения изменений в ядро операционной системы (например, как в случае с OpenVZ), но при этом преимуществом является родная производительность, без «накладных расходов» на виртуализацию устройств.
Виртуализация уровня операционной системы изолирует виртуальные серверы.
Этот подход использован в Solaris Containers, FreeBSD jail и Virtuozzo/OpenVZ в ОС Linux и *BSD, а также в Linux Containers (LXC), про которые уже немало написано на Хабре.
Теперь постараемся ответить на вопрос: «Зачем нужна виртуализация?». В настоящее время существует множество причин использования виртуализации. Возможно, что самой важной причиной является, так называемая, серверная консолидация. Проще говоря, возможность виртуализировать множество систем на отдельном сервере. Это дает возможность предприятию (организации) сэкономить на мощности, месте, охлаждении и администрировании из-за наличия меньшего количества серверов. При этом немаловажным фактором является абстрагирование от оборудования. Например, сервера иногда выходят из строя. При этом есть возможность перераспределить нагрузку на оборудование. Отсутствие привязки, к какому либо «железу» существенно облегчает жизнь IT-отделу и снижает риск простоя предприятия.
Другая возможность использования виртуализации заключается в том, что бывает изначально трудно определить нагрузку на сервер. При этом процедура виртуализации поддерживает так называемую живую миграцию (live migration). Живая миграция позволяет ОС, которая перемещается на новый сервер, и ее приложениям сбалансировать нагрузку на доступном оборудовании.
Используя возможности современных ПК можно легко развернуть любой виртуальный сервер даже на домашнем компьютере, а затем легко перенести его на другое оборудование. Виртуализация также важна для разработчиков. Например, виртуализация позволяет управлять несколькими операционными системами, и если одна из них терпит крах из-за ошибки, то гипервизор и другие операционные системы продолжают работать. Это позволяет сделать отладку ядра подобной отладке пользовательских приложений.
В целом можно выделить следующие преимущества использования виртуализации:
1. Сокращение затрат на приобретение и поддержку оборудования. В современных условиях практически в каждой компании всегда найдется один или два сервера имеющие несколько ролей, например, почтовый сервер, файловый сервер, сервер базы данных и т.д. Безусловно, на одной физической машине можно поднимать по несколько программных комплексов (серверов), выполняющих различные задачи. Но очень часто бывают ситуации, когда установка нового ПО требует независимой серверной единицы. В таком случае как раз и придет на выручку виртуальная машина с требуемой ОС. Сюда же можно отнести случаи, когда в сети необходимо иметь несколько независимых друг от друга виртуальных серверов со своим набором служб и своими характеристиками, которые должны существовать как независимые узлы сети. Типичный пример – это услуги VPS-хостинга.
2. Сокращение серверного парка. Преимущество виртуализации состоит в том, что можно значительно сократить количество физических ЭВМ. В результате меньше времени и денег тратится на поиск, закупку и замену оборудования. Наряду с этим сокращаются площади, выделяемые под содержание серверной базы.
3. Сокращение штата IT-сотрудников. На обслуживание меньшего количества физических ЭВМ требуется меньше людей. С точки зрения руководства компании, сокращение штата — это сокращение серьезной статьи расходов предприятия.
4. Простота в обслуживании. Добавить жесткий диск или расширить существующий, увеличить количество оперативной памяти, все это занимает определенное время в случае с физическим сервером. Отключение, отсоединение из стойки, подключение нового оборудования, включение – в случае использования виртуализации все эти действия опускаются, и операция сводится к нескольким щелчкам мыши или командам администратора.
5. Клонирование и резервирование. Еще одним плюсом виртуализации является простота клонирования виртуальных машин. Например, компания открывает новый офис. При этом серверная инфраструктура центрального офиса стандартизирована и представляет собой несколько серверов с одинаковыми настройками. Развертывание такой инфраструктуры сводится к простому копированию образов на сервер нового офиса, конфигурировании сетевого оборудования и изменению настроек в прикладном ПО.
Вы еще не используете виртуализацию?
Сейчас уже сложно представить себе ИТ-отрасль без виртуализации, развитие информационных систем организаций тесно связано с применением технологий виртуализации. Причем данные технологии позволяют значительно сократить расходы, связанные с приобретением и обслуживанием серверных систем, сократить время на восстановление информации или развертывания аналогичных систем в новом оборудовании. Если вы до сих пор еще не используете преимущества виртуализации, то стоит об этом задуматься уже сейчас.
Наша компания широко использует преимущества контейнерной виртуализации практически во всех проектах. И если того требует ситуация, используем также полную виртуализацию. Мы рекомендуем всем предприятиям и организациям, имеющим в своем парке несколько серверов перейти к внедрению описанных в данной статье технологий.
Автоматизация Для Самых Маленьких. Часть 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». Если вас заинтересовала какая-то конкретная тема или технология, оставляйте свои комментарии и пишите вопросы.