Cell/B.E. コンテナーの仮想化: 第 1 回 概念とアーキテクチャー、そしてツール

オープンソースのプロジェクト、OpenVZ による Cell/B.E. プラットフォームでのソフトウェア・ベースのコンテナー仮想化について、その概念を学ぶ

この 3 回連載の記事では、コンテナー仮想化 (オペレーティング・システム仮想化) として知られる、ハードウェア・リソースを中心としたソフトウェア仮想化について説明し、オープンソースのプロジェクトである OpenVZ を介してコンテナー仮想化の例を示します。ソフトウェアによる手法を使った Cell/B.E. プロセッサーの仮想化に必要なコンポーネントと手法のすべてを包括的に概説する連載の第 1 回目では、Cell/B.E. プロセッサーの仮想化に関連する基本概念、そして OpenVZ および Cell/B.E. アーキテクチャーの特徴と Cell/B.E. 上で OpenVZ がどのようにして動作するかを説明するとともに、OpenVZ ツールの一部を紹介します。

Christian Kaiser (christian.kaiser1@rwth-aachen.de), Research Intern, IBM

Christian Kaiser は、ドイツ・アーヘンにある RWTH University でコンピューター工学を学び、2007年に研修生としてボーブリンゲンの IBM Germany Research Lab に勤務しました。IBM での研修期間中に研究したのは、Cell Broadband Engine プロセッサーを対象とした仮想化の手法です。この研修期間の後、彼は RWTH Aachen の Chair for Operating Systems で論文に取り組むため大学に戻りました。論文のテーマは、「Analysis of asynchronous collective communication in memory-coupled high-speed networks」です。



Christian Rund (Christian.Rund@de.ibm.com), Research and Development Engineer, IBM

Christian Rund は、ドイツ・ボーブリンゲンの IBM Development Laboratory に勤務しています。彼は University of Stuttgart とスウェーデンの Uppsala Universitet でコンピューター・サイエンスを学び、1997年に卒業しました。学生時代にドイツのヘレンベルグとシュトュットガルトの IBM で研修生として勤務した経験を経て、1998年にシュトュットガルト所在の Landeszentralbank (Deutsche Bundesbank) システム開発部門の一員となりました。zSeries FCP チャネル開発チームの研究開発技術者として IBM に入社したのは 2001年です。その後、2006年中頃からは Cell/B.E. ベースのサーバー向けホスト・ファームウェアの研究開発技術者として活躍しています。



2007年 12月 11日

はじめに

仮想化は革新的な技術です。なかでもソフトウェア仮想化は、2007年に最もよく取り上げられた IT 世界の話題の 1 つです。この 3 回の連載で取り上げるのは、Cell Broadband Engine プロセッサーをハードウェア・リソースに関して効率的に仮想化する方法、いわゆるコンテナー仮想化 (別名、オペレーティング・システム仮想化) です。さらに、コンテナー仮想化の機能を Linux® で実現するオープンソースのソフトウェア・プロジェクト、OpenVZ プロジェクトについても説明します。OpenVZ に相当する市販の製品は、SWsoft Inc. の Virtuozzo です。

この連載では、ソフトウェアによる手法で Cell/B.E. プロセッサーを仮想化するためには何が必要なのかを明らかにしていきます。その過程のなかで、Cell/B.E. プラットフォームをコンテナー環境内で使用するために変更しなければならない OpenVZ Linux カーネルのインターフェースを紹介し、Cell/B.E 環境でのコンテナー仮想化の効率性を実証する測定レポートも記載します。


OpenVZ と Cell/B.E. プロセッサーとの関係について理解する

OpenVZ とは、コンテナー仮想化のサポートを Linux にもたらすオープンソース・ソフトウェアの実装であり、以下の 2 つのコンポーネントで構成されています。

  • OpenVZ Linux カーネル
  • OpenVZ ユーザー空間ツール

OpenVZ プロジェクトの主な目標は、仮想 Linux オペレーティング・システムのインスタンスを実行する複数の独立したコンテナーを作成することです。すべてのコンテナーは共通して 1 つの仮想化されたカーネルにアクセスします。このカーネルを提供するホスト・システムが、仮想化された、いわゆる 4 つのコア・デバイス (CPU、メモリー、ディスク空間、ネットワーク) を扱います。1 つのデバイスをコンテナーに直接渡し、そのデバイスにはホスト・システムからも、そのデバイスを所有するコンテナーを除くすべてのコンテナーからもアクセスできないようにすることも可能です (つまり、専用デバイス割り当て)。

