РОССИЙСКАЯ АКАДЕМИЯ НАУК

ДАЛЬНЕВОСТОЧНОЕ ОТДЕЛЕНИЕ

ВЫЧИСЛИТЕЛЬНЫЙ ЦЕНТР

На правах рукописи

Тарасов Алексей Григорьевич

Система мониторинга вычислительного

кластера расширенной функциональности

05.13.11 математическое и программное обеспечение

вычислительных машин, комплексов и компьютерных сетей Диссертация на соискание ученой степени кандидата технических наук

Научный руководитель чл.-корр. РАН, д.ф.-м.н.

Смагин С. И.

Хабаровск 2011 2 Оглавление Введение 1 Архитектура системы мониторинга расширенной функциональности 1.1 Основные задачи систем мониторинга............. 1.2 Система мониторинга расширенной функциональности... 1.3 Взаимодействие с источниками данных............ 1.4 Представление данных...................... 1.5 Механизмы проверки условий и уведомлений о событиях.. 1.6 Выводы по первой главе..................... 2 Реализация системы мониторинга на языке программирования Java 2.1 Соглашения о наименовании классов, методов и членов класса 2.2 Пакеты поддержки сбора данных................ 2.3 Пакеты для реализации механизма отклика системы.... 2.4 Вспомогательные пакеты.................... 2.5 Сравнение разработанной системы мониторинга с аналогами 2.6 Выводы по второй главе..................... 3 Практическое применение разработанных подходов 3.1 Схема работы типичного программного комплекса, использующего разработанные классы................. 3.2 Расширение возможностей установленной системы мониторинга Ganglia........................... 3.3 Взаимодействие с системой паравиртуализации Xen..... 3.4 Взаимодействие с нейросетевым модулем........... 3.5 Пути дальнейшего совершенствования разработанной системы мониторинга......................... 3.6 Выводы по третьей главе.................... Заключение Литература Глоссарий Приложения А Подробное описание основных классов Grate Б Пример файла настроек grated В Системы виртуализации Г Искусственные нейронные сети Список принятых сокращений БД база данных ВК вычислительный комплекс ВП вычислительный процесс ИНС искусственные нейронные сети ЛВС локальная вычислительная сеть ОС операционная система ПО программное обеспечение ППП пакет прикладных программ РВС распределенная вычислительная среда СМ система мониторинга ЦСД центр сбора данных ЭВМ электронная вычислительная машина API Application Programming Interface GUI Graphical User Interface JVM Java Virtual Machine MIMD Multiple Instructions Multiple Data MPI Message Passing Interface PVM Parallel Virtual Machine TCP Tranmission Control Protocol XML eXtensible Markup Language Актуальность темы. Во многих направлениях фундаментальных и прикладных исследований имеется необходимость в решении требовательных к вычислительным ресурсам задач. Такие потребности невозможно удовлетворить при использовании для расчётов только персональных ЭВМ (далее в тексте рабочих станций). Для решения подобных задач были предложены подходы, позволяющие получить значительно большую производительность. Они основаны на вычислительных комплексах (ВК) различной архитектуры: суперкомпьютерах на базе векторных процессоров1, вычислительных кластерах [1], высокопроизводительных системах с выделенным вычислительным блоком2, различных гибридных вариантах и др.

Вне зависимости от выбора архитектуры вычислительного комплекса, разработчикам при его внедрении необходимо решить ряд задач. Одной из них является развёртывание средств управления, в том числе системы мониторинга (СМ).

Управление кластером (здесь и далее в тексте под термином кластер подразумевается вычислительный кластер) в значительной степени отличается от управления ВК с общей памятью, поскольку контролируемые ресурсы распределены по нескольким рабочим станциям. Средства управления для кластеров обычно решают такие задачи, как:

• выполнение загрузки и остановка работы вычислительных узлов;

• выполнение непараллельных и параллельных команд на кластере с последующей передачей результата пользователю или администратору ВК;

• получение структурированной и унифицированной информации о соhttp://www.cray.com http://www.nvidia.com/object/tesla_computing_solutions.html http://versi.edu.au/downloads/SuperCGrice.pdf стоянии любого вычислительного узла, в частности, таких важных данных, как использование вычислительного времени процессора, оперативной и виртуальной памяти, системы ввода-вывода, коммуникационной среды;

• анализ состояния кластера и его компонент.

Если необходимость выполнения перечисленных задач в реальном времени отсутствует, то любое из указанных выше действий можно реализовать с помощью интерпретируемых языков программирования и стандартных механизмов операционной системы: например, Bourne Shell в Unix, PowerShell в Windows, и других. Однако задачи наблюдения и управления в реальном времени намного более сложны и поэтому требуют специализированных СМ и средств управления, предъявляя при этом более жёсткие требования к времени выполнения управляющих воздействий и накладным расходам при использовании ресурсов ВК.

