Граф-схемное потоковое параллельное программирование (Граф-схемное потоковое параллельное программирование 2), страница 4

6Блок графическойразработки ГСППБлок текстовойразработки ГСППБлок взаимнойтрансляцииБлоккоординацииБлок взаимодействия сбазой данныхОС WindowsБаза данныхРис. 6. Архитектура инструментальной средыБлок разработки ГСПП в графическом представлении позволяет визуальноразрабатывать ГС, а именно добавлять, удалять и редактировать элементы ГСПП. Такжеданный блок следит за корректностью вводимых данных и своевременным обновлениеминформации в окнах инструментальной среды.Блок разработки ГСПП в текстовом представлении управляет ходом построениятекстового представления и по своему назначению представляет собой аналог блокаразработки графического представления, но работает с текстом ГСПП.Блоки графической и текстовой разработки ГСПП помимо редактирования,синтаксического анализа и выявления ошибок в ГС создаваемых программ имеют средствадля поддержки процессов разработки программ «сверху – вниз» и «снизу – вверх».Декомпозиция и структурирование, присущие процессу разработки программ «сверху –вниз», легко реализуются в инструментальной среде благодаря модульной организацииГСПП и возможности выделения подсхем.Механизм задания интерпретации ГС требует обращения к конкретному языку (илиязыкам) последовательного программирования и их реализации на соответствующейплатформе.

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

Все визуально созданные пользователемэлементы ГСПП однозначно отображаются в текстовое представление. Второй подблокпереводит текстовое представление ГСПП в графическое. Для взаимной трансляции междупредставлениями ГСПП используется ее внутреннее представление в формате XML, котороетакже используется в качестве исходной информации для выполнения ГСПП навычислительной системе (см. раздел 3).В инструментальной среде используется база данных, как средство для длительногохранения всей информации о разрабатываемых пользователями ГСПП.

Также в ней10сохраняются «следы» («логи») разработки ГСПП, их завершенные версии и библиотекиподпрограмм.Отметим также, что в инструментальной среде предусмотрен целый ряд соглашений,усиливающих возможности визуального проектирования ГСПП за счет выбора цвета дляизображения стандартных типов на входах и выходах модулей, цветового выделенияподстановочных модулей (отличного от обычных модулей) и др.В заключение этого раздела отметим, что арсенал средств поддержки разработкипрограмм может быть намного шире, в частности, в настоящее время планируется расширитьинструментальную среду путем включения в нее средств моделирования процессоввыполнения ГСПП на заданной конфигурации кластера.3.

Реализация ЯГСПП на кластерных системах3.1 Физическая среда реализацииМы исходим из того, что локальная сеть (в том числе сеть персональныхкомпьютеров) является основным “строительным блоком” или узлом вычислительнойсистемы или кластера (рис. 7)Рис. 7. Узел кластераУзел кластера – хорошо сбалансированная по отношению, к быстродействиюкомпьютеров, их количеству и пропускной способности коммуникации вычислительнаясистема, так что на ней можно эффектно осуществлять реализацию параллельныхвычислений в достаточно широком диапазоне вариаций степени распараллеливанияпрограмм [11] от “крупнозернистого” до “мелкозернистого” параллелизма.Задача сервера на рис.

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

По-сути, эта идеология построения большихмасштабируемых вычислительных структур, продиктованная также техническими итехнологическими соображениями, прослеживается в архитектуре всех самых мощныхкомпьютерных систем: SPP, Hewlett Packard и Convex [14], SP1 и SP2, ASCI WHITE IBM [15]и др.В них в качестве узла обычно выступает 8, 16 или 32 – процессорная подсистема, вкоторой используются самые быстрые коммуникации (коммутаторы, переключательныематрицы и т.п.). Для межузловых соединений применяются менее дорогие и скоростныекоммуникации.

Эта особенность в организации вычислительной системы требует, чтобы привычислениях более частые обменные взаимодействия происходили внутри узла, так как в11нем можно планировать вычисления с большей степенью распараллеливания, т.е.мелкозернистый параллелизм. В то же время на межузловом уровне планирование загрузки(ее реализует сервер узла, рис. 7) должно осуществляться на более высоком уровнесложности частей программы, пересылаемых между узлами, с целью уменьшения времени,затрачиваемого на обмены [11].Отметим также, что компьютеры узла могут быть многопроцессорными, иметьвекторные сопроцессоры, что так же должно учитываться как на программном уровне, так ипри планировании параллельных вычислений на кластере.3.2 Управление параллельными вычислениями на кластереСобственно задача управления параллельными вычислениями формулируется какзадача минимизации времени выполнения параллельной программы и используемых приэтом ресурсов (обычно количества используемых компьютеров или процессорных элементовв вычислительной системе).

Ее практическое решение осуществляется через механизмыпланирования и требует тонкого учета специфики задания выполняемой параллельнойпрограммы, степени ее распараллеливания, загруженности различных элементоввычислительной системы (компьютеров, коммуникаций и др.), времени их безотказнойработы и др. [1,10,11].Эта проблема требует специального анализа, поэтому далее рассматриваются, восновном, организационные аспекты реализации управления параллельным выполнениемГСПП на кластерах.В организационной структуре управления можно выделить два относительносамостоятельных уровня: общесистемный, в задачу которого входит управлениеконфигурированием кластера, контроль и планирование загрузки (узлов, компьютеров),реакция на отказы компонентов кластера и др., и уровень собственно управленияпараллельными процессами, индуцируемыми при выполнении ГСПП.На рис.

8 представлена структура и основные блоки управления процессомвыполнения ГСПП на кластерных системах.Блоки системного уровняУКИНОТОБУЗАДКОУБУППЛИнтерпретаторОСБлоки процессного уровняРис. 8. Структура и основные блоки управления процессом выполнения ГСППКратко опишем функции указанных на этом рисунке блоков.АД – блок администрирования, в функции которого входят инсталляция программныхсредств для управления на кластере, оперативное получение информации офункционировании (например, загрузке) кластера, “вмешательство” в его работуадминистратора, если это оказывается необходимым.УК – блок управления конфигурациями, в задачу которого входит конфигурирование узлакластера (или кластера в целом) и его реконфигурирование в процессе функционирования всвязи с отказами и восстановлениями компонентов кластера (компьютеров, коммуникаций идр.), необходимостью динамического масштабирования.ИН – блок инициализации выполнения ГСПП (см.

далее).12ОТ – блок отказоустойчивости; его функции: реакция на отказы компонентов кластера иреализация принятой стратегии периодического сохранения состояний компонентовкластера на случай их отказа. Стратегия может быть или простейшей, предусматривающейпериодическое сохранение состояния компьютера или другого контролируемого компонентакластера на общем носителе памяти (например, дисковой памяти сервера узла) или болеесложной, например основанной на той или иной схеме “договоренности” междукомпьютерами о периодическом сохранении компьютерами состояний других компьютеровна случай отказа последних [10].Отказы или восстановления компонентов кластера, фиксируемые блоком ОТ, такжепередаются блоку УК в качестве информации для изменения конфигурации кластера.ОБ – блок реализации по соответствующему протоколу интерфейсных взаимодействий(обменов сообщениями и данными) между компьютерами кластера.УЗ – блок управления загрузкой кластера, ее прогнозирования и перераспределенияпараллельных процессов между компьютерами узла или между узлами кластера с цельюдостижения максимальной эффективности его работы.

Этот блок работает в тесной связи сблоком планирования процессов (ПЛ) каждого компьютера, получая через негонеобходимую информацию о загруженности компьютера (см. п. 3.2.2).Блок координации (КО) представляет из себя в программном смысле монитор иосуществляет все взаимодействия друг с другом перечисленных блоков.Блоки процессного уровня непосредственно связаны с определением готовности иидентификацией индуцируемых при выполнении ГСПП процессов (блок управлениябуферами – УБ), их организацией и контролем состояний (блок управления процессами УП)и планированием выполнения (блок планирования - ПЛ).Блок УП также реализует, путем обращения к операционной системе (ОС) функции,связанные с постановкой процессов в очередь для выполнения на процессоре компьютера иидентификацией команд обращения к блоку управления буферами, сопоставленными КГВхмодулей ГСПП (команды READ, WRITE, OUT, CHECK, см.