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

В НИВЦ МГУ разрабатывается программный комплекс Octotron, предназначенный для решения двух важнейших для любого суперкомпьютерного центра задач: обеспечения максимальной сохранности оборудования и предоставления пользователям максимального объема доступных в данный момент вычислительных ресурсов. Ключевая особенность Octotron — банк неисправностей вычислительных комплексов, который в перспективе должен быть доступен всему суперкомпьютерному сообществу. В банке накапливаются описания реальных ситуаций, например: протечка охлаждающей жидкости не была обнаружена, так как вышел из строя датчик протечки; SMS-уведомление администраторам о критической ситуации не было отправлено, так как на счету GSM-модема не было средств; после перезапуска всего комплекса не стартовал один из сервисов и т. п.

Задача обеспечения надежной работы суперкомпьютерных центров и повышения их отдачи далеко не нова, но основные исследования в этой области обычно направлены на поддержание бесперебойной работы приложений пользователей с помощью механизмов контрольных точек. Действительно, если приложение выполняется на большом числе процессоров достаточно долгое время, то необходимо сохранять промежуточные состояния процессов, поскольку растет вероятность сбоя. Существуют алгоритмы, реализующие предсказание сбоев на основе анализа журналов работы вычислительной системы и позволяющие инициировать превентивную миграцию процессов выполняющегося приложения с потенциально сбойных узлов на другие узлы, создаются механизмы обмена сообщениями между процессами, устойчивые к отказам. Однако задачи обеспечения максимальной сохранности оборудования и предоставления пользователям максимального объема вычислительных ресурсов, доступных в данный момент, все эти средства не решают, а поддержка надежной работы и мониторинг состояния вычислительного комплекса обеспечиваются средствами либо проприетарных программно-аппаратных продуктов (HP OpenView, IBM Systems Director и т. п.), либо одной из имеющихся систем мониторинга, которая требует большой дополнительной работы по установке, настройке и написанию набора скриптов, реагирующих на конкретные подмножества потенциально аварийных ситуаций. Подобные решения, как правило, не работают на системах разных производителей и не обеспечивают обмена опытом поддержки больших вычислительных комплексов.

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

 

Рис. 1. Порядок формирования модели в виде мультиграфа
Порядок формирования модели в виде мультиграфа

 

Для хранения графа модели в системе Octotron используется графовая СУБД Neo4j [1], а сама система написана на Java. Для построения графа модели суперкомпьютерного комплекса можно использовать непосредственно интерфейс Neo4j, однако для удобства разработки и с учетом возможной смены системы хранения графовых данных был создан API, реализующий основные функции построения модели (создать вершину с атрибутами, связать вершины заданным типом связи и т. д.). С помощью этого интерфейса можно описать модель на относительно простом языке Python. Есть возможность загрузить данные из внешних файлов в формате CSV, описывающих, скажем, соответствия IP-адресов узлов и их имен или же идентификаторы сетевых карт. На языке Python описываются и правила, определяющие сбои в работе суперкомпьютера. Данные в Octotron поступают прежде всего от системы мониторинга суперкомпьютера — написав простую программу, можно обеспечить работу Octotron совместно с любой системой мониторинга и считывание данных из других источников, например от системы управления потоками заданий или специальных датчиков (проверка баланса GSM-модема и т. д.).

Принципы построения модели суперкомпьютерного комплекса сходны с идеями базы данных управления конфигурациями (Configuration Management Database, CMDB), также предполагающей составление и ведение хранилища сведений о компонентах инфраструктуры ИТ и связях между ними. Подход, принятый в Octotron, более низкого уровня и вместе с тем более «легковесный» — объектами модели являются не компьютерные системы в целом, а только те их компоненты, некорректное поведение которых можно оперативно диагностировать: процессоры, модули памяти, вентиляторы. В модель входят логические сущности, такие как очереди или свойства доступности вычислительных узлов. Структура модели не изменяется в ходе штатной работы вычислительного комплекса и не содержит данных, не требующихся для обеспечения автономной работы комплекса. Атрибуты объектов модели содержат в основном характеристики состояния объектов, получаемые с «живой» вычислительной системы. Система Octotron не взаимодействует с пользователями, а является инструментом системного администратора.

Octotron тестируется на суперкомпьютерах «Чебышев» и «Ломоносов» МГУ [2, 3], причем на первом она фактически уже работает в режиме промышленной эксплуатации. Модель этого суперкомпьютера в конфигурации из 1250 процессоров содержит около 10 тыс. вершин, 25 тыс. связей и 230 тыс. атрибутов (на рис. 2 представлен фрагмент модели). Система отслеживает выход за заданные пороги температуры процессоров вычислительных узлов, воздуха в помещении, охлаждающей жидкости на входе и выходе кондиционеров, определяет недоступность вычислительных узлов, повышение средней загрузки процессоров, анализирует состояние очередей заданий (например, фиксируя аномальные ситуации: слишком мало заданий в очереди или выполняющихся заданий, много свободных процессоров и т. п.), рост числа ошибок на сетевых интерфейсах. Основной источник данных — система мониторинга, основанная на collectd.

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

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

***

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

Литература

  1. Александр Алексиянц, Антон Коршунов, Сергей Кузнецов. СУБД для социальных сетей // Открытые системы.СУБД. — 2014. — № 2. — С. 51–53. URL: http://www.osp.ru/os/2014/02/13040051 (дата обращения 20.10.2014).
  2. Владимир Воеводин. Ситуационный экран суперкомпьютера // Открытые системы.СУБД. — 2014. — № 3. — С. 10–13. URL: http://www.osp.ru/os/2014/03/13040775 (дата обращения 20.10.2014).
  3. Владимир Воеводин, Сергей Жуматий, Сергей Соболев и др. Практика суперкомпьютера «Ломоносов» // Открытые системы.СУБД. — 2012. — № 7. — С. 36–39. URL: http://www.osp.ru/os/2012/07/13017641 (дата обращения 20.10.2014).

Сергей Соболев (sergeys@parallel.ru) — старший научный сотрудник, НИВЦ МГУ им. М. В. Ломоносова. Статья подготовлена на основе материалов доклада, представленного на Пятом Московском суперкомпьютерном форуме (МСКФ-2014, грант РФФИ № 14-07-20284г). Работа выполняется при поддержке РФФИ, грант № 12-07-33047.