Традиционно, для исследования вопросов организации сбора данных и контроля ВК, локальных вычислительных сетей (ЛВС) и программных комплексов (ПК) разрабатывалось прикладное программное обеспечение (ПО). Исследованиями в этом направлении, в том числе практической реализацией, занимались такие авторы как Р. Вольски, Я. Фостер, М. Дженерсерет (R. Wolski, I. Foster, M. Genersereth) [49,53,91] и другие. Значительные результаты были достигнуты и в смежных областях: в теории управления и управляющих систем, теории автоматов, системном анализе и системах поддержки принятия решений (А. А. Ляпунов, М. Мортон, С. В. Яблонский, О. И. Ларичев, Э. Кодд, Н. Н. Моисеев [5–8, 31, 65] и другие).

Тем не менее, задачи мониторинга по-прежнему являются сложными в практической реализации. Например, большинство кластеров имеют в своём составе управляющие узлы, к которым могут обращаться пользователи. Задания выполняются на наборе узлов, допуск к которым из публичных сетей запрещён из соображений повышения стабильности работы ВК и защиты информации от несанкционированного доступа к данным.

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

Мониторинг компонент программно-аппаратного комплекса и оказание управляющих воздействий являются критически важными для организации высокопроизводительных распределённых вычислений. После того как началось выполнение приложения, пользователь и администратор кластера нуждаются в информации о том, как выполняется задание, какое влияние оно оказывает на вычислительную систему в целом. При этом с ростом числа вычислительных узлов в составе ВК возрастает и объём данных, которые приходится анализировать администратору, растёт вероятность ошибки вследствие человеческого фактора. Возникает необходимость в автоматизации рутинных операций по контролю за состоянием ВК.

Для коммерческих суперкомпьютеров и кластеров разработано специализированное ПО, обычно поставляемое производителем ВК, наприIBM Tivoli4. Такое программное обеспечение нередко совмещает мер функции мониторинга с функциями управления и тесно взаимодействует с аппаратным обеспечением ВК, предоставляя информацию со всех уровней мониторинга.

Для вычислительных кластеров, стоимость которых невелика по сравнению с коммерческими ВК, ввиду использования менее специализированного и потому более доступного по цене оборудования, подобное указанному выше ПО для них либо отсутствует, либо его применение затруднено в силу лицензионных ограничений. Поэтому обычно используются различные сторонние программные продукты, в задачи которых входит сбор необходимых данных, обработка и представление полученных результатов в удобном для конечного пользователя виде. Такое ПО доступно, в том числе, и на принципах свободного программного обеспечения, которое http://www.ibm.com/software/ru/tivoli/ успешно применяется в научной среде, в частности, в ВЦ ДВО РАН [25].

Подходы, используемые в системах мониторинга в настоящее время, во многом являются следствием развития концепций построения вычислительных систем. Для понимания особенностей архитектур СМ необходимо рассмотреть основные этапы эволюции подходов к организации ВК.

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

В 90-е годы прошлого столетия с суперкомпьютерами стали конкурировать ВК, состоящие из набора вычислительных станций. Этому способствовали быстрые темпы развития технологий передачи данных в ЛВС.

В итоге вычислительные кластеры стали параллельными вычислительными системами, сравнимыми по производительности с суперкомпьютерными системами с общей памятью [41].

Один из ранних подходов к организации кластеров состоял в использовании вычислительного времени простаивающих рабочих станций.

Он и в настоящее время применяется для решения ряда задач, таких как, например, анализ принимаемых из космоса радиосигналов в проекте SETI@Home [36] и численные расчёты процессов свёртывания молекул белка в проекте Folding@Home [59]. Для поддержки таких вычислительных систем был разработан ряд пакетов прикладных программ (ППП) [54, 61].

Это ПО в основном было предназначено для централизованного управления ресурсами и распределения процессов непараллельных заданий по свободным рабочим станциям (далее в тексте вычислительным узлам), http://www.clusterresources.com/products/torque-resource-manager.php объединённым в ВК. Задача наиболее эффективного использования разнородной вычислительной среды, состоящей зачастую из рабочих станций с различным аппаратным и программным обеспечением, требовала надёжных механизмов работы в унифицированной виртуальной параллельной машине. В этих целях использовалось такое ПО, как PVM [77], MPI [67] (см. также: LAM6, OpenMPI7, MPICH8 ) и др.

Эти программные продукты позволили стандартизировать на уровне межгосударственных организаций модель обмена данными между вычислительными узлами в ЛВС. В свою очередь, принятие стандартов привело к тому, что, согласно обновляемому каждое полугодие списку высокопроизводительных систем мира TOP5009, наиболее распространёнными на сегодняшний день являются вычислительные кластеры, доля которых превышает 80% от общего числа ВК. В аналогичном списке для стран СНГ доля кластеров равна 98% от общего числа ВК10.

