Главная

Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Основные принципы организации МВС – 1000.


МВС-1000 – это Linux – кластер, определенным образом сконфигурированный [2,15]. Тип процессора и сети могут быть разными.

Общая структура МВС-1000:

- сервер доступа, он же инструментальный сервер,

- управляющая машина,

- вычислительное поле, состоящее из узлов,

- файловый сервер,

- три сети.

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

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

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

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

Три сети – это:

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

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

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

Это также функции, распределение которых по конкретным сетям может быть разным. Это могут быть действительно три сети, или две (сеть коммуникаций выделена), или даже, в небольших кластерах, всего одна сеть.

 

Рис. 6.1. Функциональная структура МВС-1000.

Сеть ввода-вывода охватывает все машины, сеть управления – управляющую машину и узлы, сеть коммуникаций – только узлы. Выход в Интернет имеет только сервер доступа и, возможно, файловый сервер (не показано).

 

Само название «МВС – 1000» относится, прежде всего, к системе управления ресурсами, функционирующей на управляющей машине. В первую очередь речь идет о процессорном ресурсе.

Системы параллельного программирования (обычно на базе MPI) сами по себе ресурсами вычислительной установки не управляют. При запуске параллельной программы в такой системе пользователь сообщает точный список узлов, на которых он бы хотел программу запустить. Сам процесс «разбрасывания» ветвей параллельной программы по узлам происходит при помощи команды rsh или ssh, соответственно, предполагается, что пользователь авторизован на узлах для выполнения этой команды без запроса пароля. Процесс прекращения работы программы вообще практически не поддержан – всегда есть вероятность, что на узлах после аварийного (или просто принудительного) завершения программы останутся «обломки» - процессы, потребляющие память и процессорное время.

Довольно очевидно, что работать так можно (хотя и не без трудностей) лишь на установке, монопольно занятой одним пользователем. Попытка использовать при таких условиях систему в режиме коллективного пользования и удаленного доступа – это гарантированный кошмар. Разные параллельные программы будут пересекаться по используемым узлам, узлы будут постепенно «деградировать» за счет оставшихся на них «обломков» от прошлых запусков и т. п. Доступные системы управления ресурсами, вроде Open PBS [4], решают проблему лишь отчасти: они позволяют вести учет свободных и занятых узлов. Но ведь надо еще проследить, чтобы эта «бухгалтерия» соответствовала действительности. В самом деле, если пользователь всегда авторизован на узле для беспарольного входа, ничто не мешает ему запросить у PBS три узла на час, а занять – 100 узлов на сутки (при этом про оставшиеся 97 узлов PBS будет «думать», что они свободны). По крайней мере, в то время, когда принималось решение о разработке системы управления ресурсами МВС-1000, среди свободно распространяемых систем упраления ресурсами кластеров не удалось найти ни одной, свободной от этого недостатка.

Система управления ресурсами МВС – 1000 была задумана для преодоления трудностей именно такого рода, а в конечном счете – для обеспечения устойчивой эксплуатации кластера в режиме коллективного пользования при удаленном доступе (то есть без каких-либо «договоренностей», кто и когда «возьмет» те или иные узлы).

Функциональные принципы управления процессорным ресурсом таковы:

- единая точка входа. Пользователь «видит» при сетевом доступе только сервер доступа,

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

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

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

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

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

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

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

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

Система управления процессорным ресурсом прозрачна относительно конкретной используемой системы параллельного программирования. Она не настроена жестко на какую-либо конкретную реализацию MPI (и вообще именно на MPI). Все известные и доступные в настоящее время разработчикам МВС-1000 системы параллельного программирования придерживаются единой схемы начальной раскрутки – при помощи беспарольного доступа на узлы командами rsh или ssh. Именно этот механизм и контролируется. Для настройки на конкретную систему параллельного программирования необходимо написать несколько несложных скриптов.

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

 

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

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

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

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

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

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

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

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

 

Рис. 6.2. Метакластер МВС-900. Широкой полосой обозначен выход виртуального хоста во внешнюю сеть для доступа пользователей.

 

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

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

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

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

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

Так, экспериментально установлено и неоднократно проверено, что виртуальная машина под управлением Linux, на которой не выполняется напряженной вычислительной работы, не создает заметной нагрузки на ресурсы физической машины. Узел виртуального кластера может быть постоянно запущен на штатно используемой машине в фоновом режиме – если на виртуальном кластере ничего не считается, физическая машина не будет работать медленнее или ощущать дефицит памяти.

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

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

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

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

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

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

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

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

Программное обеспечение МВС-900 также рекомендуется для целей преподавания.

VMWare является не единственной из доступных сегодня технологий виртуализации. В последнее время популярны такие системы виртуализации, как, например, coLinux или Xen, распространяемые свободно. Много информации на эту тему можно найти в Интернет по двум упомянутым ключевым словам.

 

7. Технологии параллельного программирования и метакомпьютинг.

