Контрольная точка приложения
 | В данной статье поднимается несколько вопросов. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
Контрольно-пропускные пункты — это метод, обеспечивающий вычислительных систем отказоустойчивость . По сути, он заключается в сохранении моментального , чтобы снимка состояния приложения приложения могли перезапуститься с этого момента в случае сбоя . Это особенно важно для длительно работающих приложений, которые выполняются в подверженных сбоям вычислительных системах.
Контрольные точки в распределенных системах [ править ]
В распределенной вычислительной среде контрольные точки — это метод, который помогает выдерживать сбои, которые в противном случае заставили бы долго работающее приложение перезапускаться с самого начала. Самый простой способ реализовать контрольные точки — остановить приложение, скопировать все необходимые данные из памяти в надежное хранилище (например, параллельную файловую систему ), а затем продолжить выполнение. [1] В случае сбоя при перезапуске приложения его не нужно начинать с нуля. Скорее, он будет читать последнее состояние («контрольную точку») из стабильного хранилища и выполнять его. Хотя продолжаются споры о том, является ли создание контрольных точек доминирующей рабочей нагрузкой ввода-вывода в распределенных вычислительных системах, существует общее мнение, что контрольные точки являются одной из основных рабочих нагрузок ввода-вывода. [2] [3]
Существует два основных подхода к созданию контрольных точек в распределенных вычислительных системах: скоординированное создание контрольных точек и нескоординированное создание контрольных точек. При использовании скоординированного подхода к контрольным точкам процессы должны обеспечивать согласованность своих контрольных точек. Обычно это достигается с помощью какого-то алгоритма протокола двухфазной фиксации . При нескоординированной контрольной точке каждый процесс независимо проверяет свое состояние. Следует подчеркнуть, что простого принуждения процессов к проверке своего состояния через фиксированные интервалы времени недостаточно для обеспечения глобальной согласованности. Необходимость установления согласованного состояния (т. е. отсутствия пропущенных или дублированных сообщений) может заставить другие процессы откатиться к своим контрольным точкам, что, в свою очередь, может привести к тому, что другие процессы откатятся к еще более ранним контрольным точкам, что в самом крайнем случае может привести к откату других процессов к их контрольным точкам. означают, что единственным найденным непротиворечивым состоянием является начальное состояние (так называемый эффект домино ). [4] [5]
Реализации для приложений [ править ]
Сохранить состояние [ править ]
 |
