Технологии высокопроизводительных вычислений

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

Реализационные принципы, позволяющие эту функциональность обеспечить, весьма просты:

- пассивность узла относительно процесса управления ресурсами. Вся работа по управлению процессорным ресурсом сосредоточена в управляющей машине. На узле нет никаких специальных активных компонентов – серверов, демонов или модулей ядра – которые были бы специально разработаны для взаимодействия с управляющей машиной или для специфического отслеживания действий программы пользователя. Все управление осуществляется командами rsh или ssh, которые выдаются от имени root’а с управляющей машины,

- выборочное разрешение доступа пользователей только на те узлы, которые им выделены, с последующим запретом при освобождении узла,

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

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

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

Система управления процессорным ресурсом прозрачна относительно конкретной используемой системы параллельного программирования. Она не настроена жестко на какую-либо конкретную реализацию MPI (и вообще именно на MPI).

В качестве дополнительной возможности в систему управления может включаться управление еще одним ресурсом – локальной дисковой памятью (ЛДП). Мы уже говорили о том, что общая файловая система кластера – одно из важнейших «узких мест» в системе. Альтернативой могло бы быть использование локальных дисков вычислительных узлов, но для этого необходимо обеспечить возможность повторного попадания задачи, использующей локальные диски, именно на те узлы, на которых она считалась в прошлый раз. Также необходимо правильно настроить квотирование пространства на этих дисках, внести изменения в алгоритмы планирования очереди и т. п. Система управления ЛДП все это умеет. Она может включаться или не включаться в систему управления конкретным кластером и, конечно, ее действие распространяется только на те задачи, которые явно запрашивают ее услуги.

5.2. Как работает и зачем нужен метакластер МВС – 900.

Важнейшая проблема практического применения вычислительных кластеров – проблема первоначального освоения технологии [1,12]. Ее часто ошибочно отождествляют с проблемой обучения параллельному программированию. В действительности практическое освоение вычислительного кластера, внедрение его в реально существующую производственную обстановку – сложнейшая комплексная инженерно – психологическая задача. Типичный новый пользователь вычислительного кластера – вовсе не программист – профессионал, а специалист по инженерным расчетам в своей предметной области. Даже применение традиционного программирования его тяготит, и не является, с его точки зрения, содержательной деятельностью, к которой следует стремиться, которую следует осваивать и изучать. Компьютер – неизбежное зло. К нему следует привыкнуть и приспособиться, если уж без этого никак не обойтись. Да, было бы хорошо, чтобы он считал раз в 20 или 200 побыстрее, но не настолько же хорошо, чтобы отвлекаться от проектирования турбин, реакторов или новых лекарств ради освоения всех этих Линуксов, серверов и демонов. Рассказ о новом, прекрасном с точки зрения разработчика суперкомпьютеров, программном обеспечении воспринимается, в лучшем случае, со снисходительной улыбкой занятого взрослого, общающегося с заигравшимся, увлеченным ребенком. Удастся ли действительно прорваться сквозь этот детский лепет? Стоит ли это делать, поможет ли это лучше завершить расчеты к концу отчетного квартала? Надо попробовать. Но попробовать на практике, а не на бумаге. Получится – будем искать деньги на покупку этой чудо – техники. А на чем пробовать, если самой техники еще нет? Порочный круг. Для его разрыва нужна техника, удовлетворяющая следующим требованиям:

- «портретное» сходство с настоящим, «железным» вычислительным кластером при работе на нем. Не «сходство в принципе», которое дает программное обеспечение кластеров невыделенных рабочих станций, вроде MPICH для Windows, а именно полное совпадение интерфейсов. Мы – люди серьезные, «в принципе» нам не подходит – как известно, «работать должно не в принципе, а в корпусе»,

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

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

Портретное сходство в сочетании с нулевой ценой способна дать программная модель суперкомпьютера (симулятор). Скоростной выигрыш способен дать MPICH для Windows, но ни портретного сходства, ни нулевой цены эксплуатации он не даст.

Метакластер МВС – 900 [1,13] способен удовлетворить все три указанных требования.

Устроен он следующим образом. На выделенном наборе машин под управлением Windows, объединенном локальной сетью, устанавливается (на каждой машине) программное обеспечение VMWare [14]. Под его управлением в каждой из реальных машин создается функционирующая в фоновом режиме виртуальная машина. На каждой из таких виртуальных машин устанавливается Linux, а на получившийся Linux – кластер устанавливается программное обеспечение МВС – 1000 (отсюда название: 900 – это почти 1000).

В реализации этой идеи присутствуют две трудности:

- как обеспечить нулевую цену эксплуатации, то есть сделать систему администрируемой отдельно от Windows – класса, на оборудовании которого она установлена?

- будет ли, и за счет чего, достигнут реальный скоростной выигрыш от параллельного выполнения программ?

Первая проблема решается написанием совсем несложных скриптов, запускающих виртуальную машину в фоновом режиме как сервис, автоматически, при старте Windows. При этом в конфигурации виртуальной машины режим виртуализации жесткого диска для узлов (но не хоста!) выбирается “Independent, non-persistent”, что позволяет прерывать работу узла на ходу, не выполняя всякий раз “shutdown”. При этом узел в процессе работы обладает полноценным жестким диском, но при старте «не помнит» прошлых изменений – состояние жесткого диска узла при включении всегда эталонное и правильное. Следовательно, узлы дополнительной нагрузки на администратора «несущей» нашу систему Windows – сети не создают.

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

