謎のOracleトラブルに挑む（後編）
− 事例に見るトラブルシューティング技法 −
松本 庄司
株式会社サンブリッジテクノロジーズ
2001/11/17
障害原因の本格的な切り分け
何とか障害を再現できたので、問題の切り分けに入れます。まず、現状のテスト環境と対象となる本番環境を比べてみます。
|
本番サイト
|
テストサイト
|
|
| アプリ | クライアント企業サイト | 弊社モジュールによるダミーアプリ |
| アプリサーバ | ColdFusion | JRun |
| アプリサーバOS | Windows NT 4.0 | Windows NT 4.0 |
| DB | Oracle 8.1.6 | Oracle 8.1.6 |
| DBサーバOS | Red Hat Linux 6.2 | Red Hat Linux 6.2 |
| DBサーバカーネル | 2.2.19-6.2.1smp | 2.2.19-6.2.1smp |
| DBサーバSCSI | Adaptec 2940U2W | Adaptec 2940W |
これを見ると分かるように、アプリケーションサーバサイドの問題である可能性は非常に低くなります。弊社モジュールによるダミーアプリは内製で、イリーガルなオペレーションがないことは保証できるからです。というわけで、やはりOracleかOS／カーネルの問題であろうと考えられます（こうなることを予想して見切りテストを始めたという面もありますが）。また、ハードウェア障害でもないでしょう。
ここで、最初の手掛かりである「Interrupted System Call」に立ち戻って、次の切り分けポイントを以下のように絞り込みました。
- Oracle 8.1.6
- カーネル
SCSI関連ドライバ
ファイルシステム関連
シグナルハンドラ関連
メモリマネジメント関連そのほか
カーネル回りでいろいろ挙がっているのは、2.2.18から2.2.19へのバージョンアップ時の変更点が多いからです。2.2.18までは純粋に2.2系なのですが、2.2.19は2.4系からのバックポートパッチが含まれており、2.2系と2.4系の要素を持つという特殊な状態にありました。Oracle自体はそうそう簡単に変えられるものではないので、主にカーネルに絞って切り分けることにしました。
■SCSI関連の切り分け
本番とテスト環境ではSCSIホストアダプタが若干違います（残念ながら同じものは準備できませんでした）。ただし、使用するドライバは同じです。2940系といえばかなり昔からあるメジャーなカードなのでドライバも枯れているだろうと思ったのですが、ドライバの変更履歴を見るとまだアップデートが続いているようなので、ドライバの問題も考えられます。
ほかのカードとドライバを使ってテストする方法もありますが、もう少し大きく切り分け範囲を取って、IDEを使ってみることにしました。さすがに、IDE回りのドライバに大きな不具合が残っているとは思えません。実のところ、この時点ではSCSIドライバが最も怪しいと考えていたので、IDEを使えば不具合は出ないだろうと思っていました。ドライバの独立性は比較的高いので、仮にSCSIドライバの問題だとすればほかのバージョンのカーネルを使うなどのテストもしやすく、問題の回避方法も手軽になります。
しかし、SCSIからIDEに変更したテストではたった1日で障害が出てしまいました。これは結構大ごとです。IDEでも起こるとなれば、ファイルシステム、メモリマネジメント、シグナルハンドリング、スケジューリングなど非常に影響の大きな部分に不具合があることになり、切り分けが難しくなるからです。
■原因はカーネルそのものか？
こうなると、どこから手を付けたものか考え込んでしまいます。とにかくどのバージョンのカーネルから障害が発生するのかを探し出し、発生し始めたバージョンへの差分から原因を特定せねばなりません。
ここにきて出てきた情報が、「Red Hat Linux 6.2のupdatesを適用する前、すなわちRed Hat製のカーネル2.2.16で運用していた6カ月間は同じ障害は発生しなかった」です。正直なところ、これが分かっていれば真っ先にテストしたのですが……。とはいえ、「障害が発生しない」ことを証明するには時間がかかります。いままでの経緯からいって、最低でも3日、欲をいえば10日程度は様子を見る必要があることが分かっています。Red Hat製の2.2.16では障害が発生しないことが分かっただけでもよしとしましょう。
そこで、Red Hat製のカーネル2.2.16および2.2.17を使って同様のテストを行いました。Red Hatのサイトにupdatesの履歴は残っていないので、過去のバージョンのカーネルを雑誌付録のCD-ROMなどから探し出しました。これらのバージョンを試した結果、2.2.16は12日間、2.2.17は3日間の連続稼働を行っても不具合は出ませんでした。
ここまでのテストによって、残る可能性は、
- 「2.2.17→2.2.18」の差分
- 「2.2.18→2.2.19」の差分
- 「2.2.19→Red Hat製2.2.19」の差分
のいずれかに問題を引き起こす原因があると絞り込まれました。
前述のように、2.2.18→2.2.19のバージョンアップではさまざまなバックポートパッチが適用されており、その範囲はメモリマネジメントにまで及んでいます。状況的にスワップ頻発時の障害発生確率が高いことが分かっているので、これは怪しい。また、Red Hatのカーネルにはスケーラビリティ向上のためのパッチが多数含まれています。Red Hat社自身はRed Hat Linux 7.x系でサーバを構築するでしょうから、6.2のupdatesが十分にテストされているかは分かりません。
そこで、さらなる切り分けのためにkernel.orgから2.2.18と2.2.19を取ってきてテストしました。すると、2.2.18は6日間の連続稼働でも障害は出なかったのに対し、2.2.19では1日で例の障害が発生したのです。
■カーネル2.2.19の問題部分を特定するなら？
ここまでのテストにより、カーネル2.2.19のどこかに今回の障害に関係する部分があることは分かりました。これをさらに突き詰めて障害の原因を追究するなら、2.2.18→2.2.19の差分のうち、独立性の高いものを順に切り張りして2.2.18に適用して（もしくは2.2.19から引き算して）、これまでと同様にテストしていくという手順になります。しかし、ここまでですでに2週間ほどかかっており、さらにカーネルソースレベルの切り分けテストをするとなると時間がかかりすぎます。当然、切り張りのためにはカーネルのソースをつぶさに読む必要もあります。
すでに「Red Hat製2.2.16では障害が出ていない」という実績があることから、費用対効果を考えるとこれ以上の切り分けに意味があるとは思えません。その旨をクライアント企業に伝えました。
そして決着へ
クライアント企業の別の要望もあり、調査自体はここで終了となりました。結果的には「2.2.19とOracle8.1.6の相性」ということになります。相性問題を生んだ原因は2.2.19のバグかもしれませんし、Oracleのバグかもしれません。これはどちらが原因ともいい切れません。Oracle 8.1.6はカーネル2.2系対応となっていますが、8.1.6発表時点では2.2.19はまだ出ていなかったのですから、2.2.19でのテストは行われていないはずです。取りあえず、オラクルにはこの障害について問い合わせておくことにしました。
このケースで本番マシンに手を加えて対処するとすれば、「2.2.16に戻したうえで2.2.19までのパッチのうちセキュリティに関する部分を洗い出し、ネットワーク的にセキュリティを高める」ということになるでしょう。
そもそもどうあるべきだったのか
カーネル2.2.19にバージョンアップした時点から障害が発生し始めたということは、まずカーネルのバージョンを戻すべきだったのです。セキュリティパッチとはいえ、データベースサーバはサイトの奥底に隠して外からのアクセスは許さない設定にするのが基本です。2.2.19における変更がカーネルのコアにも及んでいるということは、ChangeLogを読むだけでも分かります。
「うまく動いているようにみえるサイトはいじらない。いじらなければならない状況になったら、自分が何をしようとしているのかはっきりと理解し、十分なテストを行ったうえでやる」ということは、サイト運営の基本です。
この辺りはUNIXサーバでの運用経験が豊富な会社ならば当たり前なのですが、Windows系だとそうでもないのかもしれません。また、UNIX系にしてもHP-UXやSolarisの場合はベンダが十分なテストを行ったうえでパッチを出しており、運用する方もその内容を理解しています。
しかし、Linuxサーバの場合はそうではないようです。弊社の別の案件で「Linux＋PostgreSQLの限界だということなのでSolaris＋Oracleに移行したい」というものがありました。そこで、データ移行のために元のサーバを調べると、いまだ安定しているとはいい難い（普段Linuxばかり使っている私が個人で使うにしてもちょっと怖い）ReiserFSを使っており、実はファイルシステムが壊れていただけ、というお粗末なオチでした。
Linuxサーバでの環境構築と運用には、情報、ノウハウ、ソースを読むだけの力（もしくはそれをできる人／会社を知っていること）が必要です。いざとなったらソースを読んででも対応できるという力がなければ、オープンソースであるメリットは受けられません。それどころか、オープンソースはだれも保証も対応もしてくれないのですから、実力がないのであればWindowsや商用UNIXの方がいいでしょう。もっとも、信頼できる開発・運用先があればそれに越したことはありませんが……。
| 前編へ |
2/2
|
|
|
||||
|
||||
 |
