Oracle Direct Seminar... Oracle Direct Seminar サポートエンジニアが語る！RAC環境のインスタンスダウンやノードダウンの原因調査と予防

<Insert Picture Here>

Oracle Direct Seminar

サポートエンジニアが語る！RAC環境のインスタンスダウンやノードダウンの原因調査と予防

日本オラクル株式会社データベーステクノロジーサポート本部テクニカルサポートエンジニア永岡正行

Copyright© 2010, Oracle. All rights reserved. 2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

Copyright© 2010, Oracle. All rights reserved.

Real Application Clusters概要

3

Database

InstanceDatabase

Instance

Database

Instance

Oracle Clusterware / Grid Infrastructure

RAC環境は、以下の2つのコンポーネントで構成される

- データベースインスタンス・レベル

- Oracle Clusterware・レベル

RAC環境における可用性の管理は、この2つのコンポーネントで行われている


アジェンダ

4

RAC環境における可用性の管理

インスタンスの可用性管理

ノードの可用性管理

RAC環境における考慮事項

インスタンスやノードがダウンした後の対応

ダウンした後を考慮した設計

Database Instance

Oracle Clusterware








アジェンダ

5

Database Instance

Oracle Clusterware


インスタンス監視の仕組み

6

ckptが制御ファイルへ書込む

lmon同士がネットワーク通信

lmon

ckpt

制御ファイル

lmon

ckpt

Oracle Clusterware Oracle Clusterware

Database Instance Database Instance

生存を監視するハートビート機能

lmon同士がネットワーク通信を介して他インスタンスの生存を確認

ckpt同士が制御ファイルへの書き込みを介して他インスタンスの生存を確認


インスタンス排除の仕組み

7

排除インスタンスのアラートログ

Thu Nov 1 15:19:54 2010

ORA-29740: evicted by member 0, group incarnation 54

Thu Nov 1 15:19:54 2010

LMON: terminating instance due to error 29740 制御ファイル

生存排除

ORA-29740

lmon lmon

ハートビート

プロセスの

ノード間通信インスタンス1 インスタンス2

プロセスプロセス

補足：Clusterware が自動的にインスタンスを再起動

IMR (Instance Membership Recovery) による障害の検出と対処

ハートビートの障害や、プロセスのノード間通信で障害を検知

制御ファイルを用いた投票で、生存インスタンスの確認と排除インスタンスの決定

ORA-29740を出力し、LMONがインスタンスを停止


インスタンス排除の原因調査で有効な情報

8

原因調査で有効な情報が確認できるファイル

アラートログ、 LMONのトレース

生存インスタンスと障害インスタンスを比較し、全体の流れを把握

投票の結果や Reason など、IMRの詳細な状況を確認

IPC Send timeout が発生したプロセスのトレース

通信障害の詳細を確認

OS側ログ（syslog、messages）

ハードウェアやOSなどの障害の有無を確認

採取しておきたい情報

OS負荷、リソース使用状況、プロセスの一覧、ネットワークの統計

sar や vmstat、ps –elf や top、netstat など。OS Watcherの利用も。

ネットワーク障害だけではなく、プロセスハング、OSリソース不足などを確認することができる

ファイルの場所

アラートログ、トレース：(10g) background_dump_dest、user_dump_dest、（11g）<diagnostic_dest>/diag/rdbms/<db_unique_name>/<SID>/trace/

OSログ：/var/adm/syslog、/var/log/


IMRにおける問題点

9

IMRによるインスタンス停止処理が LMONのハングなどが原因で長引くと、インスタンス再構成（※）を開始できず、全インスタンスでSQL処理がハングしてしまう可能性がある。

IMR によるインスタンス排除フェーズまで、最大でおよそ20分間の障害検出時間がある。

インスタンス再構成を開始できない

生存インスタンス排除インスタンス

バッファ

キャッシュ

バッファ

キャッシュ

インスタンス停止が完了しない

※一般的に、RAC環境でインスタンスを停止（正常停止を含む）するとインスタンス再構成（バッファキャッシュの整合性などを再構成する処理）が起動中のインスタンスで実行される。


