Oracle RACノードの重み付け（Node Weighting）機能とは？スプリットブレイン対策の新アルゴリズムを解説

Oracle RACにおけるスプリットブレインとは

Oracle Real Application Clusters（RAC）環境では、すべてのインスタンス（サーバー）がプライベートネットワーク上の高速インターコネクトを介して相互に通信しています。RACのメンバーインスタンスがこのプライベートインターコネクト経由でのpingや接続に失敗すると、物理的には稼働し続けているサーバー（およびその上のデータベースインスタンス）がスプリットブレインと呼ばれる状態に陥る可能性があります。

Oracle RAC 12c Release 2以前のOracleクラスタでは、ネットワークやディスクの問題によってスプリットブレインが発生した場合、最も小さいノード番号を持つノードがクラスタ内で生存していました。しかし、最新のOracle RAC 12c Release 2では、スプリットブレインによってサブクラスタに同数のノードが形成される特定ケースにおいて、退避候補ノードを選択するアルゴリズムに変更が加えられました。

本記事では、新しいノード重み付け機能に基づくOracle RAC 12c Release 2のノード退避アルゴリズムの変更点について解説します。

ノード重み付けアルゴリズムの概要

下図は、ノード重み付けアルゴリズムの仕組みを示したものです。

出典：https://goo.gl/images/qarxrq

ノード重み付けは、Oracle RAC 12c Release 2で導入された新機能で、フェンシング時にクラスタでホストされているワークロードを考慮します。スプリットブレインが発生すると、Oracle Clusterwareは一定のルールに従って生存させるグループを選択しますが、その過程で重要なリソースを実行中のノードが退避させられる可能性があります。この新機能を利用すれば、特定のノードに重みを割り当てることで、そのノードがクラスタから強制排除されるのを防ぐことができます。

新しく追加されたタグCSS_CRITICALは、さまざまなレベルやコンポーネントに対して「クリティカル」のマークを付けるために設定でき、障害発生時にクラスタがそれらを保護しようとします。スプリットブレイン発生時にOracle Clusterwareがどのノードを退避するかを判断する際、技術的な理由でノードの生存が妨げられない限り（障害発生時に少なくとも1つのクリティカルコンポーネントを持つノード）、CSS_CRITICALタグは尊重されます。この仕組みにより、他の条件が同等であれば、大部分のワークロードへの影響を回避できます。

ノード重み付けアルゴリズムの処理内容

ノード重み付けアルゴリズムは、以下の処理を行います。

• データベースインスタンスまたはサービスへの重み付け： srvctl add databaseやsrvctl add serviceコマンドでデータベースインスタンスやサービスを追加する際に、-css_critical yesを指定できます。また、srvctl modify databaseおよびsrvctl modify serviceコマンドでパラメータを後から設定・変更することも可能です。
• ora.*以外のリソースへの重み付け： リソースの追加・変更時には、crsctl add resourceおよびcrsctl modify resourceコマンドに-attr CSS_CRITICAL=yesパラメータを使用します。
• サーバーへの重み付け： crsctl set serverコマンドで-css_critical yesパラメータを設定します。

以下は、データベースインスタンスやサービスに重みを割り当てる実行例です。

$srvctl modify database –d <dbname> css_critical yes
$srvctl modify service –db <dbname> -service <service_name> css_critical yes

リソースに重みが割り当てられていない場合、アルゴリズムは以下の観点を評価します。

• どのノードに最も多くのサービスが作成されているか？
• そのインスタンス用にシングルトンサービスが作成されているか？
• そのノードはFlex ASMインスタンスとして構成されているか？
• パブリックネットワークの障害が発生していなかったか？
• ノードのタイプは何か（ハブまたはリーフ）？

テストケース

以下の手順では、bond2を2ノードクラスタのプライベートインターコネクトとして使用しているケースを確認します。

$oifcfg getif
bond0  147.167.80.0  global  public
bond2  10.168.33.32  global  cluster_interconnect
$olsnodes -s -n
node1   1       Active
node2   2       Active
$
$crsctl set server css_critical yes
$crsctl get server css_critical
CRS-5092: Current value of the server attribute CSS_CRITICAL is yes.
$

次に、node1とnode2間の通信障害をシミュレートするため、bond2を停止します。

#ifdown bond2

$olsnodes -s -n
node1   1       Active
node2   2       Inactive

このときのOCSSD.trcの出力は以下の通りです。

2018-01-09 11:01:21.220 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.220 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: Server pool version not consistent
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: stamp(393228187), completed(1/2)

まとめ

RAC 12c Release 2以降、スプリットブレイン発生時に退避または保持されるノードを決定する新しいアルゴリズムは、以下のように動作します。

• サブクラスタのサイズが異なる場合： 以前のリリースと同じ動作になります。
• すべてのサブクラスタが同サイズの場合： 動作が以下のように変更されました。
  • サブクラスタのノード重みが等しい場合：ノード番号が最も小さいサブクラスタが生存します。これにより、2ノードクラスタでは最小ノード番号のノードが生存することになります。
  • サブクラスタのノード重みが異なる場合：より高い重みを持つサブクラスタが生存します。これにより、2ノードクラスタでは重みが低い方のノード（最小ノード番号のノード）が退避されることになります。

サーバーの重みに基づくノード退避を活用することで、スプリットブレイン発生時にどのクラスタノードを終了・退避させるかを選択でき、Oracle Clusterwareの障害回復メカニズムをより柔軟に制御できるようになります。本トピックに関するご質問やご不明な点があれば、下記のコメント欄からお気軽にお寄せください。