nkjmkzk.net

SSDではデータを書き込む際に素子を包む絶縁体が摩耗していき、この摩耗がいわゆる「SSDの寿命」につながっています。

プロダクション環境でSSDを搭載したサーバを運用する場合は、当然この寿命を定期的に監視しておきたいでしょう。実際、SSDを本番導入できないユーザの多くは膨大な容量が必要になる環境を運用しているか、HDDにはなかった寿命というdeadlineに不安をおぼえていることがほとんどだと思います。しかし稼働部品のないSSDはHDDに比べて衝撃に強く耐障害性が高いことが期待できます。なので寿命さえマネージできればSSDは恐るるに足らずということになります。

SSDの寿命確認について、今のところ各ベンダー間で統一したパラメータが提供されているわけではなく、S.M.A.R.T.に独自のパラメータをもたせて寿命確認の指標としているようです。

今回はIntel X25-Mでの寿命確認方法を紹介しておきます。IntelさんもS.M.A.R.T.にパラメータを持たせています。より公式な方法はIntelさんが提供するIntel SSD ToolBoxをインストールしてこのツールでS.M.A.R.T.のパラメータを引っぱってくるというやり方ですが、残念ながらIntel SSD ToolBoxは現時点ではWindows版しかないようです。僕は宗教上の理由でWindowsは使っていないのでLinuxで使えるsmartmontoolsを使ってこのパラメータを取得することになります。

まず、もしsmartmontoolsがインストールされていない場合はインストールします。大抵のディストリビューションではベースレポジトリにあるはずです。

X25-Mが差さっているマシンでsmartmontoolsをインストールしたら、smartctlコマンドでパラメータを確認できます。下記は/dev/sdaがSSDだという前提でのコマンド実行例です。

[root@~]# smartctl -a /dev/sda

smartctl 5.39.1 2010-01-28 r3054 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     INTEL SSDSA2M080G2GC
Serial Number:    CVPO0082023A080BGN
Firmware Version: 2CV102HD
User Capacity:    80,026,361,856 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 1
Local Time is:    Wed Sep  8 11:39:26 2010 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever
					been run.
Total time to complete Offline
data collection: 		 (   1) seconds.
Offline data collection
capabilities: 			 (0x75) SMART execute Offline immediate.
					No Auto Offline data collection support.
					Abort Offline collection upon new
					command.
					No Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 (   1) minutes.
Conveyance self-test routine
recommended polling time: 	 (   1) minutes.

SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0020   100   100   000    Old_age   Offline      -       0
  4 Start_Stop_Count        0x0030   100   100   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       2807
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       46
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       22
225 Load_Cycle_Count        0x0030   200   200   000    Old_age   Offline      -       22301
226 Load-in_Time            0x0032   100   100   000    Old_age   Always       -       573
227 Torq-amp_Count          0x0032   100   100   000    Old_age   Always       -       3
228 Power-off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       4278423803
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   099   099   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   099    Pre-fail  Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

Note: selective self-test log revision number (0) not 1 implies that no selective self-test has ever been run
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

赤字の部分が寿命に該当するパラメータです。これらのパラメータをIntelさんのサイトから引用させていただきました。

E8 Available Reserved Space Normalized 予約領域の残っている数を表す。正規化した (Normalized) 値は、100 パーセントを表す 100 から始まる。正常の範囲は 10 パーセントまで。
E9 Media Wearout Indicator Normalized 記録メディアであるフラッシュメモリーの使い込んだ程度を表す。平均消去回数が増えるにつれ、正規化した (Normalized) 値が 100 から 1 へ減少していく。

なお、smartmontoolsのバージョンが5.38以下の場合、これらのATTRIBUITE_NAMEはUnknownと表示されます。

運用方法としてはこれらの値をスクリプトでしきい値を設けて定期チェックする等が考えられるでしょう。

参考

• Intel SSDオプティマイザーとは？
• smartmontools

昨日、8/19に目黒雅叙園にてOracle Sun Technology Updateが開催されました。3Track x 3でセッションが開催され、各セッションは大きく分けてJavaとSolarisを扱う内容でした。その中でも最新情報の提供を行うようなセッションと、DTraceチュートリアルのような具体的な技術話とかなり幅広い内容が提供されたように思います。

僕はSolaris Trackに一日中入り浸っていましたので簡単にレポートしたいと思います。

B-1 Solaris開発環境のご紹介

大曽根 明さん

Mr.Solarisの異名をとる大曽根さんはOracle Solaris Operating Systemについてこれまでを振り返り、今後のロードマップを紹介しました。

次に新しいH/Wサポートメニュー「Premier Support for Systems」についても紹介しました。Premier Support for SystemsはH/Wの保守プログラムでありながら、同時にOracle Solaris, Oracle Enterprise Linux, Oracle VMが使いたい放題になることを説明。

また、ZFS, Containerについて概要を紹介し、特にZFSについては「非クラスター型で現在最強のファイルシステムだろう」と指摘。そしてSun Studioを使ったデモを披露する等幅広い内容をカバー。

