9 лет проекту OpenVZ. Обзор участия Parallels в развитии открытых проектов
1 декабря 2014 года
В декабре исполняется 9 лет открытому проекту OpenVZ и 15 лет с момента создания компании Parallels, проделавшей огромную работу по развитию технологий изолированных контейнеров для Linux. В связи с данным событием публикуется интервью, в котором представители Parallels раскрыли некоторые подробности участия компании в разработке различных открытых проектов.
Parallels является одним из создателей индустрии контейнерной виртуализации, как развивались события и какие сегодня ставятся задачи?
Контейнерную виртуализацию серверов на уровне ОС мы делаем уже больше 15 лет, и именно благодаря ей наша компания (в те времена она называлась SWsoft) в самом начале своего существования быстро получила известность. В 2001 году Parallels выпустила Virtuozzo (Архивная копия от 23 декабря 2014 на Wayback Machine) - решение для контейнерной виртуализации, получившее большую популярность на рынке хостинга. Его версия с открытым исходным кодом известна под названием OpenVZ (Архивная копия от 28 июня 2014 на Wayback Machine). Как отдельный проект OpenVZ существует с 2005 года. В Parallels пытались делать и Virtuozzo для FreeBSD, но поняли, что это бесперcпективно, и проект свернули. В 2005 году была выпущена версия Virtuozzo для Windows.
Несколько лет назад по отчетам Linux Foundation компания входила в список разработчиков, вносящих наибольший вклад в код ядра Linux. Например, когда-то только по проекту OpenVZ у нас было сделано примерно 1700 патчей в основном ядре. Из последних событий Red Hat отметил Владимира Давыдова за обнаружение серьезных уязвимостей CVE-2014-0203 и CVE-2014-4483 в последнем обновлении ядра RHEL6 (вторая проблема, кстати, была найдена с помощью одного из наших автоматических тестов, использующих Linux Test Project). Василий Аверин получил благодарность за обнаружение ошибки CVE-2014-5045, Дмитрий Монахов – за CVE-2012-4508.
Контейнерный проект Parallels до сих пор – единственный коммерчески успешный в сфере виртуализации на операционных системах. А с проявлением интереса к контейнерам со стороны Google (большая плотность по сравнению с гипервизорами, высокая производительность и эластичный отклик при переконфигурировании системы под изменившуюся нагрузку для массового предоставления веб-сервисов) технология стала проникать и в корпоративный сегмент. Проект OpenVZ постоянно усовершенствуется, портируется на новые ядра. Компания добавляет функциональность, улучшает производительность и своевременно выпускает обновления, в том числе связанные с безопасностью. В данный момент мы сосредоточены на стабилизации ядра на базе RHEL7, которое довольно быстрыми темпами приближается к статусу beta.
Стоит сказать, что недавно у OpenVZ появилась официальная техподдержка от Parallels, а также возможность помочь проекту финансово.
Сегодня задача Parallels – включить технологии контейнерной виртуализации в мейнстрим Linux, чтобы фактически каждый в мире Linux-сервер получил возможность создавать контейнеры.
Какие технологии OpenVZ уже приняты в ядро Linux?
Проект OpenVZ, как часть контейнерных разработок компании, также подчинен задаче перенести всю его функциональность в ядро Linux, что на две трети уже реализовано. Сейчас в ядре есть PID, и network namespaces, и куски cgroups resource controllers, и NFS-виртуализация, и масса разнообразных фиксов. Реализовано расширение возможностей по управлению ресурсами контейнеров, «заморозка» состояния контейнеров и возобновление их работы с минимумом ядерных модификаций, живая миграция контейнеров с одного физического сервера на другой. И будем продолжать эту работу.
Почему? У нас взаимовыгодные отношения с OS-сообществом: мы создаём новые технологии, оттачиваем их на своих пользователях и отдаём в ядро. Зачем нам их отдавать? Раз в несколько лет изменения приходится переносить на новую кодовую базу, и эта не самая увлекательная работа отнимает большое количество времени.
Вторая причина в том, что кто-то другой может добавить идентичную функциональность, но в виде, не самом удобном для наших нужд. Надо понимать, что продвижение своего кода в ядро нередко выливается в долгие дискуссии с остальными разработчиками, и в итоге от первоначального патча не остается ничего. Однако в большинстве случаев удается сохранить функцию в виде удобном как для нас, так и для остального сообщества.
Имеет ли Parallels отношение к разработке инструментария LXС?
Мы часто слышим, что люди разделяют LXC и OpenVZ как проекты. Это печально, потому что команда, которая разрабатывает OpenVZ, активно разрабатывает и LXC, просто совместно с другими компаниями. И вклад людей из Parallels в LXC немаленький - больше половины кода написано нами, а что-то - только нами. Мы как разработчики только выигрываем от того, что контейнерами занимается еще кто-то (например, IBM и Google). Поэтому мы не противопоставляем LXC и OpenVZ. По сути, это взаимопроникающие вещи, просто LXC пока ещё в разработке (и не готов к промышленному использованию), а OpenVZ - готовое решение, надстройка над LXC.
В 2005 году компания Google искала способ эластичного масштабирования ресурсов: нужно было, чтобы каждый пользователь получал качественный веб-сервис в любой момент, независимо от текущей загрузки, а оставшиеся ресурсы можно было использовать для служебных фоновых задач. Сотрудники Google экспериментировали с традиционной виртуализацией, но отказались от ее применения. В то же самое время группа разработчиков работала с Linux и концепцией, основанной на механизме cgroups. В считанные месяцы Google наняла эту группу для работы над контейнеризацией своих дата-центров. В январе 2008 года часть технологии cgroup, используемой в Google, перешла в ядро Linux.
Так родился проект LXC (LinuX Containers). А приблизительно в это же время Parallels выпустила OpenVZ. В 2011-ом Google и Parallels пришли к соглашению о совместной работе над своими контейнерными технологиями. Результатом стал релиз ядра Linux версии 3.8 в 2013 году, в котором были объединены все актуальные на тот момент контейнерные технологии для Linux, что позволило избежать повторения болезненного разделения ядер KVM и Xen.
CRIU уже может делать живую миграцию контейнеров?
CRIU – проект, который также родился в процессе взаимодействия «ядерной» команды Parallels с сообществом разработчиков ядра Linux. Это технология, которая умеет снимать состояние выполняющихся в Linux процессов и восстанавливать эти процессы в другом месте или в другое время из полученных данных (технология checkpoint/restore, или так называемая «заморозка»). Более того, это первая в истории реализация технологии snapshot-а приложений, которая работает на немодифицированной ОС (ядро + системные библиотеки) Linux (например, доступна в Fedora, начиная с 19-й версии) и поддерживает любые состояния процессов. Проекты такого рода были и раньше, но у них были недостатки – либо нужно было брать особое ядро, подкручивать системные библиотеки, либо существовали ограничения на то, какое состояния поддерживалось.
Первая реализация checkpoint/restore от Parallels появилась в 2005 году, и поддерживала контейнеры OpenVZ и Virtuozzo. Написал её легендарный Алексей Кузнецов – создатель 90% стека TCP/IP в Linux. Уже тогда мы попытались привнести ее в апстримное ядро, но не преуспели. Следующую такую попытку, куда более настойчивую, чем наша, предпринял уже Орен Лаадан (Oren Laadan) в 2008-ом. Он предложил более универсальную версию реализации в ядре, но сообщество не горело большим желанием принимать настолько сложный код, и попытка снова не удалась. Тогда в 2011 году руководитель группы разработчиков Parallels Server Virtualization Павел Емельянов решил пойти другим путём - когда большая часть логики реализуется в пространстве пользователя, а модификации ядра минимальны. Так родился проект CRIU (Checkpoint/Restore [mostly] In Userspace). Осенью 2013 года был анонсирован первый крупный релиз проекта – CRIU 1.0, а в сентябре 2014 вышла версия 1.3, с помощью которой, в числе прочих, можно делать крайне важную для всего рынка вещь - живую миграцию контейнеров, включая Docker и LXC. Этого мы добились благодаря другому проекту - P.Haul, который надстраивается над CRIU и реализует живую миграцию.
Как проект CRIU создавался не благодаря, а вопреки: например, компания VMware заявила, что нужно использовать vmotion для миграции контейнеров, потому что у них нет собственных возможностей сделать это. Эндрю Мортон также скептически выразился о живой миграции и Userspace: «Это проект, разрабатываемый разными сумасшедшими россиянами, по созданию контрольных точек и рестарта с них в основном из пользовательского приложения, с различным странным вспомогательным кодом, добавленным в ядро там, где показана такая необходимость. Однако, я не так, как разработчики, уверен в том, что всё это когда-нибудь заработает! Поэтому я прошу их „обернуть“ макросом CONFIG_CHECKPOINT_RESTORE каждый кусок нового кода в ядре. Если со временем всё это закончится слезами, и проект в целом развалится, то будет простой задачей - пройтись по коду и выкинуть всё без следа». Сегодня CRIU - стандарт реализации checkpoint/restore в Linux, которому помогают другие разработчики, в частности, из Google и Canonical принимают активное участие в обсуждении поддержки cgroup в CRIU и успешно используют CRIU с утилитами Docker и LXC.
Зачем это нужно нам? У технологии масса применений: помимо миграции «на лету» - еще и ускорение старта «толстых» приложений, обновление ядра без перезагрузки, балансирование нагрузки, сохранение состояния задачи на случай падения системы. А для чего это самому сообществу? Сценариев использования несколько, в том числе балансировка сетевой нагрузки, анализ поведения приложений на другой машине, дупликация процессов и так далее.
Каково взаимоотношение Parallels с проектом Docker?
Docker - не конкурент, а партнер по системным библиотекам. Нам иногда задают странные вопросы о том, к чему привела наша конкуренция с компанией Docker, которая также занимается контейнерами. Мы считаем их странными потому, что существующие контейнерные проекты на рынке не находятся в состоянии конкуренции. Долгое время разные контейнерные проекты (например, OpenVZ, LXC, Docker) сосуществовали скорее параллельно, предлагая пользователям одинаковую по сути, но разную в реализации и деталях технологию. Но облака продолжают бурно развиваться и популярность контейнеров растет вместе с ними. И разработчики технологий контейнерной виртуализации объединяются, чтобы решать свои задачи.
Так, вместе мы работаем над проектами системных библиотек, предоставляющих интерфейс к ядерным контейнерным компонентам. Это, во-первых, начатый Docker проект Libcontainer, в который в данный момент влились Parallels, Canonical, Google и RedHat, договорившись о его совместном развитии. Во-вторых - libct, библиотека, работа над которой начата нашим коллегой Павлом Емельяновым, развитию которой сейчас помогают инженеры Docker, LXC и Google. В частности, мы работаем над поддержкой Docker OpenVZ ядра (бэкенд в libct) и внутри OpenVZ контейнера. Цели у обоих этих проектов одинаковые - стандартизировать работу Docker с ядром Linux и привязать к основным языкам программирования, и за счет этого - расширить количество сценариев использования для контейнеров в индустрии.
Эти библиотеки необходимы, так как в ядре не существует такого понятия как "контейнер". Говоря о контейнерах, разработчики ядра подразумевают несколько разных подсистем ядра, которые позволяют, при правильном использовании, изолировать приложения в виртуальных средах. Это, главным образом, cgroups и namespaces. Прямое использование ядерных интерфейсов возможно, но весьма нетривиально. Библиотеки призваны облегчить процедуру их использования, предоставив программистам интерфейс, в котором есть более привычные понятия: "контейнер", "вычислительные ресурсы", "виртуальная сеть" и т.п.
Вторая причина необходимости совместного развития – это возможность интегрировать контейнеры еще и с платформой по разворачиванию и управлению облачной инфраструктурой - OpenStack. До сих пор OpenStack работал только с виртуальными машинами, но в последнее время сообщество разработчиков всё чаще думает, что неплохо было бы создавать контейнеры и в облаках, управляемых OpenStack. Уже было предпринято несколько попыток достичь этого - RackSpace разработал расширение на основе контейнеров OpenVZ, но это решение не было принято сообществом. Docker предоставил расширение, основанное на своей технологии, но и оно не закрепилось в проекте.
В качестве дальнейшего развития разработчики Parallels, Docker, Canonical и, возможно, RackSpace попробуют привнести контейнеры в OpenStack через Libcontainer.
Заинтересована ли компания Parallels в развитии платформы OpenStack?
Очень неплохой пример сотрудничества с OpenStack - наше решение Parallels Cloud Server (Архивная копия от 7 марта 2015 на Wayback Machine) (единственный в мире продукт, который объединяет контейнерную и гипервизорную виртуализацию с распределенной облачной системой хранения данных). Интеграция с OpenStack поддерживается с помощью разработанного Parallels отдельного плагина для OpenStack Nova.
Участвует ли компания Parallels в разработке технологий виртуализации?
Мы принимаем участие в кроссплатформенной библиотеке управления виртуализацией libvirt, организованной Red Hat. Туда мы добавили поддержку вышеупомянутого продукта Parallels Cloud Server и OpenVZ.
В каких других проектах с открытым кодом участвует Parallels?
Parallels является одним из контрибуторов Wine. Наш коллега Константин Назаров – автор Python-модуля для artifactory, Павел Юдин контрибьютит в Chef. Иногда это приводит к появлению самостоятельных OpenSource-проектов, как это произошло с открытым бесплатным плагином для Vagrant (средство управления виртуальными машинами, которое позволяет разработчикам неплохо сэкономить время и силы на поддержке рабочего окружения и синхронизации с коллегами).
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
