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

2.1 Обзор и установка инструментов

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

Для метода согласованных контрольных точек изначально рассматривался Cornel preCompiler, но в связи с тем, что на сайте Корнелльского университета отсутствовала ссылка на скачивание компилятора, был сделан запрос авторам статьи (источник [2]). Из их ответа следовало, что работа над проектом велась более 15 лет назад, и на данный момент не сохранилось ни исходного кода, ни самого компилятора. Поэтому был выбран другой инструмент, реализующий тот же метод - CPPC Framework. приложение тестирование интерконнект сбой

CPPC Framework

Для установки CPPC необходимо скачать архив с официального и распаковать его. Чтобы сконфигурировать пакет командой “./configure” для системы Десмос не требуется никаких специальных параметров. Однако поддержку MPI можно отключить флагом “--with-mpi=no”. С помощью команды “make && make install” пакет будет установлен.

Для работы CPPC разработчику необходимо расставить директивы для компилятора. Доступные директивы: “cppc execute/end execute”- используется для того, чтобы обозначить блок кода, который будет выполнен при перезагрузке приложения; “cppc checkpoint” - директива устанавливается в критических блоках кода, где может произойти сбой, указывает компилятору, в какой момент записывать контрольную точку; “cppc checkpoint loop” - директива устанавливается перед циклами, компилятор примет во внимание коммуникации между процессами и запишет контрольную точку в первом безопасном месте, которую сможет найти в теле цикла.

Код программы для проверки находится в приложении Б.

Fault Tolerance Interface

Для установки FTI необходим cmake версии 3.3.2 или выше, в то время как на системе Десмос в момент написания работы установлена версия 2.8.12.1, кроме того, для установки версии 3.3.2 необходим компилятор, поддерживающий C++11 (gcc версии 4.8.1 или выше, а в момент написания была 4.3.4). Учитывая ограниченность прав пользователей на Десмосе возможна только локальная установка компилятора и конфигуровщика. Этот момент стоит подчеркнуть при использовании данного инструмента обеспечения отказоустойчивости, так как он требует дополнительных действий от пользователя. Для установки пакета требуется выполнение команды “cmake && make all install”.

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

Работа FTI настраивается при помощи конфигурационного файла config.fti. В этом файле настраиваются различные параметры MPI, такие как “Node_size” - для указания количества процессов, запускаемых на одном узле, а также временные интервалы (в минутах) записи и чтения контрольных точек для каждого из четырех уровней: “Ckpt_L1” - для уровня локальной записи, “Ckpt_L2” - для уровня копирования на партнерские узлы, “Ckpt_L3” - для уровня кода Рида - Соломона и “Ckpt_L4” - для уровня записи параллельной файловой системы. Разработчики библиотеки рекомендуют устанавливать интервалы в возрастающем порядке с одинаковым шагом (самый низкий для низшего уровня и самый высокий - для высшего).

Для работы FTI в пользовательском коде необходим импорт библиотеки fti.h, а также вызов подпрограммы FTI_Init. В месте, где требуется запись контрольной точки, следует вызвать подпрограмму FTI_Snapshot. С помощью подпрограммы FTI_Protect можно явно задать объекты, чье состояние следует сохранять. Пример тестовой программы с использованием библиотеки FTI представлен в приложении В.

User Level Failure Mitigation

Установка ULFM для сети «Ангара» не требуется, так как библиотека MPI для этой сети построена на MPICH версии 3, где поддержка ULFM включена по умолчанию. Чтобы менеджер задач автоматически не очищал процесс при сбое требуется прописывать флаг “ --disable-auto-cleanup” при запуске через mpiexec и флаг “ --no-kill” при запуске через sbatch (при использовании очереди задач Slurm).

Главными функциями при работе с ULFM являются “MPIX_Comm_revoke(MPI_Comm comm)” - прерывает все коммуникации, ожидающие на коммуникаторе на всех рангах, “MPIX_Comm_shrink(MPI_Comm comm, MPI_Comm* newcomm)” - создает новый коммуникатор, из которого изъят мертвый процесс.

