2014年12月03日

[JPOUG Advent Calendar] Oracle on Hyper-V 2014

charade_oo4oと申します。昨年に引き続き、今年も「JPOUG Advent Calendar 2014」へ参加致します。
昨日はYohei Azekatsuさんの「fulltime.sh by Craig Shallahamer で DB CPU の内訳を調べる」でした。

今年もOracleとHyper-Vで何か書こうと思いましたが、2014年は昨年程の大きな動きは無かった様に思えます。
クラウド関連の動きは相変わらず活発ですが、オンプレミスでは、Microsoftの新OSはTecnical Preview止まり、Oracle Database 12cの小数点第3位は上がりましたが、Release2は再来年までお預けです。

新しいネタを用意出来そうも無かったので、古いネタを再料理しようと思います。
私自身は、2014年にもなって今更ながらに11gR2のParallel処理を活用し、Exadataを初めて使った年となりました。
学習用の11gR2 RACの環境はWindows7+VirtualBoxで構築していた為、RACについて何か調べる度にBootし直す必要がありました。
最近はWindows8.1+Hyper-Vで各種OS+DBを検証しているので、11gR2 RACもHyper-Vで再構築する事にしました。

 <目次>

・11gR2 RAC 仮想環境
・OL5 Version/Kernel
・変わるNIC
・共有ディスク
・遅いディスク
・膨れるディスク
・インストール時注意点
・インストール後注意点
・暴れるマウス
・クローンが無い
・重いネットワーク

 <11gR2 RAC 仮想環境>

11gR2 RACを仮想環境で構築する場合、OTNの資料が判り易いと思います。

http://www.oracle.com/technetwork/jp/database/database-11g/documentation/index.html
Oracle VM VirtualBox を用いた Oracle Real Application Clusters(RAC)11g Release 2 環境の構築
https://blogs.oracle.com/oracle4engineer/entry/material_rac_virtualbox
【チュートリアル】Oracle VM VirtualBoxを用いたOracle Real Application Clusters(RAC) 11g Release 2環境の構築

Windows7+VirtualBoxの仮想環境で、現在はOracle Linux 6.4(OL6.4)又は Oracle Linux 6.3(OL6.3)を使用する資料が公開されていました。
昔私が構築した際はOracle Linux 5.7(OL5.7)での資料が公開されていました。
ExadataやPlatinum実技試験等、今でもOL5の環境が必要となる事もあると思います。
今回のHyper-Vでの構築ではOL5を使用しました。

 <OL5 Version/Kernel>

Hyper-VでOL5を使用する場合、Linux Integration Services(LIS)を組込済のOL5.9以降が便利です。
LISがないと、低速なレガシネットワークアダプターしか認識せず、ホストOSとゲストOS間のマウス連携も働きません。
OL5.9以降ではRHEL互換KernelにはLISが組み込まれていますが、UEKでは未組込です。
その為、OL5.9以降(最新はOL5.11)でRHEL互換Kernelを使用した方が良いです。

OL6ではOL6.4以降(最新はOL6.6)で、RHEL互換Kernel/UELどちらもLISを組込済です。

VirtualBoxではなくHyper-Vを使用する利点として、Kernelアップデート後にGuest Additionsをインストールし 直す必要が無いという点が挙げられます。

 <変わるNIC>

Hyper-Vの仮想マシンのデフォルト設定では、前回起動時と異なるMACアドレスへ変更される場合があります。
LinuxではMACアドレス毎に新たなethとして認識されます。
MACアドレスが変わると、古いethに設定したIPアドレスは使われません。
IPアドレスが変わると、ゲストOS上に構築したRACが稼働不能となってしまいます。

対策として、仮想マシンの電源ON後に割り当てられたMACアドレスを静的に設定しました。
grubメッセージ表示中にすぐに電源OFFして、ネットワークアダプター → 高度な機能 → MACアドレス から、 動的 → 静的 へ変更しました。

Hyper-Vの仮想スイッチは、外部通信するNODE側のeth3用とDNS側のeth1用は「外部」、それ以外は「内部」で作成しました。
NODE側のeth1,2用のインターコネクトは「内部」ではなく「プライベート」を使用しても良いのですが、最後の方で記載する理由から止めました。

 <共有ディスク>

