LinuxかHP-UX、あなたはどっち？
～潜むリスクを完全比較、適材適所のOS選択～

第3回　障害発生時における迅速な切り分けを比較

≫ HP-UX 11i
Knowledge-on-Demand

≫コラム

≫連載
≫特集、特別企画

ドキュメント/ツール

HPラボ

≫Webキャスト

関連情報

≫HP-UX
- ≫各種ソフトウェア

≫日本HPサイトマップ

事業の根幹に関わる重要なミッションクリティカル・システムには、決してシステムを止めることにない可用性が求められる。高可用性を実現するためにシステムを冗長化・多重化することも重要だが、どんなに堅牢なシステムを構築したとしても、障害発生のリスクをゼロにすることは不可能だ。しかし、たとえ障害発生のリスクをゼロにできなくても、障害発生の根本原因を即座に発見・特定できれば、障害発生によるダウンタイムの短縮に大きく寄与することになり、再発というリスクも防止できる。今回は、障害発生時において迅速な切り分けを実現するHP-UX/Integrityサーバーの優位性を解説する。

第3回　障害発生時における迅速な切り分けを比較

≫	根本原因が分からなければ、障害を繰り返すことに
≫	障害の根本原因究明を実現する機能の違い：HP-UX/Integrityサーバーのハードウェアダンプ
	≫ Twitterでつぶやく

2010年11月
大神企画富樫純一

ページ： 1 2 | 次へ ≫

	根本原因が分からなければ、障害を繰り返すことに

日進月歩、急速に普及を続けるITテクノロジーのおかげで、今のコンピューターシステムは障害発生の頻度がずいぶん小さくなっている。しかし、メカニカルなパーツを組み合わせて作られている以上、障害発生をゼロにすることは残念ながら不可能と言わざるを得ない。さらに、障害発生はすべてがハードウェアに起因するものとは限らない。ソフトウェアの不具合により、障害が引き起こされることもある。

重要なのは、障害が発生したときにその原因を出来るだけ早く発見・特定することだ。これにより、ダウンタイムからの復旧時間は大幅に短縮され、可用性も高まる。システムの停止を回避するためにHAクラスター構成で二重化しているからといって、障害原因を即座に特定しなくても大丈夫、と高を括ってはいけない。障害が発生して稼働系システムがダウンし、待機系システムが代替処理を行っている間、冗長性は大きく損なわれているからだ。この事態から一刻も早く脱するには、障害からの復旧を迅速に進めるとともに、原因の特定と切り分けが行えることが望ましい。

障害から復旧しさえすればよい、と原因究明に無頓着になってもいけない。システムがダウンして根本原因が分からないままにしておくと、同じ障害を繰り返すことも考えられるからだ。たとえば、CPUやメモリに障害が発生してシステムがダウンしたことが分かったとしても、その原因がCPUやメモリなどを構成するハードウェアの故障にあるのか、それともCPUやメモリに致命的なエラーを発生させるソフトウェアの不具合にあるのかによって、対処の仕方は当然のことながら変わってくる。対処方法を誤れば、同じ障害が繰り返されるばかりか、無駄なコストをかけることにもなりかねない。

そこで、ミッションクリティカル・システムに求められるのが、障害発生時にその原因を即座に発見・特定し、障害の内容を切り分けて的確な対応を行えるように支援する機能である。

富樫先生が伝える今回のポイント


	障害発生時における根本原因を即座に究明できる機能を知る! 1. 障害の根本原因究明を実現する機能に違いがあることを理解しよう！ 2. システムがサポートするイベントトレーサビリティの違いを理解しよう！

OSのことならお任せ！
富樫先生

	障害の根本原因究明を実現する機能の違い：HP-UX/Integrityサーバーのハードウェアダンプ

HP-UXのハードウェアプラットフォームであるHP Integrityサーバーには、インテルが最新テクノロジーを結集して開発した64ビットCPU、インテル^® Itanium^® プロセッサー（以下、Itaniumプロセッサー）が搭載されている。このItaniumプロセッサーには、障害発生時の根本原因を即座に発見・特定するために有用なハードウェアダンプ機能が搭載されている。

	Itaniumプロセッサーは “遺言”を残す

システムの稼働中、Integrityサーバーに搭載されたItaniumプロセッサーは、発生したエラーがハードウェアで訂正されたのか、ファームウェアで訂正されたのか、OSで訂正されたのか、その内容をチップセットを通じてNVRAM（Non Volatile RAM＝不揮発性メモリ）に記録している。また、HP-UXでは、NVRAMに書き込まれたエラーメッセージを定期的に参照し、訂正されたエラーカウントをチェックしている。

ところが、訂正できない深刻なエラーが発生し、障害発生の根本原因を取り除いたのちにシステムを再起動しなければならないケースが発生することも考えられる。その際、Itaniumプロセッサーは働きを停めることになるわけだが、黙って働きが停まるわけではない。Itaniumプロセッサーは、「こういうわけでシステムが停止した」という“遺言”を残すのだ。これが、Itaniumプロセッサーに備えられたハードウェアダンプ機能である。

Itaniumプロセッサーは、ダンプファイルをNVRAMに保存する。そのダンプファイルには、訂正できなかったエラーが発生した際の全レジスタの内容が記録されており、これを解析することで障害原因をすぐに特定することが可能になっている。これにより、たとえばメモリのDRAMチップに不良があると分かれば該当するメモリモジュールと交換し、CPUのコアに不具合があると分かればCPUモジュールを交換する。また、ソフトウェアに起因する障害と分かれば、障害回避のための修正パッチを開発する。このようにして、障害の原因を特定し、同じ障害が再び発生しないように対処することが可能になるわけだ。

図1：NVRAMに訂正されたエラーを記録

これに対し、Linux/x86サーバーの場合、インテル^® Xeon^®プロセッサーにはハードウェアダンプ機能がない。したがって、ハードウェアに起因する障害の場合、何らかのエラーによってシステムダウンしたという情報しか得られない。原因が特定できないので、どのコンポーネント、どのモジュールを交換すればよいのか調査するのに時間がかかることになる。

図2：障害時の切り分けの比較

※インテル、Intel Inside、Intel Insideのロゴ、Pentium 、Intel Xeon、およびPentium III Xeonは、米国その他の国々におけるインテル株式会社もしくはその子会社の商標または登録商標です。

ページ： 1 2 |

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

≫このページのトップへ戻る

	Twitterでつぶやく「LinuxかHP-UX、あなたはどっち？」～適材適所のOS選択、ミッションクリティカル・システムに最適なプラットフォームは？～