Содержание к диссертации
Введение
Глава 1. Программная инфраструктура параллельных вычислительных систем 8
1.1. Средства сопровождения выполнения параллельных программ: предпосылки разработки 8
1.2. Пакеты управления вычислительными ресурсами 11
1.3. Пакеты мониторинга 18
1.4. Постановка задачи 22
Глава 2. Архитектура и базовые возможности комплекса РагСоп 33
2.1. Общая структура комплекса 33
2.2. Архитектура системы управления заданиями Geo 35
2.3. Архитектура системы мониторинга Antmon 51
2.4. Архитектурные особенности комплекса РагСоп 57
Глава 3. Использование комплекса РагСоп 59
3.1. Пользовательский интерфейс РагСоп 59
3.2. Исследование параллельных приложений с помощью РагСоп 60
3.3. Комплекс РагСоп на кластерных системах 65
Заключение 67
Список литературы
- Пакеты управления вычислительными ресурсами
- Постановка задачи
- Архитектура системы управления заданиями Geo
- Исследование параллельных приложений с помощью РагСоп
Введение к работе
Активное внедрение идей параллелизма в вычислительную практику привело к широкому распространению высокопроизводительных кластерных систем. Обладая многими характеристиками классических суперкомпьютеров, кластеры имеют и целый ряд дополнительных преимуществ. Они намного дешевле, их архитектуру можно выбирать в зависимости от класса решаемых задач, а сами кластерные решения хорошо масштабируются, позволяя создавать конфигурации с необходимыми параметрами по числу процессоров, стоимости, производительности, потребляемой мощности, объему оперативной и внешней памяти и целому ряду других.
Однако вместе с доступностью кластеров на первый план вышли серьезные задачи, с которыми сразу столкнулись как пользователи, так и администраторы этих систем. Потенциал систем огромен, но используется ли он в полной мере - в этом и состоит основной вопрос. При этом для пользователя важно понять, насколько эффективно выполняется именно его программа, где узкие места, в чем причины снижения производительности и как их устранить, У администраторов кластеров акцент смещается в сторону анализа эффективности работы вычислительной системы в целом, обрабатывающей поток заданий разных пользователей.
Подобные проблемы всегда сопровождали суперкомпьютерную технику, но стали особенно актуальными именно сейчас, когда использование кластеров стало массовым. Различные стороны проблемы эффективного функционирования параллельных программ и систем рассматривались многими зарубежными и российскими учеными. В нашей стране это направление имеет свою историю, активно развивается и к настоящему времени получены значительные результаты в научных коллективах, возглавляемых академиками В.С.Бурцевым, В.В.Воеводиным, Г.И.Савиным, чл.-корр. А.В.Забродиным и В.П.Иванниковым, докторами физ.-мат. наук С.М.Абрамовым, Д.А.Корягиным, В.А.Крюковым, И.Д.Софроновым. Вместе с этим, несмотря на значительную предысторию данного вопроса особенности современных кластерных систем и значительное расширение круга пользователей потребовали разработки новых подходов к решению задачи анализа эффективности выполнения программ на параллельных вычислительных системах.
Целями данной диссертационной работы являются:
• разработка методики анализа эффективности функционирования высокопроизводительных вычислительных систем с кластерной архитектурой;
• разработка принципов построения и архитектуры программного комплекса для мониторинга и исследования базовых характеристик программно-аппаратной среды кластерных систем, обрабатывающих поток пользовательских программ;
• реализация распределенного программного комплекса, позволяющего определять узкие места в конфигурациях программно-аппаратных сред кластерных систем как в процессе выполнения, так и после завершения работы параллельных программ;
• проведение апробации предложенных подходов и разработанных программных средств, их внедрение в практику работы современных суперкомпьютерных центров.
Научная новизна диссертации состоит в разработке принципов построения программного комплекса для мониторинга и исследования ключевых характеристик программно-аппаратной среды высокопроизводительных кластерных систем. Основными свойствами предложенной архитектуры являются распределенность, расширяемость, живучесть, переносимость, незначительное влияние на поведение исследуемых параллельных программ.
Все исследования, выполненные в рамках данной работы, ориентированы на совместный анализ кластерных характеристик системного уровня с возможностью одновременного изучения профиля пользовательских программ.
Данная диссертационная работа отталкивалась от реальной потребности в разработке эффективных методов организации вычислений на современных параллельных вычислительных системах, что определяет её практическую значимость. Работоспособность всех основных положений и подходов, предложенных в ходе исследований, проверялась в практике работы суперкомпьютерных центров. Использование созданного программного комплекса РагСоп позволяет значительно повысить эффективность работы высокопроизводительных вычислительных кластерных систем. Для пользователей кластеров появляется возможность проанализировать работу параллельных программ с точки зрения использования ресурсов кластеров, обнаружить их узкие места. Администраторы кластеров могут оценить и оптимизировать работу вычислительных систем на потоке задач в целом, отталкиваясь от собранных интегральных характеристик.
Принципы и характеристики, заложенные в архитектуру комплекса РагСоп, позволяют его использовать и для решения более широкого класса задач, таких, как мониторинг распределённых сетей и сервисов, анализ производительности сетевых сервисов и вычислительных комплексов, управление распределёнными сетевыми ресурсами и ряда других.
Данная диссертационная работа состоит из трёх основных глав и кратно её содержание может быть описано следующим образом.
Первая глава посвящена обзору и анализу существующей программной инфраструктуры параллельных вычислительных систем. На основе этого анализа выбирается направление исследований и уточняется постановка задачи.
Для эффективной работы параллельных программ на кластере, необходимо программное окружение, позволяющее управлять использованием ресурсов кластера. В противном случае для каждой задачи нужно будет указывать ресурсы вручную. Это сложно даже в том случае, когда задачи запускаются одним пользователем. Если же кластер находится в распоряжении нескольких пользователей, то без программной поддержки управления ресурсами просто не обойтись.
Однако, эффективность распределения ресурсов кластера между разными программами пользователей - это лишь одна сторона вопроса. Не меньшее значение имеет и эффективность работы отдельных параллельных программ. В чём причина низкой эффективности параллельной программы? Оптимизировать программу, не имея соответствующего инструментария, очень сложно, а сам этот процесс может занять значительное время.
Подобный круг вопросов является предметом исследования данной работы. В данной главе проведен анализ наиболее распространенных в настоящее время пакетов LoadLeveler, Condor, OpenPBS (TorquePBS), Queue, NQS/NQE, DQS, LSF, системы управления прохождением задач для МВС-1000/М, Autostatus, Sysmon, Ganglia, Nagios, PIKT, Mon. Оцениваются их сильные стороны и недостатки, вырабатываются требования к проектируемому комплексу.
Вторая глава посвящена описанию методики анализа эффективности параллельных программ и вычислительных систем, проектированию архитектуры и набора определению базовых функций комплекса РагСоп, разработанного на основе этой методики.
На основе выделенных уровней программно-аппаратных сред вычислительных кластеров разработаны механизмы отслеживания изменения состояния критических компонентов. Все ключевые динамические параметры кластера, такие как загруженность процессоров, особенности работы с памятью, сетевое взаимодействие и многие другие, фиксируются системой мониторинга и сохраняются в базе данных. По этой базе и информации о работающих и/или уже завершившихся задачах аналитический блок комплекса генерирует отчёт о работе задачи на кластере или о работе кластера в целом.
На основе проведенного анализа предметной области сформулирован ряд требований, которым должен удовлетворять создаваемый программный комплекс. В течение длительного времени комплекс РагСоп успешно работает на четырех различных кластерах НИВЦ МГУ, обслуживая в сумме более 300 процессоров. Комплекс работает под операционной системой Linux и требует для работы лишь интерпретатор языка perl версии не ниже 5.6.0 и пакет rrd [22]. Оба этих компонента являются свободно распространяемыми и доступны в подавляющем большинстве дистрибутивов Linux. Комплекс разработан на модульной основе, что позволяет легко расширять его возможности. Длительная эксплуатация комплекса подтвердила правильность сделанных проектных решений: нагрузка на вычислительные узлы кластеров, вызванная работой компонентов РагСоп, составляет менее 3% процессорного времени и значительно меньше 1% сетевого трафика.
Компоненты комплекса РагСоп работают независимо друг от друга. Система управления заданиями ведёт файл журнала, а система мониторинга сохраняет данные о параметрах вычислительных узлов в легковесной базе данных rrd.
В третьей главе диссертации описывается опыт практического использования разработанных программных средств. Многочисленные примеры, взятые из практики суперкомпьютерного комплекса НИВЦ МГУ, иллюстрируют возможности РагСоп по анализу эффективности выполнения параллельных программ и работе кластерных систем.
В заключении сформулированы основные результаты диссертационной работы.
Пакеты управления вычислительными ресурсами
В настоящее время наиболее развиты и представляют интерес несколько систем управления прохождением заданиями. Сделаем их краткий обзор.
LoadLeveler
Данная система разработана и поддерживается компанией IBM. Это стандартная система управления прохождением заданиями для мейнфреймов под управлением ОС AIX. В данной системе поддерживается детальное описание ресурсов, необходимых для задачи. По этому описанию система пытается найти наилучший из доступных компьютеров для запуска. Единицей измерения вычислительных ресурсов в LoadLeveler является компьютер. Это не обязательно должен быть физически один компьютер, это может быть очередь NQS, обслуживающая вычислительный кластер.
LoadLeveler изначально ориентирован на однопроцессорные задачи, но в настоящее время поддерживает и параллельные среды [8]. Однако, набор их весьма невелик и ограничивается IBM Parallel Environment Library (POE/MPI/LAPI) 2.4.0, Parallel Virtual Machine (PVM) 3.3 (на архитектуре RS6K architecture) и Parallel Virtual Machine (PVM) 3.3.11+ (на архитектуре SP2MPI).
Важной особенностью LoadLeveler является поддержка контрольных точек, как для последовательных, так и для параллельных приложений.
Система активно используется во всём мире. Например, под её управлением работает комплекс Regatta, установленный на факультете ВМиК МГУ им. М.В. Ломоносова в Москве.
Подробную информацию можно получить по адресу: http://publib.boulder.ibm.com/clresctr/windows/public/llbooks.html Condor
Изначальное предназначение системы Condor - использование времени простоя компьютеров для счёта задач [6]. В обычном режиме компьютер может использоваться как рабочая станция, а когда пользователь не работает за компьютером, Condor запускает на нём задачи. Эта система была разработана в 1988 году и продолжает активно развиваться.
Кроме однопроцессорных заданий поддерживаются и параллельные, однако их круг ограничен приложениями PVM и приложениями MPI, использующими библиотеку mpich, причём только определённые версии (последняя версия mpich-1.2.6 не поддерживается).
Система Condor поддерживает механизм контрольных точек, но только для последовательных задач. Создание и восстановление контрольных точек происходит прозрачно для программы. Таким образом, если вычислительные ресурсы компьютера надо вернуть до того, как программа завершилась, Condor может сделать контрольную точку в программе, завершить её и запустить из этой контрольной точки позднее на этом или другом компьютере. Condor позволяет сконфигурировать очередь таким образом, чтобы контрольные точки автоматически создавались через заданные интервалы времени. Программа также может использовать контрольные точки явно, вызывая соответствующие подпрограммы.
Данная система распространяется бесплатно. Подробную информацию о системе можно получить по адресу: http://www.cs.wisc.edu/condor/ OpenPBS (TorquePBS)
Это, наверное, одна из самых популярных систем на сегодняшний день. К сожалению, сейчас проект OpenPBS заморожен и не развивается [7], хотя есть его коммерческая версия OpenPBS Pro, которая развивается и поддерживается. Существует новый проект, основанный на OpenPBS TorquePBS, который унаследовал от предшественника все достоинства, но и большинство недостатков [21].
По умолчанию, OpenPBS не имеет поддержки параллельных программ, но используя дополнительные средства, такую поддержку можно организовать. Для запуска программы необходимо написать специальный командный файл, описывающий необходимые ресурсы и строку запуска программы. По информации из этого файла OpenPBS осуществляет планирование запуска программы.
Одним из важных недостатков OpenPBS является отсутствие контроля за запущенными программами. Неудачное завершение программы может остаться незамеченным системой, а оставшиеся от неудачного запуска процессы могут оставаться на рабочих узлах и затруднять работу других программ. Пользователь не может быть ограничен от прямого запуска параллельной программы в обход системы, что также может привести к затруднению работы программ. В случае сбоя вычислительного узла, система не исключает его из рабочего поля и продолжает распределять на него задачи. Подробную информацию о системе можно получить по адресу: http://www.openpbs.org Queue
Данная система не предоставляет сервиса собственно очереди. Интерфейс к системе представляет собой расширенную замену стандартного сервиса rsh. Задачи, запущенные через Queue, запускаются на том вычислительном узле, который наименее загружен в данный момент. Загруженность узла определяется по количеству запущенных на нём задач.
Таким образом Queue осуществляет балансировку загрузки вычислительных узлов кластера. Запуск параллельных задач возможен при условии, что запуск процессов задачи осуществляется с помощью rsh (как сделано в реализации mpich_p4).
Система Queue не предоставляет возможности отложить запуск задачи до момента освобождения необходимых ресурсов, а также просмотра состояния и управления уже запущенными задачами [9].
Подробную информацию о системе можно получить по адресу: http://www.gnu.org/software/queue/
Постановка задачи
Пользователь должен получать оперативную информацию о состоянии своих задач, поэтому система мониторинга должна собирать данные со степенью детализации и в объёме, достаточными для анализа. Например, информации о загрузке процессора в течение последних 10 минут явно недостаточно для оценки эффективности работы задачи.
Система мониторинга должна собирать информацию обо всех основных параметрах вычислительных узлов - загрузка процессоров, _, загрузка системы (LoadAverage), использование оперативной памяти, использование файла подкачки и page-файлов, интенсивность обменов с жёстким диском, интенсивность сетевых обменов, количество коллизий и сбоев сети, использование сетевых дисков. Так как для построения могут использоваться самые разные компоненты, позволяющие проводить мониторинг своей работы, то набор параметров мониторинга может быть самым разным. Это значит, что система мониторинга должна поддерживать возможность добавить мониторинг нового оборудования без особых г сложностей.
Информация, собранная системой мониторинга, должна быть доступной для пользователя в удобной для него форме. Наиболее удобной формой представления в данном случае является графическая - в виде графиков зависимости параметров от времени работы программы.
Кроме оперативной информации, для пользователя представляется важной суммарная информация о завершённой задаче. Используя эту информацию, пользователь может оценить общую эффективность исполнения своей задачи, обратить внимание на критичные параметры.
Для больших задач может оказаться очень полезной функция оповещения пользователя о некорректном поведении его программы, например, слишком большое время простоя процессора, слишком высокая интенсивность обменов с диском и т.п. Если программа заведомо начинает работать некорректно, то лучше пользователю узнать об этом сразу и принять меры, чем ждать сутки и получить неверный результат по истечении большого промежутка времени.
Требования к системе мониторинга с точки зрения администратора
Данные мониторинга крайне важны не только для пользователей, но и для системного администратора. Эти данные предоставляют администратору возможность не только оперативно решать возникающие проблемы, но и прогнозировать их появление.
В качестве примера можно привести мониторинг скорости вращения вентиляторов, охлаждающих процессоры. Если скорость вращения вентилятора падает ниже критической, то вероятность сбоя на этом узле резко возрастает. Имея возможность отследить момент, когда скорость начнёт приближаться к критической, администратор может предотвратить возникновение сбоев, заранее заменив вентилятор.
Так как администратор отвечает не только за состояние вычислительных ресурсов, но и за политику их использования пользователями, то для него крайне важно знать режим в котором каждый пользователь занимает вычислительные ресурсы.
Для этого администратору необходимо предоставить статистику использования ресурсов пользователем и сводные данные мониторинга, относящиеся именно к тем ресурсам, которые были заняты пользователем и к тем периодам времени, когда они были заняты.
Например, может сложиться такая ситуация, что эффективность использования процессора задачами некоторого пользователя весьма низкая. Для того, чтобы общая эффективность использования кластера была выше, может быть целесообразно ограничить доступные этому пользователю ресурсы либо попросить провести оптимизацию его программы.
Оперативность оповещения администратора о возникающих проблемах играет важную роль. Оповещение о критических проблемах должно быть максимально быстрым. Вместе с тем, о рядовых проблемах или о потенциально возможных проблемах оповещать немедленно не только не имеет смысла, но и вредно. Регулярно отвлекаясь на малозначащие сообщения, администратор не может сосредоточиться на основной работе.
Таким образом, система мониторинга должна иметь возможность оповещать администратора о происходящих событиях различными способами и в различных режимах, в зависимости от важности события.
Требования устойчивости работы
Так как средства мониторинга вычислительного комплекса нацелены на повышение надёжности работы, то надёжность их собственной работы становится узким местом. Отказ средств мониторинга способен привести к весьма неприятным последствиям, так как администратор вычислительного комплекса наверняка рассчитывает на получение оперативной информации, и её отсутствие будет воспринято лишь как сигнал "происшествий нет".
Так как сбой работы системы мониторинга с большой вероятностью будет сопряжён со сбоем работы вычислительного комплекса (к примеру, завис головной сервер, на котором установлена головная программа мониторинга), то повышение надёжности работы средств мониторинга является залогом стабильности работы всего вычислительного комплекса.
Архитектура системы управления заданиями Geo
Система управления заданиями Cleo включает в себя: головную программу-демон, программы-демоны на вычислительных узлах, подгружаемые компоненты, клиентские программы, позволяющие посылать запросы программе-демону и получать информацию о состоянии системы, документацию и информационные материалы.
Головная программа-демон запускается на хост-компьютере кластера. На этом же компьютере осуществляется работа пользователей. Именно программа-демон отвечает за состояние очередей, планирование запуска задач, процедуры запуска, завершения и отслеживания состояния задач. С головной программой общаются клиентские программы, посылая ей запросы на операции с задачами и очередью. Общая схема Cleo представлена на рис. 3.
Для того чтобы действия пользователей соответствовали их правам в системе, при общении клиентской программы с головной используется механизм авторизации. Права пользователя в системе Cleo определяются в конфигурационном файле и могут быть изменены в процессе работы системы без её перезапуска. Заметим, что права пользователя в системе могу быть отличны от его прав на компьютере. Например, рядовой пользователь может быть администратором Cleo, и наоборот, суперпользователь на компьютере может иметь ограниченные права в Cleo или даже вообще не иметь их.
Независимые программы-агенты системы Cleo работают на вычислительных узлах и обеспечивают сопровождение работы прикладных параллельных программ. Они проверяют, все ли процессы программы запустились, завершились ли они корректно при завершении программы и выполняют ряд других действий. Кроме того, по факту доступности программы-агента головная программа определяет доступность вычислительного узла. Если узел недоступен, то он автоматически блокируется системой, и все использующие его программы завершаются.
Динамически загружаемые компоненты позволяют изменять логику работы Cleo, не перегружая систему и не останавливая работу уже запущенных параллельных программ. В качестве такого компонента реализован планировщик задач. Система допускает использование и нескольких планировщиков, переключаясь с одного на другой при необходимости. Формат подгружаемых компонентов открыт, поэтому написать новый компонент или модифицировать готовый сравнительно просто.
В стандартную поставку системы входит базовый модуль планировщика запуска задач. Этот модуль запускает задачи по порядку приоритетов при наличии достаточного количества процессоров для запуска.
Если задача не может быть запущена из-за введённых квот, она временно блокируется, и могут быть запущены задачи, стоящие в очереди за ней. Перед каждым вызовом планировщика заблокированные задачи проверяются на соответствие квотам — если блокировка по квоте более не актуальна, она снимается.
Общение пользователей и администраторов с системой Cleo осуществляется как через программы-клиенты, так и через файлы состояния системы. Через файлы состояния можно получать данные о задачах и очередях, но нельзя влиять на состояние системы. С помощью программ-клиентов можно добавлять или удалять задачи из очереди, менять их приоритет, изменять состояние системы и получать расширенные данные о её текущем статусе.
Для удобства пользователей реализована программа mpirun, которая имеет такие же ключи, как и программа mpirun, входящая в состав большинства реализаций широко распространённой библиотеки MPI. Вместо немедленного запуска задачи, mpirun из поставки Cleo просто ставит эту задачу в очередь с использованием всех указанных в ключах параметров. Кроме стандартных ключей mpirun в Cleo реализованы опциональные, специфичные для Cleo ключи такие, как указание приоритета, лимита времени счёта, названия конкретной очереди и другие.
Все программы, входящие в поставку Cleo, документированы в стандартном формате man. Кроме того, в поставку входит документация в формате MS Word.
Исследование параллельных приложений с помощью РагСоп
Не всегда удаётся точно оценить объём оперативной памяти, необходимый для работы даже одной задачи. На рис. 12 приведён пример профиля задачи, которая пыталась использовать больше оперативной памяти, чем было доступно. Из-за этого использование процессора упало вдвое. Большая часть времени уходила на ожидание подкачки нужной страницы в память, что и иллюстрирует рис. 12. На левом графике показана загрузка процессора, а на правом графике - число подкачиваемых в память страниц.
В подобных случаях эффективность программы может падать сильнее, чем в 2 раза, и важно донести эту информацию до пользователя. Комплекс РагСоп способен не только показать причину замедления программы, как во время её работы, так и после её завершения, но и предупредить системного администратора о том, что на соответствующих узлах подкачка слишком велика.
Ещё одна причина возможного замедления работы программ - это работа с сетевым диском. На рис. 13 и рис. 14 показан пример задачи, активно использующей сетевой диск. На рис. 13 показана загрузка сети, которая составляет около 50% от максимума. На рис. 14 слева показана загрузка процессора, а справа - использование подсистемы NFS. Как видно из левого графика на рис. 14, загрузка процессора упала до 50-60% после того, как задача начала интенсивно писать данные на сетевой диск. При этом хорошо видно, что в это же время резко возросла нагрузка на сеть рис. 14, но не до максимальной величины. Это обусловлено тем, что файл-сервер оказался не в состоянии обслужить такой поток данных с максимальной скоростью. Именно поэтому задача значительное время провела в ожидании завершения сетевых операций с файл-сервером.
В подобных случаях разумно либо хранить временные данные на локальном диске (если по окончании счёта их можно уничтожить), либо сокращать объём данных, хранимых на сетевом диске (сохранять данные в упакованном виде, например).
Как уже было отмечено выше, программный комплекс РагСоп может быть использован не только для анализа эффективности программ и кластеров по запросу, но и в режиме оповещения. В случае, если важные параметры кластера вышли за допустимые рамки, администратор получит немедленное уведомление.
На рис. І 5 показан пример письма, посланного системой администратору, с информацией о повышенной загрузке процессора на узле aqua34 и о том, что количество переключений контекста на узле scil-2 вернулось в норму.
Существуют параметры кластера, выход которых за допустимые рамки не означает серьёзных нарушений в работе кластера. О таких параметрах администратор также получает уведомление, но лишь раз в сутки, в виде дайджеста. Он может просмотреть его и решить, насколько нарушения этих параметров могут влиять на эффективность работы кластера. Например, если загрузка файл-сервера слишком часто превышает допустимую, то имеет смысл подумать о его модернизации.
Под управлением комплекса РагСоп в течении нескольких лет работают 4 кластера НИВЦ МГУ обслуживающих более 300 процессоров [4]. РагСоп прошел успешную апробацию и внедрен в ряде других организаций: в Институте вычислительной математики РАН (16 узлов с 2-мя процессорами Itanium-2 1.3 Ghz и 4GB оперативной памяти каждый, объединённые сетью Myrinet) в Южно-Уральском государственном университете (18 узлов с 2-мя процессорами Intel Хеоп ЕМ64Т и 2 GB оперативой памяти каждый, объединённые сетью InfiniBand) в Самарском государственном университете На рис. 16 показан сайт кластера Южно-Уральского государственного университета с информацией о системе Оео, установленной на нём,
