nkjmkzk.net

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

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、素敵ですね。

システム環境

• CPU: Intel Core-i7 860
• チップセット: Intel P55 Express
• マザーボード: MSI P55M-SD40
• Xen: 3.4.0
• dom0: Oracle VM Server (Oracle Enterprise Linux 5.3ベース)
• Passthrough対象のdomU: OpenSolaris b134 PVHVM

Xenは既にインストールされているという前提で始めます。/etc/grub.confのkernel行に「iommu=pv」と追記してI/O Virtualizationを有効化します。＊これはBIOSでの有効とは異なります。BIOSでI/O Virtualizationを有効にした上でこの設定を行います。参考までにgrub.conf全体を。

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Oracle VM server (2.6.18-128.2.1.4.25.el5xen)
	root (hd0,0)
	kernel /xen-64bit.gz dom0_mem=564M iommu=pv
	module /vmlinuz-2.6.18-128.2.1.4.25.el5xen ro root=UUID=d060bc44-d5d2-49ec-8312-222c761a3746
	module /initrd-2.6.18-128.2.1.4.25.el5xen.img

＊より一般的にはiommu=1と設定しますが、これではPVM（準仮想化マシン）に対してのPassthroughが有効にならないのでiommu=pvとしています。iommu=pvとすればHVM, PVM双方でPassthroughが有効になります。

ここで一度OSを再起動します。再起動後、xm dmesgコマンドを発行してI/O Virtualizationが有効になったことを確認します。

[root@vmserver]# xm dmesg | grep "I/O virtualisation"
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests enabled

＊ちなみにgrepする場合はvirtualizationではなく上記のようにvirtualisationで引っ掛けてください。

次にdomUにPassthroughしたいPCIデバイスをdom0から隠します。作業の流れとしては、まず対象となるPCIデバイスのBDFを求めます（BDFについて詳しくはこちら）。次にPCIデバイスをdom0から隠すためのカーネルモジュール「pciback」をロードします。そしてsysファイルシステムを使うか、modprobe.confに適当な記述を行うことでPCIデバイスをdom0から隠しdomUにPassthrough可能な状態にします。

BDFはlspciコマンドでPCIデバイスの一覧を表示させ、それっぽいモノを判別します。

[root@vmserver]# lspci
00:00.0 Host bridge: Intel Corporation Clarksfield/Lynnfield DMI (rev 11)
00:03.0 PCI bridge: Intel Corporation Clarksfield/Lynnfield PCI Express Root Port 1 (rev 11)
00:08.0 System peripheral: Intel Corporation Clarksfield/Lynnfield System Management Registers (rev 11)
00:08.1 System peripheral: Intel Corporation Clarksfield/Lynnfield Semaphore and Scratchpad Registers (rev 11)
00:08.2 System peripheral: Intel Corporation Clarksfield/Lynnfield System Control and Status Registers (rev 11)
00:08.3 System peripheral: Intel Corporation Clarksfield/Lynnfield Miscellaneous Registers (rev 11)
00:10.0 System peripheral: Intel Corporation QPI Link (rev 11)
00:10.1 System peripheral: Intel Corporation QPI Routing and Protocol Registers (rev 11)
00:1a.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 05)
00:1b.0 Audio device: Intel Corporation Ibex Peak High Definition Audio (rev 05)
00:1c.0 PCI bridge: Intel Corporation Ibex Peak PCI Express Root Port 1 (rev 05)
00:1c.4 PCI bridge: Intel Corporation Ibex Peak PCI Express Root Port 5 (rev 05)
00:1c.5 PCI bridge: Intel Corporation Ibex Peak PCI Express Root Port 6 (rev 05)
00:1d.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Ibex Peak LPC Interface Controller (rev 05)
00:1f.2 IDE interface: Intel Corporation Ibex Peak 4 port SATA IDE Controller (rev 05)
00:1f.3 SMBus: Intel Corporation Ibex Peak SMBus Controller (rev 05)
00:1f.5 IDE interface: Intel Corporation Ibex Peak 2 port SATA IDE Controller (rev 05)
01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0a65 (rev a2)
01:00.1 Audio device: nVidia Corporation Unknown device 0be3 (rev a1)
03:00.0 SATA controller: 1b4b:9123 (rev 11)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

