Гипервизор

Как устроен контейнер

Ближайшая аналогия для контейнера — ящики с грузом, которые можно поставить где угодно. На их содержимое не влияют условия снаружи. Только внутри контейнера может запуститься и работать приложение. Оно будет исполняться изолированно от основной системы, не взаимодействуя с ней. Контейнер универсален: его можно развернуть в любой ОС независимо от настроек.

Контейнеры создаются на основе образов, похожих на те, которые используются для установки ОС. Но есть отличие: внутри находится не полноценная операционная система, а минималистичная среда с нужными настройками. Образ запускается в приложении для управления контейнерами, и из него разворачивается контейнер.

Какой вариант лучше?

Будет несправедливо сравнивать Docker и виртуальные машины, поскольку они предназначены для различного использования. Docker, без сомнения, набирает сейчас обороты, но нельзя сказать, что они заменяют виртуальные машины. Несмотря на завоевание популярности Docker, виртуальная машина в некоторых случаях является лучшим выбором. Виртуальные машины считаются подходящим выбором в производственной среде, а не в контейнерах Docker, поскольку они работают на своих собственных ОС, не создавая угрозы для главного компьютера. Но если приложения должны быть протестированы, то стоит выбрать именно Docker, поскольку Docker предоставляет различные платформы ОС для тщательного тестирования программного обеспечения или приложения.

Кроме того, Docker-контейнеры используют docker-engine вместо гипервизора, как в виртуальных машинах. Поскольку ядро хоста не используется совместно, использование docker-engine делает контейнеры небольшими, изолированными, совместимыми, высокопроизводительными и быстро реагирующими. Контейнеры Docker имеют сравнительно низкие накладные расходы, поскольку они совместимы для совместного использования библиотек одного ядра и приложений. Организации используют гибридный подход главным образом, поскольку выбор между виртуальными машинами и контейнерами Docker зависит от предлагаемой рабочей нагрузки.

Кроме того, не многие компании, занимающиеся цифровыми операциями, полагаются на виртуальные машины в качестве своего основного выбора и предпочитают переходить на использование контейнеров, поскольку развертывание сравнительно длительное, а использование микросервисов также является одной из основных проблем, с которыми оно сталкивается. Тем не менее, они все еще являются некоторыми фирмами, которые предпочитают виртуальные машины, а не докеры, тогда как компании, которые заинтересованы в безопасности корпоративного уровня для своей инфраструктуры, предпочитают использовать докеры.

Наконец, контейнеры и Docker не конфликтуют с виртуальными машинами, они оба являются дополнительными инструментами для различной рабочей нагрузки и использования. Виртуальные машины созданы для приложений, которые обычно статичны и меняются не очень часто. Принимая во внимание, что платформа Docker имеет более гибкий подход, позволяющий легко и часто обновлять контейнеры. Итак, Docker – это просто шумиха или революция – или он заменяет виртуальные машины? Прокомментируйте свои мысли ниже или дайте дальнейшие предложения

Итак, Docker – это просто шумиха или революция – или он заменяет виртуальные машины? Прокомментируйте свои мысли ниже или дайте дальнейшие предложения.

Виртуальные машины

Виртуальная машина, по сути, является эмуляцией реального компьютера, которая выполняет те же программы, что и настоящий компьютер. Виртуальные машины запускаются на физической машине с использованием «гипервизора». Гипервизор, в свою очередь, работает либо на машине-хосте, либо на чистом сервере.

Давайте разберемся с жаргоном:

Гипервизор — это часть ПО, прошивки или аппаратного обеспечения, на которой работают виртуальные машины. Гипервизоры запускаются на физических компьютерах, называемых «хост-машинами». Хост-машина обеспечивает виртуальные машины ресурсами, включая оперативную память и процессор. Эти ресурсы делятся между виртуальными машинами и могут быть распределены по вашему усмотрению. Если на одной виртуальной машине работает более ресурсоемкое приложение, вы можете выделить больше ресурсов для нее, чем для других виртуальных машин, запущенных на одном и том же хосте.