Для использования данного инструмента программист должен заранее предусмотреть, что именно будет делать MPI-программа при сбое и потере определенного процесса, сможет ли она продолжать работу, как уведомить об этом другие процессы, и как они должны на это отреагировать. Код тестовой программы с использованием средств ULFM представлен в приложении Г.

2.2 Разработка тестов

Способы эмуляции сбоев

При разработке тестов были рассмотрены следующие способы эмуляции сбоев:

- Прерывание программы извне в случайный момент с помощью POSIX-сигнала SIGINT

- Прерывание программы изнутри, используя функцию exit()

- Завершение процессов на случайном узле командой из головного узла

- Отключение сетевого интерфейса

- Сбой файловой системы при помощи удаления её файла

Виды задач с различными объемами сохраняемых данных

Чтобы проверить эффективность методов для различных типов задач были рассмотрены следующие их виды:

- Задача расчёта с относительно низким потреблением оперативной памяти с периодическим использованием системы ввода/вывода

- Задача расчёта с относительно низким потреблением оперативной памяти с непрерывным использованием систем ввода/вывода

- Задача расчёта с относительно высоким потреблением оперативной памяти с периодическим использованием системы ввода/вывода

- Задача расчёта с относительно высоким потреблением оперативной памяти с непрерывным использованием систем ввода/вывода

Здесь, высокое потребление оперативной памяти определяется порядком нескольких гигабайт, а низкое - порядком несколько десятков мегабайт.

2.3 Результаты выполнения тестов и сравнение программных реализаций методов

Тесты проводились на кластере «Десмос», состоящем из 32 узлов, соединённых интерконнектом «Ангара». Топология сети - 4D-тор размерности 4 2 2 2.

Характеристики вычислительного узла:

- 2х Intel Xeon CPU E5-2630 @ 2.30GHz (6 cores);

- Linux 3.0.101-63-default x86_64;

- 64 GB RAM [10].

Из особенностей Ангары от других интерконнектов стоит отметить собственную реализацию MPICH. Ангара использует некоторые принципы интерконнектов IBM Blue Gene L/P and Cray Seastar2/Seastar2+. Среди интерфейсов мультипрограммирования поддерживаются MPI и OpenMP. Каждый узел имеет выделенную область памяти, доступную для удаленного доступа из других узлов (чтение, запись, атомные операции) для поддержки OpenSHMEM и PGAS [11]. Одним из наиболее используемых программных пакетов на кластере Десмос является пакет классической молекулярной динамики LAMMPS, использующий интерфейс MPI.

Задачи запускались при помощи планировщика очереди задач Slurm (используя скрипт и команду sbatch). Тесты и проверяемые программы написаны на языке C, скрипты, управляющие тестами и прерыванием процессов написаны на bash. Все вычисляемые задачи используют интерфейс MPI для коммуникации между процессами.

Все тесты проводились минимум 10 раз, с последующим усреднением полученных значений. Перед выполнением тестов с эмуляцией различных типов сбоев был произведен запуск задач четырёх различных типов, перечисленных в разделе 2.2.2., без использования каких-либо инструментов обеспечения отказоустойчивости. Среднее время выполнения задач (в секундах) представлено на графике (рис. 3).

Рис. 3. Время выполнения задач без использования средств отказоустойчивости

Здесь (и далее): TT1 - время выполнения задачи (далее T1) расчёта с относительно низким потреблением оперативной памяти с периодическим использованием системы ввода/вывода (пример задачи в приложении В), TT2 - время выполнения задачи (далее T2) расчёта с относительно низким потреблением оперативной памяти с непрерывным использованием систем ввода/вывода (та же задача, но с записью результатов в файл при каждой итерации), TT3 - время выполнения задачи (далее T3) расчёта с относительно высоким потреблением оперативной памяти с периодическим использованием системы ввода/вывода (пример задачи в приложении Б), TT4 - время выполнения задачи (далее T4) расчёта с относительно высоким потреблением оперативной памяти с непрерывным использованием систем ввода/вывода (та же задача, но с записью результатов в файл при каждой итерации).

