Изоляция GRID-задач с поощью lxc

Денис Пынькин, Минск, Беларусь, Белорусский Государственный Университет Информатики и Радиоэлектроники

В докладе описывается опыт применения Linux Containers (LXC) ¹ для создания изолированного окружения для запуска задач GRID. Контейнеры для вычислительных задач основаны на механизмах cgroup, что позволяет быстро создавать необходимые окружения, а также использовать их для бездисковых вычислительных узлов.

Введение

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

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

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

LXC

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

Существуют следующие варианты изоляции GRID-задач:

Запуск кластерного программного обеспечения в отдельном LXC-контейнере. Плюсы этого варианта – возможность создания выделенной вычислительной сети, запуск всех сервисов, необходимых для поддержки кластерного ПО, в отдельном контейнере. Подход сравнительно легко реализовать без вмешательства в исходный код системы управления заданиями, и при необходимости, можно использовать свою собственную систему авторизации пользователей. Его минусы – отсутствие изоляции по отдельным задачам, в результате чего программы, случайно или намеренно запущенные одним из пользователей кластера могут влиять на другие задачи в том же контейнере.
Изоляция каждой отдельной задачи в собственном контейнере. Плюсы подхода – изоляция задач друг от друга и динамическое создание контейнеров “под задачу”. Минусы – проблема запуска задач, использующих ssh (например, openmpi) и необходимость вмешательства в исходный код PBS_MOM, скрипты “prologue” и “epilogue”.

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

Предварительная инициализация контейнера

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

mount -o loop $image $rootfs

Файловая система squashfs подключается в режиме чтения, и ее необходимо перевести в режим для записи:

mount -n -t aufs -o ro,br=$rootfs=rr none $rootfs
mount -n -t aufs -o remount,prepend=$rwfs=rw none $rootfs

Переменная “rwfs” указывает на место, где будут храниться измененные файлы (в нашем случае это tmpfs, но можно использовать и сетевые ресурсы, например NFS).

Дополнительно вносятся модификации для перевода сервера sshd на порт 222, т.к. порт 22 уже занят, а сам сервис требуется для корректной работы задач MPI. Кроме того в файл ssh_config добавляются правила доступа к другим узлам, перенаправляя соединения ssh по умолчанию на порт 222.

Т.к. внутри контейнера можно ограничиться только необходимым для GRID-задач, содержимое /etc/inittab изменяется:

id:3:initdefault:
 pts:12345:once:/bin/mount -t devpts -o newinstance,ptmxmode=666,gid=5,\
mode=620 $name /dev/pts
 sshd:12345:once:/etc/init.d/sshd start
 pbs:12345:once:/etc/init.d/pbs_mom start

Монтирование devpts необходимо производить внутри контейнера (!), причем обязательно используя параметр “newinstance”.

Конфигурационный файл для контейнера содержит стандартные для lxc параметры ¹, однако из-за кластерной специфики необходимо “пробросить” внутрь общую для кластерных задач директорию, что делается в нашем случае добавлением правила:

lxc.mount.entry = /home/altlinux/work $rootfs/home/altlinux/work \
none rw,bind 0 0

Запуск контейнера

Перед запуском контейнера необходимо подключить подсистему “cgroup”:

  mkdir /dev/cgroup 
  mount -t cgroup cgroup /dev/cgroup

Запуск контейнера производится с помощью вызова команды:

 lxc-start -d -n edagrid

Результат

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

Литература:
¹ Мэт Хэлсли. LXC: Kонтейнерные утилиты Linux.
² А.В. Отвагин, Д.А. Пынькин. Виртуальное операционное окружение для интеграции вычислительных ресурсов в грид-системы. /Труды международной конференции “Суперкомпьютерные системы и их применение” (SSA2008), Минск, 2008.
³ Д.А. Пынькин. Бездисковые рабочие станции на базе технологий ALT Linux. Международная конференция “Linux Vacation / Eastern Europe” (LVEE 2008).