oracle direct seminar... oracle direct seminar...
TRANSCRIPT
<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つのコンポーネントで行われている
Copyright© 2010, Oracle. All rights reserved.
アジェンダ
4
RAC環境における可用性の管理
インスタンスの可用性管理
ノードの可用性管理
RAC環境における考慮事項
インスタンスやノードがダウンした後の対応
ダウンした後を考慮した設計
Database Instance
Oracle Clusterware
Copyright© 2010, Oracle. All rights reserved.
RAC環境における可用性の管理
インスタンスの可用性管理
ノードの可用性管理
RAC環境における考慮事項
インスタンスやノードがダウンした後の対応
ダウンした後を考慮した設計
アジェンダ
5
Database Instance
Oracle Clusterware
Copyright© 2010, Oracle. All rights reserved.
インスタンス監視の仕組み
6
ckptが制御ファイルへ書込む
lmon同士がネットワーク通信
lmon
ckpt
制御ファイル
lmon
ckpt
Oracle Clusterware Oracle Clusterware
Database Instance Database Instance
生存を監視するハートビート機能
lmon同士がネットワーク通信を介して他インスタンスの生存を確認
ckpt同士が制御ファイルへの書き込みを介して他インスタンスの生存を確認
Copyright© 2010, Oracle. All rights reserved.
インスタンス排除の仕組み
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がインスタンスを停止
Copyright© 2010, Oracle. All rights reserved.
インスタンス排除の原因調査で有効な情報
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/
Copyright© 2010, Oracle. All rights reserved.
IMRにおける問題点
9
IMRによるインスタンス停止処理が LMONのハングなどが原因で長引くと、インスタンス再構成(※)を開始できず、全インスタンスでSQL処理がハングしてしまう可能性がある。
IMR によるインスタンス排除フェーズまで、最大でおよそ20分間の障害検出時間がある。
インスタンス再構成を開始できない
生存インスタンス 排除インスタンス
バッファ
キャッシュ
バッファ
キャッシュ
インスタンス停止が完了しない
※一般的に、RAC環境でインスタンスを停止(正常停止を含む)するとインスタンス再構成(バッファキャッシュの整合性などを再構成する処理)が起動中のインスタンスで実行される。
Copyright© 2010, Oracle. All rights reserved.
インスタンスの可用性に関する機能拡張(1)
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
Copyright© 2010, Oracle. All rights reserved.
インスタンスの可用性に関する機能拡張(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
Copyright© 2010, Oracle. All rights reserved.
RAC環境における可用性の管理
インスタンスの可用性管理
ノードの可用性管理
RAC環境における考慮事項
インスタンスやノードがダウンした後の対応
ダウンした後を考慮した設計
アジェンダ
12
Database Instance
Oracle Clusterware
Copyright© 2010, Oracle. All rights reserved.
Oracle Clusterwareによる監視の仕組み
13
ネットワーク通信のハートビート
投票ディスクのハートビート
CSS
oprocdOS負荷を監視
Oracle Clusterware Oracle Clusterware
CSSの状態を監視
oclsomon
CSS(Cluster Synchronization Services )
メンバーシップを管理
他ノード生存を監視
投票ディスクのハートビート
ネットワーク通信のハートビート
CSS
oprocd
OS負荷を監視
oclsomon
oclsomon
CSSを監視し、ハングを検知
oprocd
OS負荷を監視し、カーネルレベルのハングを検知
投票ディスク
Copyright© 2010, Oracle. All rights reserved.
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秒)
Copyright© 2010, Oracle. All rights reserved.
排除するノードの決定
15
1 2
3 4
各ノードからノード1への通信が障害
ノード2~4は互いを認識、最大のサブクラスタを形成
→ノード1を排除
ノード1と3、ノード2と4のそれぞれがサブクラスタ
ノード1が最も若い
→ノード2、4を排除
1 2
3 4
1 2
相手ノードへの通信に障害
ノード1が最も若い
→ノード2を排除
投票ディスクを通じて、サブクラスタを把握
ノード数が最大のサブクラスタに属するノードが生存、属さないノードが排除
サブクラスタに属するノード数が同じ場合は、ノード番号が若いノードが属するサブクラスタが生存、それ以外が排除
障害
障害
障害
Copyright© 2010, Oracle. All rights reserved.
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>
処理が遅延して監視がタイムアウトに達している
Copyright© 2010, Oracle. All rights reserved.
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からの応答がなく、監視がタイムアウトに達している
Copyright© 2010, Oracle. All rights reserved.
ノード排除の原因調査で有効な情報
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/
Copyright© 2010, Oracle. All rights reserved.
ノード再起動が発生した場合の調査手順
1.いつ、どのノードで何が発生し、どのノードが排除されたのかを調べる
messagesなどOSログ、ocssd.log
記録が途切れた箇所、OSやCSSが起動を開始した記録を探す
2.どのプロセスが排除処理を行ったのかを調べる
ocssd.log、oprocd.log、oclskd.log、oclsomon.log
※注意
あるノードが突然OS停止のとき、他のノードでは通信ハートビートのエラーが検知され、ocssd.logに記録される。
Eviction startedも記録される。CSSが管理するメンバーシップ情報の更新。
OS停止のほうが先か、OS側ログやocssd.logの記録のタイムスタンプ等から判断する。
3.必要に応じ、負荷やリソース使用状況、ネットワークや投票ディスクの状況を調べる
CPUやメモリ使用、RUNキュー、ページイン/アウト、など
NIC、スイッチ、ストレージ装置、ストレージへのパス、など
19
Copyright© 2010, Oracle. All rights reserved.
インスタンス/ノードの再起動のまとめ
• データ保護のためインスタンスやノードを再起動させる(排除)
• インスタンス
• 監視:LMONはネットワーク通信、CKPTは制御ファイル
• ORA-29740
• ノード
• CSSによる監視:投票ディスク、ネットワーク通信
• oprocd による監視:OS負荷
• oclsomon による監視:CSSの障害
• 調査方法
• いつ、どのプロセスで障害があって、だれがダウンさせたのかを把握
20
Copyright© 2010, Oracle. All rights reserved.
RAC環境における可用性の管理
インスタンスの可用性管理
ノードの可用性管理
RAC環境における考慮事項
インスタンスやノードがダウンした後の対応
ダウンした後を考慮した設計
アジェンダ
21
Database Instance
Oracle Clusterware
Copyright© 2010, Oracle. All rights reserved.
排除後の対応と注意
22
排除後を想定した処理能力を用意
運用開始後も負荷状況の変化を把握
接続要求や処理要求が生存インスタンスへ集まる
CPUやメモリを要する
排除直後は短時間に集中する
生存ノードが高負荷になる
DBインスタンスへのセッションが切断されている
再接続が必要
FCF、TAFを設定
アプリ側で再接続を実装
被害拡大の可能性を最小化するためには
排除後に再接続するよう設定
排除後、生存ノードでの負荷・処理能力を確認
Copyright© 2010, Oracle. All rights reserved.
生存ノードの負荷に関して設計や考え方のヒント
23
余裕のある設計・運用を心がけてください
100
1つのノードの最大処理能力を100とし、
ノード数減少後に各ノードが100の処理を行うことになったと想定
ノード数減少
正常時は各ノードで66の要求まで処理
正常時 再構成後
ノード数減少
正常時は各ノードで50の要求まで処理
100
1005050
66 66 66
Copyright© 2010, Oracle. All rights reserved.
まとめ
監視と排除の仕組み
• データ保護のため
• 監視・排除の仕組み
ダウン後の対応と注意
• ダウン後の対応も考慮することが必要
• 生存インスタンスでの負荷に備えてリソースの用意
• 余裕のある設計とテストを行うことが必要
24
Copyright© 2010, Oracle. All rights reserved.
参照資料
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
以外の任意の掲示板
Copyright© 2010, Oracle. All rights reserved.27
OTNセミナー オンデマンド コンテンツダイセミで実施された技術コンテンツを動画で配信中!!
ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。
※掲載のコンテンツ内容は予告なく変更になる可能性があります。期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。
OTN オンデマンド
最新情報つぶやき中
oracletechnetjp
・人気コンテンツは?
・お勧め情報
・公開予告 など
Copyright© 2010, Oracle. All rights reserved.28
Oracle エンジニアのための技術情報サイト
オラクルエンジニア通信http://blogs.oracle.com/oracle4engineer/
• 技術資料
• ダイセミの過去資料や製品ホワイトペーパー、スキルアップ資料などを多様な方法で検索できます
• キーワード検索、レベル別、カテゴリ別、製品・機能別
• コラム
• オラクル製品に関する技術コラムを毎週お届けします
• 決してニッチではなく、誰もが明日から使える技術の「あ、そうだったんだ!」をお届けします
こんな資料が人気です
6か月ぶりに資料ダウンロードランキングの首位が交代!新王者はOracle Database構築資料でした。
データベースの性能管理手法について、Statspack派もEnterprise Manager派も目からウロコの技術特集公開中
オラクルエンジニア通信
最新情報つぶやき中
oracletechnetjp
Copyright© 2010, Oracle. All rights reserved.29
■パフォーマンス診断サービス
•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
Copyright© 2010, Oracle. All rights reserved.30
インストールすることなく、すぐに体験いただけます
製品無償評価サービス
http://www.oracle.com/jp/direct/services/didemo-195748-ja.html
Web問い合わせフォーム「ダイデモ」をキーワードに検索することで申し込みホームページにアクセスできます
提供シナリオ一例
・データベースチューニング
・アプリケーション性能・負荷検証
・無停止アップグレード
・Webシステム障害解析
1日5組限定!
※サービスご提供には事前予約が必要です
サービスご提供までの流れ
1. お問合せフォームより「製品評価サービス希望」と必要事項を明記し送信下さい
2. 弊社より接続方法手順書およびハンズオン手順書を送付致します
3. 当日は、弊社サーバー環境でインターネット越しに製品を体感頂けます
Copyright© 2010, Oracle. All rights reserved.31
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プロジェクト全般の相談窓口としてご支援いたします。
システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。
必ず挿入してください
Copyright© 2010, Oracle. All rights reserved.
Appendix
Copyright© 2010, Oracle. All rights reserved.
*** 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
インスタンス1(生存) インスタンス2(排除)
キーワード:Reason
Reason は IMR が行われた理由を示す(次頁参照)
時系列に基づいて、各インスタンスにおける処理の流れを把握
理由
理由
インスタンス1がIMRを開始
投票の結果、インスタンス1が生存
インスタンス1に排除された
投票の結果、インスタンス1が生存インスタンス2を排除
Copyright© 2010, Oracle. All rights reserved.
Reasonの意味
34
I/O障害、ネットワーク障害
ネットワーク障害
プロセスのスピン、ハング
ノード高負荷によるOSハング、OSリソース不足
クラスタウェアが障害を検知し、ノードを排除した場合
Reason 2:インスタンスダウンの検知による再構成
例 他インスタンスの監視で、制御ファイルから生存を確認できなくなった
Reason 1:ノードモニター(クラスタのレイヤ)からの通知
例 クラスタウェアがノードを排除したためインスタンスも排除された
Reason 3:ノード間通信での障害による再構成
例 LMON によるハートビートが途絶えた
例 フォアグラウンド、バックグラウンドプロセスの通信に障害
Copyright© 2010, Oracle. All rights reserved.
投票ディスクのハートビート障害
35
WARNING: clssnmvDiskCheck: voting device hang at 50% fatal, termination in 99370 ms, disk (0//voting/1106_voting1)
WARNING: clssnmvDiskCheck: voting device hang at 50% fatal, termination in 99330 ms, disk (2//voting/1106_voting3)
WARNING: clssnmvDiskCheck: voting device hang at 75% fatal, termination in 49280 ms, disk (0//voting/1106_voting1)
WARNING: clssnmvDiskCheck: voting device hang at 75% fatal, termination in 49240 ms, disk (2//voting/1106_voting3)
...
WARNING: clssnmvDiskCheck: voting device hang at 90% fatal, termination in 150 ms, disk (2//voting/1106_voting3)
WARNING: clssnmvDiskCheck: voting device hang at 90% fatal, termination in 20 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つある環境
2つの投票ディスクのハートビ
ートの失敗
3つの投票ディスクのうち2つが利用不可
Copyright© 2010, Oracle. All rights reserved.
ネットワーク通信のハートビート障害
36
WARNING: clssnmPollingThread: node node2 (2) at 50% heartbeat fatal, eviction in 14.236 seconds
WARNING: clssnmPollingThread: node node2 (2) at 75% heartbeat fatal, eviction in 7.236 seconds
WARNING: clssnmPollingThread: node node2 (2) at 90% heartbeat fatal, eviction in 2.236 seconds
WARNING: clssnmPollingThread: node node2 (2) at 90% heartbeat fatal, eviction in 0.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)
WARNING: clssnmPollingThread: node(2) missed(5) checkin(s)
WARNING: clssnmPollingThread: node(2) missed(6) checkin(s)
...
WARNING: clssnmPollingThread: node(2) missed(29) 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秒続いた
Copyright© 2010, Oracle. All rights reserved.
排除されるノードにおけるログ出力例
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(停止)が正常に完了した
ノード1に排除されていることを投票結果から把握している
shutdownの記録がなく、突然起動している
CSSが起動を開始
Copyright© 2010, Oracle. All rights reserved.
調査の例1 ノード間通信の障害
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:22.861 [18] >WARNING: clssnmPollingThread: node node2 (2) at 75% heartbeat fatal, eviction in 7.236 seconds
[ CSSD]2010-11-09 12:01:29.861 [18] >WARNING: clssnmPollingThread: node node2 (2) at 90% heartbeat fatal, eviction in 0.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:15.731 [18] >WARNING: clssnmPollingThread: node node1 (1) at 50% heartbeat fatal, eviction in 14.236 seconds
[ CSSD]2010-11-09 12:01:22.731 [18] >WARNING: clssnmPollingThread: node node1 (1) at 75% heartbeat fatal, eviction in 7.236 seconds
[ CSSD]2010-11-09 12:01:29.731 [18] >WARNING: clssnmPollingThread: node node1 (1) at 90% heartbeat fatal, eviction in 0.236 seconds
…
[ CSSD]2010-11-09 12:01:29.967 [18] > TRACE: clssnmPollingThread: Eviction started for node node1 (1), flags 0x000d, state 3, wt4c 0
…
[ 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: ###################################
1.いつ、どのノードで何が発生し、どのノードが排除されたか
misscount:30秒、2ノードRAC
Copyright© 2010, Oracle. All rights reserved.
調査の例1 ノード間通信の障害
39
ノード間のネットワーク通信で用いているスイッチが故障していた
ノード2 ocssd.log より、ノード1から排除されている。CSSによる排除。
[ CSSD]2010-11-09 12:01:30.088 [18] > ERROR: clssnmCheckDskInfo: Aborting local node to avoid splitbrain.
2.どのプロセスが排除したのか
3.ネットワークの状況
総合的に考え、ノード間ネットワーク通信の障害
Copyright© 2010, Oracle. All rights reserved.
調査の例2 OS高負荷でoprocdが障害を検知
40
ノード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:22.861 [18] >WARNING: clssnmPollingThread: node node2 (2) at 75% heartbeat fatal, eviction in 7.236 seconds
[ CSSD]2010-11-09 12:01:29.861 [18] >WARNING: clssnmPollingThread: node node2 (2) at 90% heartbeat fatal, eviction in 0.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
ノード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
1.いつ、どのノードで何が発生し、どのノードが排除されたか
?
Node#1 Node#2
Copyright© 2010, Oracle. All rights reserved.
調査の例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が再起動を発生させ、負荷が高かった状況である可能性の推測までは可能。どのような負荷が高かったことまでは言及が難しい(裏付けられない)。
負荷の情報があると高負荷の状況の詳細まで調査・判断できる。
2.どのプロセスが排除したのか
3.負荷の状況
総合的に考え、高負荷が原因で oprocd が排除したと考えられる
Copyright© 2010, Oracle. All rights reserved.
Copyright© 2010, Oracle. All rights reserved. 43