インスタンスの可用性に関する機能拡張（１）

10

oclskd

kill

プロセスの終了によりインスタンス強制停止

DBインスタンス1

oclskd による可用性の確保 (11gR1)oclskd は Clusterware 側のデーモンoclskd が排除インスタンスのプロセスをkillしてインスタンス強制停止

oclskd ログ : $ORA_CRS_HOME/log/<nodename>/client/oclskd.log

プロセスのkillでも対処できない場合はノード再起動へ

Oracle Clusterware

早く終了して欲しい

DBインスタンス2

[ OCLSKD][3086743232]clsskdKillMembers: Member kill requested. Number of pids: 11[ OCLSKD][3086743232]clsskdKillMembers: kill status 0 pid 15932 [ OCLSKD][3086743232]clsskdKillMembers: kill status 0 pid 15973[ OCLSKD][3086743232]clsskdKillMembers: kill status 0 pid 15989...[ OCLSKD][3086743232]clsskdKillMembers: kill status 0 pid 18309[ OCLSKD][3086743232]clsskdeventhndlr: Kill daemon instructed to exit.

Exiting …

oclskd.log

対象のプロセスをkill


インスタンスの可用性に関する機能拡張（2）

New

Thu Nov 1 12:34:30 2010

Errors in file

/u01/app/oracle/diag/rdbms/sid/sid4/trace/sid4_lmhb_18291.trc (incident=243417):

ORA-29770: global enqueue process LMON (OSID 18272) is hung for more than 70 seconds

Incident details in:

/u01/app/oracle/diag/rdbms/sid/sid4/incident/incdir_243417/sid4_lmhb_18291_i243417.trc

ERROR: Some process(s) is not making progress.

LMHB (ospid: 18291) is terminating the instance.

Please check LMHB trace file for more details.

Please also check the CPU load, I/O load and other system properties for anomalous behavior

ERROR: Some process(s) is not making progress.

LMHB (ospid: 18291): terminating the instance due to error 29770

Thu Nov 1 12:34:43 2010

Instance terminated by LMHB, pid = 18291

Instance

ハング状態

Node

LMS

LMON LMD

LMHB

ハング検知

ORA-29770

Oracle Clusterware

LCK

LMHBプロセスによるインスタンス停止

RAC固有の重要プロセス(LMS LMD LMON LCK)を監視し、より早くハング（インスタンス障害）を検知

ハングを検知するとLMHBプロセスがインスタンスを停止

LMHBがインスタンス停止

LMONハングを検知

11








アジェンダ

12

Database Instance

Oracle Clusterware


Oracle Clusterwareによる監視の仕組み

13

ネットワーク通信のハートビート

投票ディスクのハートビート

CSS

oprocdOS負荷を監視

Oracle Clusterware Oracle Clusterware

CSSの状態を監視

oclsomon

CSS(Cluster Synchronization Services )

メンバーシップを管理

他ノード生存を監視



CSS

oprocd

OS負荷を監視

oclsomon

oclsomon

CSSを監視し、ハングを検知

oprocd

OS負荷を監視し、カーネルレベルのハングを検知

投票ディスク


CSSによる監視

14

設定値を確認するコマンド

$ crsctl get css disktimeout

200

$ crsctl get css misscount

60

ハートビートを通じた監視

投票ディスクのタイムアウト：disktimeout (秒)

ネットワーク通信のタイムアウト：misscount (秒)

ハートビートの監視がタイムアウトすると、ノード排除処理へ進む

CSSのログ

$ORA_CRS_HOME/log/< hostname>/cssd/配下

（10gR1: $ORA_CRS_HOME/css/log/配下）

Clusterwareのアラートログ

$ORA_CRS_HOME/log/<hostname>/alert<hostname>.log

確認した結果（200秒）

確認した結果（60秒）


排除するノードの決定

15

１ 2

3 4

各ノードからノード１への通信が障害

ノード２～４は互いを認識、最大のサブクラスタを形成

→ノード１を排除

ノード１と３、ノード２と４のそれぞれがサブクラスタ

ノード１が最も若い

→ノード２、４を排除