通常、RACを構築する際には、Fibre ChannelやiSCSI等の高価なSANストレージが必要です。
OTNのVirtualBox+11gR2 RACの資料、更に遡るとVMware+10gR2 RACの資料でも、RACの共有ディスクは仮想ディスクファイルの共有で低コストに実現していました。

Windows8.1(2012R2) Hyper-Vから、同様の仮想ハードディスクの共有が実装された為、当初はこの機能を使用する予定でした。
しかしこの機能はPC単体のディスクでは利用不可でした。
SCSIコントローラ → ハードドライブ → 高度な機能 → 仮想ハードディスクの共有 → 仮想ハードディスクの共有を有効にする のチェックを入れると、「仮想ハードディスクがある記憶域は、仮想ハードディスクの共有をサポートしていません。」というエラーが出てしまいます。
理由は下記の通りでした。
・Hyper-Vの仮想ハードディスクの共有には、スケールアウトファイルサーバーが必要。
・スケールアウトファイルサーバーには、SANストレージが必要。

対策として、今回はiSCSI S/Wを導入しました。
OTNのVirtualBox+11gR2 RACの資料は、NODE2台にDNS1台の構成です。
DNS側に「scsi-target-utils」をインストールして、iSCSI Targetとしました。
NODE側の「iscsi-initiator-utils」はOTN資料通りでインストール済でした。

共有ディスク/dev/sdb-sdg用のVHDXはiSCSI Target(DNS)側にのみ接続しました。
Hyper-Vの仮想マシン設定(第1世代)で、起動用ディスクはIDE、共有ディスクはSCSIで接続しました。
iSCSI Initiator(NODE)側は起動用ディスクのみです。

iSCSI用ネットワークとして、Hyper-Vの仮想スイッチと全仮想マシンでNICを1系統ずつ追加しました。
RAC用のインターコネクトで192.168.100.0/24と192.168.200.0/24が使用されていた為、被らない様にiSCSI用は192.168.101.0/24としました。

DNS用の仮想マシン、OL6版のOTN資料ではメモリ1024MBを指定していますが、OL5版では512MBでした。
iSCSI Target化した場合でも512MBでメモリ不足とはなりませんでした。

--iSCSI Target(DNS)側作業
yum install scsi-target-utils

#/etc/tgt/targets.conf 追記
<target iqn.2014-12.jp.oracle11g.dns1-iscsi-disk>
    backing-store /dev/sdb      # Becomes LUN 1
    backing-store /dev/sdc      # Becomes LUN 2
    backing-store /dev/sdd      # Becomes LUN 3
    backing-store /dev/sde      # Becomes LUN 4
    backing-store /dev/sdf      # Becomes LUN 5
    backing-store /dev/sdg      # Becomes LUN 6
    initiator-address 192.168.101.0/24
    write-cache off
</target>

#サービス再起動
service tgtd restart
chkconfig tgtd on

#設定確認
tgtadm --lld iscsi --op show --mode target

--iSCSI Initiator(NODE)側作業
#iscsi-initiator-utilsはインストール済

iscsiadm --mode discovery --type sendtargets --portal 192.168.101.254 --login
#/dev/sdb-sdgのマウント確認

 <遅いディスク>

2012/12/05に書いたネタ、ミスアライメントのLinux版です。
OL5はパーティション開始オフセットが31.5K(63セクタ)で作成される為、物理4Kセクタ(AFT)のHDDやSSDやRAIDでは速度低下します。Small Readは2倍、Small Writeは4倍、DISK I/O負荷が上がります。
OL6はパーティション開始オフセットが1M(2048セクタ)で作成される為、大抵の環境で問題ありません。

本来ならOL5でミスアライメントを解消する方法を見つけるべきなのでしょうが、今回は安直な手段をとりました。
1.まずOL6を最小インストール(パーティション作成)。
2.次にOL5でインストールし直し。パーティションの設定で「カスタムレイアウトを作成します。」を選択して、マウントポイント(/,/boot)とフォーマット(ext3,swap)を指定。

共有ディスク用にiSCSIでマウントした/dev/sdb-sdgでも、fdiskでミスアライメント対策しました。
fdisk /dev/sd<x>
u → n → p → 1 → 2048 → → w