Linux Square全記事インデックス |
| Linux Squareフォーラム Linux導入事例関連記事 |
 |
オープンソースで情報システムを刷新した嘉悦大学 嘉悦大学は情報システムのインフラを、CentOSやOpenLDAP、Sambaといったオープンソースソフトウェアで刷新した |
|
日米大手銀行がLinuxを採用したそれぞれのワケ バンク・オブ・アメリカと三菱東京UFJという日米を代表する大手銀行は、なぜLinuxとその上で動作するオープンソースソフトウェアを導入したのか |
|
特集：謎のOracleトラブルに挑む（前編） わずかな手掛かりから障害を解決した事例をとおして、トラブルシューティングのあり方や技法、困難さが見えてくる |
|
特集：謎のOracleトラブルに挑む（後編） 編で障害再現に成功したが、原因が特定されたわけではない。彼らはどのようにして問題を切り分けていったのだろうか？ |
|
3年間無停止でNTTグループを支えるLinux 国内で最初期にLinuxで業務システムを構築したNTTコムウェア。このシステムはNTTグループ全体にも導入され、3年間無停止で稼働し続けている |
|
Linux Squareフォーラム全記事インデックス |
|
- 【 pidof 】コマンド――コマンド名からプロセスIDを探す （2017/7/27）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。 - Linuxの「ジョブコントロール」をマスターしよう （2017/7/21）
今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です - 【 pidstat 】コマンド――プロセスのリソース使用量を表示する （2017/7/21）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 - 【 iostat 】コマンド――I/Oデバイスの使用状況を表示する （2017/7/20）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。
 |
|
|
|
|
