3.2Архитектура и алгоритмы системы запуска заданий в грид для различных сред исполнения
3.2.1Общая архитектура СЗЗ-РСИ
В состав системы запуска заданий в грид для различных сред исполнения входят следующие модули
Cлужба предоставления сред исполнения (СПСИ)
Модуль (обертывающий скрипт) разворачивания ВМ на рабочем узле
Репозиторий сред исполнения
Монитор виртуальных машин (МВМ)
Модуль передачи данных в виртуальную среду (FTP-сервер)
Модули безопасности (программа sudo, модули авторизации передачи данных по протоколу FTP)
Общая архитектура СЗЗ-РСИ представлена на рис. 6.
Рис.6 Общая архитектура системы запуска заданий в грид для различных сред исполнения (СЗЗ-РСИ)
Сложность создания данной системы состоит в том, что она должна тесно взаимодействовать с другими системами и модулями грид-инфраструктуры, в первую очередь – с подсистемой управления загрузкой грид-ресурсов. На рис. 7 показана совместная архитектура подсистемы управления загрузкой, описанной в разд. 2, и СЗЗ-РСИ (модули СЗЗ-РСИ указаны жирным шрифтом).
Рис.7 Совместная архитектура подсистемы управления загрузкой и СЗЗ-РСИ
Теоретические исследования на данном этапе работы показали, что функциональные возможности менеджера загрузки ППО gLite достаточны для достижения целей настоящего проекта при условии, что на его вход подаются расширенные входные данные, включающие информацию о средах исполнения, как описано в разд. 3.1. Это связано с тем, что такую информацию удалось представить в рамках стандартной GLUE-схемы.
Более детальная архитектура вычислительного элемента, репозитория сред исполнения и рабочего узла с модулями СЗЗ-РСИ представлена в разд. 3.2.4, а архитектура основного модуля – СПСИ – в разд. 3.2.3.
3.2.2Общий алгоритм работы СЗЗ-РСИ и ее взаимодействие с другими подсистемами грида
Общий алгоритм работы системы запуска заданий, подготовленных для различных сред исполнения, представлен на рис. 8.
Рис.8 Общий алгоритм работы системы запуска заданий, подготовленных для различных сред исполнения
В соответствии с этим алгоритмом сценарий использования системы запуска заданий, подготовленных для различных сред исполнения, является следующим:
Пользователь в описании задания на языке JDL в значении атрибута Requirements указывает значение ".*jobmanager-vres" и наименование требуемой среды, как описано в предыдущем разделе.
Менеджер загрузки с помощью подсистемы информационного обслуживания находит ресурсный центр и CE, имеющий службу предоставления сред исполнения (СПСИ) и свободные рабочие узлы и направляет туда задание;
на CE задание обрабатывается с участием СПСИ; при этом создается специальный обертывающий скрипт, который через локальную систему управления пакетными заданиями передается на рабочий узел;
при необходимости СПСИ инициирует передачу (репликацию) на локальный SE нужного образа ВМ с требуемой средой с удаленного SE;
при запуске на рабочем узле с установленным монитором виртуальных машин (МВМ) СПСИ и обертывающий скрипт выполняют следующие основные действия (ср. рис. 8):
копирует образ стандартной виртуальной машины с предустановленной гостевой ОС,
запускает ВМ,
запускает на хосте ftp-сервер,
после окончания выполнения задания и выгрузки результатов из ВМ в хост-систему, скрипт останавливает ВМ и уничтожает образ на локальном диске.
результаты задания доставляются пользователю стандартными средствами gLite.
Необходимо отметить, что в этом сценарии подразумевается, что в грид-системе (хотя бы на одном SE) находится образ диска с требуемой средой. Это может быть как общедоступный образ, или образ, специально приготовленный пользователем для выполнения данного задания. Такой образ должен быть выложен на один из SE, с помощью стандартных средств системы управления данными в грид-среде и зарегистрирован в распределенных файловых каталогах.
3.2.3Архитектура службы предоставления сред исполнения (СПСИ)
Поскольку, в соответствии с Техническим заданием, система запуска заданий для произвольных сред исполнения должна быть совместима с промежуточным программным обеспечением (ППО) gLite, служба запуска заданий в средах исполнения по запросам пользователей (СПСИ) должна быть совместима с вычислительным элементом LCG-CE и, соответственно, подклассом модуля Globus::GRAM::JobManager, отвечающего за запуск любых заданий в ППО gLite. Имя подкласса удобно выбрать так, чтобы оно соответствовало его функциональному назначению сервиса запуска заданий в средах исполнения по запросам: Globus::GRAM::JobManager::vres (опять использована аббревиатура английского Virtual Runtime Environment Service – VRES). Минимальный набор основных методов, который должен реализовывать этот сервис являются следующими (ср. [8]):
submit – запуск задания;
poll – запрос статуса задания;
cancel – отмена запуска.
Алгоритм работы сервиса (подкласса) сводится к следующему.
1. Импортируются модули, необходимые для работы сервиса GRAM (Grid Resource Allocation Manager – основной модуль запуска заданий на грид-ресурсах в ППО gLite).
2. Декларируется принадлежность сервиса запуска заданий в средах исполнения по запросам пользователя (VRES) как подкласса Globus::GRAM::JobManager
3. Декларируются значения переменных среды исполнения модуля VRES (в частности, пути к командам, которые будут использоваться при работе модуля).
4. Реализуется метод “submit”:
Анализируются атрибуты задания, указанные в файле JDL (они доступны сервису в виде объекта JobDescription)
-
Используя результаты анализа, создается специальный скрипт с
соответствующим образом подготовленным описанием задания, которое передается локальной системе управления заданиями (СУПЗ) в качестве параметра команды запуска задания;
указанием исполнимого файла (собственно задания);
С помощью созданного скрипта задание передается СУПЗ, при этом результатом выполнения скрипта должно быть либо сообщение об ошибке (объект GRAMerror) или идентификатор задания.
5. Реализуется метод “poll”:
Идентификатор задания, полученный в результате выполнения метода “submit”, передается команде СУПЗ, проверяющей состояние задания, выполняемого на рабочем узле вместе с объектом JobDescription, содержащим описание задания.
Выдача команды СУПЗ, проверяющей состояние задания, выполняемого на рабочем узле, анализируется, преобразуется к удобному виду и передается подсистеме мониторинга ППО gLite.
6. Реализуется метод “cancel”:
Идентификатор задания, полученный в результате выполнения метода “submit”, передается команде СУПЗ, отменяющей выполнение задания на рабочем узле
Подсистеме мониторинга ППО gLite передается состояние задания "FAILED".
7. Для того, чтобы грид-шлюз (gatekeeper) ППО gLite мог взаимодействовать с сервисом предоставления сред исполнения по запросам пользователей, необходимо произвести его настройку. Это делается с помощью специального установочного скрипта.
8. Сервис предоставления сред исполнения регистрируется в грид-шлюзе как обработчик заданий с помощью команды globus-job-manager-service.
9. Инсталируется файл проверки атрибутов JDL, специфических для сервиса предоставления сред исполнения.
3.2.4Архитектура и алгоритмы работы вычислительного элемента, репозитория и рабочих узлов со службой предоставления сред исполнения (СПСИ)
На рис. 9 представлена общая архитектура ресурсного грид-центра с модулями СЗЗ-РСИ.
Рис. 9 Общая архитектура вычислительных грид-ресурсов (CE и WN) с модулями СЗЗ-РСИ
Архитектура репозитория сред исполнения представлена на рис. 10.
Рис. 10 Архитектура репозитория сред исполнения.
Алгоритм выполнения задания в требуемой среде, соответствующий разработанной архитектуре, показан на рис.11.
Рис.11. Алгоритм выполнения задания в среде по запросу пользователя с помощью службы предоставления сред исполнения.
3.2.5Обеспечение безопасности грид-среды
При реализации системы запуска заданий важно обеспечить безопасность грид-среды, с точки зрения возможности несанкционированных действий недобросовестных пользователей. Возможные проблемы связаны с тем, что запуск виртуальной машины Xen, которая была выбрана в качестве основного кандидата для виртуализации грид-ресурсов на первом этапе работы, осуществляется от имени привилегированного пользователя хост-системы.
Для решения этой проблемы и обеспечения общей безопасности будет использоваться инфраструктуры безопасности грида Globus GSI [9] и программа "sudo" [10].
Инфраструктура безопасности обеспечивает безопасный доступ к ресурсам в незащищенных сетях общего доступа (Интернет) с учетом прав данного пользователя и правил обслуживания пользователей данным ресурсным центром (такие правила часто называют «локальной политикой»). Система Globus GSI предоставляет такие сервисы, как аутентификация, конфиденциальность передачи информации и делегирование прав. Под делегированием прав подразумевается, что пользователю нужно лишь один раз пройти процедуру аутентификации, а далее система сама позаботится о том, чтобы аутентифицировать его на всех ресурсах, которыми он собирается воспользоваться. GSI, в свою очередь, основана на надежной и широко используемой технологии открытых криптографических ключей (Public Key Infrastructure, PKI).
Программа sudo (англ. superuser/substitute user do, дословно «выполнить от суперпользователя») - это программа, разработанная в помощь системному администратору и позволяющая делегировать те или иные привилегированные ресурсы пользователям с ведением протокола работы. Основная функциональность, которая будет использоваться для безопасной работы СЗЗ-РСИ - это возможность предоставления пользователям строго ограниченных прав, но при этом ровно столько, сколько необходимо для решения поставленных задач.
Команда sudo предоставляет возможность пользователям выполнять команды от имени привилегированного пользователя (root) либо от имени других пользователей:
Для использования sudo не требуется знания паролей тех пользователей, права которых приобретаются.
Права, предоставляемые через sudo, можно ограничить исключительно выполнением фиксированного набора программ с заранее определенным (или заданным по шаблону) набором аргументов.
При реализации СЗЗ-РСИ набор команд,которые будут выполняться через sudo будет жестко ограничен командами по запуску конкретных виртуальных машин.
Правила, используемые sudo для принятия решения о предоставлении доступа, зависят от настроек программы, которые описываются в файле Linux-дистрибутива /etc/sudoers. В частности, в нем можно задать правила, допускающие исполнение определенных команд только отдельным пользователям. В обобщенном виде это выглядит так:
username host = command
Здесь username - имя пользователя, для которого устанавливается данное правило, host - имя машины, с которой он может к этому правилу прибегнуть, command - конкретная команда, использование которой разрешается данному пользователю с данной машины. Команда должна указываться с указанием полного абсолютного пути (то есть /sbin/fdisk, а не fdisk). Поле описания команд может включать несколько значений, разделенных запятыми, например:
username ALL = /sbin/fdisk, /bin/mount
Таким образом, sudo позволяет разрешенному пользователю выполнять команду как суперпользователь или другой пользователь, как определено в файле sudoers. Реальный и эффективный uid и gid при этом устанавливаются так, чтобы соответствовать таковым целевого пользователя, как определено в файле passwd (также инициализируется вектор группы, если целевой пользователь - не root). По умолчанию sudo требует, что бы пользователи аутентифицировали себя при помощи пароля. Как только пользователь аутентифицировал себя, происходит обновление временной метки и пользователь может использовать sudo некоторый период времени без пароля (по умолчанию пять минут, если в sudoers не указано другое).
Если не указанный в файле sudoers пользователь попытается выполнить при помощи sudo команду (в частности, представляющую угрозу безопасности грид-системы), то уполномоченному пользователю (администратору данного грид-ресурса) будет отправлено электронное сообщение. Программа sudo может регистрировать оба типа попыток выполнения команд - успешные и неудачные, (так же как и ошибки) при помощи системного журнала регистрации событий, собственного журнала, или с использованием обоих вариантов. Далее такие записи могут обрабатываться подсистемой протоколирования грид-инфраструктуры.
Для обеспечения безопасности будет учтено, что sudo регистрирует только явно выполненные команды. Если пользователь выполняет такую команду как sudo su или sudo sh, то команды выполненные из этих оболочек не будут запротоколированы и при этом их не затронет управление доступом sudo. Тоже-самое верно по отношению к командам, допускающим использование управляющих символов (включая большинство редакторов). В связи с этим должна быть проявлена осторожность при предоставлении пользователям доступа к выполнению команд посредством sudo, чтобы избежать нечаянного предоставления пользователю доступа к оболочке суперпользователя (root).
3.2.6Предварительные шаги по реализации алгоритмов работы СЗЗ-РСИ
3.2.6.1 Инструкция по ручному развертыванию виртуальной машины и запуску в ней заданий средствами грида
Для проверки реализуемости алгоритмов работы системы, разработанных на данном этапе, была осуществлена их предварительная реализация в ручном режиме и выработана соответствующая инструкция, которая приводится ниже. В окончательном варианте большинство пунктов инструкции (все, кроме пунктов, относящихся к инсталляции монитора виртуальных машин) будут выполняться автоматически компонентами СЗЗ-РСИ.
1. Загружается архивный файл с МВМ Xen: xen-unstable-src.3.tgz
2. С помощью установщика приложений Yum устанавливаются необходимые пакеты:
yum install bridge-utils
yum install curl
yum install curl-devel
yum install zlib-devel
yum install python-devel
Также необходимо установить python-twisted и vnc.
3. Распаковывается архивный файл с МВМ Xen и осуществляется переход в соответствующую директорию:
tar xzf xen-unstable-src.3.tgz
cd xen-unstable
4. Инсталлируется Xen:
make world
make install
Если Xen предполагается использовать в паравиртуальном режиме, то необходимо в командной строке make указать
KERNELS="linux-2.6-xen0 linux-2.6-xenU"
5. В директории /lib/modules ищутся модули Xen и производится их загрузка. Например, найден модуль 2.6.19.29-xen. Тогда выдаются команды:
depmod 2.6.19.29-xen
mkinitrd -v -f --with=aacraid --with=sd_mod --with=scsi_mod \ /boot/initrd.img 2.6.19.29-xen
6. Редактируется конфигурационный файл /boot/grub/grub.conf : в него добавляются строки, соответствующие данной инсталляции, например:
title Xen stable
root (hd0,0)
kernel /boot/xen-3.0-unstable.gz dom0_mem=262144
module /boot/vmlinuz-2.6.16.29-xen ro root=LABEL=/ hdc=ide-scsi fastboot ro console=tty0
module /boot/initrd.img
7. Компьютер перезагружается и при загрузке в меню выбирается «grub Xen stable».
8. Создается образ гостевой операционной системы
dd if=/dev/zero of=/images/xenOS.img bs=1M count=4096
9. Если xen работает в режиме полной виртуализации, то создается файл /etc/xen/xmdefconfig со следующим содержанием (при этом предполагается, что существует директория /images/, и существует образ установочного диска /images/xenOSdisk.iso):
# -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or
# you can set the parameters for the domain on the xm command line.
#============================================================================
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'
#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/usr/lib/xen/boot/hvmloader"
# The domain build function. HVM domain uses 'hvm'.
builder='hvm'
# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
# memory errors. The domain needs enough memory to boot kernel
# and modules. Allocating less than 32MBs is not recommended.
memory = 384
# Shadow pagetable memory for the domain, in MB.
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
# shadow_memory = 8
# A name for your domain. All domains must have different names.
name = "XPP"
# 128-bit UUID for the domain. The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
#-----------------------------------------------------------------------------
# The number of cpus guest platform has, default=1
#vcpus=1
# Enable/disable HVM guest PAE, default=1 (enabled)
#pae=1
# Enable/disable HVM guest ACPI, default=1 (enabled)
#acpi=1
# Enable/disable HVM APIC mode, default=1 (enabled)
# Note that this option is ignored if vcpus > 1
#apic=1
# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = "" # leave to Xen to pick
#cpus = "0" # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5
# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=ne2k_pci' ]
# type=ioemu specify the NIC is an ioemu device not netfront
vif = [ 'type=ioemu, bridge=xenbr0' ]
dhcp=" dhcp "
#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.
#disk = [ 'phy:hda1,hda1,r' ]
disk = [ 'file:/images/xenOS.img,ioemu:hda,w',
'file:/images/xenOSdisk.iso,hdc:cdrom,r']
#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits. There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash. For each of these you
# may specify:
#
# "destroy", meaning that the domain is cleaned up as normal;
# "restart", meaning that a new domain is started in place of the old
# one;
# "preserve", meaning that no clean-up is done until the domain is
# manually destroyed (using xm destroy, for example); or
# "rename-restart", meaning that the old domain is not cleaned up, but is
# renamed and a new domain started in its place.
#
# The default is
#
# on_poweroff = 'destroy'
# on_reboot = 'destroy'
# on_crash = 'destroy'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'destroy'
#
# restart = 'always' means on_poweroff = 'restart'
# on_reboot = 'restart'
# on_crash = 'restart'
#
# restart = 'never' means on_poweroff = 'destroy'
# on_reboot = 'destroy'
# on_crash = 'destroy'
#on_poweroff = 'destroy'
#on_reboot = 'restart'
#on_crash = 'restart'
#============================================================================
# New stuff
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="d"
#-----------------------------------------------------------------------------
# write to temporary files instead of disk image files
#snapshot=1
#----------------------------------------------------------------------------
# enable SDL library for graphics, default = 0
sdl=0
#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=1
#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
vnclisten="127.0.0.1"
#----------------------------------------------------------------------------
# set VNC display number, default = domid
#vncdisplay=1
#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
#vncunused=1
#----------------------------------------------------------------------------
# enable spawning vncviewer for domain's console
# (only valid when vnc=1), default = 0
#vncconsole=0
vncviewer=0
#vncconsole=1
#----------------------------------------------------------------------------
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
vncpasswd='123'
#----------------------------------------------------------------------------
# no graphics, use serial port
#nographic=0
#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0
#-----------------------------------------------------------------------------
# serial port re-direct to pty deivce, /dev/pts/n
# then xm console or minicom can connect
serial='pty'
#-----------------------------------------------------------------------------
# Qemu Monitor, default is disable
# Use ctrl-alt-2 to connect
#monitor=0
#-----------------------------------------------------------------------------
# enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='sb16'
#-----------------------------------------------------------------------------
# set the real time clock to local time [default=0 i.e. set to utc]
#localtime=1
#-----------------------------------------------------------------------------
# set the real time clock offset in seconds [default=0 i.e. same as dom0]
#rtc_timeoffset=3600
#-----------------------------------------------------------------------------
# start in full screen
#full-screen=1
#-----------------------------------------------------------------------------
# Enable USB support (specific devices specified at runtime through the
# monitor window)
#usb=1
# Enable USB mouse support (only enable one of the following, `mouse' for
# PS/2 protocol relative mouse, `tablet' for
# absolute mouse)
#usbdevice='mouse'
#usbdevice='tablet'
#-----------------------------------------------------------------------------
# Set keyboard layout, default is en-us keyboard.
#keymap='ja'
extra = "xencons=tty128 console=tty128"
10. Выполняется команда:
xm create -c /etc/xen/xmdefconfig
11. Далее устанавливается гостевая ОС, следуя стандартной для данной операционной системы процедуре установки.
12. После окончания установки выполняется команда
xm destroy 1
и редактируется строка boot="d" заменяя ее на boot="c".
Далее выполняется команда:
xm create -c /etc/xen/xmdefconfig
Система начнет загружатся.
13. На рабочем узле ресурсного центра выполняется команда:
ssh-keygen -t dsa
При этом не используем passphrase.
14. Ключ ./.ssh/id_dsa.pub копируется в гостевую операционную систему - в файл .ssh/authorized_keys2 одного из непривилегированных пользователей.
15. Используя в ssh, задания запускаются на выполнение в гостевой операционной системе.
3.2.6.2 Выбор реализации обмена данными между хостовой и гостевой операционными системами на рабочем узле грид-системы
При каждом новом запуске, виртуальная машина оказывается в первоначальном состоянии, и необходимо обеспечить механизм, который позволял бы передавать в виртуальную машину и обратно входные данные («песочницу»), а так же выполняемые файлы задачи. В соответствии с алгоритмами, описанными в разделе 3.2.4 (рис. 9 - 11), для решения этой задачи предлагается использовать ftp-сервер, установленный на хост-машине, и сконфигурированный специальным образом, описанным ниже.
Протокол FTP [12] предназначен для передачи файлов через IP-сети; программы и библиотеки для работы с этим протоколом поддерживаются в подавляющем большинстве операционных систем, включая различные версии Linux и Microsoft Windows.
Конфигурация ftp-сервера должна быть организованна таким образом, чтобы:
виртуальная машина могла автоматически найти ftp-сервер для передачи данных;
любые две виртуальные машины, работающие на одном хосте не должны иметь доступа к данным друг друга, находящимся на ftp-сервере.
В настоящем проекте предлагается использовать реализацию ftp-сервера Pure-FTPd [13]. Данный сервер был выбран в связи с тем, что он поддерживает следующие возможности:
изоляция пользователей путем вызова команды chroot;
возможность использования внешних модулей для авторизации и аутентификации ftp-сессии.
В рассматриваемом алгоритме работы сервер Pure-FTPd постоянно запущен на хост-машине. Доступ к этому серверу разрешен только из IP-сетей, используемых виртуальными машинами. На сервере созданы пользовательские записи по максимальному числу одновременно работающих виртуальных машин. Каждый такой пользователь имеет свою отдельную домашнюю директорию на ftp-сервере, эта директория указана как директория, для которой будет производиться операция chroot на ftp-сервере для данного пользователя. Права доступа к домашним директориям пользователя установлены таким образом, что обертывающий скрипт задачи имеет право на любые действия над файлами в домашних директориях этих пользователей.
Обертывающий скрипт производит следующие действия:
Уничтожает все содержимое домашней директории на ftp-сервере.
Создает директории “in” и “out”, в директорию in копирует входную песочницу и выполняемый файл задачи.
После окончания работы виртуальной машины обертывающий скрипт пытается найти файлы выходной песочницы в директории out.
Для сервера Pure-FTPd будет разработан внешний модуль авторизации, идентифицирующий соединения по ip-адресам виртуальных машин.
После старта виртуальной машины на ней запускается стандартный скрипт автоматического запуска задачи. Этот скрипт устанавливает анонимное ftp-соединение с хост-машиной, скачивает из директории “in” входную песочницу и выполняемый файл задачи, запускает задачу, а после окончания ее выполнения копирует файлы выходной песочницы в директорию “out”.
|
