Верифицируемые контрольные точки восстановления для параллельных приложений.

Введение 3
Постановка задачи 5
Обзор литературы 6
Глава 1. Теоретические аспекты обеспечения отказоустойчивости параллельных приложений. 9
1.1 Основные понятия и определения 9
1.2 Сравнительный анализ подходов к обеспечению отказоустойчивости параллельных приложений 10
1.3 Обзор существующих решений 12
Глава 2. Верифицируемые контрольные точки восстановления для параллельных приложений 19
2.1 Реализация 19
2.2 Тестирование решения 22
Выводы 37
Заключение 38
Список литературы 39

Весь текст будет доступен после покупки

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

Весь текст будет доступен после покупки

Постановка задачи

Целью данной работы является реализация легковесного фреймворка для создания контрольных точек на уровне приложения, с возможностью проверки корректности выполнения программы при запуске из каждой созданной контрольной точки. Поставленная цель определила следующие задачи:
1. изучить существующие подходы к созданию контрольных точек: system-level checkpoint/restart [2] и application-level checkpoint/restart [3];
2. изучить существующие реализации подходов, проанализировать их преимущества и недостатки;
3. разработать и имплементировать легковесный фреймворк для создания верифицируемых контрольных точек на уровне приложения, использующих MPI версии 2.1 и выше;
4. протестировать эффективность реализованного фреймворка на примере бенчмарков NAS Parallel [4] и miniFE [5], а также сравнить и сопоставить их с контрольными точками системного уровня, созданными с помощью DMTCP [6].










Обзор литературы

В статье [2] описывается разработка и реализация контрольных точек на уровне системы для кластеров Linux, предназначенная для типичных приложений высокопроизводительных вычислений, включая MPI. По мнению авторов, несмотря на тот факт, что контрольные точки на уровне приложения более эффективны по времени необходимому для их создания и по количеству занимаемой памяти, контрольные точки на уровне системы позволяют реагировать на факты, свидетельствующие о скором возникновении ошибки (например, повышенная частота ошибок в памяти ECC [7] или повышенная температура той или иной части оборудования). Данный подход также может повысить эффективность пакетного планирования (перераспределение ресурсов, основанное на очереди задач) и снижения среднего времени в очереди (путем выполнения больших задач в непиковые часы без ограничения времени их продолжительности).
В [6] описывается разработанный авторами пакет DMTCP (Distributed MultiThreaded CheckPointing) для создания контрольных точек на уровне системы, эффективность которого не зависит от используемой реализации MPI. Результаты экспериментов показывают, что время на создание контрольной точки остается почти постоянным по мере увеличения количества узлов в кластере. DMTCP не требует привилегий супер-пользователя или специальных патчей ядра UNIX, поэтому может быть включен и распространен как модуль в каком-либо более крупном пакете.
Авторы [8] считают, что создание контрольных точек на уровне приложения был и есть наиболее удачный подход для обеспечения отказоустойчивости, однако несмотря на его эффективность с точки зрения накладных расходов, он требует больших усилий по реализации. Авторы разработали библиотеку CRAFT (Checkpoint-Restart and Automatic Fault Tolerance) - расширяемую библиотеку, которая значительно упрощает реализацию контрольных точек на уровне приложения. В качестве средства сокращения накладных расходов библиотека предлагает встроенный асинхронный механизм создания контрольных точек, а также поддержку библиотеки Scalable Checkpoint/Restart (SCR) [9] для создания контрольных точек на уровне узла.
В статье [9] утверждается, что за счёт использования большего количества аппаратных компонентов в современных системах высокопроизводительных вычислений снижается среднее время до сбоя системы, поэтому необходимо чаще создавать контрольные точки, чтобы добиться прогресса. Однако, объем системной памяти растет быстрее, чем пропускная способность параллельной файловой системы и стоимость создания контрольной точки начинает преобладать над временем выполнения приложения. По мнению авторов статьи, многоуровневый подход потенциально решает эту проблему с помощью нескольких типов контрольных точек с разной стоимостью и разными уровнями отказоустойчивости: облегченные - для обработки наиболее распространенных сбоев, а более дорогие - для менее распространенных, но более серьезных сбоев. Библиотека Scalable Checkpoint/Restart (SCR), разработанная авторами статьи, предлагает многоуровневую систему, которая записывает контрольные точки в ОЗУ, флэш-память или диск на вычислительных узлах в дополнение к параллельной файловой системе.
[10] является сравнением двух подходов: контрольные точки на уровне системы и пользовательские контрольные точки (на уровне приложения). Авторы рассматривают плюсы и минусы обоих подходов и представляют экспериментальное исследование.

Весь текст будет доступен после покупки

1. Message Passing Interface // Wikipedia: https://ru.wikipedia.org/wiki/Message_Passing_Interface (дата обращения: 26.05.2022).
2. Hargrove P. H., Duell J. C. Berkeley lab checkpoint/restart (BLCR) for Linux clusters //Journal of Physics: Conference Series. – IOP Publishing, 2006. – Vol. 46. – Issue 1. – P. 067
3. Application checkpointing // Wikipedia: https://en.wikipedia.org/wiki/Application_checkpointing (дата обращения: 26.05.2022).
4. Van der Wijngaart R. F., Wong P. NAS parallel benchmarks version 2.4. – 2002.
5. Heroux M. A. et al. Improving performance via mini-applications //Sandia National Laboratories, Tech. Rep. SAND2009-5574. – 2009. – Vol. 3
6. Ansel J., Arya K., Cooperman G. DMTCP: Transparent checkpointing for cluster computations and the desktop //2009 IEEE International Symposium on Parallel & Distributed Processing. – IEEE, 2009. – P. 1-12.
7. ECC Memory // Wikipedia: https://en.wikipedia.org/wiki/ECC_memory (дата обращения: 26.05.2022).
8. Shahzad F. et al. CRAFT: A library for easier application-level checkpoint/restart and automatic fault tolerance //IEEE Transactions on Parallel and Distributed Systems. – 2018. – Vol. 30. – Issue 3. – P. 501-514.
9. A. Moody, G. Bronevetsky, K. Mohror, and B. R. d. Supinski, “Design, Modeling, and Evaluation of a Scalable Multi-level Checkpointing System,” in Proceedings of the 2010 ACM/IEEE International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’10. Washington, DC, USA: IEEE Computer Society, Nov. 2010, pp. 1–11.

Весь текст будет доступен после покупки