CC BY
36
УДК 004.75 ББК 74.580.253
ОПЫТ ПРОЕКТИРОВАНИЯ И ЭКСПЛУАТАЦИИ УЧЕБНОЙ МНОГОПОЛЬЗОВАТЕЛЬСКОЙ СИСТЕМЫ НА БАЗЕ ОТКРЫТОГО ПО
В. Л. Бурцев, к. т. н., доцент кафедры «Компьютерные системы и технологии» Тел.: 761-57-54, e-mail: vburcev@mail.ru
A. Б. Вавренюк, к. т. н., доцент кафедры «Компьютерные системы и технологии»
Тел.: (903) 724-40-85, e-mail: abvavrenyuk@mephi.ru А. В. Воронин, асс. кафедры «Компьютерные системы и технологии»
Тел.: (906) 729-24-48, e-mail: voroninja@gmail.com
В. В. Макаров, к. т. н., доцент кафедры «Компьютерные системы и технологии» Тел.: (906) 037-89-96, e-mail: makarov@dozen.mephi.ru
B. А. Шурыгин, к. т. н., доцент кафедры «Компьютерные системы и технологии»
Тел.: (903) 131-03-35, e-mail: vic-54@mail.ru Национальный исследовательский ядерный университет МИФИ
www.mephi.ru
In this paper, the construction of a universal learning laboratory to support the learning process in higher education on the subject "Computer Science and Engineering" is considered. Such laboratory will ensure the laboratory practice on special subjects of the curriculum in traditional and distance modes of running classes.
В статье рассматриваются вопросы построения универсальной учебной лаборатории для поддержки учебного процесса в вузе по направлению «Информатика и вычислительная техника». Такая лаборатория должна обеспечивать проведение лабораторных практикумов по специальным дисциплинам учебного плана в традиционном и дистанционном режимах проведения занятий.
Ключевые слова: кластер, информатика и вычислительная техника, операционная система, параллельная вычислительная система.
Keywords: cluster, informatics and computer science, operating system, parallel computer system
Введение
Задачи, поставленные руководством страны по широкому внедрению во все сферы деятельности свободно распространяемого программного обеспечения, в
настоящее время становятся особенно актуаль-
ными в сфере образования. Это
объясняется, прежде всего,
особенностями образовательного процесса, тре-
бующего, во-первых, постоянного и быстрого обновления используемых программных продуктов для удовлетворения быстро меняющихся требований со стороны работодателей; во-вторых, широким распространени-
ем дистанционных форм образования; в-третьих, потребностью иметь аналогичные программные продукты, установленные на домашних компьютерных системах обучающихся; в-четвертых, экономическими соображениями. (Так,
совокупная стоимость ПО, необходимого для поддержки учебного процесса подго-
товки бакалавров по направлению
«Информатика и вычислительная техника», может составлять до $3000 и более на один рабочий компьютер домашнего использования.)
Переход на двухступенчатый образовательный процесс в высшей школе (бакалавриат, магистратура), а также необходимость
обеспечивать переподготовку и повышение квалификации кадров для нужд народного хозяйства силами одного и того же коллектива вуза (кафедры) с использованием, как правило, одного и того же оборудования и ПО ставят задачу проектирования универсальных учебных лабораторий, отвечающих ряду общих требований, в том числе и обеспечивающих учебный процесс в дистанционном режиме. В предлагаемой вниманию читателей статье рассматривается один из возможных вариантов оборудования такой лаборатории.
Отправной точкой для проектирования такой лаборатории является комплекс требований, определяемых учебным процессом, а также рядом соображений по рациональной организации коллективного доступа к аппаратным и программным ресурсам системы, в том числе и в дистанционном режиме (через Интернет). Все решения принимались разработчиками исходя из:
• действующего стандарта ГОС 3 по направлению подготовки 230100;
• минимизации общих затрат на приобретение оборудования;
• типового численного состава учебных групп;
• взаимозаменяемости рабочих мест;
• необходимости резервирования при хранении пользовательских данных;
• необходимости быстрого восстановления системы при сбоях оборудования;
• необходимости обеспечить одновременный коллективный доступ к ресурсам системы непосредственно с рабочих мест лаборатории и через Интернет;
• необходимости обеспечить оперативный контроль при проведении учебных занятий со стороны преподавателя, выступающего одновременно и в роли
администратора системы;
• необходимости защиты пользовательских программ и данных от случайного или умышленного разрушения;
• необходимости защиты системы от вредоносных воздействий извне;
• требований «привязки» к действующему расписанию учебных занятий;
• требований обеспечения коллективного дистанционного доступа к внешней аппаратуре, не включенной в состав лаборатории;
• необходимости установки в лаборатории автоматизированной системы контроля знаний по дисциплинам учебного плана;
• требований защиты авторских прав разработчиков учебно-методических материалов, размещенных в лаборатории в электронном виде.
Учебный план по направлению «Вычислительная техника и информатика» в соответствии с ГОС 3 диктует необходимость обеспечивать в лаборатории проведение лабораторных практикумов по нескольким блокам учебных дисциплин, а именно: «Основы теории ЭВМ», «Программирование», «Моделирование», «Системное ПО», «Защита информации», «Параллельные вычисления», «Компьютерная графика», «Микропроцессорные системы», «САПР» и др.
Все лабораторные практикумы можно условно отнести к четырем категориям в зависимости от режима использования ресурсов лаборатории. К первой категории следует отнести те практикумы, которые требуют только наличия устройств хранения и отображения текстовой информации (например, «Надежность, контроль и диагностика»). Ко второй категории можно отнести те практикумы, для которых необходимо выполнение соответствующих приложений (например, «Программирование на языке высокого уровня»). Третья категория включает практикумы, в которых объектом изучения является собственно системное ПО лаборатории (например, «Операционные систе-
мы»). И, наконец, четвертая категория будет включать практикумы, в которых оборудование лаборатории используется как единый кластер (например,
«Параллельное программирование»). Для последних двух категорий объект изучения является в то же время и средством изучения. Кроме того, особенностью режима является коллективный доступ к ресурсам кластера, что существенно повышает требования к ресурсам лаборатории.
Иными словами, универсальная лаборатория должна обеспечивать проведение практикумов по всем специальным дисциплинам учебного плана (кроме схемотехнических дисциплин, которые также планируется поддерживать в будущем).
С учетом изложенного будут рассмотрены решения, положенные в основу проекта.
Архитектура аппаратного и программного обеспечения лаборатории
Основой лаборатории является сервер, важной задачей является выбор для него операционной системы. При ограниченных финансовых ресурсах взгляд непременно падает на свободное программное обеспечение, в частности на ОС, базирующиеся на ядре Linux. Большинство таких операционных систем являются бесплатными, но некоторые дистрибутивы распространяются только с коммерческой поддержкой от производителя. Учитывая число людей, способных разобраться со сложной системой, платить за такую поддержку не имеет смысла. Безусловно, операционная система должна быть стабильной и обладать большими библиотеками приложений. По этим показателям можно выделить дистрибутив Debian GNU/Linux, который имеет наибольшее среди всех дистрибутивов хранилище пакетов. В текущую стабильную версию включено свыше двадцати девяти тысяч пакетов программ для девя-
ти архитектур на основе ядра Linux. Также следует учесть, что операционные системы данного типа являются перспективными, бурно развиваются и поддерживаются как крупными компаниями, так и многочисленными сообществами пользователей. Эти ОС активно применяются на серверах и вычислительных узлах кластеров. Следовательно, они также имеют широкий спектр поддерживаемых аппаратных платформ. С точки зрения администрирования выбор этого дистрибутива тоже оправдан: Debian используется как серверная ОС повсеместно, поэтому имеется богатый набор инструкций по настройке ПО и решению разнообразных проблем, большое внимание уделено стабильности - все приложения тщательным образом тестируются для поиска и устранения ошибок.
Для того чтобы не усложнять задачу администрирования, для компьютеров на рабочих местах лаборатории выбрана та же версия операционной системы.
Без использования сети такая лаборатория имеет ограниченные возможности. Сеть организована обычным способом, через 16-портовый сетевой коммутатор. При этом для увеличения числа рабочих компьютеров можно подключать дополнительные сетевые коммутаторы. Однако, учитывая особенности лаборатории - большой трафик (PXE, FTP, NFS, работа кластера), желательно использовать коммутаторы с шириной полосы пропускания 1000 Мб/с и выше.
Необходимое число компьютеров в одной аудитории соответствует размеру групп студентов. В среднем можно предположить, что необходимо 25 рабочих мест в одной аудитории. В стандартной конфигурации для этого необходимо 25 комплектов: системный блок, монитор, мышь, клавиатура. Однако для экономии денежных средств можно уменьшить количество используемых системных блоков. В настоящее время дискретные видеокарты ведущих производителей обладают несколькими выходами (VGA, DVI, HDMI, Display Port) и могут посылать разный сигнал на эти выходы. Новые модели видеокарт могут обеспечить и три независимых сигнала. То есть к одному компьютеру можно подключить два монитора. Первоначально это и было реализовано. Но помимо этого, в продаже есть материнские платы со встроенной видеокартой, которая может работать одновременно с дискретной видеокартой. В среде ОС Linux можно реализовать независимую работу
двух и более рабочих столов
(монитор, мышка и клавиатура) на одном системном блоке. То есть можно обеспе-
чить три рабочих места, подклю-
ченных к одному компьютеру, и тем самым достичь значительной экономии оборудования. Уменьшение общего числа компьютеров обеспечивает упрощение администрирования, однако некоторое усложнение происходит из-за необходимости дополнительной настройки операционной системы. Желательно придерживаться стандартного набора оборудования, иначе придется проводить дополнительную настройку. Например, при разных производителях видеокарт, необходимо
иметь несколько конфигураций файла xorg.conf.
При проектировании учебной лаборатории всегда приходится находить компромиссы. Один из таких компромиссов - обеспечение приемлемой отказоустойчивости и простоты администрирования. Было рассмотрено две конфигурации.
Первая - на каждом клиентском компьютере установлена собственная версия операционной системы. Основной проблемой при таком решении является сложность администрирования: при изменении набора ПО необходимо повторить все действия на каждом компьютере, могут накапливаться изменения, в любом случае необходимо настраивать общий доступ к домашним каталогам пользователей.
Вторая - с помощью проектов PXE (Preboot eXecution Environment), LTSP (Linux Terminal Server Project) все рабочие компьютеры по сети при включении получают ядро операционной системы. В этом варианте также есть две возможных конфигурации -«тонкий» клиент или «толстый». В случае тонкого клиента все приложения запускаются на сервере, а терминалы просто принимают видеоряд, посылаемый сервером, и кроме него ничего не обрабатывают. При этом в терминалах может отсутствовать жесткий диск. В последнем случае существенно увеличивается нагрузка на сервер, что приводит к негативным эффектам в некоторых лабораторных работах (например, в практикуме по программированию на языке Java, где используется приложение Eclipse), особенно учитывая количество мест в аудитории - 21. Второй недостаток: слабо используются вычислительные возможности рабочих компьютеров. Поэтому при расширении разнообразия проводимых в аудитории занятий необходимо было либо значительно увеличивать производительность сервера, либо уходить от архитектуры тонкого клиента. С помощью тех же средств можно организовать и конфигурацию «толстый клиент». В этом случае операционная система полностью доступна рабочим компьютерам по сети, накопители на жестких дисках либо отсутствуют, либо используются как swap. Версия ОС для рабочих компьютеров хранится на сервере. Такой подход не требует индивидуальной настройки рабочих компьютеров, которая отнимает много времени даже при незначительных изменениях или обнаружении какой-либо ошибки в программном обеспечении. Настройка же
конфигурационных файлов для данной конфигурации выполняется только один раз при установке системы. Модификация ОС для рабочих компьютеров осуществляется стандартными средствами - менеджером пакетов APT, изменения доступны после перезагрузки.
Для уменьшения числа конфигурационных файлов желательно использовать аппаратное обеспечение одних и тех же производителей (например, видеокарты - NVIDIA, процессоры - Intel и т. д.). Жесткие диски можно использовать для хранения swap, необходимого при одновременном запуске на одном компьютере нескольких копий приложения, требовательного к объему оперативной памяти.
Опыт эксплуатации лаборатории показывает, что достаточным объемом для конфигурации трех рабочих мест на одном компьютере является 2 Гб оперативной памяти. Хорошо, если сетевая и материнская карты обладают технологией Wake-on-LAN, позволяющей организовать включение компьютеров непосредственно перед началом занятий. Выключение осуществляется специальным скриптом на сервере, который отслеживает время окончания занятий и посылает соответствующие сигналы рабочим компьютерам. Использование многоядерных процессоров также возможно с используемой конфигурацией.
Такая архитектура лаборатории имеет два узких места, отказ которых приводит к неработоспособности всей системы. Это сетевой коммутатор и главный сервер. В первый год эксплуатации лаборатории пришлось столкнуться с отказом и того и другого, поэтому желательно иметь запасной коммутатор, а надежность сервера повышать другими аппаратными и программными методами. Для хранения данных на сервере используется RAID пятого уровня (в дальнейшем планируется использование RAID шестого уровня) и периодически выполняется резервное копирование разделов с данными пользователей и ОС для рабочих компьютеров. Желательно иметь в наличии запасной сервер, на который в случае аварии можно перенести резервную копию ОС для рабочих компьютеров и конфигурационные файлы сетевых сервисов для быстрого восстановления работоспособности. Защита от злоумышленников, мониторинг и ведение журнала осуществляются стандартными средствами ОС.
На сервере постоянно запущены службы DHCP, DNS, FTP. При включении клиентского компьютера он соединяется с сервером с помощью службы PXE. Она позволяет получить IP-адрес до загрузки ОС. Далее с ftp-сервера загружается специально скомпилированное ядро ОС. Так как отсутствует жесткий диск, все необходимые для работы ОС файлы доступны с помощью сетевой файловой системы NFS. На последнем этапе загрузки ОС, после запуска большого X.Org, GDM запускает внутри себя три маленьких X.Org; в конфигурационном файле /etc/gdm/gdm.conf за каждым из них закреплены физические адреса USB-портов соответствующей мышки и клавиатуры и адрес выхода соответствующей видеокарты.
Процесс добавления новых компьютеров к уже готовой конфигурации зависит от его аппаратного обеспечения. При идентичных характеристиках и одном производителе аппаратуры исправления конфигурационных файлов может и не понадобиться. Характеристики оборудования, из-за которых необходимо выполнять дополнительную настройку: отличается количество ядер у процессора - необходимо собрать новую версию ядра ОС с поддержкой необходимого числа ядер процессора. Аналогично надо поступить при разных производителях CPU. Далее скомпилированное ядро помещается в каталог, доступный по FTP, настраивается конфигурационный файл pxeconfig.cfg для проверки IP-адреса компьютера, загружающего ядро. При совместном использовании видеокарт различных производителей необходимо создать правильно настроенный файл xorg.conf, который при помощи стартовых скриптов LTSP будет заменять стандартный. Похожим способом можно решить проблему различия разрешений экранов и адресов USB-портов только конфигурированием файла gdm.conf.
Если конфигурация для успешной загрузки рабочего компьютера подготовлена, надо убедиться, что компьютер получил IP-адрес по DHCP и доменное имя.
Количество конфигурационных файлов и ядер зависит от разнородности используемого аппаратного обеспечения. Однако разнородность не является непреодолимым препятствием при замене оборудования или добавлении новых компьютеров в сеть. В ходе эксплуатации лаборатории было выполнено ее расширение пятью компьютерами другой конфигурации.
При расширении сети компьютеров желательно помещать их в одну подсеть.
Опыт эксплуатации лаборатории с рассмотренной архитектурой показал удобство ее администрирования, гибкость, масштабируемость, эффективность.
Особенности использования оборудования лаборатории в режиме кластера
В связи с широким распространением в последнее время кластерных технологий важной задачей учебного процесса является подготовка кадров для разработки и эксплуатации параллельных и распределенных вычислительных систем (ПРВС). В производственных и научных ПРВС основное внимание уделяется эффективности использования ресурсов системы и достижению наивысшей ее производительности. В учебной же ПРВС основное внимание должно быть уделено другим качествам, таким как «прозрачность» и защита от некорректных действий обучаемого.
Требования к программному обеспечению:
• Возможность мониторинга пользователем каждого этапа выполнения параллельной программы (такие возможности предоставляет DVM [8], внешние мониторы оперируют данными о загрузке кластера, для остальных коммуникационных библиотек необходимо использовать сторонние средства анализа производительности параллельных приложений).
• Многопользовательский режим (запуск задач в процессе обучения осуществляется одновременно, что особенно актуально во время лабораторной работы, когда необходимо обеспечить очередность доступа к вычислительным ресурсам).
• Ограниченность ресурсов учебной лаборатории (тяжело использовать и поддерживать громоздкие системы, наподобие Condor [9] или OpenPBS [10]).
• Поддержка основных стандартов в области параллельных вычислений и различных моделей параллелизма (MPI [11], DVM, OpenMP [12]). Возможность добавления средств поддержки новых коммуникационных библиотек.
• Простой интерфейс пользователя. Параллельные приложения могут передаваться на выполнение с огромным числом различных параметров, также различные коммуникационные библиотеки имеют различный синтаксис параметров запуска приложений.
• Защита от ошибок и сбоев (в процессе обучения пользователь совершает ошибки, некоторые из которых могут оказаться критическими и привести к неработоспособности системы в целом, поэтому необходимо предусмотреть возможность их устранения и быстрого восстановления кластера).
• Временные ограничения (использование квот для пользователей во время проведения лабораторных занятий).
• Требование к аппаратным и программным платформам (свободность, бесплатность, поддержка ОС Linux, минимальная зависимость от конечного дистрибутива).
Промежуточный программный слой предоставляет набор программных инструментов для обмена сообщениями в рамках сетей, вызова удаленных процедур, управления доступом к ресурсам и других механизмов управления. Он обеспечивает создание единого виртуального пространства для выполнения распределенных задач, не зависящего от используемых сетевых технологий, аппаратного обеспечения, операционных систем и географической удаленности. Однако использование таких проектов (Globus Toolkit, Unicore, gLite [13]) для целей обучения сильно ограничено сложностью структуры и развертывания. Образовательные учреждения не обладают обширной аппаратной базой, ведь программное обеспечение этого уровня разрабатывалось для объединения множества вычислительных ресурсов, в том числе связанных глобальной сетью.
Как показывает анализ, наиболее подходящими для обучения являются системы DVM (Distributed Virtual Machine, Distributed Virtual Memory) и PVM (Parallel Virtual Machine). Название системы поддержки параллельного программирования DVM отражает наличие единого адресного пространства и использование виртуальных машин для двухступенчатой схемы отображения данных и вычислений на реальную параллельную машину. Помимо средств создания параллельных программ, эта система обладает богатым набором средств отладки, анализа и предсказания производительности, что обеспечивает простоту разработки и отладки параллельных программ и наглядно объединяет элементы моделей параллелизма по данным и управлению.
Для работы требуется установленная и настроенная реализация библиотеки стандарта MPI. Эти библиотеки представляют собой интерфейс для передачи информации, который позволяет обмениваться параллельным программам сообщениями. На текущий момент разработано множество интерфейсов параллельного программирования: PVM, MPI, OpenMP, ACE, CVM, HPVM, iCC, MPL и т. д. Со стороны обучения интерес представляют OpenMP, MPI и PVM. Система MPI является наиболее широко ис-
пользуемым и динамично развивающимся интерфейсом своего класса. Существуют его реализации для большого числа аппаратных и программных платформ, он также поддерживается крупными компаниями (Oracle, SGI, HP Intel, Microsoft). На его основе базируется множество библиотек для организации параллельных вычислений: ARCH,
BLACS, Counterpoint, DOUG, JOSTLE и др. Поддержка стандарта передачи сообщений MPI есть практически во всех ПРВС, поэтому вопросов о его использовании в комплексе ПО, направленном на обучение, не возникает. Стандарт OpenMP (Open MultiProcessing) специализирован для программирования многопоточных приложений на многопроцессорных системах с общей памятью, что очень актуально в связи с активным развитием и широким распространением многоядерных процессоров. Применение OpenMP совместно с MPI позволяет выполнять двухуровневое (гибридное) распараллеливание, особенно эффективное на большом числе процессоров [14]. Системы управления кластером или системы управления пакетной обработкой - обширный пласт ПО (OpenPBS, PBSPro, LSF, PGICDK, Sun Grid Engine, Condor, TORQUE), предназначенный для запуска на кластере нескольких параллельных программ одновременно и дающий возможность запускать новые по мере освобождения ресурсов. Некоторые системы полностью автоматизируют процесс распределения заданий, например Condor High-Throughput Computing System использует для этого объектную технологию ClassAds, которая работает подобно газетному рекламному классификатору. Системы LSF, OpenPBS, Condor, SGE хорошо подходят для вычислительно емких и больших по объему данных приложений и разработаны для сложных, масштабных и высокопроизводительных систем. Для обучения же можно ограничиться более простой и удобной системой управления кластером, наподобие SLURM (Simple Linux Utility for Resource Management) [15].
Отдельной задачей при обучении параллельному программированию на кластере является анализ поведения параллельных программ в зависимости от наличия вычислительных ресурсов и реализаций различных моделей параллелизма. Среди наиболее известных средств, позволяющих анализировать поведение параллельных программ с целью улучшения их производительности, можно выделить AIMS, VampirTrace, Jump-
shot, Paradyn. Для сбора информации в исследуемую программу встраиваются специальные вызовы, фиксирующие наступление определенных событий или продолжительность интервалов. Полученная информация фиксируется в журнале трассировки. Пакет Jumpshot распространяется вместе с пакетом MPICH и работает на поддерживаемых этим пакетом платформах.
Причин низкой эффективности параллельной программы может быть много - не хватает оперативной памяти, малая производительность коммуникационной сети, неудачное распараллеливание и другие. Для эффективного использования кластера необходимо предоставить пользователям возможность анализа эффективности параллельных программ на кластере, с тем чтобы они могли оптимизировать свои программы под конкретную вычислительную систему. Как правило, системы управления кластером предоставляют свои собственные инструменты для сбора информации о ходе выполнения параллельной программы на кластере. Но независимые средства мониторинга (Ganglia, Cacti, Nagios, Hyperic) предоставляют более разнообразный набор данных и различные механизмы взаимодействия для получения информации об использовании вычислительных ресурсов.
Для удовлетворения всех этих требований при ограниченности аппаратных возможностей в лаборатории целесообразно использовать технологию виртуализации. С ее помощью можно эмулировать различные платформы для поддержки разнообразных библиотек и стандартов параллельного программирования, обеспечивать достаточный уровень безопасности, увеличивать число виртуальных машин для создания более масштабного кластера, чем тот, который может быть построен с использованием только аппаратных средств лаборатории.
Технология виртуализации уже используется в ряде учебных курсов по администрированию операционных систем: каждый пользователь запускает собственную виртуальную машину и, соответственно, настраивает собственную копию изучаемой операционной системы. Ее образ хранится в домашнем каталоге. Из-за структуры лаборатории редактирование конфигурационных файлов непосредственно на рабочих компьютерах затруднено, так как один системный блок обеспечивает три рабочих места. Для этого курса требуется давать пользователю права администратора операционной систе-
мы, что небезопасно из-за ошибок в выполнении работы, которые могут привести к временной неработоспособности сразу трех рабочих мест. Для исправления такой ситуации необходимо перезагрузить компьютер (из-за использования PXE и LTSP), однако, несмотря на это неудобство, использование виртуальной машины все равно предпочтительней, так как при наличии прав администратора к рабочему компьютеру пользователь может получить доступ к любому из них, кроме сервера. То есть в лабораторных практикумах, где требуется, виртуализацию можно применить, если необходимо использовать программное обеспечение для других операционных систем. Например, возможно использование Windows в качестве гостевой ОС в виртуальных машинах, например в Openbox или VMWare.
Из-за ограничений, связанных с мощностью компьютеров, потреблением ресурсов виртуальной машиной и числом рабочих мест на один компьютер, следует, если это возможно, использовать виртуализацию уровня ОС, например OpenVZ [16], базирующуюся на ядре Linux (гостевая система -только Linux). Виртуализация на уровне операционной системы (в OpenVZ) дает лучшую производительность, масштабируемость, плотность размещения, динамическое управление ресурсами, а также легкость в администрировании. Падение производительности составляет от 1 до 3 процентов. Также следует минимизировать число виртуальных машин, запущенных на одном компьютере. При использовании особо требовательной к ресурсам компьютера виртуальной машины можно запускать ее на сервере или выделенном специально для нее мощном компьютере, а доступ к ней осуществлять по локальной сети.
Особенность нагрузки на учебный кластер состоит в неравномерности ее распределения во времени. Пик нагрузки приходится на время проведения лабораторных работ, в которых используются его вычислительные ресурсы. Поэтому для исключения возможной перегрузки кластера пользовательскими задачами, необходимо организовать очередь (например, через SLURM).
Взаимное влияние кластера и другого, не требующего кластерной архитектуры, программного обеспечения в лаборатории трудно оценить без проведения специальных экспериментов, однако влияние на приложения пользователя менее критично, так как необходимым условием является его успеш-
ное выполнение (если оно не связано с получением каких-либо временных интервалов). В случае с работой кластера, особенно при изучении времени выполнения параллельных программ, использование компьютеров лаборатории другим приложением может привести к получению недостоверных результатов. Поэтому в отсутствие экспериментальных данных временным решением может быть ограничение работы кластера при составлении расписания. Можно также предусмотреть механизмы, запрещающие запуск не относящихся к кластеру приложений различными путями, например разрешением входа во время работы кластера только определенным группам пользователей и др.
Так как Linux - многопользовательская операционная система, удаленный доступ к серверу учебной лаборатории могут получить все пользователи, зарегистрированные в системе. Доступ к кластеру, организованному в лаборатории, осуществляется через стандартные средства (ssh) используемой операционной системы и ничем не отличается от использования кластера непосредственно из лаборатории. Для удобства можно использовать специальную программу с интерфейсом, хранящуюся в домашнем каталоге пользователя (который доступен сразу при входе в систему).
Обеспечение коллективного доступа к внешнему оборудованию
Подготовка специалистов по специальности 230101 «Вычислительные машины, комплексы, системы и сети» требует организации лабораторных практикумов, связанных с изучением уникального дорогостоящего оборудования. Причем необходим сетевой доступ (оборудование может находиться в другом помещении), а с другой стороны - коллективный доступ, так как к оборудованию в каждый момент времени может обращаться несколько пользователей (студенческая группа при выполнении лабораторного практикума). Особенно актуальной такая задача становится в связи с развитием в последнее время различных дистанционных форм обучения, при реализации которых студентам на рабочем месте обычно доступен только компьютер с выходом в Интернет [1, 2]. Таким образом, задача удаленного коллективного доступа к уникальному оборудованию актуальна и имеет важное практическое значение. Для ее реализации на кафедре «Компьютерные системы и
технологии» НИЯУ МИФИ в универсальной учебной лаборатории разработана специальная клиент/серверная система [5-7].
В данной реализации уникальное оборудование - многопроцессорная вычислительная плата SMT320 на основе четырех модулей сигнальных процессоров фирмы Texas Instruments TMS320С40. Студентам в рамках лабораторного практикума требуется в интерактивном режиме подготавливать небольшие параллельные задачи для их выполнения на многопроцессорной системе.
Рассмотрим решения, положенные в основу серверной части системы. Данная система представляет собой систему массового обслуживания, следовательно, основное внимание необходимо обратить на организацию очередей заявок. Также немаловажную роль играют вопросы взаимодействия между собой основных модулей системы.
В нашем случае удобно ввести двухприоритетную систему заявок, так как источником заявок могут являться два типа пользователей: обучаемые и преподаватели. Большинство заявок имеют обычный приоритет. В особых случаях некоторые заявки будут иметь высокий приоритет. Например, преподавателю необходимо для проверки правильности функционирования уникального оборудования запустить некоторый тестовый пример. Такого рода заявки будут получать высокий приоритет. Для организации такой схемы обслуживания достаточно одной очереди заявок. Вновь поступающие заявки обычного приоритета помещаются в конец очереди, а высокого приоритета - в начало. Обслуживание заявок всегда происходит из начала очереди. Таким образом, заявки высокого приоритета будут первыми получать право обслуживания.
Итак, в нашей системе существует одна очередь заявок. Обслуживание происходит по дисциплине FIFO. Поступление заявок в зависимости от их приоритета может происходить как с конца, так и с начала очереди. Данный способ организации очереди представлен на рис. l.
Рассмотрим теперь структурную схему серверной части. Ее вид представлен на рис.
2.
Существует главный процесс, управляющий работой всей системы. На него возложена обязанность: в начальный момент запустить процесс, реализующий обработку заданий, который, в свою очередь, автоматически организует обработку очереди.
Также главный процесс отвечает за запуск интерфейсных процессов в ответ на каждое входящее сетевое соединение.
Клиентская часть системы реализована с использованием модульного подхода. Для выполнения каждой элементарной операции, требующей сетевого обращения к серверу, существует отдельный модуль-утилита. Та-
кой подход имеет ряд преимуществ. Во-первых, достаточно простые утилиты, выполняющие ограниченные действия, легче разрабатывать и тестировать. С другой стороны, такие утилиты не требуют мощных вычислительных ресурсов, что позволяет иметь недорогие клиентские рабочие места.
Заявка всегда извлекается из начала очереди, для нескольких заявок с высоким приоритетом действует закон обслуживания в порядке, обратном поступлению Рис. 1. Организация двухприоритетной очереди заявок
Рассмотрим этот подход еще под одним углом зрения. Если клиентское рабочее место будет оснащено более мощными ресурсами,
Рис. 2. Структурная схема серверной части системы коллективного дистанционного доступа
позволяющими работать с графическими средствами, то не возникнет необходимости в повторной разработке новой графической версии клиентских программных средств. Для эксплуатации клиентского программно-
го обеспечения в новых условиях будет достаточно разработать графическую оболочку, обеспечивающую пользовательский интерфейс, соответствующий новым возможностям, а функциональное наполнение этой системы будет обеспечиваться вызовом тех же самых модулей-утилит. Наращивание возможностей клиента можно проводить путем разработки новых модулей-утилит, реализующих требуемые действия.
Существует другой способ реализации взаимодействия с сервером - на основе распространенного опыта организации систем сетевого коллективного доступа к вычислительным ресурсам. Этот способ используется в вычислительном портале, описанном в [3, 4]. Как известно, в настоящее время наиболее часто при работе в Интернете пользуются браузерами, которые осуществляют получение информации от серверов Интернета при помощи стандартных протоколов. Поэтому возможно в качестве клиентского программного обеспечения использовать стандартный браузер. Причем возможно использование браузера наравне с клиентским программным обеспечением, рассмотренным выше. То есть с одним и тем же сервером одновременно часть клиентских машин могут осуществлять взаимодействие при помощи клиентского программного обеспечения, описанного выше, а другая часть -при помощи стандартного браузера.
Выводы
Описанная выше версия универсальной лаборатории в настоящее время является
базой для проведения лабораторных практикумов на кафедре «Компьютерные системы и технологии» НИЯУ МИФИ по большинству учебных дисциплин рабочего учебного плана по направлению подготовки бакалавров и магистров 230100. Трехлетняя эксплуатация лаборатории показала справедливость основных решений, положенных в основу проекта. Главными достоинствами предложенных решений, по мнению авторов, следует считать возможность быстрого развертывания такой лаборатории с исполь-
Литература
зованием широкодоступных и недорогих компонентов аппаратуры и свободно распространяемого программного обеспечения, практически неограниченную масштабируемость и относительно простое администрирование, что обеспечивает в основном потребности лабораторной поддержки учебного процесса по направлению 230100. При некоторых доработках проект может служить прототипом для создания подобных систем в учебных заведениях.
1. Забродин Л. Д., Чернышев Ю. А. Методология дистанционного обучения компьютерным наукам // Научная сессия МИФИ - 2000: Сборник научных трудов. - М.: МИФИ, 2000. Т. 10. С. 18-20.
2. Забродин Л. Д., Чуканов В. О. Дистанционное обучение на кафедре «Компьютерные системы и технологии» МИФИ // Научная сессия МИФИ - 2001: Сборник научных трудов. - М.: МИФИ, 2001. Т. 12. С. 102-103.
3. Прохоров В. В. Вычислительный портал: Средства удаленного доступа к ресурсам суперкомпьютеров // Высокопроизводительные вычисления и их приложения: Труды всероссийской научной конференции. - Черноголовка, 2000. С. 161-164.
4. Прохоров В. В. Технология использования вычислительных ресурсов в Интернете на основе вычислительных прокси-серверов // Алгоритмы и программные средства параллельных вычислений. Вып. 2. - Екатеринбург: УрО РАН, 1998. С. 256-267.
5. Вавренюк А. Б., Забродин Л. Д., Макаров В. В., Чепин Е. В. Сетевой доступ к многопроцессорной системе // Научная сессия МИФИ - 2000: Сборник научных трудов. - М.: МИФИ, 2000. Т. 10. С. 86-87.
6. Вавренюк А. Б., Забродин Л. Д., Макаров В. В., Никитин А. Н., Чепин Е. В. Удаленный коллективный доступ к многопроцессорной системе // Высокопроизводительные вычисления и их приложения: Труды всероссийской научной конференции. - Черноголовка, 2000. С. 72-73.
7. Вавренюк А. Б., Забродин Л. Д., Макаров В. В., Никитин А. Н., Чепин Е. В. Удаленный коллективный доступ к уникальным вычислительным ресурсам // Научная сессия МИФИ - 2001: Сборник научных трудов. - М.: МИФИ, 2001. Т. 12. С. 116-117.
8. DVM-система. Институт прикладной математики им. М. В. Келдыша. -http://www.keldysh.ru/dvm/dvmhtm1107/rus/index.html (дата обращения: 11.05.2011).
9. Condor High Throughput Computing. - http://www.cs.wisc.edu/condor (дата обращения: 11.05.2011).
10.0penPBS Public Home. - http://www.mcs.anl.gov/research/projects/openpbs/ (дата обращения:
11.05.2011).
11.Message Passing Interface Forum. - http://www.mpi-forum.org/ (дата обращения: 16.04.2011).
12.The OpenMP API specifications for parallel programming. - http://openmp.org/wp/ (дата обращения:
16.04.2011).
13.Парошина И. Высокопроизводительные вычисления и кластерные системы. Обзор и сравнение: Globus Toolkit, Unicore, gLite. - http://www.ibm.com/developerworks/ru/library/l-paroshina_toolkits/index.html?S_TACT=105AGX99&S_CMP=GR01 (дата обращения: 23.05.2011).
14.Горобец А. В., Суков С. А. Двухуровневое MPI + OpenMP распараллеливание алгоритма для расчетов газовой динамики и аэроакустики на тысячах процессов суперкомпьютера. -
http://agora.guru.ru/abrau2010/pdf/63.pdf (дата обращения: 16.04.2011).
15.SLURM: Highly Scalable Resource manager. - https://computing.llnl.gov/linux/slurm/ (дата обращения: 1.06.2011).
16.0penVZ Wiki. - http://wiki.openvz.org/Main_Page (дата обращения: 9.05.2011).
Открыта подписка на журнал «Открытое образование»
5*71
ПРЕСС
У^гмд
Санкт-Петербург
Я*
бибком АГЕНТСТВО
И«де«с 10574
«РОСПЕЧАТЬ»
нндтс 4720Э
Источник. JOE (http://www.e-joe.ru/)