Эта совокупность мер позволяет говорить о раздельном администрировании физической и виртуальной сетей, что и требовалось. Администрирование МВС – 900 из дополнительной нагрузки на штатного администратора становится плановой учебной задачей будущего администратора будущего вычислительного кластера, то есть совершенно закономерной частью «пробования, получится ли освоить эту технику».

Вторая проблема – откуда возьмется скоростной выигрыш? Чтобы ответить на этот вопрос, надо вспомнить, что такое виртуальная машина (в узком терминологическом смысле VMWare и подобных систем). Эмулятор? Но эмуляция процессором собственной системы команд, как известно, приводит к примерно 100-кратному замедлению в выполнении кода. До выигрыша ли тут? А если это не эмулятор, то как она вообще работает? Что происходит при выполнении процессором – не при эмуляции, а именно при честном выполнении – команды обращения к жесткому диску, сетевому адаптеру или ячейке памяти, которых нет в действительности, поскольку они – виртуальны?

Выше, в Разделе 2, мы довольно подробно обсуждали этот и смежные с ним вопросы. Там же давалось определение виртуальной машины (в общем смысле этого термина), объяснялся механизм работы виртуальной памяти и специальных «виртуальных» команд – системных запросов. Смысл всей техники виртуализации – в том, что подавляющее большинство команд процессор выполняет напрямую, без всякой программной эмуляции, а переход от прямого выполнения кода к программной эмуляции той или иной виртуальной сущности происходит по прерыванию. В случае виртуальной памяти – это прерывание «аварийное», а в случае обращения к ОС за услугой – запланированное, программное. В результате мы получаем виртуальную машину, отличающуюся по системе команд и набору внешних устройств от реальной. Чтобы получить то, что мы видим, наблюдая за работой виртуальной машины под управлением VMWare, нам достаточно распространить технику виртуализации памяти на виртуализацию системных запросов. Еще раз – что происходит, когда ядро Linux на виртуальной машине обращается к несуществующему адаптеру жесткого диска? Прерывание. Аварийное. Заменим обработчик такого вида аварий в ОС несущей машины на программный эмулятор виртуального адаптера жесткого диска – и задача решена. Именно так работает VMWare. В выполняющейся под управлением VMWare виртуальной машине прерывания от команд обращения к несуществующему (виртуальному) оборудованию просто выполняют функцию системных запросов. В итоге получаем частный случай виртуальной машины, или виртуальную машину в узком смысле этого термина. А именно – виртуальную машину, которая совпадает с физической машиной по системе команд, но отличается от нее набором внешних устройств.

Что можно сказать о быстродействии такой виртуальной машины по сравнению с физической? Падение производительности вычислительной работы, при которой ничего не эмулируется (прерываний почти нет), практически отсутствует – оно не больше, чем накладной расход на выполнение программы под управлением Linux или Windows по сравнению с выполнением на «голом» процессоре, то есть пренебрежимо мало. Это дает надежду на получение реального скоростного выигрыша от параллельного выполнения программ. Будет ли он столь же весомым, как и на «железном» кластере – при условии, конечно, что несущие нашу систему физические машины не заняты в данный момент собственной вычислительной работой?

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

Наконец, итоговое замечание о названии предложенной технологии. Слово «метакластер», казалось бы, претендует на принадлежность МВС – 900 к области метакомпьютинга [3]. Что дает нам основания для такой претензии? Техническое назначение системы. МВС – 900 можно рассматривать как вариант дисциплины отбора вычислительной мощности с вычислительной установки, изначально для этого не предназначенной. Это и есть одна из постановок задачи метакомпьютинга. Ничто не мешает применять МВС – 900, в некоторых случаях, не только для первоначального освоения технологий параллельной обработки данных, но и как систему отбора мощности, на постоянной основе.

6. Модели и технологии параллельного программирования.

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

Технологией параллельного программирования называется конкретное программное воплощение модели, например: «технология программирования при помощи библиотеки MPI (или PVM)».

Одна модель может быть представлена несколькими технологиями.

В этом разделе мы не ставим задачи систематического описания технологий параллельного программирования. Технология MPI изучалась в курсе Параллельных и распределенных вычислений, прочие упоминаемые ниже технологии могут быть, при необходимости, изучены по сетевым источникам. Задача настоящего раздела – дать общий сравнительный анализ основных концепций разных моделей и технологий, и не более того.

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

Для демонстрации верности этого утверждения достаточно сопоставить всего несколько чисел.

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

За 10 микросекунд (добавим хотя бы один порядок к «идеальной латентности») современный процессор выполняет примерно 10 – 30 тыс. операций. Для того, чтобы выделить фрагмент программы такой длины в качестве независимого куска, не связанного с вычислениями в других процессорах, наш гипотетический распараллеливающий транслятор должен его проанализировать и убедиться в отсутствии зависимостей. Однако в реальной программе, содержащей ввод – вывод, обращение к внешним процедурам и прочую динамику, возможен анализ лишь линейных фрагментов кода. 10 тыс. команд – это примерно 100 – 200 операторов. Такой длины линейных фрагментов в программах не бывает. Демонстрация верности основного постулата завершена.