Некоторые ВК низшего ценового диапазона до сих пор построены с применением ЛВС организации, обычно на базе технологий Fast или Gigabit Ethernet в качестве аппаратного обеспечения коммуникационной среды, используемой совместно с невычислительными станциями. Было показано, что пропускной способности и латентности такой ЛВС достаточно для определённого класса задач [48,58,85]. Однако, чрезмерно загруженная сеть или сеть с неэффективной топологией (с точки зрения пропускной способности) заметно снижает производительность ВК в задачах, требующих обменов данными большого объёма. Поэтому предпочтительным является использование выделенных кластеров с изолированной средой передачи данных [87].

Проект Now института Беркли [45] является одним из общеизвестных примеров таких ВК. В работах [76,86] показано преимущество выделенных вычислительных кластеров по сравнению с системами, в которых применяется неизолированная ЛВС. Кластеры, используемые научными учреждениями для решения широкого круга задач, в основном используют выhttp://www.lam-mpi.org http://www.open-mpi.org http://www-unix.mcs.anl.gov/mpi/mpich http://top500.org http://supercomputers.ru деленную ЛВС. Независимо от типа ЛВС кластер нуждается в средствах наблюдения за состоянием всех компонент, поскольку производительность всего ВК зависит от корректности функционирования каждого из вычислительных узлов.

Пользователю довольно сложно определить воздействие его задания на вычислительную систему, поскольку возникает необходимость, не имея соответствующего инструментария, выделить влияние приложения из суммарного воздействия всех других выполняемых на кластере заданий. Обычно на практике измеряют все характеристики на узле до и после запуска задания. Этот подход не всегда удобен, если вообще возможен: в ряде случаев пользователь не обладает информацией о том, где конкретно будет выполняться его задание. К тому же, по результатам многочасового выполнения задания в таком случае не всегда ясно, происходит ли, например, ошибочное выделение памяти без возврата его системе в наблюдаемом приложении (т.н. утечка памяти ), или другом, выполняющемся на том же самом вычислительном узле.

Ситуация значительно усложняется, если задание ставится в очередь на выполнение в РВС (например, организованных при помощи инструментальных комплексов Condor-G [52] или Globus [51]), поскольку пользователь вынужден сначала определить кластер, на выполнение в котором было отправлено его задание, а затем получить доступ к данным мониторинга для конкретных узлов. В системах подобных Globus GRAM [51], пользователь работает с кластером посредством интерфейса постановки задания в РВС. Это создаёт неразрешимую на уровне пользователя задачу, т.к.

возможности по мониторингу в таком случае ограничены особенностями службы Globus MDS [49], которая ориентирована, в основном, на предоставление редко обновляемой информации, такой, как число вычислительных ядер, общий объём оперативной памяти вычислительного узла и т.п.

Контроль состояния вычислительной системы и текущего потребления ресурсов необходим для выявления проблем в ВК и проведения работ по организации вычислительного процесса (ВП) с более эффективным использованием имеющихся ресурсов. Механизмы автоматизированного определения неполадок и восстановления системы могут использовать данные, предоставляемые СМ, для определения, в каком состоянии находится вычислительный узел или кластер в целом [12]. Службы предсказания производительности сети могут использовать данные CM как входные векторы для модели предсказаний [90]. В свою очередь, сами службы предсказания могут использоваться планировщиками заданий с целью выявления, какие ресурсы ВК и когда возможно использовать для планируемого задания при составлении расписания выполнения заданий.

Также полученные данные могут быть использованы для:

• определения стадии выполнения задания, в т. ч. выявления отказов и сбоев, текущего состояния задания, причин перехода в это состояние;

• анализа производительности и автоматической настройки требований заданий к ресурсам в процессе выполнения (в последние годы это становится более востребованным в связи с развитием т.н. облачных вычислений [56]);

• эффективного управления различными службами ЛВС;

• планирования заданий и предсказания поведения вычислительной системы;

• сбора данных о конфигурациях вычислительных узлов и использовании ВК.

Приведённые выше задачи, возникающие при организации работы ВК, являются одними из самых важных, но ими не исчерпывается множество задач, решение которых облегчается при использовании подходящей СМ.

Изначально СМ создавались для контроля состояния сетевых служб, ввиду их большой значимости в ЛВС и глобальной сети Интернет, например проект Network Weather Service [90]; этой же тематике посвящены работы в Bell Labs [47, 57].

В работе [68] описывается применение мониторинга для отслеживания попыток проникновения в контролируемую сеть; вводится понятие двух классов систем определения вторжения: сетевые (network-based) и узловые (host-based). Первые работают на основе контроля потока данных (или трафика) в сети; вторые принимают решение об обнаружении попытки проникновения в ЛВС на основе контроля данных с рабочих станций.

В [75] специализированные СМ также делятся на централизованные и распределённые. Первые осуществляют сбор данных в каком-либо одном месте. Вторые не используют единый центр сбора данных: все узлы ВК либо владеют полной информацией о системе, либо существует несколько узлов, ответственных за сбор информации. Там же вводится понятие прямого (direct) и косвенного (indirect) мониторинга. К первому относится непосредственный доступ к данным контролируемого объекта, например, данным ядра операционной системы. Ко второму доступ к той же информации через посредника, которым может являться некоторый файл, содержащий текстовое или двоичное представление значений набора данных.