Тема метакомпьютинга [4], очень популярная в последние годы, не является предметом специального рассмотрения в настоящем курсе. Это – совершенно отдельная, большая и интересная тема, на которую уже написано и еще будет написано очень много. Однако, совсем не затронуть ее мы не можем. Проблемы метакомпьютинга требуют весьма своеобразных решений в областях, которые мы, так или иначе, рассматривали: как в технологиях параллельного программирования, так и, в особенности, в технологиях управления многопроцессорными вычислителями.

 

7.1. Две постановки задачи.

Задача метакомпьютинга в общем виде – это задача построения в рамках Интернет единой, потенциально неограниченной, распределенной вычислительной среды. Как по масштабу, так и по степени ожидаемого влияния на развитие вычислительных технологий, решение этой задачи не имеет прецедентов. Сравнить ее можно, пожалуй, лишь с появлением самой сети Интернет. Продолжая аналогию с историей Интернет (конечно, в чем-то спорную, как и всякая аналогия), можно заметить, что метакомпьютинг находится сейчас в стадии развития, в которой Интернет был в самом начале 80-х годов прошлого столетия. На рубеже 70-х и 80-х годов сетевые технологии еще воспринимались как некоторая «экзотика». Всего несколько лет спустя уже не очень понятно было, как мир обходился до сих пор без Интернет, и для чего вообще может быть нужен компьютер, если не для подключения к Интернет. «Экзотикой» стали казаться все остальные компьютерные технологии. Нечто подобное должно произойти в ближайшие годы (и уже происходит) с технологиями метакомпьютинга. Многое уже достигнуто, еще больших результатов следует ожидать в самом ближайшем будущем, учитывая темп развития этих технологий. Число действующих международных сетей метакомпьютинга уже сейчас измеряется десятками, и быстро растет. На Интернет – портале [4] поддерживается и постоянно обновляется богатый раздел, посвященный технологиям метакомпьютинга, где обо всем этом можно узнать подробнее.

На практическом уровне можно выделить две постановки задачи метакомпьютинга: «узкую» и «широкую».

Под метакомпьютингом в узком смысле этого слова понимается задача объединения территориально удаленных и независимо администрируемых вычислительных установок в единый вычислительный ресурс. Например, несколько суперкомпьютерных центров коллективного пользования могут договориться о создании общей очереди задач, с направлением задач из очереди на выполнение в тот суперкомпьютерный центр, где в настоящее время имеются свободные ресурсы. Или же можно пытаться объединить несколько суперкомпьютеров в единое вычислительное поле для решения особенно крупных задач. На решение преимущественно этой задачи ориентировано, в частности, такое программное обеспечение из области технологий Grid, как программный комплекс Globus [4,40] – пожалуй, самой популярной в настоящее время технологии метакомпьютинга.

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

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

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

7.2.Метакомпьютинг выделенных мощностей. Пример технологии.

Главная техническая проблема метакомпьютинга выделенных мощностей – это, конечно же, недостаток производительности коммуникационного канала, связывающего между собой части системы. Проблема эта стоит очень остро даже в том случае, когда территориально удаленные части системы не используются для организации единого вычислительного поля. Например, пусть имеется всего лишь общая очередь задач, каждая из которых, по мере освобождения соответствующих ресурсов, направляется целиком на один из суперкомпьютеров комплекса, но заранее не известно, на какой именно. Этой задаче, очевидно, потребуются какие-то исходные данные, а также место для записи результатов расчета. Файловый ввод-вывод зачастую является узким местом даже для классических, территориально сосредоточенных, кластеров. В случае же, когда между вычислительным полем и хранилищем данных, которые на нем обрабатываются, «внезапно» возникает спутниковый или другой канал, более узкий, нежели канал доступа к собственному файловому серверу, проблема рискует стать неразрешимой. Задачи, в которых объем обмена данными с файловой системой особенно велик, в рамках этих технологий не решаются. Эта же проблема недостаточной производительности канала между составляющими комплекс суперкомпьютерами встает в случае, когда делается попытка организовать из узлов нескольких суперкомпьютеров единое вычислительное поле. При этом добавляется еще и проблема латентности – все высокоскоростные магистральные каналы передачи данных обладают очень высокой (по сравнению с собственной производительностью) латентностью. Обычно программистам, пишущим программы для таких комплексов, приходится явно учитывать в структуре программы тот факт, что общее (формально) поле вычислительных узлов разбито в действительности на несколько сравнительно слабо связанных между собой подмножеств.

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

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

Как мы знаем, помимо реализаций MPI на базе протоколов tcp/ip, существуют реализации MPI на базе специализированных, нестандартных протоколов, присущих тем или иным высокоскоростным сетям. Например, MPI для Myrinet, или MPI для Infiniband. Высокая эффективность этих реализаций именно тем и достигается, что построены эти реализации не на базе tcp/ip. Почти наверняка объединяемые в метакомпьютер установки оснащены именно такими реализациями MPI, и естественно полагать, что реализации эти разные. Например, одна из объединяемых машин построена на базе Myrinet, а вторая – на базе Infiniband. Объединяющий их Internet – канал, вероятно, спутниковый, поддерживает tcp/ip.

 

Рис. 7.1. Разнородный метакомпьютер.

 

