Active GridLink for RAC 検証解説 ( @WebLogic Server 12c Forum ) by NEC

Oracle RAC の性能を最大限に引き出す！WebLogic 新機能

Active GridLink for RAC の詳細解説

2013/02/01

NEC 第三ITソフトウェア事業部

Agenda

▐ 検証環境

▐ 実行時接続ロードバランス(RCLB)

▐ Webセッション・アフィニティ

▐ 高速接続フェイルオーバ(FCF)

▐ オラクル製品の強みとNECの強み

検証環境（HW構成図）

バブリックLAN －1000BASE-TX －冗長化あり（bonding）

クライアント兼管理サーバ

ストレージ

DBサーバ4 DBサーバ3

APサーバ1 APサーバ2

DBサーバ1 DBサーバ2

インターコネクトLAN －1000BASE-TX －冗長化あり（bonding）

FC接続ー4Gbps

管理用LAN －1000BASE-TX －冗長化なし (パブリックLANとは別セグメント)

4ノードRAC テスト内容に

よってノード数を調整

WebLogic クラスタ 2ノード

ランタイム接続ロードバランシング（RCLB）

▐ 検証の目的

負荷分散に使用されている情報から、構成や設定の指針を確認する

実行時接続ロードバランシングによるDBリソースの自動配分を確認する

▐ RCLB目次

バランシングに使用している情報

負荷の偏りによるバランシング動作の確認

▐ RCLBを使用すると、接続プールからgetConnectionする際にロードバランシング情報に基づいて接続先のRACノードを選択します。

RACからWLSに送信されるロードバランシング情報には何%の割合でどのRACノードへの接続を取得するかが含まれています。

この割合は実行時MBean の CurrentWeightの値で確認でき、各RACノードに対する CurrentWeight を合計すると100になります。


CurrentWeightは 30秒間隔で変化する。

同時刻の全RACノードの CurrentWeightを合計すると100になる。

3ノードRACでTHROUGHPUTを目標にし、 CPU使用率80%前後の負荷をかけた時のCurrentWeight 30～35%程度で推移している。


▐ RACは30秒に1回の間隔でWLSにロードバランシング情報を送信します。

ロードバランシング情報は、各RACノードの統計情報から計算され、各RACノードに振り分ける割合の情報が含まれています。

▐ 利用する統計情報はRCLBの目標（RAC側の設定値）によって異なります。

SERVICE_TIMEの場合

「1コール当たりの経過時間」 V$SERVICEMETRIC の ELAPSEDPERCALLが短いRACノードに多くのリクエストを振り分けるように動作します。

THROUGHPUTの場合

「1秒当たりのユーザー・コールの数」 V$SERVICEMETRIC の CALLSPERSECが大きいRACノードに多くのリクエストを振り分けるように動作します。

NONEの場合

ロードバランシング情報は送信されず、動的なロードバランシングを行いません。

▐ 意図的に片方のRACノードに負荷を偏らせRCLBの動作を確認しました。

大きく3パターンの検証を実施しています。

WLSからの処理と、別の処理で同一のRACサービスに対し負荷をかける

WLSからの処理と、別の処理で異なるRACサービスに負荷をかける

Oracleとは無関係のCPU使用率の高いシェルスクリプトを起動する

その他、様々なテストケースを実施し、バランシングに使用される情報を切り分けました。


マシン1

DataBase1

マシン2

DataBase2

マシン1

DataBase1

マシン2

DataBase2

マシン1

DataBase1

マシン2

DataBase2 WLS WLS

SQL*Plus

WLS

ケースA ケースB ケースC

サー

ビス

A

サー

ビス

A

サービスB

サー

ビス

A

SQL*Plus

SQL*PlusはWLSと同一のサービスでDataBase1に負荷をかける

SQL*PlusはWLSと異なるサービスで DataBase1に負荷をかける

Oracleとは無関係のプロセスでマシン1に負荷をかける


▐ ケースA 結果

DB処理時間が大きくなったノードへの振り分けの割合が大きく低下します。同じサービスに負荷を与えた場合にはRCLBに影響があると言えます。

CurrentWeight WLS側のMBean属性で、各RACノードへの振り分けの割合を示す。

V$SERVICEMETRIC. ELAPSEDPERCALL RAC側のメトリックで、 1コールあたりのDB処理時間を示す。

■・・・RACノード1 ■・・・RACノード2 別業務(SQL*Plus)を

