Предыдущая статья Я рассмотрел архитектуру виртуализированной сети, подложку-оверлей, путь передачи пакетов между ВМ и т.д. Римское ущелье Меня это вдохновило, и я решил написать обзор о виртуализации в целом.
В этой статье мы затронем (или попытаемся затронуть) следующие вопросы: как на самом деле происходит виртуализация сетевых функций, как реализован бэкенд основных продуктов, обеспечивающих запуск и управление ВМ, а также как виртуальная коммутация( Мост OVS и Linux) работает. Тема виртуализации широка и глубока; невозможно (да и не нужно) объяснить все детали работы гипервизора.
Мы ограничимся минимальным набором знаний, необходимым для понимания работы любого виртуализированного решения, не обязательно телекоммуникационного.
Содержание
- Введение и краткая история виртуализации
- Типы виртуальных ресурсов — вычислительные ресурсы, хранилище, сеть.
- Виртуальное переключение
- Инструменты виртуализации — libvirt, virsh и др.
- Заключение
Введение и краткая история виртуализации История современных технологий виртуализации берет свое начало в 1999 году, когда молодая компания VMware выпустила продукт под названием VMware Workstation. Это был продукт, обеспечивающий виртуализацию настольных/клиентских приложений.
Виртуализация на стороне сервера появилась чуть позже в виде продукта ESX Server, который позже развился в ESXi (i означает «интегрированный») — это тот же продукт, который повсеместно используется как в ИТ, так и в телекоммуникациях в качестве гипервизора для серверных приложений.
Что касается Opensource, два крупных проекта принесли виртуализацию в Linux:
- KVM (Kernel-based Virtual Machine) — модуль ядра Linux, позволяющий ядру работать в качестве гипервизора (создает необходимую инфраструктуру для запуска и управления виртуальной машиной).
Он был добавлен в ядро версии 2.6.20 в 2007 году.
- QEMU (Quick Emulator) — напрямую эмулирует оборудование виртуальной машины (ЦП, Диск, ОЗУ, все, включая порт USB) и используется в сочетании с KVM для достижения практически «родной» производительности.
Фактически на данный момент весь функционал KVM доступен в QEMU, но это не важно, так как большинство пользователей виртуализации в Linux не используют KVM/QEMU напрямую, а получают к ним доступ хотя бы через один уровень абстракции, а более об этом позже.Сегодня VMware ESXi и Linux QEMU/KVM являются двумя основными гипервизорами, доминирующими на рынке.
Они также являются представителями двух разных типов гипервизоров:
- Тип 1 — гипервизор работает непосредственно на оборудовании (голое железо).
Это VMware ESXi, Linux KVM, Hyper-V.
- Тип 2 – гипервизор работает внутри ОС хоста (операционной системы).
Это VMware Workstation или Oracle VirtualBox.
Производителям оборудования также пришлось внести свой вклад в обеспечение приемлемой производительности.
Пожалуй, самым важным и наиболее широко используемым является Intel VT (Технология виртуализации) — набор расширений, разработанных Intel для своих процессоров x86, которые используются для эффективной работы гипервизора (а в некоторых случаях необходимых, например, KVM не будет работать без VT с включенным -x и без него гипервизор вынужден заниматься чисто программной эмуляцией, без аппаратного ускорения).
Два наиболее известных из этих расширений — VT-x и VT-d. Первый важен для повышения производительности процессора при виртуализации, так как обеспечивает аппаратную поддержку некоторых его функций (с VT-x 99,9% кода гостевой ОС выполняется непосредственно на физическом процессоре, делая эмуляционные выходы только в самых необходимых случаях), второй для подключения физических устройств напрямую к виртуальной машине (для проброса виртуальных функций (ВФ) SRIOV, например, VT-d должен быть включен ).
Следующее важное понятие — это разница между полной виртуализацией и паравиртуализацией.
Полная виртуализация — это хорошо, она позволяет запускать любую операционную систему на любом процессоре, однако она крайне неэффективна и совершенно не подходит для высоконагруженных систем.
Короче говоря, паравиртуализация — это когда гостевая ОС понимает, что она работает в виртуальной среде, и взаимодействует с гипервизором для достижения большей эффективности.
То есть появляется интерфейс гостя-гипервизора.
Подавляющее большинство используемых сегодня операционных систем имеют поддержку паравиртуализации — она появилась в ядре Linux начиная с версии ядра 2.6.20. Для работы виртуальной машины требуется не только виртуальный процессор (vCPU) и виртуальная память (RAM), но и эмуляция устройств PCI. То есть по сути необходим набор драйверов для управления виртуальными сетевыми интерфейсами, дисками и т.д. В гипервизоре KVM Linux эта проблема была решена введением виртио — основа для разработки и использования виртуализированных устройств ввода-вывода.
Virtio — это дополнительный уровень абстракции, который позволяет эмулировать различные устройства ввода-вывода в паравиртуализированном гипервизоре, предоставляя единый стандартизированный интерфейс для виртуальной машины.
Это позволяет повторно использовать код драйвера virtio для различных по своей природе устройств.
Виртио состоит из:
- Фронтальный драйвер — что находится в виртуальной машине
- Back-end драйвер — что есть в гипервизоре
- Транспортный драйвер — что связывает бэкенд и фронтенд
То есть существует соединение гость-гипервизор, когда гостевая ОС «знает», что она работает в виртуальной среде.
Если вы когда-либо писали вопрос в запросе предложений или отвечали на вопрос в запросе предложений: «Поддерживает ли ваш продукт virtioЭ» Речь шла только о поддержке фронтенд-драйвера Virtio.Типы виртуальных ресурсов — вычислительные ресурсы, хранилище, сеть.
Из чего состоит виртуальная машина? Существует три основных типа виртуальных ресурсов:
- компьютер — процессор и оперативная память
- хранилище — системный диск виртуальной машины и блочное хранилище.
- сеть - сетевые карты и устройства ввода/вывода
Вычислить
Процессор
Теоретически QEMU способен эмулировать процессор любого типа и соответствующие ему флаги и функциональные возможности; на практике они используют либо хост-модель и выборочно отключают флаги перед передачей их в гостевую ОС, либо берут именованную модель и специально включают/отключают флаги.По умолчанию QEMU эмулирует процессор, который будет распознан гостевой ОС как виртуальный процессор QEMU. Это не самый оптимальный тип процессора, особенно если приложение, работающее на виртуальной машине, использует для своей работы флаги ЦП.
Узнайте больше о различных моделях процессоров в QEMU. .
QEMU/KVM также позволяет управлять топологией процессора, количеством потоков, размером кэша, связывать виртуальный ЦП с физическим ядром и многое другое.
Необходимо ли это для виртуальной машины или нет, зависит от типа приложения, работающего в гостевой ОС.
Например, известен факт, что для приложений, обрабатывающих пакеты с высоким PPS, важно сделать Закрепление процессора , то есть не допускать переноса физического процессора на другие виртуальные машины.
Память
На очереди оперативная память.С точки зрения хост-ОС виртуальная машина, запущенная с помощью QEMU/KVM, ничем не отличается от любого другого процесса, работающего в пользовательском пространстве операционной системы.
Соответственно, процесс выделения памяти виртуальной машине выполняется теми же вызовами в ядре Host OS, как если бы вы запускали, например, браузер Chrome.
Прежде чем продолжить рассказ об оперативной памяти в виртуальных машинах, необходимо сделать отступление и объяснить этот термин.НУМА - Неравномерный доступ к памяти.
Архитектура современных физических серверов включает два или более процессоров (ЦП) и связанную с ними оперативную память (ОЗУ).
Такая комбинация процессор+память называется узлом или узлом.
Связь между разными узлами NUMA осуществляется по специальной шине — QPI (Интерконнект QuickPath) Существует локальный узел NUMA — когда процесс, запущенный в операционной системе, использует процессор и оперативную память, расположенные в одном узле NUMA, и удаленный узел NUMA — когда процесс, работающий в операционной системе, использует процессор и оперативную память, расположенные в разных NUMA узлах.
узлы.
то есть взаимодействие процессора и памяти требует передачи данных по шине QPI.
С точки зрения виртуальной машины, память ей уже выделена в момент ее запуска, но на самом деле это не так, и хостовая ОС ядра выделяет новые блоки памяти процессу QEMU/KVM по мере приложения.
в гостевой ОС запрашивает дополнительную память (хотя это также может быть исключением, если вы напрямую указываете QEMU/KVM выделить всю память виртуальной машине непосредственно при запуске).
Память выделяется не побайтно, а определенного размера — страница .
Размер страницы настраивается и теоретически может быть любым, но на практике используются следующие размеры: 4 КБ (по умолчанию), 2 МБ и 1 ГБ.
Последние два размера называются Огромные страницы и часто используются для выделения памяти для виртуальных машин, интенсивно использующих память.
Причина использования HugePages в процессе поиска соответствия виртуального адреса страницы и физической памяти в Резервный буфер перевода ( TLB ), который в свою очередь ограничен и хранит информацию только о последних использованных страницах.
Если в TLB нет информации о нужной странице, происходит процесс, называемый промах TLB , и вам нужно с помощью процессора ОС хоста найти ячейку физической памяти, соответствующую нужной странице.
Этот процесс неэффективен и медленный, поэтому используется меньше страниц большего размера.
QEMU/KVM также позволяет эмулировать различные топологии NUMA для гостевой ОС, брать память для виртуальной машины только из конкретного узла NUMA Host OS и так далее.
Наиболее распространенной практикой является получение памяти для виртуальной машины из узла NUMA, локального для процессоров, выделенных виртуальной машине.
Причина – желание избежать лишней нагрузки на QPI шина, соединяющая сокеты ЦП физического сервера (конечно, это логично, если на вашем сервере 2 и более сокета).
Хранилище Как известно, оперативная память называется оперативной потому, что ее содержимое исчезает при отключении питания или перезагрузке операционной системы.
Для хранения информации используется постоянное запоминающее устройство (ПЗУ) или постоянного хранения .
Существует два основных типа постоянного хранилища:
- Блочное хранилище — это блок дискового пространства, который можно использовать для установки файловой системы и создания разделов.
Грубо говоря, его можно представить как обычный диск.
- Объектное хранилище – информация может быть сохранена только в виде объекта (файла), доступного по HTTP/HTTPS. Распространенными примерами объектного хранилища являются AWS S3 или Dropbox.
Этот метод малоэффективен, и поэтому, как и для сетевых устройств, здесь вместо полной эмуляции IDE или iSCSI-устройства используется драйвер virtio. Вы можете прочитать об этом больше Здесь .
Таким образом, виртуальная машина обращается к своему виртуальному диску через драйвер virtio, а затем QEMU/KVM следит за тем, чтобы переданная информация была записана на физический диск.
Важно понимать, что в ОС хоста серверная часть диска может быть реализована в виде полки CEPH, NFS или iSCSI. Самый простой способ эмулировать постоянное хранилище — использовать файл в любом каталоге ОС хоста в качестве дискового пространства виртуальной машины.
QEMU/KVM поддерживает множество различных форматов файлов этих типов — raw, vdi, vmdk и другие.
Однако наиболее распространенным форматом является qcow2 (QEMU копирование при записи, версия 2).
В общем, qcow2 — это файл, структурированный определенным образом, без какой-либо операционной системы.
Большое количество виртуальных машин распространяется именно в виде образов (образов) qcow2 и представляет собой копию системного диска виртуальной машины, упакованную в формате qcow2. Это имеет ряд преимуществ - кодировка qcow2 занимает гораздо меньше места, чем сырая побайтовая копия диска, QEMU/KVM может изменять размер файла qcow2, а значит, можно изменить размер системного диска виртуальной машины, Также поддерживается AES-шифрование qcow2 (это имеет смысл, поскольку образ виртуальной машины может содержать интеллектуальную собственность).
Далее, при запуске виртуальной машины QEMU/KVM использует файл qcow2 в качестве системного диска (процесс загрузки виртуальной машины я здесь опускаю, хотя это тоже интересная задача), и виртуальная машина имеет возможность чтения / записать данные в файл qcow2 через virtio -driver. Именно так работает процесс захвата образов виртуальных машин, поскольку в любой момент времени файл qcow2 содержит полную копию системного диска виртуальной машины, и образ можно использовать для резервного копирования, переноса на другой хост и т.д. В общем, этот файл qcow2 будет определен в гостевой ОС как /dev/вда -device, а гостевая ОС разобьет дисковое пространство на разделы и установит файловую систему.
Аналогично, следующие файлы qcow2, подключенные с помощью QEMU/KVM, как /dev/vdX устройства могут использоваться как блочное хранилище в виртуальной машине для хранения информации (именно так работает компонент Openstack Cinder).
Сеть Последними в нашем списке виртуальных ресурсов являются сетевые карты и устройства ввода-вывода.
Виртуальной машине, как и физическому хосту, требуется Шина PCI/PCIe для подключения устройств ввода/вывода.
QEMU/KVM способен эмулировать различные типы чипсетов — q35 или i440fx (первый поддерживает PCIe, второй — устаревший PCI), а также различные топологии PCI, например, создавая отдельные шины PCI (шину расширения PCI) для узлов NUMA. Гостевая ОС.
После создания шины PCI/PCIe к ней необходимо подключить устройство ввода-вывода.
В общем, это может быть что угодно, от сетевой карты до физического графического процессора.
И, конечно же, сетевая карта, либо полностью виртуализированная (полностью виртуализированный интерфейс e1000, например), либо паравиртуализированная (virtio, например), либо физический сетевой адаптер.
Последний вариант используется для виртуальных машин плоскости данных, где необходимо получить скорость передачи пакетов — маршрутизаторы, межсетевые экраны и т. д. Здесь есть два основных подхода: Сквозное соединение PCI И СР-ИОВ .
Основное различие между ними в том, что для PCI-PT драйвер используется только внутри Гостевой ОС, а для SRIOV — драйвер Хостовой ОС (для создания VF — Виртуальные функции ) и драйвер гостевой ОС для управления SR-IOV VF. Более подробная информация о PCI-PT и SRIOV превосходна Разместил: Джунипер .
Для пояснения стоит отметить, что сквозная передача PCI и SR-IOV являются взаимодополняющими технологиями.Итак, мы рассмотрели основные типы виртуальных ресурсов и следующим шагом будет понимание того, как виртуальная машина общается с внешним миром через сеть.SR-IOV разделяет физическую функцию на виртуальные функции.
Это делается на уровне хостовой ОС.
В этом случае хост-операционная система рассматривает виртуальные функции как другое устройство PCI/PCIe. Что он с ними сделает дальше, не важно.
А PCI-PT — это механизм перенаправления любого PCI-устройства хостовой ОС в гостевую ОС, включая виртуальную функцию, созданную устройством SR-IOV.
Виртуальное переключение Если есть виртуальная машина, и у нее есть виртуальный интерфейс, то, очевидно, возникает задача передачи пакета с одной ВМ на другую.
В гипервизорах на базе Linux (например, KVM) эту задачу можно решить с помощью моста Linux, однако проект получил широкое распространение.
Открыть vSwitch (ОВС).
Существует несколько основных функций, которые позволили OVS получить широкое распространение и стать де-факто основным методом коммутации пакетов, используемым во многих платформах облачных вычислений (например, Openstack) и виртуализированных решениях.
- Передача состояния сети — при миграции ВМ между гипервизорами возникает задача переноса ACL, QoS, таблиц пересылки L2/L3 и прочего.
И ОВС может это сделать.
- Реализация механизма передачи пакетов (datapath) как в ядре, так и в пользовательском пространстве.
- Архитектура CUPS (Control/User-plane Separation) — позволяет перенести функциональность обработки пакетов на специализированный набор микросхем (чипсет Broadcom и Marvell, например, может это сделать), управляя им через OVS уровня управления.
- Поддержка методов удаленного управления трафиком — протокол OpenFlow (привет, SDN).
Для работы с ОВС необходимо понимать следующее:
- Путь к данным — здесь обрабатываются пакеты.
Аналогия – ветошь-ткань железной вилки.
Datapath включает в себя прием пакетов, обработку заголовков, поиск совпадений в таблице потоков, которая уже запрограммирована в Datapath. Если OVS работает в ядре, то он реализован как модуль ядра.
Если OVS работает в пользовательском пространстве, то это процесс в пользовательском пространстве Linux.
- vswitchd И овсдб — демоны в пользовательском пространстве, которые непосредственно реализуют функциональность коммутатора, сохраняют конфигурацию, задают поток в пути данных и программируют его.
- Набор инструментов для настройки и устранения неполадок ОВС - овс-всктл, овс-дпктл, овс-офктл, овс-апктл .
Всё что нужно прописать конфигурацию порта в ovsdb, указать какой поток куда переключать, собрать статистику и т.д. Люди добрые написал статью в этом случае.
В операционной системе Linux пакеты передаются между ядром и процессами пользовательского пространства через два специальных интерфейса.
Оба интерфейса используют запись/чтение пакетов в/из специального файла для передачи пакетов из пользовательского процесса в ядро и обратно - файловый дескриптор (FD) (это одна из причин низкой производительности виртуальной коммутации, если OVS путь к данным находится в ядре — каждый пакет требуется для записи/чтения через FD)
- ТУН (туннель) — устройство, работающее в режиме L3 и позволяющее записывать/читать только IP-пакеты на/из FD.
- КРАН (сетевой отвод) — то же, что и интерфейс tun + может выполнять операции с кадрами Ethernet, т.е.
работать в режиме L2.
Именно поэтому, когда виртуальная машина работает в ОС хоста, вы можете увидеть TAP-интерфейсы, созданные командой IP-ссылка или есликонфигурация — это «ответная» часть virtio, которая «видна» в ядре Хост-ОС.
Также стоит отметить, что интерфейс TAP имеет тот же MAC-адрес, что и интерфейс virtio на виртуальной машине.
Интерфейс TAP можно добавить в OVS с помощью команд овс-vsctl - тогда любой пакет, коммутируемый OVS на TAP-интерфейс, будет передаваться на виртуальную машину через файловый дескриптор.
Реальная процедура создания виртуальной машины может отличаться, т.е.Теперь, если нам нужно иметь возможность передавать пакеты между двумя и более виртуальными машинами, работающими на одном гипервизоре, нам достаточно создать OVS-мост и добавить к нему TAP-интерфейсы с помощью команд ovs-vsctl. Легко погуглить, какие команды для этого нужны.сначала вы можете создать мост OVS, затем указать виртуальной машине создать интерфейс, подключенный к этому OVS, или наоборот.
На гипервизоре может быть несколько мостов OVS, например, так работает Openstack Neutron, или виртуальные машины могут располагаться в разных пространствах имен для реализации мультитенантности.
Что делать, если виртуальные машины расположены в разных мостах OVS? Для решения этой проблемы есть еще один инструмент – вет пара .
Пару Veth можно представить как пару сетевых интерфейсов, соединенных кабелем — все, что «влетает» в один интерфейс, «вылетает» из другого.
Пара Veth используется для соединения нескольких мостов OVS или мостов Linux. Еще одним важным моментом является то, что части пары veth могут располагаться в разных пространствах имен ОС Linux, то есть пары veth также могут использоваться для связи пространств имен друг с другом на сетевом уровне.
Инструменты виртуализации — libvirt, virsh и др.
В предыдущих главах мы рассмотрели теоретические основы виртуализации; в этой главе мы поговорим об инструментах, доступных пользователю непосредственно для запуска и изменения виртуальных машин на гипервизоре KVM. Остановимся на трёх основных компонентах, которые покрывают 90 процентов всех возможных операций с виртуальными машинами:
- libvirt
- вирш CLI
- вирт-установка
Конечно, существует множество других утилит и команд CLI, позволяющих управлять гипервизором, например, можно напрямую использовать команды qemu_system_x86_64 или графический интерфейс virt Manager, но это скорее исключение.Кроме того, существующие сегодня облачные платформы, например Openstack, используют libvirt.
libvirt
libvirt — масштабный проект с открытым исходным кодом, разрабатывающий набор инструментов и драйверов для управления гипервизорами.Он поддерживает не только QEMU/KVM, но также ESXi, LXC и многое другое.
Основная причина его популярности — структурированный и понятный интерфейс взаимодействия через набор XML-файлов плюс возможность автоматизации через API. Стоит отметить, что libvirt не описывает все возможные функции гипервизора, он лишь предоставляет удобный интерфейс для использования.
полезный , с точки зрения участников проекта, функции гипервизора.
И да, libvirt сегодня является стандартом де-факто в мире виртуализации.
Только взгляните на список приложений , которые используют libvirt. 
Хорошая новость о libvirt в том, что все необходимые пакеты уже предустановлены во всех наиболее часто используемых Host OS — Ubuntu, CentOS и RHEL, поэтому, скорее всего, вам не придется собирать необходимые пакеты вручную и компилировать libvirt. В худшем случае вам придется использовать соответствующий установщик пакетов (apt, yum и тому подобное).
При первоначальной установке и запуске libvirt по умолчанию создает мост Linux virbr0 и его минимальную конфигурацию.
Вот почему, например, при установке Ubuntu Server вы увидите в выводе команды ifconfig Linux Bridge virbr0 — это результат запуска демона libvirtd.Этот мост Linux не будет подключен ни к какому физическому интерфейсу, однако его можно использовать для подключения виртуальных машин внутри одного гипервизора.
Libvirt, безусловно, можно использовать вместе с OVS, однако для этого пользователю необходимо самостоятельно создавать OVS-мостики с помощью соответствующих OVS-команд. Любой виртуальный ресурс, необходимый для создания виртуальной машины (вычисление, сеть, хранилище), представлен в libvirt как объект. За процесс описания и создания этих объектов отвечает набор различных XML-файлов.
Подробно описывать процесс создания виртуальных сетей и виртуальных хранилищ не имеет особого смысла, поскольку эта задача приложения хорошо описана в документации libvirt:
Сама виртуальная машина со всеми подключенными PCI-устройствами в терминологии libvirt называется доменом.Это слишком объект внутри libvirt , который описан в отдельном XML-файле.
Этот XML-файл, строго говоря, представляет собой виртуальную машину со всеми виртуальными ресурсами — оперативной памятью, процессором, сетевыми устройствами, дисками и т. д. Этот XML-файл часто называют libvirt XML или дампом XML. Вряд ли найдется человек, разбирающийся во всех XML-параметрах libvirt, однако при наличии документации это и не требуется.
В целом XML libvirt для гостевой ОС Ubuntu Desktop будет довольно простым — 40-50 строк.
Поскольку все оптимизации производительности также описаны в libvirt XML (топология NUMA, топологии ЦП, привязка ЦП и т. д.), для сетевых функций XML libvirt может быть очень сложным и содержать несколько сотен строк.
Любой производитель сетевых устройств, поставляющий свое программное обеспечение в виде виртуальных машин, рекомендует примеры XML libvirt.
вирш CLI
Утилита virsh — это встроенная командная строка для управления libvirt. Его основная цель — управлять объектами libvirt, описанными в виде XML-файлов.Типичными примерами являются операции запуска, остановки, определения, уничтожения и т. д. То есть жизненный цикл объектов – управление жизненным циклом.
Описание всех команд и флагов virsh также доступно в документации.
libvirt .
вирт-установка
Еще одна утилита, которая используется для взаимодействия с libvirt. Одним из главных преимуществ является то, что вам не придется иметь дело с форматом XML, а достаточно использовать флаги, доступные в virsh-install. Второй важный момент – море примеров и информации в Интернете.Таким образом, какую бы утилиту вы ни использовали, управлять гипервизором в конечном итоге будет libvirt, поэтому важно понимать архитектуру и принципы ее работы.
Заключение В этой статье мы рассмотрели минимальный набор теоретических знаний, который необходим для работы с виртуальными машинами.
Я сознательно не стал приводить практические примеры и вывод команд, поскольку таких примеров можно найти в Интернете в изобилии, и я не ставил перед собой задачу написать «пошаговое руководство».
Если вас интересует какая-то конкретная тема или технология, оставляйте свои комментарии и пишите вопросы.
Полезные ссылки
Спасибо
- Александр Шалимов - мой коллега и эксперт в области разработки виртуальных сетей.
Для комментариев и правок.
- Евгению Яковлеву, моему коллеге и эксперту в области виртуализации, за комментарии и поправки.
-
Праздники, Которые Отмечает Яндекс
19 Oct, 24 -
«Находка» Новый Алгоритм Поиска Яндекса
19 Oct, 24 -
Sublimehaskell
19 Oct, 24 -
Облако 3D-Тегов В Html 5
19 Oct, 24 -
Вы Играете В Игры?
19 Oct, 24 -
Жизнь За Пределами Солнечной Системы
19 Oct, 24 -
Мобильный Телефон Учит
19 Oct, 24