Ниже приведены графики зависимости времени выполнения от количества отказавших узлов (в процентном соотношении) для четырех разных типов задач и трех различных инструментов восстановления задач после сбоев (рис. 4). Для остальных видов сбоев отклонение значения времени выполнения составило не более 5%. Все задачи запускались одновременно на 16-ти узлах. При этом использовались только А-узлы, имеющие процессоры по 6 ядер на узел. Всего - 96 ядер. По причине активной работы других пользователей на кластере «Desmos», очередь задач slurm не была способна выделить большее количество узлов за разумное время.

Результаты выполнения тестов для задачи типа T1 демонстрируют самые высокие накладные расходы для управления системой отказоустойчивости при использовании инструментов ULFM, при этом для задачи T2 при отказе одного или четырех узлов этот способ является более эффективным, чем остальные. Способ FTI характеризуется слабой зависимостью от количества отказавших узлов, с увеличением этого количества время выполнения увеличивается незначительно. Зависимость способа CPPC от количества отказавших узлов выражена значительнее, поэтому при большом количестве отказавших узлов этот способ менее эффективен, чем FTI.



Рис. 4. Графики зависимости времени выполнения от количества отказавших узлов для задач типа T1 и T2

Здесь (и далее):

- ST - время выполнения без использования инструментов отказоустойчивости;

- CPPC - время выполнения задачи с использованием CPPC;

- FTI - время выполнения задачи с использованием FTI;

- ULFM - время выполнения задачи с использованием ULFM.

Из результатов тестов при решении задач типов T3 и T4 следует (рис. 5), что способ ULFM является наименее эффективным из рассмотренных. Несмотря на то, что при отказе одного или двух узлов способ CPPC является более эффективным, чем FTI, выигрыш во времени незначительный, порядка десятых долей секунды. Тем не менее при увеличении количества отказавших узлов, эффективность способа FTI выше чем у ULFM.



Рис. 5. Графики зависимости времени выполнения от количества отказавших узлов для задач типа T3 и T4

В таблице 3 представлены результаты общего сравнительного анализа рассмотренных инструментов.

Таблица 3 Сравнительный анализ рассмотренных инструментов

Инструмент	Достоинства	Недостатки
Cornell Checkpoint preCompiler	Простота использования управляющих директив и команд; Подробная документация.	Критический недостаток: отсутствие открытых ссылок на скачивание инструментария.
Инструмент	Достоинства	Недостатки
CPPC Framework	Универсальность (независимость от архитектуры и операционной системы); Портативность (создает портативные файлы контрольных точек и не использует традиционных решений, таких как координация процессов и журналирование сообщений)	2% ко времени выполнения в качестве накладных расходов на запись контрольных точек в файл.
FTI	Позволяет пользователям самостоятельно определять множества данных, которые должны быть записаны в многоуровневую контрольную точку; Позволяет выделить отдельный процесс на каждом узле, в котором будут исполняться задачи, связанные с обеспечением отказоустойчивости.	Эффективность использования зависит от программиста, выбирающего места записи контрольных точек; Требуется ручное проставление директив и команд в коде программы, для этого требуется ознакомиться со внушительной документацией.
ULFM 2.0 (MPICH)	Встроенное в MPICH решение, по умолчанию используемое Ангарой; Эффективно работает для модели процессов master-slave.	Необходимо балансирование нагрузки; Не подходит для модели больших синхронных процессов.

По результатам, полученным в результате тестирования рассматриваемых инструментов следует заметить, что в большинстве случаев набор инструментов ULFM уступает другим инструментам, кроме случая решения задачи типа T2 при количестве отказавших узлов менее 13% от всех работающих узлов. Кроме того, этот способ не подходит для решения задач с моделью больших синхронных процессов.

Набор инструментов CPPC показал наилучшее время при решении задач всех типов, кроме T2, однако при увеличении количества отказавших сбоев (более 10% от общего числа) этот способ проигрывает FTI. Инструменты FTI добавляют большие накладные расходы, чем CPPC при отказе 1 узла, однако с увеличением количества отказов эти расходы увеличиваются незначительно.

Таким образом, на основании выше полученных результатов, для дальнейшей работы и реализации системы восстановления после сбоев была выбрана библиотека Fault Tolerance Interface.



Глава 3. Описание практической части

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

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

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

3.1 Реализация системы тестирования