Для определения состояния ВК применяются различные механизмы. Например, в работах [12, 13] предлагается распознавать типы состояний вычислительного кластера с помощью искусственных нейронных сетей (ИНС), используя данные системы мониторинга Ganglia. В [38, 93] обсуждается подход с использованием сетей Петри для диагностики состояния контролируемой системы, на основе уведомлений о событиях в СМ с дискретными событиями. Событием является такое состояние в контролируемой системе, которое требует дополнительной обработки.

Обработка событий и уведомление пользователей системы о них могут осуществляться различными способами. Системами с уведомлением о событиях на базе подписки являются ISIS [39], Gryphon [33]. СМ XMLBlaster [73] использует XML11 для описания события и нахождения пути к адресату на базе информации о событии. Альтернативой такому подходу является уведомление всех пользователей системы обо всех событиях, либо уведомление лишь администратора вычислительного комплекса. Последний подход используется при мониторинге системной информации в операционных системах, основанных на Unix, при возникновении любых сообщений ядра ОС.

http://www.w3.org/XML/ В JINI12 определены события (Distributed Event Specication) и указано как объект в виртуальной машине Java (JVM) регистрируется для получения события, генерируемого объектом какой-либо другой JVM. Там же описывается, как производится уведомление при возникновении события. Система мониторинга JAMM [82] определяет способ поиска событий и генерирующих их объектов или служб с помощью локальной службы каталогов [89].

Задачи, решаемые в JAMM, во многом схожи с основанными на SNMP системами HP OpenView и SGI Performance Co-Pilot13. Протокол SNMP является одним из средств контроля состояния сетевых устройств;

его подробное описание приведено в RFC 115614 и RFC 115715. Данный протокол может использоваться как средство доступа к аппаратным счётчикам сетевых устройств. SNMP разрабатывался для управления и мониторинга подключенных к сети устройств и узлов, а не распределённых комплексных систем. Интеграция либо построение приложений мониторинга, основанных исключительно на поддержке SNMP, является трудоёмкой задачей. Вместе с тем, несмотря на некоторые ограничения, SNMP счётчики хорошо вписываются в архитектуры СМ как источники данных (или сенсоры).

Сложной в практической реализации задачей является опрос всех источников данных и выработка удобного и не ресурсоёмкого способа опроса всех известных сенсоров. В [40] приводится описание механизма SQL запросов для получения и агрегирования необходимых данных из сети сенсоров.

Чем более масштабными и сложными становятся распределённые вычислительные среды, например, такие глобальные РВС, как GRIDсистемы [50], тем более важными и актуальными становятся задачи мониторинга и автоматизации управления. Одним из подходов к решению данной проблемы является использование агентов мониторинга [53] в событийно-управляемом программном комплексе управления РВС.

Обычно под агентом понимается автономный настраиваемый комhttp://www.sun.com/jini/specs/ http://www.sgi.com/software/co-pilot/ http://www.ietf.org/rfc/rfc1156.txt http://www.ietf.org/rfc/rfc1157.txt понент программно-аппаратного комплекса, способный производить контроль и управлять какими-либо другими компонентами в составе РВС.

СМ представляют собой набор таких агентов, которые в ряде случаев могут перенастраиваться в процессе выполнения. В задачи агентов входит получение соотнесённой со временем информации о состоянии любой системной компоненты, такой как использование процессора и др. В ряде СМ агенты могут предоставлять дополнительные управляющие возможности, в частности, выполнять безопасным образом ПО и анализировать результат выполнения.

При таком подходе СМ обычно реализована в виде двух компонент.

В состав первой входят агенты мониторинга, которые установлены на каждом вычислительном узле. Ко второй относятся сервер и клиент сбора статистики. Например, в системе мониторинга проекта SMILE [88] на каждом вычислительном узле запущен фоновый процесс CMA (Control and Monitoring Agent), который периодически собирает статистику использования ресурсов. Затем полученные данные передаются на центральный сервер управления ресурсами SMA (Systems Management Agent). Причина централизации данных в SMA простота и эффективность обработки информации на одном сервере. Такой вариант подходит для небольших и средних кластеров, но для ВК со значительным числом узлов необходимы разделение данных по принадлежности к зонам (доменам) и применение иерархической обработки информации.

У описанной выше архитектуры, несмотря на очевидные достоинства, есть и следующие недостатки:

1. SMA является точкой отказа, которая нарушает корректность работы всей системы управления. Эта проблема может быть решена с использованием дублирующего SMA.

2. Централизация без иерархии затрудняет масштабирование СМ на больших кластерах и глобальных РВС. Однако, как показано в [88], для кластеров с числом узлов до 64, эта проблема несущественна.

Чтобы сделать агенты переносимыми, разработчики систем мониторинга явно или неявно внедряют уровень (или слой) абстрагирования от аппаратного обеспечения, т. н. HAL (Hardware Abstraction Layer). Этот слой предоставляет данные в унифицированном формате, обычно машиннонезависимом.

