Open MPI

Глава 15 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Open MPI, глава из книги "The Architecture of Open Source Applications" том 2.
Автор: Jeffrey M. Squyres
Перевод: Н.Ромоданов

15.2. Архитектура

По целому ряду причин (в основном, связанных либо с производительностью, либо с переносимостью) единственными двумя возможностями языка первичной реализации были C и C++. Язык C++ в конце концов был отвергнут, поскольку различные компиляторы С++, как правило, размещали структуры/классы в памяти в соответствии с различными алгоритмами оптимизации, что при работе с сетью приводило к различным реализациям. Поэтому в качестве основного языка реализации был выбран язык C, что оказало влияние на несколько архитектурных проектных решений.

Когда проект Open MPI был запущен, мы знали, что он должен представлять собой сложный код большого объема:

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

Архитектура слоев абстракции

В Open MPI есть три основных слоя абстракции, которые показаны на рис.15.1:

• Open, Portable Access Layer (OPAL): Слой OPAL является нижним слоем абстракции проекта Open MPI. Его абстракции сфокусированы на отдельных процессах (а не параллельном выполнении заданий). Он предоставляет утилиты и связующий код, например, связные списки общего назначения, обработку строк, управление отладкой и другие рутинные, но необходимые функции.

  В слое OPAL также реализуется ядро переносимости Open MPI между различными операционными системами, например, доступ к интерфейсам IP, совместное использование память на одном и том же сервере, согласование процессора и памяти, высокоточные таймеры и т.д.

• Open MPI Run-Time Environment (ORTE) (произносится как «ор-тей»): Реализация MPI должна предоставить не только интерфейс API, необходимый для передачи сообщений, но и сопутствующую систему времени выполнения для запуска, отслеживания и уничтожения параллельно выполняемых заданий. В случае Open MPI параллельно выполняемое задание состоит из одного или нескольких процессов, которые могут исполняться на нескольких экземплярах операционной системы и могут быть взаимосвязанны друг с другом так, чтобы они действовали как нечто единое.

  В простых средах со слабой поддержкой или без поддержки распределенных вычислений слой ORTE использует команды rsh или ssh для запуска отдельных процессов в параллельно выполняемых заданиях. В более продвинутых HPC-средах обычно есть планировщики и менеджеры ресурсов, применяемые для справедливого распределения вычислительных ресурсов между многими пользователями. В таких средах обычно предоставляются специализированные интерфейсы, предназначенные для запуска и регулирования процессов на вычислительных серверах. В слое ORTE поддерживается широкий спектр таких управляемых сред, например (но не только): Torque/PBS Pro, SLURM, Oracle Grid Engine и LSF.

• Open MPI (OMPI): Слой MPI является самым высоким уровнем абстракции, и является единственным слоем, который виден приложениям. В этом слое реализован интерфейс API для MPI, т.к. в нем заключена семантика передачи сообщений, определяемая стандартом MPI.

  Поскольку переносимость является основным требованием, в слое MPI поддерживается широкий спектр различных типов сетей и лежащих в их основе протоколов. Некоторые сети похожи по своим основным характеристикам и абстракциям, а некоторые - нет.

Рис.15.1: Представление архитектуры абстрактных слоев проекта Open MPI в виде трех основных слоев: OPAL, ORTE и OMPI

Хотя каждая абстракция представляет собой слой, расположенный поверх слоя, лежащего ниже, по причинам, связанным с производительностью, слои ORTE и OMPI могут, когда необходимо, обходить нижележащие слои абстракции и непосредственно взаимодействовать с операционной системой и/или аппаратным обеспечением (так, как показано на рис.15.1). Например, для достижения максимальной производительности сетей в слое OMPI используются методы обхода ОС при взаимодействии с определенными типами аппаратных интерфейсов NIC.

Каждый слой собран в виде отдельной библиотеки. Библиотека ORTE зависит от библиотеки OPAL; библиотеки OMPI зависит от библиотеки ORTE. Разделение слоев на свои собственные библиотеки стало прекрасным инструментом для предотвращения нарушений абстракции. В частности, приложения не смогут быть скомпонованы, если некоторый слой пытается неправильно использовать символ, находящийся на более высоком уровне. На протяжении многих лет такой механизм абстракции защищал многих разработчиков от случайного нарушения границ между этими тремя слоями.