B-2 開発環境でのSolaris ZFS

野崎 宏明さん

先のセッションで「最強」とされたZFSについて、こちらの@IT記事でもわかりやすい解説をされてる野崎さんからプレゼン。End-to-Endの整合性チェック機構、CoW等ZFSの根幹を成す内部アーキテクチャについて説明。

B-3 DTrace活用術

ZFSと並ぶSolarisの代表的な機構であるDTraceについて藤田さん、本間さんからプレゼン。

藤田 勇治さん

藤田さんはDTraceが何であるのか、どういった情報がとれて、どのように活用できるのかという全体象を事例を交えて紹介。端的で軽快なトークでDTraceのメリットを限られた時間ながら非常にわかり易く説明されていました。カーネルを特別なビルドオプション付きでコンパイルしたりする必要がない、特別な起動オプションもいらない、その場でほしい情報を動的に出力させることができる、ということがズドンと理解できる濃密な時間でした。

本間 大輔さん

本間さんはDTraceのHow toを紹介。「こういう情報をとりたいときは・・」という切り口で実際のスクリプトを見せて解説しながら出力結果を確認していくという実践的なセッション。持ち時間は30分足らずであるにもかかわらずDTraceのサンプルスクリプトを含む実用的な資料を120枚作成するというパッション。事実、この資料はこれからDTraceを使ってみたい！という人にはバイブルでしょう。必見です。バイブルのダウンロードはこちら。
DTrace活用術

特別企画トークライブ：「2020年に向けてITエンジニアはどうやって生き残るか？」

ウルシステムズ（株）の漆原様、（株）Preferred Infrastureの太田様、クックパッド（株）大野様によるパネルディスカッション。モデレータは弊社の伊藤さん。
はっきり言って、かなり面白いディスカッションでした。何が面白かったかというと、みなさんそれぞれ強い信念をお持ちで、その信念が名言となって出てくるとことです。僕が特に印象に残った名言を下記に挙げさせていただきました。

• 製品や技術にコミットするかどうかは開発者に会って決める。信頼できるヤツならいける。（漆原様）
• めちゃ難しいプロジェクトを社員に任せる。できたら、目一杯給料を払ってあげる。それを繰り返す。（漆原様）
• 今日欲しいと言われたものは明日提供できなければそこに感動はない。（大野様）
• やりたいことをやる。やりたくないことはやらない。やりたいことを宣言する。（大野様）

それぞれ深い思考や経験を元にしたパワフルな持論です。共感する部分や「なるほど〜」な気付きもあり、非常に有益な時間だったと思います。

個人的には今後SunのテクノロジーとOracleのテクノロジーの合体技をより具体的に訴求するようなセミナーをやりたいなと思っています。Solaris, ASM, ZFS、このあたりがキーワードになるでしょう。楽しくなりそうです。

Linux環境のiscsi-initiator-utilsを用いた際に重要となるタイムアウト関連の設定について。

信頼性の高いシステムでは当然iSCSIストレージへの接続も冗長化するという要件があります。汎用的な実装だとdevice-mapper-multipathを使ってストレージネットワークの障害に対しての冗長構成でとることができます。また、OracleのASMを使ったStorage GRID構成では複数ストレージをストライピング＆ミラーリングし、例えストレージが筐体ごとパワーダウンしてもオンラインで処理を継続することができます。このStorage GRID構成で重要なのがiSCSI Initiatorのタイムアウト設定です。

iSCSIストレージへの接続性に不具合が発生した場合、iSCSI Initiatorが死活監視によってそれを検出します。最終的にはiSCSI InitiatorがiSCSI Targetへの接続障害という判定を行い、それをI/Oエラーという形でOSに報告します。ASMはその報告をもってストレージの切り離しを行い、残るストレージで処理を再開、継続します。障害が起こってからiSCSI InitiatorがI/Oエラーを報告するまでの間は全てのI/Oが一旦保留されます。本番環境ではこの保留される時間を制御したいという要件が出てくるでしょう。

下記のような障害パターンで上記の保留期間を制御するためのiSCSI Initiator設定を紹介します。

• クライアント側のNIC故障
• iSCSIネットワーク断（ケーブル劣化、スイッチ故障）
• iSCSIストレージのパワーダウン、コントローラ故障

ちなみにiSCSI InitiatorはOracle Enterprise Linux 5.4にバンドルされるiscsi-initiator-utils-6.2.0で動作を確認しています。前後のバージョンでもデフォルト値は変更されている可能性はありますが、挙動に大きな違いはないと思います。

重要なパラメータは下記の3つです。

• node.conn[0].timeo.noop_out_interval（デフォルト5秒）

pingによるコネクションの死活監視間隔

• node.conn[0].timeo.noop_out_timeout （デフォルト5秒）

pingによるコネクションの死活監視がコネクションエラーと判定するまでの待ち時間

• node.session.timeo.replacement_timeout（デフォルト120秒）