Виртуальная машина, работающая на хосте (опять же, с использованием гипервизора), также часто называется «гостевой машиной». Этот гостевой компьютер содержит как приложение, так и все, что ему нужно для его запуска (например, системные двоичные файлы и библиотеки). Он также включает в себя весь собственный виртуализированный аппаратный стек (в него входят виртуализированные сетевые адаптеры, хранилище и процессор). Это означает, что у него также есть своя полноценная гостевая операционная система. Изнутри гостевая машина ведет себя как отдельное устройство с собственными ресурсами. С точки зрения извне, мы знаем, что это VM-ресурсы совместного доступа, предоставляемые хост-машиной.

Как упоминалось выше, гостевая машина может работать либо на гипервизоре в хосте, либо на гипервизоре на чистом сервере. Между ними есть некоторые важные различия.

Во-первых, хостовый гипервизор виртуализации работает на операционной системе хост-машины. Например, компьютер с OSX может иметь виртуальную машину (например, VirtualBox или VMware Workstation 8), установленную «поверх» этой ОС. У VM нет прямого доступа к аппаратным средствам, поэтому она должна проходить через операционную систему хоста (в нашем случае — Mac OSX).

Преимущество хостового гипервизора заключается в том, что базовое оборудование здесь имеет меньшую важность. Операционная система хоста отвечает за аппаратные драйверы вместо самого гипервизора и поэтому считается более «совместимой с оборудованием»

С другой стороны, этот дополнительный уровень между аппаратным обеспечением и гипервизором требует больше ресурсов, что снижает производительность виртуальной машины.

Гипервизорная среда на чистом сервере устраняет проблему производительности, так как установка и запуск проходит с аппаратного обеспечения хост-машины. Поскольку взаимодействие происходит напрямую с базовым оборудованием, для его работы не требуется ОС хоста. В этом случае сначала на сервере хост-машины в качестве ОС нужно установить гипервизор. В отличие от хостового гипервизора, гипервизор чистого сервера имеет собственные драйверы устройств и взаимодействует с каждым компонентом напрямую для любых задач ввода-вывода, обработки или специфических команд. Это приводит к повышению производительности, масштабируемости и стабильности. Компромисс заключается в том, что аппаратная совместимость ограничена, потому что в гипервизор может быть встроено ограниченное количество драйверов устройств.

После этого разговора о гипервизорах вам могло стать интересно, почему нам нужен этот дополнительный слой гипервизора между виртуальной машиной и машиной-хостом.

Ну, поскольку VM имеет собственную виртуальную ОС, гипервизор играет важную роль в обеспечении виртуальных машин платформой для управления и выполнения этой гостевой операционной системы. Он позволяет хост-компьютерам делиться своими ресурсами с виртуальными машинами, которые работают в качестве гостей поверх них.

Как вы можете видеть на диаграмме, каждая виртуальная машина содержит виртуальное оборудование, ядро (т. е. ОС) и пользовательское пространство.

I/O, VT-d

Кроме CPU и памяти, требуется виртуализизировать I/O, для того, чтобы немодифицированные ОС были в состоянии запускаться и работать с таким (эмулированным) оборудованием, как:

SATA контроллеры
NIC адаптеры
USB, Serial порты
VGA адаптером
Irq контроллерами (LAPIC, IO-APIC)
Clock (HPET,TSC)
и тд.

Поскольку устройства требуют физический адрес для DMA, а гостевым ОС недоступны физические страницы, для виртуальных систем созданы паравиртуализированные драйвера для I/O операций: virtio, которые в даный момент являются стандрартом де-факто. Также, для PCI устройств и DMA, существует поддержка на уровне процессора (IOMMU (VT-d)) принцип который также строится в построении таблиц трансляций памяти для DMA между гостевыми адресами и физическими.

Проблема контейнеров № 1: безопасность

Это самая серьезная проблема, которая, однако, часто упускается из виду. Дэниэл Уолш, инженер по безопасности из Red Hat, опубликовал статью «Пустые контейнеры». Там рассматривается Docker, который использует libcontainers в качестве основы. Libcontainers взаимодействует с пятью пространствами — Process, Network, Mount, Hostname, Shared Memory — при работе с Linux. При этом есть множество важных подсистем ядра Linux вне контейнера.

К ним относятся все устройства, SELinux, Cgroups и вся файловая система внутри /sys. Это значит, что при наличии у пользователя или приложения прав суперпользователя в контейнере операционная система может быть взломана. И это плохо.

