International conference of developers
and users of free / open source software

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

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

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

Введение

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

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

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

LXC

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

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

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

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

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

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

mount -o loop !http://www.codecogs.com/png.latex?\textstyle%20image!rootfs

Файловая система squashfs подключается в режиме чтения, и ее необходимо перевести в режим для записи:
mount -n -t aufs -o ro,br=!http://www.codecogs.com/png.latex?\textstyle%20rootfs=rr%20none!rootfs
mount -n -t aufs -o remount,prepend=!http://www.codecogs.com/png.latex?\textstyle%20rwfs=rw%20none!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 !http://www.codecogs.com/png.latex?\textstyle%20name%20/dev/pts%0D%0A%20sshd:12345:once:/etc/init.d/sshd%20start%0D%0A%20pbs:12345:once:/etc/init.d/pbs_mom%20start%3C/code%3E%3C/pre%3E%0D%0A%0D%0A%D0%9C%D0%BE%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20devpts%20%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D1%8C%20%D0%B2%D0%BD%D1%83%D1%82%D1%80%D0%B8%20%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%B0%20(!),%20%D0%BF%D1%80%D0%B8%D1%87%D0%B5%D0%BC%20%D0%BE%D0%B1%D1%8F%D0%B7%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D1%8F%20%D0%BF%D0%B0%D1%80%D0%B0%D0%BC%D0%B5%D1%82%D1%80%20%22newinstance%22.%0D%0A%0D%0A%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%20%D0%B4%D0%BB%D1%8F%20%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%B0%20%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D1%82%20%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%BD%D1%8B%D0%B5%20%D0%B4%D0%BB%D1%8F%20lxc%20%D0%BF%D0%B0%D1%80%D0%B0%D0%BC%D0%B5%D1%82%D1%80%D1%8B%20[1],%20%D0%BE%D0%B4%D0%BD%D0%B0%D0%BA%D0%BE%20%D0%B8%D0%B7-%D0%B7%D0%B0%20%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%BD%D0%BE%D0%B9%20%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B8%20%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%22%D0%BF%D1%80%D0%BE%D0%B1%D1%80%D0%BE%D1%81%D0%B8%D1%82%D1%8C%22%20%D0%B2%D0%BD%D1%83%D1%82%D1%80%D1%8C%20%D0%BE%D0%B1%D1%89%D1%83%D1%8E%20%D0%B4%D0%BB%D1%8F%20%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%BD%D1%8B%D1%85%20%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%B8%D1%8E,%20%D1%87%D1%82%D0%BE%20%D0%B4%D0%B5%D0%BB%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20%D0%B2%20%D0%BD%D0%B0%D1%88%D0%B5%D0%BC%20%D1%81%D0%BB%D1%83%D1%87%D0%B0%D0%B5%20%D0%B4%D0%BE%D0%B1%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC%20%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0:%0D%0A%3Cpre%3E%3Ccode%3Elxc.mount.entry%20=%20/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-системы.

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

Материалы к докладу

blog comments powered by Disqus