Для исключения большого числа TCP-соединений и нагрузки на сеть, системы мониторинга часто работают поверх UDP протокола [63, 88]. Тем не менее, часть, либо все операции обменов данными, также могут быть реализованы и поверх TCP [43, 72].

Многие СМ и технологии в их основе создавались для решения конкретных задач, стоявших перед их разработчиками. Они успешно и эффективно решают эти задачи в своих областях. Тем не менее, для ВК, на которых установлено устаревшее ПО мониторинга, зачастую переход на новые системы мониторинга затруднен, а ранее использованная СМ уже не удовлетворяет возросшим требованиям. К тому же некоторые возможности недоступны даже ряду современных СМ. Несмотря на всё многообразие архитектур и ПО СМ, до сих пор отсутствует возможность взаимодействия различных СМ между собой, затруднено добавление возможностей к уже разработанным СМ, сложен переход от контроля на низком к более высокому уровню и наоборот.

Анализ достоинств и недостатков различных систем во время эксплуатации ВК, относящемуся к классу Beowulf-кластеров, выявил необходимость разработки универсальной системы мониторинга, удовлетворяющей требованиям к базовым возможностям, простоте добавления новых модулей и взаимодействию с другими СМ.

Цель работы состоит в разработке архитектуры и реализации СМ расширенной функциональности, которая представляет механизмы взаимодействия сторонних СМ и программных комплексов в рамках единой СМ. Для достижения этой цели были поставлены следующие задачи:

1. Разработать архитектуру СМ, позволяющей производить интеграцию построенных на её основе приложений с различным ПО, в том числе сторонними СМ с учётом современных требований к ним.

2. Реализовать кросс-платформенную СМ, построенной на базе разработанной архитектуры.

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

Объектом исследования являются теория и практика организации систем мониторинга вычислительных кластеров.

Предметом исследования являются методы и инструментальные средства контроля разнородных данных в вычислительном кластере.

Методы исследования. При решении поставленных задач использовались методы системного и прикладного программирования; методы объектно-ориентированного и модульного программирования; технологии построения вычислительных кластеров.

Научная новизна. В диссертации представлен подход к архитектуре СМ, позволяющий осуществлять автоматизированный контроль ресурсов ВК и более простое взаимодействовие СМ со сторонним программным обеспечением через механизм отклика на изменения в работе вычислительной системы. Новой возможностью при таком подходе является взаимодействие ПО, разработанного на различных языках программирвоания.

Разработанная архитектура позволяет наращивать возможности мониторинга, в том числе, добавляя сторонние модули к СМ, не останавливая их работы, а также осуществлять совместный мониторинг и анализ данных, поступающих от различных СМ. Подход к расширению функциональных возможностей уже используемых СМ без их остановки и в рамках единой СМ ранее не был описан.

Для взаимодействия с независимыми модулями СМ, в том числе, реализующим нейросетевые алгоритмы с целью определения текущего состояния вычислительного кластера, предложено использовать авторскую механизм передачи информации о событиях в работе контролируемой системы, при котором подписка на уведомления может выполняться в процессе работы СМ.

Практическая значимость. Разработанное ПО позволяет повысить эффективность и надёжность использования вычислительных кластеров.

Создание и внедрение программных средств, предложенных в диссертации, выполнялись в рамках проекта по внедрению экспериментального кластера ВЦ ДВО РАН [10] и работ по созданию РВС ВЦ ДВО РАН [15].

Разработанная СМ Grate помогает выполнять мониторинг вычислительных задач, производящих расчёты по плановым научно-исследовательским работам.

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

Доступные исходные коды разработанной системы и документированный интерфейс модулей позволяют адаптировать разработанную СМ под нужды конкретного ВК с меньшими усилиями и накладными расходами, чем при использовании аналогичных по возможностям СМ, благодаря использованию стандартизованных форматов передачи сообщений, необходимых для подписки на уведомления и получение данных.

Соответствие диссертации паспорту специальности. Отражённые в диссертации научные положения соответствуют области исследования специальности 05.13.11 - Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей, включающей исследования моделей, методов, алгоритмов, языков и программных инструментов для организации взаимодействия программ и программных систем (пп. 1, 3 области исследования).

Достоверность полученных в работе результатов и эффективность разработанной архитектуры СМ подтверждается опытом успешной практической эксплуатации разработанного автором диссертации ПО Grate в Вычислительном центре ДВО РАН при мониторинге ряда ресурсоёмких прикладных задач.

Апробация. Результаты работы были представлены на XXX, XXXII и XXXIII математических школах-семинарах им. Е.В. Золотова (Хабаровск, 2005 г., Владивосток, 2007, 2008 гг.), Всероссийской научной конференции Научный сервис в сети Интернет: многоядерный компьютерный мир (Новороссийск, 2007), Межрегиональной научно-практической конференции Информационные и коммуникационные технологии в образовании и научной деятельности (Хабаровск, 2008 г.), международной научной конференции Параллельные вычислительные технологии (СПб, 2008 г.), XI Всероссийской конференции молодых учёных по математическому моделированию и информационным технологиям (г. Иркутск, 2010), международной научной конференции Russia and Pacic Conference on Computer Technology and Applications (г. Владивосток, 2010 г.).

