Виртуализация приложений
Виртуализация приложения позволяет создать изолированную среду для работы приложения, включающую специфические для приложения библиотеки, реестр и другие системные элементы. С помощью Microsoft Application Virtualization (App-V) приложения можно сделать доступными для пользовательских компьютеров без необходимости устанавливать их непосредственно на эти компьютеры. Это стало возможным благодаря процессу, называемому виртуализацией приложений, который позволяет каждому приложению работать в собственной автономной виртуальной среде на клиентском компьютере. Виртуализированные приложения изолированы друг от друга. Это позволяет избежать конфликтов между приложениями, но они по-прежнему могут взаимодействовать с клиентским компьютером.
Клиент App-V Client — это компонент, который позволяет пользователю взаимодействовать с приложениями после того, как они будут опубликованы на компьютере. Клиент управляет виртуальной средой, в которой работают виртуализированные приложения на каждом компьютере. Установив клиента на компьютер, приложения необходимо сделать доступными для этого компьютера с помощью процесса, называемого публикацией, который позволяет пользователю запускать виртуальные приложения.
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 и его минимальную конфигурацию.
Этот Linux bridge не будет подключен ни к одному физическому интерфейсу, однако, может быть использован для связи виртуальных машин внутри одного гипервизора. Libvirt безусловно может быть использован вместе с OVS, однако, для этого пользователь должен самостоятельно создать OVS bridges с помощью соответствующих OVS-команд.
Любой виртуальный ресурс, необходимый для создания виртуальной машины (compute, network, storage) представлен в виде объекта в libvirt. За процесс описания и создания этих объектов отвечает набор различных XML-файлов.
Детально описывать процесс создания виртуальных сетей и виртуальных хранилищ не имеет особого смысла, так как эта прикладная задача хорошо описана в документации libvirt:
- Networking
- Storage
Сама виртуальная машина со всеми подключенными 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.
Виртуализация серверов
Серверная виртуализация предполагает создание виртуальных машин на хост-серверах для размещения серверных нагрузок. Специально для этих целей компания Microsoft разработала средство для виртуализации на аппаратном уровне, которое называется Hyper-V и внедрено во все редакции Windows Server 2008/2008 R2 x64 кроме Windows Web Server 2008/2008 R2. Hyper-V – это платформа виртуализации, основанная на гипервизоре, которая позволяет разворачивать серверные операционные системы. Виртуализация серверов обычно соответствует следующим требованиям:
- Интерфейсы управления. Для виртуализации серверов существуют интерфейсы управления, благодаря которым администраторы могут создавать, настраивать и наблюдать за виртуальными машинами, работающими на компьютере. К тому же, всеми виртуальными машинами вы можете управлять дистанционно.
- Управление памятью. Для виртуализации серверов также используется менеджер памяти, который распределяет ресурсы оперативной памяти хостовой машины между всеми изолированными гостевыми виртуальными машинами.
- Планирование управления. Для виртуализации серверов также используется планирование управления доступом к физическим ресурсам для разных виртуальных машин. Планировщик настраивается администратором так, что различные виртуальные машины могут распределять аппаратные ресурсы по своей необходимости.
- Управление жесткими дисками и сетью. Для виртуализации серверов используются абстрактные системы хранения и управления сетевыми ресурсами, чтобы у каждой виртуальной машины можно было создавать собственные жесткие диски, а также настраивать сетевые интерфейсы.
- Виртуализация устройств. Обеспечивает использование существующих устройств в виртуальных машинах.
Для виртуализации серверных операционных систем компания Microsoft разработала технологию полной и аппаратной виртуализации.
К средству аппаратной виртуализации относится Microsoft Hyper-V Server 2008/2008 R2, который был выпущен 1 октября 2008 года и является абсолютно бесплатным решением от компании Microsoft. Бесплатная 64-разрядная «Core»-версия Hyper-V ограничена интерфейсом командной строки (CLI), где конфигурация текущей операционной системы, физического аппаратного и программного оборудования выполняется при помощи команд оболочки. Администрирование и конфигурирование сервера осуществляется при помощи RSAT, установленного на компьютеры под управлением Windows Vista или Windows Server 2008/2008 R2 с установленным дополнением для администрирования Hyper-V из MMC.
К полным средствам виртуализации компании Microsoft относится Microsoft Virtual Server, а также роль Hyper-V в Windows Server 2008/2008 R2. Роль Hyper-V позволяет создать виртуализованную вычислительную серверную среду и управлять ею с использованием встроенной технологии Windows Server 2008 R2. Эта роль доступна в 64-разрядных редакциях Windows Server 2008 Standard, Enterprise и Datacanter как в полном режиме, так и в режиме ядра.
На практике это выглядит следующим образом. Перед вами стоит задача развернуть контроллер домена, почтовый сервер Microsoft Exchange Server, сервер служб сертификации, а также службы удаленных рабочих столов. Купив четыре отдельных сервера, вы будете тратить немало средств на систему охлаждения и аренду помещения для их расположения. Устанавливать все эти роли на одну физическую машину нецелесообразно. Решить эту задачу вам поможет роль Hyper-V серверной операционной системы Windows Server 2008/2008 R2.
После установки хостовой серверной 64-разрядной операционной системы любой редакции, кроме Windows Web Server 2008/2008 R2, установите роль контроллера домена, DNS и Hyper-V. В гипервизоре создайте столько виртуальных машин, сколько вам нужно для реализации всех ваших ролей. Например, создав первую виртуальную машину, вы можете установить на нее Microsoft Exchange Server с ролями сервера почтовых ящиков, транспортного сервера и сервера клиентского доступа. Для этой машины вам нужно будет выделить достаточно ресурсов, так как этот почтовый сервер будут использовать все пользователи вашей организации. На второй виртуальной машине вы можете развернуть роли служб сертификации и удаленных рабочих столов, тем самым создав три отдельных сервера на одной физической машине.
Основные отличия облачных технологий и виртуализации
По таблице разница между облачными вычислениями и виртуализацией будет более наглядной.
Параметр | Облачные вычисления | Виртуализация |
---|---|---|
Способность к масштабированию | Неограниченная, можно расширять до бесконечности | Ограничена конфигурацией виртуального аппаратного обеспечения |
Скорость установки | Процедура длительная, трудоемкая | Простая, быстрая настройка, требует минимум знаний |
Гибкость настроек | Высокая: пользователь может получить доступ к своему облаку из любого уголка мира и гаджета при условии наличия интернет-соединения | Чтобы получить доступ к виртуальной машине необходимо пойти аутентификацию |
Тип обслуживания | IaaS | SaaS |
Необходимое оборудование | Требуется несколько аппаратных средств для обеспечения облачных вычислений | Каждая виртуальная машина требует своего аппаратного обеспечения |
Возможность интеграции | Предполагает расширение в будущем: добавление количества приложений, пользователей | В рамках одной инфраструктуры позволяет добавлять новые устройства |
Зависимость | По одной и той же ссылке в сети могут получить доступ несколько пользователей, в том числе одновременно | На одном компьютере/сервере может быть установлено несколько операционных систем |
Доступность | Широкая: любой пользователь с доступом в интернет | Низкая: доступ только у тех, кто подключен к сети. Сторонние пользователи могут получить доступ только через разрешение |
Аварийное восстановление | Если одна из машин выйдет из строя, облако продолжит работать, распределив ее нагрузку между другим оборудованием | Сбои в работе одной машины могут повлечь за собой выход из строя других виртуальных устройств |
Возможные виды | Публичное и частное облако | Аппаратная виртуализация и виртуализация приложений |
Виртуализация представлений
Виртуализация представлений позволяет отделить процесс обработки информации от графического интерфейса приложения и системы ввода с клавиатуры и мыши. Другими словами, виртуализация представлений отделяет пользовательский интерфейс приложения от физического компьютера, на котором выполняется приложение. Таким образом, представления позволяют запускать приложения в одном ресурсе (пользовательском компьютере или мобильном устройстве), которое на самом деле установлено в другом расположении (например, в центре обработки данных). Тем самым, виртуализация представлений вписывается в общую концепцию виртуализации как технология, которая изолирует одни слои компьютерных ресурсов от других.
Службы удаленных рабочих столов Windows Server 2008/2008 R2 (или службы терминалов) обеспечивают возможность пользователям работать с программами Windows, установленными на сервере, или со всем рабочим столом Windows. Реализация решения виртуализации представлений довольно проста. По окончании планирования администратор настраивает Windows Server 2008/2008 R2 в качестве терминального сервера путем установки одной или нескольких служб терминалов на отдельном сервере. После этого администратору нужно установить на терминальном сервере соответствующие приложения, которые необходимы пользователям для работы.
Службы терминалов также могут использоваться для предоставления пользователям удаленного доступ к рабочим станциям, а также безопасного доступ к приложениям и рабочему столу при помощи веб-доступа, реализованного к удаленным рабочим столам и возможности локальной печати с удаленных приложений. Узел виртуализации удаленных рабочих столов можно настроить таким образом, чтобы каждому пользователю в организации назначался индивидуальный рабочий стол или чтобы пользователи перенаправлялись в общий пул с динамическим назначением виртуальных рабочих столов.
Что такое Docker
Подобно тому, как название фирмы Xerox стало нарицательным именем для всех копировальных аппаратов или копий бумажных документов, а поисковик Google обогатил интернет-словарь глаголом «гуглить», Docker стал синонимом работы с контейнерами.
Однако Docker — больше, чем сами контейнеры. Это обширный набор инструментов для разработчиков, позволяющий создавать, публиковать, запускать и управлять контейнерными приложениями.
Создание образов
Docker Build создает базовый образ контейнера, который включает все необходимое для запуска приложения — его код, двоичные файлы, сценарии, зависимости, конфигурацию, переменные среды и другое. Для определения и запуска многоконтейнерных приложений применяется инструмент Docker Compose.
Docker Build и Docker Compose тесно интегрированы с репозиториями кода (GitHub), а также с инструментами конвейера непрерывной интеграции и непрерывного развертывания — CI/CD (например, Jenkins).
Совместное использование образов
Docker Hub — служба реестра Docker, применяемая для поиска образов контейнеров, а также предоставления ограниченного (для разработчиков) или общего доступа к этим образам. Docker Hub по функциональности похож на GitHub.
Запуск контейнеров
Среда выполнения контейнеров Docker Engine работает практически на любой платформе — компьютерах Mac и Windows, серверах Linux и Windows, в облаке и на пограничных устройствах.
Docker Engine функционирует как обертка над движком containerd — исполняемой средой для запуска контейнеров с открытым исходным кодом, поддерживаемой независимым проектом Cloud Native Computing Foundation (DNCF).
Встроенная оркестрация контейнеров
Встроенный инструмент Docker Swarm управляет кластером модулей Docker или «роем» (от англ. swarm). Обычно такой кластер создается на разных нодах. Функционал Docker Swarm напрямую пересекается с Kubernetes.
Подробнее об устройстве и работе с Docker можно узнать из нашей статьи «Что такое Docker».
В чем разница Kubernetes и Docker Swarm
И Docker Swarm, и Kubernetes — это платформы для оркестрации контейнеров производственного уровня, но у каждой из них есть свои сильные стороны.
Платформа Docker Swarm
Встроенная утилита Docker Swarm (Docker in swarm mode, «Docker в режиме роя») — самый простой в развертывании и управлении оркестратор. Это хороший выбор для организации, которая только начинает использовать контейнеры в производстве.
Swarm надежно покрывает 80% всех возможных сценариев оркестровки контейнеров. При этом его инструментарий примерно в 5 раз легче освоить, чем Kubernetes.
Swarm легко интегрируется с остальной частью набора инструментов Docker, например с Docker Compose и Docker CLI. Это обеспечивает привычный пользовательский интерфейс с плавной кривой обучения. Для контейнеров Docker Swarm считается более безопасным и простым в устранении неполадок, чем Kubernetes.
Плюсы Docker Swarm
- Удобная установка. Для работы Docker Swarm использует тот же интерфейс командной строки, что и Docker. Это упрощает настройку и дальнейшую работу пользователей. Ведь им нужно изучить только один набор инструментов для создания сред и конфигураций.
- Совместимость. Docker Swarm работает поверх Docker и идеально совместим с другими инструментами этой экосистемы. Пользователи работают с одним и тем же интерфейсом командной строки Docker, который обеспечивает простую в использовании структуру команд.
- Скорость. Docker Swarm предоставляет динамичную среду, которая позволяет приложениям быстро запускаться в виртуальном пространстве.
- Хорошая документированность. Docker постоянно обновляет свою документацию, чтобы давать пользователям самую последнюю информацию по изменениям в своей экосистеме.
- Контроль версий. Пользователи могут легко отслеживать текущие версии docker-контейнера, чтобы контролировать расхождения с предыдущими версиями.
Минусы Docker Swarm
- Зависимость от платформы. Docker Swarm поддерживает несколько операционных систем, но только на базе Linux.
- Хранилище. В Docker нет встроенной реализации хранилища, поэтому Docker Swarm — не самое простое решение для подключения контейнеров к хранилищу.
- Мониторинг. В Docker Swarm нет встроенных инструментов расширенного мониторинга, позволяющих собрать больше данных в режиме реального времени.
Платформа Kubernetes
Главные «козыри» платформы оркестрации Kubernetes — почти безграничная масштабируемость, гибкая настраиваемость и богатая технологическая экосистема, включающая множество фреймворков с открытым исходным кодом для мониторинга, управления и безопасности.
Плюсы Kubernetes
- Ведение журнала и мониторинг. Поддержка нескольких вариантов ведения журнала и мониторинга при развертывании служб в кластере.
- Скорость. Kubernetes способен обновлять приложения в непрерывном режиме, добиваясь стабильного аптайма и отсутствия простоев.
- Декларативная конфигурация системы. Декларативный подход позволяет разработчику сообщить API-серверу о необходимом ему состоянии системы, а распределение ресурсов, организацию процессов и другие детали реализации берет на себя kubectl.
- Масштабирование инфраструктуры. Из-за неизменной и декларативной природы Kubernetes систему легко расширять с помощью методов горизонтального, автоматического и ручного масштабирования, а также применения контроллера репликаций.
- Хранилище. Kubernetes обменивается данными между контейнерами, надежно сохраняя данные на удаленном хранилище, пока пользователь не решит их удалить.
Минусы Kubernetes
- Настройка. Kubernetes использует разные настройки для каждой операционной системы, что усложняет процесс.
- Миграция. Если приложение уже кластеризовано или не имеет состояния, попытка миграции в Kubernetes приведет к сбою настройки подов и необходимости переработки конфигурации.
- Совместимость. Kubernetes несовместим с существующими инструментами Docker CLI и Compose.
Kubernetes | Docker Swarm |
Комплексная установка. | Облегченная установка поверх Docker. |
Более сложный — длительный процесс обучения, но более мощный инструмент. | Легкий и простой в освоении, но с ограниченной функциональностью. |
Поддерживает автоматическое масштабирование. | Масштабирование в ручном режиме. |
Встроенный мониторинг. | Требуются сторонние инструменты для мониторинга. |
Ручная настройка балансировщика нагрузки. | Автоматическая балансировка нагрузки. |
Необходим отдельный инструмент CLI. | Интегрирован с Docker CLI. |
Почему Корпорация Майкрософт является отличной платформой для виртуальных устройств
Платформа Майкрософт была спроектирована как отличная платформа для создания и развертывания виртуальных устройств. Ниже объясняются причины.
-
Корпорация Майкрософт предоставляет ключевые виртуализированные сетевые функции с Windows Server 2016.
-
Вы можете развернуть виртуальное устройство от выбранного поставщика.
-
Вы можете развертывать, настраивать виртуальные устройства и управлять ими с помощью сетевого контроллера Майкрософт, который поставляется с Windows Server 2016. Дополнительные сведения о сетевом контроллере см. в разделе «Сетевой контроллер».
-
Hyper-V может размещать наиболее необходимые гостевые операционные системы.
CPU
Теоретически QEMU способен эмулировать любой тип процессора и соотвествующие ему флаги и функциональность, на практике используют либо host-model и точечно выключают флаги перед передачей в Guest OS либо берут named-model и точечно включают\выключают флаги.
По умолчанию QEMU будет эмулировать процессор, который будет распознан Guest OS как QEMU Virtual CPU. Это не самый оптимальный тип процессора, особенно если приложение, работающее в виртуальной машине, использует CPU-флаги для своей работы. Подробнее о разных моделях CPU в QEMU.
QEMU/KVM также позволяет контролировать топологию процессора, количество тредов, размер кэша, привязывать vCPU к физическому ядру и много чего еще.
Нужно ли это для виртуальной машины или нет, зависит от типа приложения, работающего в Guest OS
Например, известный факт, что для приложений, выполняющих обработку пакетов с высоким PPS, важно делать CPU pinning, то есть не позволять передавать физический процессор другим виртуальным машинам
Виды виртуализации
При виртуализации физическую инфраструктуру чаще всего заменяют виртуализированной на аппаратном уровне или на уровне операционной системы. Первый вариант еще называют полной виртуализацией. В этой модели всегда участвует гипервизор — приложение, которое занимается управлением (менеджментом) виртуальных машин. Полная виртуализация используется при построении крупных корпоративных систем.
Паравиртуализация похожа на полную виртуализацию. Здесь за распределения доступа к аппаратным ресурсам отвечает код самой операционной системы. В этом решении есть большой плюс — виртуализированные ресурсы не уступают физическим, поэтому производительность системы остается высокой, чего нет в полной виртуализации. К недостаткам относят ограниченный выбор ОС с поддержкой этой технологии и необходимость менять ядро операционной системы на уровне кода.
Виртуализация ИТ на уровне ОС предполагает, что серверы виртуализированы над операционной системой и при этом есть много отдельных (независимых друг от друга) виртуальных серверов. Здесь тоже нужно менять ядро ОС, но появляется другой плюс — виртуальные машины работают независимо от физического оборудования.
virt-install
Еще одна утилита, которая используется для взаимодействия с libvirt. Одно из основных преимуществ — можно не разбираться с XML-форматом, а обойтись лишь флагами, доступными в virsh-install
Второй важный момент — море примеров и информации в Сети.
Таким образом какой бы утилитой вы ни пользовались, управлять гипервизором в конечном счете будет именно libvirt, поэтому важно понимать архитектуру и принципы его работы
Заключение
В данной статье мы рассмотрели минимальный набор теоретических знаний, который необходим для работы с виртуальными машинами. Я намеренно не приводил практических примеров и выводов команд, поскольку таких примеров можно найти сколько угодно в Сети, и я не ставил перед собой задачу написать «step-by-step guide». Если вас заинтересовала какая-то конкретная тема или технология, оставляйте свои комментарии и пишите вопросы.
Спасибы
- Александру Шалимову — моему коллеге и эксперту в области разработки виртуальных сетей. За комментарии и правки.
- Евгению Яковлеву — моему коллеге и эксперту в области виртуализации за комментарии и правки.
Как работает виртуализация
Гипервизоры забирают ваши физические ресурсы и разделяют их для виртуальных сред. Они устанавливаются поверх ОС (например, на ноутбуке) или непосредственно на аппаратном обеспечении, как это происходит на большинстве предприятий.
Ресурсы распределяются по мере необходимости — от физического окружения до множества виртуальных. Пользователи взаимодействуют и выполняют вычисления в виртуальном пространстве (обычно называемой гостевой или виртуальной машиной). Виртуальная машина функционирует как один файл данных. Его можно открывать и перемещать с одного места на другое.
Когда средства виртуализации запущены, и пользователь или программа выдает инструкцию на дополнительные меры от физической среды, гипервизор обращается к системе, и кэширует изменения. Это протекает почти на собственной скорости (особенно если запрос отправляется через гипервизор с открытым исходным кодом на основе KVM — гостевой машины на основе ядра).
Заключение
Kubernetes и Docker — технологии контейнеризации с разными сферами применения, которые успешно работают как по отдельности, так и вместе. Первый инструмент служит для определения и запуска контейнеров, а второй — это система оркестрации, которая представляет и управляет контейнерами в веб-приложении.
Возможность создание контейнеров — это главное, чем Docker отличается от Kubernetes. Сам Kubernetes не создает контейнеры, а полагается на готовый способ их реализации, такой как Docker или containerd.
Docker целесообразно применять для разработки программного обеспечения. Это включает настройку, создание и распространение контейнеров, с использованием конвейеров CI / CD и DockerHub в качестве реестра образов.
Kubernetes хорошо показывает себя в операциях с кластерами контейнеров, решая проблемы автоматизации развертывания, работы в сети, масштабирования и мониторинга. Хотя Docker Swarm является альтернативой в этой области, Kubernetes — лучший выбор при оркестровке больших распределенных приложений с сотнями подключенных микросервисов, включая базы данных, секреты и внешние зависимости.
Оцените материал: