Oracle Real Application Clusterの検証 その２
＜Oracle Real Application Clusterの検証 ～その２～＞
ペンネーム ダーリン
— RAC環境の実際 —
先週からスタートした、Real Application Cluster(以下、RAC)に関する検証
ですが、では、実際にRACでシステムを構築している現場では、どうなってい
るのでしょうか。
まず、RACを構成するシステムのHW構成を見てみましょう。おおむね以下のよ
うになります。
【RACの構成】
Public LAN
--------------------------------------------------------------
| | |
| | Private LAN |
================================================= |
|| | || | || |
|~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~|
| INSTANCE 1 | | INSTANCE 2 | | INSTANCE n |
| | | | | |
| | | | | |
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
| | |
---------------------------------------------
|
|^^^^^^^^^^^^^^^^^^|
| Shared DISK |
| |
| |
^^^^^^^^^^^^^^^^^^^^
************************************************************
"INSTANCE[1-n]" RACを構成するインスタンス。
"Public LAN" データベースにアクセスするためのLAN。
アプリケーションサーバなどが接続されているLAN。
"Private LAN" RACのInter Connectを構成するLAN。
キャッシュフュージョンが利用。
ギガビットイーサで構成されるケースが多い。
"Shared DISK" 各インスタンスで使用する共有DISK。
RACではRAWデバイスで利用するケースが多い。
************************************************************
上記の構成は、これまでのクラスタデータベースと同じように見えます。
ただし、OPSと同様、各インスタンスのOracleは、起動しておりサービス可能
な状態にあります。この辺は、HOT/COLDスタンバイのクラスタデータベース
とは異なる部分です。
つまり、停止しているリソースがないので、リソースの稼働率からみればRAC
の方が有利になります。では、OPSとの違いは？
OPSも全てのインスタンスでサービスが提供できる点についてはRACと同じで
す。大きな違いは、Inter Connectを利用したキャッシュフュージョン(Cache
Fusion)にあります。
キャッシュフュージョンがどのように機能しているかの詳細はここでは記述
しませんが、大まかには、各インスタンスで要求のあった同一Oracleブロッ
クをキャッシュフュージョンによって転送、共有するという仕組みです。
OPSのキャッシュフュージョンは、各インスタンスにおけるREAD/READおよび、
READ/WRITE要求に対応していますが、WRITE/WRITE要求には対応していません。
WRITE/WRITE要求が発生した場合には、一旦DISK上に書き戻し、要求インスタ
ンスでDISKから読み込むと言うステップを踏んでいます。
RACの場合は、WRITE/WRITE要求が発生した場合でもキャッシュフュージョン
によって同一ブロックへの高速アクセスが可能となっています。
つまり、Oracleデータベースでは常にボトルネックのひとつとして上げられ
るDISK I/Oを回避することで、WRITE/WRITE要求が発生する環境下では、OPS
で発生するレスポンスの低下を回避できることになります。
【実際の環境では】
では、実際にRACで構築したシステムでどのくらいの処理性能が得られたか具
体的な数値についてお話しましょう。
ここでお話するシステムはOLTP系で、一時間あたり100万件のデータ更新が見
込まれるような環境です。2インスタンス構成のRACで、各6CPU、メモリは各
8GBのマシンです。
このときの動作検証は以下のような具合です。
アプリケーションサーバをシミュレートしたサーバから、上記データベース
サーバに対して、各インスタンスに対して250session程度のコネクションを
はります。
まずは、片側のインスタンスで処理速度をはかり、続いて両方から同様の処
理を行い、その間の処理速度を計測しました。そのときの数値を以下に記し
ます。さてさてどうなったかと言うと、、
CASE INSTANCE NO SESSIONs EPS(※1) TPS(※2)
=======================================================
01 1 237 16,083 732.3
-------------------------------------------------------
02 1 256 5,453
2 256 5,362
----------------------------------------------
Total 512 10,815 489.4
-------------------------------------------------------
※1:EPS(Execution per second) 単位時間あたりのSQL実行数
※2:TPS(Transaction per second) 単位時間あたりのトランザクション数
CASE01でsession数がちょっと違うのは目をつむってください。
この環境では、2インスタンスのRAC環境でsession数を約2倍にした場合、処
理性能が1インスタンス時のより下がってしまいました。スケーラビリティで
いうところの”0.67″ぐらいです。このときは、ユーザ様も（あきれて？）笑っ
ていましたが、サービスインまでの時間にも余裕があるわけではなかったの
で、心中察するに「胃に穴があきそう」な結果となりました。
※CASE02のTPS=489.4tpsでも、想定トランザクション100万件/時間をクリア
していると言えばそうなんですけど、でもRAC構成にしたら遅くなったでは
困りますよね。
来週からは実際のチューニングの作業と検証結果を交えてお話していきます。
皆さんも一緒にチューニングの現場を覗いてみてください。
社内のRACを壊しちゃったどうしよう、、 茅ヶ崎にて