Введение 3
Постановка задачи 6
Обзор литературы 7
Глава 1. Формализация журнала 10
Глава 2. Модель актеров 15
Глава 3. Модель вычислительных ядер 21
3.1. Определения 21
3.1.1. Программа-пример 23
3.2. Правила разбиения 24
3.2.1. Разбиение программы-примера 26
3.3. Иерархия вычислительных ядер 28
Глава 4. Имплементация вычислительных ядер 33
4.1. Ведение журнала 35
4.2. Вычислительный сервер, управляющий задачи 39
4.3. Работа модели 40
4.4. Тестирование 44
Выводы 46
Заключение 48
Список литературы
Современные проблемы вычислений на кластерах
Сегодня никого не удивить существованием больших суперкомпьютеров, составляющих основу для ЦОДов. Свои собственные вычислительные системы (кластера) есть у лабораторий, университетов, небольших частных компаний. Их повседневное использование и обслуживание — предмет интереса широкого круга людей. Мой же интерес к теме HPC (high performance computing, высокопроизводительные вычисления) формировался все последние годы. Мне, правда, не интересен сам факт существования подобных вычислительных систем - мне интересны проблемы, с которыми сталкиваются их пользователи. Проблемы высокопроизводительных вычислений можно грубо разделить на три группы:
• В первую можно отнести проблемы производительности оборудования. Сюда входят всевозможные алгоритмы оптимизации и практики использования графических ускорителей при вычислениях, производительность сети (локальная/распределенная), производительность центральных процессоров, взаимодействие между устройствами по шине обмена данными, производительность подсистемы оперативной памяти и т.д.
• Вторая группа содержит проблемы надежности. Надежность в данном контексте стоит понимать как свойство аппаратуры и ПО, которое позволяет выполнить задачу вне зависимости от характера и степени внешнего или внутреннего противодействия. К негативным воздействиям относятся аппаратные ошибки и сбои, логические ошибки программной реализации и т.д.
• В третью группу можно отнести проблемы алгоритмического характера, которые можно описать следующим вопросом: как наилучшим образом реализовать задачу в виде программы для ЭВМ, задействовав при этом вычислительный ресурс максимально эффективно?
В среде computer science проблемы первой и третьей группы намного популярнее проблем второй группы. Например, запросы в Google Scholar “cluster computation performance” и “cluster computation reliability” дают результаты в 1300000 и 513000 ответов соответственно. Почему такая большая разница в количестве ответов? Скорее всего потому, что прямая и явная выгода от прироста производительности очевидна всем, а повышение надежности будет иметь вес только в определенном круге задач. Так, если задача рассчитывается быстрее, то в выигрыше все: и тот, кто считает и те, кто предоставляет ресурсы. Но что касается повышения надежности?
Степень надежности процесса вычислений исторически принято связывать с надежностью оборудования. С одной стороны, это логично: если техника работает штатно, то внутренним программным процессам не угрожают фатальные ошибки. Здесь стоит уточнить, что программные фатальные ошибки, например, некорректный доступ к общей памяти, остаются на совести тех, кто целенаправленно их добивается. Сегодня существует достаточно уровней программных разграничений, чтобы исполняемый код не привел к непредсказуемым последствиям.
Но вернемся к технике. Для обеспечения аппаратной надёжности за последние 50 лет разработано достаточное количество методик. В общем, они сводятся к резервированию ресурсов и замещению процессов, подвергнутых сбою. Так, если выходит из строя один жесткий диск, то проще будет перенаправить потоки данных на резервный, ведь таких резервных дисков еще N штук. Тоже — с целыми вычислительными узлами.
Подобные методы резервирования ресурсов оправданы, если стоит цель сохранить статические данные. Здесь под статическими данными я понимаю такие массивы информации, скорость изменения которых не требует их постоянного хранения в оперативной памяти, или такие, которые настолько велики, что могут обработаться только частями, при этом операций чтения с диска много больше операций записи на диск. Потеря таких данных в случае аварии будет худшим из сценариев, потому что эти данные — предмет вычислений. Что же до самого процесса расчета, то его начинают заново. С момента, когда требуется полный перезапуск задачи, начинается мое исследование.
Перезапуск задачи всегда влечет за собой потери. Прежде всего это временные потери, которые в худшем случае составляют полное время выполнения задачи до поломки. Если расчет идет на множестве узлов и сам алгоритм решения задачи реализован с помощью технологий обмена сообщениями, такими как MPI/OpenMP, то вероятность перезапуска всей задачи значительна, потому значительное негативное влияние имеет выход из строя любого узла по любой причине. Временные потери при повторном вычислении ранее рассчитанных, но прерванных операций, приводят к неэффективному использованию кластера в целом. Так, уменьшается показатель эффективности “задача/час”, повышается энергопотребление и т.д. Какие существуют способы этого избежать?
В ходе выполнения квалификационной работы были получены следующие результаты:
1. Разработан новый алгоритм запуска вычислительных задач в кластерных средах с восстановлением, на основе алгоритма без восстановления.
2. Пошагово, на примере, описан процесс использования нового алгоритма для получения программной реализации.
3. Оценена эффективность работы алгоритма в соответствии с целевым критерием.
4. Проведена верификация полученного алгоритма на предмет восстановления прерванных вычислений.
5. Разработана программная среда выполнения алгоритма запуска задач.
