«Разработка Ядра Linux Похожа На Общение В Клубе По Интересам»

Наш архитектор отдела виртуализации серверов Павел Емельянов дал интервью журналу «Системный администратор».

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

«Разработка ядра Linux похожа на общение в клубе по интересам»

Расскажите, пожалуйста, чем вы занимаетесь в Parallels? Я работаю над основным серверным продуктом Parallels под названием Cloud Server. Это специально подготовленный для запуска виртуальных машин и контейнеров дистрибутив Linux, который аккуратно интегрирован с большим количеством дополнительных приложений от Parallels — управление кластером, распределенное хранилище, веб-панели и тому подобное.

Этот продукт является многокомпонентным; ее компоненты иногда сами по себе являются очень сложными системами.

Чем я занимаюсь, так это проектирую многие из этих систем, в основном связанные с ядром, их внутренней структурой, логикой работы и взаимодействием друг с другом.

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

Я слежу за этой деятельностью и стараюсь направить ее в нужное для компании русло.

Сегодня мое любимое занятие — разработка проекта CRIU, который стал результатом нашей работы с сообществом Linux. Это приложение, которое может снимать состояние процессов, запущенных в Linux, и восстанавливать эти процессы в другом месте или в другое время на основе полученных данных.

Как появился проект ЦРИУ? Что именно послужило толчком к его созданию? Проект возник как решение для интеграции кода контейнера Parallels в ядро Linux. Да и сама интеграция — это тоже интересная история, о которой я уже говорил.

Через несколько лет после запуска проекта OpenVZ в Parallels поняли, что самостоятельно поддерживать все изменения, внесенные в ядро, будет очень сложно.

Мы решили начать перенос кода ядра нашего контейнера в ядро Linux и представить эти изменения сообществу с просьбой принять их.

Я тогда был всего лишь разработчиком, и выбор «кто пришлет» пал на меня.

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

За пару лет нам удалось интегрировать около половины всего функционала ядра, который был у Parallels, но тот код, который у нас был для «живой миграции» контейнеров, не был взят в ядро Linux. Более того, не только мы пытались, другие компании тоже хотели иметь подобный функционал, но сообщество не пришло к единому решению «бери».

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

Первый прототип был написан примерно за три дня дома, пока я был на больничном.

Я отправил его сообществу «посмотреть».

Люди посмотрели и.

решили, что внесут те небольшие изменения в ядро, которые мне были нужны (эти изменения окончательно воплотились в ядре Linux через пару месяцев).

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

Кто и где использует CRIU? Что касается применимости, то сейчас проект находится в «переходном возрасте».

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

Например, мне уже прислали исправления и дополнения люди из Samsung, Huawei и даже недавно из самого Google. А раз прислали, значит, с этим пытаются что-то сделать.

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

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

Сколько разработчиков работает над проектом CRIU? Сложный вопрос.

Пока что с проектом активно и регулярно что-то делают три человека, в том числе и я.

Еще есть около десятка людей, которые «помогают», время от времени присылая сообщения об ошибках, иногда с исправлениями, спрашивая, сможет ли проект сделать то-то и то-то, тем самым давая нам новые идеи.

А еще и эта сторона — мы периодически что-то меняем в ядре и отправляем эти изменения сообществу, таким образом неявно вовлекая в процесс людей из него.

Что нового стоит ожидать от ЦРИУ в ближайших релизах? Какой функционал планируется добавить в проект в будущем? О, самое важное, что произойдет с CRIU в ближайшем будущем, это то, что вся необходимая поддержка ядра появится в ядре 3.11. Если кто-то захочет использовать CRIU «на полную катушку», ему не придется компилировать и устанавливать нестандартное ядро.

Кроме того, по данным секретной разведки, следующая версия дистрибутива Red Hat, получившая название RHEL7, будет основана на 3.11, то есть вполне вероятно, что CRIU сразу же будет работать над одним из самых популярных дистрибутивов Linux. Что будет дальше с проектом, мне очень интересно.

Дело в том, что возможности, которые способен предоставить CRIU, выходят за рамки интересов Parallels. Но кто и когда их будет реализовывать? Мой план — создать вокруг CRIU сообщество, подобное тому, которое построено вокруг ядра Linux, чтобы проект разрабатывали не несколько человек из Parallels, а более разнообразная и многочисленная группа разработчиков.

Вы сказали, что вся необходимая поддержка CRIU будет в ядре 3.11. Чего сегодня не хватает в ядре для полной поддержки CRIU? Если взять самое «свежее» на сегодня ядро 3.10, то здесь не хватает двух вещей.

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

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

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

Вторая часть немного меньше, но в чем-то гораздо важнее первой.

Это небольшое расширение подсистемы отладки процессов, которое позволяет вам контролировать, как процессы обрабатывают сигналы.