Есть много способов обезопасить Docker и другие технологии контейнеризации. Например, можно смонтировать /sys только для чтения, заставить процессы контейнеров работать с определенными разделами файловой системы и настроить сеть так, чтобы можно было подключаться лишь к определенным внутренним сегментам. Но ничего из этого по умолчанию не сделано, и вам придется дополнительно озаботиться этими вопросами.

В качестве базового правила можно порекомендовать относиться к контейнерам так же, как вы относитесь к любому серверному приложению. Вот что советует Уолш:

Другая проблема состоит в том, что контейнеризованные приложения выпускает кто угодно. И среди разработчиков всегда найдутся «плохие парни». Если, к примеру, вы или ваши сотрудники достаточно ленивы, чтобы запустить на сервере первый попавшийся контейнер, то вполне можете получить трояна

Важно донести до сотрудников мысль, что нельзя просто скачивать любые приложения из Интернета так же, как они это делают на своих смартфонах

Вообще, на смартфоны тоже не стоит ставить что попало, но это уже совсем другая история.

Непростой выбор

Так что же выбрать — VM или контейнеры? Если требуется запустить несколько копий одного приложения, скажем MySQL, то используйте контейнер. Если нужна большая гибкость при работе нескольких программ — задействуйте виртуальную машину.

Кроме того, контейнеры обычно привязывают к определенной версии операционной системы. Это бывает полезно: нет необходимости беспокоиться о зависимостях, если приложение корректно работает в контейнере. Но взамен вы получаете дополнительные ограничения

С виртуальными машинами не важно, какой гипервизор используется (KVM, Hyper-V, vSphere, Xen), — скорее всего, вы сможете запустить там любую ОС. Нет проблемы запустить в VM специфичное приложение, работающее только на QNX

Но реализовать это с нынешним поколением контейнеров становится не просто.

Итак, подытожим:

Необходимо запускать максимум приложений на минимальном количестве серверов? В таком случае вы наверняка воспользуетесь контейнерами. Но помните о необходимости дополнительно позаботиться о безопасности.
Если же нужно выполнять множество приложений и/или поддерживать различные ОС — лучше подойдут виртуальные машины. И если вопрос безопасности для вашей организации стоит на первом месте, то тоже лучше остаться при VM.
Полагаю, большинство из нас будут использовать контейнеры совместно с виртуальными машинами как в облаках, так и в собственных ЦОД. Ведь открываемые контейнерами возможности экономии на масштабе слишком значительны, чтобы их игнорировать. А у виртуальных машин по-прежнему есть немало достоинств.

По мере «взросления» технологии контейнеризации нас ждет такое будущее, где контейнеры и виртуальные машины совместно будут составлять гибкую и портативную облачную среду. До этого еще далеко, но свет в конце тоннеля уже виднеется.

Разновидности гипервизоров

Гипервизоры подразделяются на 2 вида — первый и второй. Существует еще гибридный, совмещающий качества двух типов. Первый функционирует напрямую с сервером, а ОС клиентов накладывается поверх программы. Эти гипервизоры могут некоторым пользователям предлагать управленческие функции в отношении сервера. Основное количество организаций пользуются конкретно таким типом программы.

Гипервизоры второго вида называют размещенными. Они функционируют с ОС, стоящей на сервере. А операционки для новых пользователей накладываются поверх гипервизора. Примеры программ: первый тип — KVM, второй вид — настольные гипервизоры VMware Workstation, Oracle VirtualBox.

Преимущества виртуализации серверной инфраструктуры

Уменьшение административной нагрузки

С виртуальной инфраструктурой управление становится проще. Вот несколько примеров:

Администрирование серверов через централизованную консоль
Возможность быстрого монтирования CD/DVD-дисков с помощью ISO-файлов
Быстрое выделение дополнительной оперативной памяти или дискового пространства
Быстрое перемещение виртуальных серверов с одного сервера на другой.

Быстрое развертывание сервера

В крупных организациях установка операционной системы и приложений на все машины – довольно хлопотная задача. Виртуализация избавляет от этого – ИТ-специалисты устанавливают приложения и ОС всего на одну машину, и все будет работать на подключенных виртуальных серверах.

