Виртуализация – это, безусловно, революционная технология. Программная виртуализация была одной из наиболее обсуждаемых тем в сфере информационных технологий в 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.
Базовая архитектура состоит из процессорного элемента 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.
Контейнерам предоставляется доступ к выделенным физическим SPU, имеющимся в системе. SPU, доступные в контейнере, недоступны в других контейнерах и в базовой системе на время выделения. Каждый контейнер использует только те SPU, которыми он владеет. Чтобы реализовать это, необходимо выполнить четыре действия:
- Виртуализовать файловую систему SPU (spuf). spuf должна быть доступна внутри контейнеров, но каждый контейнер должен видеть только потоки SPE, созданные им самим.
- Скорректировать виртуальную файловую систему, реализованную в ядре Linux 2.6 (sysfs). В /sys/devices/system/spu в sysfs внутри контейнера должны содержаться правильные записи каталогов для каждого SPU, выделенного ему. libspe2 использует эти записи каталогов для подсчёта SPU, доступных внутри контейнера.
- Изменить планировщик SPU. Необходимо изменить планирование SPU таким образом, чтобы потоки SPE, созданные внутри контейнера, работали только на SPU, выделенных этому контейнеру.
- Изменить инструменты OpenVZ. Инструмент vzctl из пакета инструментов OpenVZ должен поддерживать выделение SPU контейнерам и наоборот, освобождать SPU от контейнеров. Выделение и освобождение должны функционировать во время работы контейнера.
Понятие общих виртуализованных устройств означает, что устройство доступно всем контейнерам, как показано на рисунке 4.
Рисунок 4. Общая виртуализация SPU
Нам нужен механизм, который будет контролировать, какой частью устройства владеет контейнер или в течение какого времени всё устройство будет доступно контейнеру. Поскольку SPU невозможно разделить на части физически, контейнеры используют SPU с разделением по времени доступа.
В рамках нашей реализации должны выполняться следующие четыре действия:
- Виртуализовать spufs. spufs должна быть доступна внутри контейнеров, но каждый контейнер должен видеть только потоки SPE, созданные им самим.
- Скорректировать sysfs. В папке /sys/devices/system/spu в sysfs внутри контейнера должны содержаться правильные записи каталогов. Лучшим решением будет наличие контейнеров, у которых есть доступ ко всем SPU, установленным в системе, поэтому в директории /sys/devices/system/spu будут одинаковые записи как на базовой системе, так и во всех контейнерах.
- Изменить планировщик SPU. Планировщик SPU необходимо изменить таким образом, чтобы потоки SPE, созданные внутри контейнера, имели доступ только к SPU, доступным в системе на определенный момент времени. Для потоков SPE может быть разработан алгоритм планирования, схожий с двухуровневым равномерным планировщиком центрального процессора, который реализовала команда OpenVZ для обычных процессов. Можно внедрить даже полностью новый алгоритм планирования.
- Изменить инструменты OpenVZ. Инструмент vzctl из пакета инструментов OpenVZ должен поддерживать установку времени выполнения SPU для каждого контейнера. Этот параметр должен быть изменяем во время работы контейнера.
Теперь немного о 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
Исполняемый файл 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.
На рисунке показана библиотека управления SPE в реальном времени (libspe), работающая в пространстве пользователя, которая использует файловую систему spufs, реализованную в пространстве ядра.
Изначально 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 - это модифицированное ядро 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.
Научиться
- Оригинал статьи "Cell/B.E. container virtualization, Part 1 (EN)"
- Подпишитесь на канал RSS для получения уведомлений о новых статьях в этой серии. (Подробная информация о каналах RSS для контента developerWorks.)(EN)
- Описание OpenVZ и виртуализации можно найти в работе "Виртуализация в Linux" (сентябрь 2006 г.), которая связывает три наиболее популярных подхода к виртуализации (эмуляция, паравиртуализация и виртуализация на уровне ОС) и OpenVZ. (EN)
- Познакомьтесь со статьёй Арнда Бегмана "Spufs: синергический процессор Cell как виртуальная файловая система" (developerWorks, июнь 2005 г.), где изложена подробная информация об интерфейсе файловой системы SPU, который позволяет Linux работать на платформе Cell/B.E. Статья Бегмана "Как не изобрести интерфейсы ядра" (статья на конференцию LinuxConf Europe, июль 2007 г.) объясняет, как выбрать форму интерфейса пространства пользователя для использования в коде ядра. Бергман также ведет виртуальный учебный курс по Linux на платформе Cell/B.E., который охватывает модель формирования потоков, стратегию работы Linux в реальном времени, требования к работе PPU/SPU, spufs, обработку сигналов и многое другое.(EN)
- В презентации Дэниэля Хакенберга "Измерение производительности систем Cell SMP" (для конференции Центра информационных служб и высокопроизводительных вычислений, посвящённой кластерам Cell/B.E., май 2007 г.) приведен анализ показателей производительности операций по умножению матриц, полосе пропускания DMA к XDR и полосе пропускания DMA между SPE. (EN)
- Познакомьтесь с презентацией Дака Вьянни "Модель создания программных решений Cell" (март 2006 г.), где рассмотрены вопросы модели программирования для Cell/B.E., сравнение моделей, основанных на PPE и SPE, перенос функциональной нагрузки, перекрытие DMA и вычислений, а также гетерогенная многопоточность.(EN)
- Основные понятия виртуализации описаны на примере обычных шаблонов в "Справочнике по виртуализации" (developerWorks, июнь 2006 г.). mВиртуальный Linux" (декабрь 2006) - описывает различные виды виртуализации (а также текущие проекты виртуализации) с точки зрения Linux. (EN)
- Дополнительную информацию о паравиртуализации можно найти в статьях "Виртуализация в coLinux" (developerWorks, март 2007 г.) и "Эмуляция систем с помощью QEMU" (сентябрь 2007 г.). (EN)
- Изучите серию кратких вводных руководств в блоге по SDK 3.0: (EN)
- Введение в среду Accelerated Library Framework (ALF)
- Иллюстрация 10 наиболее важных понятий ALF
- Введение в службы библиотеки Data Communication and Synchronization (DaCS)
- Изучите статью "Изменения в libspe: как libspe2 влияет на программирование Cell Broadband Engine" (developerWorks, июль 2007 г.), где приводится описание libspe2 и способов организации базового управления процессами SPE и связи с libspe2. (EN)
- В статье "Введение в многопроцессорные системы Cell"
в журнале IBM Journal of Research and Development, 2005 г.) приводится обзорное введение в историю многопроцессорных систем Cell/B.E., целей и трудностей программы, проектных решений, программных и архитектурных моделей, а также реализаций.(EN)
- Обратите внимание на другие ресурсы developerWorks, которые могут вас заинтересовать в связи с виртуализацией, в том числе на раздел Linux и раздел Open Source.
- Чтобы подробнее узнать о программировании Cell/B.E., познакомьтесь со следующими сериями статей developerWorks: (EN)
- "Программирование высокопроизводительных приложений на процессоре Cell/B.E. "
- "PS3: с фабрики в лабораторию"
- "Небольшой широкополосный механизм, который может все"
- Множество руководств, спецификаций и других материалов можно загрузить из раздела документации Cell Broadband Engine технической библиотеки IBM Semiconductor Solutions. (EN)
- Подпишитесь на новостную рассылку developerWorks и получайте по почте последние новости для разработчиков и о событиях Cell/B.E. каждую неделю. Если вы хотите подписаться на новости Cell/B.E., отметьте раздел Power Architecture.(EN)
Получить продукты и технологии
- Скачайте "Руководство пользователя OpenVZ" версии 2.7.0-8 от компании SWsoft.
- Попробуйте новый инструментарий для анализа производительности LMbench, в который входят инструменты кросс-платформенного контроля производительности различных систем UNIX.(EN)
- Используйте пример кода, который выполняет быстрое преобразование Фурье с единичной точностью на 4 потоках команд с множеством потоков данных
в среде Cell/B.E. с сайта Power.org. (EN)
- Следите за основными этапами разработки Cell/B.E., включая выпуск новейшего Cell/B.E. SDK: SDK для многоядерной архитектуры версии 3.0.
Для его поддержки существует даже библиотека документации(EN)
.
- Все статьи, форумы, материалы для загрузки и многое другое, относящееся к Cell/B.E., на IBM developerWorks Ресурсный центр Cell Broadband Engine: - основной ресурс по всем вопросам, связанным с Cell/B.E. (EN)
- Свяжитесь с IBM по вопросам специальных решений на базе Cell/B.E. или специальных процессоров.(EN)
Обсудить
- Примите участие в обсуждении материала на форуме.
- Задавайте вопросы на форуме OpenVZ.(EN)
- Посетите форум архитектуры Cell Broadband Engine, если хотите получить ответы на технические вопросы о процессоре. Интересные вопросы и ответы из форумов можно найти в периодических обзорах в серии блога "Наблюдаем за форумом".(EN)
- Новости, материалы для загрузки, инструкции и уведомления о событиях, связанных с Cell/B.E. и другими технологиями Power Architecture, можно найти в блоге Power Architecture. Здесь можно найти популярную серию блога "Наблюдаем за форумом" (подборка вопросов и ответов), технические сообщения серии "FixIt", а также краткие технологические обзоры Infobomb. (EN)
Кристиан Кайзер (Christian Kaiser) изучает вычислительную технику в университете RWTH в Ахене в Германии. В 2007 году он проходил стажировку в исследовательской лаборатории IBM в Германии, в городе Бёблинген. Во время стажировки в IBM он исследовал методы виртуализации для процессора Cell Broadband Engine. После завершения стажировки Кристиан Кайзер начал работу над диссертацией на кафедре операционных систем в университете RWTH в Ахене. Тема его диссертации - "Анализ коллективной асинхронной связи в высокоскоростных сетях, организованных в памяти"
Кристиан Рунд (Christian Rund) - сотрудник исследовательской лаборатории IBM в Бёблингене, в Германии. Он изучал теорию вычислительных систем в университете Штутгарта и в Упсальском университете в Швеции, закончив обучение в 1997 году. Во время учебы он проходил стажировку в IBM в Херренберге и Штутгарте в Германии. В 1998 году он поступил на работу в департамент разработки систем банка Landeszentralbank в Штутгарте (Deutsche Bundesbank). В 2001 году Кристиан перешел в команду разработчиков канала FCP zSeries корпорации IBM в качестве исследователя-разработчика. С середины 2006 года он занимается исследованием и разработкой микропрограммного обеспечения хост-контроллера Cell/B.E.