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

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

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

Средства визуализации являются органичной частью многих современных программных систем управления кластерами. Например, в Scalable Cluster Environment (SCE) обеспечиваются разнообразные возможности визуализации кластера, включая трехмерные изображения с использованием языка описания трехмерных сцен VRML. Однако в данной статье мы обратим внимание на более простые и доступные системы визуализации, которые можно использовать для отображения состояния вычислительных кластеров под управлением ОС Linux/Unix: Ganglia (http://ganglia.sourceforge.net) и Big Brother (http://bb4.net).

Общие задачи систем визуализации

Система визуализации должна решать несколько задач, которые могут выполняться параллельно (квазипараллельно) либо полностью (относительно) независимо:

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

Системы визуализации имеют некоторый стартовый набор параметров, значения которых регулярно регистрируются, например, процент использования отдельных процессоров, дата загрузки ОС, и т. п. Каждый такой наблюдаемый параметр именуется метрикой. Всякая метрика имеет свой временной интервал опроса — интервал получения значения параметра. Время между реальным изменением отслеживаемого параметра и отображением на экране администратора зависит от конкретной системы; на практике интервал опроса составляет от нескольких секунд до нескольких минут. Рассматриваемые в статье системы дают значения параметров, которые усреднены по временному интервалу. Большинство систем визуализации можно дополнять своими программами, поставляющими информацию, специфичную для конкретной конфигурации вычислительной установки. По сути, такие программы, часто именуемые «сенсорами», выдают конкретное значение метрики.

Технически система визуализации представляет собой множество клиентов и серверов, причем чаще всего сервер один, а число клиентов равно или кратно числу машин в кластере. Клиентская часть обычно состоит из главной программы, которая запускает (или использует) несколько программ-сенсоров и посылает собранные данные серверу. Серверная часть системы, содержащая необходимые модули расширения и CGI-программы для организации диалога с пользователем, формирует Web-страницы о состоянии кластера.

Ganglia

Основа клиентской части свободно распространяемой программы сбора информации в Ganglia — демон Ganglia MONitoring Daemon (gmond). Демон выполняет несколько задач:

  • наблюдает за изменениями параметров;
  • передает все значимые изменения состояния в канал групповой рассылки (multicast channel);
  • "слушает" канал групповой рассылки и вносит в свою таблицу все изменения состояния других машин (на каждой машине системы хранится таблица с состоянием всей системы);
  • отвечает на запросы о состоянии кластера в формате XML.

Групповая передача позволяет одиночному демону gmond посылать данные о состоянии машины всем остальным демонам кластера. По умолчанию демон запускается в виде двух потоков, один из которых «слушает» канал групповой рассылки, а другой записывает данные в хешированную таблицу в основной памяти, которая занимает там относительно немного места. Например, если на кластере, состоящем из 1024 машин, используется 25 метрик, то потребуется лишь около 144 Кбайт памяти.

Каждый демон gmond передает информацию в двух различных направлениях: в канал групповой рассылки в формате external data representation (XDR) или в формате XML через TCP-соединение. Демон передает только изменения значений метрик и делает это, когда значение метрики либо превышает определенный порог, либо не передавалось в течение заранее определенного временного интервала (интервал опроса). Это позволяет Gagnglia значительно (в разы) снизить объемы передаваемых метрик, что в свою очередь снижает загрузку канала групповой рассылки.

Взаимодействие с демонами gmond

Если демон получает групповой пакет от нового хоста, которого ранее не было в таблице, то демон примет все метрики с этого хоста, даже если заданный временной интервал для передачи ряда метрик не истек. Это обусловлено тем, что часть параметров посылается весьма редко (скажем, информация о количестве процессоров на машине — один раз в час) и часть метрик с нового хоста какое-то время останется недоступной.

Демон gmond на одной из машин может стать недоступным для других таких же демонов, например, из-за того, что машина зависла. Однако другие демоны gmond «не забудут», что одна из машин зависла. Когда машина снова станет доступной, информация о ней вновь появится в групповом канале. Демон на каждой машине воспринимает собственную информацию также посредством группового канала через локальную петлю (loopback). Хотя другие демоны не забудут о зависшей машине, собственно проблема зависания как таковая на данном этапе никак не решается.

При запросе демон выдает полную информацию о состоянии кластера в формате XML, включая описатели документа DTD (Document Type Definition). Однако такая информация будет выдана только тому хосту, адрес которого содержатся в хешированной таблице в основной памяти или отмечен как «доверительный» (trusted). Является ли адрес доверительным, демон определяет при запуске. Чтобы сделать адрес хоста доверительным, следует добавить в конфигурационный файл (/etc/gmond.conf) строку trusted_hosts . Теперь демон будет выдавать по запросу полное состояние кластера. Параметр trusted_hosts может быть использован несколько раз, чтобы описать несколько доверительных хостов. Таким способом на основе демона gmond можно строить системы отображения состояния сразу нескольких кластеров. Так, если имеется два отдельных кластера, то на каждом можно запустить систему Ganglia. Если написать в файлах /etc/gmond.conf строку trusted_hosts с указанием хостов соседнего (не своего) кластера, то можно будет видеть на одной картинке общее состояние сразу двух кластеров. Другой вариант: на HTTP-сервер, где планируется размещать страницы состояния кластеров, можно объявить как доверительный хост на обоих кластерах.

Содержимое файла описания состояния кластера на конкретной машине можно увидеть, запустив команду «telnet localhost 8649» либо «telnet remote.cluster.nodename 8649» на удаленной машине. Если демон на машине remote.cluster.nodename «доверяет» хосту, на котором выдана предыдущая команда, то можно будет увидеть XML-документ.

Демон gmond имеет 24 стандартные метрики: количество процессоров на машине, скорость процессора, использование (в процентах) процессора задачами и т. п. При необходимости можно увеличить число метрик, использовав программу gmetric из комплекта Ganglia.

Например, если в ОС Linux потребуется добавить имя выполняющегося процесса, который потребляет большую часть процессорного времени, то в bash это можно сделать так:

NAME=`top -ibn 1 | awk /COMMAND/,/=======/
 | head -2 | tail -1 | awk ?{print $NF}? `
gmetric —name=PROG_NAME —value=»$NAME»
 —type=string,

где PROG_NAME — имя процесса, которое фигурирует в последней колонке вывода команды ?top?.

Если приведенная последовательность будет выполняться регулярно (даже не подключаясь к демону), например, как задание cron, то этот параметр можно будет наблюдать с помощью Ganglia постоянно.

Сервер Ganglia

Рис. 1. Пример отображения состояния кластера (Ganglia)

Наблюдать состояние кластера можно с использованием специальных программных модулей расширений (plug-in), которые добавляются к HTTP-серверу. На рис. 1 приведен пример состояния реально работающего кластера. В отличие от программ типа «ntop» для нормальной работы Ganglia все необходимые компоненты должны быть установлены на той машине, на которой планируется запустить Web-сервер, воспринимающий информацию из канала групповой рассылки и формирующий соответствующие графические образы на Web-странице (см., например http://ram48.i2net.sunysb.edu/ganglia/index.php).

Состояние кластера представлено в виде Web-страницы, составленной из отдельных графических элементов, каждый из которых содержит указатель URL на страницу состояния отдельного хоста (рис. 2). Порядок размещения графических элементов может быть упорядочен в соответствии со значениями одной из метрик (в порядке уменьшения или увеличения). Система позволяет увидеть как текущее состояние, так и «историю»: час, день, месяц, год назад. Имеется возможность упорядочивания машин кластера на картинке по заданной метрике.

Рис. 2. Пример графических элементов для одного узла кластера

Big Brother

Хотя Big Brother не является свободно распространяемой системой, при условии некоммерческого использования ее можно получить бесплатно.

Рис. 3. Пример страницы состояния сети

Информация о кластере представляется в виде Web-таблиц (рис. 3), колонки которых имеют имена различных сервисов и ресурсов: процессор, диск, nntp, ftp, dns, http, msgs, и др., иными словами имена метрик, которые можно добавлять при помощи сенсоров. Строки таблицы представляют собой имена машин кластера. В каждой ячейке таблицы отображается кружок (или квадратик) определенного цвета, соответствующий состоянию метрики. Красный показывает, что значение метрики вышло за пределы допустимого; желтый — на границе допустимого; черный — недоступно для системы отображения состояния; зеленый означает, что все в норме; сиреневый — не поступало сведений о значении данной метрики в течение интервала опроса (по умолчанию — 30 секунд). При выборе курсором мыши любой из цветных фигур в таблице можно получить страницу с более полной информацией о данном элементе компьютерной системы. В Big Brother имеется хорошо проработанная возможность конфигурирования автоматической отправки сообщения о выходе метрик за пределы допустимого. Сообщение может быть послано по электронной почте, на пейджер или на мобильный телефон (в формате SMS).

На каждом компьютере кластера устанавливается и запускается клиентская программа, которая регулярно (например, как задание cron) передает информацию на сервер, собирающий поступающую информацию в соответствии с таблицей клиентских хостов. На основе поступившей информации Big Brother формирует группу Web-страниц, которые могут быть сделаны доступными для обозрения посредством подходящего HTTP-сервера. Эти страницы просматриваются практически любым браузером. Важной особенностью является возможность объединять хосты в группы, которые будут отображаться на отдельной Web-странице (директивы group и group-compress). Кроме того, существует возможность просмотра архива состояний кластера и его компонентов за день, месяц или год.

Все компоненты Big Brother должны запускаться автоматически после загрузки операционной системы на любом компьютере кластера. В системе предусмотрено автоматическое обновление визуализируемых параметров посредством использования параметров HTML — языка описания страницы.

Заключение

Обе описанные системы визуализации кластера можно использовать на любом вычислительном Unix-кластере, существует ряд технических различий. Например, Big Brother дает более грубую картинку (несколько цветов описывающих различные группы состояний узлов кластера), чем Ganglia (график показывающий изменение метрики во времени), но Big Brother предоставляет средства для уведомления администратора о наступлении неблагоприятных событий. В целом же можно заключить, что Ganglia в большей степени ориентирована на пользователя кластера, а Big Brother на администратора. Обе системы визуализации состояния кластера не являются альтернативами для конкретного вычислительного кластера, более того, полезно использовать обе системы в одно и то же время, если количество пользователей велико, а простои оборудования дороги.

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

Андрей Шевель (Andrei.Chevel@pnpi.spb.ru) — сотрудник Института ядерной физики (Санкт-Петербург).

Поделитесь материалом с коллегами и друзьями