全ディスク、全パーティションの開始位置が、fdisk -lu /dev/sd<x> で start 2048 や 1026048 の様に、物理セクタサイズやRAIDストライプサイズで割り切れれば対策完了です。

 <膨れるディスク>

OL5が採用しているファイルシステムext3は、容量可変VHDXファイルとの相性が悪いです。
大きなディスクをフォーマットしただけでも、ゲストOSでの使用量以上にVHDXファイルが膨れ上がってしまいます。
OTN資料のHDDサイズではそれ程大きな問題は発生しませんが、ディスクの無駄遣いに繋がります。

下記の回避策が一般的です。
・PowerShellからブロックサイズ1MB(デフォルト32MB)のVHDXを作成。
  New-VHD -Path node1.vhdx -Dynamic -SizeBytes 25GB -BlockSizeBytes 1MB
・VHDXではなくVHDを使用。AFT対応を考えると非推奨。

OL6が採用しているext4では、容量可変VHDXファイルでもそれ程肥大化しません。

 <インストール時注意点>

VirtualBoxと違い、Hyper-V向けにインストール時に設定変更した方が良い箇所があります。
OL5で設定方法が違う箇所についても記載します。

--OL5,OL6共通
・地域の設定 → システムクロックでUTCを使用 → チェック無。
・ソフトウェアのカスタマイズ → 仮想化 → HyperV → チェック有。

--OL5差分
・ネットワークデバイスの設定 → 編集 → Enable IPv6 support → チェック無。
・ソフトウェアのカスタマイズ oracle-rdbms-server-11gR2-preinstall → oracle-validated。
・ファイアウォール → 無効。
・SE Linux → 無効。

 <インストール後注意点>

OL5とOL6ではネットワーク関連の設定箇所が異なります。殆どGUIから設定可能です。
コマンドも一部変わっています。

・システム → 管理 → ネットワーク
  デバイス → eth<n> → 編集
   全般 → 一旦dhcpを選択 → 「DNS情報をプロバイダから自動取得 → チェック無。
      → 固定のIPアドレス設定 → 再設定。
  DNS → ホスト名 → node<n>.oracle11g.jp
    → 1番目のDNS → 192.168.56.254
    → DNS検索パス → oracle11g.jp
・oracle-rdbms-server-11gR2-preinstall-verify → oracle-validated-verify
・udevadm control --reload-rules → udevcontrol reload_rules

 <暴れるマウス>

OL5の起動後、マウスカーソルの動きに違和感があるかも知れません。

インストール時と同様、仮想マシンのコンソールをクリックしないとマウスカーソルが働かない場合、LISが働いていません。
UEKで起動しているかも知れませんので、/etc/grub.confを見直して再起動する必要があります。

OL5のRHEL互換Kernelでは、ホストOSとゲストOSのマウスカーソルが連動せずに過剰に動きます。
例えるなら、キャリブレーションされていないタッチパネルの様な状況で、非常に使い辛いです。

OL6ではマウスカーソルの問題はありませんが、ホストOSとゲストOS間のクリップボード連携が上手く働きません。

今回はHyper-Vの仮想コンソールを使う事を諦めて、リモートデスクトップソフトのVNCで操作する事にしました。
OL5ではOTN資料通りで「vnc-server」はインストール済だった為、設定のみ行いました。
OL6では「tigervnc-server」をインストールする必要があります。

#/etc/sysconfig/vncservers 追記
VNCSERVERS="2:oracle"
VNCSERVERARGS[2]="-geometry 1024x768"

#接続ユーザ毎に設定
vncpasswd

#サービス起動 設定ファイル作成
chkconfig vncserver on
service vncserver start

#~/.vnc/xstartup 変更
#xterm ...
#twm &
exec gnome-session

#サービス再起動 設定ファイル反映
service vncserver restart

ホストOSのvncviewerから「192.168.56.101:2」へ接続して、node1のoracleユーザのデスクトップを快適に操作可能です。
Javaの例外サイトリストに登録後、ブラウザから「http://192.168.56.101:5802」で接続する事も可能ですが、Nativeアプリの方が快適です。

要注意、vncでログアウトしてはいけません。

 <クローンが無い>

