Oracle Real Application Clusterの検証 その2

<Oracle Real Application Clusterの検証 ~その2~>
ペンネーム ダーリン

— 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を壊しちゃったどうしよう、、 茅ヶ崎にて