Одним из первоначальных и в настоящее время наиболее распространенных средств проверки приложений была функция «сохранения состояния» в интерактивных приложениях, с помощью которой пользователь приложения мог сохранять состояние всех переменных и других данных на носителе данных в момент их использования. его и либо продолжить работу, либо выйти из приложения и позднее перезапустить приложение и восстановить сохраненное состояние. Это было реализовано с помощью команды «Сохранить» или пункта меню в приложении. Во многих случаях стало стандартной практикой при выходе из приложения спрашивать пользователя, есть ли у него несохраненная работа, хотят ли они сохранить свою работу перед этим.
Функциональность такого рода стала чрезвычайно важной для удобства использования в приложениях, где конкретную работу невозможно выполнить за один присест (например, игра в видеоигру, которая может занять десятки часов, или написание книги или длинного документа, состоящего из сотен или тысяч страниц). ) или когда работа выполнялась в течение длительного периода времени, например ввод данных в документ, например строки в электронной таблице.
Проблема с состоянием сохранения заключается в том, что оператор программы требует запроса на сохранение. Для неинтерактивных программ, включая автоматизированные или пакетно обрабатываемые рабочие нагрузки, возможность проверки таких приложений также должна была быть автоматизирована.
Контрольная точка/Перезапуск [ править ]
|
Поскольку пакетные приложения начали обрабатывать десятки и сотни тысяч транзакций, где каждая транзакция могла обрабатывать одну запись из одного файла в нескольких разных файлах, возникла необходимость в перезапуске приложения в какой-то момент без необходимости повторного запуска всего задания с нуля. стал обязательным. Таким образом родилась возможность «контрольной точки/перезапуска», при которой после обработки ряда транзакций можно было сделать «моментальный снимок» или «контрольную точку» состояния приложения. Если приложение потерпело неудачу до следующей контрольной точки, его можно было перезапустить, предоставив ему информацию о контрольной точке и последнее место в файле транзакции, где транзакция была успешно завершена. Приложение может затем перезапуститься в этот момент.
Создание контрольных точек обычно обходится дорого, поэтому обычно оно выполняется не для каждой записи, а с некоторым разумным компромиссом между стоимостью контрольной точки и стоимостью компьютерного времени, необходимого для повторной обработки пакета записей. Таким образом, количество записей, обрабатываемых для каждой контрольной точки, может варьироваться от 25 до 200, в зависимости от факторов стоимости, относительной сложности приложения и ресурсов, необходимых для успешного перезапуска приложения.
Интерфейс отказоустойчивости (FTI) [ править ]
|
FTI — это библиотека, цель которой — предоставить ученым-компьютерщикам простой способ масштабируемого выполнения контрольной точки/перезапуска. [6] FTI использует локальное хранилище, а также методы многократной репликации и стирания для обеспечения нескольких уровней надежности и производительности. FTI обеспечивает контрольные точки на уровне приложений, которые позволяют пользователям выбирать, какие данные необходимо защитить, чтобы повысить эффективность и избежать потерь пространства, времени и энергии. Он предлагает прямой интерфейс данных, поэтому пользователям не нужно иметь дело с именами файлов и/или каталогов. Все метаданные управляются FTI прозрачным для пользователя способом. При желании пользователи могут выделить один процесс на каждый узел для перекрытия рабочей нагрузки отказоустойчивости и научных вычислений, чтобы задачи после контрольной точки выполнялись асинхронно.
Контрольная точка/перезапуск лаборатории Беркли (BLCR) [ править ]
Группа Future Technologies в Национальной лаборатории Лоуренса разрабатывает гибридную реализацию контрольной точки/перезапуска ядра/пользователя под названием BLCR. Их цель — предоставить надежную, качественную реализацию, которая проверяет широкий спектр приложений, не требуя внесения изменений в код приложения. [7] BLCR фокусируется на контрольных точках параллельных приложений, которые взаимодействуют через MPI, а также на совместимости с пакетом программного обеспечения, созданным SciDAC Scalable Systems Software ISIC. Его работа разбита на 4 основных направления: контрольная точка/перезапуск для Linux (CR), контрольные библиотеки MPI, интерфейс управления ресурсами для контрольной точки/перезапуска и разработка интерфейсов управления процессами.
ДМТСП [ править ]
DMTCP (Distributed MultiThreaded Checkpointing) — это инструмент для прозрачной проверки состояния произвольной группы программ, распределенных по множеству машин и соединенных сокетами. [8] Он не изменяет программу пользователя или операционную систему. Среди приложений, поддерживаемых DMTCP, — Open MPI , Python , Perl , а также многие языки программирования и языки сценариев оболочки. С помощью TightVNC он также может проверять и перезапускать приложения X Window, если они не используют расширения (например, OpenGL или видео). Среди функций Linux, поддерживаемых DMTCP, — дескрипторы открытых файлов , каналы, сокеты, обработчики сигналов, виртуализация идентификаторов процессов и потоков (гарантируйте, что старые идентификаторы pid и tids продолжают работать после перезапуска), ptys, fifos, идентификаторы групп процессов, идентификаторы сеансов, терминалы. атрибуты и mmap /mprotect (включая общую память на основе mmap). DMTCP поддерживает API OFED для InfiniBand на экспериментальной основе. [9]
Совместная проверка [ править ]
Некоторые недавние протоколы выполняют совместную проверку контрольных точек, сохраняя фрагменты контрольной точки в соседних узлах. [10] Это полезно, поскольку позволяет избежать затрат на хранение в параллельной файловой системе (которая часто становится узким местом для крупномасштабных систем) и использует более близкое хранилище. [ нужна цитата ] Это нашло применение, в частности, в крупномасштабных суперкомпьютерных кластерах. Задача состоит в том, чтобы обеспечить, чтобы при необходимости чекпоинта при восстановлении после сбоя были доступны близлежащие узлы с фрагментами чекпоинтов. [ нужна цитата ]
Докер [ править ]
Docker и лежащая в его основе технология содержат контрольную точку и механизм восстановления. [11]
ПЛАЧ [ править ]
CRIU — это библиотека контрольных точек пользовательского пространства.
Реализация для встроенных и ASIC-устройств [ править ]
Сувениры [ править ]
Mementos — это программная система, которая преобразует задачи общего назначения в прерываемые программы для платформ с частыми перебоями, такими как перебои в подаче электроэнергии. Он был разработан для встраиваемых устройств без батарей, таких как RFID-метки и смарт-карты, которые используют энергию из фоновых источников окружающей среды. Mementos часто определяет доступную энергию в системе и решает, поставить ли программу контрольную точку из-за надвигающейся потери мощности или продолжать вычисления. При контрольной точке данные будут храниться в энергонезависимой памяти . Когда энергии становится достаточно для перезагрузки , данные извлекаются из энергонезависимой памяти и программа продолжает работу из сохраненного состояния. Mementos реализован на MSP430 семейства микроконтроллерах . Mementos назван в честь книги Кристофера Нолана « Memento » . [12]
Идетик [ править ]
Idetic — это набор автоматических инструментов, который помогает разработчикам специализированных интегральных схем (ASIC) автоматически встраивать контрольные точки в свои проекты. Он ориентирован на инструменты синтеза высокого уровня и добавляет контрольные точки на уровне передачи регистров ( код Verilog ). Он использует подход динамического программирования для определения точек с минимальными издержками в конечном автомате проекта. Поскольку контрольная точка на аппаратном уровне предполагает отправку данных зависимых регистров в энергонезависимую память, оптимальные точки должны иметь минимальное количество регистров для хранения. Idetic развертывается и оценивается на устройстве RFID-меток, аккумулирующем энергию . [13]
См. также [ править ]
- Изображение процесса
- Состояния сохранения — аналогичная концепция, предоставляемая эмуляторами игровых консолей.
Ссылки [ править ]
- ^ Планк Дж. С., Бек М., Кингсли Г. и Ли К. (1994). Libckpt: Прозрачная контрольная точка под unix. Кафедра компьютерных наук.
- ^ Ван, Дэн; Снайдер, Шейн; Локвуд, Гленн; Карнс, Филип; Райт, Николас; Бина, Сурен (сентябрь 2018 г.). «IOMiner: крупномасштабная аналитическая платформа для получения знаний из журналов ввода-вывода». Международная конференция IEEE по кластерным вычислениям (CLUSTER) 2018 . IEEE. стр. 466–476. дои : 10.1109/CLUSTER.2018.00062 . ISBN 978-1-5386-8319-4 . S2CID 53235850 .
- ^ «Сравнительная характеристика рабочей нагрузки ввода-вывода двух кластеров хранения данных лидерского класса» (PDF) . АКМ. Ноябрь 2015 г.
- ^ Бутейлер Б., Лемаринье П., Кравезик К. и Капелло Ф. (2003, декабрь). Скоординированная контрольная точка и журнал сообщений для отказоустойчивого MPI. В кластерных вычислениях, 2003. Труды. Международная конференция IEEE 2003 г. (стр. 242–250). IEEE.
- ^ Эльнозахи, Э.Н., Алвиси, Л., Ван, Ю.М., и Джонсон, Д.Б. (2002). Обзор протоколов отката-восстановления в системах передачи сообщений. Обзоры вычислений ACM, 34 (3), 375–408.
- ^ Баутиста-Гомес Л., Цубои С., Коматич Д., Каппелло Ф., Маруяма Н. и Мацуока С. (2011, ноябрь). FTI: высокопроизводительный отказоустойчивый интерфейс для гибридных систем. В материалах Международной конференции по высокопроизводительным вычислениям, сетям, хранению и анализу 2011 г. (стр. 32). АКМ.
- ^ Харгроув, PH, и Дуэлл, JC (2006, сентябрь). Контрольная точка/перезапуск лаборатории Беркли (blcr) для кластеров Linux. В журнале физики: серия конференций (том 46, № 1, стр. 494). Издательство ИОП.
- ^ Ансель Дж., Арья К. и Куперман Г. (май 2009 г.). DMTCP: Прозрачная контрольная точка для вычислений кластера и рабочего стола. В параллельной и распределенной обработке, 2009. IPDPS 2009. Международный симпозиум IEEE (стр. 1–12). IEEE.
- ^ «GitHub — DMTCP/DMTCP: DMTCP: распределенная многопоточная проверка точек» . Гитхаб . 11.07.2019.
- ^ Уолтерс, JP; Чаудхари, В. (1 июля 2009 г.). «Отказоустойчивость на основе репликации для приложений MPI». Транзакции IEEE в параллельных и распределенных системах . 20 (7): 997–1010. CiteSeerX 10.1.1.921.6773 . дои : 10.1109/TPDS.2008.172 . ISSN 1045-9219 . S2CID 2086958 .
- ^ «Докер — ЦНИИУ» .
- ^ Бенджамин Рэнсфорд, Джейкоб Сорбер и Кевин Фу. 2011. Mementos: системная поддержка длительных вычислений на устройствах RFID-масштаба. Уведомления ACM SIGPLAN 47, 4 (март 2011 г.), 159–170. DOI=10.1145/2248487.1950386 http://doi.acm.org/10.1145/2248487.1950386
- ^ Мирхосейни, А.; Сонгори, EM; Кушанфар, Ф., «Идетик: подход к синтезу высокого уровня для обеспечения длительных вычислений на ASIC с переходным питанием», Pervasive Computing and Communications (PerCom), Международная конференция IEEE, 2013 г., том, №, стр. 216, 224, 18. –22 марта 2013 г. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6526735&isnumber=6526701
Дальнейшее чтение [ править ]
- Ибэй Лин, Цзе Ми, Сяола Линь: подход вариационного исчисления к оптимальному размещению контрольных точек. IEEE Транс. Компьютеры 50(7): 699-708 (2001).
- Р. Э. Ахмед, Р. К. Фрейзер и П. Н. Маринос, «Алгоритмы восстановления ошибок отката с помощью кэша (CARER) для многопроцессорных систем с общей памятью», 20-й международный симпозиум IEEE по отказоустойчивым вычислениям (FTCS-20), Ньюкасл-апон-Тайн, Великобритания, 26–28 июня 1990 г., стр. 82–88.