Публикации. Результаты научных исследований отражены в 12-и научных работах [9,13,15,20,22,24,27,28], включая 1 статью [9] в журнале, рекомендованном ВАК для опубликования научных результатов диссертации на соискание ученой степени доктора или кандидата наук, 2 препринта [10, 11], 1 свидетельство [26] об официальной регистрации программы в Федеральной службе по интеллектуальной собственности, патентам и товарным знакам. В перечисленных публикациях все результаты, связанные с алгоритмизацией, программной реализацией и проведением вычислительных экспериментов на высокопроизводительных системах, получены автором лично. Результаты вычислительных экспериментов интеграции системы мониторинга и компоненты искусственных нейронных сетей, полученные совместно с Писаревым А. В., являются неделимыми. Из совместных работ и публикаций с Сапроновым А. Ю., Шаповаловым Т. С., Пересветовым В. В., Смагиным С. И., Щербой С. И. в диссертацию включены только те результаты, которые принадлежат непосредственно автору.

Структура и объём работы. Диссертация состоит из введения, трёх глав, заключения, библиографического списка из 94 наименований, глоссария и 4 приложений. Общий объем работы 131 страница, в том числе 28 рисунков и 3 таблицы.

Личный вклад автора. Автором осуществлена выработка требований к системе мониторинга, разработка трёхуровневой архитектуры и реализация системы мониторинга расширенной функциональности, получение основных результатов проведённых исследований.

Краткое содержание работы. Во введении обосновывается актуальность работы, ставятся цели и задачи исследования, приводятся основные положения работы. Анализируется специфика предметной области, существующие подходы и их реализация.

В первой главе сформулированы требования к архитектуре программного комплекса для мониторинга кластера ВЦ ДВО РАН. Приводится более строгая формулировка задач мониторинга, вводятся основные термины. На основе изложенного материала формулируется постановка задачи диссертационной работы, предлагается новая архитектура СМ. Приводится описание элементов разработанной архитектуры трёхуровневой СМ и принципов их взаимодействия.

В предлагаемой архитектуре информация о значениях контролируемых величин (метрики) предоставляется сенсорами в центры сбора данных (ЦСД) одним из доступных способов, например, широковещательным пакетом данных или ориентированным на соединение протоколом TCP.

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

Ретрансляторы событий совмещены с ЦСД и предоставляют клиентским приложениям возможность подписываться на уведомления об изменениях в работе ВК, снимая тем самым необходимость осуществления маршрутизации пакетов данных с вычислительных узлов до конкретного пользователя. Любое приложение имеет возможность как зарегистрироваться для получения уведомления о конкретном событии, так и генерировать новые события. Уведомления обрабатываются в определённом порядке, который зависит от установленных пользователем фильтров.

ЦСД могут обмениваться полученной информацией между собой.

Пользователь получает сведения от такого центра посредством явного запроса с указанием интересующих его параметров.

Вторая глава демонстрирует особенности авторской программной реализации СМ, структуру модулей и интерфейсов, которые необходимы для интеграции СМ в более сложные программные комплексы.

Описывается ряд интерфейсов и классов языка программирования Java, объединённых в пакеты для более удобного взаимодействиях со сторонним программным обеспечением. Программный комплекс СМ в предлагаемой реализации представляет собой клиент-серверное приложение, состоящее из нескольких модулей. Модули выполняются либо на вычислительных узлах (источники данных), либо на выделенных узлах (ретрансляторы сообщений, ЦСД).

Поскольку вычислительный кластер не является географически распределённым ВК со свободным доступом из внешних сетей к вычислительным узлам, то при создании СМ предполагалось, что его безопасность будет обеспечиваться другими компонентами системного ПО. В большинстве практических реализаций вычислительных систем необходимые средства защиты информации аутентификация клиентов, авторизация для доступа к ресурсам и т. д. доступны посредством служб операционных систем или систем диспетчеризации задач.

Третья глава содержит описание применения разработанных подходов, архитектуры СМ и ПО на её базе для решения ряда задач: расширения возможностей установленной ранее СМ для контроля соблюдения температурного режима центральных процессоров ВК; взаимодействия с системой виртуализации Xen и нейросетевым модулем. Там же приводятся примеры других задач, решение которых может быть упрощено при использовании предлагаемых подходов.

В заключении диссертации сформулированы основные результаты работы, намечаются направления дальнейших исследований.

В приложениях А и Б представлены более детализированная информация по программным интерфейсам разработанной СМ Grate, описание формата файла настройки. В приложениях В и Г приведены краткие сведения из практики применения систем виртуализации и теории искусственных нейронных сетей соответственно. Данная информация полезна для понимания принципов функционирования компонент СМ, взаимодействие с которыми описывается в третьей главе.