手元の環境では増設したSATAコントローラ（赤字）がPassthroughしたいPCIデバイスです。したがって対象のBDFは03:00.0です。が、実際にはこの番号の頭に0000:をくっつけて、『0000:03:00.0」が正式なBDFで、この後もこちらの正式なBDFを使用します。

＊ちなみに00:1f.0, 00:1f.2, 00:1f.3, 00:1f.5のように下一桁だけが異なるものはマルチファンクションのPCIデバイスです。この例ではこのPCIデバイスはオンボードのSATAコントローラ・ブリッジで、6ポートのSATAポートを装備しています。そしてこの内4ポートが00:1f.2に属しており、2ポートが00:1f.5に属しています。一度00:1f.2にSSDを一枚差し、00:1f.5にSSDを一枚差して後者だけをdomUにPassthroughできるか試してみましたが、結果はNGでした。Xen 3.4.0とXen 4.0.0両方でトライしましたが、前者は一見うまくいったように見えるのですがその内I/Oエラーやファイルシステムのジャーナルエラーが報告され、domo, domUともフリーズしました。後者は割り当てた瞬間にフリーズが発生しました。DMAのマップがめちゃくちゃになってそうな雰囲気です。

次にpcibackのロードですが、Oracle VM Serverのdom0カーネルでは（恐らく多くの他の環境でも）、pcibackはカーネルに組み込まれてビルドされておらずモジュールとしてビルドされています。この状態ではpcibackはオンラインでmodprobeコマンドによってロードできますが、逆にブート時にカーネルパラメータを渡すことでロードすることはできません。自動的にロードさせたい場合はブートのもう少し後の段階でロードします。具体的にはrc.localかmodprobe.confを少々編集します。今回はrc.localに記載する手順で話を進めます。そしてロードに続けてPCIデバイスをdom0から隠しPassthrough可能にする設定を行います。これらをまとめてrc.localに下記のように記述します。