Hyper-Vでは、VirtualBoxの様な親切なクローン機能はありません。
おそらくSystem CenterでTemplate化する方針なのでしょう。
今回は「node1」の仮想ファイル一式をディレクトリ毎手動コピーした後、「仮想マシンのインポート」から「仮想マシンをコピーする(新しい一意なIDを作成する)」を実行しました。
その後、起動用ディスクのリネーム、NICの 静的 → 動的 → 静的 を手動実行しました。

 <重いネットワーク>

ゲストOSの準備が整えば、後はOTN資料通りに11gR2 RACを構築可能です。

但し、Hyper-Vで構築した11gR2 RACは妙に負荷が高く、Load Averageが20を超える事もありました。
同一物理マシンで構築したHyper-Vのスタンドアロンの11gR2や、VirtualBoxでの11gR2 RACはそこまで負荷は上がりません。
私自身が用意した環境ではないのですが、iSCSIを使用したVirtualBoxでのRAC環境も高負荷でした。
Hyper-Vの問題というより、iSCSI S/Wの問題の様です。

調べた所、iSCSIの高速化にジャンボフレーム化が有効という記事がありました。
最大フレームサイズを1.5Kから9Kへ拡大してスループットを向上します。
ジャンボフレーム化する為には、NIC、スイッチ、通信経路を全て対応する必要があります。
ゲストOS側では、eth<n>へMTU=9000を設定しました。
Hyper-Vの仮想スイッチでは、ホストOS側に追加された仮想化NICの「Hyper-V 仮想イーサネット アダプタ #n」のプロパティ → 詳細設定 → Jumbo Packet から、 無効 → 9014Bytes へ変更しました。

「内部」の仮想スイッチではホストOS側に仮想化NICが追加されるのですが、「プライベート」では仮想化NICが追加されません。
「プライベート」でのジャンボフレーム化の設定変更箇所が判らず、「内部」を使用しました。

更に、11gではOracle Netのパケットサイズが2Kから8Kへ変更されています。
その為、RAC用インターコネクトでもジャンボフレーム化は有効だと思います。
但し問題もあり、物理環境の通信経路の設定によっては8Kのパケットでは繋がらない場合もあるとの事です。
10g以前のClientからは繋がるのに、11g以降のClientからは繋がらない、そんな障害も起きる事があるそうです。

ジャンボフレーム化の効果を確認する為、RAC用共有ディスクとは別のLUNをDISK I/Oネックが発生しない様にRAMDISK上に用意して、ホストOS側のiSCSI Initiatorから接続して、CrystalDiskMarkで計測しました。
ジャンボフレームでは特にSequential Readのスコアが倍増しています。

iSCSI 通常フレーム iSCSI ジャンボフレーム
iscsi_ol5_normal iscsi_ol5_jumbo

但し、肝心の11gR2 RACの負荷は、ジャンボフレーム化でも殆ど下がりませんでした。

Oracle自身のI/O測定機能「DBMS_RESOURCE_MANAGER.CALIBRATE_IO」でも確認しました。
このCALIBRATE_IO、Enterprise Editionでは結構重要です。
11.2.0.2以降では、Parallel処理の「自動並列度(Auto DOP)」でCALIBRATE_IOの結果が使用されます。
11gR2(11.2.0.1)登場時に作成された資料では、CALIBRATE_IOの事に触れられていないかも知れません。
CALIBRATE_IOしていないと(RESOURCE_IO_CALIBRATE$が0行だと)、Auto DOPが働かず、Default DOPで実行されてしまいます。
例えば、In-Memory Parallel Executionで実行する為にSQLへPARALLEL(AUTO)ヒントを付けた際、テーブルサイズに関わらずDefault DOPの大量コア数でParallel処理されてしまいます。
Exadataでも同様です。

「DBMS_RESOURCE_MANAGER.CALIBRATE_IO」自身にも結構癖があります。
最初にHDD(SSHD)で試した時は、SSHDのSSD部に乗るのか、実行する度に速くなりました。
iSCSIのディスクをRAMDISKへ移動した後でも、複数回実行すると結果にかなりばらつきが出ました。
今回は5回計測した中間値(3位)で比較しました。

