9 лет проекту OpenVZ. Обзор участия Parallels в развитии открытых проектов
В декабре исполняется 9 лет открытому проекту OpenVZ и 15 лет с момента создания компании Parallels, проделавшей огромную работу по развитию технологий изолированных контейнеров для Linux. В связи с данным событием публикуется интервью, в котором представители Parallels раскрыли некоторые подробности участия компании в разработке различных открытых проектов. Parallels является одним из создателей индустрии контейнерной виртуализации, как развивались события и какие сегодня ставятся задачи?
Контейнерную виртуализацию серверов на уровне ОС мы делаем уже больше 15 лет, и именно благодаря ей наша компания (в те времена она называлась SWsoft) в самом начале своего существования быстро получила известность. В 2001 году Parallels выпустила Virtuozzo — решение для контейнерной виртуализации, получившее большую популярность на рынке хостинга. Его версия с открытым исходным кодом известна под названием OpenVZ. Как отдельный проект 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 (единственный в мире продукт, который объединяет контейнерную и гипервизорную виртуализацию с распределенной облачной системой хранения данных). Интеграция с OpenStack поддерживается с помощью разработанного Parallels отдельного плагина для OpenStack Nova.
Участвует ли компания Parallels в разработке технологий виртуализации?
Мы принимаем участие в кроссплатформенной библиотеке управления виртуализацией libvirt, организованной Red Hat. Туда мы добавили поддержку вышеупомянутого продукта Parallels Cloud Server и OpenVZ.
В каких других проектах с открытым кодом участвует Parallels?
Parallels является одним из контрибуторов Wine. Наш коллега Константин Назаров — автор Python-модуля для artifactory, Павел Юдин контрибьютит в Chef. Иногда это приводит к появлению самостоятельных OpenSource-проектов, как это произошло с открытым бесплатным плагином для Vagrant (средство управления виртуальными машинами, которое позволяет разработчикам неплохо сэкономить время и силы на поддержке рабочего окружения и синхронизации с коллегами).
Полный текст статьи читайте на OpenNet
