V Международная студенческая научная конференция Студенческий научный форум - 2013

Введение

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

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

Много исследований в области миграции процессов сосредоточено на переносе информации о состоянии процесса. Например, перенос страниц памяти процесса с исходного узла целевому узлу. Запуск переносимого процесса на исходном узле осуществляется посредством загрузки этих страниц в память целевого узла и корректного восстановления состояния процесса (например, состояния регистров, содержимого стека). Также необходимо осуществлять поддержку всех связей между восстанавливаемым процессом и другими, необходимыми для его выполнения [6, 9].

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

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

Области применения

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

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

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

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

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

5. Использование специальных возможностей. Если процессу необходимы специальные возможности, но на узле, на котором он был запущен, их нет, целесообразно перенести его на другой узел, на котором эти возможности есть. К примеру, некоторые математические программы будут гораздо эффективнее выполняться на узлах с математическим сопроцессором или на множестве процессоров суперкомпьютера. Если не использовать миграцию, пользователь будет вынужден самостоятельно решать, где запускать процесс, и в дальнейшем не иметь никакой возможности менять окружение процесса в течение всего времени его работы. Эта проблема усугубляется еще и тем, что конечный пользователь может не знать некоторых особенностей и требований запускаемой программы.

6. Мобильные компьютеры. Для того чтобы в полной мере использовать все преимущества мобильных компьютеров, пользователь должен иметь доступ к стационарным вычислительным узлам, имеющим гораздо большую мощность. К примеру, пользователь мобильного компьютера (ноутбука, либо портативного компьютера) запустил на выполнение процесс, результат расчета которого имеет большую важность. Используя технологии миграции, пользователь может перенести этот процесс, не прерывая выполнение, на большой вычислительный сервер, с целью экономии заряда батареи или для более быстрого получения результата [9].

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

Виды миграций

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

1. Пассивный объект. Процесс (или объект), передача которого осуществляется, содержит только пассивные данные. Нет необходимости перемещать исполняемый код. В данном случае необходимо преобразовывать формат данных исходного узла в формат данных целевого узла.

2. Активный объект, миграция во время неактивности. Есть необходимость перемещения, как пассивных данных, так и исполняемого кода. Однако миграция происходит тогда, когда исполняемый код не активен. Предполагается, что исполняемый код доступен на целевом узле.

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

4. Активный объект, машинный код. В данном случае активная программа компилируется в родной машинный код исходного узла. Миграции подобного типа являются самыми сложными из всех вышеперечисленных. Это связано как со сложностью «захвата» состояния выполняющегося процесса, так и со сложностью восстановления процесса в это состояние. Кроме того каждая архитектура имеет свой способ и формат хранения состояния выполняющегося процесса. Таким образом, возникает проблема конвертации форматов хранения состояния между узлами с разной архитектурой [3, 6, 9].

Были рассмотрены основные традиционные типы миграции выполняющихся процессов. Основные их отличия заключаются в активности или неактивности исполняемого кода на момент сохранения состояния, а также в форматах хранения состояния процесса. Наиболее проблемный вид миграции с точки зрения реализации – «активный объект, машинный код». Это связано со сложностью «захвата» состояния выполняющегося процесса и с различием форматов хранения этого состояния.

Существующие решения

Рассмотрим некоторые существующие решения, реализующие сохранение и восстановление состояния выполняющегося процесса.

Одним из таких решений является программа «CryoPID» [4], которая способна сохранять состояние запущенного процесса в файл и в дальнейшем запускать этот процесс из файла на той машине, на которой производилось сохранение или же на другой машине, в случае, если на ней установлена ОС Linux и сама «CryoPID».

Особенности «CryoPID»:

• Не требует привилегий root.

• Не требует модификаций ядра.

• Работает под версиями ядра 2.4 и 2.6.

• Работает под x86 и AMD64.

• Может замораживать и размораживать процессы в любое время.

• Может реализовывать миграцию процессов между разными машинами и версиями ядра (2.4 и 2.6).

Механизм сохранения и восстановления состояния выполняющихся процессов встроен в саму ОС Windows последних версий – так называемый режим «Гибернация». Под ним подразумевается режим, при котором состояние системы, а также всех процессов и ресурсов сохраняется на жесткий диск компьютера, после чего происходит отключение питания, а при запуске система возобновляет свою работу с того момента, с которого была введена в состояние «Гибернации».

Также подобный функционал реализуют различные виртуальные машины. Наиболее известными на данный момент являются «Microsoft Virtual PC» [7], «VirtualBox» [8] и «VMWare Workstation» [11].

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

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

Преимущества виртуальных машин:

• Совместимость: виртуальные машины совместимы со всеми стандартными компьютерами x86.

• Изоляция: виртуальные машины изолированы друг от друга так, как если бы они работали на разных физических системах.

• Инкапсуляция: в виртуальных машинах инкапсулируется полная вычислительная среда.

• Независимость от оборудования: виртуальные машины работают независимо от базового оборудования.