図 1 には、独立した 3 つのコンテナー・インスタンス (VS-1、VS-2、VS-3) を示してあります。この 3 つのコンテナーはいずれも同じ OpenVZ Linux カーネルを共有しています。「参考文献」を参照してください。

図 1. 独立した 3 つのコンテナー・インスタンス
独立した 3 つのコンテナー・インスタンス

読者の皆さんはすでに Cell/B.E. プロセッサーについてはよくご存知のことでしょう。Cell/B.E. プロセッサーはサード・パーティー製品で使用されており、ハイブリッド・スーパーコンピューターから、高速分散処理用に特化した CAB (Cell Accelerator Board)、そして Sony Playstation 3 のゲーム・コンソールに至る機器までが Cell/B.E. プロセッサーによって実行されています。このプロセッサーは汎用 Power Architecture™ コアに、マルチメディア・アプリケーションとベクトル・アプリケーションの大幅な高速化を実現するために合理化されたコプロセッサーである SPU (Synergistic Processing Unit) を組み合わせたものです。SPU あたりの単精度浮動小数点演算のパフォーマンスが 25.6 GFLOPS であることから、Cell/B.E. プロセッサーはチップ上のスーパーコンピューターとも呼ばれています。

図 2 は、Cell/B.E. プロセッサーの基本アーキテクチャーの概要です。

図 2. Cell/B.E. プロセッサーの基本アーキテクチャー
Cell/B.E. プロセッサーの基本アーキテクチャー

基本アーキテクチャーを構成するのは、1 基の PPE (Power Processing Element) と 8 基の SPE (Synergistic Processing Element) です。従来のメモリー・サブシステムを持つ PowerPC コアを取り入れた PPE は、EIB (Element Interconnect Bus) と呼ばれる帯域幅の広い内部コネクターによって SPE と接続されます。それぞれの SPE を構成するのは、SPU と、命令および SPE のデータを保持する 256KB の LS (Local Store)、そしてシステムのメイン・メモリーと SPE の LS 間で DMA 転送を行う MFC (Memory Flow Controller) です。PPE はオペレーティング・システム以外にはサービスを提供しません。現時点でこれらの Cell/B.E. の機能を利用しているオペレーティング・システムは、Linux のみです。


コンテナー仮想化と Cell/B.E. プロセッサーとの関係について理解する

図 3 に、Cell/B.E. プロセッサーのパーティショニングを図解します。

図 3. Cell/B.E. プロセッサーのパーティショニング
Cell/B.E. プロセッサーのパーティショニング

コンテナーには、システム内にある利用可能な専用の物理 SPU へのアクセスが認められます。コンテナー内でアクセス可能な SPU には、その専用割り当て期間中、他のコンテナーやホスト・システムがアクセスすることはできません。コンテナーはそれぞれが所有する SPU のみを使用します。これを実装するには、以下の 4 つの作業が必要です。

  1. SPU ファイルシステム (spufs) を仮想化します。spufs はコンテナー内でアクセス可能になる必要がありますが、各コンテナーにはそれぞれが作成した SPE スレッドだけが見えるようにしなければなりません。
  2. 2.6 Linux カーネルに用意された仮想ファイルシステム (sysfs) を調整します。コンテナー内の sysfs には、それに割り当てられた SPU の /sys/devices/system/spu に正しいディレクトリー・エントリーが含まれていなければなりません。libspe2 はこれらのディレクトリー・エントリーを使用して、コンテナー内で利用可能な SPU の数をカウントします。
  3. SPU スケジューラーを変更します。SPU スケジューリングを変更し、コンテナー内に作成された SPE スレッドがそのコンテナー専用の SPU のみで実行するようにします。
  4. OpenVZ ツールを変更します。コンテナーの SPU を解放するには、OpenVZ ツールに含まれる vzctl ツールがコンテナーへの SPU 割り当てと割り当ての解放をサポートしなければなりません。割り当てと解放は、コンテナーの実行時に機能する必要があります。

