Викиновости

Интервью с Павлом Емельяновым, одним из самых активных российских разработчиков ядра Linux

8 октября 2012 года

Павел Емельянов, один из самых активных российских разработчиков ядра Linux, ответил на несколько вопросов opennet.ru, приуроченных к выходу релиза CRIU 0.2, системы для заморозки и восстановления состояния процессов в Linux. Последние восемь лет Павел работает в компании Parallels над проектами, связанными с изолированными контейнерами и облачными системами, в том числе является одним из основных разработчиков таких открытых проектов, как CRIU и OpenVZ.

Расскажите, как проходило становление участника разработки ядра Linux. Помните ли вы ваш первый коммит в ядро?

Становление проходило труднее, чем, как мне сейчас видится, могло. Дело в том, что участвовать в разработке я стал сразу с нелегкой задачей - созданием нового функционала. Кроме того, до меня из Parallels (тогда SWsoft) в mainstream слали не много патчей (да и были это, главным образом, устранения неисправностей), так что посоветоваться было не с кем.

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

Как был преодолён языковой барьер? Или у вас изначально было отличное знание английского? Были ли языковые казусы?

Если речь идет о письменном английском, то барьера не было, так как до этого я уже больше года работал в SWsoft, а там вся техническая переписка велаcь на английском (впрочем, для Parallels это некие корпоративные стандарты). Когда начал ездить на конференции, говорил, конечно, с трудом. Разговорился, наверное, после третьей или четвертой поездки. А казусы были однотипные - я ничего не понимал, что мне говорят, и постоянно переспрашивал.

Как проходит продвижение патчей, какие подводные камни возникают?

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

С кем приходится контактировать в цепочке продвижения патчей?

Ну, "цепочка" это громко сказано. Обычно цель патча - это репозиторий ответственного человека (майнтейнера). Пока туда патч не попадет, контактируешь с ним и с другими обитателями тематического списка рассылки.

Возникают ли проблемы со стилем оформления кода? Бывает ли, что не принимают патчи по идеологическим или формальным причинам? Как удаётся приходить к компромиссу?

Со стилем уже не бывает. Хороший текстовый редактор все делает за меня :) По идеологическим причинам не принимают довольно часто, особенно, когда это патч, который открывает "новое направление" в ядре. Тут приходится попотеть и попереписываться. К компромиссу приходят одним путем - это называется "progress by argument". Ты объясняешь, какой цели ты хочешь добиться и почему так, как это написано в патче. Если кто-то с тобой не согласен, он объясняет почему, и как сделать по-другому. Обычно один из вас объективно не прав, и в диалоге выясняется кто.

Какие наиболее важные подсистемы/патчи, в создании которых вы принимали участие, удалось продвинуть в основное ядро Linux? Какие из подобных подсистем пока остаются непринятыми в ядро и что мешает их принятию?

Все, что я делал, уже там в том или ином виде. Из самых крупных - виртуализация сетевого стека и PID-ов (идентификаторов процессов) и контроллер памяти приложений (a.k.a. memcg). Ну и, конечно же, главный мой проект сейчас - checkpoint-restore in userspace. Для него модифицируется во всех подсистемах по-немногу (но в сумме набралось уже почти 100 патчей). Непринятых в смысле принципиально отвергаемых сейчас нет, есть патчи, которые пока плавают в списках рассылки, ждут своей очереди на обсуждение или переработку.

Какой примерно объем работы приходится выполнять для синхронизации с новыми версиями ядра параллельно поддерживаемых патчей, которые ещё не приняты в основное ядро, для OpenVZ и CRIU? Были ли особенно тяжёлые случаи, когда какое-то изменение в ядре серьёзно все ломало или заставляло пересматривать архитектуру?

Для criu мы не перебазируемся в привычном смысле этого слова, так как проект изначально разрабатывается в mainstream. То есть - если что-то сообщество не берет, мы это и к себе не берем, а сразу переделываем.

