Ситуационный экран суперкомпьютера

Понятие «ситуационный экран» ассоциируется сегодня не с суперкомпьютером, а, скорее, с работой диспетчеров АЭС, в задачу которых входит обеспечение надежного функционирования таких объектов. Для больших суперкомпьютерных систем «ситуационный экран» становится жизненно необходимым, и тому есть по крайней мере две причины: обеспечение эффективности и сохранность оборудования.

Эффективность работы действующих во всем мире суперкомпьютеров крайне низка: потери при их эксплуатации идут по всей вертикали — от формирования очереди заданий до уровня системного программного обеспечения и аппаратуры [1, 2]. Не существует какого-то одного параметра, который бы позволял судить об эффективности работы системы в целом, — администратор суперкомпьютера должен иметь информацию о статусе операционной системы на каждом узле, использовании ресурсов, состоянии очереди задач и о сотнях других компонентов. Кроме того, часто необходимо иметь не только сиюминутные, но и исторические данные, позволяющие прогнозировать ситуацию и вовремя принимать правильные решения.

Большие суперкомпьютерные системы — это исключительно сложные, энергонасыщенные и весьма дорогостоящие установки, поэтому остро стоит вопрос сохранности оборудования, простой которого оборачивается большими убытками. Срок службы суперкомпьютеров — шесть-семь лет, и с учетом только начальной стоимости (десятки миллионов долларов) каждый день его работы оценивается во многие сотни тысяч рублей. Завис планировщик заданий, нет свободного места на диске для временных данных, возникли проблемы с драйвером межсоединения — суперкомпьютер простаивает, а значит, налицо убытки. В такой ситуации лишь постоянный оперативный контроль над всеми компонентами дает уверенность в своевременном обнаружении и исправлении проблем.

Общие требования

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

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

• Вычислительные устройства. Сюда входят процессоры, память, системы хранения всех уровней иерархии, коммуникационные сети, коммутаторы, служебные серверы и т. п.
• Инженерная инфраструктура. Сегодня на эту часть суперкомпьютера обращают мало внимания, однако нарушение ее работоспособности вызывает проблемы более серьезные, чем выход из строя одного вычислительного узла, в силу масштаба последствий.
• Стек программного обеспечения. Нештатная работа ключевых компонентов программного обеспечения может оказать влияние не меньшее, чем выход из строя части аппаратуры. Вместе с усложнением аппаратуры суперкомпьютерных систем усложняется и соответствующее программное обеспечение, отказы в работе которого приходится отслеживать столь же внимательно, как и отказы в работе оборудования.
• Приложения. Эффективность работы лишь немногих суперкомпьютерных приложений превышает 10%, а в большинстве случаев используются лишь единицы процентов от их потенциала. Вовремя показать признаки низкой эффективности приложений, помочь найти и ликвидировать причины — важная и очень сложная задача.
• Поток задач. Здесь требуется определить структуру входного потока заданий, ждущих исполнения в различных очередях и в различных разделах суперкомпьютера, а также составить набор уже выполняющихся заданий. При этом акцент делается на определении влияния приложений друг на друга.
• Пользователи. Важно определить профиль использования суперкомпьютера каждым пользователем. Именно конкретные пользователи определяют структуру потока задач и набор выполняющихся в каждый момент времени заданий, а также, отчасти, КПД работы суперкомпьютера.

Перечисленные элементы суперкомпьютерного комплекса в том или ином виде должны быть отражены на ситуационном экране.

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

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

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

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

Открытость к внешним источникам данных. Ситуационный экран берет данные о работе системы и ее отдельных элементах из внешних источников, следовательно, должны быть предусмотрены внешние интерфейсы для интеграции со сторонними сервисами с использованием стандартных протоколов и форматов (http, json, csv,. ..). Сложное оборудование, например системы энергоснабжения, имеет собственные системы мониторинга, что, конечно, нужно использовать. Необходимо брать данные и от систем управления прохождением заданий (SLURM, Cleo и т. п.), без чего анализ на уровне отдельных заданий и пользователей будет невозможен. В будущем разнообразие источников данных будет только увеличиваться, что должно поддерживаться ситуационным экраном. Не менее важна и интеграция с разного рода аналитическими системами, выполняющими анализ параметров работы компонентов суперкомпьютерного комплекса.

Что и для кого?

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

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

Основная задача ситуационного экрана при анализе данных — это предоставление информации о «здоровье» системы (сведения об отказах оборудования или компонентов программного обеспечения должны быть немедленно отображены на ситуационном экране). Не менее важной является информация о перегрузке компонентов, об их выходе на предельные режимы работы, которые потенциально могут быть узким местом в работе суперкомпьютера. Например, средний исходящий трафик суперкомпьютера «Ломоносов» — 150 Гбайт/сутки, и отклонение от этого показателя в любую сторону должно фиксироваться.

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

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

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