Поскольку каждый виртуальный гостевой сервер представляет собой просто файл на диске, вы можете быстро клонировать существующую систему или создать новую из образа.

Снижение стоимости инфраструктуры

Помимо экономии времени, виртуальный сервер поможет сократить затраты на физическое оборудование, систему охлаждения, электричество, сетевые порты. VMware, ведущий разработчик систем виртуализации, приводит следующие цифры:

Повышение уровня использования оборудования на 50-70%
Уменьшение капитальных затрат на аппаратное и программное обеспечение на 40%
Снижение операционных расходов на 50-70%

Также вам не придется приобретать лицензии на каждое устройство в отдельности. Для этого существуют пакеты виртуального лицензирования.

Простое аварийное восстановление

Если производственная площадка пострадала в результате катастрофы, необходимо быстро восстановить критически важные данные и операции, чтобы сократить время простоя системы и свести к минимуму ее негативное влияние на бизнес. Восстановление бизнес-операций, выполняемых на физическом сервере, может затянуться на несколько дней. Он включает в себя настройку нового физического сервера, установку ОС, настройку приложений и восстановление критически важных данных из резервных копий.

В виртуальной среде процесс аварийного восстановления гораздо проще – можно восстановить всю виртуальную машину на узле аварийного восстановления с помощью ранее созданных резервных копий ВМ. Это приводит к практически нулевому времени простоя.

Развернуть виртуальный сервер достаточно просто, отчасти поэтому их использование стало настолько распространенным. Вы можете сделать это самостоятельно или обратиться к специалистам облачного провайдера Cloud4Y. Мы предоставляем тестовый доступ, который позволит вам оценить возможности переноса рабочих нагрузок в виртуальную среду.

История

На заре развития компьютеры (или ЭВМ, электронно-вычислительные машины) были очень дорогим и штучным инструментом, позволить который могли себе только наиболее крупные институты и предприятия. Вычислительные ресурсы приходилось экономить всеми возможными способами. Первые разработчики писали код в режиме «офлайн» и передавали их оператору ЭВМ, который последовательно вводил программы в машину и производил расчеты. В начале 1960-х годов зародилась концепция разделения времени (time-sharing) – распределение вычислительных ресурсов между несколькими пользователями: пока один вводит данные, машина занимается расчетами других. Первые проекты с поддержкой данной концепции – Compatible Time-Sharing System (CTSS), Project MAC и предшественница ОС семейства Unix Multics – стали настоящим прорывом, однако они были небезопасными, сложными и, как следствие, не слишком стабильными.

В поисках путей решения проблемы оптимизации использования вычислительных ресурсов командой инженеров IBM был предложен новый подход – в рамках одной ЭВМ предоставить каждому пользователю виртуальную машину со своей ОС. Так в 1964 году появился проект CP-40, который позволил запускать несколько экземпляров клиентских ОС, например CMS. В 1967 году на основе проекта CP-40/CMS появилась CP-67/CMS – многопользовательская операционная система с разделением времени. CP-67/CMS работала на аппаратном мейнфрейме IBM System/360-67 и состояла из двух компонентов:

CP (Control Program)Программа управления виртуализацией (прообраз современного гипервизора).
CMS (Cambridge Monitor System)Одна из наиболее распространенных однопользовательских операционных систем для запуска в виртуальном окружении CP (клиентская, или гостевая, ОС).

Пользователи подключались к гостевым ОС с помощью специальных устройств ввода-вывода – терминалов.

Виртуализация обладала существенными преимуществами над концепцией разделения времени:

Увеличенные надежность и безопасность за счет изоляции пользователей.
Запуск любых приложений (не только приспособленных к концепции разделения времени) за счет симуляции отдельного компьютера для каждого пользователя.
Увеличенная производительность за счет использования легковесных гостевых ОС.

Шло время, компьютеры уменьшались в размерах и дешевели. В 1980-х годах x86 серверы и персональные компьютеры стали доступны для широкого спектра потребителей, вследствие чего мейнфреймы с виртуализацией и терминалами для многопользовательской работы ушли в прошлое. Однако технологии виртуализации продолжали развиваться и решать насущные проблемы. В 1988 году компания Insignia Solutions представила эмулятор программного обеспечения SoftPC, с помощью которого можно было запускать приложения MS DOS на рабочих станциях Unix, что стало своеобразным прорывом. В 1997 году компания Connectix создала программу Virtual PC для запуска под Mac ОС Windows. В 1999 году ныне всемирно известная компания VMware представила VMware Workstation, которая позволила запускать различные ОС в рамках виртуальных машин.