１ 2

3 4

１ 2

相手ノードへの通信に障害

ノード１が最も若い

→ノード2を排除

投票ディスクを通じて、サブクラスタを把握

ノード数が最大のサブクラスタに属するノードが生存、属さないノードが排除

サブクラスタに属するノード数が同じ場合は、ノード番号が若いノードが属するサブクラスタが生存、それ以外が排除

障害

障害

障害


oprocdによるOS負荷監視

16

| INF | monitoring started with timeout(1000), margin(500), skewTimeout(125)

| INF | fatal mode startup, setting process to fatal mode

| ERR | AlarmHandler: timeout(3500) exceeds interval(1000)+margin(500)

| ERR | *** Terminating process in FATAL mode ***

oprocd OS負荷を監視

定期的に自ノードのOSの動作状況を監視

高負荷などでOS処理遅延があると障害として検知

oprocdがノードを再起動

/var/opt/oracle/oprocd 配下または /etc/oracle/oprocd 配下の<nodename>.oprocd.log.<date-time>

処理が遅延して監視がタイムアウトに達している


oclsomonによるCSSの監視

17

ネットワークのハートビート


CSSoclsomon

CSSの状態を監視

CSS

CSS の動作状態を監視

CSS障害を検知するとノードを再起動

$ORA_CRS_HOME/log/<hostname>/cssd/oclsomon/oclsomon.log

2010-11-09 14:44:13.085: clsc_connect: (0x98b3a28) no listener at (ADDRESS=(PROTOCOL=ipc)(KEY=OCSSD_LL_node1_))

Reconfig event. (12/2/2)

clssomon: Timeout waiting for CSS response.

CSSからの応答がなく、監視がタイムアウトに達している


ノード排除の原因調査で有効な情報

18

原因調査で有効な情報が確認できるファイル

ocssd.log、Clusterwareのアラートログ

生存ノードと障害ノードを比較し、全体の流れを把握

ハートビートのエラーや投票の結果など、詳細な状況を確認

oprocd.log、oclsomon.log

CSSのハートビート以外の要因でノード再起動となっているかを確認

OS側ログ（syslog、messages）

ハードウェアやOSなどの障害の有無を確認

採取しておきたい情報

OS負荷、リソース使用状況、プロセスの一覧、ネットワークの統計

sar や vmstat、ps –elf や top、netstat など。 OS Watcherの利用も。

ネットワーク障害だけではなく、プロセスハング、OSリソース不足などを確認することができる

ファイルの場所

Clusterware : $ORA_CRS_HOME/<hostname>/log 配下

oprocd : /var/opt/oracle/oprocd 配下または /etc/oracle/oprocd 配下

OSログ : /var/adm/syslog、/var/log/


ノード再起動が発生した場合の調査手順

１．いつ、どのノードで何が発生し、どのノードが排除されたのかを調べる

messagesなどOSログ、ocssd.log

記録が途切れた箇所、OSやCSSが起動を開始した記録を探す

２．どのプロセスが排除処理を行ったのかを調べる

ocssd.log、oprocd.log、oclskd.log、oclsomon.log

※注意

あるノードが突然OS停止のとき、他のノードでは通信ハートビートのエラーが検知され、ocssd.logに記録される。

Eviction startedも記録される。CSSが管理するメンバーシップ情報の更新。

OS停止のほうが先か、OS側ログやocssd.logの記録のタイムスタンプ等から判断する。

３．必要に応じ、負荷やリソース使用状況、ネットワークや投票ディスクの状況を調べる

CPUやメモリ使用、RUNキュー、ページイン/アウト、など

NIC、スイッチ、ストレージ装置、ストレージへのパス、など

19


インスタンス/ノードの再起動のまとめ

• データ保護のためインスタンスやノードを再起動させる（排除）

• インスタンス

• 監視：LMONはネットワーク通信、CKPTは制御ファイル

• ORA-29740

• ノード

• CSSによる監視：投票ディスク、ネットワーク通信

• oprocd による監視：OS負荷

• oclsomon による監視：CSSの障害

• 調査方法

