Контейнерная виртуализация Cell/B.E. : Часть 1. Понятия, архитектура и инструменты

Представляем принципы программной контейнерной виртуализации на платформе Cell/B.E. с использованием проекта с открытым исходным кодом OpenVZ

В этой серии из трёх частей представлена форма программной виртуализации, ориентированная на аппаратные ресурсы, известная как контейнерная виртуализация (или виртуализация операционной системы), для демонстрации которой используется проект с открытым исходным кодом OpenVZ.

Кристиан Кайзер, Стажёр, IBM

Кристиан Кайзер (Christian Kaiser) изучает вычислительную технику в университете RWTH в Ахене в Германии. В 2007 году он проходил стажировку в исследовательской лаборатории IBM в Германии, в городе Бёблинген. Во время стажировки в IBM он исследовал методы виртуализации для процессора Cell Broadband Engine. После завершения стажировки Кристиан Кайзер начал работу над диссертацией на кафедре операционных систем в университете RWTH в Ахене. Тема его диссертации - "Анализ коллективной асинхронной связи в высокоскоростных сетях, организованных в памяти"



Кристиан Рунд, исследователь-разработчик, IBM

Кристиан Рунд (Christian Rund) - сотрудник исследовательской лаборатории IBM в Бёблингене, в Германии. Он изучал теорию вычислительных систем в университете Штутгарта и в Упсальском университете в Швеции, закончив обучение в 1997 году. Во время учебы он проходил стажировку в IBM в Херренберге и Штутгарте в Германии. В 1998 году он поступил на работу в департамент разработки систем банка Landeszentralbank в Штутгарте (Deutsche Bundesbank). В 2001 году Кристиан перешел в команду разработчиков канала FCP zSeries корпорации IBM в качестве исследователя-разработчика. С середины 2006 года он занимается исследованием и разработкой микропрограммного обеспечения хост-контроллера Cell/B.E.



08.02.2008

Введение

Виртуализация – это, безусловно, революционная технология. Программная виртуализация была одной из наиболее обсуждаемых тем в сфере информационных технологий в 2007 году. Из этой короткой серии вы узнаете об эффективном подходе к виртуализации аппаратных ресурсов процессора Cell Broadband Engine, которая называется контейнерной виртуализацией (или виртуализацией операционной системы). Вы также узнаете о проекте OpenVZ - программном проекте с открытым исходным кодом, который реализует возможности контейнерной виртуализации в Linux®. Коммерческим конкурентом OpenVZ является продукт Virtuozzo компании SWsoft Inc.

В этой серии статей обсуждаются элементы, необходимые для реализации виртуализации процессора Cell/B.E. программными методами. Вы познакомитесь с введением в интерфейсы ядра Linux OpenVZ, которые нужно изменить для использования платформы Cell/B.E. в среде контейнера. Вы также увидите отчёт по исследованиям, демонстрирующим эффективность контейнерной виртуализации в среде Cell/B.E.


Понятия OpenVZ и процессора Cell/B.E.

OpenVZ - это программная реализация поддержки контейнерной виртуализации в Linux с открытым исходным кодом. OpenVZ состоит из двух компонентов:

  • Ядро Linux OpenVZ
  • Инструменты пространства пользователя OpenVZ

Основная цель проекта OpenVZ состоит в создании изолированных контейнеров, которые работают под управлением виртуальных экземпляров операционной системы Linux. У всех контейнеров есть доступ к единому виртуализованному ядру. Базовая система, реализующая это ядро, обслуживает так называемую основную четверку виртуализованных устройств: центральный процессор, оперативную память, дисковые накопители и сетевые устройства. Также можно передать одно из устройств напрямую контейнеру, после чего оно становится недоступным базовой системе и всем остальным контейнером, за исключением контейнера, владеющего этим устройством (выделение устройства в монопольное владение).

На рисунке 1 показана изоляция трёх экземпляров контейнеров (отмечены как VS-1, VS-2 и VS-3). Все три контейнера используют одно общее ядро Linux OpenVZ. См. раздел Ресурсы.

Рисунок 1. Изоляция трёх экземпляров контейнеров
Изоляция трёх экземпляров контейнеров

Вы уже, вероятно, знакомы с процессором Cell/B.E., который применяется в различных продуктах сторонних производителей - от гибридных суперкомпьютеров до специализированных высокозащищенных аппаратных ускорителей и игровой приставки Sony Playstation 3. Процессор Cell включает в себя ядро общего назначения с архитектурой Power Architecture™ и оптимизированные сопроцессорные элементы (streamlined co-processing elements, SPU), которые значительно ускоряют мультимедийные и векторные приложения. Процессор Cell/B.E. имеет производительность операций с плавающей точкой единичной точности в 25,6 гигафлопс на SPU, за что его часто называют суперкомпьютером в микросхеме.