Система тестирования состоит из пакета последовательно выполняемых тестов, эмулирующих различные сбои (внезапное завершение программы извне, отказ сетевого интерфейса, отказ файловой системы, самостоятельное завершение одного из процессов). При запуске пакета тестов необходимо указать тип задачи, один из четырёх, описанных в разделе 2.2.2. Для каждого из типов задач будет исполнен код для конкретного типа и способа обеспечения отказоустойчивости. Способы описаны в разделе 2.1. Также можно указать количество узлов, которые будут задействованы при решении задачи и количество узлов, которые откажут во время выполнения теста.

Из вышеописанного следует следующий набор входных параметров:

- Тип задачи (по объему используемой памяти) (далее TT), допустимые значения: целое число от 0 до 3 (соответствующие порядку изложения в разделе 2.2.2.);

- Тип инструмента обеспечения отказоустойчивости (далее FT), допустимые значения: целое число от 0 до 2 (где 0 - для CPPC Framework, 1 - для FTI и 2 - для ULFM 2.0);

- Количество узлов, используемых для решения задачи (далее WN), допустимые значения: целое число от 1 до 32;

- Количество узлов, которые должны отказать (далее FN), допустимые значения: целое число от 1 до 31, но строго меньше WN.

Общий принцип работы тестовой системы продемонстрирован на рисунке 6.

Рис. 6. Принцип работы тестовой системы

По окончанию выполнения тестов фиксируется время, затраченное на работу программы, включая время, затраченное на восстановление задач после сбоев. Для каждого запуска тестов создается файл с результатами в формате csv (comma separated values) с парами значений построчно: 1 строка - тип сбоя, 2 строка - время, затраченное на выполнение. Данный файл может быть открыт и обработан средствами Microsoft Office Excel. Также в отдельный текстовый файл записывается журнал событий с метками времени для более детального анализа, данный файл главным образом содержит информацию о времени возникновения сбоя и о времени возобновления работы программы.

3.2 Реализация системы восстановления задач после сбоев

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

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

Разработанная программа работает со следующими входными параметрами:

- Ссылка на файл, содержащий код программы на языке C;

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

При запуске программа создаёт файл конфигурации config.fti, содержащий значения по умолчанию, включая интервал записи контрольных точек различного уровня в минутах, рекомендованный разработчиками FTI. Затем создает директории “Local”, “Global”, “Meta”, куда будут записывать файлы контрольных точек. Далее программа сканирует файл программы в поисках команды MPI_Init, после которой вставляет команду инициализации FTI - FTI_init, передавая в качестве аргументов ссылку на ранее созданный файл конфигурации и MPI_COMM_WORLD в качестве коммуникатора. Таким же образом программа вставляет команду FTI_Finalize перед найденной в коде команды MPI_Finalize. В случае, если одна из команд не найдена, программу завершит работу с ошибкой.

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

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

Пример вызова программы: «./ftize program.c crtiticalArray counter currentResult», где “ftize” - название утилиты, “program.c” - путь к коду программы пользователя, “crtiticalArray counter currentResult” - названия защищаемых переменных.



Заключение

В данной работе была разработана система обеспечения отказоустойчивости на основе самой эффективной (среди рассмотренных) по времени выполнения библиотеки Fault Tolerance Interface, адаптированная для пользователей кластеров, работающих с интерконнектом «Ангара».

Для достижения цели были выполнены следующие задачи:

- Рассмотрены существующие методы обеспечения отказоустойчивости;

- Проведен сравнительный анализ этих методов;

- По результатам сравнительного анализа отобраны три подходящих метода;

- Для каждого из методов найдена его программная реализация, в последствии установленная на кластере «Десмос»;

- Для выбора наиболее подходящего инструмента была разработана система тестирования;

- Благодаря результатам тестирования выбран наиболее эффективный инструмент;

- Разработана программа, преобразующая программы на языке C в отказоустойчивый эквивалент с использованием библиотеки FTI.

В рамках исследования методов восстановления задач после сбоев было рассмотрено 7 различных методов, среди которых было выбрано 3 для дальнейшего анализа и тестирования их программных реализации.

Для выбора наиболее эффективной для данной архитектуры программной реализации было необходимо разработать систему тестирования.

