Павел Емельянов, один из самых активных российских разработчиков ядра 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. Первым дистрибутивом стал ASP-linux, так как на то время это был единственный дистрибутив с нормальной поддержкой русского языка. Не в интерфейсах - с этим проблем не было - просто мне к тому времени уже захотелось сделать 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 пока так не может.