Для OpenVZ патч для переезда, конечно, огромный. Перебазировались по-крупному мы уже 2 раза (с 2.6.9 на 2.6.18 и потом на 2.6.32), сейчас начинаем на 3.6. Переезд у меня занимал около месяца до состояния "готово к отдаче в QA". После этого еще пол-года на стабилизацию.

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

Чего не хватает в штатном ядре для полноценной реализации CRIU? Какие есть идеи по дальнейшему развитию CRIU?

Если не брать мелочи, то самое большое белое пятно это memory snapshot. Технология, при которой мы говорим ядру, что хотим знать, какие страницы памяти меняются приложением в процессе его работы, и начинаем параллельно с выполнением процессом своих дел копировать его память. Потом замораживаем его и копируем только то, что он поменял. Это сильно сокращает время миграции и открывает возможность для такой фичи, как incremental snapshot состояния, при котором повторное снятие производится быстрее (гораздо быстрее) и можно делать его чаще.

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

В каких ещё открытых проектах, кроме ядра Linux и продуктов Parallels, приходилось заниматься?

По-крупному ни в каких. Linux kernel + OpenVZ + CRIU (плюс закрытые продукты Parallels) пока с лихвой покрывают области моих интересов.

Какой дистрибутив и десктоп окружение используете для работы и дома? Какой инструментарий разработки предпочитаете (в чем пишете и отлаживаете код)?

На ноутбуке Fedora + FluxBox, оно же дома. Инструментарий для работы и отладки сначала был простой - vim + дизассемблер + голова ;) чуть позже появилась еще команда. У нас в kernel team собрались очень талантливые люди, они знают и умеют гораздо больше меня, чем я и пользуюсь (в хорошем смысле этого слова).

Работаете ли дома в своё удовольствие или ограничиваетесь только рабочим временем? Даёт ли работодатель возможность заниматься в рабочее время сторонними открытыми проектами (например, в Google можно тратить 20% своего времени на любые интересные проекты)?

Для меня "рабочее время" очень размыто определено. У меня нет строгих часов, когда мне надо быть в офисе, чем я активно пользуюсь и крою свой день очень сильно. С другой стороны, когда возникает необходимость или желание, я часто что-то делаю из дома.

Заниматься своими проектами в рабочее время в Parallels, строго говоря, нельзя. Но с другой стороны, в Parallels работают очень открытые люди, так что если "свой проект" имеет отношение к деятельности компании, то можно (и даже нужно) поговорить со своим руководителем, и если проект действительно хороший, то у него огромные шансы стать частью продуктов Parallels. Или даже стать самостоятельным новым продуктом ;)

В каком году вы впервые столкнулись с Linux и когда стали использовать его вплотную? Какой был ваш первый дистрибутив?

С Linux столкнулся в институте на 2-м курсе. У нас в программе была тема про UNIX, а практика была на Linux. Первым дистрибутивом стал ASPLinux, так как на то время это был единственный дистрибутив с нормальной поддержкой русского языка. Не в интерфейсах - с этим проблем не было - просто мне к тому времени уже захотелось сделать Linux основной рабочей ОС на домашней машине, и невозможность читать странички из рунета или написать письмо по-русски удручала.

Считаете ли вы перспективными операционные системы подобные Qubes ( qubes-os.org), использующие механизмы виртуализации для изоляции приложений?

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

В последнее время системы виртуализации Xen, KVM и VirtualBox развиваются стремительными темпами. Насколько ощущается конкуренция со стороны подобных систем, ведь они всё больше влезают в нишу, принадлежащую системам контейнерной изоляции?

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

В чём сегодня сильные стороны систем контейнерной виртуализации? Насколько у них ниже накладные расходы при выполнении изолированных окружений по сравнению с Xen и KVM в режиме паравиртуализации?

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

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

