3Программная реализация разработанных алгоритмов и создание макета системы запуска заданий для различных сред исполнения 3.1Программная реализация компонент СЗЗ-РСИ
В соответствии с разработанными архитектурой и алгоритмами работы была осуществлена программная реализация компонентов СЗЗ-РСИ, а именно, были реализованы:
Cлужба предоставления сред исполнения (СПСИ)
Модуль разворачивания ВМ на рабочем узле
Монитор виртуальных машин (МВМ)
Модуль передачи данных в виртуальную среду
Модули безопасности
Репозиторий сред исполнения
Часть компонент разработанной системы являются оригинальным программным продуктом. В качестве основы других модулей были взяты готовые свободно распространяемые продукты с открытым исходным кодом. Для их интеграции в систему запуска заданий для различных сред исполнения была проведена работа по их инсталляции и соответствующей конфигурации.
В следующих подразделах данной части отчета приведена краткая характеристика программной реализации каждого из компонентов. Более подробное описание приведено в технической документации (см. разд. 3.3).
3.1.1Cлужба предоставления сред исполнения (СПСИ) 3.1.1.1 Функциональное назначение
будет дополнено
3.1.1.2 Описание логической структуры
будет дополнено
3.1.1.3 Программное обеспечение, необходимое для функционирования программы
будет дополнено
3.1.1.4 Языки программирования, на которых написана программа
будет дополнено
3.1.1.5 Используемые технические средства
будет дополнено
3.1.1.6 Вызов и загрузка
будет дополнено
3.1.1.7 Входные и выходные данные
будет дополнено
3.1.2Модуль разворачивания ВМ на рабочем узле 3.1.2.1 Функциональное назначение
Назначением программы является монтирование/размонтирование файла образа требуемой среды исполнения к локальной файловой системе рабочего узла, запись входной "песочницы" (sandbox) задания в файл образа и результатов задания в файловую систему, запуск ВМ и разворачивание требуемой среды исполнения, после окончания выполнения задания - прекращение работы ВМ.
Программа работает на рабочем узле грид-системы и взаимодействует с соответствующей компонентой ППО.
3.1.2.2 Логическая структура
Программа состоит из следующих частей:
блок разворачивания ВМ;
блок монтирования/размонтирования файла образа среды исполнения;
блок аварийной остановки и уничтожения ВМ.
Модуль запускается службой предоставления сред исполнения (СПСИ) и обращается к монитору виртуальных машин (МВМ). Требуемая среда исполнения указывается в файле описания задания на языке JDL с помощью атрибута " Requirements".
3.1.2.3 Программное обеспечение, необходимое для функционирования программы
Программа предназначена для работы в операционной среде Scientific Linux 4 (SL4).
3.1.2.4 Языки программирования, на которых написана программа
При написании модуля использовались языки программирования:
3.1.2.5 Используемые технические средства
Модуль устанавливается на рабочие узлы ресурсного центра на базе персонального компьютера (ПК) со следующими минимальными параметрами:
ЦПУ - Pentium III 1GHz
ОП - 256MB
диск - 40GB
сеть ethernet 10Mb с доступом в интернет
внешний канал выхода в интернет - 10Mb/сек
3.1.2.6 Вызов и загрузка
Для обращения к программе необходимо иметь доступ с правами привилегированного пользователя на рабочий узел ресурсного центра с установленной программой. От имени привилегированного пользователя запускается программа xenrun с параметром, который указывает путь к JDL-файлу описания задания:
#root> xenrun -i input_dir -o output_dir -e exec_file test.jdl
При правильной работе задание input_dir/exec_file должно быть выполнено в среде, специфицированной в файле test.jdl и результаты записаны в директорию output_dir.
3.1.2.7 Входные и выходные данные
Входными данными программы являются:
входная директория (ключ -i);
выходная директория (ключ -o);
исполняемый файл (ключ -e);
файл описания задания (JDL-файл).
Выходными данными являются подходящим (в соответствии с JDL-файлом) сгенерированные команды развертывания виртуальной машины с требуемой средой исполнения.
3.1.3Монитор виртуальных машин (МВМ) 3.1.3.1 Функциональное назначение
Назначением монитора виртуальных машин (МВМ) является организация безопасного исполнения виртуальной машины с требуемой средой исполнения на физической системе с производительностью близкой к хостовой системе. В качестве МВМ в СЗЗ-РСИ используется Xen (http://www.xen.org), распространяющийся с открытым исходным кодом (opensource).
3.1.3.2 Описание логической структуры
В системе Xen есть множество уровней, нижним и наиболее привилегированным из которых является сам Xen.
В Xen может работать множество гостевых операционных систем, каждая из которых выполнятся в безопасной виртуальной машине. В терминологии Xen такая машина называется домен. Исполнение кода доменов планируется Xen так, чтобы сделать использование доступных процессоров наиболее эффективным. Каждая гостевая ОС занимается управлением собственных приложений. Это управление включает ответственность за планирование выполнения каждого приложения в течение временного интервала, выделенного Xen виртуальной машине.
Первый домен, домен 0, создаётся автоматически при загрузке системы. Этот домен обладает особыми управляющими привилегиями. Домен 0 запускает остальные домены и предоставляет им виртуальные устройства. Еще он занимается выполнением административных задач, таких как остановка (suspending), возобновление (resuming) работы виртуальных машин и их миграция.
В домене 0 работает процесс xend, который и занимается управлением Xen. Xend отвечает за управление виртуальными машинами и обеспечение доступа к их консолям. Команды Xend даются из командной строки и передаются ему через HTTP-интерфейс.
Дистрибутив Xen включает три главных компонента: собственно Xen, порт Linux и NetBSD для работы в Xen и утилиты для управления Xen-системой.
3.1.3.3 Программное обеспечение, необходимое для функционирования программы
Программа предназначена для работы в операционной среде Scientific Linux 4 (SL4).
3.1.3.4 Языки программирования, на которых написана программа
При написании МВМ использовались языки программирования:
3.1.3.5 Используемые технические средства
Модуль устанавливается на рабочие узлы ресурсного центра на базе персонального компьютера (ПК) со следующими минимальными параметрами:
ЦПУ - Pentium III 1GHz
ОП - 256MB
диск - 40GB
сеть ethernet 10Mb с доступом в интернет
внешний канал выхода в интернет - 10Mb/сек
3.1.3.6 Вызов и загрузка
Для запуска управляющего демона Xen, необходимо дать команду:
# xend start
Когда демон запустится, с помощью программы xm можно выполнять управление и наблюдать за доменами, работающими в вашей системе. Утилита xm предоставляет множество команд по управлению доменами. Запуск домена выполняется с помощью команды create. Предположим, что вы создали конфигурационный файл myvmconf, базирующийся на файле /etc/xen/xmexample2. Для старта домена с ID виртуальной машины 1 нужно ввести команду:
# xm create -c myvmconf vmid=1
Ключ -c обозначает, что после того как домен будет создан, xm должна превратиться в его консоль. Параметр vmid=1 устанавливает переменную vmid, использующуюся в конфигурационном файле myvmconf, равной 1.
В терминале, в котором была введена команда, должна появиться консоль с загрузочными сообщениями домена, а после того как загрузка завершится -- приглашение о входе в систему.
Если надо запустить домен в режиме полной виртуализации (с конфигурационным файлом /etc/xen/xmdefconfig, см. Приложение В), выполняется команда
xm create -c /etc/xen/xmdefconfig
Далее устанавливается гостевая ОС, следуя стандартной для данной операционной системы процедуре установки. После окончания установки выполняется команда
xm destroy 1
и редактируется строка boot="d" конфигурационного файла: она должна быть заменена на boot="c".
Далее выполняется команда:
xm create -c /etc/xen/xmdefconfig
Система должна начать загружаться.
3.1.3.7 Входные и выходные данные
Входными данными программы являются файлы образов сред исполнения.
Выходными данными сообщения о развернутой виртуальной машине.
3.1.4Модуль передачи данных в виртуальную среду 3.1.4.1 Функциональное назначение
Назначением модуля передачи данных является передача данных, которые требуются в процессе выполнения задания, из хранилища в виртуальную машину, где выполняется это задание. В качестве такого модуля используется клиетская часть GridFTP.
Программное обеспечение GridFTP является компонентом грид-инструментария Globus (http://www.globus.org) и состоит из следующих частей:
сервер (globus-gridftp-server),
клиентской части (globus-url-copy),
библиотеки для разработки модифицированных клиентских частей
Для того, чтобы данные были доступны с помощью GridFTP, необходимо на хосте, который может обратиться к требуемым данным, установить GridFTP-сервер и обеспечить соответствующий интерфейс к хранилищу данных (Data Storage Interface, DSI). Чаще всего это означает стандартную (POSIX) файловую систему, но DSI также существуют для Брокера ресурсов хранения (Storage Resource Broker, SRB) и высокопроизводительной системы хранения данных (High Performance Storage System, HPSS)
Если нужно просто обратиться к данным, которые доступны по GridFTP, достаточно установить клиенте GridFTP - globus-url-copy. Этот клиент способен обращаться к данным посредством целого ряда протоколов: http, https, ftp, gsiftp и file. Важным является то, что это не интерактивный клиент, а интерфейс командной строки, подходящий для использования внутри скриптов.
3.1.4.2 Описание логической структуры
Программное обеспечение GridFTP является компонентом грид-инструментария Globus (http://www.globus.org) и состоит из следующих частей:
сервер (globus-gridftp-server),
клиентской части (globus-url-copy),
библиотеки для разработки модифицированных клиентских частей
Для того, чтобы данные были доступны с помощью GridFTP, необходимо на хосте, который может обратиться к требуемым данным, установить GridFTP-сервер и обеспечить соответствующий интерфейс к хранилищу данных (Data Storage Interface, DSI). Чаще всего это означает стандартную (POSIX) файловую систему, но DSI также существуют для Брокера ресурсов хранения (Storage Resource Broker, SRB) и высокопроизводительной системы хранения данных (High Performance Storage System, HPSS)
Если нужно просто обратиться к данным, которые доступны по GridFTP, достаточно установить клиенте GridFTP - globus-url-copy. Этот клиент способен обращаться к данным посредством целого ряда протоколов: http, https, ftp, gsiftp и file. Важным является то, что это не интерактивный клиент, а интерфейс командной строки, подходящий для использования внутри скриптов.
3.1.4.3 Программное обеспечение, необходимое для функционирования программы
Программа предназначена для работы в различных операционных средах, в зависимости от требуемой среды исполнения. Для работы программы требуется, чтобы хранилище данных было доступно для установленного сервера GridFTP.
3.1.4.4 Языки программирования, на которых написана программа
При написании МВМ использовались языки программирования:
3.1.4.5 Используемые технические средства
Модуль устанавливается в среду исполнения и формируется файл образа диска с этим модулем для последующего развертывания в виртуальной машине на рабочем узле.
3.1.4.6 Вызов и загрузка
Следующая команда позволяет передать файл из удаленного хранилища на локальный диск или файл-сервер, определенный во втором URL:
globus-url-copy [optional command line switches] Source_URL Destination_URL
Здесь Source_URL - адрес источника данных, Destination_URL - адрес приемника данных. Возможными префиксами адресов могут быть:
file://
ftp://
gsiftp://
http://
https://
Возможные форматы URL:
gsiftp://myhost.mydomain.com:2812/data/foo.dat
http://myhost.mydomain.com/mywebpage/default.html
file:///foo.dat
3.1.4.7 Входные и выходные данные
Входными данными программы являются файлы, которые необходимо скопировать.
Выходными данными программы являются копии требуемых файлов.
3.1.5Модуль безопасности 3.1.5.1 Функциональное назначение
Назначением этой программы является делегирование тех или иных привилегированных ресурсов пользователям с ведением протокола работы. В рамках СЗЗ-РСИ основное назначение этого модуля безопасности - запуск монитора виртуальных машин со строго ограниченными правами.
3.1.5.2 Описание логической структуры
Команда sudo предоставляет возможность пользователям выполнять команды от имени привилегированного пользователя (root) либо от имени других пользователей:
Для использования sudo не требуется знания паролей тех пользователей, права которых приобретаются.
Права, предоставляемые через sudo, можно ограничить исключительно выполнением фиксированного набора программ с заранее определенным (или заданным по шаблону) набором аргументов.
При реализации СЗЗ-РСИ набор команд, которые выполняются через sudo жестко ограничен командами по запуску конкретных виртуальных машин.
Правила, используемые sudo для принятия решения о предоставлении доступа, находятся в файле /etc/sudoers; язык их написания и примеры использования подробно изложены в sudoers(5). Кроме того, пример правил, предоставляющих пользователям, являющимся членами группы rpm, возможность устанавливать, обновлять и удалять пакеты в системе, приведен в файле /usr/share/doc/sudo-<версия>/rpm.sudoers.
Для редактирования файла /etc/sudoers следует использовать программу visudo, которая проверяет синтаксис и тем самым позволяет избежать ошибок в правилах.
3.1.5.3 Программное обеспечение, необходимое для функционирования программы
Программа предназначена для работы в ОС Scientific Linux. В качестве модуля безопасности используется программа sudo (англ. superuser/substitute user do, дословно «выполнить от суперпользователя»). Назначением этой программы является делегирование тех или иных привилегированных ресурсов пользователям с ведением протокола работы. В рамках СЗЗ-РСИ основное назначение этого модуля безопасности - запуск монитора виртуальных машин со строго ограниченными правами.
3.1.5.4 Языки программирования, на которых написана программа
При написании МВМ использовались язык программирования С.
3.1.5.5 Используемые технические средства
Модуль устанавливается на рабочий узел ресурсного центра грид-инфраструктуры.
3.1.5.6 Вызов и загрузка
Общий формат обращения к программе является следующим:
sudo [необязательные опции] команда
Если пользователь не перечисленный в списке, в файле sudoers, попытается выполнить команду посредством sudo, должно быть отправлено письмо, как определено в установленное время или как определено в файле sudoers (по умолчанию root). Однако, это письмо не будет отправлено, если неавторизованный пользователь попытается запустить sudo, с флагами -l или -v. Эта возможность позволяет пользователям узнать, могут они использовать sudo или нет.
Если sudo запущен пользователем root и переменная SUDO_USER установлена, sudo будет использовать это значение, для определения того, кто является настоящим пользователем. Данная возможность может быть использована пользователем для протоколирования команд через sudo, даже когда вызван root shell. Утилита так же поддерживает -e флаг, который будет полезен, даже если будет запущен через sudo-скрипт или программу.
3.1.5.7 Входные и выходные данные
Входными данными программы являются команды, которые надо выполнить от лица привилегированного пользователя и список пользователей, которому это разрешено (содержится в файле sudoers).
Выходными данными являются результаты выполнения запущенных команд.
3.1.6Репозиторий сред исполнения 3.1.6.1 Функциональное назначение
Назначением репозитария образов дисков с различными средами исполнения является предоставление модулю разворачивания виртуальных машин требуемой среды исполнения.
3.1.6.2 Описание логической структуры
Файлы с образами дисков могут быть размещены в локальной файловой системе рабочих узлов ресурсных центров. В этом случае модуль разворачивания виртуальных машин на рабочем узле обращается к ним по протоколу NFS.
Другой вариант - размещение дисков в хранилище данных ресурсного центра. При этом перед началом выполнения задания файл с образом диска передается на локальный диск того рабочего узла, на котором предполагается выполнение задания в требуемой среде.
3.1.6.3 Программное обеспечение, необходимое для функционирования программы
К файлам репозитория необходим доступ по протоколу NFS, GridFTP или каким-либо другим стандартным протоколам.
3.1.6.4 Используемые технические средства
Репозиторий располагается на локальных дисках рабочих узлов или на файловых серверах, к которым есть доступ с рабочих узлов протоколу NFS, GridFTP или каким-либо другим стандартным протоколам.
3.1.6.5 Вызов и загрузка
Репозитарий должен быть доступен модулю разворачивания ВМ по протоколу NFS или каким-либо другим стандартным протоколам. Файлы с образами в репозитории должны иметь стандартизованные наименования: названиеОС-типФайловойСистемы-номерВерсииСреды.
3.1.6.6 Входные и выходные данные
Входными данными являются файлы образы дисков с различными средами исполнения.
Выходными данными являются развернутая виртуальная машина с соответствующей средой исполнения.
|