実行した時間帯

ケースA: WLSからの処理と、別の処理で同じRACサービスに負荷をかける


▐ ケースB 結果

負荷をかけた時間帯でDB処理時間が多少上がって見えますが、同じサービスに負荷をかけたケースAよりも振れ幅は小さくなりました。



■・・・RACノード1 ■・・・RACノード2

別業務(SQL*Plus)を実行した時間帯

ケースB: WLSからの処理と、別の処理で異なるRACサービスに負荷をかける

負荷が偏った際のバランシング動作の確認

▐ ケースC 結果

別のサービスに負荷をかけた検証ケースBと似たような結果となりました。



■・・・RACノード1 ■・・・RACノード2

ケースC: Oracleとは無関係のCPU負荷で偏らせた場合

CPU負荷のかかるシェルスクリプトを実行した時間帯


▐ 結果

RCLBはサービスごとにレスポンスタイムやスループットを測定し、バランシングに利用しています。

サービス外の負荷はそのサービスのバランシングに影響しません。

マシン内でリソースが競合する場合は間接的にバランシングに影響します。

間接的に他のサービスのレスポンスタイムやスループットが低下し、それを元にロードバランシング情報を計算するからです。

つまりリソースが十分にある場合は、RCLBはほぼ均等に振り分けを行います。

▐ ポイント

レスポンスタイムやスループットに大きな差がある業務は、サービスを分けて別々のサービスにアクセスすることが推奨されます。 (お互いの業務でRCLBのバランシングへの影響が大きいためです)

Webセッション・アフィニティ

▐ 検証の目的

キャッシュ・フュージョン抑制効果の確認

性能向上の確認

▐ Webセッション・アフィニティ目次

アフィニティ使用によるパフォーマンス向上

セッション・レプリケーションにおけるアフィニティの引き継ぎ

RCLBとセッション・アフィニティの優先関係


▐ アフィニティの効果を実証するために、以下の検証を行いました。

アフィニティありとアフィニティなしで比較

買い物カゴ処理や会員情報の更新・参照のような処理を想定し各HTTPセッションが自分のデータを参照・更新するアプリケーション

リクエストはgetConnection→Update、getConnection→Selectを交互に行う

getConnection時に選択するRACノードはGridLinkの動作にまかせる。

session getConnection

奇数回:Update

偶数回:Select


▐ 結果(2ノードRAC)

レスポンスタイムは約半分に、インターコネクト通信量は大幅に減少させることができました。

0.000

1.000

2.000

3.000

4.000

5.000

None Session

Response Time Avg - 2 Node ms

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

None Session

Estd Interconnect traffic - 2Node Kbyte/s

Affinity-policy Response Time(ms) Estd Interconnect traffic(Kbyte/s)

None 4.311 8238.445

Session 2.184 129.195


▐ 結果(4ノードRAC)

レスポンスタイムは半分以下に、インターコネクト通信量も2ノードRAC同様、大幅に減少ができました。

0.000

1.000

2.000

3.000

4.000

5.000

6.000

7.000

8.000

9.000

10.000

11.000

12.000

13.000

14.000

None Session

Response Time Avg - 4 Node ms

0100020003000400050006000700080009000

100001100012000130001400015000

None Session

Estd Interconnect traffic - 4Node Kbyte/s

Affinity-policy Response Time(ms) Estd Interconnect traffic (Kbyte/s)

None 12.539 13907.678

Session 5.691 475.435

▐ アフィニティの継続

WLSがフェイルオーバしてもHTTPセッションが同一であれば、フェイルオーバ前と同じRACノードを接続先として使用します。

WLS障害時もキャッシュ・フュージョンの抑制効果は継続され、突発的にキャッシュ・フュージョンが増加し悪影響がでることはありません。

セッション・レプリケーションにおけるアフィニティの引き継ぎ

session

session

session

session

session

session

セッションレプリケーション

session

session

session


▐ アフィニティの基本動作

初回接続 → RCLBでRACノードを選択

2回目以降 → 初回接続で選んだRACノードを選択

▐ アフィニティの自動ON/OFF

Webセッション・アフィニティはRCLBのバランス状況やキャッシュ・フュージョンの発生状況に応じON/OFFが自動で変わります。

session session

RACノードの負荷状況に差がある

クラスタ待機時間の増加

アフィニティON

初回

2回目以降 RCLBのみ

アフィニティOFF