Это очень распространенное мнение, на практике, однако, не подтверждающееся. Да, конечно, "уронив" ядро, контейнер "роняет" всю систему, но ведь сделав то же самое с гипервизором VM добьётся того же эффекта. Обычно возражают, что гипервизор меньше по размеру кода, но на ядро в целом тоже "смотрят" больше человек, чем на гипервизор. Так что вопрос в том, кто стабильнее открыт. Что касается эксплоитов вида "побег из окружения", то мой опыт подсказывает, что количество известных случаев создания таких эксплоитов примерно одинаково как для контейнерной, так и для аппаратной виртуализации.

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

OpenVZ и LXC во многом похожие и движущиеся к одной цели проекты, есть ли взаимодействие между командами разработчиков этих систем? Проявляется ли конкуренция? В чём принципиальные различия OpenVZ и LXC?

Я часто слышу, как люди разделяют LXC и OpenVZ как проекты. Для меня это очень печально, потому, что команда, которая разрабатывает OpenVZ, активно разрабатывает и LXC, просто совместно с другими компаниями. И вклад людей из Parallels в LXC даже с точки зрения количества кода не маленький - больше половины написано нами, а что-то - только нами. Поэтому правильным ответом на вопрос про конкуренцию будет - она проявляется в головах пользователей. Мы же, как разработчики, только выигрываем от того, что контейнерами занимается еще кто-то (например IBM и Google :) ).

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

В дополнение, Павел также ответил на серию вопросов, заданных читателями opennet.ru в процессе обсуждения анонса новой версии CRIU:

Я правильно понимаю, что теперь я могу заморозить nginx с несколькими гигами кэша, перезагрузиться с новым ядром, разморозить его обратно и не получить лежащий от DoS-а сервер?

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

Раньше был подобный по сути, но не реализации, проект CryoPID - A Process Freezer for Linux. Связаны ли как-то CRIU и CryoPID?

Только идеологически - оба проекта пытаются достичь одного и того же. Но CRIU изначально ориентировался на тесную работу с ядром, в то время как CrypoPID пытается сделать все на существующих ядерных интерфейсах. Но достичь цели без модификации ядра невозможно, поскольку ядро "знает" о процессах гораздо больше, чем показывает наружу. В CryoPID с этим быстро столкнулись, и проект де-факто умер.

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

А это как раз мы эти API и делали в ядро. На сегодня почти все, что нужно CRIU уже в включено в linux-3.6. Но проект на месте не стоит, у нас есть планы на дальнейшее расширение как ядра, так и нашего проекта. Договоренности о включении нет, сообщество разработчиков ядра устроено по-другому (и это тема для отдельной беседы). Но есть благожелательное отношение сообщества к нашему проекту, поэтому перспективы видятся самые радужные.

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

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

Как быстро он сохраняет слепок процесса? Есть ли смысл экспериментировать с заморозкой всех процессов, или suspend/resume всей системы будет слишком много времени занимать? Интересно поковырять CRIU в сторону создания слепка для всей системы и восстановления на другой машине для обеспечения high availability или для переноса без остановки на более мощный сервер.

Скорость сохранения в основном зависит от количества памяти, которые используют приложения. Замораживать все процессы сейчас смысла большого нет. Но в будущем должна появиться фича, при которой можно будет поменять ядро пока вся система заморожена. Делать слепок системы для HA не совсем полезно. Для HA достаточно просто перезапустить все с нуля на failover машине. А вот FT (fault tolerance) это уже интересно, но criu пока так не может.

Источники

править
 
 
Creative Commons
Эта статья содержит материалы из статьи «Интервью с Павлом Емельяновым, одним из самых активных российских разработчиков ядра Linux», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.
 
Эта статья загружена автоматически ботом NewsBots в архив и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.



Источник — https://ru.wikinews.org/w/index.php?title=Интервью_с_Павлом_Емельяновым,_одним_из_самых_активных_российских_разработчиков_ядра_Linux&oldid=8948227