Однородный программный интерфейс для параллельных вычислений на кластере

1 Оглавление 2
2 Введение 3
3 Постановка задачи 8
4 Обзор литературы 9
5 Архитектура распределенной системы 12
5.1 Управляющие объекты 12
5.2 Планировщик 16
5.3 Ручной параллелизм 23
5.4 Автоматический параллелизм 24
6 Результаты 28
7 Выводы 33
8 Заключение 34
9 Литература 35
Купить

Текущие исследования по созданию интерфейса программирования высокого уровня для суперкомпьютеров и кластеров направлены на то, чтобы
• изменить существующий функциональный язык для параллельного выполнения программы, написанной на этом языке, в кластере;
• создать движок, позволяющий выполнять направленный ациклический граф задач (программ или скриптов) на кластере с учетом их зависимостей.
Преимущество первого подхода заключается в том, что если у вас уже есть последовательная программа, написанная на функциональном языке, вы можете выполнить ее на кластере с использованием либо компилятора, который генерирует параллельный код, либо библиотеки, которая предоставляет те же функциональные формы (например, map, reduce), которые реализованы для параллельного выполнения на нескольких узлах кластера. Однако этот подход представляет некоторые сложности: обработка спекулятивного выполнения различных ветвей кода и устойчивость к сбоям узлов кластера. Вероятно, главный недостаток этого подхода заключается в том, что на функциональных языках написано не так много высокопроизводительных приложений: большинство из них написано на низкоуровневых императивных языках по соображениям эффективности, и этот подход не предоставляет средств для их выполнения в кластере.
Преимущество второго метода по сравнению с подходом на функциональном языке состоит в том, что он позволяет выполнять произвольные программы и сценарии в кластере и определять информационные зависимости между ними. К сожалению, большинство механизмов рабочих процессов используют XML для определения задач, их аргументов и зависимостей. Этот подход неэффективен, поскольку XML не является языком программирования, и добавление тегов, представляющих циклы, условные выражения и другие важные конструкции потока управления, приводит к созданию языка сценариев с синтаксисом языка разметки - возможно, наиболее неинтуитивно понятным и многословным способом написания программ. Несмотря на эти недостатки, существуют реализации потоков задач, которые популярны и достаточно развиты, чтобы их можно было использовать для решения реальных проблем.
Таким образом, можно сказать, что функциональный подход не является достаточно высокоуровневым, чтобы его можно было использовать для написания сценариев, выполняющих существующие программы в сложном потоке задач, а потоки задач слишком высокоуровневы для написания сценариев общего назначения. Причина отсутствия промежуточного подхода заключается в том, что планировщики пакетных заданий предоставляют интерфейс для выделения узлов кластера и запуска на них любого исполняемого файла, но интерфейс для написания параллельных программ (MPI) - это просто библиотека, которая динамически связывается с исполняемым файлом и не предоставляется планировщиком. Функциональный подход часто основан на использовании библиотеки MPI, а потоки задач основаны на интерфейсе планировщика пакетных заданий. Это создает разрыв между технологиями, который не позволяет создать универсальный и унифицированный интерфейс для выполнения вычислений в кластере, и заставляет выбрать один из двух подходов.
В то же время планировщики заданий, которые используются при анализе больших данных, такие как YARN [21], не имеют этой проблемы, поскольку они предоставляют низкоуровневый интерфейс на основе Java для запуска приложений. Различные среды программирования, такие как Apache Hadoop [1] и Apache Storm [2], построены поверх этого интерфейса, чтобы обеспечить интерфейс высокого уровня для написания определенных видов программ, таких как пакетная обработка или работа в реальном времени.
Существуют интерфейсы более высокого уровня, такие как Oozie [11]. Эта иерархическая архитектура позволяет выбрать правильный уровень абстракции для программы и представляет собой единый интерфейс для запуска приложений на кластере.
Существует множество фреймворков и языков программирования для параллельных и распределенных вычислений [17, 19, 22, 23], которые успешно применяются как в промышленности, так и в академических кругах, однако все они изолированы и самодостаточны. Основная причина отсутствия общего знаменателя между этими фреймворками и языками заключается в том, что нет протокола или низкоуровневого языка для распределенных вычислений. Для последовательных вычислений у нас есть байт-код (например, LLVM [13], байт-код Java, байт-код Guile), который используется в качестве промежуточного, переносимого и универсального представления программы, написанной на любом языке; также у нас есть ассемблер, который не является переносимым, но все же является популярным промежуточным представлением.
Почему общий низкоуровневый язык существует для последовательных вычислений, но не существует для параллельных и распределенных вычислений? Одна из причин, которая относится как к распределенным, так и к параллельным вычислениям, заключается в том, что люди все еще думают о программах как о последовательности шагов - так же, как люди сами выполняют сложные задачи. Императивные языки, на которых программы записываются в виде последовательности шагов, по- прежнему преобладают в промышленности и академических кругах; это контрастирует с непопулярными функциональными языками, на которых программы написаны как композиции функций без подразумеваемого порядка вычислений. Другая причина, которая относится к распределенным вычислениям, заключается в том, что эти вычисления по своей сути ненадежны и не существует универсального подхода для обработки выхода из строя узлов кластера. Хотя императивные языки позволяют писать более эффективные программы, они не обеспечивают защиты от взаимных блокировок и не гарантируют отказоустойчивость. Кроме того, их намного сложнее писать, так как человеку приходится работать с изменяемым состоянием (локальные и глобальные переменные, объекты и т. д.), и трудно держать это состояние в голове при написании кода. Функциональные языки минимизируют использование изменяемого состояния, обеспечивают частичную защиту от взаимных блокировок (при условии, что программист не использует блокировки вручную) и могут быть изменены для обеспечения отказоустойчивости. С точки зрения автора, люди понимают потенциал функциональных языков, но еще не осознали этот потенциал, чтобы получить все их преимущества; люди осознали весь потенциал императивных языков, но не знают, как избавиться от их недостатков.
Одна важная особенность, которой не хватает в байт-коде и ассемблере, - это способность взаимодействовать между параллельными процессами. Это взаимодействие является общим определяющим фактором, на котором могут быть построены все фреймворки и языки для параллельных и распределенных вычислений, однако универсального низкоуровневого протокола или языка, описывающего общение, не существует.
Распределенные вычислительные системы представляются как множество индивидуальных сущностей (узлов), которые соединены между собой с помощью специализированных программ: в высокопроизводительных вычислениях — это планировщики пакетных задач, в области больших данных — это планировщики задач, тесно связанные с параллельной файловой системой, в облачных вычислениях — системы управления контейнерами приложений и виртуальными машинами. Несмотря на эффективность этих программ в их предметных областях, они не являются универсальными: вместо того чтобы предоставить пользователю программный интерфейс для проведения вычислений общего назначения на распределенной системе, они либо предоставляют ограниченный потребностями конкретной предметной области интерфейс (в случае с большими данными и облачными вычислениями), либо интерфейс для параллельного запуска программы на всех узлах и коммуникации параллельных процессов между собой, тесно связанный с конфигурацией системы (в случае высокопроизводительных вычислений).
Основным сдерживающим фактором для создания универсального интерфейса, который бы позволял программировать распределенные системы без непосредственной привязки к количеству узлов, их физическим характеристикам (количеству параллельных процессов, сетевым адресам и т.п.), является свойственная им ненадежность. Действительно, при рассмотрении одного вычислительного узла, его выход из строя является критической ситуацией, которую нельзя разрешить на уровне программного обеспечения, из-за чего все программы, предназначенные для запуска на одном узле, написаны в предположении, что этот узел абсолютно надежен. В то же время, в распределенной системе достаточно большого размера выход из строя одного из узлов является нормальной ситуацией, которая не должна влиять на ее работоспособность в целом. В современных распределенных системах решены лишь частные случаи данной проблемы: в высокопроизводительных вычислениях используются контрольные точки восстановления, в больших данных надежность обеспечивается файловой системой, а в облачных вычислениях, как правило, сетевым хранилищем. Разработчики этих систем как будто бы хотят уйти от обязанности обеспечения отказоустойчивости, переложив ее на распределенную систему хранения данных, которая вычислениями не занимается. Такой подход вряд ли можно назвать эффективным: контрольные точки восстановления работают не для каждой программы и даже для подходящих программ всегда есть шанс ошибки при восстановлении, сохранение всех промежуточных результатов вычислений в параллельных файловых системах невозможно сделать быстро, а сетевые хранилища на деле являются просто узлами с большим количеством дисков, выход из строя которых может повлечь за собой нарушения функционирования всей распределенной системы.
Таким образом, проблема заключается в специализированности механизмов обеспечения отказоустойчивости распределенных систем, а также их примитивности, что является одной из основных причин отсутствия универсальных средств и интерфейсов для программирования таких систем.
Купить