Проще всего было бы использовать на объединенной установке MPI на базе tcp/ip, но это привело бы к падению эффективности коммуникаций в пределах каждой из объединяемых установок. Хотелось бы построить такую реализацию MPI, чтобы в пределах каждой из объединяемых установок сообщения пересылались по «внутренним» протоколам, а между установками – по tcp/ip. Принципиально ничего невозможного в этом нет, но технически за такую реализацию вряд ли кто возьмется – слишком уж велико число возможных сочетаний из разных сетей. А вдруг к метакомпьютеру решено будет присоединить еще и машину на базе Quadrics?

Для удовлетворительного решения этой задачи необходимо научиться «вживлять» в работу функций уже существующей реализации MPI некоторые дополнительные действия, например, проверку, по Myrinet отправлять сообщение, или же по tcp/ip, но при этом не транслировать заново ни саму библиотеку MPI, ни вызывающую программу.

Исторически эта проблема встала перед разработчиками MPI впервые в связи с необходимостью добавлять к имеющимся реализациям MPI средства профилирования и отладки. Хотелось бы иметь возможность создать «обертку» для каждой функции MPI, которая работает так:

- принимает все аргументы данной функции,

- делает нечто (например, засекает время),

- вызывает данную функцию,

- делает еще что – то, например, еще раз засекает время, вычисляет время работы функции и что – то с ним делает,

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

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

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

Решение этой проблемы, являющееся частью стандарта MPI, основывается на так называемых «слабых символах (weak symbols)» - некогда дополнительной, а сегодня – практически обязательной возможности транслятора C и компоновщика (линкера).

От транслятора требуется наличие директивы #pragma weak, позволяющей снабдить имя функции синонимом, объявив его «слабым». Например, функция может иметь основное имя “abc” и слабый синоним “def”, обозначающие одну и ту же точку входа в функцию. Реализация такой возможности ничего не стоит разработчику транслятора, поскольку на уровне формата объектного модуля этот аппарат всегда был. Например, на языке ассемблера любая функция может иметь как угодно много равноправных названий. На Фортране запись синонимов, кстати, также допускается. Мы, впрочем, хотим, чтобы каждый из синонимов не просто обозначал одну и ту же функцию, но и имел дополнительный атрибут – признак «слабости».

Для вызывающей программы наличие синонима означает, что функцию можно с равным успехом вызвать и как “abc(…)”, и как “def(…)”, причем работать будет в обоих случаях один и тот же код.

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

В стандарт MPI входит так называемый интерфейс профилирования. Он состоит в том, что каждая из функций MPI имеет свое каноническое имя в качестве слабого синонима, и имя, полученное приписыванием перед каноническим именем буквы “P”, в качестве основного имени. Так, функция MPI_Send «в действительности» называется PMPI_Send, а “MPI_Send” – лишь слабый синоним ее основного имени.

Пусть теперь мы хотим вставить «обертку» между прикладной программой и библиотекой MPI, не транслируя заново ни программу, ни библиотеку. В программе все функции MPI вызваны по «слабому» варианту, без “P”. Мы же написали, например, для MPI_Send «обертку» такого вида:

int MPI_Send( ……. )

{

…………….

rc = PMPI_Send( ……. );

…………….

return rc;

}

Если мы укажем в командной строке линкера объектный модуль нашей обертки до библиотеки MPI, то наш вариант MPI_Send скомпонуется вместо библиотечного. Он вызовет PMPI_Send уже из библиотеки. Доставая из библиотеки объектный модуль по имени PMPI_Send, линкер с негодованием обнаружит, что его синонимом является MPI_Send, а такое имя уже встречалось, как имя совсем другой функции (нашей «обертки»). Казалось бы, налицо повторное определение имени, надо ругаться и завершать работу. Однако, библиотечный синоним MPI_Send, к счастью, «слабый», и линкер просто проигнорирует его, скомпоновав функцию по альтернативному имени. Задача решена – мы «вклинились» со своим кодом между программой и библиотекой, не имея исходных текстов ни того, ни другого.

Именно на использовании интерфейса профилирования построена библиотека PACX – MPI [29] – набор программ построения «связок» нескольких библиотек MPI в одну без какого – либо вмешательства в связываемые библиотеки. PACX – MPI удобен для применения в GRID – системах. С его помощью, например, легко связать в единое вычислительное поле два суперкомпьютера, один из которых оснащен сетью Myrinet, а второй – сетью Infiniband, причем связь между этими двумя компьютерами осуществляется по спутниковому Internet – каналу. При работе PACX – MPI в рамках этого единого вычислительного поля передача данных внутри каждой из его частей будет происходить с использованием штатно установленной на этой части реализации MPI, и лишь при посылке сообщений из одной части в другую будет использоваться tcp/ip. Сам же PACX – MPI – всего лишь набор оберток.

MPICH – самая популярная свободно распространяемая реализация MPI – включает в себя очень удобный дополнительный сервис по использованию интерфейса профилирования. В составе MPICH поставляется программа wrappergen (генератор оберток) – специализированный



Последнее изменение этой страницы: 2016-07-23

headinsider.info. Все права принадлежат авторам данных материалов.