Опыт коллективного использования масс-параллельных ЭВМ

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

Институт математики и механики УрО РАН, Екатеринбург

Введение

При реализации коллективного доступа к вычислительным ресурсам комплекс аппаратных, программных и организационных решений в значительной мере обуславливается количественными и качественными характеристиками имеющегося потока задач. Технология пропуска задач в свою очередь может влиять на круг пользователей. Здесь исключительно важно обеспечить адекватность принятых проектных или реализационных решений существующим потребностям и сложившимся привычкам использования вычислительной техники. При организации коллективного доступа к МВС-100 в ИММ УрО РАН были учтены большой опыт эксплуатации универсальных ЭВМ, специфика самого МВС с точки зрения аппаратуры, а также исследовательский характер основного потока задач.

Реализация коллективного использования МВС

Уникальность аппаратной части МВС-100 [3] обуславливает необходимость распределения цикла разработки программ между МВС и совокупностью рабочих станций, в частности, очень важно обеспечить возможность предварительной отладки на PC пользователя. Для решения проблемы была создана технология кросс-отладки программ для МВС, а в качестве отладочных могут выступать и специально выделенные для этой цели машины (в ИММ это две рабочие станции с процессорами Alpha-21164/533). Перенос отладки с МВС-100 значительно повысил как эффективность процесса отладки, так и продуктивность использования МВС [2]. Однако полностью исключить отладочные задачи из потока к МВС-100 не удалось, в силу значительных отличий платформ.

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

Для программного регулирования доступа к МВС-100 и сближения интересов разных групп пользователей в ИММ была разработана технология коллективного доступа, которая с самого начала была ориентирована на обеспечение равных возможностей для всех пользователей путем выбора разумных ограничений и поддержки очереди задач с предварительным заказом ресурсов [1].

При коллективном доступе довольно естественно ограничивать продолжительность захвата ресурса для одного пользователя, а также требовать указания предположительной длительности работы, так как это позволяет другим спланировать свои действия. Однако просто ограничение длительности счета, хотя оно и увеличивает частоту освобождения ресурсов и в какой-то мере открывает возможность отладки на МВС-100, не снимает проблему полностью, так как один пользователь, поставив в очередь сразу несколько своих задач, не даст считать другим. Было принято решение лимитировать и суммарное время, которое выдается конкретному пользователю на сутки. Если его задача выходит за эти рамки, то она считается низкоприоритетной и будет запускаться позже всех высокоприоритетных. Наш опыт эксплуатации универсальных ЭВМ показывает, что введение жестких мер, когда при исчерпании бюджета задачи откладываются вне зависимости от загрузки, приводит к длительным простоям. И хотя в нашей системе такое ограничение также предусмотрено, оно практически не используется.

Очевидно, что набор дневных и ночных ограничений должен отличаться. Мы пошли дальше и создали файл с расписанием ограничений на целый год. Чтобы упростить администрирование, была предусмотрена возможность задавать расписание для групп дней. Группировать можно по месяцу, числу или дню недели, можно задать расписание для конкретной даты, наконец, для обычных дней - особая группа. Так, при большом количестве задач с длительным счетом целесообразно включать ночной режим в субботу и воскресенье раньше, чем в обычные дни (как это и делается в ИММ). Для ИММ актуально также выделение днем часов для отладки, когда уменьшен максимально допустимый заказ времени и установлен более жесткий лимит на суммарное время задач одного пользователя.

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

Использование электронной почты для доступа к МВС

Говорят, что все новое - это хорошо забытое старое. Несколько лет назад электронная почта активно использовалась для доступа к разнообразным ресурсам Интернет, таким как news, ftp, базы данных и даже для доступа к WWW. Справочники для начинающих содержали адреса десятков и сотен почтовых шлюзов. C развитием скоростных линий коммуникаций подобный способ доступа утратил былую популярность. Более того, даже почтовые клиенты все чаще реализуются на основе доступа через WWW. Однако и при нынешнем уровне развития Интернет, электронная почта остается мощным и удобным средством коммуникации.