Без него невозможно снять состояние с процессов, находящихся в остановленном состоянии.

Звучит страшно, но, к счастью, такие ситуации относительно редки, поэтому до сих пор ЦНИИУ обходился без этого.

Над какими проектами, связанными с ядром Linux, помимо CRIU, вы работаете? В каких проектах, не связанных с ядром Linux, вы участвуете? Серьезно, почти ни над чем и ни в чем.

Того, что мне предстоит сделать в рамках OpenVZ, CRIU и нашей интеграции с ядром Linux, более чем достаточно.

Вы упомянули проект OpenVZ. Расскажите, что это за проект? Какова степень вашего участия в нем? С программной точки зрения это ядро от Parallels + несколько утилит для его настройки, с помощью которых можно создавать контейнеры Linux и управлять ими.

Помимо программного обеспечения, это еще и (уже) бренд, с помощью которого Parallels заявляет о себе в мире Open Source. Вокруг проекта даже выросло сообщество среднего размера.

Степень моего участия в этом, судя по всему, не мала.

Вскоре после рождения проекта меня «продвинули» от простого разработчика до руководителя команды атомщиков.

А поскольку главное, что было ценно в OpenVZ на тот момент, — это ядро, я де-факто тоже стал чем-то вроде технического руководителя проекта.

А через год стартовала упомянутая кампания по интеграции кода OpenVZ в ядро Linux, которая также проводилась под флагом OpenVZ и изначально обрушилась лично на меня.

Сейчас ядро не является главной ценностью проекта (так как мы уже многое интегрировали в ядро Linux, и, например, в Fedora 19 можно делать контейнеры без нашего ядра).

Вот я вместе с руководителем проекта (Кир Колышкин) работаем над тем, как продвинуть проект дальше, не «уходя» всего с одним ядром.

Одним из таких направлений является, например, наш ЦНИИУ, который позиционируется как подпроект OpenVZ. Каковы сильные и слабые стороны проекта OpenVZ? Сила в том, что этот проект вовремя по сравнению с конкурентами осознал необходимость интеграции с другими проектами и начал с главного — с ядра.

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

Какие трудности возникли в процессе интеграции кода OpenVZ в ядро Linux? С какой версии ядра началась интеграция? Я уже забыл, когда мы разослали первые патчи.

Я даже не помню, с какой подсистемы мы тогда начинали.

Помню только, что в ядре 2.6.18, на основе которого мы сделали стабильную ветку, у нас уже была интегрирована часть кода.

По-моему, это были пространства имен PID и SysVIPC. В версии 2.6.32, которая стала нашей следующей стабильной версией, была интегрирована виртуализация сети (сетевые пространства имен) и кое-что еще.

Трудности возникли в том, что мне пришлось на лету осваивать совершенно другой способ развития.

Мы имели примерное представление о том, как выглядит процесс интеграции патчей в ядро.

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

Как проект OpenVZ связан с LXC? И это вообще замечательный вопрос.

Менеджер OpenVZ давно и безнадежно хотел, чтобы ответ был напечатан огромными буквами и повешен в каком-нибудь безумно популярном месте, где его мог бы прочитать каждый! Прежде всего, что такое LXC? LXC — это, во-первых, набор компонентов ядра, позволяющих изолировать процессы друг от друга, а, во-вторых, это утилита, которая заставляет эти компоненты корректно взаимодействовать, создавая контейнер.

OpenVZ — это практически одно и то же: компоненты ядра, реализованные по-разному, и утилиты, которые эти компоненты настраивают для создания того же контейнера, но более безопасного и функционального.

Итак, ответ на вопрос заключается в том, что команда разработчиков ядра Parallels создала большую часть функций ядра в LXC. Весь функционал, который появляется в основном ядре (т.е.

де-факто в LXC), обязательно начинает использоваться проектом OpenVZ. Как только мы делаем и выпускаем наше ядро, основанное на более новой версии ядра Linux, мы выбрасываем нашу реализацию подсистемы и заменяем ее аналогичной, которую мы (обычно мы) написали для Linux. То есть, чем дальше мы продвигаемся, тем больше частей нашего ядерного кода меняют бренд с OpenVZ на LXC. Какой функционал планируется реализовать в OpenVZ в ближайшем будущем? Каково будущее? Планируются ли какие-либо другие подпроекты OpenVZ, связанные или не связанные с ядром Linux? Сейчас мы работаем над несколькими вещами.

Это почти готовый драйвер виртуального диска для контейнеров, так называемое петлевое устройство для тех, кто работает с Linux. Оно есть, но нас не устраивает, как оно работает и какие возможности оно предоставляет. Другое дело — оптимизировать работу подсистемы управления памятью групп процессов (memcg).

То, как это работает сейчас, нас не устраивает с точки зрения производительности и распределения ресурсов между контейнерами.

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