共有仮想化デバイスという概念は、すべてのコンテナーがデバイスにアクセス可能であることを意味します (図 4 を参照)。

図 4. SPU の共有仮想化
SPU の共有仮想化

共有仮想化には、特定のコンテナーがアクセス可能なデバイスの部分、あるいはデバイス全体にアクセスできる時間を制御するメカニズムが必要です。1 つの SPU を部分的に共有可能にすることはできないため、複数のコンテナーはその SPU にアクセス可能な期間、SPU を共有します。

共有仮想化の実装は、4 つのステップに従って行います。

  1. spufs を仮想化します。spufs はコンテナー内でアクセス可能になる必要がありますが、各コンテナーにはそれぞれが作成した SPE スレッドだけが見えるようにしなければなりません。
  2. sysfs を調整します。コンテナー内の sysfs には、/sys/devices/system/spu に正しいディレクトリー・エントリーが含まれていなければなりません。より賢いソリューションは、システムにインストールされたすべての SPU にコンテナーがアクセスできるようにして、ホスト・システム上とすべてのコンテナー内で /sys/devices/system/spu ディレクトリーに同じエントリーが含まれるようにすることです。
  3. SPU スケジューラーを変更します。SPU スケジューラーを変更して、コンテナー内で作成された SPE スレッドが、システム内で利用可能な SPU に一定の期間だけアクセスできるようにします。SPE スレッド用には、OpenVZ チームが通常のプロセス用に実装した 2 段階の Fair CPU Scheduler と同じようなスケジューリング・アルゴリズムを設計することができます。あるいはまったく新しいスケジューリング・アルゴリズムをデプロイすることも可能です。
  4. OpenVZ ツールを変更します。OpenVZ ツールに含まれる vzctl ツールは、コンテナーごとの SPU 実行時間の設定をサポートする必要があります。この設定は、コンテナーの実行時に変更可能でなければなりません。

ここで、spufsについて多少説明しておきます。

spufs を使用する

spufs は、よく知られた仮想ファイルシステム (VFS) である procfs に匹敵します。procfs は、プロセスを簡単な方法で表すために設計された Linux 初の抽象ファイルシステムです。procfs が CPU で実行されるプロセスを表す一方、spufs は Cell/B.E. プロセッサーの SPU で実行されるスレッドを表します。

spufs は特殊な用途のファイルシステムで、Cell/B.E. プロセッサー上で SPU を制御するために開発された VFS です。spufs 内の各ディレクトリーは論理 SPE コンテキストを参照します。このような SPE コンテキストは物理 SPE と同じように扱われ、コンテキストのプロパティーはディレクトリーに含まれるファイルとして表現されます。SPE コンテキストへのアクセスでは、実際の SPE を操作することもあれば、メモリー内に保存された SPE の状態を操作することもあります。SPU プログラムを起動するには、SPU ELF 実行可能ファイルを SPE の LS にコピーし、それから spu_run システム・コールを実行します。

Cell/B.E. の SPU で実行するプログラムなど、Linux で Cell/B.E. 固有のコードを実行する場合には、spufs を使用する必要があります。Linux で Cell/B.E. の SPU を使用するプロセスを起動するには、これ以外の方法はありません。

リスト 1 を見るとわかるように、ls コマンドを実行する前に、Cell SDK の FFT (高速フーリエ変換) のサンプル・プログラムが 2 つの SPE スレッドで実行されています。/spu は、spufs のマウント・ポイントです。