• いつ、どのプロセスで障害があって、だれがダウンさせたのかを把握

20








アジェンダ

21

Database Instance

Oracle Clusterware


排除後の対応と注意

22

排除後を想定した処理能力を用意

運用開始後も負荷状況の変化を把握

接続要求や処理要求が生存インスタンスへ集まる

CPUやメモリを要する

排除直後は短時間に集中する

生存ノードが高負荷になる

DBインスタンスへのセッションが切断されている

再接続が必要

FCF、TAFを設定

アプリ側で再接続を実装

被害拡大の可能性を最小化するためには

排除後に再接続するよう設定

排除後、生存ノードでの負荷・処理能力を確認


生存ノードの負荷に関して設計や考え方のヒント

23

余裕のある設計・運用を心がけてください

100

１つのノードの最大処理能力を100とし、

ノード数減少後に各ノードが100の処理を行うことになったと想定

ノード数減少

正常時は各ノードで66の要求まで処理

正常時再構成後

ノード数減少

正常時は各ノードで50の要求まで処理

100

1005050

66 66 66


まとめ

監視と排除の仕組み

• データ保護のため

• 監視・排除の仕組み

ダウン後の対応と注意

• ダウン後の対応も考慮することが必要

• 生存インスタンスでの負荷に備えてリソースの用意

• 余裕のある設計とテストを行うことが必要

24


参照資料

25

KROWN:55682 Real Application Clustersにおける、Instance Membership Recoveryについて

KROWN:56123 RAC 環境における ORA-29740のトラブルシューティングガイド

NOTE:219361.1 Troubleshooting ORA-29740 in a RAC Environment

KROWN:91896 10g RAC : CSS による投票ディスクへの I/O タイムアウトについて

KROWN:108257 10gR2 RAC : CSS による投票ディスクへの I/O タイムアウトについて (10.2.0)

KROWN:140599 11gRAC : CSS による投票ディスクへの I/O タイムアウトについて (11g)

KROWN:126323 10gR2 RAC : 10.2.0.3 以降の diskLongTimeout について

KROWN:100830 10g RAC : 10.1.0.3 からの CSS タイムアウト算出および CSS MISSCOUNT の変更方法

KROWN:93150 10g RAC : Cluster Synchronization Services (CSS) の MISSCOUNT の意味について

KROWN:129170 Oracle Database 11g 以降のトレースファイルの出力ディレクトリについて

KROWN:133097 [ADR] 自動診断レポジトリと rdbms, listener, clients 配下のファイルについて

KROWN:140563 OS Watcher (OSW) を使用してオペレーティング・システムに関する情報を取得する方法

Copyright© 2010, Oracle. All rights reserved.26

OTN×ダイセミでスキルアップ!!

※OTN掲示版は、基本的にOracleユーザー有志からの回答となるため100%回答があるとは限りません。ただ、過去の履歴を見ると、質問の大多数に関してなんらかの回答が書き込まれております。

Oracle Technology Network(OTN)を御活用下さい。

・一般的な技術問題解決方法などを知りたい！・セミナ資料など技術コンテンツがほしい！

一般的技術問題解決にはOTN掲示版の

「データベース一般」をご活用ください

http://forums.oracle.com/forums/main.jspa?categoryID=484

過去のセミナ資料、動画コンテンツはOTNの

「OTNセミナーオンデマンドコンテンツ」へ

http://www.oracle.com/technetwork/jp/testcontent/index-086873-ja.html

※ダイセミ事務局にダイセミ資料を請求頂いても、お受けできない可能性がございますので予めご了承ください。ダイセミ資料はOTNコンテンツオンデマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。

DB

以外の任意の掲示板


OTNセミナーオンデマンドコンテンツダイセミで実施された技術コンテンツを動画で配信中!!

ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。

※掲載のコンテンツ内容は予告なく変更になる可能性があります。期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。

OTN オンデマンド

最新情報つぶやき中

oracletechnetjp

・人気コンテンツは？

・お勧め情報

・公開予告など


Oracle エンジニアのための技術情報サイト

オラクルエンジニア通信http://blogs.oracle.com/oracle4engineer/