Причем все это делается сразу с прицелом на интеграцию в дерево Linux. Есть также большие планы по интеграции OpenVZ с другими проектами, например, он уже почти весь доступен в составе Fedora 19. Люди из OpenStack благосклонно относятся к идее поддержки OpenVZ в своих сервисах.

Интеграция с ЦНИИУ из той же серии.

Есть еще несколько интересных направлений, которые, кстати, вполне достойны названия подпроекта.

Но, к сожалению, пока не могу о них рассказать.

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

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

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

Так.

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

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

То же самое произойдет и с контейнерами, но на другом «фронте».

Теперь контейнеры можно использовать как обертку для отдельного процесса, приложения и для всего образа операционной системы (без ядра).

В будущем использование контейнеров для создания виртуальной операционной системы должно исчезнуть (эту нишу заполнят виртуальные машины).

А использование контейнеров для «изоляции» сервисов, как локальных, так и в облаке, должно стать невидимым стандартом.

Как вы стали разработчиком ядра? С какими трудностями вы столкнулись на начальном этапе? Все началось, кажется, на четвертом курсе колледжа.

Я тогда работал над академической распределенной файловой системой, и мой руководитель сказал, что Parallels (тогда компания еще называлась SWsoft) собирается сделать из этой системы коммерческий проект, и отправил меня поговорить с моим аспирантом, чтобы тот присоединился к ним.

Этот аспирант работал в команде ядра Linux, меня взяли на собеседование и взяли в команду со словами: «С этой файловой системой разберемся позже, начнем пока с ядра».

В результате Parallels так и не дошли до этой системы, так что я остался разработчиком ядерной программы.

Настоящие трудности возникли, когда мне пришлось писать код не для ядра, которое было разработано в рамках Parallels, а для основного, которое делает Линус Торвальдс, и это было связано с тем, что модели разработки кода в Parallels и в сообществе были радикально другой.

В Parallels это более или менее стандартная разработка коммерческого кода.

Работа в сообществе – это совершенно другой процесс.

Его главная особенность, с моей точки зрения, в том, что это.

не совсем процесс разработки программного обеспечения.

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

Осознание этого факта и приспособление к нему были основными трудностями.

Над какими подсистемами ядра вы работаете? Почти все, кроме водителей.

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

Есть, правда, «любимые» системы — для меня это сетевой код и подсистема управления памятью.

Как работает процесс включения ваших патчей в ядро? Каковы особенности этого процесса? Каковы проблемы? Процесс выглядит одинаковым для всех.

Для начала нужно сделать сам патч или их серию, написать комментарии к каждому (это, кстати, отдельный навык).

Затем патч отправляется в список рассылки, в котором обсуждается необходимая подсистема ядра.

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

Тогда придется немного подождать.

Если все сделано хорошо и всем все нравится, мейнтейнер забирает патч в свой репозиторий.

Затем Линус включает в свое дерево то, что накопили все сопровождающие.

Это самый простой путь, но он может оказаться сложным и занять больше времени.

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

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

После этого процесс необходимо начать заново.

Самое главное для автора патча здесь не принимать критику на свой счет, а вникнуть в ее суть и, если вы со всем согласны, переделать.

Например, когда я начал рассылать части кода контейнера по спискам рассылки, мне пришлось несколько раз переписывать код с нуля.

В результате то, что сейчас есть у Линуса «про контейнеры», — это не одна строчка, похожая на то, что есть у нас, хотя она решает те же проблемы.

Существуют ли стандарты включения кода в ядро Linux? Если да, не могли бы вы привести типичные примеры? Допускаются ли отклонения от стандартов? Стандарты, конечно, есть.

Даже написан специальный документ — Kernel Coding Style. Содержит все требования для регистрации.

Требования, надо сказать, весьма разумные.

К ним легко привыкнуть, а потом очень сложно начать писать (и читать) по-другому.

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

В общем, ядро написано максимально абстрактно от архитектуры.

Чаще бывает, что пишешь на СИ, но в коде, зависящем от архитектуры.

Результатом является новая функциональность, которая работает только на одной архитектуре.

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

Как и когда вы познакомились с Linux? Какие дистрибутивы вы использовали? С Linux я познакомился на втором курсе института.

Там у нас был целый семестр, посвященный системам Unix на примере Linux. Примерно через год после первой установки Windows окончательно развалилась.

Это был очень правильный шаг, кстати, когда пришло время писать дипломную работу, почти все мои однокурсники делали это в Microsoft Word, а я в LaTeX. В результате только моя работа выглядела на защите достойно с точки зрения дизайна и компоновки.

Первым дистрибутивом, который я себе установил, был AspLinux, потому что о нем мне тогда говорили «более опытные коллеги», что в нем и только в нем русский язык работает нормально.

