CC BY
33
УДК 004.451
О ВОССТАНОВЛЕНИИ ПРОГРАММ ИЗ КОНТРОЛЬНЫХ ТОЧЕК
А.Ю. Поляков
ON PROGRAM RESTORATION FROM CHECKPOINTS SET
A.Y. Polyakov
В работе описаны два подхода к проблеме восстановления распределенных программ из контрольных точек. Предложен алгоритм восстановления взаимосвязей типа «родитель-потомок» и алгоритм принадлежности к группам и сеансам для набора процессов в рамках элементарной машины распределенной вычислительной системы. Предложен алгоритм координированного восстановления набора связанных процессов, перезапускаемых раздельно (на различных элементарных машинах или терминалах). Описанные подходы реализованы в системе создания контрольных точек DMTCP (Distributed MultiThreaded Checkpointing).
Ключевые слова: распределенные вычислительные системы, контрольные точки восстановления, отказоустойчивость
In paper two approaches to distributed programs restore problem from checkpoints set are described. Computation node wide algorithm of parent-child relationships and group/session assignement recreation at restore time is proposed. Also coordinated algorithm for process set restoration from several nodes/terminals is designed. Described algorightms are implemented in checkpointing package called DMTCP (Distributed MultiThreaded Checkpointing).
Keywords: RPC, rollback-recovery, checkpointing, fault tolerance
Введение
Распределенные вычислительные системы (ВС) - это важнейший вычислительный инструмент, который используется для проведения научных, инженерных и экономических расчетов [1]. Такие ВС являются большемасштабными, они состоят из сотен тысяч процессорных ядер и имеют производительность порядка PetaFLOPS [2]. Однако даже на таких высокопроизводительных системах многие современные задачи требуют для своего решения дни, недели и месяцы. Несмотря на высокий уровень развития элементной базы и схемотехники, аппаратные ресурсы распределенных ВС не являются абсолютно надежными. В связи с их болынемасштабностью вероятность выхода из строя одной или нескольких составляющих становится достаточно высокой. Отказы процессоров, жестких дисков, сетевых адаптеров, кабелей и шин передачи данных могут повлечь за собой потерю значительного количества промежуточных вычислений, что приведет к снижению технико-экономической эффективности ВС. Таким образом, актуальной задачей является обеспечение отказоустойчивого выполнения программ на распределенных ВС.
Наиболее распространенным подходом к решению данной проблемы является создание контрольных точек (КТ) [3]. В процессе выполнения программы происходит периодическое сохранение ее состояния на надежный носитель данных. В случае отказа производится
«откат» к ближайшей доступной контрольной точке, и работа возобновляется. При этом теряется незначительное количество промежуточных вычислений.
В данной работе описаны два подхода к проблеме восстановления распределенных программ из контрольных точек. Предложен алгоритм координированного восстановления набора связанных процессов, перезапускаемых раздельно (на различных элементарных машинах или терминалах). Разработан алгоритм восстановления взаимосвязей типа «родитель-потомок» и алгоритм принадлежности к группам и сеансам для набора процессов в рамках элементарной машины (ЭМ) распределенной ВС. Данные алгоритмы реализованы в программном пакете создания КТ DMTCP (Distributed MultiThreaded Checkpointing) [4], который позволяет формировать КТ для последовательных, параллельных и распределенных программ в ОС GNU\Linux.
1. Классификация средств создания контрольных точек
Существует достаточно много средств создания КТ (ССКТ) [4-7], каждое из них имеет свои преимущества и недостатки. Рассмотрим несколько подходов к классификации ССКТ.
Существует две основные схемы взаимодействия ССКТ с защищаемой программой: явная и прозрачная (неявная). ССКТ, построенные на основе явной схемы, позволяют задать ограниченный набор информации, которую необходимо сохранить в КТ. Это позволяет снизить объем дискового ввода/вывода, т.е. значительно уменьшает накладные расходы таких ССКТ. Недостатком явной схемы является необходимость модификации исходного кода, что не позволяет применять ее к программам, доступным только в бинарном виде. Кроме того, КТ могут создаваться только в моменты времени, определяемые программой и связанные с завершенностью определенного периода вычислений.
ССКТ, построенные на основе прозрачной схемы, выполняют сохранение КТ незаметно для программы, что обеспечивает простоту и универсальность их использования. Недостатком этой схемы является больший объем дискового ввода/вывода, так как сохраняется все пространство памяти программы.
По классам поддерживаемых программ ССКТ можно разделить на сосредоточенные и распределенные. Сосредоточенные ССКТ обеспечивают отказоустойчивость выполнения одного или нескольких процессов в рамках вычислительного узла. Распределенные ССКТ обычно строятся на базе сосредоточенных и позволяют выполнять создание КТ для распределенных и параллельных программ, что делает их важным инструментом организации функционирования ВС. Для создания распределенной КТ (РКТ) необходимо:
1) создать сосредоточенные КТ для всех процессов, входящих в состав распределенной программы (РП);
2) сохранить граф связей между процессами РП;
3) сохранить сообщения, которые были отправлены, но не доставлены на момент создания РКТ (такие сообщения также называют in-transit).
Для распределенных ССКТ различают координированный и некоординированный подходы. При создании РКТ каждый процесс РП сохраняет свое состояние в КТ. Целостной РКТ [3] называется набор из N локальных КТ, формирующих допустимое состояние программы. Такая РКТ может быть использована для восстановления программы после сбоя. При координированном подходе создание КТ происходит синхронно, что гарантирует целостность РКТ. При некоординированном подходе каждый процесс создает КТ независимо от других. Следовательно, при восстановлении необходимо выполнять поиск целостного состояния программы на основе набора независимых КТ, что вносит дополнительные накладные расходы. Для некоординированного подхода существует опасность возникновения «эффекта домино»,
когда в процессе поиска целостного состояния происходит откат к начальному состоянию программы.
Распределенные ССКТ также можно разделить на универсальные и MPI-ориентированные. Первые позволяют создавать РКТ для любых распределенных и параллельных программ, в том числе для различных реализаций модели передачи сообщений (PVM, MPI). Что касается вторых, то существует несколько ССКТ, построенных на базе конкретных реализаций MPI. Например, OpenMPI [8], MVAPICH2 [9], LAM-MPI [10]. Все они используют ССКТ BLCR [5] для создания сосредоточенных КТ и реализуют собственные механизмы сохранения графа связей и транзитных сообщений.
Для создания КТ сосредоточенного процесса необходимо сохранить информацию о его состоянии. Это может быть реализовано на различных программных уровнях:
1. Уровень операционной системы (ОС). Предусматривает сохранение содержимого пространства ядра и пространства пользователя для всех процессов ОС. Такой подход подразумевает использование систем виртуализации, например, VMWare.
2. Уровень ядра ОС. Предусматривает внедрение дополнительных компонентов, позволяющих сохранить необходимую информацию: содержимое памяти конкретного процесса и состояние ядра, относящееся к нему.
3. Уровень системных библиотек. Предусматривает сохранение содержимого памяти и состояния ядра с использованием средств, предоставляемых ОС для управления процессами.
4. Прикладной уровень. Предусматривает сохранение минимального объема информации, необходимого для восстановления каждой конкретной программы.
Средства создания КТ уровней ядра ОС, ядра и системных библиотек реализуются в рамках прозрачной схемы. Кроме того, некоторые ССКТ уровней ядра и системных библиотек предоставляют программе возможность влиять на процесс обеспечения отказоустойчивости, например, выбирать наиболее удобные моменты для создания КТ. Прикладной уровень предусматривает только явную схему.
Преимуществом первого уровня является простота реализации, а недостатком - значительный объем дискового ввода/вывода и отсутствие гибкости. Второй уровень позволяет получать прямой доступ к внутренним структурам ядра и памяти процесса и выполнять сохранение необходимой для восстановления информации при меньшем объеме ввода/вывода. Недостатком данного подхода является зависимость от изменений в ядре ОС (новые версии ядра ОС GNU\Linux выходят в среднем с частотой раз в 3 - 4 месяца). Также данный подход требует привилегий суперпользователя для установки и управления, а ошибки, допущенные в программном обеспечении уровня ядра, приводят к нарушению работы всей ОС.
Третий уровень позволяет обеспечить создание КТ, не требуя при этом привилегий суперпользователя и не подвергая угрозе функционирование всей ОС. Однако при данном подходе невозможно осуществить прямой доступ к внутренним структурам ядра, которые описывают защищаемый процесс. Для этого требуется перехват и обработка системных вызовов.
На четвертом уровне сохраняется лишь содержимое буферов, которые явно указываются в программе.
2. Distributed MultiThreaded Checkpointing - DMTCP
Программный пакет DMTCP реализован на уровне системных библиотек и является универсальной координированной распределенной ССКТ. DMTCP разработан в Северо-
восточном университете (Northeastern University) США под руководством профессора Дж. Купермана.
Наиболее распространенной сосредоточенной ССКТ на данный момент является пакет BLCR. Кроме того, как было отмечено ранее, он используется во многих распределенных MPI-ориентированных ССКТ. Таблица отражает сравнение ССКТ DMTCP и BLCR по поддерживаемым функциям ОС. BLCR используется для создания сосредоточенных КТ в нескольких MPI-ориентированных распределенных ССКТ.
Таблица
Функции, поддерживаемые ССКТ
Поддерживаемые компоненты ОС DMTCP BLCR
Полностью Частично Полностью Частично
Обработка сигналов X X
Сокеты X - -
Многопоточные приложения X X
Идентификаторы ресурсов ОС (процессы, группы, сессии) X X
Именованные и неименованные каналы X X
Открытые файлы X X
Отображенные (mapped) файлы X X
/pro с файлы X X
Статически скомпилированные программы — — X
Отлаживаемые программы X - -
Из таблицы видно, что DMTCP уступает BLCR по двум параметрам. Во-первых, нет поддержки статически скомпилированных программ, т.к. для перехвата системных вызовов используется «предзагрузка» служебной динамической библиотеки dmtcphijack.so. Однако данный пункт не полностью поддерживается и в BLCR. Во-вторых, отсутствует восстановление идентификаторов ресурсов ОС, таких как идентификаторы групп и сессий. В пространстве ядра в связи с прямым доступом к его внутренним структурам данная задача является более простой. В DMTCP (на уровне системных библиотек) была реализована частичная виртуализация идентификаторов процессов. В данной работе предложен алгоритм, позволяющий более полно восстанавливать идентификационную информацию. Он был интегрирован и используется в DM TCP в настоящее время.
На рис. 1 показан запуск программы с применением DMTCP. В процессе ее работы автоматически осуществляется контроль над созданием новых процессов с использованием системного вызова fork().
hostl$ dmtcp_checkpoint ./programl
Рис. 1. Запуск программы programl под управлением DMTCP па. узле hostl
Как было сказано ранее, DMTCP реализует координированное создание КТ. На каждую вычислительную группу создается один координатор (dmtcp_ coordinator). Он может быть запущен явно, как показано на рис. 2а. Если при запуске программы (рис. 1) процесс координатор не обнаружен, то он будет запущен автоматически.
hostil dmtcp_checkpoint ./program2 hostil dmtcp_checkpoint ./program2 a) 6)
host2$ DMTCP_HOST=hostl dmtcp_checkpoint ./program3
B)
Рис. 2. Использование DMTCP. а) Запуск процесса-координатора на узле hostl, б) Запуск программы ргодгатЁ под управлением DMTCP на узле hostl, в) Запуск программы ргодгатЗ под управлением DMTCP на узле host2
Возможно создание РКТ для нескольких взаимодействующих программ, запускаемых с разных терминалов. Например, как показано на рис. 1 и 26. В этом случае вспомогательный модуль DMTCP, интегрированный в каждую из программ, выполнит соединение с координатором.
Также возможно создание РКТ для процессов, работающих на разных узлах сети. Для этого необходимо указать через переменную окружения DMTCP_HOST адрес узла, на котором выполняется координатор. Так, на рис. 2в показан запуск программы ргодгатЗ, которая подключается к вычислительному процессу, уже содержащему программы programl и ргодгат2.
Создание РКТ происходит следующим образом: каждый процесс сохраняет свое состояние в отдельном файле, а координатор формирует shell-скрипт, содержащий последовательность действий, необходимых для запуска вычислений из данной РКТ.
1. Восстановление открытых файлов и псевдо-терминалов
2. Восстановление сетевых подключений
3. Запуск восстанавливаемых программ (fork)
4. Восстановление файловых дескрипторов
5. Восстановление областей памяти и нитей
6. Восстановление буферов ядра
7. Продолжение работы
Discovery служба
(поиск адресов после аосстаноал сгний)
Нити программы
Синхронизация служебных нитей
Служебная нить
Приостановленные нити Сигнал возобновления
Рис. 3. Восстановление вычислений из РКТ DMTCP
Как показано на рис. 3, на этапе восстановления на каждом узле запускается один служебный процесс, использующий РКТ для воссоздания компонентов программы (этап 3). Для синхронизации узлов используется этап восстановления сокетов (этап 2).
Недостаток данной схемы заключается в том, что процессы, выполнявшиеся на разных терминалах, будут перезапущены уже на одном. Например, DMTCP используется в качестве основы для универсального реверсивного отладчика URDB [11]. Типичным сценарием
применения URDB является подключение (attach) к уже выполняющейся программе и ее отладка. При восстановлении такой отладочной сессии необходимо сохранить принадлежность к разным терминалам, однако отсутствие средств синхронизации не позволяет этого сделать.
Рассмотрим другой пример: восстановление из контрольной точки группы процессов, распределенных по разным узлам сети. Процессы разбиты на подгруппы, не связанные между собой постоянными сетевыми соединениями. В этом случае барьер, образованный этапом 2 (Recreate and reconnect sockets), не является достаточным для синхронизации. Если одна подгруппа была запущена значительно раньше остальных, ее выполнение будет продолжено, а остальные подгруппы не будут иметь возможности возобновить работу.
Для устранения указанных недостатков был предложен дополнительный компонент схемы синхронизации, который представлен в данной работе.
3. Дополнительные компоненты схемы синхронизации
В DM TCP предусмотрен барьер, позволяющий синхронизировать восстановление из РКТ только для процессов, связанных постоянными сетевыми соединениями. Как было показано в разделе 3, существуют программы, для которых это условие не выполняется. Для устранения этого недостатка было предложено расширение существующей схемы синхронизации, которое будет рассмотрено далее.
Координатор
Каждый процесс в DMTCP имеет уникальный идентификатор uID (unique ID), который формируется из трех компонент: <хеш-код имени сетевого узла>-<РЮ>-<временная метка>. Координатор играет роль службы, предоставляющей сервис синхронизации. Его состояние подстраивается под выполняемые задачи и не сохраняется в РКТ. В качестве синхронизационного условия выбрано число процессов, принадлежащих вычислительной группе (ВГ) на момент создания контрольной точки. Как показано на рис.
4, для идентификации ВГ (CID - computational group ID) используется uID процесса, который выполнил подключение первым. Если приходит запрос на подключение от другой
ВГ (процесс 3 на рис. 4), то оно отклоняется. На этапе создания РКТ координатор рассылает CID текущей ВГ и число ее участников (пр - number of process). Эта информация сохраняется в каждой локальной КТ. При отключении последнего процесса из текущей ВГ координатор переходит в состояние CID—? и готов принимать новые запросы на услуги синхронизации от других ВГ. На этапе восстановления (рис. 5) процесс считывает CID и пр из КТ и отправляет координатору при подключении. Если координатор не занят обслуживанием других заявок, он устанавливает параметр CID в значение, которое содержится в сообщений. Также запоминается количество клиентов, которое должно выполнить подключение до того, как можно будет продолжить вычислительный процесс. Если подключение выполняет клиент, не имеющий CID или имеющий CID, который отличается от текущего, то такое соединение отклоняется.
Координатор
Рис. 5. Восстановление из РКТ
4. Алгоритм восстановления идентификационной информации
Как было сказано ранее, восстановление идентификационной информации на уровне системных библиотек затруднено отсутствием прямого доступа к внутренним структурам ядра ОС GNU\Linux. Для решения данной проблемы автором предложен алгоритм восстановления идентификационной информации, который имитирует процесс первоначального запуска набора процессов.
4.1. Идентификационные ресурсы
В ОС GNU\Linux процесс описывается набором идентификаторов. Первый из них -идентификатор процесса PID (process ID). PID назначается при создании системными вызовами fork() или vfork() и используется для того, чтобы указать на процесс в ряде важных системных вызовов, таких как kill(), ptraceQ, setpriority(), waitpid(). Отношение родитель-потомок строится на основе PID. Процесс, выполнивший системный вызов fork, становится родителем созданного процесса. Для доступа к информации об идентификаторе родителя (parent PID - PPID) используется системный вызов getppid(). Если процесс завершается, а потомки продолжают существование, их родителем становится системный процесс init, имеющий PID=1. Каждый процесс принадлежит к одной и только одной сессии, для создания новой используется системный вызов setsidQ. Идентификатор сессии SID (session ID) равен идентификатору процесса-создателя (или лидера). Принадлежность к сессии наследуется потомком от родителя. Каждый процесс принадлежит к одной и только одной группе. Если его идентификатор совпадает с идентификатором группы, то он называется ее
лидером. Все процессы группы принадлежат одной и только одной сессии. Данные механизмы используются командными интерпретаторами при организации конвейеров, некоторыми отладчиками для управления отлаживаемыми программами и т.д.
4.2. Постановка задачи
Пусть имеется множество контрольных точек С = {с*}, г = 1... /V , каждая из которых
однозначно соответствует восстанавливаемому процессу Рг € Р . КТ описывается четырьмя
параметрами с* = (pidi,ppidi,sidi,imgi), где: pidi - уникальный идентификатор (V*,,? =
1....ЛГ, * ф ],ргё^ ф р{й]) в рамках ЭМ ВС; рр')л1г - идентификатор процесса, создавшего рг
через системный вызов /огк(); sidi - идентификатор сессии, если pidi = sidi , то КТ сц
содержит процесс-лидер сессии sidi^, тгд, - сохраненное состояние процесса, необходимое
N
для его перезапуска. Обозначим через в = и sidi множество уникальных идентификаторов
г=1
сеансов, к которым принадлежат процессы из Р. Пусть в = {5^}, к = 1...|в| - множество сеансов, где 5^ = {сг |сг- £ С. 81^1.1 = *>■} - подмножество КТ, содержащих процессы одного
сеанса. Очевидно, что С = и Бц и Укх,к2 = 1...|з|,/г1 ф П Бк2 = 0- Пусть также
вкев
определено множество Я = {с,|\/? = 1...А7, ] ф '¡,,рр'и1г ф pгdj} независимых КТ.
Требуется, используя программный интерфейс ОС СКЦ\Ыпих, выполнить запуск процессов из контрольных точек так, чтобы восстановить их исходную иерархию и принадлежность к сеансам. При этом для изменения сеанса имеется только системный вызов setsid(), который позволяет процессу создать собственный сеанс, в котором он становится лидером.
4.3. Алгоритм восстановления иерархии процессов и сеансов
На вход алгоритма подается множество контрольных точек С. Алгоритм состоит из следующих шагов:
4.3.1. Формирование отношений типа родитель-потомок
Строится лес деревьев Т = {Тг}. I = 1...|Д| (рис. 6), для которого определена функция однозначного соответствия / между КТ и узлами деревьев леса: / = {(¿, с)|В/ = 1...|Д|,< € 7}, с £ С, t 4Ф с}. Справедливы следующие утверждения:
1. \/Т; € Т, если ¿-корень Т/, то /(¿) £ Л
2. VI) € Т,¿2 £ 2), ¿1 - непосредственный потомок ¿2 Зг',.7 : С{ = = /(£2) и
pidi = ppidj
Рис. 6. Лес деревьев Т, соответствующий восстанавливаемым КТ
4.3.2. Построение метаинформации
Для того, чтобы восстанавливать принадлежность к одной сессии процессов, которым соответствуют узлы различных деревьев, выполняется построение метаинформации. Для каждого дерева 7} Е Т выполняется его обход в глубину. Для каждого обрабатываемого узла £ Е 2] определяется номер соответствующей ему КТ г : с* = /(¿). Строится метаинформация, которая представляется в виде пары (хгк,угк), где х1кЕх1,
хг = {хк\хк = sidj,j — 1...|АГ|,/_1(с^) € ЗиЬТгее(1)},
Ук
3Cj Е С : f-i(cj) Е SubTree(t),
О, иначе.
Второй компонент пары (ук) указывает на наличие или отсутствие лидера сессии с идентификатором хгк. На рис. 7 показан пример сбора метаинформации. Рассмотрим узел X, которому соответствует метаинформация, состоящая из одной пары (SID3,0). X является листовым и не является лидером SID3. Корень дерева (узел Y) содержит метаинформацию из четырех пар: (SID1,1), (SID2,1), (SID3,1), (SIDA, 1). Это означает, что на текущем и нижележащих уровнях дерева имеется четыре сессии с идентификаторами SID 1, SID2, SID3, SIDA для каждой из них были найдены лидеры.
(StD-i ,1 )(SID2,1 ) (SID3,1)(SíD4,1)
(SiD4,1) i
у
Рис. 7. Построение метаинформации
4.3.3. Построение зависимостей между элементами Т
Каждому узлу t ET ставится в соответствие множество D(t) — 0. Далее выполняется обработка метаинформации, соответствующей корням деревьев из леса Т. Пусть Тмг, Тм2 £ Т, как показано на рис. 8. Пусть t± - корень Тщ, ¿2 ~ корень Тм2, hj~ соответствующие индексы КТ: с* = f(ti),Cj = /(¿г)- Тогда Тм2 зависит от Тмг, если Зк\,к2 ■ хгк — х^ V уЗк = 1 V ук = 0. В этом случае выполняется поиск лидера сессии xkl - t = /~1(q) : pidi = sidi = Xk И модифицируется соответствующее множество D(t) = D(t) U {¿2} •
На рис. 8 показано, что метаинформация корня дерева Тм2 указывает на отсутствие лидера сессии SIDв Тм2- Пара (SIDк, 1), соответствующая корню дерева Тд,/,, указывает на наличие узла t и контрольной точки с = /(¿), содержащей лидера SIDТогда считаем, что дерево Тм2 зависит от узла t. То есть при запуске процессов из КТ сначала должна быть восстановлена КТ, соответствующая с, и создана новая сессия SIDа после этого восстановлено дерево Тм2 ■
УС
...<SIDKf1)...........(SJDk,0)...
ti
(Т
т ; с
• М1 : sid=SIDk
т,
М2
т
(RI
Рис. 8. Построение зависимостей между деревьями леса Т
4.3.4. Запуск процессов из КТ
Для всех независимых деревьев (\/Т; 6 'Г : I = гоо/,(Т() V В(Г) = 0) выполняется восстановление исходной структуры процессов с использованием /огк() и setsid() по алгоритму, приведенному ниже.
procedure restore(t,psid)
1: i-^k: (ck == f(t))
2: if pidi ^ sidi then 3: for t\ <r- childs(t) do
4: fork() V restore(f(tl),psid)
5: end for
6: start(ci)
7: else
8: for ti 4— childs(t) do
9: j <r- k : (ck == /(ij)
10: if sidj 7^ pidi then
11: if forkQ = 0 then
12: restore(f (tl), psid)
13: end if
14: end if
15: end for
16: psid = setsidQ
17: for t 4- D(t) do
18: if forkQ — 0 then
19: if forkQ = 0 then
20: restore(f(tl),psid)
21: else
22: exit( 0)
23: end if
24: end if
25: end for
26: for ti 4- childs(t) do
27: j 4- k : (ck == /(¿i))
28: if sidj — pidi then
29: if forkQ = 0 then
30: restore(f(ti),psid)
31: end if
32: end if
33: end for
34: start(f(t))
35: end if
5. Экспериментальные данные
На рис. 9 показаны структуры двух программ, для которых были созданы КТ с применением ССКТ DMTCP.
а)
б)
Рис. 9. Структуры тестовых программ
На рис. 10 показаны отношения между восстановленными процессами без применения разработанного алгоритма. Как видно из рис. 10а, все процессы принадлежат одной сессии, а процесс р'2, который должен быть потомком тй(РЮ 1), является потомком р1. На рис.
106 мы также видим, что принадлежность к сессиям не восста
hostS ря axjf
рте BID PGXD SID С0ММАЮ hostS ps aixjf
і 6514 6514 HIT і/bin/login — PPID BID PGIÍ3 SID
€514 П87Э 11879 6514 \_ -bash 1 SSI 4 6514 6514
1187$ 20757 28757 6514 \ < pi 6514 11879 :iB79 €514
28757 28770 2875? 6514 V-, 12079 32163, 32161 6514
2877Q 28771 28757 6514 і І (mtcp^xestart] <--» p2l| 32161 32172 32161 6514
28773 28175 287S7 $514 1 1 \ Jsatcp restart! < P2Z| 32161 32173 32161 6514
гю$і 28772 3&757 6514 32161 32176 32161 6514
28757 28776 28757 6514 < pl2 32176 32177 32161 6514
2ЮЫ 26777 2875? SSI 4 C^tcp restart) <--- pl3 32176 32180 32161 6514
2&771 SS17B 28757 6514 f®fccp_£«5tart} <« — pl3l 32X76 32182 32161 6514
2Є777 28783 28-75? 6514 ¿»tep_r«s t« St ] < pi 32
сшяит /bin/login —
\_ -bash
{j&tcp^restax-tj <-—pi \ [ffitcp jE-astare.] <—-pll \ ^ [»tcp restar ti <—pl2
\_ [r»tcp_restaxti <--------pl3
\_ {mtcp_res t* г fc I <-----pI31
\_ } <------pl32
• fatcg>_E®stac t} <—-pl 33
a)
6)
Рис. 10. Восстановление с неполным учетом идентификационной информации
На рис. 11а, 116 приведены результаты восстановления из КТ с применением предложенного алгоритма для соответствующих программ рис. 9. Рассмотрим более подробно рис. 11а. Очевидно, что процессы р13, р131, р132, р2, р21, р22 принадлежат одной сессии, лидером которой является р13, как это и должно быть. Остальные процессы принадлежат сессии командного интерпретатора. Элемент р2 восстановлен, как наследник тії (РШ=1). На рис. 116 процессы рІЗ, р133 находятся в новой сессии, в которой р13 является лидером. При этом потомки р13 - р131 и р132 остались в сессии командного интерпретатора, как это было в исходной программе.
т*> РГВ РСИЗ X 5949 3949
5»4? 15323 10323 50323 10349 10349 50349 2.0362 30349 хат 10374 юз*«* 10361 1Q375 19349 1036'}. 10376 3,03*761 10376 10378 103761 Ю316 т.0379 гоз7в|
SID
5949 /bin/login --5949 Ч_ "!a*ah S?49 tftc -ad
SN? <-----
5Э4Ф \ _ [atcp_ restart]
S?48 \_ [®tcp reetarfc) <-"■ -
МЩ
.037«
Я37*
l 10381 10376 |lS3?ß 10381 IÖ383 15376 ¡10Э7« 1038t 10364 10376»037«
{®tcp_restarti \_ {SBtCp_t*3t4.rtJ <■ \ (ratcp_r«start) <•
|ffltcp__r©starc] |
\_ i3Stcp_reat;*3rtJ
[sfecp_re«t*stj <-■
■— p21
-----pZZ
pll pl2 pl 3
pm • pi3a
fcoet-l js>a axjf Pf»tD &ID PGID SID СОМШШ
I 6514 $514 6514 /Ып/login -
€514 11879 11379 11S79 14820 14820 14820 14S35 I482Q 14820 1483S 14820 14820 14837 14837 14837 14вз7 14338 неге ftSTTI 14837 14S39 1462Э 165141 14837 14844 14837 14837
\ -b*sh
|mscp xest&rej <-— pl
[mfccp_restart] <--- pll \_ {eifccp__r es tart} <—- pl2
[mfccp_restarfc| <-----|»23
\_ (mtcp_ir»srt«et.3 <----pl31
[mtcp^r*st*ct] <--- p!32
\_ [mtcp_EescaEtj <—- pL33
a) 6)
Рис. 11. Полное восстановление идентификационной информации
PPI0 BID P&TD SXD TTY ОСШШ
16315 16324 16324 16324 pts/0: bash
16324 16356 16356 16324 |> fcs/Ö i V. 010
163S6 24203 16356 16324 pts/0I \_ £mfcep_r*Ä t*x t]
16315 21247 2124? 21247 Cts/T basfc
21247 21617 2161? 21247[pte/2 mc -u&
2161? 24223 21617 21247 jpts/2 \_ £mtcp_xes tart]
Рис. 12. Восстановление процессов на разных терминалах
На рис. 12 показано восстановление тестовой программы. Она состоит из двух процессов, взаимодействующих через механизмы IPC. Запуск компонентов выполнен с двух различных терминалов: pts/0 и pts/2. До реализации предложенного расширения схемы синхронизации подобное восстановление исходными средствами DMTCP было невозможно.
Заключение
В работе были рассмотрены подходы к восстановлению программ из распределенных контрольных точек, реализованные в CCKT DMTCP. Предложен алгоритм восстановления отношений родитель-потомок и алгоритм принадлежности к сессиям и группам с использованием стандартного механизма системных вызовов ОС GNU\Linux. Так как DMTCP реализован на уровне системных библиотек, он не имеет прямого доступа к внутренним структурам ядра. Следовательно, для восстановления указанных отношений между процессами требуется имитация основных шагов их запуска. Для этого выполняется построение древовидной структуры, отражающей родственные отношения между узлами. Далее происходит сбор метаинформации, содержащей описание принадлежности к сессиям. Разработанный алгоритм позволяет расширить диапазон программ, поддерживаемых DMTCP. Расширена схема синхронизации, используемая в DMTCP: добавлен новый барьер, позволяющий выполнять восстановление процессов из РКТ на различных терминалах, расположенных на одном или разных узлах сети. Это позволяет использовать DMTCP для восстановления из РКТ программ, которые не связаны постоянными сетевыми соединениями. Предложенная доработка также необходима для организации реверсивной отладки, построенной на базе DMTCP[ 11].
Статья рекомендована к публикации программным комитетом международной научной конференции «Параллельные вычислительные технологии 2010».
Работа проводилась при финансовой поддержке РФФИ (гранты 08-07-00018, 08-07-00022, 08-08-00300, 09-07-00185, 09-07-12016, 09-07-13534, 09-07-90403)
Литература
1. Хорошевский, В.Г. Архитектура вычислительных систем / В.Г. Хорошевский. - М.: МГТУ им. Н.Э. Баумана, 2008. - 520 с.
2. ТОРбОО supercomputer site [Электронный ресурс].- Режим доступа: http://www.top500.org/ . - Загл. с экрана. - яз. англ.
3. A survey of rollback-recovery protocols in message-passing systems / E.N. Elnozahy, L. Alvisi, Y.M. Wang, D.B. Johnson // ACM Computing Surveys. - 2002. - V. 34, № 3. - P. 375 - 408.
4. Ansel, J. DMTCP: Transparent Checkpointing for Cluster Computations and the Desktop / J. Ansel, K. Arya, G. Cooperman // Proc. of IEEE International Parallel and Distributed Processing Symposium (IPDPS’09). - Rome, 2009. - P. 1 - 12. - ISBN: 978-1-4244-3751-1.
5. Hargrove, P.H. Berkeley Lab Checkpoint/Restart (BLCR) for Linux Clusters / P.H. Hargrove, J.C. Duell //In Proceedings of SCIENTIFIC DISCOVERY THROUGH ADVANCED COMPUTING (SciDAC 2006). - Denver, 2006. - V. 46. - P. 494 - 499. - ISSN 1742-6588.
6. Checkpoint and migration of UNIX processes in the Condor distributed processing system / M. Litzkow, T. Tannenbaum, J. Basney, M. Livny // Technical report 1346, University of Wisconsin, Madison. - Wisconsin, 1997. - P. 8.
7. Libckpt: Transparent checkpointing under Unix / J.S. Plank, M. Beck, G. Kingsley, K. Li //In Proc. of the USENIX Winter 1995 Technical Conference. - New Orleans, 1995. -P. 213 - 323.
8. The design and implementation of checkpoint/restart process fault tolerance for Open MPI / J. Hursey, J. M. Squyres, Т. I. Mattox, A. Lumsdaine //In Proceedings of the 21st IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE Computer Society. - Long Beach, 2007. - P. 1 - 8. - ISBN: 1-4244-0910-1.
9. Application-transparent checkpoint/restart for MPI programs over InfiniBand / Q. Gao, W. Yu, W. Huang, D. K. Panda // Proceedings of the 2006 International Conference on Parallel Processing / IEEE Computer Society. - Washington, 2006. - P. 471 - 478.
10. FT-MPI, Fault-Tolerant Metacomputing and Generic Name Services: A Case Study / D. Dewolfs, J. Broeckhove, V. Sunderam, G. Fagg // Lecture Notes in Computer Science, Springer Berlin. - Heidelberg, 2006. - P. 133 - 140.
11. Temporal Debugging using URDB / A.M. Visan, A. Polyakov, P.S. Solanki, K. Arya, T. Denniston, G. Cooperman // 2009. - Режим доступа: http://arxiv.org/abs/0910.5046vl.
Поляков Артем Юрьевич, лаборатория вычислительных систем, институт физики полупроводников им. А.В. Ржанова СО РАН, [email protected].
Поступила в редакцию 16 апреля 2010 г.