• 技術資料

• ダイセミの過去資料や製品ホワイトペーパー、スキルアップ資料などを多様な方法で検索できます

• キーワード検索、レベル別、カテゴリ別、製品・機能別

• コラム

• オラクル製品に関する技術コラムを毎週お届けします

• 決してニッチではなく、誰もが明日から使える技術の「あ、そうだったんだ！」をお届けします

こんな資料が人気です

6か月ぶりに資料ダウンロードランキングの首位が交代！新王者はOracle Database構築資料でした。

データベースの性能管理手法について、Statspack派もEnterprise Manager派も目からウロコの技術特集公開中

オラクルエンジニア通信

最新情報つぶやき中

oracletechnetjp

http://blogs.oracle.com/oracle4engineer/


■パフォーマンス診断サービス

•Webシステムボトルネック診断サービス

•データベースパフォーマンス診断サービス

オラクル社のエンジニアが直接ご支援しますお気軽にご活用ください!

オラクル無償支援検索

NEW

■システム構成診断サービス

•Oracle Database構成相談サービス

•サーバー統合支援サービス

•仮想化アセスメントサービス

•メインフレーム資産活用相談サービス

•BI EEアセスメントサービス

•簡易業務診断サービス

■バージョンアップ支援サービス

•Oracle Databaseバージョンアップ支援サービス

•Weblogic Serverバージョンアップ支援サービス

•Oracle Developer/2000(Froms/Reports)

Webアップグレード相談サービス

■移行支援サービス

•SQL Serverからの移行支援サービス

•DB2からの移行支援サービス

•Sybaseからの移行支援サービス

•MySQLからの移行支援サービス

•Postgre SQLからの移行支援サービス

•Accessからの移行支援サービス

•Oracle Application ServerからWeblogicへ移行支援サービス

ITプロジェクト全般に渡る無償支援サービス

Oracle Direct Conciergeサービス

NEW

NEW


インストールすることなく、すぐに体験いただけます

製品無償評価サービス

http://www.oracle.com/jp/direct/services/didemo-195748-ja.html

Web問い合わせフォーム「ダイデモ」をキーワードに検索することで申し込みホームページにアクセスできます

提供シナリオ一例

・データベースチューニング

・アプリケーション性能・負荷検証

・無停止アップグレード

・Webシステム障害解析

1日5組限定！

※サービスご提供には事前予約が必要です

サービスご提供までの流れ

1. お問合せフォームより「製品評価サービス希望」と必要事項を明記し送信下さい

2. 弊社より接続方法手順書およびハンズオン手順書を送付致します

3. 当日は、弊社サーバー環境でインターネット越しに製品を体感頂けます







http://www.oracle.com/jp/direct/inquiry-form-182185-ja.html

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せください

Web問い合わせフォームフリーダイヤル

専用お問い合わせフォームにてご相談内容を承ります。

※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。

0120－155－096

※月曜~金曜 9:00~12:00、13:00~18:00

（祝日および年末年始除く）

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。

必ず挿入してください


Appendix


*** 2010-11-01 15:08:08.786

kjxgrgetresults: Detect reconfig from 0, seq 53, reason 3

kjxgrrcfgchk: Initiating reconfig, reason 3

*** 2010-11-01 15:08:08.786

kjxgmrcfg: Reconfiguration started, reason 3

*** 2010-11-01 15:19:49.280

Voting results, upd 0, seq 54, bitmap: 0

*** 2010-11-01 15:19:49.280