Положения, выносимые на защиту.

1. Архитектура и программная реализация СМ расширенной функциональности обеспечивает мониторинг данных на различных программно-аппаратных платформах под управлением нескольких операционных систем.

2. Использование механизма уведомлений о событиях позволяет осуществлять эффективное взаимодействие СМ со сторонним программным обеспечением для расширения его функциональности.

Автор благодарит Пересветова В.В. и Смагина С.И. за руководство и помощь в процессе выполнения диссертационной работы.

Глава 1. Архитектура системы мониторинга 1.1. Основные задачи

систем мониторинга Задачи, решаемые системами мониторинга ВК, можно сформулировать следующим образом.

Пусть N число контролируемых узлов, на i-ом узле измеряются li характеристик (в последнюю декаду, в литературе эти характеристики принято называть метриками), все li составляют множество L = {li }, i = Обозначим через Mi (t) = {mik (t)} множество значений характеристик на i-ом узле в момент времени t, k = 1, 2,..., li. Положим M (t) = {Mi (t)} множество значений всех контролируемых характеристик в момент времени t.

Назовем кортеж Sp =< M (t), N, L > состоянием контролируемой вычислительной системы, где p порядковый номер состояния.

Значимым событием назовем переход из устойчивого состояния Sp в состояние Sp, при котором происходит существенное для контролируемых характеристик изменение значений множества M (t), указывающее на важные для пользователя СМ изменения в работе ВК.

Задачами системы мониторинга являются:

1. получение от контролируемой вычислительной системы и сохранение 2. выявление значимых событий;

3. запуск средств реагирования (отклика) на значимое событие.

Все эти задачи сложны и могут быть решены различными способами. Данные о поведении вычислительной системы можно собирать и предоставлять различными способами, что позволяет разделить все СМ на две группы: система-ориентированные и задание-ориентированные системы мониторинга.

Система-ориентированная СМ может предоставить всеобъемлющую статистику о том, как ведёт себя вычислительная система, например, СМ Ganglia контролирует более чем 40 параметров на каждом вычислительном узле [63,72]. Другим примером СМ такого типа является MonALISA [34,60].

Тем не менее, задачи тонкой настройки приложений и выявления недостатков используемых в них алгоритмов невозможно эффективно решать, основываясь на данных лишь система-ориентированного мониторинга.

Задание-ориентированные СМ не могут заменить системаориентированные, но позволяют более эффективно использовать данные мониторинга для анализа поведения конкретных заданий. Именно это и определило название данного вида СМ. Наиболее востребованы такие системы в РВС, где могут применяться для более точной планировки заданий, а также для приложений, способных изменять требования к вычислительным ресурсам в процессе выполнения, в т. н. облачных вычислениях [56, 62]. Свойствами задание-ориентированных СМ обладают многие планировщики заданий.

Вследствие большего объёма данных мониторинг поведения отдельного задания в РВС или среде вычислительного кластера является зачастую более ресурсоёмкой задачей, чем сбор данных в системаориентированных СМ.

Пользователь СМ заинтересован в получении информации в течение всего жизненного цикла задания, при этом мониторинг ресурсов может производиться на различных уровнях: всей вычислительной системы, кластера, узла и уровне задания. Первый указанный уровень свойственен глобальным распределённым вычислительным средам (РВС), второй большинству кластеров, третий система-ориентированным, последний задание-ориентированным СМ.

Основными характеристиками, представляющими интерес при мониторинге вычислительного кластера, являются разделяемые между различными задачами ресурсы: количество доступных процессоров, объем используемой оперативной и дисковой памяти, нагрузка на сетевую подсистему, количество пользователей и т. п. Простой и оперативный доступ к этой информации позволяет оценивать текущее состояние ВК, реагировать на изменения в вычислительном процессе, находить причины неисправностей и сбоев, а также использовать полученную информацию в высокоуровневых программных компонентах (диспетчеризация задач, системы виртуализации и др.) Для пользователя СМ является средством отладки программы и наблюдения за процессом решения своей задачи. Он заинтересован в возможности наблюдать расходуемые его программой ресурсы в реальном времени, выявлять в ней узкие места. При запуске параллельных программ пользователю обычно необходимо знать общий уровень загрузки кластера и доступные в этот момент ресурсы ВК. При нарушении работы приложения для анализа причин сбоя ему могут понадобиться данные за некоторый период времени, предшествующий аварийному завершению.

Как администратору, так и пользователю важно получать уведомления об изменениях в работе контролируемой системы, особенно критически важных для функционирования кластера или выполнения приложения.

Необходима поддержка уведомлений различными способами: электронная почта, уведомление через клиент мгновенных сообщений и др.

При разработке СМ важно учитывать специфику параллельных приложений, выполняемых на вычислительных кластерах. Такие приложения оказывают наиболее сильную нагрузку на вычислительные ядра, оперативную память и, как правило, на среду передачи данных. Программный комплекс мониторинга должен также иметь возможность для удаленного наблюдения.