▐ アフィニティのON/OFFが切り替わる様子

●最初はアフィニティで接続を選んだ回数が増えている

RACの負荷が偏った → ▼ RCLBで接続を選ぶ回数が増える

RACノード1に追加の負荷

キャッシュ・フュージョンを発生させた → ●アフィニティで接続を選ぶ回数が増える

← RACノード2への振り分け割合 ← RACノード1への振り分け割合

■・・・接続を選んだ回数の合計 ●・・・アフィニティで接続を選んだ回数 ▼・・・RCLBで接続を選んだ回数

■

●

▼

高速接続フェイルオーバ（FCF）

▐ 検証の目的

FCFによって短縮できる障害種類の見極め (DBダウン、DBストール、NW障害等)

SQL処理中のRead待ち状態での障害についてAP停止時間を短縮する

動的なRACノード追加によるパフォーマンスの向上と拡張性の向上

▐ FCF目次

FCFの有効性とAP停止時間の確認

動的なRACノード追加によるパフォーマンス向上の確認


▐ 障害は以下のポイントで発生させています。

マシン2

DataBase2

マシン3

DataBase3

接続プール

WLS

パブリックネットワーク障害

マシン1

DataBase1

L3スイッチ

インターコネクト障害

プロセスダウンプロセスストール

WLSネットワーク全損

AP

プロセスダウン障害、プロセスストール障害は以下の状況を想定しています。 • バックグラウンドプロセスダウン・・・ DBのインスタンスダウンを想定 • バックグラウンドプロセスストール

・・・マシン障害やOS障害に引き摺られてOracleが正常に処理を実行できなくなった状況を想定し、監視系プロセスを含めてストールさせています。

障害発生～再接続までの流れ

▐ パブリックネットワーク障害

Oracle Clusterwareが検知し、仮想IP(VIP, SCAN)とSCANリスナーを生存ノードにフェイルオーバします。

VIPのフェイルオーバによりサービスダウンが発生・検出され、生存ノードからFANイベントが通知されます。

マシン1

DataBase1

マシン2

DataBase2

接続プール

WLS

生存ノードのパブリックネットワークを通じて FANイベントが送られる。 (NODE_DOWN, SERVICE_DOWN)

VIPのフェイルオーバにより、サービスダウンが発生する。

ネットワーク障害発生 1

2

3

4

エラーが返り、 DataBase1への接続がクリーンアップされる。（APからgetConnectionで正常な接続に張替）

AP

▐ 結果一覧

障害発生～Read待ちリクエストにエラーが返るまでの時間は下記となりました。

パブリックネットワーク障害、インターコネクト障害

- アプリケーションがエラーを検知するまでの時間を短縮することができました。

プロセスストール障害

- 今回実施したケースではRAC側での障害検知に時間がかかり、 FANイベントが送信されないため、停止時間は短縮されませんでした。


FCFの有無

障害の種類 FCFなし FCFあり

FCFによって AP停止時間が短縮されたか?

プロセスダウン即時

即時 ×

プロセスストール 6分20秒

6分10秒他製品との連携で短縮可 ×

パブリックネットワーク障害

9分30秒 TCP keepaliveタイムアウト

15秒生存ノードからのFAN ○

インターコネクト障害 (RAC3ノード)

5分 TCP keepaliveプローブ1回目送出

33秒全ノードからのFAN ○

WLS側ネットワーク障害

9分30秒 TCP keepaliveタイムアウト

9分30秒 TCP keepaliveタイムアウト ×

プロセスストール障害について

▐ プロセスストール障害を早期に検知する方法

プロセスストール障害は、FCF単体の機能では早期のエラー検知ができません。

FCFではRAC側の監視機能で障害を検知しFANイベントが飛んで初めて APにエラーが返ります。例えば監視用のプロセスもストールしてしまった場合、 FANイベントが飛ばないため、FCFでエラーを返すことができません。

CLUSTERPRO MC ApplicationMonitor の機能を使用すると、 SQLがハングしたRACノードを強制終了させることでFANイベントが飛ぶため、 FCFでストールしたノードの障害検知が可能となります。

CLUSTERPRO MC（HAシリーズ）は、Linux/Windows ベースの高可用システムを実現する製品です。 MC ApplicationMonitorは、Oracle DataBaseの障害（停止障害、無応答障害）をインスタンス、リスナレベルで監視するソフトウェアです。 http://www.nec.co.jp/pfsoft/clusterpro/mc_ha/index.html 次のページでは、WebLogic12cの可用性を向上する CLUSTERPRO X3.1監視エージェントをご紹介します。

