Современные технологии Virtuozzo | Интервью с Павлом Емельяновым
THG.ru: Существуют ли какие-то особые предпочтения у заказчиков по продуктам серверной виртуализации Virtuozzo для разных платформ?
П. Емельянов: Основной контингент наших заказчиков – это хостинг-провайдеры. Сейчас ситуация несколько меняется, но исторически сложилось так, что большая часть этих заказчиков не является представителями так называемого Enterprise – то есть, в основном, они обладают достаточно скромными бюджетами и пытаются экономить там, где это возможно. Ориентируясь на таких заказчиков, мы не могли выставлять большую цену на свои продукты. В то же время, набор возможностей, востребованный такими покупателями, достаточно широк и разнообразен по той причине, что каждому из них нужна разная функциональность. Каждый хостинг-провайдер в противостоянии с десятками своих конкурентов желает предоставлять какие-то особые возможности своим клиентам, и создание всего этого разнообразия было нашей задачей.
Получаемый в итоге достаточно огромный список функций при неизменно невысокой цене обусловил выпуск подавляющей части продуктов на Linux и Open Source. Опираясь изначально на некое базовое ядро продукта, далее заказчики высказывают свои предпочтения – ту или иную файловую систему, принципы и настройки резервного копирования и так далее.
Заказчики – особенно крупные хостинг-провайдеры, со своей стороны также не рассматривают Virtuozzo как законченный “продукт из коробки” и зачастую применяют его вместе с собственным наработками как один из компонентов.
Подход с использованием ядра базовой платформы и дальнейшей его кастомизацией надстройками под нужды каждого отдельного заказчика устраивает всех, в ином случае охватить все запросы было бы просто нереально.
THG.ru: Кто из крупных хостинг-провайдеров использует продукты Virtuozzo?
П. Емельянов: Наши продукты использует, например, крупнейший американский хостинг-провайдер GoDaddy. Среди известных компаний, использующих OpenVZ, можно упомянуть OpenWorx, студии Pixar Animation, Wargaming.net и Yandex.
THG.ru: Можно ли назвать контейнерную виртуализацию технологией для специфических нишевых разработок или всё же это нечто большее?
П. Емельянов: В последние пару лет значительным образом поменялось само определение “контейнера”. Когда компания Virtuozzo только начинала свою работу, о контейнерах как таковых ещё не говорили, вместо этого использовали термин “виртуальные среды”, симметричный “виртуальным машинам”. Позже, когда технология вышла за рамки нашей компании и мы начали интегрировать её в основную ветку Linux-ядра, возник термин “контейнеры”, поскольку “виртуальными средами” почему-то никому называть её не нравилось.
Затем появился проект Docker, который на базе этой технологии построил довольно мощный инструментарий по подготовке приложений для размещения контейнеров. Таким образом, “контейнерами” начали называть всю технологию – и виртуализацию, и способ запаковать и запустить приложение внутри этой виртуализации.
Со временем базовый слой этой виртуализации стал привычным и на общем фоне вполне привычным, поскольку развитие проекта Docker оказалось достаточно масштабным, так что сейчас под “контейнерами” подразумевают только способ запаковки и запуска приложений, совершенно неважно в какой виртуальной среде – он все равно остается контейнером.
Есть, например, проекты, запускающие приложения внутри гипервизора – по сути, в виртуальной машине. С точки зрения виртуализации – это VM, но по сути это контейнер, в котором запаковано приложение.
В этом плане контейнерная виртуализация – это технология низкоуровневой изоляции приложения или дистрибутива. Да, действительно, сейчас она уходит в ниши. Какое-то время назад это была отдельная технология, успешно конкурировавшая с виртуальными машинами. Десяток лет назад разница между запуском VM и контейнеров при одинаковом времени отклика на схожем “железе” составляла 2-3 раза. Со временем разница очень сильно сократилась – частично благодаря усилиям компании Intel, которая обеспечила аппаратную поддержку, частично благодаря разработчикам гипервизорных технологий, и сейчас, если измерить время отклика, задержки или скорость работы, VM работают медленнее контейнеров лишь на десятки процентов – 10-20%, в редких случаях 30%, во всём остальном они практически уже сравнялись.
В то же время, с точки зрения удобства использования, виртуальные машины обеспечивают больше, чем контейнеры, поскольку для контейнерной виртуализации, по сути, нужно взять всё ядро и “обучить” каждую подсистему разделению прав доступа между приложениями. Запуская приложение внутри контейнера, пользователь зачастую сталкивается с невозможностью реализации каких-то функций, или с нежелательностью их использования для сохранения целостности системы. В виртуальных машинах с точки зрения безопасности ядра таких проблем нет: если одна виртуальная машина сломается, остальные останутся нетронутыми, и ядро при этом никак не пострадает.
THG.ru: Каким образом можно повредить ядро изнутри контейнера?
П. Емельянов: При наличии уязвимости в ядре и если упакованный в контейнере софт умудряется до неё дотянуться – да, действительно, он может сломать весь хост, все контейнеры, есть такая проблема безопасности. Одним из достоинств Virtuozzo как раз является то, что мы внимательно следим за такими вопросами безопасности, и для любых ядер Linux, которые пользователи ставят с продуктами Virtuozzo, все такие проблемы известны и заведомо закрыты.
Фундаментальная проблема заключается в том, что при запуске софта в VM соблюдается максимальная изоляция, и так называемая “площадь атаки” (Attack surface) очень мала и, по сути, захватывает только гипервизор, в то время как при запуске софта в контейнере площадь атаки большая и составляет весь ядерный потенциал, который ему разрешено использовать. Это можно лечить, затыкать дыры, но фундаментальная проблема от этого никуда не уйдёт.
Именно поэтому постепенно отмирает практика использования системных контейнеров – мы называем их также “контейнеры общего назначения”, внутри которых запускаются дистрибутивы: проще, гибче и безопаснее сделать это в VM, тем более что по скорости выигрыша почти нет.
Другое дело, когда речь заходит о специфическом использовании контейнеров. Самый распространённый пример, который у всех на слуху – это достаточно большой рынок решений NFV (Network Functions Virtualization) — специализированного софта по виртуализационному управлению сетями в общем смысле, с разветвленной топологией, балансировщиками, сложными файрволлами. Сейчас принцип NFV реализуют в виде небольших “операционных систем”, которые, например, можно поставить даже на отдельный физический сервер и через него маршрутизировать весь трафик с любыми настройками функций. Производители таких “сетевых дистрибутивов” часто переносят их в виртуальные машины, однако если вместо них использовать контейнеры с заведомо решёнными вопросами безопасности, можно получить прирост в производительности: 10-20% рост скорости или снижения задержек для современных сетевых решений является существенным выигрышем, и за него стоит бороться.
NFV – это лишь один из многочисленных примеров выгодного использования контейнерной виртуализации. Не менее популярны сегодня, например, сервисы для бэкапов на базе контейнерной виртуализации. Широко также представлен проект OpenStack, предлагающий контейнерный запуск многочисленных сервисов для управления процессами в дата-центрах.
Трудно предсказать, будут ли контейнеры когда-нибудь вытеснены виртуальными машинами из таких приложений, но, по крайней мере, не в обозримой перспективе.
THG.ru: Как можно описать место контейнеров в общей ИТ-экосистеме?
П. Емельянов: Docker определяет понятие “контейнер” как запакованное приложение, готовое к запуску в любой среде. Virtuozzo подходит к контейнеру несколько иначе, запуская в гостевом режиме целый дистрибутив – своего рода лёгкую виртуальную машину. Однако и тот и другой подход требует адаптации прочих элементов ИТ-экосистемы для свободной работы с контейнерами.
Пользователи хотят получить возможность работать с приложением, независимо от того, кто это приложение создал, от каналов его распространения, от платформы и других параметров. Заказчик вообще не хочет думать о том, как это всё работает. Поэтому отрасль постепенно приходит к пониманию, что необходимо распространять контейнеры в виде готовых продуктов – как пирожки с повидлом. Ведь нам без разницы, где их испекли и на каком автомобиле привезли в ближайший киоск.
THG.ru: Расскажите о текущей ситуации по стандартизации технологий для работы с контейнерами.
П. Емельянов: Работа проекта Open Containers Initiative (OCI) стартовала в начале 2016 года. Сейчас в OCI входят десятки ведущих компаний отрасли, включая Amazon, AT&T, Cisco, Dell EMC, Facebook, Fujitsu, Goldman Sachs, Google, HPE, Huawei, IBM, Intel, Microsoft, Red Hat, Suse, Virtuozzo, VMVare и другие.
Глубинная суть проекта состоит в том, чтобы обеспечить возможность прямого взаимодействия разработчиков, магазинов и провайдеров платформ для запуска приложений. Разработчиков существует огромное множество. В роли магазинов могут выступать DockerHub, Quay, Bitnami, RedHat, а потенциальные платформы для запуска контейнеров предлагают Docker, CoreOS, Virtuozzo, LXC, OpenShift, Magnum и другие.
В результате роль OCI заключается в том, чтобы дать возможность этим решениям взаимодействовать с использованием единого стандарта.
Первой целью проекта была назначена разработка двух стандартов. Первый из них – стандарт по запуску контейнеров, в нем описываются требования к определенному интерфейсу, который должна предоставлять платформа для запуска контейнеров с приложениями приложений. За основу этого стандарта – Application Container spec (appc) де факто была взята послойная запаковка контейнеров Docker v2.
Этот стандарт был представлен летом и сейчас переживает уже не первую ревизию. Второй стандарт, выпущенный позже, описывает характеристики распространения контейнеров. Этот стандарт также готов, но его делали уже не из разработок Docker, а на основе схожего проекта CoreOS. В свое время проект CoreOS стартовал в качестве платформы для запуска контейнеров Docker, но позже их не устроил способ описания упаковки контейнеров Docker, и они выпустили свой, более продвинутый вариант с подписями для верификации и другими функциональными возможностями. Именно поэтому в OCI приняли решение взять за основу стандарта распространения контейнеров более гибкие наработки CoreOS.
Помимо разработки стандартов, инициатива OCI также разработала ряд референсных утилит, гарантированно поддерживающих принятые стандарты. Таким образом, любая платформа контейнерной виртуализации, претендующая на совместимость со стандартами OCI, имеет возможность пройти сертификационные процедуры и подтвердить эту совместимость на практике.
THG.ru: Каков вклад Virtuozzo в деятельность OCI?
П. Емельянов: Наш вклад, возможно, не такой глубокий как хотелось бы, но тем не менее участие мы принимаем. В разработке самих стандартов Virtuozzo участие не принимала, но внутри OCI существует собственный надзорный орган (Technical Oversight Board, TOB) для координации всех действий проекта. Численность этого надзорного органа составляет 10 представителей от разных компаний, и в 2016 году одним из участников этого совета довелось стать мне.
Virtuozzo планирует присоединиться к максимальному количеству технических комитетов, которые будут разрабатывать стандарты взаимодействия контейнеров.
Но уже сейчас в рамках OCI наши специалисты участвуют в доработках ядра Linux, позволяющих расширить функционал технологий контейнерной виртуализации. В рамках этой инициативы происходит массовое исправление ошибок, а также внедрение дополнительных библиотек для таких проектов как KVM, CRIU, Ploop и т.д.
Кстати, коллективная работа позволяет совместно с другими группами вести такие проекты как расширение функционала KVM и поддержка Hyper-V для гостевых машин с Windows. В проекте qemu мы совместными силами внедряем технологии резервного копирования и поддержку plop. Для контейнеров Docker происходит интеграция с нашим инструментом “живой миграции” CRIU. И это только начало – впереди нас ждёт значительно больше новых комьюнити и совместных инициатив.
Тем не менее, открытость стандартов несёт в себе как преимущества, так и недостатки. В частности, нужно приложить немало усилий, чтобы создать единую экосистему, способную учитывать мнения и объединять усилия разработчиков из разных компаний. Но если это не чья-то коммерческая инициатива, нам нужно самостоятельно организоваться и договориться о стандартах и форматах совместной работы.
Роль таких ассоциаций, как Open Container Initiative (OCI), сводится к созданию открытого “клуба”, который будет направлять развитие отрасли, создавая единые отраслевые стандарты для различных контейнерных технологий.
THG.ru: Каким образом формируется структура OCI?
П. Емельянов: Open Container Initiative создает двухуровневую модель взаимодействия разработчиков. С одной стороны, существуют сообщества Technical Developer Community (TDC), которые непосредственно разрабатывают стандарты, обсуждая и описывая их в режиме “открытого сообщества”. На начальном этапе создано два сообщества, но ожидается, что их будет очень много, так как областей, требующих введения единого стандарта, появляется всё больше.
Надзорный орган – Technical Oversight Board (TOB), членом которого я являюсь, представлен экспертами отрасли и занимается формированием сообщества TDC, даёт начальные рекомендации и координирует их работу. Примечательно, что TOB состоит из отдельных экспертов, компании же работают на уровне технических сообществ.
На данный момент активно работает TDC по стандарту запуска контейнера (основные участники – Docker, RedHat, CoreOS, Google) и по формату распространения и хранения (основные участники – Docker, Google, RedHat, CoreOS и Huawei). Первые шаги уже сделаны, и TOB рекомендует в качестве базового использовать формат AppC принятый в Rocket, который почти полностью поддержан в RunC (утилита командной строки) и ContainerD (демон, предоставляющий REST интерфейс к RunC).
Современные технологии Virtuozzo | Интервью с Павлом Емельяновым (окончание)
THG.ru: В чём основные отличия технологии Virtuozzo/OpenVZ от технологии Docker?
П. Емельянов: Изначально проект Docker развивался в качестве надстройки на OpenVZ. Когда они написали первую версию своего проекта, они основывались на OpenVZ – платформе для контейнеров в ещё том “старом смысле” – для запуска виртуальных сред, а что в них запускать было неважно.
В Docker решили на этом не останавливаться и вышли на новый уровень – представили контейнеры с готовым набором инструментов-утилит внутри контейнера – так называемых “шаблонов”, с помощью которых создавалась внутренняя среда. Кроме того, они очень красиво решили проблему создания нескольких контейнеров со схожим содержимым. Например, при задаче запуска нескольких сред с Ubuntu они избавились от необходимости её копирования в несколько контейнеров: послойный подход как раз стал изящным решением этого вопроса.
Получилось, что изначально была платформа OpenVZ для создания контейнеров в качестве виртуальных сред, а сверху можно было поставить Docker для создания контейнеров уже для запуска приложений, запакованных их способом.
При дальнейшем развитии проекта в Docker решили, что ядра Linux, проверенные на совместимость с OpenVZ, для них уже “староваты”, и поэтому переключились на сотрудничество с LXC, которой по большому счёту всё равно, с какой версией ядра работать.
Через какое-то время им не стало хватать даже возможностей LXC, поэтому они написали свой собственный нижний уровень, который впоследствии переродился в проект RunC.
Таким образом, если сравнивать нас и Docker, то на самом деле конкурентом для Virtuozzo в каком-то смысле выступает проект RunC как способ создания виртуальных сред. Но поскольку RunC является своеобразным “отдельным винтиком” в составе Docker, и отдельно им никто не пользуется, говорить о прямой конкуренции не стоит. Тем более, что в нашем проекте есть бэкап, “живая миграция” и другие инструменты, которых в Docker пока нет. Точнее будет назвать нас не конкурентами, а несколько разными технологиями для различных рынков и приложений, со временем разошедшимися от единой концепции.
У нас есть в планах развития идея поддержать Docker. Дело в том, что современные заказчики – те же хостинг-провайдеры, начинают смотреть в сторону продаж клиентам не виртуальных серверов, а готовых приложений. Чтобы хостер мог предложить клиенту не виртуальный сервер для последующей установки приложений, а сразу взять уровень выше и предложить заказчику, например, сразу готовый работающий WordPress. Это как раз вотчина Docker. С большой долей вероятности такая возможность появится уже в Virtuozzo 8.
THG.ru: Расскажите о преимуществах вашего нового продукта Virtuozzo Storage for Docker.
П. Емельянов: Virtuozzo Storage for Docker – это, скорее, не отдельный продукт под Docker, а некий способ сохранить текущее или промежуточное состояние работающего в контейнере софта. Docker изначально озаботился о такой функциональности, предусмотрев подключение так называемых внешних “томов” для хранения данных. Docker умеет подключать тома не только на NFS, но и на самых различных распределённых файловых системах, включая Lustre и Ceph.
В Virtuozzo тоже есть свое распределённое хранилище. Про него тоже можно долго рассказывать, но суть в том, что оно отличается от того же популярного Ceph. Таким образом, мы просто взяли и написали вот такое расширение-плагин для Docker, которое позволяет подключить том с нашего хранилища к Docker.
Если же говорить о преимуществах систем распределённого хранения, сейчас их все модно сравнивать с функциональностью Ceph. И в этом плане преимущества Virtuozzo Storage вытекают из задач, поставленных при его создании. Поскольку мы изначально исходили из того, что во внешних файлах будут храниться данные отдельных виртуальных машин, первая задача – это требование записывать данные в хранилище в отдельный файл только с одного физического сервера. То есть, это в каком-то смысле даже облегчение функций хранилища. В Ceph, который представляет собой хранилище общего назначения, такого “облегчения” нет, и одновременный доступ на запись в один файл из нескольких источников поддерживается в обязательном порядке.
Второе “облегчение” состоит в том, что эти внешние файлы – это виртуальные диски хранения данных виртуальных машин, они будут огромными, и их метаданные, скорее всего, меняться не будут: возможно, будет расти размер, но не эти самые метаданные. Именно поэтому вся внутренняя логика раскладывания блоков и элементов этих файлов, и их синхронизация друг с другом при необходимости, устроена таким образом, что при записи данных идет максимально быстрое обслуживание, а запись метаданных может и обождать. Например, если сравнивать такие операции, как смена прав, переименование, создание нового файла, изменение его размера, то при таких операциях Ceph работает быстрее. Если же необходимо просто писать или читать файл, то здесь за счёт другого принципа синхронизации преимущество по скорости уже будет за Virtuozzo Storage.
THG.ru: Какие аппаратные ресурсы – процессоры, память, устройства хранения, наиболее критичны для производительности Virtuozzo?
П. Емельянов: И вновь здесь нет однозначного ответа, поскольку результат в значительной степени зависит от области использования продукта. Скажем, у хостинг-провайдеров наиболее критичным является как объём оперативной памяти, так и тип используемых накопителей. Сам характер нагрузки хостинга многочисленными виртуальными машинами подразумевает множество одновременных операций чтения/записи на один и тот же физический накопитель, и это именно тот случай, с которым классические жёсткие диски – “винчестеры”, справляются хуже флеш-накопителей.
Для компаний, сфокусированных на вычислениях – например, на аналитике больших данных, наиболее критичными узлами являются процессоры. Для хостера, например, 1% разницы в скорости работы гипервизора просто незаметен, но для аналитики данных это очень критично.
THG.ru: Есть ли недостатки у Virtuozzo 7 по сравнению с предложениями конкурентов?
П. Емельянов: С технологической точки зрения он затрагивает сегодняшний нелёгкий период в жизни в нашей компании. Дело в том, что Virtuozzo всегда был продуктом для одного сервера. Клиент ставил виртуальные среды на один сервер, и у него всё получалось отлично, и быстрее чем у конкурентов. На практике всё чаще приходится управлять не одним, а несколькими серверами, и раньше эти потребности закрывались подразделением Parallels, которое называлось Automation – такими продуктами, как Plesk и подобными. Они как раз закрывали вопросы управления кластерными системами.
После отделения от Parallels компания Virtuozzo осталась со своим продуктом для одного сервера, и поддержки кластеров, как это ни печально, у нас сейчас нет. Мы сейчас активно работаем в этом направлении, но на сегодняшний день готовой поддержки этой функциональности Virtuozzo не представляет.
THG.ru: Теперь давайте о хорошем: какие преимущества для крупных дата-центров предлагает Virtuozzo 7 по сравнению с предыдущими версиями и предложениями конкурентов?
П. Емельянов: Кроме контейнеров, мы предлагаем виртуальные машины, и в Virtuozzo 6 они были построены на базе гипервизора, который достался нам от Parallels. В новой версии Virtuozzo 7 мы перешли на более удобный гипервизор KVM, который мы ещё и доработали под свои задачи.
Ещё одно серьёзное преимущество Virtuozzo 7 заключается в более простой интеграции. Раньше у Virtuozzo был свой собственный API для интеграции, и с ним интегрироваться было сложнее по той причине, что кроме нас его никто не поддерживал. Сейчас для работы с Virtuozzo 7 используется стандартный интерфейс LibVirt. Если проект поддерживает LibVirt, он также с лёгкостью будет работать с Virtuozzo.
Благодаря этому мы сразу получили очень много плюсов. Например, можно развернуть OpenStack, и запущенные вычислительные машины заменить на виртуальные – всё продолжит работать, но уже на базе Virtuozzo.
Преимущества непосредственно Virtuozzoперед другими проектами заключается в том, что основное его назначение – платформа для запуск виртуальных сред. Мы следим за стабильностью с этой точки зрения, за безопасностью именно в плане процессов виртуализации – а не в общем плане, как практикуется у конкурентов.
Наконец, наш конёк, отшлифованный и доведённый до совершенства в Virtuozzo 7 – это резервное копирование виртуальных машин. В нынешней версии он стабилен, но самое главное, что в том же OpenStack нет аналогичных инструментов для бэкапа.