• Использование виртуальных машин в качестве структурных элементов виртуальной инфраструктуры.

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

Описание разрабатываемой системы

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

Основные требования к разрабатываемой системе:

1. Система способна сохранять состояние выполняющегося процесса в файл формата XML [5].

2. Система способна восстанавливать выбранный процесс из файла в том же состоянии, в котором он был сохранен, на той же ОС, на которой происходило сохранение.

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

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

Для хранения и передачи состояния выполняющегося процесса был выбран формат XML. Причиной такого выбора является ряд преимуществ XML таких как:

• Независимость от платформы. Так как разрабатываемая система кроссплатформенная, то и формат хранения состояния должен быть также кроссплатформенным.

• Расширяемость. Так как система будет разрабатываться параллельно с исследованием, возможны изменения структуры файла-хранилища. Формат XML является расширяемым, что способствует быстрому и беспроблемному изменению структуры.

• Точная выраженность. Документ XML представляет собой текстовый файл, имеющий точную структуру, которая логична и понятна для конечного пользователя или разработчика. Чтобы посмотреть содержимое XML документа не нужно никаких специальных средств, достаточно простого текстового редактора.

Разрабатываемая система будет состоять из нескольких независимых уровней, которые взаимодействуют посредством открытых стандартных интерфейсов (см. рис. 1). На данной схеме красными стрелками обозначаются команды на выполнение некого функционала, синими – передача данных, результат выполнения запрошенной ранее команды.

Рис. 1. Схема архитектуры системы

Основные уровни разрабатываемой системы:

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

2. Уровень ядра. Реализует основной функционал системы, такой как сохранение и восстановление состояния процесса. Использует набор функций системо-зависимого уровня.

3. Системо-зависимая часть. Содержит код, зависящий от конкретной операционной системы. Этот уровень будет разрабатываться отдельно для каждой операционной системы и, в ходе развертывания приложения на конкретной машине, подменяться.

С точки зрения открытых и адаптируемых систем [1, 2] разрабатываемая система должна удовлетворять требованиям расширяемости, переносимости и интерперабельности:

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

2. Переносимость. Для разработки системы будут использоваться кроссплатформенная библиотека Qt [10]. Данная библиотека позволяет запускать написанное с ее помощью ПО в большинстве современных операционных систем путём простой компиляции программы для каждой ОС без изменения исходного кода. Уровень, зависящий от конкретной операционной системы, будет разрабатываться отдельно для каждой операционной системы и, в ходе развертывания приложения на конкретной машине, подменяться.

3. Интероперабельность. Так как разрабатываемое решение будет иметь открытые интерфейсы, оно может быть использовано частично или полностью в качестве составной части сторонней системы. К примеру, в качестве составной части системы балансировки нагрузки на вычислительные узлы или распределенной отказоустойчивой системы.

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

Библиографический список

1. Лядова Л.Н., Ланин В.В., Шаврин С.М. Стандарты и технологии создания открытых информационных систем: : учеб.-метод. пособие / Перм. ун-т. – Пермь, 2007. – 228 с.

2. Лядова Л. Метамоделирование и многоуровневые метаданные как основа технологии создания адаптируемых информационных систем / International Book Series "Information Science and Computing", С. 125-132.

3. Ferrari A.J. Process State Capture and Recovery in High-Performance Heterogeneous Distributed Computing Systems [Текст]: дис. ... Doctor of Philosophy, Computer Science, January 1998.

4. CryoPID – A Process Freezer for Linux[Электронный ресурс] [Режим доступа: http://cryopid.berlios.de/] [Проверено: 4.06.2011].

5. Extensible Markup Language (XML) [Электронный ресурс] [Режим доступа: http://www.w3.org/XML/] [Проверено: 20.01.2013].

6. Douglis F., Paindaveine Y., Wheeler R., Zhou S., Dejan S. Process Migration // ACM Computing Surveys. Vol. 32, No. 3, September 2000, pp. 241-299.

7. Microsoft Virtual PC [Электронный ресурс] [Режим доступ: http://www.microsoft.com/windows/virtual-pc/] [Проверено: 6.06.2011].

8. Oracle VirtualBox [Электронный ресурс] [Режим доступ: https://www.virtualbox.org/] [Проверено: 5.06.2011].

9. Smith P., Hutchinson N.C. Heterogeneous Process Migration : The Tui System [Текст]. Department of Computer Science University of British Columbia Vancouver, B.C., V6T 1Z4, March 14, 1997.

10. Qt Developer Guides [Электронный ресурс] [Режим доступ: http://qt-project.org/wiki/developer-guides/] [Проверено: 16.01.2013].

11. VMWare – основы виртуализации[Электронный ресурс] [Режим доступа: http://www.vmware.com/ru/virtualization/virtualization-basics/virtual-machine.html] [Проверено: 24.06.2012].

Научный руководитель: старший преподаватель кафедры математического обеспечения вычислительных систем ПГНИУ Фирсов Антон Николаевич

8

Код для цитирования: Скопировать