リスト 1. 2 つの SPE スレッドによる Cell SDK の高速フーリエ変換サンプルの実行
[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 スレッドごとに 1 つのディレクトリー (kobject) があり、ディレクトリー名にはプロセス ID (PID) と SPE スレッドのスレッド ID が含まれていることがわかります。2 番目のコマンドの出力には、両方のディレクトリー内にあるファイルが示されています。

図 5 に、2 種類の ELF 実行可能ファイルがそれぞれどのように処理されるかを示します。

図 5. 2 種類の ELF 実行可能ファイルの処理方法
2 種類の ELF 実行可能ファイルの処理方法

SPE オブジェクト・ファイル (SPE object files) という形式での SPE 実行可能ファイルは、物理 SPE (Physical SPEs) 上で実行される SPE スレッド (SPE threads) によって処理されます。物理 SPE でいつ、どの SPE スレッドを実行するかを決定するのは、専用の SPE スケジューラーです。一方、PPE オブジェクト・ファイルは JS21 ブレード・サーバーなどの標準 PowerPC® アーキテクチャー・システムでの場合と同じように扱われます。PPE オブジェクト・ファイル (PPE object files) は、カーネル内に実装された Linux スケジューラーによってスケジューリングされる標準 Linux スレッドで処理されます。このように、PPE 上で実行されるアプリケーションには特に変わった点はありません。


Cell/B.E. SDK と libspe との関係について理解する

Cell/B.E. のソフトウェア開発キット (SDK) は現在、バージョン 3.0 が最新です (Cell resource center の Downloads で最新のコピーを入手してください)。Cell/B.E. SDK には、Cell/B.E. プロセッサーを活用したアプリケーションを開発するために必要なすべてのツールが揃っていますが、何よりもこの SDK で注目に値するのは、各種のコンパイラーおよびリンカー・スイート、開発を簡易化するライブラリー (libspe など)、そして Cell/B.E. アーキテクチャー固有の機能の使い方を実例で示す SPU、MFC、LS などのサンプル・プログラムが含まれている点です。

現時点で spufs を使用しているのは libspe のみです (libspe1 および libspe2 バージョン)。libspe は、SPE 上で実行する Cell/B.E. アーキテクチャー用コードを簡単に開発できるようにするフレームワークです。このフレームワークによって、ELF 実行可能ファイルが SPE の LS にコピーされ、さらに spu_run システム・コールが呼び出されるため、SPE 上で実行可能ファイルを起動するためのすべての内部処理について心配する必要はありません。

図 6 は、Linux で Cell/B.E. プロセッサーを使用するために実装されている拡張機能の階層です。

図 6. Cell/B.E. プロセッサーを使用するために Linux に実装された拡張機能の階層
Cell/B.E. プロセッサーを使用するために Linux に実装された拡張機能の階層

上記の図から、ユーザー空間内の SPE Management Runtime Library (libspe) はカーネル空間内に実装された spufs ファイルシステムを利用していることがわかります。


sysfs について理解する

sysfs は当初、カーネルが認識するすべてのデバイスとドライバーの概要を提供するという意図で、driverfs として Linux カーネルに導入されました。procfs に比べてはるかに簡潔にデバイスおよびドライバーにアクセスする方法となるように設計された sysfs は、kobject データ構造の階層を (それぞれをディレクトリーとして) 示すとともに、kobject 構造の一連の属性を示します。これらの属性は、通常はテキスト文字列にエンコードされた単一の値が含まれるファイルです。

例えば、リスト 2 は QS21 Cell/B.E. ブレードでの /sys/devices/system/spu ディレクトリーの内容です。

リスト 2. 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 ~]#

QS21 Cell/B.E. ブレードは、それぞれに 8 基の SPU を備えた 2 基の Cell/B.E. プロセッサーを保有するため、このブレード上に常駐する SPU は合計 16 基ということになります。ご覧のように、/sys/devices/system/spu ディレクトリーには SPU ごとに 1 つのディレクトリーが含まれます。libspe2 はこれらのディレクトリー・エントリーを利用して、システム内で利用可能な物理 SPU の数をカウントします。


OpenVZ カーネルについて理解する

OpenVZ カーネルは、独立した (オペレーティング・システムの) コンテナー環境を実現するために変更された Linux カーネルです。さらにこのカーネルは、コンテナーにリソース管理機能とチェックポインティング機能を提供します。それぞれのコンテナー、さらにはホスト・システムまでもが同じ共有仮想化カーネルを使用するという点を忘れないでください。

各コンテナーには、カーネルによって提供される独自のリソース・セットがあります。このセットには、例えば以下のリソースが含まれます。

  • ファイル: システム・ライブラリーおよびアプリケーション
  • 仮想化されたファイルシステム: procfs または sysfs
  • ユーザーおよびグループ: コンテナーごとに、固有のルート・ユーザー、さらにその他のユーザーとグループがあります。
  • プロセス・ツリー: 各コンテナーは、仮想化 PID (初期 PID は 1) を持つ、コンテナー独自のプロセスのセットのみを見ることができます。
  • ネットワーク: 固有の IP アドレス、ルーティング、フィルター・ルールを持つ仮想ネットワーク・デバイス
  • デバイス: 一部のデバイスは仮想化されます。必要な場合には、あらゆるコンテナーに実際の (仮想化されていない) デバイスへのアクセスが認められます。
  • IPC オブジェクト: セマフォー、メッセージ、または共有メモリー