На рисунке 2 показана базовая архитектура процессора Cell/B.E.

Рисунок 2. Базовая архитектура процессора Cell/B.E.
Базовая архитектура процессора Cell/B.E.

Базовая архитектура состоит из процессорного элемента Power (Power Processing Element, PPE), который представляет собой ядро PowerPC с обычной подсистемой памяти, и восьми синергических процессорных элементов (Synergistic Processing Elements, SPE), соединенных высокоскоростным внутренним каналом, называемым шиной соединения элементов (Element Interconnect Bus, EIB). Каждый SPE состоит из синергического процессора (Synergistic Processing Unit, SPU), локальной памяти (LS) объёмом 256 КБ, в которой хранятся инструкции и данные SPE, а также контроллера потоков памяти (MFC), который управляет передачей данных по DMA между основной памятью системы и LS элемента SPE. PPE служит исключительно для нужд операционной системы. На сегодняшний день Linux является единственной операционной системой, которая поддерживает архитектуру Cell/B.E.


Контейнерная виртуализация и процессор Cell/B.E.

На рисунке 3 изображено разбиение процессора Cell/B.E.

Рисунок 3. Разбиение процессора Cell/B.E.
Разбиение процессора Cell/B.E.

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

  1. Виртуализовать файловую систему SPU (spuf). spuf должна быть доступна внутри контейнеров, но каждый контейнер должен видеть только потоки SPE, созданные им самим.
  2. Скорректировать виртуальную файловую систему, реализованную в ядре Linux 2.6 (sysfs). В /sys/devices/system/spu в sysfs внутри контейнера должны содержаться правильные записи каталогов для каждого SPU, выделенного ему. libspe2 использует эти записи каталогов для подсчёта SPU, доступных внутри контейнера.
  3. Изменить планировщик SPU. Необходимо изменить планирование SPU таким образом, чтобы потоки SPE, созданные внутри контейнера, работали только на SPU, выделенных этому контейнеру.
  4. Изменить инструменты OpenVZ. Инструмент vzctl из пакета инструментов OpenVZ должен поддерживать выделение SPU контейнерам и наоборот, освобождать SPU от контейнеров. Выделение и освобождение должны функционировать во время работы контейнера.

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

Рисунок 4. Общая виртуализация SPU
Общая виртуализация SPU

Нам нужен механизм, который будет контролировать, какой частью устройства владеет контейнер или в течение какого времени всё устройство будет доступно контейнеру. Поскольку SPU невозможно разделить на части физически, контейнеры используют SPU с разделением по времени доступа.

В рамках нашей реализации должны выполняться следующие четыре действия:

  1. Виртуализовать spufs. spufs должна быть доступна внутри контейнеров, но каждый контейнер должен видеть только потоки SPE, созданные им самим.
  2. Скорректировать sysfs. В папке /sys/devices/system/spu в sysfs внутри контейнера должны содержаться правильные записи каталогов. Лучшим решением будет наличие контейнеров, у которых есть доступ ко всем SPU, установленным в системе, поэтому в директории /sys/devices/system/spu будут одинаковые записи как на базовой системе, так и во всех контейнерах.
  3. Изменить планировщик SPU. Планировщик SPU необходимо изменить таким образом, чтобы потоки SPE, созданные внутри контейнера, имели доступ только к SPU, доступным в системе на определенный момент времени. Для потоков SPE может быть разработан алгоритм планирования, схожий с двухуровневым равномерным планировщиком центрального процессора, который реализовала команда OpenVZ для обычных процессов. Можно внедрить даже полностью новый алгоритм планирования.
  4. Изменить инструменты OpenVZ. Инструмент vzctl из пакета инструментов OpenVZ должен поддерживать установку времени выполнения SPU для каждого контейнера. Этот параметр должен быть изменяем во время работы контейнера.

Теперь немного о spufs.

Использование spufs

Spufs совместима с другой хорошо известной виртуальной файловой системой (VFS) procfs. Procfs была первой абстрактной файловой системой в Linux, которая была призвана максимально упростить представление процессов. В то время как procfs представляет процессы, работающие на центральном процессоре, spufs представляет потоки, работающие на SPU процессора Cell/B.E.

spufs является специальной файловой системой. Это виртуальная файловая система разработана для управления SPU на процессоре Cell/B.E. Каждая директория spufs обозначает логический контекст SPE. Такой логический контекст SPE рассматривается так же, как физический SPE. Свойства контекста представлены в виде файлов в каталоге. При доступе к контексту SPE происходит манипуляция либо реальным SPE, либо его состоянием, сохранённым в оперативной памяти. Для запуска программы SPU скопируйте исполняемый файл ELF SPU в LS SPE и выполните системный вызов spu_run.