Первые результаты

Для суперкомпьютеров «Чебышев» и «Ломоносов», составляющих основу вычислительного комплекса МГУ, был разработан ситуационный экран, в котором воплотились многие из перечисленных требований.

На рис. 1 показан пример возможного варианта ситуационного экрана для использования на мобильном устройстве. В данном случае пользователю выдаются параметры загруженности основного х86-раздела суперкомпьютера «Ломоносов». Имеется возможность настройки экрана под особенности конкретного суперкомпьютера, запросы пользователя, например системного администратора, и под требования устройства (экран ПК, планшета или смартфона). Кроме того, должна быть возможность создания стены визуализации — качественная поддержка большого суперкомпьютерного комплекса сопровождается таким объемом необходимых данных, что может потребоваться стена из 15 больших панелей, которые всегда должны быть доступны пользователю.

Рис. 1. Мобильный вариант ситуационного экрана

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

Рис. 2. Тонкий анализ динамики поведения и эффективности приложения

Пример приложения, у которого также явно имеются дефекты эффективности, показан на рис. 3. Каждая горизонтальная линия отражает загрузку одного ядра: зеленый цвет соответствует загрузке ядра 100%, красный — 0%. Из графика ясно следует, что около трети из 50 ядер данного приложения все время простаивают.

Рис. 3. Приложение с явным дефектом в эффективности

На рис. 4 отражена средняя загрузка процессоров (CPU_Load) суперкомпьютера «Чебышев» за три дня, полученная путем усреднения по всем вычислительным узлам. Во-первых, видно, что в среднем процессоры загружены на 70–80%. С учетом постоянной большой очереди ожидающих заданий данный факт говорит о свойствах реальных приложений, требующих не только циклов процессора, но и других конкурентных ресурсов: коммуникационных сетей, дисков и т. п. Во-вторых, на графике виден «провал» загрузки до 14–15%, что может быть сигналом о проблемах на суперкомпьютере, однако в данном случае причина не в этом — политика прохождения заданий на «Чебышеве» такова, что все задания, требующие большого числа процессоров, собираются в единый пул, который начинает выполняться в ночь со среды на четверг каждой недели. Именно эта ситуация и отражена на графике — пока не набралось нужного числа свободных процессоров, первое задание из пула не может стартовать и уже освободившиеся процессоры простаивают.

Рис. 4. Средняя загрузка процессоров (CPU_Load) суперкомпьютера «Чебышев»

Неожиданной оказалась гистограмма на рис. 5, показывающая распределение времени нахождения вычислительных узлов в таком состоянии, когда величина LoadAVG принимает конкретное значение. На суперкомпьютере «Чебышев» вычислительные узлы содержат по два четырехъядерных процессора, поэтому значения LoadAVG от 8 и ниже нормальны — на каждое ядро приходится не более одного процесса. На рис. 5 показано распределение LoadAVG от значения 9 и выше, а это диапазон, который вызывает вопросы. В некоторых случаях можно объяснить появление значения 9 отражением модели мастер-рабочие, когда активность мастера невелика (один процесс-мастер управляет восемью процессами-рабочими, и все эти девять процессов работают на одном узле). Можно также понять значение 16 — «это надежда неопытных пользователей на гипертрейдинг» (Hyper-Threading — гиперпоточность, параллельное выполнение задания на множестве исполнительных устройств). Однако разнообразие принимаемых значений LoadAVG слишком велико, что сигнализирует о ситуации, в которой нужно разбираться, — «лишние» процессы на узлах заведомо будут снижать эффективность выполнения приложений. Все эти данные должны анализироваться системными администраторами.

Рис. 5. Значение величины LoadAVG на узлах суперкомпьютера «Чебышев»

***

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

Литература

1. Воеводин Вл. В. Суперкомпьютеры и парадоксы неэффективности // Открытые системы.СУБД. — 2009. — № 10. — С. 17–20. URL: http://www.osp.ru/os/2009/10/11169656 (дата обращения: 18.04.2014).
2. Воеводин Вл. В., Воеводин Вад. В. Спасительная локальность суперкомпьютеров // Открытые системы.СУБД. — 2013. — № 9. — С. 12–15. URL: http://www.osp.ru/os/2013/09/13038278 (дата обращения: 18.04.2014).

Владимир Воеводин (voevodin@parallel.ru) — зам. директора НИВЦ МГУ. Работа выполняется при поддержке РФФИ (13-07-12206-офи).