RAC One Node の検証 その９
＜RAC One Node の検証 その９＞
ペンネーム : ダーリン
今回は、検証結果のおさらいと構築時にちょっと気を使った点をお
話します。
まずは、検証結果のおさらいから。
■ 検証結果のまとめ
当シリーズでの検証項目は以下の通りです。
□ ライブ・マイグレーション
1) Omotion
メモ：
Omotion 実行前に環境変数の設定を忘れずに。
export LANG=C
export NLS_LANG=American_America.US7ASCII
(or export NLS_LANG=American_America.UTF8)
export LC_ALL=C
( 切替にかかる時間 - 新規接続できない時間はある？ )
メモ：
当検証環境では Omotion 実行時間中（ 2 分 40 秒程度）
少なくても 60 秒程度は、新規接続が不安定な時間があ
りそう。
( 切替にかかる時間 - 既存の接続は？ )
メモ：
サービスが切り替わるタイミングで一時的に接続がきれ
るタイミングがあり、その時間は 10 秒程度と思われる。
新規接続の場合と比較すると短時間で、かつその際のト
ランザクションは保証される。
( 切替前後のインスタンス名が変わるので注意 )
メモ：
今回の検証環境を例にとると、Omotion を実行した場合
ノード１側で RON_1 で起動していたインスタンスは切替
後ノード２側で RON_2 となります。
障害発生時のフェイルオーバーにおいては、インスタン
ス名は変わらずに " 移動 " するので実運用の際には要
注意。
□ 障害発生時
2) サーバダウンをシミュレート
メモ：
今回は OS の shutdown でシミュレート。
( 切替にかかる時間
- Oracle が起動する間はやむを得ない。 )
メモ：
Omotion とは違ってスタンバイ側の Oracle が起動して
いない状態で切替が始まるので、Oracle のインスタンス
が起動するまでの時間はまるまる接続できません。
3) インターコネクト断線をシミュレート
メモ：
RAC One Node はアクティブなインスタンスがひとつなの
でインターコネクトが切れても影響ないと思ったが、そ
うでもないらしい。
( ノード１でデータベースが起動しているときはノード２のサー
バが OS ごと停止・再起動する。 )
メモ：
一応、ノード１側のインスタンスが停止するわけではな
く、サービスには影響ないが、ちょっとびっくり。
( ノード２でデータベースが起動しているときもノード２のサー
バが OS ごと停止・再起動する。かつ、データベースはノード
１であらたに起動する。 )
メモ：
eth1 を停止した場合、隠しパラメータの設定が必要。
(_disable_interface_checking = TRUE)
まさかまさかのインスタンスが起動しているノードの停
止・再起動。運用に際しては注意したい。メンテナンス
目的でノード２側でインスタンスを起動しているのであ
れば、必要な作業が終了し次第、ノード１側にきり戻し
ておいた方がよさそう。
4) インターコネクト断線 + CRS 書き込み障害 をシミュレート
メモ：
ノード１側から CRS への書き込みができないのなら、さ
すがにノード１が生き残ることはなく、ノード２でイン
スタンスが起動するだろうと期待。
(若干の胸騒ぎを感じつつ….)
( ノード１でデータベースが起動しているときノード１はもとよ
り、ノード２も停止。その後ノード２で Oracle が起動しよう
としているようだが、インスタンス 2 重起動のようなエラー
で起動できず。 )
メモ：
つまりサービス停止。さすがに仕様というわけではない
らしく、ノード２側で起動しようとしている気配はあり
ました。よって、検証環境の問題かあるいは不具合か？
（これは今回の検証においては残念ながら切り分けに至
らず）
総括：
トランザクションを保証しつつ、ライブマイグレーションが可能
という面で非常に興味深いところがあります。
今回の検証では多重障害時の挙動を除いて、インスタンスが完全
に停止することは ありませんでした。多重障害発生時の挙動につ
いてはもう少し調査する必要がありそうです。
このシリーズの最初に少しお話しましたが、RAC One Node の魅力
はサーバ統合において発揮されるのではないかと考えています。
その場合は、単体の物理サーバ上に複数のRAC One Node のイン
スタンスが稼働していると考えられます。障害が発生するとこれ
らのインスタンスが一気に生存しているサーバに移動します。
そんな場合でも問題なく動作できるように、移動先のサーバを設
定するなどの考慮が必要になるでしょう。移動先が完全にスタン
バイとは限りませんからね。(※)
※ リソース分散を目的として完全なスタンバイサーバを設けず、
複数のアクティブなサーバが相互にスタンバイを兼任する構成
をとるような場合。
昨今の一般コンシューマ向けのシステムなどで、サービスの成長
度合いによるためいきなり大規模なシステムを構築はできないの
で、スモールスタートしたい。でも、システム規模に上限を設定
することができない。という場合もあるのではないでしょうか。
RAC One Node は、いうまでもありませんが無数の実績を持つ Oracle
RAC への移行が可能です。さらに、Enterprise Edition が前提と
なるため RAC に移行してしまえば SE RAC のようなノード数の制
限 ( 正確にはソケット数の制限 ) がありません。
統合データベースの解決策と、将来の拡張性に富んだソリュー
ションを同時に手に入れることができるかもしれません。
■ 構築時の注意事項
続いて、構築時の注意事項について
さて、今回は当メルマガでは初の 11gR2 環境での検証でしたので
構築時にちょっと気を使ったところをいくつか紹介しておきます。
<<>>
Oracle Database 11gR2 で RAC 環境を構築する場合、従来と同じく
クラスタウェアを導入する必要があります。従来 CRS (Cluster
Ready Service ) と呼ばれていたサービスでクラスタ配下のリソー
スを管理していましたが、11gR2 では、さらに、Grid Infrastructure
と呼ばれる概念が導入されています。
Grid Infrastructure の詳細については Oracle 社の資料に譲ると
して 11gR2 の RAC を構築する際にはまず、Grid Infrastructure
を導入する必要があります。この管理者ユーザとして OS 上に grid
というユーザを作成します。検証中に crsctl コマンドを実行して
いたユーザがこの grid ユーザです。
Grid Infrastructure を導入する際に出てくるこれまた新しい用語が
SCAN ( Single Client Access Name ) です。
Oracle 社の推奨では、DNS 等を利用して設定することになっていま
すが、今回は、検証環境の都合上、hosts ファイルを使用して SCAN
の設定を行っています。この場合以下の点に注意する必要があります。
hosts で SCAN IP を設定した場合、インストールの最後にインストー
ラでエラーが出ます。
その際、ログファイルに以下のようなメッセージが出ますがこれは
無視して良いようです。
$ORACLE_BASE/oraInventory/logs/installActionsYYYY-MM-DD_HH-MI-SS[AM|PM].log
-------------------------------------------------------------
情報: 単一クライアント・アクセス名(SCAN)をチェック中...
情報: "oel55sv-cluster-scan"の名前解決の設定をチェック中...
情報: ERROR:
情報: PRVF-4664 : SCAN名"oel55sv-cluster-scan"に対して一貫性のない名前解決エントリが検出されま
した
情報: ERROR:
情報: PRVF-4657 : "oel55sv-cluster-scan"の名前解決の設定チェック(IPアドレス: 192.168.100.181)に
失敗しました
情報: ERROR:
情報: PRVF-4664 : SCAN名"oel55sv-cluster-scan"に対して一貫性のない名前解決エントリが検出されま
した
-------------------------------------------------------------
<<>>
SCAN の設定を無事終えて、Grid Infrastructure の導入が完了し
たら、Oracle Database のインストールです。
Oracle Database をインストールする際にいくつか面倒だなぁと
思うことがありますが、カーネルパラメータもそのひとつです。
今回も変更漏れがあったようなので、早速チェックで引っかかっ
てしまいました。。
ところが、さすが最新のインストーラはちょっと違います。
カーネルパラメータが要件を満たさない場合は、なんと、カーネ
ルパラメータを再設定するためのスクリプトを生成してくれる機
能が用意されていました。
これを使わない手はありません。
早速これを適用して無事 Oracle Database の導入を完了。
好事魔多しとはこのことです。CRS が起動しません。
早速 CRS のログを確認します。
/u01/app/11.2.0/grid/log/diag/clients/user_root/host_3864432128_76/trace/ora_2862_3046087440.tr
c
-------------------------------------------------------------------------------------------
2010-06-28 16:52:22.883675*:0000000F:KGF:kgfn.c@1043: error handle created
2010-06-28 16:52:22.883675*:00000010:KGF:kgfp.c@391: kgfpInitComplete hdl=0x9def420 conn=0
x9def42c ok=0
2010-06-28 16:52:22.883675*:00000011:KGF:kgfo.c@620: kgfo_kge2slos error stack at kgfoAl06
: ORA-15077: 必要なディスク・グループに対応するASMインスタンスが見つかりませんでした
2010-06-28 16:52:22.883675*:00000012:KGF:kgfo.c@539: kgfoFreeHandle ctx=0x9de82ac hdl=0x9d
ef41c conn=0x9def42c disconnect=0
-------------------------------------------------------------------------------------------
というわけで、ASM がおかしいようです。
そうそう 11gR2 からは CRS 領域も ASM 上で管理することができま
す。今回は CSR を ASM 上で管理させるようにしているので、ASM
が無事起動しないと CRS が起動しないのです。
続いて ASM のログを確認します。
/u01/app/grid/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log -------------------------------------------------------------------------- Mon Jun 28 16:52:19 2010 NOTE: No asm libraries found in the system Starting ORACLE instance (normal) Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_2691.trc: ORA-27154: post/wait create failed ORA-27300: OS system dependent operation:semget failed with status: 28 ORA-27301: OS failure message: No space left on device ORA-27302: failure occurred at: sskgpsemsper --------------------------------------------------------------------------
“No space left on device” とかかかれていますので、「disk full
かぁ？」と思いましたが、その 1 行上に目が留まりました。
ORA-27300: OS system dependent operation:semget failed with status: 28
「 semget で failed 」？？？
セマフォはチェックもクリアしているので大丈夫なはずなのですが、
では念のため、、、
# sysctl -p | grep sem kernel.sem = 250 100
ふーん….ん？
いや、なんかおかしい。
というわけで、sysctl.conf を確認すると、、、、
/etc/sysctl.conf
------------------------------------------
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 4294967295
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 268435456
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
kernel.sem = 250 100
------------------------------------------
なんと！！ OUI の修正スクリプトで修正したはずのカーネルパラ
メータのセマフォの値(kernal.sem)が足りない。
kernel.sem = 250 100 ↓ kernel.sem = 250 3200 100 128
これを手で修正すると無事 CRS も起動しました。
便利に目がくらむとやはり痛い目に遭いますね。
<<>>
Oracle Database を導入してしまえば、RAC One Node の導入は特
に問題ないでしょう。
強いて言えば、DBCA を実行する際に作業しているノードのみを選
択して処理を行うのですが、どうやら選択されなかったノードには
tnsnames.ora のファイルが作成されません。
よって、DBCA 終了後に別ノード側からリスナー接続しようとして
も接続できないので、必要に応じて DBCA を実行したノードの
tnsnames.ora に作成されているエントリを、別ノード側の tnsnames.ora
に追加する必要があります。（今回の検証ではそもそも DBCA で選
択しなかったノードには tnsnames.ora 自体が存在していませんで
した。）
■ ライセンスについてのたわごと
さて、今回で RAC One Node の検証は終了です。
最後にライセンスについて少し触れておきましょう。
RAC One Node では Enterprise Edition が前提となります。さらに
RAC One Node 用のオプションが必要になる点が気がかりなところで
す。
実際のところ、RAC One Node を検討するようなケースがあれば
SE RAC との比較がついてまわるのではないでしょうか。
今回のキーワードにしている、データベース統合を踏まえて考えて
みます。たとえて言うならば、判断するポイントは「ひとつのノー
ドにインスタンスをいくつ統合させるのか」という点ではないでしょ
うか。
プロセッサライセンスでは、Standard Edition は 約 200万/CPU
Enterprise Edition では 約 500万/CPU です。
RAC One Node は オプションが必要でこれは約 100万/CPU です。
たとえば 16 のデータベースを SE RAC あるいは、EE RAC One Node
に詰め込んでみましょう。
仮に総プロセッサ数 8CPU の環境に統合したとします。
(アクティビティーがあまり大きくない環境ということにしましょう。)
(また、Linux サーバで Xeon プロセッサを前提とし 総 core 数が
32 core になる前提です)
SE RAC の場合：
8 CPU x 200万 = 1600万 （100万/データベース）
想定環境 : 2 ソケット/ノード 4core/CPU
2 ノード RAC
上記 SE RAC 2 セット
EE RAC One Node の場合：
8 CPU x 4core x 0.5 x 500万 + 8CPU x 4core x 0.5 x 100万 = 9600万
（600万/データベース）
想定環境 : 8 ソケット/ノード 4core/CPU
1 ノード
※ スタンバイ機は基本的にはライセンスがかからない
ため考慮外。
RAC One Node を構築するとなると SE RAC の、約 6 倍 ！？
結構違うのね。
SE RAC の場合通常データベースはそれぞれのノードにインスタン
スを持つため、2 ノードの場合は 1データベース辺り 2 インスタ
ンス起動しています。そのおかげで単一のノードで障害が発生し
た時でもサービス停止が発生しないというメリットがあります。
仮に、SE RAC で高可用性と引き換えに起動するインスタンス数が
2 倍必要になるならば（ちょっと強引ですが RAC のセットを倍に
増やすと仮定するならば)
SE RAC の場合： 200万 / データベース (総core数 64)
EE RAC One Node の場合：600万 / データベース (総core数 32)
それでも RAC One Node だと SE RAC と比較して 3 倍もライセン
ス費用がかかってしまいますね。
サポート費用やサーバ保守などの費用も考慮に入れる必要があるた
め単純な比較はできませんが、ライセンスのみをみると RAC One
Node は安易に選択できるものではないかもしれません。
やはり、EE 版でのみ利用できる オプション（パーティショニン
グ、Enterprise Manager など）や、そのあとの拡張性状況まで考
慮して RAC One Node の採用を検討する必要がありそうですね。
また、移行の際には以下の様な点を考慮する必要があります。
Enterprise Edition から Standard Edition への移行の場合
Standard Edition のライセンス分は新規で必要になります。
Standard Edition から Enterprise Edition への移行の場合
ライセンス費用の差額が必要になります。
つまり移行のケースによっては、新しく Enterprise Edition に
移行する方がライセンスの追加費用が抑えられる可能性もありま
す。
※ 上記の価格は以下の情報を参考におおよその数値をあてはめてい
ます。
価格表
http://www.oracle.com/lang/jp/corporate/pricing/doc/e_PL100907_100907a_n.pdf
ライセンス見積の基本的な考え方
http://www.oracle.com/lang/jp/direct/oracledatabaselicense.pdf
Oracle Processor Core Factor Table
http://www.oracle.com/lang/jp/corporate/pricing/doc/Processor_Core_Factor_Table_jp.pdf
数字のお遊びはここまで。
ではまたいつか、あらたな検証でお会いしましょう。