kjxgrdtrt: Evicted by 0, seq (54, 54

排除の状況を調査するポイント – lmonのトレース

33

*** 2010-11-01 15:08:01.076

kjxgrrcfgchk: Initiating reconfig, reason 3

*** 2010-11-01 15:08:01.198

kjxgmrcfg: Reconfiguration started, reason 3

*** 2010-11-01 15:19:49.228

Voting results, upd 0, seq 54, bitmap: 0

Evicting mem 1, stat 0x0007 err 0x0002

インスタンス１（生存）インスタンス２（排除）

キーワード：Reason

Reason は IMR が行われた理由を示す（次頁参照）

時系列に基づいて、各インスタンスにおける処理の流れを把握

理由

理由

インスタンス１がIMRを開始

投票の結果、インスタンス１が生存

インスタンス１に排除された

投票の結果、インスタンス１が生存インスタンス２を排除


Reasonの意味

34

I/O障害、ネットワーク障害

ネットワーク障害

プロセスのスピン、ハング

ノード高負荷によるOSハング、OSリソース不足

クラスタウェアが障害を検知し、ノードを排除した場合

Reason 2:インスタンスダウンの検知による再構成

例他インスタンスの監視で、制御ファイルから生存を確認できなくなった

Reason 1:ノードモニター（クラスタのレイヤ）からの通知

例クラスタウェアがノードを排除したためインスタンスも排除された

Reason 3:ノード間通信での障害による再構成

例 LMON によるハートビートが途絶えた

例フォアグラウンド、バックグラウンドプロセスの通信に障害


投票ディスクのハートビート障害

35

WARNING: clssnmvDiskCheck: voting device hang at 50% fatal, termination in 99370 ms, disk (0//voting/1106_voting1)




...



TRACE: clssnmvDiskCheck: stale disk (200020 ms) (2//voting/1106_voting3)

TRACE: clssnmvDiskCheck: stale disk (200010 ms) (0//voting/1106_voting1)

ERROR: clssnmDiskPMT: Aborting, 2 of 3 voting disks unavailable

ERROR: ###################################

ERROR: clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread

ERROR: ###################################

障害を検知したノードの ocssd.log に記録

過半数の投票ディスクへのハートビート障害が発生するとCSSが終了し、ノード再起動


例：投票ディスクが3つある環境

２つの投票ディスクのハートビ

ートの失敗

3つの投票ディスクのうち2つが利用不可


ネットワーク通信のハートビート障害

36

WARNING: clssnmPollingThread: node node2 (2) at 50% heartbeat fatal, eviction in 14.236 seconds




…

TRACE: clssnmPollingThread: Eviction started for node node2 (2), flags 0x000d, state 3, wt4c 0

補足：10.2.0.2まで

WARNING: clssnmPollingThread: node(2) missed(4) checkin(s)



...


…

TRACE: clssnmPollingThread: Eviction started for node node2 (2), flags 0x000d, state 3, wt4c 0

ハートビート障害を検知したノードの ocssd.log に記録

タイムアウトすると排除ノード決定処理へ進む（即排除ではない）

ハートビート障害を検知した秒数がmisscount の何%かを記録


misscount:30秒

排除ノード決定処理に進む

排除ノード決定処理に進む

排除ノード決定処理まで約14秒

ハートビート障害がmisscountの50%続いた

ハートビート障害が29秒続いた


排除されるノードにおけるログ出力例

37

ERROR: clssnmCheckDskInfo: Aborting local node to avoid splitbrain.

…

ERROR: ###################################

ERROR: clssscExit: CSSD aborting

ERROR: ###################################

補足：正常停止時のログ

WARNING: clssgmClientShutdown: graceful shutdown completed.

USER: Copyright 2010, Oracle version 11.1.0.7.0

USER: CSS daemon log for node node1, number 1, in cluster ddd2010

TRACE: clssgmHandleDataInvalid: grock HB+ASM, member 1 node 1, birth 1

TRACE: clssgmDispatchCMXMSG: msg type(3) src(4) dest(3) size(420) tag(07b90036) incarnation(168309989)

TRACE: clssgmHandleMasterAdd(): src(3) dest(3) size(420)

USER: Copyright 2010, Oracle version 11.1.0.7.0

USER: CSS daemon log for node node1, number 1, in cluster ddd2010

投票ディスクから投票結果を確認

排除が決定したノードのCSSが終了し、ノード再起動へ

CSS終了のログが残らない場合がある

CSSのshutdown(停止)が正常に完了した

ノード１に排除されていることを投票結果から把握している

shutdownの記録がなく、突然起動している

CSSが起動を開始


調査の例１ノード間通信の障害

38

高負荷

ノード1 ocssd.logでは、 11/9 12:01:15 ごろからネットワークのハートビートのエラーを記録

[ CSSD]2010-11-09 12:01:15.861 [18] >WARNING: clssnmPollingThread: node node2 (2) at 50% heartbeat fatal, eviction in 14.236 seconds



…

[ CSSD]2010-11-09 12:01:30.097 [18] > TRACE: clssnmPollingThread: Eviction started for node node2 (2), flags 0x000d, state 3, wt4c 0

…

[ CSSD]2010-11-09 12:01:30.615 [18] >TRACE: clssnmReadDskHeartbeat: node 2, node2, has a disk HB, but no network HB, DHB has rcfg 91536673, 30 wrtcnt, 12233830, LATS 250279884, lastSeqNo 12233830, timestamp 1236578848/4294395390

ノード2 ocssd.logでも 11/9 12:01:15 ごろからハートビートのエラーを記録、最終的にabortしている




…


…

[ CSSD]2010-11-09 12:01:30.088 [18] > ERROR: clssnmCheckDskInfo: Aborting local node to avoid splitbrain.

…

[ CSSD]2010-11-09 12:01:30.088 [18] > ERROR: ###################################

[ CSSD]2010-11-09 12:01:30.088 [18] > ERROR: clssscExit: CSSD aborting

[ CSSD]2010-11-09 12:01:30.088 [18] > ERROR: ###################################

１．いつ、どのノードで何が発生し、どのノードが排除されたか

misscount:30秒、2ノードRAC


調査の例１ノード間通信の障害

39

ノード間のネットワーク通信で用いているスイッチが故障していた

ノード2 ocssd.log より、ノード１から排除されている。CSSによる排除。

[ CSSD]2010-11-09 12:01:30.088 [18] > ERROR: clssnmCheckDskInfo: Aborting local node to avoid splitbrain.

２．どのプロセスが排除したのか

3．ネットワークの状況

総合的に考え、ノード間ネットワーク通信の障害


調査の例２ OS高負荷でoprocdが障害を検知

40

ノード1 ocssd.logでは、 11/9 12:01:15 ごろからハートビートのエラーを記録




…


ノード2 ocssd.log では、11/9 12:02:00 ごろ、突然、CSS起動の記録がはじまっていた

[ CSSD]2010-11-09 12:00:50.000 >TRACE: clssgmExecuteClientRequest: GRKEXIT recvd from client 1567

[ CSSD]2010-11-09 12:02:00.000 >USER: Copyright 2010, Oracle version 11.1.0.7.0

１．いつ、どのノードで何が発生し、どのノードが排除されたか

？

Node#1 Node#2


調査の例２ OS高負荷でoprocdが障害を検知

41

高負荷

ノード2の各種ログを調査したところ oprocd.log に以下の記録

Nov 09 12:01:00.000| ERR | AlarmHandler: timeout(3500) exceeds interval(1000)+margin(500)

Nov 09 12:01:00.000| ERR | *** Terminating process in FATAL mode ***

ノード再起動したノードの sar などを見ると、負荷が高い

負荷の情報採取のスケジュールが遅れている（例：12:00:00の予定が12:01:30に採取されていた）

CPUのアイドルが数％しかない状態が続いていた、RUNキューが多い、ページイン・アウトが多い

0

100もしも負荷・リソース使用の情報採取が無かった場合、ログからはoprocdが再起動を発生させ、負荷が高かった状況である可能性の推測までは可能。どのような負荷が高かったことまでは言及が難しい（裏付けられない）。

負荷の情報があると高負荷の状況の詳細まで調査・判断できる。

２．どのプロセスが排除したのか

3．負荷の状況

総合的に考え、高負荷が原因で oprocd が排除したと考えられる


Copyright© 2010, Oracle. All rights reserved. 43

Documents

Oracle Direct Seminar... Oracle Direct Seminar サポートエンジニアが語る！RAC環境のインスタンスダウンやノードダウンの 原因調査と予防

Oracle Direct Seminar... Oracle Direct Seminar サポートエンジニアが語る！RAC環境のインスタンスダウンやノードダウンの原因調査と予防