Архитектура плагинов

Хотя первоначально члены сообщества Open MPI стремились к одной и той же основной цели (создать переносимую высокопроизводительную реализацию стандарта MPI), наши организационные возможности, мнения и декларации, да и все тому подобное, были абсолютно различными. Поэтому мы потратили достаточно много времени на разработку архитектуры, которая позволила бы нам оставаться разными даже в случае совместного использования одного и того же базового кода.

Естественным выбором стали компоненты, загружаемые во время исполнения (т.е. динамически разделяемые объекты или «DSO», или «плагины»). Компоненты соответствовали общему интерфейсу API, но они имели незначительные ограничения на реализацию этого API. А именно: одно и то же поведение интерфейса можно было реализовывать несколькими способами. Пользователь мог на этапе исполнения выбрать, какой плагин (плагины) он будет использовать. Это даже позволило третьим лицам самостоятельно разрабатывать и распространять свои собственные плагины Open MPI, которые не входят в состав базового пакета Open MPI. Возможность произвольного расширения является вполне либеральной политикой, причем как непосредственно среди разработчиков Open MPI, так и в гораздо большем по размеру сообществе Open MPI.

Такая гибкость времени выполнения является ключевым компонентом философии проекта Open MPI и она глубоко интегрирована во всей его архитектуре. Показательный пример: серия Open MPI v1.5 включает в себя 155 плагинов. Просто перечислим лишь несколько примеров: есть плагины для различных реализаций memcpy(), плагины для дистанционного запуска процессов на других серверах, и плагины для взаимодействия в различных типах базовых сетей.

Одно из основных преимуществ использования плагинов состоит в том, что несколько групп разработчиков могут свободно экспериментировать с альтернативными реализациями, не затрагивая основной проект Open MPI. Это была очень важно особенно в первое время работы над проектом Open MPI. Иногда разработчики не знают, как правильно что-то реализовать, а иногда просто не соглашаются друг с другом. В обоих случаях, каждая из сторон будет реализовывать свое собственное решения в виде компонента, позволив остальной части сообщества разработчиков легко сравнивать и сопоставлять результаты. Конечно, сравнение кода может быть выполнено без использования компонентов, но концепция компонентов позволяет гарантировать, что все реализации будут находиться в условиях одного и того же внешнего API, и, следовательно, будет обеспечена одна и та же необходимая семантика.

Прямым результатом такой гибкость является то, что она обеспечивает, что компонентная концепция используется в полной мере во всех трех слоях проекта Open MPI; в каждом слое есть много различных типов компонентов. Каждый тип компонента представлен в виде фреймворка. Компонент принадлежит ровно одному фреймворку, а фреймворк поддерживает ровно один вид компонента. На рис.15.2 приведена общая компоновка архитектуры проекта Open MPI; на ней показаны несколько фреймворков Open MPI и некоторые из имеющихся компонентов. Остальные фреймворки и компоненты Open MPI подключены к проекту аналогичным образом. Набор слоев проекта Open MPI, его фреймворки и компоненты называются модульной архитектурой компонентов - Modular Component Architecture (MCA).

Рис.15.2: Архитектурное представление фреймворков в Open MPI — показаны всего лишь несколько фреймворков и компонентов из Open MPI (т.е., плагины). Каждый фреймворк содержит базовый код base и один или несколько компонентов. Эта структура реплицируется в каждом из слоев, показанных на рис.15.1. На данном рисунке показаны примеры фреймворков всех трех слоев: btl и coll относятся к слою OMPI, plm относится к слою ORTE, а timer относится к слою OPAL.

Наконец, еще одним важным преимуществом использования фреймворков и компонентов является присущее им свойство сочетаемости. Наличие в версии MPI v1.5 более чем 40 фреймворков предоставляет пользователям возможность по-разному соединять различные плагины различных типов и позволяет им создавать программный стек, который наиболее эффективен в их конкретной системе.

---

Далее Фреймворки

---

---