Потом я попробовал Centos, Suse, а теперь использую Fedora. Как выглядит ваш рабочий день? Сколько времени вы уделяете программированию и сколько дизайну? Хм.

Я даже представить себе не могу, как выглядит обычный рабочий день.

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

и чтобы люди, ожидающие от меня каких-то действий, не ждали их «напрасно».

Какое программное обеспечение вы используете на работе? Среда рабочего стола (GNOME, KDE, XFCE и т. д.), почтовый клиент (возможно, комбинация веб-интерфейса и почтового клиента), веб-браузер, редактор, инструменты разработчика (например, git)? «Настроенный» (как обычно) Fedora Linux. Ну и продукты Parallels, конечно.

Мне не нравятся KDE и Gnome, поэтому я сразу установил FluxBox. Для графических приложений я использую Thunderbird, Chrome, Skype. Время от времени вам нужно рисовать слайды для следующей конференции.

Пока возможностей OpenOffice достаточно.

Остальное (даже мультики для детей) запускаю в терминале.

Редактор VIM, а также стандартные инструменты разработчика — make, git, svn, gcc, objdump, gdb. Используете ли вы облачные сервисы для работы или личных целей? Если да, то какие? Кроме гугл+ и тусовки почти ничего.

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

Как выглядит рабочее место? Есть ли особые предпочтения при выборе оборудования? Стол, стул, ноутбук.

Аппаратное предпочтение только одно — у IBM ThinkPad очень удобная клавиатура и трекпойнт. Используете ли вы мобильные устройства в рабочих целях? Если да, то какие из них вы предпочитаете? Девайс (один) - да, я купил себе HTC Sensation пару лет назад в одну из командировок, чтобы не пришлось постоянно доставать в аэропортах ноутбук и не таскать с собой фотоаппарат и читалку со мной.

Ну и заодно это меня почти избавило от отдельного навигатора.

С тех пор ничего не изменилось.

В этом плане я классический «сапожник без сапог».

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

" Принимаете ли вы участие в специализированных конференциях? Вы проводите презентации? Да, пару раз в год я о чем-то рассказываю на конференциях по Linux. Иногда приезжаю без доклада, но тогда цель – поучаствовать в своеобразном «круглом столе».

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

Вы присутствуете на форумах и в чатах? Но это не так.

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

Что вы думаете об этом? Какую музыку ты слушаешь? Зависит от того, чем именно я «работаю».

Если это что-то рутинное, например просмотр ежедневного информационного бюллетеня, то возможно все.

Если это кодирование, о котором уже понятно, что именно кодировать, то музыка без слов, иначе сложно сконцентрироваться.

Для более интеллектуальной деятельности я предпочитаю тишину.

Но мне кажется, что явных предпочтений в музыке у меня нет – это классика, тяжелая музыка, советские поп-рок-сеты и какие-то случайные песни, которые я слышал по радио.

Какой совет вы бы дали начинающим разработчикам ядра? Как снизить «порог входа» в процесс разработки? Я слышал много советов о том, что делать, а что не делать.

Мне кажется, все они сводятся к тому, что разработка ядра Linux — это, в первую очередь, общение в «клубе по интересам» и лишь во вторую очередь собственно разработка.

Этакая открытая социальная сеть любителей системного программирования.

Поэтому первое, что нужно сделать, это настроиться на такой стиль общения.

А все остальное последует. Какие книги или ресурсы вы можете порекомендовать тем, кто начинает разработку ядра? Рекомендую, за очень редким исключением, не читать книги о строении ядра — оно слишком быстро меняется, так что любая книга устаревает менее чем за год. Лучше ознакомиться с принципами работы аппаратных платформ и операционных систем и сразу «окунуться» в чтение кода.

Но я могу порекомендовать сайт kernelnewbies.org - для новичков в ядре это будет как минимум отличный и главное актуальный сборник ссылок на другие сайты, документацию и некоторую каноническую литературу по ядру.

Павел Емельянов родился в 1982 году.

В 2004 году начал работать в компании SWsoft, которая в 2007 году была переименована в Parallels. В 2005 году окончил Московский физико-технический институт. В 2008 году защитил диссертацию «Математическое моделирование процессов управления потреблением памяти в многопользовательских средах и системах виртуализации», став кандидатом физико-математических наук по специальности «Математическое моделирование, численные методы и программные комплексы».

Он является архитектором многих систем, связанных с ядром Linux, в Parallels, в том числе руководителем проектов OpenVZ и CRIU. Отвечает за организацию взаимодействия между командой разработчиков ядра Parallels и сообществом ядра Linux. Беседовал Игорь Штомпель, журнал «Системный администратор» Теги: #linux #Виртуализация #criu #parallels #openvz #Cloud Server #Павел Емельянов