（参考） (クラスタープロ)

http://www.nec.co.jp/pfsoft/clusterpro/mc_ha/index.html

http://www.nec.co.jp/pfsoft/clusterpro/mc_ha/index.html

CLUSTERPRO 監視オプション製品について

▐ Java Resource Agent アプリケーションサーバにおける安定稼働の実現

▐ System Resource Agent リソース障害の回避による安定稼働の実現

Java VMメモリ領域、GC、デッドロックを監視トラブルを事前に検出

ロードバランサと連携再起動・縮退運転によるレスポンス劣化の改善

Java VMのメモリ領域の情報を継続採取チューニングに活用

予防

安定

稼動

最適化

予防システム全体のリソースを監視

トラブルを事前に検出

原因

究明

プロセス個別のリソース情報を採取

異常時の早期原因究明を支援

最適化負荷状況を「予測」して最適なサーバへの

フェイルオーバを実現

（参考）

(*1) ファイルリーク…ファイルのクローズ漏れ

RACノード追加によるパフォーマンス向上

FCFは障害検知だけでなく、複雑なオペレーションなしにRACノードを追加・削除する利用も可能です。

▐ 動的なRACノード追加

3ノードRAC構成で高負荷(CPU使用率80%前後)をかけた状態で、 4ノード目をサービスに追加し、性能が向上するかどうかを確認しました。

マシン3

DataBase3

マシン4

DataBase4

WLS

マシン1

DataBase1

マシン2

DataBase2

サー

ビス

A

マシン3

DataBase3

マシン4

DataBase4

WLS

マシン1

DataBase1

マシン2

DataBase2

サー

ビス

A

ノード追加

CPU 80%

CPU 80%

CPU 80%

CPU

CPU

CPU

CPU

RACノード追加によるパフォーマンス向上

▐ 結果

ノード追加

レスポンスタイムが改善される。

後から追加したノードへの振り分け割合は他のノードと同程度となっており、上手くロードバランシングされている。

レスポンスタイム(ノード追加時)

オラクル製品とNECの強み

▐ オラクル製品の強み

新規のGridLink機能だけではなく、既存のWebLogicクラスタ機能や別製品のCoherence*Webとの連携も有効性が確認できた。

FM～DB間や製品間で協調した開発がなされている

▐ NECの強み

CLUSTERPROによる、Oracleの機能だけでは検知しきれない障害のカバー

NECではCLUSTERPROとOracleDataBaseの連携検証も以前から実施し、 Oracle製品だけでは手の届かない点を開発・評価してカバーしている。

GridLinkのような製品間の連携機能を有効に利用するには、 WebLogic Serverだけでなく、DataBaseの動作についても知見が必要。

FMの専門部隊とDBの専門部隊が密接に連携できるSIerが重要

（参考）障害発生～再接続までの流れ

▐ インターコネクト障害

CSS(Oracle Clusterwareのプロセス)のハートビートにより障害が検出され、 MISSCOUNT秒でクラスタ関連プロセスが停止・再起動します。

マシン2

DataBase2

マシン3

DataBase3

接続プール

WLS

パブリックネットワークを通じてFANイベントが送られる。 (NODE_DOWN, SERVICE_DOWN, DataBase_DOWN)

インターコネクトに障害発生キャッシュ・フュージョンが発生するselectの処理がブロックされ、 APはRead待ちの状態になる。

1

2

3

4 misscountで検知(デフォルト30秒) ノード間で通信できないDataBase1がクラスタから排除される。

マシン1

DataBase1

L3スイッチ

エラーが返り、 DataBase1への接続がクリーンアップされる。 APからgetConnectionで正常な接続に張替。

インターコネクト障害が発生している状態でも、 DBのローカル・キャッシュを参照する場合はAPはハングせずに結果が返ります。本検証では、まずDataBase2でUpdateを行い、次にインターコネクト障害を発生させ、直後、DataBase1に Selectすることでキャッシュ・フュージョンでのブロックを発生させAPをRead待ちの状態にしています。

AP

Active GridLink for RAC 検証解説 ( @WebLogic Server 12c Forum ) by NEC

Documents

Transcript of Active GridLink for RAC 検証解説 ( @WebLogic Server 12c Forum ) by NEC