В начале 2000-х годов стали появляться продукты для серверной виртуализации. Эти решения дали возможность запускать несколько изолированных гостевых ОС в виртуальной среде на одном физическом сервере, что упрощало администрирование инфраструктуры, повышало ее отказоустойчивость и снижало простои серверного оборудования. Идея серверной виртуализации быстро набирала популярность. В 2001 году VMware представила ESX Server и GSX Server. В 2003 году Microsoft купила вышеупомянутую Connectix и перезапустила проект Virtual PC, ставший предшественником Microsoft Virtual Server и современного Microsoft Hyper-V). В 2007 году компанией Innotek был представлен VirtualBox. Также в 2007 году на рынок корпоративной виртуализации вышла компания Citrix, которая купила компанию XenSource и начала развивать проект с открытым исходным кодом Xen, предоставляя для клиентов коммерческую версию продукта Citrix XenServer (в настоящее время переименован в Citrix Hypervisor).

Напоследок стоит отметить, что помимо серверной виртуализации появлялись также продукты для виртуализации рабочих столов (новое воплощение той самой связки мейнфрейм-терминал из 1960-70 г.г.), приложений и др. Многие из этих решений активно развиваются и сегодня.

Читать подробнее:

Краткая история виртуализации, или Зачем вообще что-то делить
The History of Virtualization
History of Virtualization
With long history of virtualization behind it, IBM looks to the future

Сравнение гипервизоров и контейнеров

Чтобы заменить гипервизоры, начали применять технологию контейнеров. С ее помощью пользователь может размещать на вычислительной машине большее количество приложений.

Виртуальное оборудование подразумевает наличие большого объема оперативной памяти и мощного процессора, т.к. целиком копирует основную операционку и аппаратное обеспечение. Чтобы контейнер функционировал стабильно, хватит одной ОС, которая установлена на физическом носителе и совместима с ПО и библиотеками.

Но преимущества контейнеров не подразумевают вытеснения гипервизоров. Организации станут пользоваться комбинированным вариантом, состоящим из двух технологий. Стоит помнить, что контейнеры являются довольно опасными, поскольку при взломе операционки хакерами вся информация будет потеряна. С виртуальной техникой такое невозможно.

К популярным контейнерам относится модель OpenVZ, созданная на основе платформы Virtuozzo. Продукция отличается высоким уровнем производительности, использованием возможностей физической машины по максимуму благодаря высокой плотности расположения виртуальных копий хоста.

Рекомендуется присмотреться к модели Jailhouse. Запуск осуществляется через ОС Linux. При функционировании разработка образует в операционке независимые разделы для работы приложений пользователя.

Преимущества гипервизоров

Гипервизоры предоставляют корпоративным центрам обработки данных ряд преимуществ. Во-первых, способность физической хост-системы запускать несколько гостевых виртуальных машин может значительно улучшить использование базового оборудования. Если на физических (невиртуализированных) серверах может размещаться только одна ОС и одно приложение, гипервизор виртуализирует сервер, позволяя системе размещать несколько экземпляров виртуальных машин, каждый из которых работает с независимой ОС и приложением, в одной физической системе, используя гораздо больше доступных вычислительных ресурсов системы.

Виртуальные машины также очень мобильны. Абстракция, которая имеет место в гипервизоре, также делает виртуальную машину независимой от базового оборудования. Традиционное программное обеспечение может быть тесно связано с базовым серверным оборудованием – это означает, что перенос приложения на другой сервер требует длительной и подверженной ошибкам переустановки и перенастройки приложения. Для сравнения, гипервизор делает детали базового оборудования несущественными для виртуальных машин. Это позволяет перемещать или переносить виртуальные машины между любыми локальными или удаленными виртуализированными серверами – при наличии достаточных вычислительных ресурсов – практически по желанию с практически нулевым нарушением работы виртуальной машины; эту особенность часто называют живой миграцией.

