Параллельные вычисления в ИММ УрО РАН
 
 

Опыт создания учебного вычислительного кластера в ИММ УрО РАН

А. С. Игумнов, С. В. Шарф

Работа выполнена при поддержке грантов РФФИ 01-07-90215, 00-15-96042.

В 2000 году в ИММ УрО РАН был создан учебный класс для проведения практических занятий со студентами Уральского государственного университета. Данная статья рассказывает о типичных проблемах возникающих при развертывании таких классов и путях их решения.

Назначение класса

При выборе оборудования и программных средств предполагалось, что класс должен обеспечивать:

  • Объединение компьютеров в вычислительный кластер для обучения студентов параллельному программированию
  • Проведение практических занятий по языкам программирования
  • Проведение занятий по компьютерной графике, в том числе с использованием библиотеки OpenGL
  • Обучение использованию популярных прикладных программ
Дополнительно должны выполнятся требования:
  • Быстрой конфигурации при подготовке к занятиям
  • Стабильности работы всех компьютеров в классе с "защитой от дурака"

Исходя из требований к производительности, в классе были установлены 8 однотипных компьютеров PIII-700, оснащенных 128 Мб оперативной памяти, видеокартой с 3D ускорителем фирмы Nvidia, сетевой 100Мб/с картой. Все машины объединены в локальную сеть через 100Мб сетевой коммутатор фирмы 3 COM.

Базовое программное обеспечение

В качестве основной операционной системы была выбрана ОС Linux - дистрибутив RedHat. Дистрибутив RedHat содержит все основные средства разработчика - компиляторы и интерпретаторы популярных языков программирования, разнообразные программные библиотеки, базы данных и т.п. В состав дистрибутива входит интегрированная среда разработчика на Си++ - KDE Develop.

Дополнительно были установлены такие свободно распространяемые продукты как Comodo фирмы AciveState - среда разработчика на языках Perl и Python и OpenOffice фирмы Sun - комплект офисных приложений, равный по функциональности MS Office.

Кроме того, нам пришлось установить драйвер для видеокарты от фирмы Nvidia для поддержки аппаратного ускорения OpenGL.

Инсталляция системы

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

Было принято решение установить систему на один компьютер, после чего продублировать ее на все остальные.

Для копирования данных мы воспользовались мини дистрибутивом Linux'а - tomsrtbt, размещающегося на одной дискете. Этот дистрибутив содержит все необходимые программы для удаленного доступа по сети (rsh, rcp), программы работы с диском (fdisk, mkfs) и программы архивирования (tar, gz).

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

Изначально система была установлена на один компьютер и полностью сконфигурирована (примерно 2 часа рабочего времени), затем на остальные машины было скопировано содержимое винчестера исходной машины (1 час на все 7 машин). Дальнейшая настройка потребовала лишь минимальной ручной работы, а именно, установки уникальных сетевых адресов.

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

  • Настойка старых плат расширения ISA (/etc/conf.modules, /etc/isapnp.conf)
  • Параметры видеокарты и монитора (/etc/X11/XF86Config)
  • Сетевые адреса (/etc/sysconfig/network, /etc/sysconfig/network-scripts)
В процессе работы появилась идея создать специализированный одно-дискетный вариант Linux'а, который бы полностью автоматизировал процесс дублирования ОС с внесением необходимых правок. Сложность разработки такого дистрибутива минимальна, но для наших восьми машин проще оказалось внести все правки вручную.

Виртуальная машина

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

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

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

Подключение вычислительных мощностей учебного класса к МВС-1000/16

Так как занятия со студентами проходят лишь в дневные часы, то с самого начала мы хотели использовать вычислительные мощности учебного класса для счета задач, имеющихся в ИММ УрО РАН. С точки зрения организации счета комплекс машин учебного класса близок к МВС-1000/16, который представляет собой кластер-стойку из управляющей машины и 15 компьютеров PIII-800, связанных между собой двумя независимыми (на базе двух 16-портовых коммутаторов) Fast Ethernet сетями. Поэтому мы пошли по пути подключения к существующей системе управления кластером (совместная разработка ИПМ РАН и ИММ УрО РАН).

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

Первое, что пришло на ум, - это соединить коммутатор в классе и предназначенный для пользовательских сообщений коммутатор МВС-1000/16. При этом пользовательские сообщения идут через коммутаторы, а системные - по-прежнему через хост-машину. В основном, системные сообщения обусловлены работой с сетевыми файлами, которые физически расположены непосредственно на хост-машине, и не порождают никаких издержек.

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

Узким местом получившегося кластера является простое соединение портов двух коммутаторов, которое приводит к задержкам при одновременной передаче между многими парами процессоров стойка-класс. Этот недостаток может быть преодолен, например, транкированием портов. Однако примененное простое соединение обладает важным преимуществом - низкой ценой, позволяя, вместе с тем, решать достаточно широкий класс задач на всем расширенном МВС-1000/16 с приемлемыми издержками.

Режим работы учебного вычислительного кластера

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

За счет описанного выше использования виртуальной машины даже занятия по изучению ядра и администрирования ОС, которые зачастую приводят к зависанию, не затрагивают счетных задач. Неожиданная проблема, возникшая когда студенты из класса стали запускать задачи на расширенном МВС-1000/16, была обусловлена спецификой системы управления кластером. Дело в том, что при освобождении счетного узла по концу задачи уничтожаются *все* процессы данного пользователя, в том числе и запущенные студентами виртуальные машины. Возможных решений здесь много, мы остановились на простом разделении login-имен в МВС-1000/16 и учебном классе.

В качестве заключения отметим, что учебный вычислительный класс успешно функционирует в ИММ УрО РАН на протяжении более 6 месяцев.