Hyper-V+11gR2 RACでは、iSCSIのディスクをRAMDISKへ移動して、通常フレームとジャンボフレームで比較しました。ジャンボフレームではLATENCYが向 上していますが、LATENCYはばらつきが特に大きく、本当に性能向上しているのか微妙です。
昔、OTN資料を基に作成したVirtualBox+11gR2(通常フレーム)でも、共有仮想ディスクファイルをRAMDISKへ移動して計測しました。IOPSは若干低いスコアでしたが、MBPSとLATENCYはネットワークを経由しない仮想SATAの恩恵か良好でした。
Hyper-V側に低いスコアが並んだので、スタンドアロンのASMの11gR2でも計測しました。iSCSIやRACでのネットワーク遅延が発生しない為、全項目最高スコアでした。


MAX_IOPS MAX_MBPS LATENCY
Hyper-V+11gR2 RAC 通常 14993 280 11
Hyper-V+11gR2 RAC ジャンボ 15646 277 7
VirtualBox+11gR2 RAC 10686 1134 0
Hyper-V+11gR2 ASM 48615 3415 0

RAMDISK上のVHDX自体は3GByte/s以上の帯域があります。
Hyper-Vの仮想化NICは10Gbps(=約1GByte/s)なので、RAMDISKの帯域を使い切れません。
OL5のiSCSIでは仮想化NICの10Gbpsの帯域の1/3も使えていませんでした。

iSCSIの問題かも知れないので、iSCSI以外のプロトコル、ファイル共有のSMB3.02も調査しました。
iSCSI TargetのゲストOSもWindows Server 2012R2へ変更し、ジャンボフレームを有効化し、iSCSI、SMB3.02、双方で使用するVHDXをRAMDISKへ格納して、CrystalDiskMarkで計測しました。
iSCSI Targetの特性は、OL5は4Kが良く、2012R2はSequentialが良好でした。2倍以上の差はなかったので、このH/W,S/Wでは iSCSIはこの位の性能なのでしょう。
SMB3.02は特にSequential Writeが良好でした。4K QD32は4K QD1と変わらなかったので、マルチタスクな処理は苦手なのかも知れません。

iSCSI 2012R2 SMB3.02 シングルチャネル
iscsi_2012r2 smb302_single

仮想化NICの帯域不足の問題なら、ゲストOSの仮想スイッチを2つに増やせば、Active/Activeで稼働するSMBマルチチャネルで更に速度改善出来るかも知れません。
しかし、CrystalDiskMarkのスコアはSMBマルチチャネルもシングルチャネルも殆ど変わりませんでした。
ホストOSのタスクマネージャから仮想スイッチの使用帯域を確認すると、SMBマルチチャネルはシングルチャネルでの上限値を2つのNICで分割した様な数値でした。
ホストCPUの負荷も高く、1コア分の90%近くを使用していました。SMBマルチチャネルのWriteでは別コアへオフロードされている様ですが、合計負荷はシングルチャネルと同様でした。

SMB3.02 マルチチャネル ネットワーク負荷 CPU負荷
smb302_multi task_net_smb task_cpu_smb

複数コアを使用するというReceive Side Scalingは、ホストOS、ゲストOS、共にデフォルトで有効となっており(netsh interface tcp show global)、ゲストOSのVirtual Receive Side Scalingも 無効 → 有効 へ変更してみたのですが、「内部」の仮想スイッチでホスト OSの1コアに負荷が掛かる傾向は変わりませんでした。
今回はネックとなっている箇所まで判りませんでしたが、CPUに負荷をかける仮想スイッチの限界を垣間見た様な気がします。

 <まとめ>

・11gR2 RAC、基本的にはOTN資料通りで大丈夫。
・Hyper-VでOL5ならRHEL互換Kernel。
・Hyper-VでLinuxなら静的MACアドレス。
・DNS1をiSCSI Target化。
・Linuxでもミスアライメントに要注意。
・VHDX作成はPowerShellで。
・OTN資料差分。
・VNCはログアウト禁止。
・Hyper-Vでは手動クローン。
・仮想スイッチは重い。iSCSI S/Wは更に重い。
・DBMS_RESOURCE_MANAGER.CALIBRATE_IOは重要。

明日は渡部亮太さんです。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/409917553
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック