CC BY
65
Раздел I. Алгоритмическое обеспечение и аппаратно-программные средства ИМС
А.Л. Головинский, С.Г. Рябчун, А.А. Якуба СРЕДСТВА ПОСТРОЕНИЯ ГЕТЕРОГЕННОГО КЛАСТЕРНОГО КОМПЛЕКСА
В 2004 -2005 годах в Институте кибернетики НАН Украины был разработан и введен в исследовательскую эксплуатацию вычислительный комплекс из двух кластерных СуперКомпьютеров для Информационных Технологий (СКИТ), и есть перспектива существенного увеличения его мощности [1, 2]. Возникает проблема использования всего процессорного ресурса комплекса для решения одной боль -шой задачи. Дополнительным усложнением проблемы является то, что уже введенные в эксплуатацию суперкомпьютеры и следующие, которые будут установлены в Институте кибернетики, построены на разных процессорных архитектурах и с различными размерами слова (32 и 64 битов).
Возможны несколько различных подходов к решению этой проблемы:
• Разбить большую задачу на пакет подзадач с тем, чтобы обеспечить возможность параллельного выполнения подзадач на разнородных кла -стерах, т.е. пойти путем создания системы с использованием отдельных элементов грид-архитектуры.
• Создать средства объединения процессорных ресурсов и управления потоком задач в разнородном кластерном комплексе на основе существующей локальной вычислительной сети, используя МРІ или аналогичный интерфейс передачи сообщений.
• Применить типичные решения существующих грид-систем. В этом случае каждый кластер будет работать как отдельная вычислительная единица. Дальнейшее расширение подобной системы будет возможно не только за счет будущих кластеров Института кибернетики, но и за счет подключения к системе других территориально отдаленных кластеров институтов Ака -демии наук Украины, расположенных не только в Киеве.
Независимо от целей построения грид-системы унификация ее строения, доступа к ней, системы хранения данных и программ предоставляет возможность объединять разнородные ресурсы для решения одной задачи.
Типичные задачи пользователей
Основной тип задач, на которые ориентируется разработка, - исследовательские программы, программные пакеты в областях физики, химии, биологии.
Для выполнения в среде грид приемлемой будет только задача, имеющая интенсивность обращения к данным в оперативной памяти другого узла во много раз меньшую, чем интенсивность обращений к собственной оперативной памяти. Это означает, что многие задачи, которые эффективно распараллеливаются на унитарном суперкомпьютере, не следует переносить на грид, и отбор задач для такого применения есть нетривиальная проблема, решение которой не очевидно.
Можно выделить следующие категории параллельных вычислительных задач.
Большие вычислительные пакеты. Это большие пакеты программ, ориентированных на проведения расчетов в определенных предметных областях и на систему передачи сообщений МРІ, которая сейчас является стандартом де-факто. Взаимодействие между процессами в таких системах активное, поэтому создаются
они в расчете на кластерную работу. Кроме того, они требуют крупных объемов дисковой памяти для сохранения промежуточных результатов подсчетов.
Изменения в архитектуре таких пакетов для решения задач в режиме грида недопустимы, и типичной особенностью является то, что исходные файлы задач не зависят от аппаратной платформы. Поэтому выбор кластера, на котором будет выполняться задача, можно поручить системе. Привлечение ресурсов нескольких кластеров для одной задачи находится под большим вопросом, поскольку зависит от внутренней архитектуры пакета. В случае возможности работы в гетерогенной системе будет необходима индивидуальная адаптация каждого пакета.
Одной из проблем переноса прикладного программного обеспечения под грид, которую достаточно сложно решить без потери скорости вычислений, является адаптация прикладного пакета. Если существующий пакет разработан для выполнения на унитарном кластерном суперкомпьютере, то его перенос на грид-систему будет нежелателен из-за значительно меньшей пропускной способности системы управления файлами по сравнению с пропускной способностью интерконнекта, особенно тогда, когда в пакете моделируется общая память суперкомпьютера типа MPP (обычно общая память моделируется средствами интерконнекта, и в этом случае нужно менять всю модель).
MPI программы пользователей. Программы написаны на языках C, C++, FORTRAN. Подавляющее большинство таких программ не зависит от аппаратной архитектуры. Если у пользователя есть возможность задавать признак независимости его программы от аппаратной платформы, то выбор кластера, на котором будет выполняться задача, можно поручить системе.
Интенсивность взаимодействия между вычислительными процессами в задаче может быть разная. Для привлечения ресурсов нескольких кластеров целесообразно создание интеллектуальной системы, которая будет проводить интерактивный опрос пользователя в отношении пригодности его задачи для работы в гетерогенной системе и выработки предположений относительно среды выполнения. На основе ответов эта интеллектуальная система адаптирует рабочую среду к требованиям программы или отказывает в случае несоответствия требований программы реальным возможностям системы.
Комбинированный режим. Для исполнения задач, позволяющих разбивать программу на независимые блоки, целесообразным может быть комбинированный режим, при реализации которого предлагаемая структура состоит из менеджера блоков, распределяющего работу между вычислительными блоками, забирающего результаты и выдающего новую работу - все путем обмена файлами.
Экспериментальные системы. Выглядит целесообразным разворачивание в кластерном комплексе инновационных экспериментальных систем, в частности грид-системы X-Com [3], для дальнейшего исследования их эффективности и популярности среди пользователей. Такие системы требуют адаптации к архитектуре кластерного комплекса.
Запуск сверхбольших проектов, разработка инфраструктуры. Для проектов, в которых задействовано большое количество кластеров, можно использовать инфраструктуру распределенных вычислений BOINC [4]. Эта система ориентирована на работу в распределенной вычислительной системе, образованной преимущественно из персональных компьютеров, так что она должна быть адаптирована к ситуации, когда вычислительными модулями выступают кластеры.
Другим важным вариантом грид-системы есть известная система Globus Toolkit [5], но для нее требуется предварительная адаптация в кластерном комплексе.
Иерархия системы
Поскольку логическими блоками системы являются вычислительные кластеры, существуют два уровня иерархии.
Первый уровень - кластер, связи внутри кластера. Этот тип связей характеризуется использованием специализированного сетевого оборудования, которое имеет низкую латентность, высокую скорость передачи данных.
Второй уровень - связи между кластерами. На данном уровне используется массовое сетевое оборудование, обеспечивающее приемлемую скорость передачи данных.
Для первого уровня традиционным и эффективным подходом межпроцессорного взаимодействия есть протокол MPI, большая часть программных пакетов написана с использованием MPI.
Для второго уровня также не исключено использование MPI. Примером могут быть MPICH-G2 [6] или OpenRTE [7]. С некоторыми ограничениями это позволит выполнять параллельные программы в гетерогенной среде с минимальными или полностью отсутствующими изменениями программного кода. Но чаще для второго уровня практикуются другие подходы, для которых является общей идея разделения задачи на слабозависимые между собой подзадачи и запуск их на отдельных суперкомпьютерах.
Связь на втором уровне в десятки и сотни раз более медленная, чем связь на первом уровне. Поэтому стирать грань между кластерами для пользователя нецелесообразно (в случае, когда задача имеет интенсивный обмен между процессами). Пользователь должен осознавать и учитывать, что блоки программы выполняются на разных кластерах, и это выступает основным ограничением внедрения MPICH-G2 или OpenRTE, т.е. неприемлем подход, когда процессы распределяются между кластерами произвольно. Но если задача распределяет данные между процессами с учетом особенности гетерогенного интерконнекта, то прирост вычислительной мощности может быть значительным.
Можно разработать платформу, в которую интегрированы компоненты, использующие разные подходы. Тогда пользователь выберет ту, какая ему подходит. Единственное требование к компонентам: это должна быть общепринятая система для широкого круга пользователей.
Среда передачи сообщений
Наиболее привлекательной схемой организации вычислений в гетерогенном комплексе является модель передачи сообщений. Основным на сегодня остается стандарт MPI. Он поддерживает гетерогенность, в нем есть средства, обеспечивающие работу в гетерогенных сетях, обмен между узлами с разной архитектурой. К сожалению, в реализациях MPI поддержка гетерогенности ограничена. Наиболее развитой разработкой в этом направлении является OpenRTE - составная часть OpenMPI. На сегодняшний день в этом проекте поддерживается гетерогенность на уровне коммуникационной среды, обмен между узлами с разным порядком байтов в словах. Поддержка обмена между 32 и 64-битными архитектурами ожидается в ближайшее время. Наибольшее ограничение гетерогенности в нашем оборудовании - отсутствие поддержки SCI в OpenMPI и нежелание со стороны фирмы-производителя аппаратуры SCI (Dolphinics, Осло) самостоятельно разработать такую поддержку, но OpenRTE рассматривается нами как основной кандидат на среду передачи сообщений. MPICH-G2 ориентирована на выполнение в грид-среде Globus Toolkit, что накладывает достаточно много ограничений и создает неудобства для случая, когда не планируется использовать систему Globus.
Вторым вариантом является библиотека PVM - более старая разработка, предшествующая MPI с развитой поддержкой гетерогенности. PVM рассматривается как один из кандидатов на среду передачи сообщений.
С увеличением количества кластеров в комплексе на первый план выходит проблема восстановления после сбоев, которую не решают реализации модели передачи сообщений. Для большого комплекса подходят схемы вычислений, реа-лизованые в таких проектах как Х-Сот, Воіпс. Но эти проекты ориентируются на задачи, которые могут быть отнесены к классу «идеально параллельных» задач, где каждый процесс задачи слабо или вообще не зависит от иных процессов задачи. К тому же использование этих схем на кластерных комплексах полностью нивелирует преимущества высокопроизводительных и очень дорогих интерконнектов, то есть сам кластер в этой схеме выступает в качестве аппаратуры высокопроизводительной сети. Все же для некоторых задач такая схема будет наиболее оптимальной.
Управление задачами в гетерогенной среде
Наша ближайшая цель - первое направление, разбиение большой задачи на пакет подзадач с тем, чтобы обеспечить возможность параллельного выполнения подзадач на разнородных кластерах, для этого есть все необходимые компоненты, нужно только разработать новую версию системы управления задачами. Основные функциональные компоненты и средства для их создания следующие.
1. Пользователь уже обеспечен всеми функциями аутентификации и защиты.
2. Новая система предоставления процессорных ресурсов должна быть адаптирована к структуре управления задачами, которая уже есть и используется на кластерах ИК.
3. Необходимо иметь глобального менеджера ресурсов для того, чтобы большие гетерогенные задачи могли получить все необходимые для их выполнения ресурсы.
4. Если предполагается компиляция задачи для каждого кластера отдельно, то возможны два варианта выполнения - предварительно, до получения процессорных ресурсов, подготовить откомпилированные кодовые файлы для каждого из кластеров и только после этого поставить задачу в очередь на ресурсы, или получить необходимые ресурсы и выполнять задачу уже в обычном режиме, который используется сегодня -откомпилировать, поставить в очередь на ресурсы и получить их. Поскольку второй вариант предусматривает блокировку ресурсов на время компиляции, а это может быть длительным процессом, то его использование выглядит некорректным; невозможно заранее сказать, на каком кластере (т.е. на какой архитектуре) будут выделены ресурсы. Наиболее приемлемое решение - это первый вариант с предварительной компиляцией задачи для всех возможных ресурсов.
Доступ пользователей гетерогенного комплекса
Проблема аутентификации пользователя в системе является разносторонней. Нужно обеспечить одинаковый идентификатор пользователя на всех ресурсах, участвующих в задаче, иначе возникнут ошибки доступа к общим файлам. Если используются временные идентификаторы, то нужно решить проблему передачи рабочих данных временному пользователю и обеспечить их возвращение реальному пользователю. Проблема доставки данных и получения результата возникает и при отсутствии общей файловой системы.
На первом этапе реализации мы имеем совместную базу пользователей на ЬБЛР-сервере и общую файловую систему, однако в ближайшее время в кластерном комплексе будут задействованы другие кластеры со своими файловыми системами и соб -ственными базами пользователей, и нужно будет решать указанные проблемы.
Временная регистрация задачи представляет собой фиксацию соответствия имени пользователя, которому принадлежит задача, и некоторой свободной учетной записи пользователя конкретного кластера.
Временная учетная запись локализована в пределах одного кластера. Запись выдается из пула свободных учетных записей, которые есть на кластере. Учетная запись является первым ресурсом, который может получить задача. Размер пула должен быть не менее количества узлов кластера, только в этом случае задача всегда сможет получить временный идентификатор пользователя и не останется в очереди из-за нехватки ресурсов.
С завершением выполнения задачи свободная учетная запись возвращается в пул для дальнейшего использования.
Преимущество временных учетных записей перед постоянной или временной регистрацией пользователя состоит в лучшем регламентировании работы пользователей.
Выполнение задачи, разделенной на подзадачи с различными учетными записями, порождает проблемы с организацией безопасности данных, ограничивает обмен через совместную файловую систему. Также возникают проблемы с межкластерным обменом, который может в этом случае проводиться только супер -пользователем, поскольку имена учетных записей одного кластера неизвестны в другом. Поскольку все эти проблемы успешно решаются в грид-системах типа Globus Toolkit, то выглядит целесообразным частично или полностью использовать этот опыт в работах по суперкомпьютерному гриду.
Средства тестирования основных характеристик кластера
Тестирование кластера производится как программными пакетами (при этом требуется сверка полученных результатов с эталонными) так и специализированными тестами, измеряющими основные характеристики кластера. Иногда оценивается как факт прохождения теста, так и полученные им результаты.
Тестирование общей файловой системы
Тестирование файловой системы осуществляется пакетом fstest - модифицированной версии пакета [8]. Элементами модификации являются скрипт запуска, который обеспечвает пакетное прохождение теста и правильную работу алгоритма теста в случае выхода части узлов кластера из строя, а также подсистема визуализации результатов теста.
Методика тестирования состоит в синхронизированном тестировании файловой системы некоторым количеством параллельных процессов. При этом измеряемая пропускная способность усредняется по серии тестов, вычисляется ее стандартное отклонение. При таком подходе интересны как средняя пропускная способность (график ее приведен на рис. 1) так и ее среднеквадратическое отклонение. Большой разброс замеров говорит о гетерогености в структуре общей файловой системы, которая проявляется непостоянно. Такую неоднородность следует находить и устранять.
Из графика видно, что пропускная прособность возрастает с увеличением количества процессов линейно, пока не наступает насыщение. На этапе насыщения наблюдается некоторая периодичность, причина которой не ясна и требует дополнительного анализа.
Еще одним важным результатом есть сам факт прохождения теста, он говорит о надежности работы файловой системы в режиме критической нагрузки.
Рис. 1. Пропускная способность общей файловой системы Lustre
Интерфейс работы с пользователем
Базовая инсталляция кластера предоставляет командную строку как интерфейс работы пользователя. Это существенно сужает круг возможных пользовате -лей комплекса. Поэтому разработка удобных и функциональных интерфейсов пользователя является одной из важнейших задач.
Интерфейсы могут быть организованы на разной программной базе. Нами была выбрана Веб-технология как база для интерфейса: нет необходимости ставить дополнительное программное обеспечение у пользователя, веб-сервисы высоко популярны, удобны в программировании.
Необходимо четко установить баланс между функциональностью и сложностью интерфейса пользователя. Чем функциональнее интерфейс, тем он сложнее. На первых порах пользователям нужен простой и понятный интерфейс, который не будет отвлекать их от поставленных задач.
Task management interface
Choose task options:
Taik working directory (will be the ia%k name 11 GAUSSIAN w\ Path to the csccbi able filej Ta.\k command line parameters|
Number of pn)ccwri|
Cluster architecture ia32 Time limit, rain (
P* Make Execute task
tasks
al 405*6 Fri Sap 1 Hi56:07 3006 40M Thu Sap 7 14120c22 2006
Running tasks on n000.c02.icyb:
jgbid uurmiau
Running tasks on пООО.сОЗ.ісуЬ:
■ 1 uni load 1 aba arrort Qubit to contact alum control lac I о
ct failure)
Summary of n000.c02.icyb:
РЛВТГПОВ *V*IL TIME. IM17 IDCKS STA7B КШ.Ш
квоті * up 2*02i00i00 3 alloc n[020-022|
квот* up 2'02100100 1 idi* n02)
Summary of n000.c03.icyb:
alum load_parti livable to contact alurm ccetroller Iccnnact la:lure I
—Jobs on n000.c02.icyb: “
Jotold*l*0 Uae*ld*tiicuaU049i Croupld*ti)cua(l049>
Priori ty-43?4»«75f Partition-***» aalebFlaq-l JUlocMocte:Bi<*=®00Dsllfi2 TiiMLinit«40
JcMtate-WlOmC gUrtTin»-0»/0714il0i4f BmJT««r-0»/07 14i50i47 KoS«£.lat=o(020 023] Hod*L:atlndle«a*0.2,-1 P*qProc>-5 Min>Jodee-C Sbarad-0 Ccntiguou,aeO CPUa/ta«fc-0 K»r»Proca*0 KlaK«aaryxD Paaturaa* latill) Иіп1>цЛіак»0 l>apaodeiey*0 Account* laull) Raaaor.~ficc.e XetvorK' mull I
Рис 2. Веб-интерфейс пользователя кластерного комплекса
Для некоторых групп пользователей целесобразно создание специализированных интерфейсов для работы с программными пакетами.
Концепция построения кластерного комплекса
Можно предложить структуру комплекса (рис. 3), в состав которого входят следующие компоненты.
Планировщик интеллектуальной системы управления пользователя. Планировщик на основе интерактивного опроса пользователя выбирает нужные ресурсы и сервисы.
Open LDAP
Сервисы систем организации вычислений. Такими системами являются X-Сот и ВОГЫС - концептуально близкие системы, предоставляющие отработанные эффективные варианты организации вычислительного процесса.
Программные сервисы. Позволяют пользователю работать с специализированным программным обеспечением, ориентированным на решение определенного круга задач и адаптированным для работы в грид, например, с такими пакетами как ватеББ, вготасє.
Сервис классических кластерных задач. Этот сервис обеспечивает эффективное использование ресурсов кластеров при работе МРІ программ пользователя.
Порталы. Специализированные Web-порталы являются интерфейсами пользователей к сервисам системы.
Строение этих компонентов должно отображать специфику использования кластерного комплекса. Компоненты должны предоставлять удобную рабочую среду пользователям гетерогенного комплекса.
Пользователь взаимодействует с планировщиком, который опрашивает кластеры и показывает пользователю существующие ресурсы. Планировщик проводит опрос пользователя и предлагает схему запуска и паспорт на задачу. Далее планировщик проводит запуск и на основе паспорта использует нужный сервис организации вычислений или интерфейс к установленному прикладному программному пакету.
В свою очередь, интерфейсы пакетов проводят запуск задачи и ее компонентов на управляющих серверах кластеров. Отдельно выделяются порталы, предоставляющие максимально простой пользовательский интерфейс к пакетам и компонентам, позволяющим это.
Заключение
Предполагается, что на основе освещенных подходов к построению гетерогенного суперкомпьютерного комплекса будет создан мощный объединенный вычислительный ресурс, который сможет обслуживать пользователей с максимальным использованием всех процессорных ресурсов комплекса при решении сверхбольших задач и динамичное распределение задач между свободными ресурсами, если задачи это поддерживают.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Коваль В.Н., Рябчун С.Г., Сергиенко И.В., Якуба А.А. Суперкомпьютерный проект Института кибернетики НАН Украины // Искусственный интеллект, № 3, 2QQ5. С.37-42.
2. Коваль В.Н., Рябчун С.Г., Сергиенко И.В., Якуба А.А. Суперкомпьютерные кластерные системы - организация вычислительного процесса» // Проблеми програмування, 2QQ6, № 2-3. С.197 - 21Q.
3. http://www.parallel.ru/parallel/about/lab.html
4. http://boinc.berkeley.edu/
5. http://www.globus.org/toolkit/about.html
6. http://www3.niu.edu/mpi/
7. R.H.Castain, T.S.Woodall, D.J.Danial, J.M.Squyres, B.Barrett, G.E.Fagg «The Open Run-Time Environment (OpenRTE): A Transparent Multi-Cluster Environment for High-Performance Computing», http://www.open-rte.org/papers/euro-pvmmpi-2QQ5-orte/ http://parallel.ru/ftp/tests
Ю.И. Доронченко
ОРГАНИЗАЦИЯ ЭФФЕКТИВНЫХ ВЫЧИСЛЕНИЙ ДЛЯ РЕКОНФИГУРИРУЕМЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ НА ОСНОВЕ
ПЛИС
Несмотря на бурное развитие средств вычислительной техники, современные серийно выпускаемые компьютеры не позволяют в приемлемое время решать сложные научнотехнические задачи, требующие выполнения большого количества операций. Одним из способов ускорения вычислений является повышение тактовой частоты. В настоящее время происходит непрекращающийся рост рабочих частот современных вычислительных средств, однако в обозримом будущем увеличить данную характеристику можно максимум на порядок, что совершенно недостаточно для решения задач большой сложности. Следовательно, необходимо увеличивать число одновременно обрабатываемых данных за счет распараллеливания и конвейеризации вычислений. Этот путь имеет резерв производительности на несколько порядков. Однако архитектура традиционных многопроцессорных систем не обеспечивает пропорциональный рост производительности при увеличении числа процессоров [1]. Более того, при организации параллельного вычислительного процесса производительность системы может снизиться из-за возрастания системных потерь.
Наиболее эффективно вычислительная задача может быть решена с помощью создания специализированных вычислительных устройств, структура которых адекватна структуре решаемой задачи. Однако создание специализированного вычислителя для решения каждой задачи является чрезвычайно дорогостоящим процессом. Решается эта проблема созданием многопроцессорных вычислительных систем с программируемой архитектурой (МВС ПА). Технология создания таких систем разработана в Научноисследовательском институте многопроцессорных вычислительных систем им. академика А.В. Каляева Таганрогского государственного радиотехнического университета (НИИ МВС ТРТУ) под руководством академика РАН А.В. Каляева. МВС ПА позволяют достичь высокой реальной производительности путем формирования в рамках своей архитектуры виртуальных специализированных вычислителей со структурой, адекватной структуре решаемой задачи или ее фрагмента.
В НИИ МВС ТРТУ создан целый ряд МВС ПА на основе самых современных ПЛИС. Структуры на основе ПЛИС способны адаптироваться к структуре решаемой задачи на уровне логических элементов, что в сочетании с принципами программирования архитектуры позволяет увеличить удельную производительность системы за счет эффективного использования аппаратных средств. МВС ПА предназначены для выполнения алгоритмов цифровой обработки сигналов, символьной