В диссертации к архитектуре СМ и программной реализации предъявлялись следующие требования. В дополнение к основным задачам СМ должна:

• иметь возможность уведомлять приложения пользователя о значимых событиях, возникающих при работе ВК;

• быть легко настраиваемой для использования различных источников • корректно обрабатывать исключительные ситуации: задержки и ошибки при получении данных, отсутствие либо повреждение необходимой информации и т. п.;

• предоставлять набор библиотек, позволяющих интегрировать СМ в сторонние программные комплексы;

• иметь возможность получать и обрабатывать данные сторонних СМ единообразно и прозрачно для пользователя;

• предоставлять изменяемый графический интерфейс пользователя;

• быть надёжной, стабильной и нетребовательной к ресурсам.

Для удовлетворения этих требований была предложена новая архитектура СМ, объединившая в себе подходы, позволяющие решать такие задачи мониторинга, решение которых затруднено при использовании других СМ.

1.2. Система мониторинга расширенной функциональности Системы мониторинга состоят из различных структурных элементов, взаимодействующих между собой определённым образом, зависящим от архитектуры СМ и способа её реализации. В диссертации предлагается новая архитектура СМ (более подробно она описывается в следующих разделах этой главы). Весь программно-аппаратный комплекс логически разделён на три слабо-связанных уровня [20], отображённые на рисунке 1.1. Передача данных может осуществляться лишь между соседними уровнями. Это позволяет изменять и дополнять уровни, не нарушая общей работоспособности СМ. Существуют СМ, не выделяющие уровни явно или использующие меньшее число уровней. Но для удовлетворения требований, указанных в предыдущем разделе, минимально возможным числом для распределения структурных элементов, как будет ясно из приведённой ниже структуры СМ, являются три уровня.

Нижний уровень ответственен за сбор и представление данных в виде метрик. Источником данных может быть какой-либо сенсор физического или логического устройства, например SNMP-статистика или данные служб сторонних СМ. Функциональность этого уровня мала; в целях более эффективного использования ресурсов контролируемого узла предполагается использование машинно-зависимого ПО.

Промежуточный уровень отвечает за сбор данных с нескольких источников данных, преобразование их к унифицированному формату данных, проверку простейших триггеров и выполнение соответствующих им действий. Этими задачами занимаются центры сбора данных (ЦСД). На этом же уровне функционируют ретрансляторы событий. Данный уровень можно реализовать на машинно-зависимых или интерпретируемых языках.

Уровень приложений отвечает за анализ данных и представление их пользователю. Быстродействие на данном уровне не так важно, т. к. выполняющееся на нём программное обеспечение может работать за пределами ВК, обращаясь лишь к данным, предоставляемым промежуточным уровнем.

Помимо функциональных возможностей, связанных с мониторингом, на всех уровнях СМ должна предоставлять возможность интеграции с другими программными комплексами через строго определённые интерфейсы взаимодействия.

На рисунке 1.2 представлена общая схема получения и обработки данных мониторинга в СМ, построенной с использованием предлагаемой архитектуры.

Рис. 1.2: Схема работы системы мониторинга, построенной по предлагаемой архитектуре В предлагаемой архитектуре вычислительный узел отличается от узла иерархической структуры данных (ИСД), которая формируется в процессе мониторинга ВК. Если не указано иное, то в тексте под узлом понимается второе значение. Трехуровневая архитектура позволяет динамически формировать ИСД, узлом которой может выступать любой определяемый источником данных программный или аппаратный компонент. При этом базовыми единицами хранения данных являются значения метрик.

Метрика это набор значений определённого типа (целые числа, строки, числа с плавающей запятой и т. п.), отражающий текущее состояние или изменение характеристики в узле ИСД. Метрики бывают статические, т. е. неизменяемые во время работы ОС (например, архитектура аппаратного обеспечения на вычислительном узле, объём физической памяти), и динамические (время работы узла, число операций ввода-вывода в единицу времени и др.). Также они делятся на метрики с накоплением, которые обеспечивают доступ ко всем данным измерений, и одномоментные: хранят только текущее значение. СМ отслеживает непротиворечивость данных по времени, соблюдение порядка помещения данных в метрику. Метрика, в общем случае, хранит набор данных лишь за относительно небольшой промежуток времени (например, за последний час) и организует эффективный доступ к ним. Остальные данные выгружены во внешнее хранилище в целях уменьшения используемого объёма оперативной памяти. Доступ к ним возможен по запросу пользователя. Каждая метрика существует в рамках определённого узла. Узел имеет изменяемые во времени атрибуты и набор метрик. Отличие атрибута от метрики состоит в том, что атрибут всегда хранит только одно значение. Более строго, атрибут это статичная одномоментная метрика строкового типа. Атрибутами являются вспомогательные данные, используемые при работе с СМ.

Например, ими могут являться параметры командной строки, переданные приложению пользователя.