CC BY
36
УДК 004.75
М. А. Городничев
Новосибирский государственный университет ул. Пирогова, 2, Новосибирск, 630090, Россия
Институт вычислительной математики и математической геофизики СО РАН пр. Акад. Лаврентьева, 6, Новосибирск, 630090, Россия
E-mail: maxim@ssd.sscc.ru
ОБЪЕДИНЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ КЛАСТЕРОВ ДЛЯ КРУПНОМАСШТАБНОГО ЧИСЛЕННОГО МОДЕЛИРОВАНИЯ В ПРОЕКТЕ NUMGRID *
Представлен программный комплекс NumGRID для организации вычислений на объединении высокопроизводительных вычислительных кластеров в целях крупномасштабного численного моделирования. Дан анализ проблем организации распределенных вычислений на кластерах и обзор родственных проектов. Продемонстрированы результаты экспериментального исследования системы NumGRID.
Ключевые слова: NumGRID, MPI, грид, распределенные вычисления, кластерные вычисления.
Введение: задача объединения вычислительных кластеров
Объединение вычислительных систем. В целях обеспечения научных исследований вычислительными ресурсами разрабатываются сверхмощные суперкомпьютеры развиваются инфраструктурные проекты по организации доступа ученых к распределенным вычислительным ресурсам (грид 2), к вычислительным центрам коллективного пользования 3, создаются распределенные вычислительные системы на основе объединения персональных компьютеров добровольцев 4 через Интернет. Широкое распространение получили относительно малые вычислительные системы (порядка десятков ТИор8) кластерного типа (кластеры), которые приобретают университеты, институты и прочие организации. Такие малые системы являются наиболее доступными для ученых средствами решения вычислительных задач. Обычно системы используются в многопользовательском режиме, и пользователи ставят свои задачи в очередь. Такого рода системы также объединяют в грид с целью распределения пользовательских задач между вычислительными ресурсами дружественных организаций. Однако, как правило, такое объединение предполагает, что задача пользователя назначается целиком в один из кластеров, а распределение процессов параллельной задачи по вычислительным узлам нескольких кластеров невозможно: штатные средства современных кластеров спроектированы так, чтобы обеспечивать высокоскоростные коммуникации между процес-
* Проект поддержан грантом РФФИ № 10-07-00454а.
1 Top 500 Supercomputer Sites. - URL: http://www.top500.org.
2 XSEDE (https://www.xsede.org), LHC Computing Grid (http://lcg.web.cern.ch/lcg), Grid5000 (https://www.grid5000.fr), ГридННС (http://ngrid.ru) и др.
3 Межведомственный Суперкомпьютерный Центр РАН (http://www.jscc.ru), Сибирский Суперкомпьютерный Центр (http://www2.sscc.ru), Информационно-вычислительный центр НГУ (http://nusc.ru) и др.
4 Примеры: BOINC. Open-source software for volunteer computing and grid computing (http://boinc.berkeley.edu), World Community Grid (http://www.worldcommunitygrid.org)
1818-7900. Вестник НГУ. Серия: Информационные технологии. 2012. Том 10, выпуск 4 © М. А. Городничев, 2012
сами, расположенными на узлах кластеров, и не предусматривают общения процессов между кластерами. Такое положение дел имеет исторические причины: во-первых, кластерные системы появились раньше, чем желание их объединить, и, во-вторых, существенно худшая производительность сетей связи между кластерами по сравнению с производительностью внутренних сетей кластеров делала нецелесообразным запуск параллельных программ с распределением процессов между кластерами. Считалось, что для распределенного счета подходят только задачи, где отсутствует необходимость в коммуникациях между процессами либо коммуникации крайне малы. Инструменты для решения таких задач были разработаны (BOINC, X-Com [1] и др.).
Зачем распределять процессы параллельных задач между кластерами? Какие выгоды дала бы возможность запускать параллельные задачи с распределением процессов между кластерами? Во-первых, большее количество процессоров и памяти для одной задачи позволило бы увеличить масштаб решаемых задач. Во-вторых, возможность произвольного распределения процессов повысила бы гибкость при планировании распределения задач между кластерами в грид. В-третьих, появилась бы возможность вовлекать в расчеты устаревающие вычислительные комплексы, собственная производительность которых недостаточна для актуальных задач. В-четвертых, появилась бы возможность учитывать наличие специализированного оборудования или программного обеспечения, в том числе дорогостоящего, на тех или иных кластерах при распределении процессов параллельной программы, например: часть процессов программы в таком случае бы производила расчеты с использованием графических ускорителей на одном кластере, другая часть процессов получила бы возможность использовать библиотеки численных методов, имеющиеся на втором кластере. В-пятых, наличие средств для подключения дополнительных компьютеров позволило бы планировать постепенное наращивание мощностей распределенной системы.
Три технологических прорыва. Интерес к совместному использованию вычислительных ресурсов, неоднородных как в смысле процессоров, так и в смысле связей между процессорами, приводит к: развитию вычислительных алгоритмов, допускающих гибкость в организации коммуникаций между процессами и даже частичную потерю сообщений [2; 3]; развитию методов организации вычислений, позволяющих выполнять коммуникации на фоне счета и динамически перераспределять вычисления с целью оптимизации загрузки вычислительных узлов и сетей связи [4-6]. В то же время характеристики (пропускная способность, латентность) каналов, связывающих кластеры, становятся сопоставимыми с характеристиками сетей связи между узлами кластеров.
Эти три технологических прорыва открывают перспективу для применения распределенных вычислительных систем к решению крупных задач с более интенсивными коммуникациями.
В связи с этим актуальной является проблема разработки средств, которые позволили бы распределять процессы параллельных задач между вычислительными узлами нескольких кластеров и обеспечивать коммуникации между распределенными процессами.
Проект NumGRID
Цель и требования к объединению вычислительных кластеров в проекте NumGRID. Цель проекта NumGRID [7] заключается в разработке программного комплекса для поддержки исполнения параллельных программ на объединении вычислительных кластеров с распределением процессов параллельных программ между узлами вычислительных кластеров. В отличие от таких систем, как Globus Toolkit 5, ставящих задачу объединения вычислительных ресурсов в общем, проект NumGRID сконцентрирован на разработке простого инструмента пользовательского уровня для распределения процессов параллельной программы между кластерами, к которым пользователь имеет непосредственный доступ посредством личных учетных записей. Принципиальным является обеспечение единой коммуникационной среды для распределенных процессов на основе стандартов MPI. Выбор стандарта MPI в качестве
5 Globus Toolkit Homepage: http://www.globus.org/toolkit
коммуникационного протокола обосновывается доминирующим положением MPI среди средств разработки параллельных программ численного моделирования.
К разработке программного комплекса в проекте NumGRID предъявляются требования, обоснованные сложившейся практикой организации вычислений и целью проекта.
1. Общая коммуникационная среда для процессов, распределенных по нескольким кластерам, должна быть реализована на основе стандартов MPI.
2. О структуре кластеров и сети связи между ними нужно предполагать следующее: каждый кластер состоит по крайней мере из головного / управляющего узла и вычислительных узлов; при этом вычислительные узлы предназначены для запуска на них вычислительных процессов и связаны между собой высокоскоростной сетью, а с головным узлом - сетью, как правило, меньшей пропускной способности, поддерживающей протокол TCP; головной узел имеет еще по крайней мере один сетевой интерфейс, поддерживающий протокол TCP, через который узел может общаться с головными узлами других кластеров; головной узел используется для компиляции задач, управления локальными очередями задач и мониторинга задач.
3. Процессы параллельной программы должны размещаться на вычислительных узлах кластеров, узлы разных кластеров не имеют прямого сообщения друг с другом.
4. Должен быть предоставлен удобный интерфейс для задания конфигурации объединения кластеров, управления ресурсами и задачами.
5. Должны быть созданы условия для обеспечения динамических свойств прикладных программ (динамическая настраиваемость на доступные ресурсы, динамическая балансировка нагрузки, системы мониторинга и т. д.).
6. Должна обеспечиваться безопасность вычислений.
7. Каждому пользователю для запуска распределенных задач на нескольких кластерах должно быть достаточно иметь учетные записи на этих кластерах и пакет NumGRID. Организация NumGRID не должна требовать изменений в практике и политиках администрирования кластеров.
8. Кластеры могут быть разнородными в аппаратном, системном программном обеспечении, линии связи могут быть разной пропускной способности, кластеры могут иметь различную административную подчиненность.
Программный комплекс NumGRID предназначен для объединения разнородных вычислительных кластеров в единый вычислительный ресурс на основе частичной реализации стандарта MPI-2.2 6. NumGRID обеспечивает возможность запускать MPI-приложение так, чтобы процессы приложения были распределены по рабочим узлам нескольких кластеров. При этом процессы составляют один коммуникатор MPI и имеют возможность обмениваться между собой средствами MPI.
Схема устройства объединенного вычислительного ресурса NumGRID представлена на рис. 1.
0 1 2 ... п-2 п-1
MPICH
il J_________________L, _■
Скоростная
сеть
ТСРЛР
Шлюз NumGRID
' ihteniet
Рис. 1. Устройство NumGRID
6 MPI Documents: http://www.mpi-forum.org/docs/docs.html
В примере объединяются два кластера через Internet. Каждый кластер имеет рабочие узлы, объединенные высокоскоростной сетью (Myrinet, Infiniband и др.). Также узлы связаны с головным узлом сетью с меньшей пропускной способностью, поддерживающей протокол TCP. Процессы приложения, находящиеся на рабочих узлах одного кластера обмениваются между собой через высокоскоростную сеть средствами специфичной для кластера библиотеки MPI, позволяющей использовать возможности высокоскоростной сети. В примере это библиотеки MPICH и LAM-MPI. Для процессов, распределенных по рабочим узлам двух кластеров, поддерживается глобальная адресация в рамках одного коммуникатора MPI. Сообщения между процессами, расположенными на разных кластерах, проходят путь через головные узлы кластеров, где для этих целей перед стартом приложения запускаются шлюзы.
Программный комплекс NumGRID состоит из трех компонентов:
• шлюз;
• библиотека NumGRID-MPI;
• графическая система управления NumGRID.
С помощью графической или консольной системы управления NumGRID пользователь задает набор кластеров, которые он хочет объединить для решения задачи, задает параметры авторизации на каждом из кластеров (пользователь должен иметь личные учетные записи на кластерах), параметры подзадач: сколько процессов на каждом кластере должно быть запущено и как распределены, путь на своей рабочей машине до архива с файлами своей программы и входными данными.
По команде запуска задачи система управления осуществляет авторизацию на кластерах, отправляет файлы пользователя и системные файлы NumGRID на кластеры, выполняет сборку программы пользователя, а также шлюза и библиотеки NumGRID-MPI. Для обеспечения универсальности системы управления сборка программы пользователя осуществляется на основе предоставленных пользователем инструкций (в виде Makefile). На головных узлах кластеров запускаются шлюзы и устанавливают между собой каналы связи в соответствии с топологией, заданной пользователем. Затем на каждом кластере в соответствии с параметрами подзадач запускается или ставится в очередь программа пользователя. Сборка программы пользователя с библиотекой NumGRID-MPI вместо обычных библиотек MPI наделяет программу пользователя способностью ориентироваться в объединении кластеров. Поэтому запущенная программа пользователя автоматически в начале своей работы (в функции MPI_Init) осуществляет подключение к шлюзу, работающему на головном узле данного кластера. Шлюзы распространяют информацию о подключении подзадач между собой.
Когда все подзадачи подключились к своим шлюзам, шлюзы информируют подзадачи об общей конфигурации системы, и таким образом подзадачи осуществляют возврат из функции MPI_Init() с полной информацией о распределенной системе и проинициализированным коммуникатором MPI_COMM_WORLD, объединяющим все распределенные процессы.
Пользователь имеет возможность наблюдать за состоянием исполняющихся задач посредством графической системы управления NumGRID, завершать задачи, забирать результаты вычислений.
Все обращения к функциям MPI анализируются библиотекой NumGRID-MPI. Если требуемые коммуникации включают лишь процессы, расположенные в рамках одного кластера, то вызывается предустановленная на кластере библиотека MPI, способная эффективно использовать высокоскоростную сеть кластера. Если требуются коммуникации между процессами, расположенными на различных кластерах, то сообщения транслируются через шлюзы.
Применяется метод коммутации пакетов при трансляции сообщений через шлюзы. Это позволяет контролировать расход памяти на головных узлах, параллельно отсылать несколько сообщений, использовать несколько путей доставки сообщения для повышения производительности сети. Реализовано расширение функций p2p стандарта MPI функциями с зада-
нием приоритета сообщений. Учитывается топология сети при реализации коллективных операций.
Проблемы организации
распределенных вычислений на объединении кластеров
и обзор родственных проектов
Известно несколько проектов [8-12], которые ставят своей задачей объединение вычислительных систем на основе стандартов MPI. Системы, разрабатываемые в рамках этих проектов, не удовлетворяют полностью списку требований к NumGRID, однако многие проблемы, стоящие перед NumGRID, также решались в этих проектах. Далее рассмотрены наиболее значимые проблемы и подходы, которые применяются для их решения.
Обеспечение эффективности коммуникаций внутри кластеров. Как правило, в современных кластерах используется несколько типов сетей для объединения узлов. Сети с относительно малой пропускной способностью и относительно большой задержкой (латентностью) используются для задач управления узлами кластера и организации распределенных файловых систем. Для обмена данными между процессами параллельных вычислительных приложений используются скоростные сети с высокой пропускной способностью и малыми латентностями. При объединении кластеров важно, чтобы коммуникации внутри кластеров оставались эффективными. Тогда как между кластерами без существенного изменения системного ПО возможно устанавливать соединение только по протоколам TCP/IP, то в зависимости от технологии скоростной сети внутри кластеров могут применяться различные реализации MPI, способные использовать оборудование более эффективно, чем на высоком уровне TCP/IP. Обычно производитель вычислительных систем поставляет такие реализации вместе с аппаратурой, если применяются специальные сетевые аппаратные решения, либо администраторы и пользователи систем могут выбрать свободно или коммерчески доступные библиотеки (MPICH-GM, OpenMPI, Intel MPI, Voltaire MPI, HP-MPI) для распространенных коммуникационных технологий (Myrinet, Infiniband).
Необходимость использования специализированных реализаций MPI для внутрикластер-ных коммуникаций обусловила отказ от коммуникационной библиотеки Nexus [13] в проекте MPICH-G [14] и разработку новой версии системы MPICH-G2 [9].
Обеспечение коммуникаций между внутренними узлами различных кластеров. Ранние подходы к объединению вычислительных систем на основе MPI [14; 9] предполагали, что процессы, располагающиеся на одной вычислительной системе, могут установить прямое соединение в смысле TCP с процессами, расположенными на другой системе. Для современных кластерных систем установление таких прямых соединений невозможно, поэтому необходимо организовывать трансляцию сообщений с внутренних узлов кластера через узел, имеющий сетевые интерфейсы как внутрь кластера, так и в сеть связи между кластерами. Далее такой узел будем называть узлом трансляции. Трансляция может быть осуществлена неявно с помощью технологий NAT [15] или VPN. Эти технологии обеспечивают возможность установления соединения TCP между процессами, расположенными на компьютерах в различных частных сетях. Таким образом, для процессов создается иллюзия нахождения в одной сети и могут быть применены средства, например MPICH-G2 [9], для организации межкластерных взаимодействий. Однако такая организация вычислений не будет учитывать фактическую топологию сети связи, соответственно организация межкластерных коммуникаций будет неэффективной, особенно для операций коллективного взаимодействия процессов. В проекте PACX-MPI [10] предполагается, что узел трансляции имеет доступ как в высокоскоростную сеть внутри кластера, так и в сеть между кластерами. Для организации передачи сообщений между кластерами на узле трансляции запускается дополнительный процесс MPI, помимо процессов, необходимых для выполнения прикладной логики параллельной программы. Через этот процесс все остальные процессы внутри данного кластера общаются с внешним миром. Преимущества такого подхода: PACX-MPI осведомлен о топологии сети и на этой основе может оптимизировать межкластерные взаимодействия, эффективно используется высокоскоростная сеть. Недостатки: 1) часто в современных кластерах узлы, имеющие доступ во внешние сети, не имеют подключения к скоростной сети; в таких
системах требуется реализация трансляции сообщений через внутреннюю медленную TCP/IP-сеть; 2) для трансляции требуются дополнительные процессы MPI, не соответствующие логике приложения.
Поскольку идеология грид предполагает сохранение локальных политик администрирования отдельных вычислительных систем при включении их в метакомпьютер, то все порты TCP, кроме, обычно, порта для доступа по протоколу SSH закрыты с помощью сетевого экрана (файервола). Поэтому для передачи сообщений между кластерами применяются технологии проксирования и туннелирования через доступные порты [16].
В NumGRID предполагается использование ограниченного числа доверенных кластеров с выделенными линиями связи между ними, поэтому необходимые порты для связи между кластерами могут быть открыты. В случае если NumGRID нужно использовать в общественных сетях, возможно применения туннелирования соединений через SSH.
Учет особенностей сетевой организации для реализации эффективных межкластерных коммуникаций. Учет топологии сети рассматривается на уровне реализации взаимодействия между двумя процессами (р2р-взаимодействия) и на уровне реализации коллективных операций. Передача р2р может быть оптимизирована, когда существует более одного физического пути между коммуницирующими узлами. В таком случае применяется разбиение сообщения на части и параллельная доставка частей по разным путям [17].
В случае, когда для доставки сообщения требуется использование узлов трансляции, необходимо контролировать использование памяти на узлах трансляции, и, кроме того, нельзя допускать блокирование узла трансляции в процессе доставки сообщения большого размера: нужно обеспечивать возможность прохождения сообщений малого размера на фоне доставки большого. Контроль памяти возможен только посредством разбиения сообщения на части. Избежать блокирования можно, если поддерживать многопоточную обработку сообщений на узле трансляции, либо посредством разбиения сообщений на части. Таким образом, для решения рассмотренных задач целесообразно применение пакетирования сообщений [18].
Применение классификации сообщений по приоритетам (использовалось, например, в проекте MPIRT 7) целесообразно для обеспечения приоритетной доставки сообщений малого размера, имеющих смысл для управления ходом вычислений.
Эффективная реализация коллективных коммуникаций в неоднородной коммуникационной среде. Большинство упомянутых проектов занималось вопросом оптимизации коллективных коммуникаций в неоднородных сетях.
В работе [19] показано, что если время завершения посылки сообщения близко ко времени завершения приема сообщения, то оптимальной схемой рассылки сообщений для реализации широковещательной рассылки будет бинарное дерево. Если же время завершения посылки существенно больше времени завершения отправки, то оптимальная схема рассылки: корневой узел самостоятельно посылает получателям сообщение непосредственно. Таким образом, в случае объединения кластеров оптимальной схемой коллективных коммуникаций будет бинарное дерево внутри кластеров и посылка каждому кластеру по отдельности между кластерами [11]. Дополнительная оптимизация возможна, если кластеры не связаны физически в полный граф. В таком случае между кластерами, не имеющими непосредственной связи, сообщения могут двигаться через промежуточные кластеры. Поэтому если требуется широковещательная рассылка, то корневой процесс должен послать лишь одно сообщение по каждому физическому соединению, а промежуточные кластеры должны распространить это сообщение далее самостоятельно. Таким образом удается избежать многократной передачи одних и тех же данных по одним и тем же отрезкам сети.
Оптимизация приложений с учетом неоднородностей распределенной вычислительной среды. Несмотря на любые оптимизации алгоритмов межкластерных коммуникаций, неустранима проблема относительно низкой пропускной способности и высоких задержек в сети между кластерами. В таких условиях приложения, которые по своей природе требуют частых коммуникаций и в большом объеме между всем процессами приложения, не могут эффективно выполняться в распределенной среде. Для того чтобы приложение могло выполняться эффективно, необходима возможность равномерно распределять вычислительную загрузку
7 Real-Time Message Passing Specification based on MPI: http://www.mpirt.org
между всеми узлами вычислительной системы и передавать сообщения на фоне счета: сообщения должны идти по сети тогда, когда процессоры в это время заняты другой работой. Для минимизации простоев процессоров может потребоваться реализация динамического перераспределения работы между процессорами.
В проектах [20-22] реализовано автоматическое перераспределение загрузки на уровне процессов MPI: между узлами вычислительной системы передаются именно процессы MPI. Такой подход упрощает разработку приложений, однако не учитывает структуру взаимодействий процессов прикладной программы.
Авторизация и шифрование сообщений. В работе [23] даются основные требования к обеспечению безопасности распределенных вычислений: 1) должно быть установлено взаимное доверие между тем, кто порождает процесс, и ресурсом, где он порождается; при этом порожденные процессы должны наследовать способность к аутентификации от породивших процессов; 2) необходимо обеспечить шифрование данных на линиях передачи, где возможен перехват сообщений. Эти требования для распределенных приложений MPI были обеспечены реализацией MPICH-G [14] на основе библиотеки Nexus [13].
В отличие от MPICH-G, где предусматривался запуск процессов MPI на произвольных ресурсах, обнаруженных с помощью инструментария Globus Toolkit, пользователь NumGRID самостоятельно выбирает кластеры, которые он хочет объединить. Для объединения кластеров пользователь должен обладать учетными записями на каждом из них. Такая постановка облегчает проблему авторизации при порождении процессов. Авторизация может потребоваться для выполнения команд инструментария, обеспечивающих запуск процессов, например, при использовании очередей задач на выбранном вычислительном кластере. Использование выделенных сетевых линий между вычислительными кластерами позволяет на текущем этапе развития системы NumGRID отказаться от реализации шифрования передаваемых данных. В случае необходимости использования публичных линий связи могут использоваться внешние средства для организации шифрованных туннелей [23; 24].
Устойчивость к сбоям. В проекте LA-MPI [17] надежность достигалась за счет применения проверки контрольных сумм и повторной пересылки данных. Признано, что использование протокола TCP для обеспечения надежности доставки внутри вычислительных систем нецелесообразно из-за больших накладных расходов. Проект [26] предоставляет возможности восстановления прерванных MPI-процессов даже после сбоя N - 1 из N процессов. FT-MPI предоставляет прикладной программе сведения о состоянии процесса: завершён аварийно, прерван, восстановлен, перезапущен сначала. Сведения извлекаются с помощью обработчиков ошибок. Такой подход требует использования техник восстановления после сбоев внутри самой прикладной программы. Поскольку NumGRID в настоящее время ориентирован на объединение сравнительно небольших кластеров, полагается, что стабильность вычислительных процессов обеспечивается уровнем защищенности аппаратных компонентов вычислительной системы, на которой эти процессы запущены.
Экспериментальное исследование NumGRID
Эксперименты по запуску приложений проводились на объединении кластеров Сибирского суперкомпьютерного центра (ССКЦ) и Новосибирского государственного университета (НГУ). Кластеры построены на основе двухпроцессорных узлов с процессорами Intel Xeon Е5540 (4 ядра) и внутренней коммуникационной сетью InfiniBand. Пропускная способность канала между головными узлами кластеров 10 Гб/с.
Решение волнового уравнения. Графики, демонстрирующие характеристики исполнения программы решения волнового уравнения с помощью двухслойной явной схемы представлены на рис. 2, 3. На всех диаграммах запись «P (N х S)» означает «всего P ядер, из них N на кластере НГУ и S на кластере ССКЦ».
На рис. 2 видно, что при переходе к распределенным вычислениям (с 8 х 0 на 4 х 4) увеличивается общее время работы программы за счет увеличения расходов на коммуникации. Расходы на коммуникации в данном примере увеличиваются в 5 раз, что приводит к росту времени работы программы приблизительно на 6 %.
Рис. 2. Время решения волнового уравнения явным методом на NumGRID, с
Общее время выполнения
■ Время счета
■ Время коммуникаций
(8x0) [4x4) (8x8) (16x8) (24x8) (32x8) (40x8) (88x8)
Рис. 3. Зависимость времени (с) исполнения программы от увеличения объема коммуникаций на примере решения волнового уравнения для разных размеров задачи и способов распределения вычислений
На рис. 3 показано, как изменяется время решения двумерного волнового уравнения на двух процессах в зависимости от размера задачи и способа распределения вычислений. Обозначения: трЮуегаП - время работы программы, процессы которой расположены в рамках одного кластера; трЮоттишсайоп - время, потраченное программой на коммуникации; соответствующие графики numgrid показывают время для процессов, расположенных на разных кластерах.
Распределение вычислений выполняется методом декомпозиции области. Таким образом, каждый процесс обрабатывает половину области. На рис. 3, а показана ситуация, в которой область моделирования увеличивается (горизонтальная ось) по разрезанной размерности. При этом размер границы разреза, очевидно, не изменяется и объем коммуникаций между процессами остается постоянным. На рис. 3, Ь показано, что происходит, когда изменяется размер области по другой размерности. В этом случае с изменением размера области соответственно увеличивается длина разреза и объем коммуникаций. По сравнению с ситуацией а видно, что в ситуации Ь время коммуникаций между процессами, расположенными на разных кластерах, существенно увеличивается в отношении времени коммуникаций между процессами внутри кластера.
Генерация случайных чисел и расчет статистик. Ниже представлены результаты тестирования программы, которая параллельно генерирует случайные величины и вычисляет статистики. Программа используется для моделирования физических процессов методами Монте-Карло. Программа осуществляет редкие коллективные коммуникации для сбора статистик, в остальное время процессоры выполняют существенные по объему вычисления независимо. Это позволяет ожидать, что относительно плохая пропускная способность сети
Рис. 4. Время генерации 2 000 значений случайной величины и расчета статистик на NumGRID, с. При этом время генерации 2 000 значений случайной величины и расчета статистик на одном ядре кластера 1 - 0,0109 с
Рис. 5. Ускорение генерации 2 000 значений случайной величины и расчета статистик на КишОЫБ относительно времени работы программы на двух узлах: один узел кластера НГУ (8 ядер) и один узел кластера ССКЦ (8 ядер)
между кластерами незначительно скажется на общей производительности программы (рис. 4).
Время исполнения программы при переходе от решения на одном ядре к решению на 16 ядрах, по 8 ядер на каждом кластере, уменьшается в 21 раз. Объяснить подобное сверх-линейное ускорение можно более эффективным использованием кэшей процессоров при увеличении количества процессоров и низкими коммуникационными расходами, свойственными данной задаче. При дальнейшем увеличении количества вовлеченных ресурсов также отмечается сверхлинейное ускорение. Рис. 5 дает более ясное представление об ускорении времени решения при увеличении количества процессоров.
Анализ экспериментов. В ходе экспериментов показано, что в зависимости от способа распределения вычислений между кластерами меняется эффективность работы приложений. Показано, что использование дополнительных процессоров из другого кластера позволяет уменьшать время выполнения приложения при определенных конфигурациях запуска. В частности, на задаче решения волнового уравнения достигается эффективность 90 % на 40 процессорных ядрах относительно производительности программы на 8 ядрах и 65 % на 96 ядрах. На задаче генерации случайных чисел достигается эффективность 92 % на 24 ядрах и 109 % на 88 ядрах.
Несмотря на существенную разницу в производительности систем коммуникации внутри кластеров и между кластерами, время решения задач увеличивается умеренно для решения волнового уравнения на том же количестве процессоров и уменьшается для решения задачи поиска статистик. Можно заключить, что существует класс задач, которые могут быть решены на объединении кластеров за приемлемое для пользователей время. Вместе с тем объединение кластеров может позволить решать задачи, большего объема, чем был бы способен решить один кластер за то же время.
Заключение
Растущий интерес к объединению разнородных вычислительных ресурсов для решения крупномасштабных задач и повышения эффективности использования вычислительных систем стимулирует развитие численных алгоритмов, методов планирования распределенной обработки данных, инструментов взаимодействия программных систем и средств взаимодействия пользователя с объединенными вычислительными системами.
В рамках проекта №тОМБ проведен анализ проблем объединения вычислительных кластеров, существующих подходов к решению этой задачи, сформулированы требования к программному комплексу для организации распределенных вычислений на объединении вы-
числительных кластеров, программный комплекс реализован. Проведены испытания по объединению кластеров Сибирского суперкомпьютерного центра и Новосибирского государственного университета. Эксперименты демонстрируют, что существуют классы задач численного моделирования, которые целесообразно решать на объединении вычислительных кластеров.
Дальнейшая работа заключается в расширении поддержки стандарта MPI-2.2, адаптации существующих приложений для работы в среде NumGRID, создании методов и средств разработки программ численного моделирования для неоднородных вычислительных сред.
Список литературы
1. Воеводин Вл. В., Жолудев Ю. А., Соболев С. И., Стефанов К. С. Эволюция системы метакомпьютинга X-Com // Вестн. Нижегород. гос. ун-та им. Н. И. Лобачевского. 2009. № 4. C.157-164.
2. Oboril F., Tahoori M. B., Heuveline V., Lukarski D., Weiss J.-Ph. Fault Tolerance Technique for Iterative Solvers / Karlsruhe Institute of Technology. URL: http://www.emcl.kit.edu/pre-prints/emcl-preprint-2011-10.pdf.
3. Peng Du, Luszczek P., Dongarra J. High Performance Dense Linear System Solver with Soft Error Resilience // Proc. of International Conference on Cluster Computing (CLUSTER), Austin, TX, USA, September 26-30. 2011. P. 272-280.
4. Malyshkin V. E., Perepelkin V. A. LuNA Fragmented Programming System, Main Functions and Peculiarities of Run-Time Subsystem // Proc. of the 11th Conference on Parallel Computing Technologis, LNCS 6873. Springer, 2011. Р. 53-61.
5. Abramov S., Adamovich A., Inyukhin A., Moskovsky A., Roganov V., Shevchuk E., Shevchuk Yu., Vodomerov A. OpenTS: An Outline of Dynamic Parallelization Approach // Proc. of. PaCT 2005 Conference. Krasnoyarsk, Russia, September 5-9, 2005. Springer, 2005. Vol. 3606. Р.303-312.
6. Grelck C., Penczek F. Implementation Architecture and Multithreaded Runtime System of S-Net // Implementation and Application of Functional Languages. 20th International Symposium, IFL’08. Hatfield, United Kingdom, 2010.
7. Fougere D., Gorodnichev M., Malyshkin N., Malyshkin V., Merkulov A., Roux B. NumGrid Middleware: MPI Support for Computational Grids // Parallel Computing Technologies: 8th International Conference, PaCT 2005. Krasnoyarsk, Russia, September 5-9, 2005. Springer, 2005. Vol. 3606. Р. 313-320.
8. George W. L., Hagedorn J. G., Devaney J. E. IMPI: Making MPI Interoperable //Journal of Research of the National Institute of Standards and Technology. 2000. Vol. 105. Р. 343-428.
9. Karonis N. T., Toonen B., Foster I. MPICH-G2: A Grid-Enabled Implementation of the Message Passing Interface // Journal of Parallel and Distributed Computing. Special Issue on Computational Grids. 2003. Vol. 63. Is. 5.
10. Gabriel E., Resch M., Ruehle R. Implementing MPI with Optimized Algorithms for Metacomputing // Proc. Message Passing Interface Developer's and User's Conference (MPIDC'99). Atlanta, GA, 1999. Р. 31-41.
11. Kielmann Th., Hofman R. F. H., Bal H. E., Plaat A., Bhoedjang R. A. F. MagPIe: MPI’s Collective Communication Operations for Clustered Wide Area Systems // Proc. of the 7th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming. N. Y., 1999.
12. Takano R., Matsuda M., Kudoh T., Kodama Y., Okazaki F., Ishikawa Y., Yoshizawa Y. IMPI Relay Trunking for Improving the Communication Performance on Private IP Clusters // CCGrid2008, 2008.
13. Foster I., Kesselman C., Tuecke S. The Nexus Approach to Integrating Multithreading and Communication // Journal of Parallel and Distributed Computing. 1996. Vol. 37. Р. 70-82.
14. Foster I., Geisler J., Gropp W., Karonis N., Lusk E., Thiruvathukal G., Tuecke S. A Wide-Area Implementation of the Message Passing Interface // Paral. Comp. 1998. Vol. 24. Is. 12. Р.1735-1749.
15. Srisuresh P., Egevang K. Traditional IP Network Address Translator (Traditional NAT). Network Working Group, Request for Comments: 3022. - URL: http://tools.ietf.org/html/rfc3022. Дата обращения: 15.12.2011.
16. Yoshio Tanaka, Mitsuhisa Sato, Motonori Hirano, Hidemoto Nakada, Satoshi Sekiguchi. Performance Evaluation of a Firewall-Compliant Globus-Based Wide-Area Cluster System // Proc. of the 9th IEEE International Symposium on High Performance Distributed Computing IEEE Computer Society. Washington, DC, USA, 2000.
17. Aulwes R. T., Daniel D. J., Desai N. N., Graham R. L., Risinger L. D., Taylor M. A., Woodall T. S., Sukalski M. W. Architecture of LA-MPI, A Network-Fault-Tolerant MPI // 18th International Parallel and Distributed Processing Symposium (IPDPS'04). 2004. Vol. 1. Р. 15.
18. Baran P. On Distributed Communications Networks // IEEE Transactions on Communication Systems. 1964. Vol. CS-12 (1). Р. 1-9.
19. Bernaschi M., Iannello G. Collective Communication Operations: Experimental Results vs. Theory // Concurrency: Practice and Experience. 1998. Vol. 10 (5). Р. 359-386.
20. Kale L. V., Bohm E., Mendes C. L., Wilmarth T., Zheng G. Programming Petascale Applications with Charm++ and AMPI. Petascale Computing: Algorithms and Applications. Chapman & Hall / CRC Press, USA. 2008. Р. 421-441.
21. Xiaohui Wei, Hongliang Li, Dexiong Li. MPICH-G-DM: An Enhanced MPICH-G with Supporting Dynamic Job Migration // Proc. of the 2009 Fourth ChinaGrid Annual Conference. IEEE Computer Society Washington, DC, USA 2009.
22. Barak A., La'adan O., Shiloh A. Scalable Cluster Computing with MOSIX for Linux // Proc. Linux Expo '99. Raleigh, N.C., 1999. Р. 95-100.
23. Foster I., Karonis N. T., Kesselman C., Koenig G., Tuecke S. A Secure Communications Infrastructure for High-Performance Distributed Computing // HPDC '97 Proc. of the 6th IEEE International Symposium on High Performance Distributed Computing. Washington, DC, USA, 1997.
24. Farinacci D., Li T., Hanks S., Meyer D., Traina P. Generic Routing Encapsulation (GRE). // Network Working Group, Request for Comments: 2784, March 2000. URL: http:// tools. ietf.org/html/rfc2784.
25. Townsley W., Valencia A., Rubens A., Pall G., Zorn G., Palter B. Layer Two Tunneling Protocol «L2TP» // Network Working Group, Request for Comments: 2661, August 1999. URL: http://tools.ietf.org/html/rfc2661.
26. Fagg G. E., Dongarra J. J. FT-MPI: Fault Tolerant MPI, Supporting Dynamic Applications in a Dynamic World // Recent Advances in Parallel Virtual Machine and Message Passing Interface, LNCS. Springer, 2000. Vol. 1908/2000. Р. 346-353.
Материал поступил в редколлегию 04.09.2012
M A. Gorodnichev
JOINING COMPUTING CLUSTERS FOR LARGE SCALE NUMERICAL SIMULATIONS
IN THE NUMGRID PROJECT
The paper analyzes the problems of joining computing clusters for large scale numerical simulation in the NumGRID project, discusses solutions with respect to related works. The outline of the NumGRID software system and the results of its experimental evaluation are presented.
Keywords: NumGRID, MPI, grid, distributed computing, cluster computing.