Если вы хотите выполнить в Linux код, специально предназначенный для Cell/B.E., например, программу, работающую на SPU процессора Cell/B.E., вам придётся использовать spufs. Другого способа запуска на Linux процессов, использующих SPU процессора Cell/B.E, не существует.

Как вы можете увидеть в листинге 1, перед выполнением команды ls на двух потоках SPE был запущен пример программы быстрого преобразования Фурье из Cell SDK. Точка монтирования spufs - /spu.

Листинг 1. Выполнение примера быстрого преобразования Фурье из Cell SDK с двумя потоками SPE
[root@c02b12-0 ~]# ls /spu
spethread-20914-25296904 spethread-20914-25297464

[root@c02b12-0 ~]# ls /spu/*
/spu/spethread-20914-25296904:
cntl decr_status event_mask fpcr ibox_info lslr mbox_info mem mss
object-id proxydma_info regs signal1_type signal2_type wbox wbox_stat
decr dma_info event_status ibox ibox_stat mbox mbox_stat mfc npc physid
psmap signal1 signal2 srr0 wbox_info

/spu/spethread-20914-25297464:
cntl decr_status event_mask fpcr ibox_info lslr mbox_info mem mss
object-id proxydma_info regs signal1_type signal2_type wbox wbox_stat
decr dma_info event_status ibox ibox_stat mbox mbox_stat mfc npc physid
psmap signal1 signal2 srr0 wbox_info

Результат работы первой команды показывает, что для каждого потока SPE определяется одна директория (kobject), в названии которой указывается идентификатор процесса (PID) и идентификатор потока SPE. Результат работы второй команды показывает файлы, содержащиеся в обеих директориях.

На рисунке 5 показано, как обрабатываются два разных типа исполняемых файлов ELF.

Рисунок 5. Обработка двух типов исполняемых файлов ELF
Обработка двух типов исполняемых файлов ELF

Исполняемый файл SPE в виде объектного файла SPE привязывается к потоку SPE, исполняемому на физическом SPE. Специальный планировщик SPE решает, когда и какой поток SPE будет исполняться на физическом SPE. Объектные файлы PPE обрабатываются так же, как и в системах стандартной архитектуры PowerPC®, например, на Blade-серверах JS21. Объектные файлы PPE привязываются к стандартным потокам Linux, за управление которыми отвечает планировщик Linux, реализованный в ядре. Поэтому ничего нового в приложениях, работающих на PPE, нет.


Описание SDK Cell/B.E. и libspe

На сегодняшний день выпущена версия 3.0 комплекта для разработки программного обеспечения (SDK) для Cell/B.E. (последнюю версию можно получить в разделе загрузки центра ресурсов Cell). В SDK Cell/B.E. входят все инструменты, необходимые для разработки приложений, использующих процессоры Cell/B.E. Кроме всего прочего, в SDK входят различные пакеты компиляторов и компоновщиков, библиотеки, упрощающие разработку (например, libspe), а также примеры программ SPU, MFC, LS и т.д., которые демонстрируют использование возможностей архитектуры Cell/B.E.

На сегодняшний день libspe (версий libspe1 и libspe2) является единственным пользователем spufs. Это среда, которая упрощает разработку кода для SPE архитектуры Cell/B.E. Она копирует исполняемые файлы ELF в локальную память SPE и выполняет системный вызов spu_run, поэтому вам не нужно заботиться о внутренних процессах запуска исполняемых файлов SPE.

На рисунке 6 показана иерархия расширений, реализованных в Linux для использования процессора Cell/B.E.

Рисунок 6. Иерархия расширений, реализованных в Linux для использования процессора Cell/B.E.
Иерархия расширений, реализованных в Linux для использования процессора Cell/B.E.

На рисунке показана библиотека управления SPE в реальном времени (libspe), работающая в пространстве пользователя, которая использует файловую систему spufs, реализованную в пространстве ядра.


Описание sysfs

Изначально sysfs была реализована в ядре Linux как driverfs, её целью было предоставление общего обзора всех устройств и драйверов, известных ядру. Она была разработана как более простой, чем procfs, способ доступа к устройствам и драйверам. sysfs показывает иерархию структур данных kobject (представляя каждую директорией) и множество атрибутов (структуры kobject), которые являются файлами, обычно содержащими одно значение, закодированное в текстовую строку.

Например, в листинге 2 приведен листинг директории /sys/devices/system/spu на blade-сервере QS21 Cell/B.E.