リソース管理

リソース管理はリソースのタイプごとに行われます。

  • ディスク・クォータ: OpenVZ が導入する 2 段階のディスク・クォータでは、ディスク・スペースをコンテナーに制限できるため、コンテナーはその環境内で再度クォータを取得できます。
  • CPU スケジューラー: Fair CPU Scheduler も同じく 2 段階のメカニズムを使用します。これはコンテナーごとに構成可能なスケジューラーで、第 1 段階では CPU 時間のうちのどれだけを特定のコンテナーが使用するかを定義することができます。スケジューラーの第 2 段階では、コンテナー環境内でのプロセスのスケジューリングを行います。
  • ユーザー beancounter: コンテナー・リソースを制限および保証する一連のカウンターです。メモリーと各種カーネル内のオブジェクト (IPC 共有メモリー・セグメントやネットワーク・バッファーなど) を扱う約 20 のパラメーターがあります。

チェックポインティング

もう 1 つの主要な機能は、チェックポインティングです。チェックポインティングとリストアは、ライブ・マイグレーションには欠かせません。チェックポインティングとは、コンテナーをフリーズし、後でその完全な状態をディスク・ファイルに保存するプロセスのことです。一方、リストアはその逆のプロセスです。コンテナーのライブ・マイグレーションとは、1 つのホスト・システムでコンテナーのチェックポインティングを行い、別のホスト・システムでそのコンテナーのリストアを行うプロセスを指します。

図 7 に、ライブ・マイグレーションのプロセスとチェックポインティングおよびリストア・プロセスの違いを示します。

図 7. ライブ・マイグレーションのプロセスとチェックポインティングおよびリストア・プロセスの違い
ライブ・マイグレーションのプロセスとチェックポインティングおよびリストア・プロセスの違い

図 7 に表わされているように、ライブ・マイグレーションは単一のアクションからなるプロセスですが、チェックポインティングおよびリストアは 2 つの異なるアクションで、このプロセスには両方のハードウェア・ノードからアクセスできる記憶装置がもう 1 つ必要になります。


vzctl とその他の OpenVZ ツールを使用する

主要な OpenVZ ツールである vzctl は、コンテナー環境を管理するためのコマンドラインによる上位インターフェースです。vzctl を使って実行できるのは、仮想オペレーティング・システム環境の作成、起動、停止、破棄で、これはコンテナー・ライフサイクルと呼ばれます。

vzctl は、コンテナー環境が利用できる IP アドレス、メモリー、あるいは CPU 時間などの各種コンテナー・リソースを変更するために使用することもできます。これらのパラメーターのほとんどは、コンテナーの実行時に設定、変更することができます。このような変更は他の仮想化技術、例えばプラットフォーム仮想化では通常、不可能です。

vzctl ツールを起動できるのはホスト・システムからだけで、コンテナー内部からは起動できません。

vzctl の他にも、OpenVZ コンテナーを管理するツールはたくさんあります。Cell/B.E の仮想化に関しては、OpenVZ にツールは必要ないので、コンテナー環境の一般的な管理についての詳細は OpenVZ User's Guide (「参考文献」を参照) を調べてください。また同時に、この連載の著者によるハンドブック、『OpenVZ on POWER™』も参考にしてください。


第 2 回の予告

第 2 回の記事では、図 3 に記載した専用仮想化 (パーティショニング) の概念に対応した実装に話題を絞ります。


謝辞

図 1 で画像を使わせていただいた「Mehrarbeit fur CPUs」(Linux Magazin、2006年4月) の著者に大変感謝いたします。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Multicore acceleration, Open source, Linux
ArticleID=283809
ArticleTitle=Cell/B.E. コンテナーの仮想化: 第 1 回 概念とアーキテクチャー、そしてツール
publish-date=12112007