BDF=0000:03:00.0
# Load pciback
modprobe pciback
# Unbind a PCI function from its driver as necessary
[ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
        echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
# Add a new slot to the PCI Backend's list
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
# Now that the backend is watching for the slot, bind to it
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind

＊pcibackはpvops採用のdom0カーネルではxen-pcibackと名前が変更されています。

＊環境によってはPCIデバイスをunbindした瞬間にOSがクラッシュするかもしれません。僕はahciドライバで認識しているデバイスをunbindしたときにこのクラッシュに遭遇しました。これを回避するためにはrc.localではなくmodprobe.confを利用する設定方法が有効でした。ahci等のドライバがデバイスを認識する前にpcibackをロードして該当デバイスを隠蔽することによって回避することができました。詳しくはこちらの2.の手法を参照してください。skgeは手元の環境に合わせて変える必要があります。

設定がうまくいっていれば、xm pci-list-assignable-deviceで確認できます。

[root@vmserver]# xm pci-list-assignable-device
0000:03:00.0

この出力が確認できれば対象のPCIデバイスはPassthroughされる準備が整っています。あとはdomUの設定ファイルにてpci = [ '0000:03:00.0' ]の記述を入れてdomUを起動すればPassthroughが実現できます。参考までに手元のOpenSolaris b134のPVHVMの設定ファイルを掲載しておきます。

acpi = 1
apic = 1
builder = 'hvm'
device_model = '/usr/lib/xen/bin/qemu-dm'
disk = ['file:/var/ovs/mount/4ED5C364C05246FE8AEE8C0E26D79ACF/running_pool/nas/System.img,hda,w',
',hdc:cdrom,r',
]
kernel = '/usr/lib/xen/boot/hvmloader'
keymap = 'en-us'
memory = '1024'
name = 'nas'
on_crash = 'restart'
on_reboot = 'restart'
pae = 1
pci = ['0000:03:00.0']
serial = 'pty'
timer_mode = '0'
uuid = '42d9bfd3-dd90-4b54-a8a0-af90bcc53028'
vcpus = 4
vif = ['bridge=xenbr0,mac=00:16:3E:15:01:3E,type=netfront']
vif_other_config = []
vnc = 1
vncconsole = 1
vnclisten = '0.0.0.0'
vncpasswd = 'secret'
vncunused = 1

正直PCI-Passthroughの設定はなかなかクセがあり、苦労しました。動いたように見えて半日くらいしてからI/Oエラーがでたり、サーバ全体がクラッシュしたり、デバイスによっては隠蔽設定はうまくいくもののxm pci-list-assignable-deviceには表示されなかったり、Xenのバージョンによってかなり挙動が違ったり。下記にPCI-Passthroughにおける教訓を掲載しておきます 。

• マルチファンクションデバイスの一部だけPassthroughしようとしない。Passthroughするときは丸ごと。
• Linuxで確実に動作する鉄板のPCIデバイスを使う。
• Xenは出来る限り新しいバージョンを使う。
• 動いたと思っても油断しない。最低1日はヒートランすべき。

＊今回検証した機材の他に、下記の組み合わせでも動作を確認しています。ご参考まで。

• CPU: Intel Core-i7 860
• チップセット: Intel H55 Express
• マザーボード: Intel DH55TC
• Xen: 4.0.0
• dom0: Fedora12 kernel 2.6.32
• Passthrough対象のdomU: OpenSolaris b134 PVHVM

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になることが期待されますが、それを若干上回る程の性能がでてます。これはイケてる。

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

ASM、の前に、まずStorage GridというOracle社が考える理想的なストレージ構成についてですが、Storage Gridとは安価な単機能ストレージを並べてストレージI/O性能・容量をスケールアウトさせる、そして可用性を確保するというストレージ構成のことです。

高性能が必要になったとき、サーバ側はクラスタ、レプリケーションといった形で並べてスケールアウトさせることがコモディティ化してきています。これは、ハイエンドマシンを擁して単一サーバでスケールアップを図るより、ローエンドマシンを並べた方が同性能を圧倒的に安価に引き出せる、というのがそのコンセプトの根底にあります。

それではストレージはどうか？というとサーバ程「並べる」という考え方は浸透していないと思います。特にエンタープライズ環境ではその傾向が顕著でしょう。企業は高価な専用ストレージ装置にかなり出費しています。だったら、ストレージもサーバと同じように並べる構成にすればいいんじゃないの？というのがStorage Gridの発想です。ごく自然な着想ですよね。

＊ちなみこの辺に関連記事があります。

サーバ仮想化環境でのお薦めストレージ構成 at nkjmkzk.net

OracleではこのStorage Gridを体現する実装としてASM(Automatic Storage Management)という製品を提供しています。これはサーバ側にインストールするソフトウェアで、下記のことが可能になります。

• 複数ストレージを連結して一つの大きなボリュームを構築する
• 複数ストレージ間でデータを冗長化し、ストレージ装置の障害時にも完全なデータアクセスを可能にする
• 需要に応じてオンラインでストレージを追加／削除できる
• 追加・削除を行った際、ドライブ上のデータは新しい構成に応じて自動的に再配置される
• 複数クライアントからのアクセスを同時に処理できる（つまり共有ボリュームとして利用できる）
• ASMが提供するボリュームはデータベースの他、ファイルシステムでフォーマットしたりと汎用的に利用できる

従来ASMはOracle Databaseの一部であり、Database専用のボリュームマネージャでした。しかし現在ASMはDatabaseではなく「Grid Infrastructure」というパッケージに含まれるソフトウェアとなっており、Databaseとは独立してインストールして使用可能です。当然引き続きDatabaseのボリュームとしても使用可能ですが、Database以外の汎用的な用途に利用可能となっています。下図のようなイメージです。（ASMはサーバにインストールして使うソフトウェアです）

そして気になるライセンス費用ですが、驚くことにGrid Infrastructureはそれ自体にライセンス費用はかかりません。ざっくり言うと、利用自体は基本的にフリーで（一部スナップショット機能等に制限あり）、サポートが必要な場合はUBL(Unbreakable Linux）契約またはDBのサポート契約を締結していただくということになっています。下記はマニュアルからの抜粋です。

Oracle Grid Infrastructureの以下のコンポーネントは、スタンドアロンのサーバーでもクラスタ構成でも無償で使用することができます。

• Oracle Automatic Storage Management（Oracle ASM）
• ASM動的ボリューム
• ASMクラスタ・ファイルシステム（ACFS）（ACFSスナップショットとその他の付加機能を除く）
• クラスタ構成において、ASM/ADVM/ACFSのサポートのためのみに使用されるOracle Clusterware
• スタンドアロンのサーバーで、Oracle DatabaseとOracle ASMのためだけに使用されるOracle Restart

それに加えて、Oracle Clusterwareは、次のいずれかの条件を満たす場合において、アプリケーションを保護する（障害発生時のアプリケーションの再起動またはフェイルオーバー）用途で、無償で使用することができます。

1. サーバーOSが、有効なOracle Unbreakable Linuxサポート契約でサポートされていること。
2. 保護対象の製品が次のいずれかであること。
   • オラクル社によって提供された製品（例: Oracle Applications、Siebel、Hyperion、Oracle Database EE、Oracle Database XE）
   • 直接または間接的にOracle Databaseにデータを格納するサード・パーティ製品
3. クラスタを構成する少なくとも1台のマシンに対して、Oracle Database Enterprise EditionまたはOracle Database Standard Editionのライセンスが購入されていること。

クラスタは、同じOracle Cluster Registry（OCR）および投票ディスクを共有するすべてのマシンが含まれるものと定義されています。

リファレンス：http://download.oracle.com/docs/cd/E16338_01/license.112/b56284/editions.htm

＊ちなみに余談ですがOracle Unbreakable Linuxサポートを契約すると他にもEnterprise ManagerのLinux Management Packが利用可能になります。これはOSの監視、インベントリ管理、パッチ適用／アップデート等が一元的に行えるツールです。

ASMを採用したStorage Grid構成と、これまでのスケールアップ型のストレージ構成を性能・可用性・コストの観点で一度比較検討してみてはどうでしょうか。ただしこのようなストレージの組み方は多くのエンジニアにとってこれまでとはことなるやり方、で、気にはなるけどちょっと不安、という人も多いでしょう。そういうときは日本オラクルにご相談ください。出来る限り善処致します。

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’です。

OpenSolaris b133をPVM（準仮想マシン）64bitとしてOracle VM上にクリーンインストールする方法を紹介します。

リファレンス：Starting At The C

＊最初にお断りしておきますがソコソコ面倒です。

まずはOpenSolaris b133のisoをダウンロードし、VM Serverの/OVS/iso_poolあたりに置いておきます。

[root@vmserver]# cd /OVS/iso_pool
[root@vmserver]# wget http://www.genunix.org/dist/indiana/osol-dev-133-x86.iso

まずVM ServerでこのVMを格納するためのディレクトリを任意の名前で作成しそのディレクトリに移動します。ここではosolとしています。

[root@vmserver]# mkdir /OVS/running_pool/osol
[root@vmserver]# cd /OVS/running_pool/osol

次に仮想ハードディスクをファイルで作成します。Sparse形式で良いでしょう。ここでは推奨値の10GBにしています。（実際は9.8GBくらいになりちょっと足りないのでインストール時に警告がでる。が、無視。）

[root@vmserver]# dd if=/dev/zero of=system.img bs=1M count=1 seek=10000

VMの設定ファイルを作成します。この設定ファイルはインストール用で、インストール後には新しく作り直します。

[root@vmserver]# vi vm_install.cfg
bootloader = '/usr/bin/pygrub'
bootargs = '--kernel=/platform/i86xpv/kernel/amd64/unix --ramdisk=/platform/i86pc/amd64/boot_archive'
name = 'osol'
memory = 1024
on_reboot = destroy
vif = [
'type=netfront,bridge=xenbr0,mac=00:16:3e:00:00:52',
]
disk = [
'file:/OVS/iso_pool/osol-dev-133-x86.iso,xvdc:cdrom,r',
'file:/OVS/running_pool/osol/system.img,xvda,w',
]

VMを起動し、コンソールに接続します。

[root@vmserver]# xm create -c vm_install.cfg

言語とキーボード配列を選び、username：jack, password：jackでログインします。

DHCPサーバが動いている環境であればそのうちIPが割り当てられるのでしばらく待ってからifconfig等でIPを確認します。DHCPがない場合は自分で静的IPを割り当てます。IPが設定されたらコンソールを抜け、VNCのポート番号とパスワードを確認します。これは自動的に設定されているものです。

まずxm listコマンドでVMのdomain IDを確認し、次にxenstore-readコマンドでVNCの情報を取得します。

[root@vmserver]# xm list osol
Name                                        ID   Mem VCPUs      State   Time(s)
osol                                        15   1024  1        -b----     32.3

[root@vmserver]# xenstore-read /local/domain/15/guest/vnc/port
5900

[root@vmserver]# xenstore-read /local/domain/15/guest/vnc/password
bxukNvkb

ここまでで得たVMのIPアドレス、VNC Port番号、VNCパスワードをもって任意のVNCクライアントから接続します。すると通常OpenSolarisのインストールCDから起動したときと同じ画面にログインできます。画面左のショートカットから通常通りインストールウィザードを起動してインストールを進めてます。そして注意しなければいけないのは、インストールが「Finished」となってもすぐにRebootをしないことです。リブートの前にOpenSolaris上でターミナルを開いて以下の作業を行います。

[jack@osol]$ vi update-dom0.sh
#/bin/bash
dom0=$1
dompath=$2
unixfile=/platform/i86xpv/kernel/amd64/unix
root=`pfexec beadm list -H |  grep ';N*R;' | cut -d \; -f 1`
mkdir /tmp/root
pfexec beadm mount $root /tmp/root 2>/dev/null
mount=`pfexec beadm list -H $root | cut -d \; -f 4`
pfexec bootadm update-archive -R $mount
scp $mount/$unixfile root@$dom0:$dompath/kernel.$root
scp $mount/platform/i86pc/amd64/boot_archive root@$dom0:$dompath/ramdisk.$root
pfexec beadm umount $root 2>/dev/null
echo "Kernel and ramdisk for $root copied to $dom0:$dompath"
echo "Kernel cmdline should be:"
echo "$unixfile -B zfs-bootfs=rpool/ROOT/$root,bootpath=/xpvd/xdf@51712:a"
[jack@osol]$ chmod 755 update-dom0.sh
[jack@osol]$ ./update-dom0.sh vmserver1 /OVS/running_pool/osol
（dom0のパスワードを訊かれるので入力する）

これが完了したらRebootボタンを押してリブートしてください。ただし実際にはリブートではなくシャットダウンされます。シャットダウンされたらvm.cfgを作成・編集します。

[root@vmserver]# vi vm.cfg
name='osol'
kernel='/OVS/running_pool/osol/kernel.opensolaris'
ramdisk='/OVS/running_pool/osol/ramdisk.opensolaris'
extra='/platform/i86xpv/kernel/amd64/unix -B zfs-bootfs="rpool/ROOT/opensolaris",bootpath="/xpvd/xdf@51712:a"'
memory=1024
vif= [
'type=netfront,bridge=xenbr0,mac=00:16:3e:00:00:52',
]
disk= [
'file:/OVS/running_pool/osol/system.img,xvda,w',
]

これでインストールは完了です。vm_install.cfgは削除してしまって構いません。新しく作成した設定ファイルで起動してみてください。

[root@vmserver]# xm create -c vm.cfg

GUIにログインしたい場合は以下のようにVM上でVNC Serverを起動してから任意のVNCクライアントで接続すればOKです。適切なIPアドレス設定を忘れずに。

[nkjm@osol]$ vncserver

サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在のCPU性能とDISK I/O性能を鑑みれば、そもそもDISK I/O性能はCPU性能の進化に追いついておらず、共有ストレージ構成とすれば追い打ちをかけるようにそこがボトルネックとなります。多くの環境ではこれまでの何倍ものI/O性能が必要という要件に対応するため、ミドル〜ハイエンドのストレージ装置を採用するという選択を行っています。その結果初期導入費用が高価なのはもちろんですが、そのあとも莫大な保守費を支払うことになります。そして拡張できるものの、拡張するためのパーツがまた高価、というスパイラルに陥ります。これはIT関連予算を大きく圧迫することでしょう。

そこで、これまでのストレージ構成を見直し、以下の要件を敷いて仮想化環境でのお薦めストレージ構成を考案してみました。キメの部分にOracleのストレージ管理機構を適用しています。

• コスト意識をもつ
• ユニバーサルに使用可能なこと
• スケーラビリティ- 要求に応じてキャパシティ（I/O性能、容量）の拡張が可能であること
• シンプル – OS、ソフトウェア側ではスケールアウトのためのパーティション設計が不要なこと
• 可用性 – SPOFを排除。ディスク、コントローラ、ストレージ筺体のどれが壊れてもデータ保全とオンラインを維持すること

＊以下ではストレージにI/Aサーバを採用していますが、応用としてローエンドなストレージ専用機という選択肢もあると思っています。

解は、コモディティなH/Wを並べる、そして高性能・高可用性・高管理性を達成するというStorage GRIDの思想に基づいた構成です。

多数のディスクを搭載できるI/Aサーバをストレージに採用

• ストレージ専用機と比較してI/Aサーバは圧倒的に安価。
• しかもカスタマイズ可能なので必要に応じて大容量のメモリ、10GbEの搭載もできる。（詳しくは後述）
• コントローラの冗長化を行うことは難しいが、それはASMの筺体間ミラーで代用できるため不要。（詳しくは後述）
• OSにはSolarisを採用。ZFS iSCSIを使ってボリュームをエクスポート。これはZFSが多様なRAIDを構成可能なこと、チェックサムによるエンドツーエンドのブロック整合性チェックが可能性でデータの一貫性維持機構が強力なこと、ファイルシステムとボリュームマネージャ、iSCSIがZFSに集約されており管理が用意なことが採用理由。

READはすべてキャッシュで捌くことを前提に大量のDRAMを搭載

• ディスクアクセスは物理的移動がともなうため絶対的に遅い。数年後には「円盤回したりヘッド動かしたりとか有り得ないっスよね」となるかも。
• メモリは数十ナノセカンドでアクセス可能。ディスクは数ミリセカンド。比較にならない。
• I/Aサーバだと構成を自由にカスタマイズできるのでDRAMを大量に搭載することができる。ZFSではDRAMをARCというReadキャッシュにすることができる。これはRead用のキャッシュをストレージ専用機の何倍も搭載できることを意味する。最近の1U, 2Uの一般的なI/Aサーバでは100GBを超えるDRAMを搭載可能。一筺体でも100GBのデータベースをすべてキャッシュすることが可能。
• サーバではなくストレージ側にReadキャッシュを持たせることにより、複数サーバ構成時のサーバ間でのキャッシュコンテンツ重複を排除することができる。
• サーバ再起動時にもキャッシュの内容がクリアされない。
• ただしウォームアップ時間には注意。キャッシュされたことを前提でサイジングを行うことになるが、もしストレージを再起動したときにはキャッシュを温めるために相当な時間がかかることになりその間の性能は劣悪になる。したがってストレージ再起動時にはサービスをオンラインにする前にデータを強制的にキャッシュに載せるようなロジックを組み込むことが望ましい。

SSDでさらなるキャッシュ容量を、より安価に

• もし、コスト的にそれほどのDRAMを購入することはできないという場合、SSDで代用させることができる。
• SSDはDRAMの延長線上に存在するようなRead用キャッシュとなり、DRAMから溢れるデータを受け止める役割を果たす。結果、DRAMと比べて安価に大容量のReadキャッシュを構築できる。

ランダムな同期書き込みをキャッシュで受け止めるためにBBWC（Battery-Backed Write Cache）を装備

• DRAM（ARC）によるキャッシュはRead用。書き込みには利用することができない（させてはならない）。
• 特にRandom Writeが発生するデータベースではREDOログの同期書き込みに要するコストは大きい。そのような環境ではBBWCの効果は絶大。ディスクへの同期書き込みを防ぎ、しかるべきタイミングでまとめてFlushするため大幅な性能向上が約束される。当然BBWC上のデータは突然のシステムダウン時も保護される。（ただしバッテリーが切れる前に起動すること）
• BBWCはRAIDコントローラ依存となるためDRAMのように大量に積むことはできないが、Readキャッシュと比較して少量でも効果が大きく、さらに後述のASMによって増設もできる。

この筺体を複数並べて、ASMによってストライピングすることでより厳しい性能要件に対応させる

• ASMとは「Grid Infrastructure」というOracleが提供するクラスタソフトウェアに付属するストレージ管理モジュール。
• ASMは並べたストレージをOS、データベースに対して「DISKGROUP」として結果的に一つに見せることが可能。

正確にはストレージでエクスポートしている論理ボリュームはOSにそのまま個別のブロックデバイスとして認識される。しかしOSはそのままそのブロックデバイスを使用するのではなく、汎用ファイルシステムとして利用する場合はASMがそのブロックデバイスから作成するファイルシステム（ACFS）をマウントして使うことになる。このファイルシステムに対して行われるI/Oは複数のブロックデバイスに分散して実行され、ストレージが複数台で構成されている場合にはデータは複数ストレージに分散される。つまり、複数台のストレージのDISK, DRAM, BBWCをフル活用できることになる。一瞬、LVMとの違いが気になるかもしれないが、まずASMはデータの「リバランス」をおこなうところが違う。ディスク／ストレージの追加／削除はオンラインで行える上、データのリバランスが自動的に行われる。また、ASMは完全にクラスターアウェアだ。LVMでも別途クラスターLVMのデーモンを設定することでクラスター化（共有）は可能だが、ASMはクラスター機構をはじめから組み込んでいる。

• DISKGROUPに対して発行した書き込みは並べた複数のストレージに対して分散して書き込まれる。DISKGROUPに対して発行した読み込みは、並べた複数のストレージから分割して読み込まれる。
• 結果、並べた複数のストレージは仮想的に一つの大きなストレージ筺体となり、（ストレージあたりのI/O性能、ディスク容量） x ストレージ台数分のキャパシティ提供することができる。これは、ストレージH/Wに依存せずI/O性能と容量を必要に応じてスケールアウト可能であることを意味する。
• また、連結されるのはディスクだけでなく、DRAM, BBWCも同様。結果、100GBのDRAMを積んだストレージを3台並べれば300GBのキャッシュグリッドが出来上がる。

ASMのストライピングモードを「2重化モード」にすることで筺体障害に対応する

• ASMはデータを分散させるだけでなく、複製しながら分散させることが可能。いわゆるネットワークRAID、筺体間ミラーの構成。
• このとき、ストレージAにあるデータはかならずストレージB（またはC）にも存在するようになるため、万一ストレージ筺体がまるごと故障／RAIDが破壊されたとしてもデータは保全される。
• それだけでなく、ストレージ筺体が故障してもオンラインで処理を継続することが可能。（ただし最低ストレージ3台必要）

圧縮でH/W投資を必要最低限に「圧縮」

• さらに圧縮機能を活用することで、必要なH/W（ストレージ筺体、DISK、DRAM、BBWC)をまさに必要最低限にできる。
• 「圧縮はオーバーヘッドがあるのでは？」と思われるかもしれなが、そもそも現在の性能課題はストレージI/Oにあることを思い出して欲しい。つまりストレージI/Oがボトルネックになれば結果としてCPU性能はあまることになる。重要なのはオーバーヘッドがあるかないかではなく、最終的にバランスのとれたシステムを構成すること。バランスがとれたときにシステムの集約密度は最大になる。そのためにはあまっているリソースは積極的に活用すべき。

FAQ. RAIDとASMの双方でデータを二重化するのは実効容量が無駄では？

• 実効容量がどうしても気になる場合は、H/W RAIDをRAID5, 6, 50等比較的容量を確保できるモードとすればよい。しかし（あくまで一般的にだが）「容量」はそれほどコストの高いリソースではない。コストが高く、実現が難しいのは高いI/O性能。繰り返しになるがCPUと同様、余っているリソースはより重要な課題（ここでは可用性）のために積極的に利用すべき。

FAQ. それほどI/O性能が気になるならDISKでなくすべてSSDにしたらどうか？

• 今回の構成は「コスト意識を持ったユニバーサルなストレージ基盤。その前提でスケーラビリティと可用性を実現する。」というもの。
• そのテーマにおいて、すべてをSSDにすることは少なくとも現時点（2010年2月）ではコストと容量の面でオールマイティとは言えない。
• 逆に「SSDは実績が乏しく、寿命や信頼性に懸念がある」という人もいるが個人的にはそうは思わない。可動部があり故障確率の高いHDDよりSSDの方がよっぽど安心だ。寿命に対する懸念も実際にその仕組を理解しないで懸念だけをうたっていることが少なくない。現時点では寿命があるのは事実だが、SLCでは素子あたり5万回の更新が可能な製品が一般的で、一部では50万回という製品もある。そして寿命については事前に知ることができるので計画的にパーツ交換すればよい。SSDに故障がないわけではないが、より故障確率が高いことが想定されるHDDの「いつ壊れるかわからない不安」に比べればSSDの寿命などかわいいもの、と思う。