Listing 2. One directory for each SPU
[root@c02b12-0 ~]# ls /sys/devices/system/spu/
spu0  spu1  spu10  spu11  spu12  spu13  spu14  spu15  spu2  spu3  spu4  spu5  spu6
spu7  spu8  spu9
[root@c02b12-0 ~]#

В blade-сервере QS21 Cell/B.E. используется два процессора Cell/B.E. с восемью SPU в каждом, таким образом, всего в сервере имеется 16 SPU. Как вы можете видеть, в директории /sys/devices/system/spu содержится по одной директории для каждого SPU. libspe2 по этим записям директорий подсчитывает количество физических SPU, доступных в системе.


Описание ядра OpenVZ

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

В каждом контейнере есть собственное множество ресурсов, предоставляемых ядром, в число которых входят:

  • Файлы: системные библиотеки и приложения.
  • Виртуализованные файловые системы: procfs или sysfs.
  • Пользователи и группы: в каждом контейнере есть собственный пользователь root, равно как и другие пользователи и группы.
  • Дерево процессов: из контейнера видно только собственное множество процессов с виртуализованными идентификаторами (PID процесса init равен 1).
  • Сеть: виртуальные сетевые устройства с собственными адресами IP и правилами фильтрации и маршрутизации.
  • Устройства: виртуализуются некоторые устройства. При необходимости любому контейнеру может быть предоставлен доступ к реальным (не виртуализованным) устройствам.
  • Объекты IPC: семафоры, сообщения и общая память.

Управление ресурсами

Управление ресурсами выполняется по различным типам ресурсов:

  • Дисковая квота: В OpenVZ реализуется двухуровневое дисковое квотирование, которое позволяет ограничить дисковое пространство для контейнера, а также даёт контейнеру возможность устанавливать квоты в собственной среде.
  • Планировщик центрального процессора: Равномерный планировщик центрального процессора также использует двухуровневый механизм. Первый уровень этого настраиваемого планировщика - уровень контейнеров, на котором вы можете определить, сколько процессорного времени будет выделено тому или иному контейнеру. На втором уровне планировщик работает с планированием процессов в среде внутри контейнеров.
  • Счетчики beancounters пользователей: набор счётчиков, ограничений и гарантий для ресурсов контейнеров. Существует порядка 20 параметров памяти и различных объектов ядра, например, сегментов общей памяти IPC и сетевых буферов.

Копирование памяти в контрольных точках

Копирование памяти в контрольных точках (checkpointing) - ещё одна важная функция системы. Копирование и восстановление памяти в контрольных точках необходимо для миграции в реальном времени. Копирование памяти в контрольных точках - это процесс замораживания контейнера и последующего полного сохранения его состояния в дисковый файл. Восстановление представляет собой обратный процесс. Миграция контейнера в реальном времени - это процесс копирования памяти контейнера в контрольной точке на одной базовой системе и её восстановление на другой базовой системе.

На рисунке 7 показаны различия процессов миграции в реальном времени и копирования и восстановления памяти контейнера в контрольных точках.

Рисунок 7. Различия процессов миграции в реальном времени и копирования и восстановления памяти контейнера в контрольных точках
Различия процессов миграции в реальном времени и копирования и восстановления памяти контейнера в контрольных точках

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


Использование vzctl и других инструментов OpenVZ

Основной инструмент OpenVZ - это vzctl, который представляет собой интерфейс командной строки высокого уровня для управления средами контейнеров. Vzctl может использоваться для создания, запуска, остановки и уничтожения среды виртуальной операционной системы. Эти действия называются жизненным циклом контейнера.

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

Инструмент vzctl можно запустить только из базовой системы, запускать его из контейнера нельзя.

Кроме vzctl, существует множество других инструментов для управления контейнерами OpenVZ. Эти инструменты не являются необходимыми для OpenVZ в контексте виртуализации Cell/B.E., поэтому подробное описание общего управления средами контейнеров можно найти в руководстве пользователя OpenVZ (см. раздел Ресурсы). Кстати, авторы этой серии также написали руководство по OpenVZ на POWER™.


Подготовка ко второй части

Во второй части описывается исключительно реализация принципа выделенной виртуализации (разбиения), проиллюстрированного на рисунке 3.


Благодарности

Авторы выражают благодарность авторам статьи "Mehrarbeit fur CPUs (DE)" (Linux Magazin, апрель 2006 г.) за предоставленную иллюстрацию, показанную на рисунке 1.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы в первый раз заходите в developerWorks. Выберите данные в своем профиле (имя, страна/регион, компания) которые будут общедоступными и будут отображаться, когда вы публикуете какую-либо информацию. Вы можете изменить данные вашего ИБМ аккаунта в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=288230
ArticleTitle=Контейнерная виртуализация Cell/B.E. : Часть 1. Понятия, архитектура и инструменты
publish-date=02082008