Разработанная система тестирования является универсальной для разных архитектур. Один набор тестов позволяет тестировать три инструмента обеспечения отказоустойчивости (CPPC Framework, FTI, ULFM) на разных архитектурах и находить наиболее подходящий из них.

На основании результатов тестирования был сделан вывод о том, что самым эффективным инструментом для архитектуры «Ангары» является библиотека FTI.

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

В качестве направления для развития данной работы можно предложить более глубокое изучение влияния особенностей топологии «Ангары» и эффекта размера на работу и восстановление приложений, а также разработать предкомпилятор на основе полученных выводов и библиотеки FTI.



Список использованных источников

1. Duell J., Hargrove P., Roman. E. The Design and Implementation of Berkeley Lab's Linux Checkpoint/Restart // Berkeley Lab Technical Report (publication LBNL-54941). 2002.

2. Bronevetsky G. Automated application-level checkpointing of MPI programs // PPoPP '03 Proceedings of the ninth ACM SIGPLAN symposium on Principles and practice of parallel programming. 2003. № 1. P. 84-94.

3. Elnozahy E.N., Johnson D.B., Wang Y.M. A Survey of Rollback-Recovery Protocols in Message-Passing Systems // ACM Computing Surveys (CSUR). 2002. Volume 34. № 3. P. 375-408.

4. Shalf J., Dosanjh S., Morrison J. ExaScale Computing Study: Technology Challenges in Achieving Exascale Systems // VECPAR'10 Proceedings of the 9th international conference on High performance computing for computational science. 2010. P. 1-25.

5. Di S., Bouguerra M. Optimization of Multi-level Checkpoint Model for Large Scale HPC Applications // IPDPS '14 Proceedings of the 2014 IEEE 28th International Parallel and Distributed Processing Symposium. 2014. P. 1181-1190.

6. Besta M., Hoefier T. Fault tolerance for remote memory access programming models // HPDC '14 Proceedings of the 23rd international symposium on High-performance parallel and distributed computing. 2014. P. 37-48.

7. Rodrнguez G., Martнn M. CPPC: a compiler-assisted tool for portable checkpointing of message-passing applications // Concurrency and Computation: Practice & Experience - Scalable Tools for High-End Computing. 2010. Volume 22. № 6. P. 749-766.

8. Сеть «Ангара». Руководство пользователя. Версия 7.5.67 от 20.01.2017. С. 13.

9. Agarkov, A.A., Ismagilov, T.F., Makagon, D.V., Semenov, A.S., Simonov, A.S. Performance evaluation of the Angara interconnect. // Proceedings of the International Conference “Russian Supercomputing Days”. 2016. P. 626-639.

Приложение

Технические параметры суперкомпьютера Десмос на интерконнекте Ангара

Код тестовой программы на CPPC Framework



Код тестовой программы с использованием FTI



Код тестовой программы с использованием ULFM



Код утилиты для адаптации кода программы для FTI

#!/bin/bash

file="$1"

prepend='ftized_'

#Name of the finilized file

file=$prepend$file

cp "$1" file

#Copying the default config to the current folder

cp ~/tools/standart_config.fti ./config.fti

#Creating folders to store the checkpoints

mkdir Local

mkdir Global

mkdir Meta

#Adding FTI_Init after MPI_Init

sed '/MPI_Init(.*);/a FTI_Init("./config.fti", MPI_COMM_WORLD);' file

counter=0

for var in "$@"

do

#Skipping the first arguement, cause it's the name of the input file

if [ $counter -gt 0 ]

then

#Adding protection right after first occurance

sed '0/\\n.*$(var)/a \nFTI_Protect(&"$(var)");' file

#Taking checkpoint before any variable setting

sed '0/\\n.$(var)[[:space:]]*=/i \nFTI_Checkpoint(&"$(var)");/g' file

#Recovering in case of a fuilure after each variable setting

sed '0/\\n.$(var)[[:space:]]*=/a \nif(FTI_Status != 0) \n"$(var)"=FTI_Recover();/g' file

fi counter=$((counter + 1))

done

#Adding FTI_Finilize before MPI_Finilize

sed '/MPI_Finalize();/i FTI_Finalize();' file

echo "Your code have been adapted to be used with FTI. Adapted code is in the file ${file}"

Размещено на Allbest.ru

...