Виртуализация приложений: новый этап

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

Другая тенденция, которая стремительно трансформирует рынок, — использование виртуальных рабочих мест в рамках инфраструктуры виртуальных рабочих столов (VDI). Внедрившие VDI компании могут больше не заботиться о том, какие компьютеры предоставить сотрудникам: доступ к серверным ресурсам возможен даже с тонких клиентов. Однако и здесь есть где развернуться сторонникам дальнейшей оптимизации. В частности, многие элементы виртуальных машин дублируются — рабочие столы используют ту же операционную систему и те же офисные приложения. И естественно, у разработчиков возникает соблазн объединить их, чтобы не хранить множество похожих копий.

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

Контейнеры представляют собой изолированные пространства одной и той же операционной системы, в каждом из которых выполняется отдельное приложение для конкретного пользователя. Контейнер может быть организован как на виртуальной машине, так и на физическом сервере, десктопе или мобильном устройстве. Более того, в 2014 году — вслед за технологией контейнерной виртуализации для Linux, история успешных разработок которой к тому моменту насчитывала свыше 10 лет, — вышла версия Microsoft Windows Server с уже реализованной, благодаря сотрудничеству с Docker, поддержкой контейнеров.

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

В сообществе программистов давно обсуждается возможность предоставления пользователю или процессу доступа к нужному приложению или данным без привязки к конкретному контейнеру. В этой связи возникает вопрос: как создать такую резервную копию приложения, чтобы ее можно было развернуть в любом другом контейнере, на виртуальной машине или даже на физической рабочей станции? Поскольку приложение работает с определенными областями памяти и обращается к системным процессам, для решения этой задачи понадобится действительно комплексный инструмент, работающий на уровне как самих приложений, так и ядра ОС.

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

СООБЩЕСТВО ИЩЕТ РЕШЕНИЯ

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

Общая схема «живой миграции»

DMTCP

Один из способов осуществления «живой миграции» и оперативного восстановления приложений предлагает команда разработчиков из Северо-Восточного университета (США). Этот проект с открытым кодом предусматривает многопоточное создание серий контрольных точек для восстановления приложений. Distributed MultiThreaded CheckPointing (DMTCP) создает свое окружение в рамках Linux, где и становится возможной «живая миграция» поддерживаемых приложений, в числе которых Python, Matlab, графические интерфейсы рабочих столов, MPI и многие другие. Проект активно развивается, в его экосистему добавляются новые приложения, но ориентация на отдельные приложения остается его ограничением. Впрочем, если нужно обеспечить непрерывную работу и «живую миграцию» только графических интерфейсов рабочих столов, этого вполне достаточно.

BLCR

Специальная разработка Университета Беркли, Berkeley Lab Checkpoint/Restart (BLCR), использует для своей работы модуль ядра. Благодаря этому «живую миграцию» любых приложений, работающих под управлением ОС, удается обеспечить без создания отдельной инфраструктуры. Сотрудники и студенты университета разрабатывают систему резервного копирования и восстановления приложений и библиотек MPI, а также интерфейс управления. Однако они предпочли самостоятельно доработать ядро, и в результате BLCR оказался несовместим со многими версиями ядра Linux. Иначе говоря, для того чтобы воспользоваться возможностями BLCR, придется загружать специальный дистрибутив.

PinPlay

Система PinPlay основана на алгоритмах компании Intel. Она записывает процессорные инструкции, делает снимки памяти, которую использовало то или иное приложение, а также сохраняет необходимые ему библиотеки. Потенциал данного решения позволяет оптимизировать работу приложений в виртуальных средах, но, увы, осуществить полный перезапуск приложения нельзя, так как в PinPlay отсутствуют запись начального состояния приложения и информация об используемых объектах ядра. Тем не менее с помощью PinPlay можно ускорить восстановление после сбоя. Вполне вероятно, что после расширения функционала PinPlay этот инструмент тоже станет полноценным решением для виртуализации и «живой миграции» приложений.

CryoPid

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

CRIU

А вот разработчикам системы Checkpoint/Restore In Userspace (CRIU) удалось серьезно продвинуться в создании именно универсальной системы «живой миграции» для экосистемы Linux, и именно в пользовательском пространстве. Разработки были инициированы создателями проекта контейнерной виртуализации OpenVZ. Как и команда CryoPid, они столкнулись с недостаточными возможностями ядра, но, решив заняться его доработкой в тесном сотрудничестве с сообществом, смогли внести ряд важных дополнений в общее ядро Linux. Таким образом, инструкции и интерфейсы CRIU могут быть использованы с любым дистрибутивом, а в дистрибутив последней версии Red Hat Enterprise Linux эта система уже включена непосредственно. Именно поэтому у CRIU сегодня больше всего шансов стать стандартным решением для контейнерной виртуализации под Linux.

СВОБОДУ «ПОПУГАЯМ»

Преимущества технологий «живой миграции» заключаются в том, что переносить можно практически что угодно и куда угодно. Как отмечают разработчики, есть только два требования. Во-первых, возможности процессора на целевой машине должны быть не хуже, чем на источнике. Например, если на источнике поддерживалась технология SSE, она же должна быть и на целевой системе, куда мигрирует приложение. Во-вторых, ядро ОС на приемнике должно быть «не хуже», чем на источнике. Оно не обязательно должно быть той же или более поздней версии, но в нем должна быть реализована поддержка того же инструмента «живой миграции», который вы используете, а также иметься вся требуемая для приложения функциональность, например сетевые протоколы или файловые системы.

Все перечисленные выше проекты уже применяются на практике. Так, DMCTP используется в Северо-Восточном университете США для работы с Mathlab и Pyton, а также с другими инструментами. BLCR — неотъемлемая часть модификации Linux, распространяемой и используемой в Беркли, поэтому рабочие нагрузки исследовательских подразделений уже защищены на уровне приложений. CRIU, в свою очередь, помимо интеграции в дистрибутив RHEL 7, используется в разных проектах, в том числе в Tonic. Для данного инструмента даже разработана специальная надстройка p.haul, которая позволяет автоматизировать процесс миграции, например, в ЦОД. Однако все эти решения еще только развиваются и находятся в разной степени зрелости.

Учитывая, что как минимум три крупные команды работают над развитием решений «живой миграции» в виртуальных средах Linux, сегодня можно говорить об относительной независимости приложений от конкретной экосистемы и даже от контейнера. Пока эти функции только начинают применяться коммерческими компаниями, но, скорее всего, уже в ближайшие годы мы увидим повышение спроса на данные технологии за счет популяризации средств контейнерной виртуализации и роста требований к обеспечению непрерывности работающих в них ИТ-процессов. А вслед за успехами сообщества «по живой миграции» OpenSource свои решения предложит и Microsoft, но до этого пройдет немало времени.

Павел Емельянов — главный архитектор компании Virtuozzo.