Стас Протасов, сооснователь Parallels и руководитель отдела разработки, ответил на вопросы пользователей Хабрахабра.
Поводом для интервью с Parallels стал отчёт Linux Foundation за 2012 год, в соответствии с которым российский разработчик средств для виртуализации вошёл в число самых активных контрибуторов ядра Linux, наравне Google, AMD, Cisco и HP. Российская компания также приняла на работу Джеймса Боттомли, члена совета директоров Linux Foundation, который теперь отвечает за направление контейнерной виртуализации Parallels.
Кроме того, в жизни компании Parallels произошли и другие события: открытие питерского офиса, выпуск нового проекта Parallels Automation for Cloud Infrastructure (PACI) — это система, аналогичная Amazon EC2, но в виде коробочного продукта.
— На какой платформе и языке программирования реализован PACI и делались ли нагрузочные испытания системы для сравнения скорости работы с аналогами (Amazon EC2 и т.д.)? filatov
— PACI реализован на языке Java и C++ и на базе разработанной нами платформы Parallels Automation. Испытания аналогичных систем, конечно же, делались. Контейнерная виртуализация, вообще говоря, быстрее, чем Xen-гипервизор, используемый Amazon-оном, и практически не имеет накладных расходов на виртуализацию. Особенно это заметно на приложениях, которые чувствительны к latency. При этом, многое будет зависеть и от того сколько ЦПУ ресурсов в MHz и памяти выделит вам провайдер. Еще одна тонкость состоит в том, что Amazon не указывает чётко, в чём меряется и как ограничивается скорость ЦПУ, и реальная скорость может варьироваться в зависимости от модели процессора, где будут исполнять вашу среду.
Добавлю, что Amazon EC2, конечно же, не является прямым аналогом PACI, потому что не является отчуждаемым от Amazon «коробочным» продуктом.
— Хотелось бы услышать немного о самой команде, кто это делает, и наверно про сам процесс разработки. И про новый офис в Питере — с чего вдруг решили открыть и какие разработки планируется сконцентрировать там. Как сформировался основной костяк разработчиков? Кто эти люди, откуда они пришли? eaa
— Что касается команды, то её костяк составляют разработчики, которые стояли у истоков зарождения компании. Тогда в 90-х команда собиралась по крупицам, но довольно простым способом — приглашали своих «толковых» знакомых, кто-то приходил по рекомендации. К счастью, в большинстве своём, всё те люди до сих пор в лодке — это большая дружная команда реально талантливых специалистов, благодаря которым Parallels добилась того, чего добилась.
Другая часть разработчиков — бóльшая — это люди нового поколения, которые пришли к нам из лучших технических вузов страны. Во многом на это повлияло то, что Parallels имеет многолетнюю историю сотрудничества с этими вузами, в тех же МФТИ (с 1999 г.), новосибирском НГУ (с 2004 г.) и МГУ (с 2006 г.) у нас есть свои учебные центры, где моделируется работа в большой компании, предлагаются задачи для решения. Мы платим стипендии, а по итогам обучения с удовольствием приглашаем к себе на работу. В прошлом году открыли учебные центры еще в АСУ (Академический Санкт-Петербургский Университет).
И, наверное, в третью группу можно выделить нанятых технических специалистов мирового уровня, таких как Майкл Тоутонги (один из 22 technical fellow Microsoft, технический директор Parallels), Марк Збиковски (создатель Windows NT, обладатель множественных международных наград за более чем 25 летнюю карьеру в Microsoft), Джеймс Боттомли (член совета директоров Linux Foundation, технический директор направления контейнерной виртуализации Parallels), Алексей Кузнецов (создатель 90% TCP/IP стека в Linux), Ричард Вирт (бывший вице-президент, старший научный сотрудник и генеральный менеджер по программному обеспечению компании Intel), Амир Шариф (экс-топ-менеджер VM Ware, вице-президент по направлению серверной виртуализации Parallels) и другие.
По поводу центра R&D в Санкт-Петербурге: открыли его недавно и планируем довести до размеров, не уступающим нашим центрам в Москве и Новосибирске (в Москве работает около 250, в Новосибирске — около 180 инженеров). Почему именно там? Потому что это второй по величине город в нашей стране и, наверное, из-за своего размера, второй город по количеству образованных людей. Я уверен, что если IT-компания созрела до того, чтобы начать региональный девелопмент центров, то не заметить Питер просто глупо.
Люди, которые составили костяк нового центра разработки, имеют опыт работы в TogetherSoft, которую впоследствии купил Borland. Мы пересеклись и познакомились с ними относительно случайно. Borland довольно много инвестировал в средства быстрой разработки. Поэтому изначально мы задействовали команду центра в Питере для создания лёгкой в использовании программной среды, полнофункциональных плагинов для Eclipse для более простой «упаковки» приложений разработчиков по спецификациям APS. Сейчас команда занимается различными задачами по усовершенствованию платформы Parallels Automation. В частности, работой над новым APS.2.0 контролером и новым более простым в использовании интерфейсом для Plesk панелей.
— Можете раскрыть планы касательно развития проекта OpenVZ? rpisarev
— Сейчас мы будем перебазироваться на ядро 3.5 или 3.6. Следующим шагом на Red Hat Enterprise Linux 7, что случится приблизительно через год. Наш user space будет работать с main line контейнерами. То, что мы вливаем в upstream ядро Linux, оно уже более менее работоспособное, поэтому поддержка нашим user space обычного НЕ-OpenVZ up-stream ядра — это такой хороший промежуточный шаг.
Нельзя не упомянуть о проекте CRIU, в рамках OpenVZ. Проект представляет собой живую миграцию в user space. Там достаточно много и активно работаем и скоро, скорее всего, выйдет версия 1.0. Она пока не до конца позволяет мигрировать в main stream контейнер.
— Всегда интересовал вопрос — как именно происходит миграция запущенного контейнера на другой сервер? anarx
— Живая миграция основана на механизме checkpoint/restore, то есть сохранения и восстановления состояния запущенного контейнера. Если очень упрощённо, то при чекпоинтинге контейнер «замораживается» и его состояние (запущенные процессы, сетевые соединения, открытые файлы, различные буфера и так далее) скидываются в файл на диске. Потом из этого файла можно восстановить и «разморозить» контейнер в памяти, он побежит дальше. Так вот, при миграции восстановление происходит на другой машине, куда копируется файловая система контейнера и этот самый дамп состояния.
Процесс миграции можно расписать по шагам (опять же, упрощённо):
- Копирование оперативной памяти контейнера.
- Копирование файловой системы контейнера (в это время контейнер работает как обычно).
- Заморозка контейнера, запись его состояния и изменённой памяти в дамп.
- Копирование изменений в файловой системе контейнера.
- Копирование дампа.
- Восстановление из дампа.
- «Убийство» замороженного контейнера на исходном сервере.
Конечно, миграция будет выглядеть «живой» только тогда, когда время, когда контейнер заморожен, невелико (никак не больше нескольких секунд). Для оптимизации этого параметра используются разные хитрости. Например, в начале процесса (шаг 1) оперативная память контейнера итеративно (несколько раз — сначала вся, потом только изменённая) копируется на другую машину, чтобы её «прогреть» и минимизировать размер дампа. В нашем ядре есть также механизмы отслеживания изменений файловой системы контейнера, чтобы копирование изменений (шаг 3) было как можно более быстрым (про это можно прочитать тут: http://ru-openvz.livejournal.com/4741.html. Естественно, если оба физических сервера имеют общий диск (SAN/NAS/NFS), то этапы копирования файлов пропускаем.
До начала миграции выполняются различные проверки, например, что на новой машине достаточно места, и что её процессоры понимают те же наборы команды, что и на старой (типа SSE3). Тем не менее, миграция может «сломаться», скажем, если в середине процесса пропадёт сеть. В этом случае процесс прерывается, и контейнер просто «размораживается» на исходной машине.
И последнее, с точки зрения пользователей, работающих с контейнером через сеть, он «замирает» на несколько секунд, это выглядит как какая-то задержка в сети. При этом TCP-соединения не разрываются, а мигрируют и после разморозки продолжают работать.
— Виртуализация в среде Apple ещё является основным направлением работы компании? danilf
— Для тех, кто не в курсе, поясню, что в вопросе речь идет о нашем продукте Parallels Desktop для Mac, который позволяет запускать на Макинтош Windows-приложения (и ещё более 50 ОС).
Сам продукт Parallels Desktop для Mac остаётся для нас очень важным, и пока не вижу причин, почему ситуация может измениться. Мы мировой лидер на рынке десктопной виртуализации, а развитие мобильных IT открывает перед нами практически непаханое поле.
Что касается виртуализации как технологии, то она (технология) довольно зрелая, и я не думаю, что на этом поле могут появиться какие-то принципиально новые решения. Её развитие, безусловно, будет происходить, но, наверное, уже эволюционным путем
— Какое у компании отношение к KVM? Планируется ли использование этой технологии? skobkin
Я думаю, что KVM — это будущая основная система гипервизор-виртуализации в ядре Linux. Сегодня она может быть неидеальна и имеет какие-то недостатки в сравнении с конкурентами, но в будущем наверняка станет лучшей. Продуктов, использующих эту технологию, будет много. Скорее всего, что-то своё будет у Red Hat, у других крупный компаний. Мы тоже не останемся в стороне, и наши продукты будут использовать технологию KVM. Ответ — да, планируется.
— Как обстоят дела с портированием OpenVZ патчей на ядра 3.х, понятно, что некоторые вещи уже попали в апстрим. Но насколько я понимаю, далеко не всё готово для включения? Какие проблемы связаны с синхронизацией ваших патчей со свежими ядрами, ваша оценка объёма работы? Смущает то, что на сайте нету даже экспериментальных репозиториев с ядром выше 2.32. tamerlan311
— На этот вопрос довольно подробно ответил наш team leader по Open VZ Кирилл Колышкин (master1981). С его позволения, сделаю здесь перепост:
«Пока наша самая «свежая» ветка ядра — это та, которая на базе RHEL6. В планах — портирование на RHEL7, но так как он выйдет не раньше, чем через год, то мы будем делать промежуточную ветку на базе, скорее всего, 3.5 или 3.6, чтобы потом было проще переехать на RHEL7.
Отсутствие экспериментальных репозиториев для свежих ядер связано с тем, что в последнее время мы были сосредоточены на других задачах, а именно: 1) вливание нашей функциональности в ядро, в основном, это NFS for containers и CRIU, также memory controller; 2) CRIU; 3) доведение до ума новых разработок: vswap, ploop и т.п.»
— Пожалуйста, расскажите про новый продукт Parallels Cloud Storage. Чем его ядро отличается от ядра PVC / OpenVZ, кроме встроенного PSBM? Если отличия существенные, планируется ли вливать их в PVC / OpenVZ / апстрим? borisko
— PVC как такового у нас не будет, а будет Parallels Cloud Storage, который, в общем-то, представляет из себя PVC плюс гипервизор. Если говорить о ядре PCS, то оно всё будет в OpenVZ. Уже сейчас в паблике можно видеть такие значительные проекты как ploop, который является важной частью нашего хранилища. Он уже там лежит — идите и берите. Ничего закрытого в ядре PCS не будет. И если на сегодняшний день что-то в паблике не доступно, то только потому, что оно ещё не готово.
— Меня в рамках OpenVZ сейчас волнуют только ядра prod Debian… Не уверен, что это стоит отдельного вопроса на Хабре... (вопрос из ЖЖ team leader по Open VZ Кирилла Колышкина, опубликовавшего ссылку на Хабр)
— Мы традиционно предоставляем сборки нашего софта (ядра и утилит) в виде rpm-пакетов, а пакеты под Debian по ряду причин не билдим, поэтому всем советуем воспользоваться утилитой alien для конвертации rpm в deb.
В последнее время ребята из OpenStack очень полюбили OpenVZ, в частности, его используют в проекте RedDwarf (база данных как сервис). Так как OpenStack построен, как правило, на базе Ubuntu, то сейчас мы с ними работаем над тем, чтобы билдить наши ядра для Ubuntu/Debian.
— Стас, расскажите про СloudLinux. Зачем Parallels понадобился собственный дистрибутив Linux? В чем его отличие от других дистрибутивов? И еще почему PVC не поддерживает СloudLinux? freem4n
— К Parallels команда СloudLinux не имеет никакого отношения, ни людскими ресурсами, ни материально, ни как бы то ни было еще. Хотя, конечно, я знаю от туда некоторых людей. Возможно СloudLinux нам и нужен, но, к сожалению, он не наш.
— А вот ещё вопрос про APS приложения. Вещь хорошая и нужная, но очень-очень часто попадаются пакеты, которые просто не устанавливаются. Также бывает, что с выходом новой ревизии пакета он перестает устанавливаться, а на старой ревизии все хорошо. Или, например, локализация в приложении отсутствует. Причём эти приложения запакованы Parallels. Складывается впечатление, что пакеты либо вообще не тестируются, либо тестируются в ограниченном объёме. Хочется узнать предпринимаются ли шаги в сторону улучшения качества APS-приложений? freem4n
— Приложения для интеграции с внешними сервисами, как например, Microsoft Office 365 или SpamExperts, действительно нельзя поставить без логина и пароля для доступа к этому сервису. Простые веб-приложения должны устанавливаться без дополнительной информации.
Все приложения из каталога APS проходят процедуру тестирования и сертификации, в том числе проверку процедуры обновления. Если есть проблемы с каким-либо приложением, мы очень хотели бы знать об этом. На сайте APS есть форма, через которую мы собираем отзывы.
Локализация действительно доступна не для всех приложений и не для всех языков. Это происходит только если появляется спрос на соответствующем рынке. Тогда вендор приложения (или Parallels) обычно выпускает либо новую версию пакета с соответствующим переводом, либо add-on пакет с ним.
Комментарий пользователя rumkin, недовольного продуктом Plesk: «Вплотную работаю с их Плеском, кроме дискомфорта и полнейшего батхерта с вытекающим профессиональным геморроем, не испытываю больше ничего. Спасибо за возможность высказаться»
— Спасибо за этот комментарий, который уравновесит наше интервью про «замечательную команду Parallels». Поскольку в сообщении не было вопроса, я позволю себе дать просто комментарий по поводу Plesk.
Панель Plesk, имея долгую и непростою историю, является важной частью нашей линейки продуктов автоматизации и облачных услуг. Ещё пять лет назад многие наши пользователи боялись даже апгрейдиться на новую версию, потому что эти апгрейды часто им приносили только проблемы. Но за последние три года мы сделали очень много работы, чтобы сделать её лучше, и сильно в этом продвинулись. Мы регулярно замеряем уровень удовлетворённости пользователей Plesk-ом, и могу вам сказать, что за последние три года она существенно выросла. Это даёт нам веру в то, что мы всё-таки делаем правильные вещи.
Кстати, буквально несколько дней назад мы зарелизили Plesk 11, которая, с моей точки зрения, является дальнейшим существенным улучшением панели. Отмечу, что за прошедшие несколько дней мы видим просто какой-то фантастический апгрейд на 11-ю версию. Признаюсь, это впервые в нашей истории. Вероятно, это говорит о том, что людям нравится, как она выглядит по сравнению с предыдущими версиями и то, что люди перестали бояться. Вот здесь можно почитать, что в Plesk 11 нового: http://habrahabr.ru/post/146720/.
Из того описания проблемы, которое вы дали (батхерт и геморрой), трудно понять, в чем именно проблема. Но если вы обратитесь к нам напрямую – для начала, можно в твиттер @ParallelsPanel, мы попробуем как-то помочь.
Автор: habriel