При организации удаленного доступа к МВС-100 из подразделений УрО РАН, было выяснено, что быстрота современных линий связи понятие относительное. Скорости, приемлемые для просмотра WWW-страниц и пересылки небольших файлов, оказались недостаточны для организации интерактивных сеансов связи. Более того, интерактивный способ доступа оказывается утомительным для человека даже на действительно скоростных линиях, когда возрастают объемы данных и соответственно время ожидания элементарного копирования. Типичный сценарий работы пользователя заключается в циклическом повторении следующих действий.

Передача кода программы и данных на МВС-100 (от нескольких минут до нескольких часов).
Ввод команды на исполнение (одна‑две минуты).
Периодическая проверка завершения программы (в течение нескольких часов).
Передача результатов работы с МВС-100 (см. передачу на МВС-100).

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

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

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

При практической реализации была выбрана следующая схема взаимодействия.

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

Данная схема имеет два недостатка, признанных на данный момент несущественными. Как правило, существуют ограничения на максимальный размер письма, и, в тоже время, не существует стандарта разбиения больших файлов на несколько писем. Задача разбиения и последующей сборки полностью возложена на пользователя. Одним из способов может быть упаковка данных в многотомные архивы с помощью архиваторов RAR или ARJ. Вторая проблема заключается в том, что часть клиентских программ не позволяет подписать присоединенные к письму файлы. Однако даже подпись тела письма позволяет достичь удовлетворительной степени идентификации пользователя и даёт достаточно информации для расследования возможных инцидентов, связанных с несанкционированным доступом.

В качестве клиентской части может быть использована любая почтовая программа, поддерживающая совместное использование с популярным пакетом шифрования PGP версий 2.6-5.5. Выбор таких почтовых программ для различных платформ достаточно широк. Под Win32 можно использовать Microsoft Outlook Express, в сочетании с PGP Plugin, The Bat фирмы RIT Lab или Pegasus Mail. На UNIX платформах с PGP можно интегрировать стандартную программу mail, или использовать распространенную программу Pine. Естественно необходим и сам пакет PGP.

Серверная часть системы реализована на языке Perl, и предназначена для выполнения в UNIX-подобных ОС. На настоящий момент описанная выше система доведена до уровня опытной эксплуатации и протестирована в ОС Linux, но, судя по всему, может быть без проблем перенесена и в другие операционные системы, например, Digital UNIX.

Заключение

Опыт эксплуатации МВС-100 в ИММ показал, что режим коллективного использования позволяет комфортно работать с МВС при загрузке 15-20%. (За 100% принимается круглосуточная загрузка всех процессоров.) Удалось наладить обучение студентов и аспирантов принципам организации параллельных вычислений и методике использования МВС для решения научных задач, в том числе и в режиме удалённого доступа через Интернет. Работы по интеграции МВС-1000 в систему коллективного использования предполагается вести на основе понятия "обобщённый ресурс".

Модификация ядра Linux'а выполнялась студентом УрГУ С.В. Коганом, а реализация доступа к МВС по электронной почте была осуществлена Н.Н. Шамгуновым (также студентом УрГУ).

ЛИТЕРАТУРА

1. А.С. Игумнов, А.В. Коновалов, В.В. Самофалов, С.В. Шарф Развитие и адаптация системного программного обеспечения МВС-100 // Алгоритмы и программные средства параллельных вычислений: Сб. науч. тр. Екатеринбург: УрО РАН. 1998. Вып. 2. С. 123-133.

2. В.В. Самофалов, А.В. Коновалов Технология отладки программ для машин с массовым параллелизмом // "Вопросы атомной науки и техники". Сер. Математическое моделирование физических процессов. 1996. Вып. 4. С. 52-56.

3. А.V. Zabrodin, V.K. Levin, V.V. Korneev The Massively Parallel Computer System MBC-100 // Parallel Computing Technologies, Proceeding, 1995. LNCS 964. (1995), p. 341-355