Виртуальные машины также логически изолированы друг от друга, даже если они работают на одной физической машине. По сути, виртуальная машина не имеет собственных знаний или зависимости от других виртуальных машин. Ошибка, сбой или атака вредоносного ПО на одной виртуальной машине не распространяется на другие виртуальные машины на той же или других машинах. Это делает технологию гипервизора чрезвычайно безопасной.

Наконец, снимки файловой системы (снапшоты) позволяют мгновенно вернуть виртуальную машину в предыдущее состояние. Хотя снапшоты – или контрольные точки, как их называет Microsoft – не предназначены для использования в качестве замены резервных копий, они могут действовать как защитный механизм, особенно при выполнении обслуживания виртуальной машины. Если администратор собирается обновить ОС виртуальной машины, он может сделать снапшот перед выполнением обновления. В случае сбоя обновления администратор может восстановить моментальный снимок, чтобы мгновенно восстановить виртуальную машину в ее предыдущее состояние.

Таким образом, основные преимущества гипервизоров включают в себя:

Снижение затрат за счет лучшего использования оборудования.
Возможность быстро и легко перенести работающую виртуальную машину на другой хост, не отключая виртуальную машину.
Гипервизор без оболочки обеспечивает аппаратную изоляцию виртуальных машин. Злоумышленник не может использовать скомпрометированную виртуальную машину для атаки на соседнюю виртуальную машину – по крайней мере, не с помощью гипервизора.
Гипервизоры с чистым железом обычно включают в себя функцию моментальных снимков файловой системы, которая позволяет мгновенно восстанавливать виртуальные машины до предыдущего состояния без необходимости восстановления резервной копии.

Смогут ли контейнеры вытеснить классическую виртуализацию

Некоторые технические эксперты прогнозируют в ближайшее время полное вытеснение контейнерами виртуальных машин. Насколько такие утверждения обоснованы для корпоративных клиентов?

Работа с контейнерами позволяет использовать больше клиентских модулей, взаимодействующих с программными объектами, которые вынесены в виртуальную среду, чем вариант с виртуальными машинами. Это возможно благодаря тому, что оперативной памятью управляет базовая ОС, память не резервируется жёстко. В случае с виртуальной машиной тоже можно динамически распределять ресурсы памяти, но не так гибко, как с контейнерами.

Также использование контейнеров существенно сокращает время загрузки или перехода в активный режим: оно исчисляется секундами, а в случае виртуальных машин — минутами.

Контейнеризация упрощает настройку конфигурации: в какой среде велась разработка приложения, точно в такой же оно может дальше работать в продуктиве. Ещё одним преимуществом контейнеров является возможность отслеживания версионности приложения: в специальный раздел помещаются образы новых версий, и в случае проблемы можно легко вернуться к рабочему релизу.

Контейнеры удобны для упаковки и масштабного развертывания веб-приложений, они решают некоторые проблемы облачных услуг —например, обеспечивают многопользовательский доступ.

На текущий момент самая распространенная платформа контейнеризации — Docker. Сервис мониторинга Datalog собрал статистику, согласно которой на Docker чаще всего запускают RabbitMQ, nginx, Elasticsearch, PostgreSQL, Registry, MySQL, etcd, Fluentd, MongoDB и Redis.

Но кроме преимуществ, у контейнеров есть и серьезные недостатки, из-за которых корпоративные заказчики выбирают и ещё долго будут выбирать виртуализацию по модели IaaS.

Первое, с чем можно столкнуться при использовании контейнеров, — проблема «блуждающих ошибок», когда настройки ОС во время разработки и в готовой рабочей среде отличаются, а перенести все параметры идентично не всегда удаётся.

Вторая серьезная проблема — это безопасность. Если пользователь контейнера или само приложение обладает правами суперпользователя, то операционная система, на которой он размещён, может быть взломана. Приложения в контейнере, загруженные из интернета, могут содержать вирусы или трояны.

Третья проблема — качество услуги. Управлять большим числом контейнеров, выполняющих разные задачи, значительно сложнее, чем единственной виртуальной машиной, на которой выполняются все сервисы.

Четвертая проблема — совместимости: большинство контейнеров сделаны на Linux, поэтому запуск их в ОС Windows может быть очень сложным процессом.