コネクションエラーが発生してからI/Oエラーを返すまでの待ち時間。この時間までに死活監視がコネクション復帰を報告すればI/Oエラーは返らない。

デフォルト設定で障害が発生した場合、下記のような流れとなります。

1. 死活監視のpingが発行される（タイミングによって障害発生から1〜5秒経過）
2. pingがタイムアウトする（+5秒経過）
3. 継続して死活監視のpingが発行され、最終的にpingが成功しないとOSにI/Oエラーが返る（+120秒経過）
4. ASMがI/Oエラーを検出して障害ストレージを切り離し、残りのストレージで処理を再開する（即時）

経過時間をまとめると、(1〜5）+ 5 + 120 = 126〜130秒程の時間が切り替えまでに必要となります。

これを例えば障害試験等で確実に15秒程で切り替えを発動させたい場合は次のように設定すれば実現できます。

• node.conn[0].timeo.noop_out_interval = 1

• node.conn[0].timeo.noop_out_timeout = 5

• node.session.timeo.replacement_timeout = 10

この場合経過時間は（〜1）+ 5 + 10 = 15〜16秒となります。

このiSCSI Initiatorのパラメータ設定は下記のiscsiadmコマンドで設定できます。ただし、ログイン済みのセッションについては反映されません。反映させるには一旦ログアウトし、再度ログインしてセッションを再確立させる必要があります。

[root@~]# iscsiadm -m node -p [ターゲットのIP] -o update -n [パラメータ名] -v [設定値]

また、/etc/iscsi/iscsid.confを編集しておくことで新たに登録されるiSCSIターゲットについてのデフォルト値を変更することができます。これは既に登録されているiSCSIターゲットには反映されないので注意してください。

概要

• self-ballooningはゲストOS自らメモリをある条件に基づいて動的に返却する／獲得ことによって実質的にメモリをオーバーコミットするための仕組み
• xenballoondはゲストOSで動くbashベースのデーモン。これがself-ballooningを制御する
• xenballoondはdom0へのメモリ情報提供を担うことも計画されている
• xenballoondは/proc/meminfoのCommitted_ASの値をベースに最低限必要なメモリ容量を判別する

環境

• Xen: 3.4.0(Oracle VM Server 2.2.1)及び4.0.0(Fedora 12)で確認
• ゲストOS: Oracle Enterprise Linux 5.4 x86_64

セットアップ方法

Xen側には特殊な設定は必要ありません。すべてゲストOSでの作業です。

まず、ゲストOS上でxen-4.0.0.tar.gzをxen.orgからダウンロードし展開します。これはxenのtarボールの中に必要なスクリプトがあるからです。（恐らくXen 3.3以降であれば必要なツールが含まれているはず）

[root@guest]# tar xvfz xen-4.0.0.tar.gz

展開されたディレクトリ中から3つのファイルをそれぞれインストール（コピー）する

[root@guest]# cp xen-4.0.0/tools/xenballoon/xenballon.conf /etc/sysconfig/
[root@guest]# cp xen-4.0.0/tools/xenballoon/xenballond /usr/bin/
[root@guest]# cp xen-4.0.0/tools/xenballoon/xenballond.init /etc/init.d/xenballoond

bashファイルを実行可能なようにパーミッションを変更する

[root@guest]# chmod 755 /usr/sbin/xenballoond
[root@guest]# chmod 755 /etc/init.d/xenballoond

必要に応じて設定ファイルを編集する

[root@guest]# vi /etc/sysconfig/xenballoon.conf

＊特にXENBALLOON_SELF=falseはtrueに変更する必要がある

xenballoondデーモンを起動する

[root@guest]# service xenballoond start

検証結果

• self-ballooning有効化によって動的にメモリ容量が縮小されるか？ => yes
• self-ballooning有効化によって動的にメモリ容量が拡張されるか？ => yes（ただしユーザプロセスがメモリを予約した場合。page cacheでは拡張は発動しない）

使用したツール

mem_allocate.c（メモリを確保し、60秒後に解放するツール。適当に作った。）

#include
#include
#include 

int main(int argc, char **argv) {
       char *str;
       int i;

       if (argc == 2) {
               sscanf(argv[1], "%d", &i);
               printf("Allocating %d Bytes for 60 seconds...\n", i);
               str = (char *)malloc(i);
               memset(str, 1, i);
               sleep(60);
               free(str);
       } else {
               printf("This program needs exactly 1 argument.\nYou can set the bulk of RAM to allocate with integer.\n");
       }
       return 0;
}

Demo

Reference

• xen-4.0.0/tools/xenballoon/xenballoond.README
• http://blog.xen.org/index.php/2008/08/27/xen-33-feature-memory-overcommit/
• http://www.xen.org/files/xensummitboston08/MemoryOvercommit-XenSummit2008.pdf

サーバ仮想化環境ではいろいろなリソースをオーバーコミットしてリソース稼働率を高めることができます。「オーバーコミット」は、本来的には物理リソース以上のリソースをさもあるかのようにみせかけて擬似的に割り当てることですが、サーバ仮想化環境で言う場合のオーバーコミットとは実際的には「リソースを共有すること」と考える方が正しい解釈であり、意義のある活用方法だと思います。

XenはCPUに関しては上図のようなオーバーコミットを古くからサポートしています。なので物理的なCPU数が仮想マシン収容数についてハードリミットとなることはありません。同様にネットワーク帯域やディスク帯域は共有することが基本的な考え方なのでこれらについても仮想マシン収容数のハードリミットになることはありません。しかしXenはメモリのオーバーコミットはサポートしないとしていました。したがって物理メモリは唯一仮想マシン収容数を制限するハードリミットということになります。

現在I/Aサーバ用サーバ仮想化技術において、メモリのオーバーコミットには大別すると下記のような実装方法があります。

• SWAPディスク
  • ディスクをメモリに模倣して仮想マシンに割り当てる
  • しかし実際はディスクなので堪え難い性能劣化が発生する
• 重複排除
  • 複数の仮想マシン間で重複するメモリを検出して一つにまとめる
  • 同一メモリページが多いと想定される環境（同一構成の仮想マシンを多数起動するような環境）では効果を期待できる
  • 重複判定処理にはオーバーヘッドが予想される。加えて、必ずしも重複排除できる可能性が高くない。
• メモリ動的増減（Self-Ballooning）
  • 仮想マシンが必要に応じて能動的にメモリを獲得、解放する
  • オーバーサイジングされている環境ではかなりの効果を期待できる
  • しかし動的なメモリの獲得・解放は必ずしも十分高速でない

実はXenはバージョン3.3からSelf-Ballooningを用いたメモリの実質的なオーバーコミットが利用可能となっています。（ゲストOS側にSelf-Ballooning用ツールをインストールし、デーモンを起動する必要があります。）厳密にはこれはオーバーコミットというよりメモリを「増減」させる機構ですが、結果的には各仮想マシンのドメイン定義ファイルで設定されているメモリ量の総和が物理メモリを超えることができ、オーバーコミットと同様の効果をもたらします。

Self-Ballooningを有効にするとゲストOSは下記のようなことが可能になります。

• 不要なメモリ領域（完全な空き、またはpage cacheに費やされている領域）を識別して能動的にメモリをXenに返却する　＊厳密には/proc/meminfoのCommitted_ASをベースに解放範囲を特定します
• メモリ確保が必要になった場合、Xenにメモリ割り当て要求を発行して能動的にメモリ領域を獲得する

xm mem-setコマンド等でdom0側からゲストOSのメモリ容量を調整することはよく行われていると思いますが、Self-BallooningではゲストOSが能動的にメモリ増減を行うというところが特徴的です。

ちなみに少し話しはそれますが、Xen 4.0.0においてman xmdomain.cfgをみると下記のように「Xenではメモリオーバコミットはできない」と明記されています。

Xen does not support overcommit of memory, so the total memory of all guests (+ 64 MB needed for Xen) must be less than or equal to the
physical RAM in the machine.

しかし、実際にはSelf-Ballooningによるオーバーコミットは可能です。Xen 4.0.0のtarボールに含まれるxenballoonのREADMEは下記のようにメモリオーバーコミットが可能であると記載されています。

Xenballoond runs in guest domains and both implements selfballooning and provides metrics to dom0 for (future) directed ballooning. Both capabilities provide a foundation for basic “memory overcommit” functionality.

このあたりは個々の開発者でオーバーコミットに対する定義に違いがあることも一因かもしれませんが、どちらかというとXenのmanがあまりきちんとアップデートされていないことが問題な気がします。

さておき、つまるところXenではSelf-Ballooningを用いたメモリオーバーコミットが可能なわけですが、Self-Ballooningには前述の通り「メモリの獲得・解放が高速でない」という問題があります。そして、この問題を解決する手段としてPVM用に「Transcendent Memory」という新機能がXen 4.0.0から組み込まれています。Transcendent Memoryをごく簡単に言うと「物理メモリを複数の仮想マシン間で共有する仕組み」です。

その実装はXenが余っているメモリを「Transcendenet Memory Pool」というプールにまとめ、そのプールを複数の仮想マシンがクラスタファイルシステムのようなイメージで共有するという仕組みです。ファイルシステムと違うところは仮想マシンは別仮想マシンがTranscendent Memory Poolに保存したデータを閲覧することは当然できないということです。

＊別途メモリのデータを共有できるタイプのPoolも実装が予定されています。

また、Transcendent Memoryにはいくつかの用途が考案されていますが現在実装されているのはpage cacheとして利用するという形です。Transcendent Memoryを有効にするには、Xen側で起動オプションを設定しておくことと、ゲストOS側のカーネルがTranscendent Memoryを有効にしてビルドされている必要があります。構築手順について詳しくは別のポストで解説しようと思います。

＊ちなみにXen 4.0.0ではPage Sharingという重複排除タイプのオーバーコミット機能も組み込まれています。こちらはHVMのみの対応です。

そしてTranscendent MemoryはSelf-Ballooningと併用することで威力を発揮します。つまりこうなります。

• Self-Ballooningによって仮想マシンは不必要なメモリを能動的に解放する
• 元々空き領域であったメモリやSelf-Ballooningによって解放されたメモリをXenが掻き集めて「Transcendent Memory Pool」を構成する
• 各ゲストOSは自身に最低限必要なメモリ（カーネルやアプリケーションによって予約されている領域）だけを自身の専有メモリとして保持し、その他必要となるメモリ（page cache）についてはTranscendent Memory Poolを利用する

ゲストOSが全てのメモリを専有する従来の形と比べて下記のようなメリットがあります。

まず、Self-Ballooningを有効にすることで多くの仮想マシンはメモリを解放し始めます。これによってよりサーバとして空きメモリが拡大し、より多くの仮想マシンを起動できるようになります。しかしこれだけだと各仮想マシンはメモリ不足によって、あるいはメモリを動的に獲得する処理が遅延することによって性能が劣化する可能性があります。この問題を解決するためにサーバ全体としてある程度の空きメモリを用意しておき、それを遅延なく必要に応じて割り当ててあげる仕組みがTranscendent Memoryです。サーバ全体としてメモリプールを持つことでゲストOSが個別にすべてのメモリを保持する形態よりも少ないメモリで効率的なキャッシングが可能になります。

もちろん環境によって効果に差異はあると思いますが、特にpage cacheを活用するファイルサーバ、アプリケーションサーバではこの二つを組み合わせることによって集約密度を上げながら性能劣化を抑えられる可能性があります。逆にpage cacheを活用しない傾向が強いデータベースサーバではTranscendent Memoryはそれほど効果がないでしょう。ただしSelf-Ballooningで不要なメモリを綺麗に削ぎ落として他の仮想マシンやTranscendent Memory Poolで利用できるようにすることは意義があると思います。

このSelf-BallooningとTranscendent Memoryついて具体的な構築手順を別ポストにて解説しようと思います。

先日公開されたubuntu-10.04 LTSはkernel-2.6.32を採用しており、かつ、pvopsが有効となっています。pvopsが有効になっているLinuxカーネルは同一のカーネルでベアメタル上、HVMとして、またPVMとして稼動することができます。なので今回はまずHVMとしてubuntuを作成し、それをPVMとして起動し直すという手法で進めてみます。環境は下記の通り。

• Xen : Oracle VM Server 2.2.1 (Xen 3.4.0)
• domU : ubuntu-10.04 x86_64

最初にubuntuをHVMとして作成します。これはubuntuのインストレーションISOファイルを使ってOracle VM Managerから作成できます。下図のような感じ。新しい紫のテーマが美しい。

ここはごく一般的な手順なので割愛します。

インストールが終わって再起動が完了したらネットワークまわりをセットアップしてdom0と通信できるようにします。疎通できるようななったら、ubuntuのカーネルとramdiskをdom0に転送します。

[root@ubuntu1004]# scp /boot/vmlinuz-2.6.32-21-generic dom0:/OVS/running_pool/ubuntu1004/
[root@ubuntu1004]# scp /boot/initrd.img-2.6.32-21-generic dom0:/OVS/running_pool/ubuntu1004/

転送が完了したら一旦ubuntuをシャットダウンします。そしてdom0側で仮想マシン定義ファイルをいじります。

[root@vmservero]# vi /OVS/running_pool/ubuntu1004/vm.cfg

＊修正後
kernel = 'vmlinuz-2.6.32-21-generic'
ramdisk = 'initrd.img-2.6.32-21-generic'
root = '/dev/xvda1 ro'
disk = [
'file:/var/ovs/mount/4ED5C364C05246FE8AEE8C0E26D79ACF/running_pool/ubuntu1004/System.img,xvda,w',
]
keymap = 'en-us'
memory = '1024'
name = 'ubuntu1004'
on_crash = 'restart'
on_reboot = 'restart'
uuid = '6fc94c0b-d902-476c-4c8b-0dfd3dadb315'
vcpus = 4
vif = [
'type=netfront, mac=00:16:3E:14:73:5A, bridge=xenbr0',
'type=netfront, mac=00:16:3E:16:E5:F2, bridge=xenbr1',
]
vfb = [ 'type=vnc,vncunused=1,vnclisten=0.0.0.0,vncpasswd=' ]

＊修正前
acpi = 1
apic = 1
builder = 'hvm'
device_model = '/usr/lib/xen/bin/qemu-dm'
disk = ['file:/var/ovs/mount/4ED5C364C05246FE8AEE8C0E26D79ACF/running_pool/ubuntu1004/System.img,hda,w',
]
kernel = '/usr/lib/xen/boot/hvmloader'
keymap = 'en-us'
memory = '1024'
name = 'ubuntu1004'
on_crash = 'restart'
on_reboot = 'restart'
pae = 1
serial = 'pty'
timer_mode = 0
uuid = '6fc94c0b-d902-476c-4c8b-0dfd3dadb315'
vcpus = 4
vif = ['type=ioemu, mac=00:16:3E:14:73:5A, bridge=xenbr0',
'type=ioemu, mac=00:16:3E:16:E5:F2, bridge=xenbr1',
]
vnc = 1
vncconsole = 1
vnclisten = '0.0.0.0'
vncpasswd = ''
vncunused = 1

そして仮想マシン(ubuntu)を起動します。起動後、lsmodコマンドでPVM特有のカーネルモジュールがロードされていることを確認します。

[root@ubuntu1004]# lsmod
Module                  Size  Used by
binfmt_misc             7960  1
ppdev                   6375  0
joydev                 11072  0
fbcon                  39270  71
tileblit                2487  1 fbcon
font                    8053  1 fbcon
bitblit                 5811  1 fbcon
xen_kbdfront            4249  0
softcursor              1565  1 bitblit
xen_fbfront             7225  2
fb_sys_fops             1611  1 xen_fbfront
sysimgblt               2547  1 xen_fbfront
sysfillrect             3949  1 xen_fbfront
xen_netfront           17890  0
syscopyarea             3640  1 xen_fbfront
lp                      9336  0
parport                37160  2 ppdev,lp
xen_blkfront           10697  3

逆に8139cpや8139tooといった物理NIC用のドライバはロードされていないことが確認できます。

例えば修正前の仮想マシン定義ファイルをhvm.cfg, 修正後をpvm.cfgとして保存しておけば起動するときにHVMとして起動するかPVMとして起動するか切り替えることが可能になります。仮想マシンそのものは同じもので。pvops、素敵ですね。

PCI-Passthroughとは、PCIデバイスをごっそりdomU（ゲストOS）に「あげちゃう」手法です。ちなみにPCIデバイスとは主にディスクコントローラであったり、HBAであったり、ネットワークカードであったり、あるいはグラフィックカードであったりします。わかり易くするためにPCIデバイスをディスクに絞って話を進めます。通常XenではディスクをdomUに割り当てる際にはdom0が物理ディスクを一度認識した上で、そのディスクリソースを分配する形でdomUに割り当てるVBD（Virtual Block Device）という形式をとります。

例えばサーバにSATAディスクが接続されているとします。これはオンボードまたは拡張PCIカードのSATAコントローラにSATAケーブルで接続されています。このディスクがdomUに認識される道筋を通常のVBD形式とPCI-Passthroughとで比較したのが下図です。

通常のVBD割り当て

• ディスク（PCIデバイス）はdom0によって管理され、複数のdomUで共有できる
• domUからのディスクアクセスはdom0を経由して物理デバイスに到達する（一般的に性能劣化が発生する）
• domUはデバイスドライバを使用しない（厳密にはdom0が提供するダミーデバイスと通信するためのドライバを使用する）

PCI-Passthroughの場合

• PCI-Passthrough対象のSATAコントローラ（PCIデバイス）はdom0に認識させない
• PCI-Passthroughを行うdomUがSATAコントローラ（PCIデバイス）を独占する
• PCI-Passthroughを行うdomUからのディスクアクセスはは自身のデバイスドライバを使用して直接SATAコントローラ（PCIデバイス）、ディスクに到達する（dom0経由によって発生していた性能劣化から解放される）
• domUとローカルマシンのデバイスとの静的な紐付けが行われるため、ライブマイグレーションが出来ないといった制約が発生する

ひとことで言えば、

• PCI-Passthroughを使用すればdomUのディスクアクセスは高速になるが、そのデバイスは一つのdomUによって独占されてしまう。

ということになります。環境によってこれが使えそうかどうかはそれぞれだと思いますが、SATAコントローラが丸ごと一つのdomU専用になってしまうのでは収容できる仮想マシンの台数が大幅に制限されてしまいます。

＊厳密には単一のSATAコントローラでもポートがハブ形式になっており複数のPCI識別子(BDF)が割り当てられていることもあるのでその場合はこの限りではない

仮想化とはそもそもH/WとOSを疎結合にすることが大きなメリットの一つでした。その中でPCI-Passthroughのような密結合を引き起こすコンフィグレーションはどのようなシチュエーションで有用なのでしょうか？

僕が考えるユースケースの一つはNASのバーチャルアプライアンスを稼動させる場合です。実際、NexentaStorのようにNAS（NFS, iSCSI）を仮想マシンとして構成することができる製品が存在します。そのような製品では仮想マシンとして高速にディスクにアクセスすることがマストの要件になってきますし、NASバーチャルアプライアンスが使用するディスクを他のdomUと共有するといった必然性は恐らくないでしょう。したがってNASバーチャルアプライアンスのような製品ではPCI-Passthroughは理想的なコンフィグレーションだと思います。

「仮想マシンでNASを構成しようなんて思うか？」という意見が聞こえてきそうですが、例えば僕は今その必要性に迫られています。限られたサーバ資源をフルに活用してフルスペックの仮想化環境を自宅に構築したいと思っています。しかしストレージ専用機、なんてもってのほかですし（費用、スペース、音、電力、等々）、サーバを丸ごとストレージにするのも勿体ない。そんなとき、OpenSolarisのZFSを使ったNASを仮想マシンで構成できればとても効率的ですよね。でも仮想マシンだとI/O系のパフォーマンスに不安がある。そんなときに！このPCI-Passthorughがソリューションになります。具体的にはOpenSolarisをEPT, VT-dが有効なサーバ上にPVHVMとして作成します。そしてSSDをPCI-PassthroughでOpenSolaris PVHVMから直接I/Oできるようにすればベアメタル上のネイティブOSと遜色ないパフォーマンスが確保できます。メモリアクセスや演算処理もVTテクノロジで実際非常に高速に動作します。ネットワークについてもPCI-Passthroughすることは可能ですが、手元の環境ではNICが豊富にあるわけではないのでネットワークアクセスについてはdom0から割り当てたVIFをPVドライバで高速化するという構成です。（そもそも通信は同筐体内という前提ですし）そして同一サーバ上の他のdomUはこのOpenSolaris PVHVMのZFS上に作成します。ZFSの機能を存分に活用してスナップショットによるバックアップ／ロールバック、クローンによる高速プロビジョニング、圧縮、重複排除などの高度なストレージ技術がすべて利用できます。それも物理的にはサーバ一台というオールインワンで。検証環境としては最高に高密度なシロモノとなります。

また、僕のような変テコな検証環境だけでなく、これからI/Aサーバをストレージとして使用する「Open Storage」という実装が世に広がってくるようになれば、このような構成がフィットするケースが増えてくるのではないかと考えています。

それでは別エントリでこのPCI-Passthroughの構成方法を解説しようと思います。

普通のbzip2やgzipでは圧縮が1スレッドで行われます。つまりCPUコアがいっぱいあってもそのマルチコアを活かした圧縮処理ができません。例えばコンパイル処理ではmake -j8などとすることで8スレッドで並列実行することができ、ビルド時間を大幅に短縮できます。これと同じ要領でマルチコアをフル活用して圧縮したい人にはpbzip2がおすすめです。

pbzip2オフィシャルサイト

各OSディストリビューション用にPre-Builtパッケージもあるようですが、今回はソースからビルドします。ビルドにはc++コンパイラ(gcc-c++）とbzip2-develが必要なのでインストールしておきます。これはredhat系ディストリビューションであればyumとかで標準のレポジトリからインストールできます。

そしてまずはpbzip2をゲットします。

$ wget http://compression.ca/pbzip2/pbzip2-1.1.1.tar.gz

展開、解凍して、

$ tar xvfz pbzip2-1.1.1.tar.gz

ビルド、インストールします。

$ cd pbzip2-1.1.1.tar.gz
$ make
$ sudo make install

これでインストールは終了。使ってみましょう。僕は通常ディレクトリ毎tar cvfjで圧縮することが多いので、これと同義のコマンドを一例として。

tar cvf [圧縮後のファイル名] --use-compress-prog=pbzip2 [圧縮するディレクトリ]

こんな感じです。手元のマシンはクアッドコア with HT enabledでOSからは8コア見えている状態ですが、上記コマンドを発行すると最適なスレッド数が自動検出されて8スレッドで実行されます。CPU使用率は700%強となり、全コア・スレッドが活用されていることがわかります。

そして気になる性能ですが、4GByteのスパースファイルをdd if=/dev/zero of=test.img bs=1M count=0 seek=4000として作成し、これを普通のbzip2とpbzip2で圧縮して所要時間を比較してみました。

クアッドコアのマシンなので完全に並列実行できれば処理時間は理論上1/4になることが期待されますが、それを若干上回る程の性能がでてます。これはイケてる。

マルチコア圧縮は仮想マシンファイル等かなり容量の大きいファイルを圧縮するときには非常に重宝します。これからの時代に必須のツールですね。

PVMとは準仮想マシンのことで、より高性能を求めてカーネルがゲストOS専用に改造されています。

一方、HVMとは完全仮想マシンのことで、カーネルには何ら手が加えられていません。

これまでは単純にPVMとHVMの性能を比較すると圧倒的にPVMが勝っていました。HVMで最も性能劣化が顕著なのは下記2点です。

• ネットワーク、ディスクI/O
• メモリ管理

しかしネットワーク、ディスクI/OについてはHVMであっても実はPVドライバを別途インストールすることでPVMと遜色ない性能を確保することが可能でした。

＊このHVMにPVドライバをインストールした仮想マシンのことを属にPVHVMと呼んでいます。

問題だったのはメモリ管理です。HVMのゲストOSのメモリアドレスから物理メモリのアドレスを求めるときのオーバヘッドが非常に大きかったのです。しかし実はこれも状況が変わってきています。Intelのコードネーム：Nehalemと呼ばれている新しい（といってもリリースされてもう久しいが）アーキテクチャのCPUは仮想化支援機構を強化しています。その目玉がEPTという機能で、先ほど大きなオーバーヘッドであると言ったHVMのメモリアドレス変換処理を高速化するための機構です。

＊ちなみにEPTはHVM用の機構なのでPVMには影響しません。

実際このEPTの効果は様々なテストによって非常に大きいと言われています。そもそもPVMではこのメモリ変換処理を、改造したカーネルによってオーバヘッドを緩和していました。HVMではHypervisorがゲストOSの素のカーネルから発行される物理メモリへのアクセスをトラップして実際のアドレスに修正するというタフな処理を行っていたのでオーバヘッドが大きかったのですが、それがEPTによってHypervisorはそのトラップ＆変換処理をCPUに任せることができるようになりました。

そこで気になるにはどれくらい速いのか？　ですよね。

ということでEPTの効果が如実に現れるという噂のソフトウェアのコンパイル処理をPVMとPVHVMで行いました。

環境

• 物理CPU：Core i7 860（クアッドコア & Hyper-Threading）
• Hypervisor：Xen 3.4
• ゲストOS：Enterprise Linux 5u4 64bit（vCPUを4つ割り当て）
• カーネル：2.6.18-164

テスト内容

• php-5.3.1をmake -j8として8スレッドでコンパイルし、所要時間を計測

結果

• PVM：55秒
• PVHVM：46秒

ということで確かにPVHVMの方が高速です。HVMがPVMを性能面で上回るというのは以前は考えられないことでしたがEPT恐るべし、です。

これからはXenであってもゲストOSはHVM（PVHVM）を選択することも視野に入れねばなりませんね。

Oracle Enterprise Linux 5.4 x86_64 PVMのVMテンプレートを作成しました。

Oracle_Enterprise_Linux_5u4_64_for_11gR2.tar.bz2

このテンプレートにはOSしか入っていません。が！少しいじってあります。一番のカスタマイズは次の点です。

• Oracle 11g R2がすぐにインストールできる

11g R2とは、Grid InfrastructureとDatabaseのことです。Storage GRIDでキーポイントとなるASMはGrid Infrastructureをインストールすることで使えるようになります。

• このテンプレートをダウンロードしてVM Server上で起動する
• Grid InfrastructureをOTNからダウンロードして先ほど起動したVMにインストールする

としていただくことでASMが利用可能になります。ASMが使えるということは11gR2から追加されたACFS（ASM Cluster Filesystem）も使えます。ちなみにACFSとはこういうものです。

• クラスターファイルシステム
• 物理ディスクまたはLUN -> DISKGROUP -> ボリューム -> ファイルシステムというアーキテクチャ
• 動的にファイルシステムサイズを変更可能
• 動的に物理ディスクを追加／削除することが可能
• ディスク構成が変更されるとデータの再配置（リバランス）を行う
• データの冗長性を選択できる[冗長化なし | 2重化 | 3重化]　2重冗長以上であればディスクが壊れてもオンラインで運用継続
• スナップショット機能装備

現在これらの機能を全て備えたファイルシステムはACFSだけでしょう。まだあまり名前が売れてないのですが、結構すごいファイルシステムなのです。

通常11gR2のGrid InfrastructureやDatabaseをインストールするには追加のパッケージをインストールしたりカーネルパラメータをいじったりntpの設定ファイルを編集したりudevのルールファイルを編集したりしなきゃいけないわけですが、このテンプレートを使えば11g R2の前提条件チェックを一発でパスします。というわけでこれからASM、ACFSを触ってみたい！とかいう方にお薦めです。（本当はGrid Infrastructureのインストーラもテンプレートに含めておきたいのですが、そこはソフトウェアの配布規約上不可でした。無念）

使い方は以下の通り。

• VM Serverの/OVS/seed_pool以下にテンプレートをダウンロードし、展開する
• VM Managerからインポートする
• VM Managerでこのテンプレートから仮想マシンを作成する
• 仮想マシンを起動する（初回起動時にIPアドレス2つといくつかのネットワーク設定を入力します）
• Grid Infrastructureをダウンロードしてインストールする（runInstaller.shを実行するだけ。事前の環境設定は必要なし。）

VM Manager使うのが面倒な人はテンプレートを/OVS/running_pool以下に保存して展開し、vm.cfgのdiskパスだけseed_poolからrunning_poolに変えていただければxm create vm.cfgでそのまま起動可能です。ただしNICが2個あることが前提のネットワーク設定になっているのでVM ServerにNICが一つしかない場合にはbridge=xenbr1の方のVIF設定を削除する必要があります。

このテンプレートは他にも地味にいくつかカスタムしてあります。rlwrapがインストールされていてoracleユーザの.bashrcにalias sqlplus=’rlwrap sqlplus’と勝手に入れてあったり、とか。4GByte程あるのでダウンロードにそこそこ時間がかかると思いますが、ASM、ACFSを試してみたい方は是非どうぞ。

＊ちなみに解凍後のサイズは20Gbyte強になります。rootのパスワードは’oracle’です。