Oracle RAC アクティブ/アクティブ

Oracle Real Application Cluster (RAC) は、分散ロック・マネージャーのある、すべてを共有するデータベース・クラスターです。

すべてを共有するデータベースとして、すべての RAC ノードは同じデータ・ファイルにアクセスして更新します。分散ロック・マネージャーは、どのノードがデータを更新するかを制御します。どのノードでトランザクションが実行されるかは関係ありません。各ノードには、共有データベース内のデータにアクセスする同等の権利があります。

各 RAC ノードには、クライアント・プログラムからのデータベース接続要求を処理する責任を持つリスナー・プロセスがあります。リスナーが要求を受け取ると、クライアント・プログラムの接続先となる新しいデータベース・プロセスを spawn します。サーバー・サイドのロード・バランシングが使用可能な場合、リスナーは使用率の最も低い RAC ノードのリスナーに要求を送信します。

Oracle は、 Oracle RAC 11g リリース 2 からグリッド・インフラストラクチャーを導入しました。これにより、 Oracle は、 Oracle ASM と Oracle Clusterware の 2 つの製品を 1 つのソフトウェア・バンドルに統合しました。 Oracle Grid Infrastructure は、Oracle RAC データベースを稼働するためのボリューム管理、ファイル・システム、およびサーバー・プール管理に必要な機能を提供します。

Oracle RAC を使用する Sterling Order Management System Software の構成

Oracle RACで Sterling™ Order Management システム・ソフトウェアを構成する場合、RACノードを適度にバランスさせ、一定期間にわたってすべてのRACノードの使用率がほぼ同じになるようにします。ノードの障害時には、障害が起きたノードからの接続が、存続している RAC ノードに自動的に再接続されるようにもする必要があります。これはクライアント・サイドおよびサーバー・サイドで Oracle の機能を使用して行うことができます。

SCAN を使用したクライアント・サイドのロード・バランシング

Oracle RAC 11g リリース 2 は、データベースへのクライアント・アクセスをシンプル化する Single Client Access Name (SCAN) を導入しました。 SCAN では、クラスターが拡張しても、またはクラスター内のノードが時間とともに変わっても、変わらない単一の名前をクライアント接続要求で使用することができます。これにより、JDBC でシンプルな接続ストリングを使用することができます。ノードのさまざまな IP アドレスへのラウンドロビンを行う単一の名前として、DNS 内で SCAN を定義する必要があります。これらの IP アドレスは、クラスターのパブリック・ネットワークとして同じサブネット上にあることが必要です。

JDBC の URL は以下のとおりです。

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=ON)(FAILOVER=ON)(ADDRESS=(PROTOCOL= TCP )(HOST=racscan)( PORT=1521 ))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=racdb)))

Oracle RAC 11g リリース 2 は、Oracle RAC の VIP 管理を自動化することにより拡張を容易にする、グリッド・ネーミング・サービス (GNS) を導入しました。 Sterling Order Management System Software 9.1 は、GNS が有効になっている状態ではテストされていません。

SCAN について詳しくは、Oracle RAC の資料を参照してください。

すべてのデータベース・ノードで、tnsnames.ora ファイルに以下の値があります。


 RACDB =
  (DESCRIPTION = 
   (ADDRESS = (PROTOCOL = TCP)(HOST = racscan)(PORT = 1521)) 
    (CONNECT_DATA = 
    (SERVER = DEDICATED)
    (SERVICE_NAME = racdb)
   )
    )

RACDB は、以下の図に示されたように、クライアント・サイドのロード・バランシングの net_service_name です。

Sterling Order Management 「システム・ソフトウェア」パースペクティブから、RAC サーバー・インスタンスの障害後に以下のことが発生すると予想できます。

アクティブに処理をしていたアプリケーション、エージェント、および統合サーバー内のトランザクションが、SQL エラー・メッセージをスローします。残りの RAC ノードはそれらのトランザクションからの変更をロールバックします。
Sterling Order Management System Software エージェントおよび統合サーバーは、継続的に再接続を試みます。残っている RAC インスタンスの 1 つに接続すると、失敗したトランザクションが再処理されます。他のいずれかのアクティブ・ノードへの移行中に、 Sterling Order Management System Software サーバーを再始動する必要はありません。
作業要求のソース (特にエージェントおよび統合サーバーの場合) がメッセージ・キューから来る場合、メッセージはメッセージ・キュー内に残ります。データベース・サービスが復元されると、これらのメッセージは処理されます。