JP2023003988A - 情報処理装置および運用監視プログラム - Google Patents

Abstract

【課題】故障箇所の特定を容易にすること。【解決手段】情報処理装置１０１は、第１の情報１１０と第２の情報１２０に基づいて、記憶装置Ｄの仮想識別子と第１識別子と第２識別子の対応関係を示す対応情報１３０を生成する。第１の情報１１０は、ストレージ制御ソフトウェア１０３によって認識される記憶装置Ｄの仮想識別子と、ＯＳ１０４によって認識される記憶装置Ｄが装着されたスロットの第１識別子の対応関係を示す。第２の情報１２０は、状態監視回路１０５によって認識される、記憶装置Ｄが装着されたスロットの第２識別子と記憶装置Ｄの状態の対応関係を示す。情報処理装置１０１は、分散ストレージの運用中に、第３の情報１４０を取得するとともに第４の情報１５０を取得し、第３の情報１４０および第４の情報１５０と対応情報１３０とを比較した結果に基づいて、対応情報１３０における第１識別子と第２識別子との対応関係を更新する。【選択図】図１

Description

本発明は、情報処理装置および運用監視プログラムに関する。

従来、ソフトウェアを使ってストレージの機能を汎用サーバ上で実現するＳＤＳ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ）と呼ばれる技術がある。ＳＤＳを利用することで、例えば、複数の汎用サーバと、そのＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）を束ねて、大容量のストレージを構築することができる。

先行技術としては、例えば、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）内の各装置の管理エージェントから情報を取得し、取得した情報をもとにＳＡＮにおけるサーバと仮想ボリュームと実ボリュームの対応関係を管理するものがある。また、物理ディスクにより構成される論理ディスクの論理構成を管理し、物理ディスクの状態情報と論理構成とに基づいて、論理ディスクの劣化状態を診断する技術がある。また、デバイスが接続された物理ポートについてエラーが発生した場合に、そのエラーがデバイス自体の故障によるものか、または物理ポートの故障によるものかを判断するための技術がある。

特開２００５－０２５４８３号公報 特開２０１１－１８０６７３号公報 特開２０１３－１９１０２６号公報

しかしながら、従来技術では、ＳＤＳを利用して構築される分散ストレージシステムにおいて、ＨＤＤなどの記憶装置の故障箇所を特定することが困難な場合がある。

一つの側面では、本発明は、故障箇所の特定を容易にすることを目的とする。

１つの実施態様では、ストレージ装置の記憶装置を用いて分散ストレージを実現するストレージ制御ソフトウェアによって認識される記憶装置の仮想識別子と、前記ストレージ装置のＯＳによって認識される、前記ストレージ装置が有するスロットのうちの前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第１の情報を取得し、前記記憶装置の死活状態を監視する状態監視回路から、前記状態監視回路によって認識される、前記記憶装置が装着されたスロットの第２識別子と、前記記憶装置の状態との対応関係を示す第２の情報を取得し、前記第１の情報と前記第２の情報とに基づいて、前記記憶装置の仮想識別子と第１識別子と第２識別子との対応関係を示す対応情報を生成し、前記分散ストレージの運用中に、前記ストレージ制御ソフトウェアによって認識された記憶装置の仮想識別子と前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第３の情報を取得するとともに、前記状態監視回路から前記記憶装置が装着されたスロットの第２識別子と前記記憶装置の状態との対応関係を示す第４の情報を取得し、前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、前記対応情報における第１識別子と第２識別子との対応関係を更新する、情報処理装置が提供される。

本発明の一側面によれば、故障箇所の特定を容易にすることができるという効果を奏する。

図１は、実施の形態にかかる情報処理装置１０１の一実施例を示す説明図である。 図２は、ストレージシステム２００のシステム構成例を示す説明図である。 図３は、運用監視サーバ２０１のハードウェア構成例を示すブロック図である。 図４は、ソフトログ（初期）の具体例を示す説明図である。 図５は、ハードログ（初期）の具体例を示す説明図である。 図６は、ソフト／ハード対応テーブル６００の記憶内容の一例を示す説明図である。 図７は、運用監視サーバ２０１の機能的構成例を示すブロック図である。 図８は、第１のＨＤＤ情報（初期）の具体例を示す説明図である。 図９は、第２のＨＤＤ情報（初期）の具体例を示す説明図である。 図１０は、第１のＨＤＤ情報（運用時）の具体例を示す説明図である。 図１１は、第２のＨＤＤ情報（運用時）の具体例を示す説明図である。 図１２は、ＨＤＤ＄の故障の種別を示す説明図である。 図１３は、メンテナンス手順対応情報の具体例を示す説明図である。 図１４は、ソフト／ハードログ（運用時）の具体例を示す説明図（その１）である。 図１５は、故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その１）である。 図１６は、故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その２）である。 図１７は、ソフト／ハードログ（運用時）の具体例を示す説明図（その２）である。 図１８は、故障Ｃが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その１）である。 図１９は、故障Ｃが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その２）である。 図２０は、ソフト／ハードログ（運用時）の具体例を示す説明図（その３）である。 図２１は、故障Ｂが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その１）である。 図２２は、故障Ｂが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その２）である。 図２３は、ソフト／ハードログ（運用時）の具体例を示す説明図（その４）である。 図２４は、故障Ｂの後に故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その１）である。 図２５は、故障Ｂの後に故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その２）である。 図２６は、故障Ｂの後に故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その３）である。 図２７は、ソフト／ハードログ（運用時）の具体例を示す説明図（その５）である。 図２８は、複数故障が発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その１）である。 図２９は、複数故障が発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その２）である。 図３０は、複数故障が発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その３）である。 図３１は、複数故障が発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図（その４）である。 図３２は、ソフト／ハードログ（再調査）の具体例を示す説明図である。 図３３は、障害発生レポートの具体例を示す説明図である。 図３４は、運用監視サーバ２０１の第１の運用監視処理手順の一例を示すフローチャートである。 図３５は、運用監視サーバ２０１の第２の運用監視処理手順の一例を示すフローチャートである。 図３６は、ＨＤＤ単数故障処理の具体的処理手順の一例を示すフローチャート（その１）である。 図３７は、ＨＤＤ単数故障処理の具体的処理手順の一例を示すフローチャート（その２）である。 図３８は、ＨＤＤ複数故障処理の具体的処理手順の一例を示すフローチャートである。 図３９は、テーブル更新処理の具体的処理手順の一例を示すフローチャートである。

以下に図面を参照して、本発明にかかる情報処理装置および運用監視プログラムの実施の形態を詳細に説明する。

（実施の形態）
図１は、実施の形態にかかる情報処理装置１０１の一実施例を示す説明図である。図１において、情報処理装置１０１は、分散ストレージにおける記憶装置Ｄの故障箇所を特定可能にするコンピュータである。分散ストレージは、ＳＤＳを利用して構築されるストレージシステムであり、データの分散と複製を行い、性能、可用性、信頼性などを向上させる。記憶装置Ｄは、例えば、ＨＤＤ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などである。

近年、開発コストや人的コストを抑えるという観点から、分散ストレージを実現するソフトウェアとして、ＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）のストレージ制御ソフトウェアが積極的に使用されている。分散ストレージを運用するにあたり、ストレージ（記憶装置）の管理が行われる。

例えば、既存の管理機能として、サーバ本体のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に依存せず、専用ハードウェア（ストレージ状態監視ハード）によって、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）カードの各スロットに接続されたＨＤＤの死活状態を監視し、ダッシュボードに表示するものがある。

この管理機能により検出される故障は、例えば、ハードウェア的（物理的）な故障である。物理的な故障が発生した場合、ＨＤＤの交換が必要となる。また、この管理機能により検出される故障には、デフラグ失敗などによって生じるソフトウェア的（ソフト的）な故障が含まれていてもよい。ソフトウェア的な故障は、再デフラグやフォーマットなどのソフト的な回復措置によりＨＤＤが復旧することがある。

また、分散ストレージを実現するストレージ制御ソフトウェアによってＨＤＤの故障を検出することが考えられる。例えば、ストレージ制御ソフトウェアでは、ＨＤＤは、インストール時やリブート時に割り当てられるＩＤ（仮想識別子）とデバイス名（仮想デバイス名）によって管理される。このため、ストレージ制御ソフトウェア上で認識されなくなったＩＤのＨＤＤを故障として検出することが考えられる。

しかし、ＯＳＳとして提供されるようなストレージ制御ソフトウェアと、ストレージ状態監視ハードはそれぞれ別々に開発されたものであり、互いに連携をとることは想定されていない。このため、従来技術では、ストレージ制御ソフトウェアによる故障の検出結果と、ストレージ状態監視ハードによる故障の検出結果とを突き合わせて、故障の要因を特定するといったことができない。

例えば、ストレージ制御ソフトウェアでは、各ＩＤに対応するＨＤＤが、ＳＡＳカードのどのスロットに装着されているのかといった情報は管理されていない。このため、分散ストレージの運用時に、ストレージ制御ソフトウェア上でＩＤが認識不可となった場合に、そのＩＤがどのスロットに装着されたＨＤＤに対応しているのか特定できず、ストレージ状態監視ハードによる故障の検出結果と突き合わせることができない。

また、ストレージ制御ソフトウェアによって割り当てられた仮想デバイス名と、当該仮想デバイス名のＨＤＤが装着されたスロットとの紐付けは、例えば、サーバ本体のＯＳにより行われる。このため、例えば、仮想デバイス名を軸として、ストレージ制御ソフトウェアが認識するＩＤと、ＯＳが認識するスロットの識別子との対応関係を特定することが考えられる。

しかしながら、ＯＳが認識するスロットの識別子と、ストレージ状態監視ハードが認識するスロットの識別子とは、ネーミングルールが異なる場合がある。この場合、例えば、ストレージ制御ソフトウェア上でＩＤが認識不可となった場合などに、依然として、そのＩＤがどのスロットに装着されたＨＤＤに対応しているのかを特定できず、ストレージ状態監視ハードによる故障の検出結果と突き合わせることができない。

ストレージ制御ソフトウェアによる故障の検出結果とストレージ状態監視ハードによる故障の検出結果とを突き合わせて、故障箇所を特定できなければ、障害発生時の対処に時間がかかる。例えば、ストレージ制御ソフトウェア上でＩＤが認識不可となった場合に、ストレージ状態監視ハードと連携することなく、そのＩＤに対応するＨＤＤを人手により調査して、ＨＤＤ交換を実施するという処置を行うことも考えられる。しかし、認識不可となったＩＤに対応するＨＤＤの調査に作業負荷や作業時間がかかる。

そこで、本実施の形態では、ストレージ制御ソフトウェアを利用して検出される記憶装置Ｄの故障状況と、ストレージ状態監視ハードを利用して検出される故障状況とを突き合わせるための仕組みを構築し、記憶装置Ｄの故障箇所の特定を容易にする。以下、情報処理装置１０１の処理例について説明する。

（１）情報処理装置１０１は、第１の情報１１０を取得する。ここで、第１の情報１１０は、ストレージ装置１０２のストレージ制御ソフトウェア１０３によって認識される記憶装置Ｄの仮想識別子と、ストレージ装置１０２が有するスロットのうちの記憶装置Ｄが装着されたスロットの第１識別子との対応関係を示す。第１の情報１１０は、記憶装置Ｄの故障が発生していない状態（例えば、分散ストレージの運用開始時の初期状態）の分散ストレージに対応する。

仮想識別子は、ストレージ制御ソフトウェア１０３において記憶装置Ｄを識別するための仮想的な識別子である。例えば、ストレージシステムがＮ個の記憶装置Ｄにより構築される場合、Ｎ個の仮想識別子が用意される。第１識別子は、ストレージ装置１０２のＯＳ１０４によって認識されるスロットの識別子である。スロットは、ストレージ装置１０２に接続する記憶装置Ｄを着脱可能な格納部である。スロットは、例えば、ＳＡＳカードのスロットである。

ストレージ制御ソフトウェア１０３は、ストレージ装置１０２の記憶装置Ｄを用いて分散ストレージを実現するソフトウェアである。ストレージ制御ソフトウェア１０３は、記憶装置Ｄを管理したり、記憶装置Ｄへのアクセスを制御したりする。例えば、ストレージ制御ソフトウェア１０３は、Ｃｅｐｈ（登録商標）などのＯＳＳである。ストレージ制御ソフトウェア１０３は、例えば、オブジェクト単位、ブロック単位、ファイル単位でのアクセスを可能にしたり、容量の柔軟な拡張を可能にしたりする。

具体的には、例えば、情報処理装置１０１は、ストレージ制御ソフトウェア１０３から、第１対応情報１１０－１を取得する。第１対応情報１１０－１は、ストレージ制御ソフトウェア１０３によって記憶装置Ｄに割り当てられた仮想識別子と仮想デバイス名との対応関係を示す。仮想識別子と仮想デバイス名は、管理用の識別情報である。

仮想デバイス名は、ストレージ装置１０２のＯＳ１０４上で見せる記憶装置Ｄの仮想的な名前である。仮想デバイス名は、ストレージ制御ソフトウェア１０３からＯＳ１０４に通知され、ＯＳ１０４によって認識される。仮想識別子と仮想デバイス名は、例えば、ストレージ制御ソフトウェア１０３のインストール時やリブート時に各記憶装置Ｄに割り当てられる。

また、情報処理装置１０１は、ストレージ装置１０２のＯＳ１０４から、第２対応情報１１０－２を取得する。第２対応情報１１０－２は、記憶装置Ｄに割り当てられた仮想デバイス名と、ストレージ装置１０２が有するスロットのうち当該記憶装置Ｄが装着されたスロットの第１識別子との対応関係を示す。ストレージ制御ソフトウェア１０３によって割り当てられた仮想デバイス名と、当該仮想デバイス名の記憶装置Ｄが装着されたスロットとの紐付けは、例えば、ＯＳ１０４により行われる。

そして、情報処理装置１０１は、取得した第１対応情報１１０－１と第２対応情報１１０－２とに基づいて、第１の情報１１０を作成することによって、生成した第１の情報１１０を取得する。より詳細に説明すると、例えば、情報処理装置１０１は、第１対応情報１１０－１と第２対応情報１１０－２に含まれる仮想デバイス名を軸として、仮想識別子とスロットの第１識別子との対応関係を示す第１の情報１１０を作成する。

ただし、第１の情報１１０は、情報処理装置１０１とは異なる他のコンピュータ（例えば、ストレージ装置１０２のＯＳ１０４）において作成されてもよい。この場合、情報処理装置１０１は、他のコンピュータ（例えば、ストレージ装置１０２のＯＳ１０４）から第１の情報１１０を取得することにしてもよい。

（２）情報処理装置１０１は、状態監視回路１０５から第２の情報１２０を取得する。ここで、状態監視回路１０５は、ストレージ装置１０２が有する各スロットに装着された記憶装置Ｄの死活状態を監視する専用ハードウェアである。ストレージ装置１０２が有する各スロットに装着された記憶装置Ｄは、ストレージ制御ソフトウェア１０３による分散ストレージに使用される。

第２の情報１２０は、状態監視回路１０５によって認識される、記憶装置Ｄが装着されたスロットの第２識別子と、記憶装置Ｄの状態との対応関係を示す。第２の情報１２０は、記憶装置Ｄの故障が発生していない状態（例えば、分散ストレージの運用開始時の初期状態）の分散ストレージに対応する。

（３）情報処理装置１０１は、取得した第１の情報１１０と第２の情報１２０とに基づいて、記憶装置Ｄの仮想識別子と第１識別子と第２識別子との対応関係を示す対応情報１３０を生成する。具体的には、例えば、情報処理装置１０１は、第１の情報１１０に含まれる第１識別子と第２の情報１２０に含まれる第２識別子とを出現順に対応付けることにより、対応情報１３０を生成することにしてもよい。

これにより、ストレージ装置１０２のＯＳ１０４によって認識されるスロットの第１識別子と、状態監視回路１０５によって認識されるスロットの第２識別子とを仮紐付けした対応情報１３０を生成することができる。この時点では、対応情報１３０における第１識別子と第２識別子との対応関係は正しいとは限らない。

（４）情報処理装置１０１は、分散ストレージの運用中に、第３の情報１４０を取得するとともに、第４の情報１５０を取得する。ここで、第３の情報１４０は、ストレージ制御ソフトウェア１０３によって認識された記憶装置Ｄの仮想識別子と記憶装置Ｄが装着されたスロットの第１識別子との対応関係を示す。

第３の情報１４０は、例えば、第１の情報１１０と同様の手順によって取得される。ただし、第３の情報１４０は、第１の情報１１０と内容が異なる場合がある。例えば、物理的に記憶装置Ｄが故障したり、記憶装置Ｄのデフラグ（最適化）に失敗したりして、リクエストに対するレスポンスがなかったり、エラー応答があったりした場合に、その記憶装置Ｄに割り当てられた仮想識別子がストレージ制御ソフトウェア１０３に認識されなくなる。このような場合、第３の情報１４０では、その記憶装置Ｄの情報（仮想識別子、スロットの第１識別子）が欠落して、第１の情報１１０とは内容が異なるものとなる。

第４の情報１５０は、状態監視回路１０５によって認識された記憶装置Ｄが装着されたスロットの第２識別子と記憶装置Ｄの状態との対応関係を示す。例えば、物理的に記憶装置Ｄが故障して、状態監視回路１０５によってその記憶装置Ｄの故障が検出されると、第４の情報１５０では、例えば、その記憶装置Ｄの情報（スロットの第２識別子）が欠落して、第２の情報１２０とは内容が異なるものとなる。

（５）情報処理装置１０１は、取得した第３の情報１４０および第４の情報１５０と、生成した対応情報１３０とを比較した結果に基づいて、対応情報１３０における第１識別子と第２識別子との対応関係を更新する。

具体的には、例えば、情報処理装置１０１は、対応情報１３０において、第３の情報１４０から特定される故障箇所の第１識別子と、第４の情報１５０から特定される故障箇所の第２識別子とが対応しているか否かを判断する。故障箇所の第１識別子と故障箇所の第２識別子とが対応しているか否かの判断は、例えば、故障箇所の第１識別子に対応するＩＤと故障箇所の第２識別子に対応するＩＤとが同一であるか否かによって判断される。

ここで、故障箇所の第１識別子と故障箇所の第２識別子とが対応している場合、情報処理装置１０１は、対応情報１３０を更新しない。一方、故障箇所の第１識別子と故障箇所の第２識別子とが対応していない場合、情報処理装置１０１は、例えば、対応情報１３０において、故障箇所の第２識別子を、故障箇所の第１識別子に対応する第２識別子と入れ替える。すなわち、ストレージ制御ソフトウェア１０３によって検出された故障位置（ソフト側の故障位置）と状態監視回路１０５によって検出された故障位置（ハード側の故障位置）とが一致しない場合、ハード側の故障位置を入れ替えて、ソフト側の故障位置に合わせる。

このように、情報処理装置１０１によれば、例えば、記憶装置Ｄの故障が発生した際に、第３の情報１４０から特定される故障箇所と第４の情報１５０から特定される故障箇所とを突き合わせて、故障位置の違い（矛盾）を修正することができる。これにより、ＯＳ１０４と状態監視回路１０５でスロットの識別子のネーミングルールが異なるような場合であっても、記憶装置Ｄの故障箇所の特定を容易にすることができる。

例えば、分散ストレージの運用時に、ストレージ制御ソフトウェア１０３上で仮想識別子が認識不可となった場合に、情報処理装置１０１において、その仮想識別子がどのスロットに装着された記憶装置Ｄに対応しているのかを特定して、状態監視回路１０５による故障の検出結果と突き合わせることができる。これにより、故障箇所を容易に特定することができ、適切な障害対応を迅速に行うことができる。

（ストレージシステム２００のシステム構成例）
つぎに、実施の形態にかかるストレージシステム２００のシステム構成例について説明する。以下の説明では、図１に示した情報処理装置１０１を、ストレージシステム２００内の運用監視サーバ２０１に適用した場合を例に挙げて説明する。

図２は、ストレージシステム２００のシステム構成例を示す説明図である。図２において、ストレージシステム２００は、運用監視サーバ２０１と、管理者端末２０２と、ストレージサーバＳ１～Ｓｎ（ｎ：２以上の自然数）と、状態監視ハードＭ１～Ｍｎとを含む。ストレージシステム２００において、運用監視サーバ２０１、管理者端末２０２、ストレージサーバＳ１～Ｓｎおよび状態監視ハードＭ１～Ｍｎは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

以下の説明では、ストレージサーバＳ１～Ｓｎのうちの任意のストレージサーバを「ストレージサーバＳｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。また、状態監視ハードＭ１～Ｍｎのうちの任意の状態監視ハードを「状態監視ハードＭｉ」と表記する場合がある。

ここで、運用監視サーバ２０１は、ストレージシステム２００の運用監視を行う。ストレージシステム２００は、ＳＤＳを利用して構築される分散ストレージである。運用監視サーバ２０１は、例えば、サーバである。管理者端末２０２は、ストレージシステム２００の管理者が使用するコンピュータである。管理者端末２０２は、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットＰＣなどである。

ストレージサーバＳｉは、複数のＨＤＤ＄を有するコンピュータである。ＨＤＤ＄は、記憶装置Ｄ（図１参照）の一例である。ストレージサーバＳｉは、ＯＳ＃ｉと、分散ストレージソフト＃ｉと、を含む。ＯＳ＃ｉは、ストレージサーバＳｉのシステム全体を管理する。

分散ストレージソフト＃ｉは、分散ストレージを実現するソフトウェアである。図１に示したストレージ装置１０２は、例えば、ストレージサーバＳｉに対応する。図１に示したストレージ制御ソフトウェア１０３は、例えば、分散ストレージソフト＃ｉに対応する。図１に示したＯＳ１０４は、例えば、ＯＳ＃ｉに対応する。

状態監視ハードＭｉは、ストレージサーバＳｉに設けられ、ストレージサーバＳｉが有するＳＡＳカードの各スロットに装着されたＨＤＤ＄の死活状態を監視する専用ハードウェアである。図１に示した状態監視回路１０５は、例えば、状態監視ハードＭｉに対応する。

なお、ここでは、運用監視サーバ２０１を、管理者端末２０２やストレージサーバＳｉと別体に設けることにしたが、これに限らない。例えば、運用監視サーバ２０１は、管理者端末２０２により実現されることにしてもよく、また、ストレージサーバＳｉにより実現されることにしてもよい。

（運用監視サーバ２０１のハードウェア構成例）
つぎに、運用監視サーバ２０１のハードウェア構成例について説明する。

図３は、運用監視サーバ２０１のハードウェア構成例を示すブロック図である。図３において、運用監視サーバ２０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ディスクドライブ３０３と、ディスク３０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０５と、可搬型記録媒体Ｉ／Ｆ３０６と、可搬型記録媒体３０７と、を有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、運用監視サーバ２０１の全体の制御を司る。ＣＰＵ３０１は、複数のコアを有していてもよい。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ディスクドライブ３０３は、ＣＰＵ３０１の制御に従ってディスク３０４に対するデータのリード／ライトを制御する。ディスク３０４は、ディスクドライブ３０３の制御で書き込まれたデータを記憶する。ディスク３０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

通信Ｉ／Ｆ３０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して外部のコンピュータ（例えば、図２に示した管理者端末２０２、ストレージサーバＳｉ、状態監視ハードＭｉ）に接続される。そして、通信Ｉ／Ｆ３０５は、ネットワーク２１０と装置内部とのインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ３０５には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

可搬型記録媒体Ｉ／Ｆ３０６は、ＣＰＵ３０１の制御に従って可搬型記録媒体３０７に対するデータのリード／ライトを制御する。可搬型記録媒体３０７は、可搬型記録媒体Ｉ／Ｆ３０６の制御で書き込まれたデータを記憶する。可搬型記録媒体３０７としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。

なお、運用監視サーバ２０１は、上述した構成部のほかに、例えば、入力装置、ディスプレイ等を有することにしてもよい。図２に示した管理者端末２０２、ストレージサーバＳｉについても、運用監視サーバ２０１と同様のハードウェアにより実現することができる。ただし、管理者端末２０２は、上述した構成部のほかに、例えば、入力装置、ディスプレイを有する。

（ソフトログ（初期）の具体例）
つぎに、図４を用いて、ソフトログ（初期）の具体例について説明する。図１に示した第１の情報１１０は、例えば、ソフトログ（初期）に対応する。

図４は、ソフトログ（初期）の具体例を示す説明図である。図４において、ソフトログ（初期）４００は、ＩＤとＳＡＳ番号（ソフト）との対応関係を示す。ＩＤは、分散ストレージソフト＃ｉにおいてＨＤＤ＄を識別するための仮想識別子である。ＩＤは、分散ストレージソフト＃ｉによってＨＤＤ＄に割り当てられる。

ＳＡＳ番号（ソフト）は、ストレージサーバＳｉが有するスロットのうちＨＤＤ＄が装着されたスロットを識別するための第１識別子である。第１識別子は、ストレージサーバＳｉのＯＳ＃ｉによって認識されるスロットの識別子である。ソフトウェア的またはハードウェア的な故障が発生して分散ストレージソフト＃ｉによって認識されなくなったＨＤＤ＄は、例えば、欠測となる。

ソフトログ（初期）４００は、例えば、後述の図８に示す第１のＨＤＤ情報（初期）８００と図９に示す第２のＨＤＤ情報（初期）９００とから作成される。

（ハードログ（初期）の具体例）
つぎに、図５を用いて、ハードログ（初期）の具体例について説明する。図１に示した第２の情報１２０は、例えば、ハードログ（初期）に対応する。

図５は、ハードログ（初期）の具体例を示す説明図である。図５において、ハードログ（初期）５００は、ＳＡＳ番号（ハード）と状態との対応関係を示す。ＳＡＳ番号（ハード）は、ストレージサーバＳｉが有するスロットのうちＨＤＤ＄が装着されたスロットを識別するための第２識別子である。第２識別子は、状態監視ハードＭｉによって認識されるスロットの識別子である。ＳＡＳ番号（ハード）は、ＳＡＳ番号（ソフト）とはネーミングルールが異なる。

状態は、状態監視ハードＭｉによって検出されたＨＤＤ＄の状態である。状態としては、例えば、ＯｐｅｒａｔｉｏｎａｌまたはＡｖａｉｌａｂｌｅが設定される。Ｏｐｅｒａｔｉｏｎａｌは、ＨＤＤ＄が正常に動作していることを示す。Ａｖａｉｌａｂｌｅは、ＨＤＤ＄にソフトウェア的な故障が発生している可能性を示す。ハードウェア的（物理的）な故障が発生したＨＤＤ＄は、例えば、欠測となる。

（ソフト／ハード対応テーブル６００の記憶内容）
つぎに、図６を用いて、運用監視サーバ２０１が用いるソフト／ハード対応テーブル６００の記憶内容について説明する。ソフト／ハード対応テーブル６００は、例えば、図４に示したソフトログ（初期）４００と、図５に示したハードログ（初期）５００に基づき作成される。図１に示した対応情報１３０は、例えば、ソフト／ハード対応テーブル６００に対応する。

図６は、ソフト／ハード対応テーブル６００の記憶内容の一例を示す説明図である。図６において、ソフト／ハード対応テーブル６００は、ＩＤ、ＳＡＳ番号（ソフト）、ＳＡＳ番号（ハード）、状態、故障状態および識別のフィールドを有し、各フィールドに情報を設定することで、ソフト／ハード対応情報６００－１～６００－８をレコードとして記憶する。

ここで、ＩＤは、分散ストレージソフト＃ｉにおいてＨＤＤ＄を識別するための仮想識別子である。ＳＡＳ番号（ソフト）は、ストレージサーバＳｉのＯＳ＃ｉによって認識される、ＨＤＤ＄が装着されたスロットを識別するための第１識別子である。ＩＤおよびＳＡＳ番号（ソフト）は、ソフトログ（例えば、図４に示したソフトログ（初期）４００）から特定される情報である。

ＳＡＳ番号（ハード）は、状態監視ハードＭｉによって認識される、ＨＤＤ＄が装着されたスロットを識別するための第２識別子である。状態は、状態監視ハードＭｉによって検出されたＨＤＤ＄の状態である。状態としては、例えば、Ｏｐｅｒａｔｉｏｎａｌ、Ａｖａｉｌａｂｌｅ、－（Ｎｕｌｌ）が設定される。状態「－」は、ＨＤＤ＄にハードウェア的（物理的）な故障が発生していることを示す。ＳＡＳ番号（ハード）および状態は、ハードログ（例えば、図５に示したハードログ（初期）５００）から特定される情報である。

故障状態は、ソフトログおよびハードログから特定されるＨＤＤ＄の故障状態を示す。例えば、ソフト「○」は、ソフトログから故障が特定されなかったことを示す。例えば、ハード「○」は、ハードログから故障が特定されなかったことを示す。例えば、ソフト「×」は、ソフトログから故障が特定されたことを示す。例えば、ハード「×」は、ハードログから故障が特定されたことを示す。

識別は、ＨＤＤ＄の状態を識別する。識別としては、例えば、－、Ｂ、Ｃ、Ｄ、Ｏのいずれかが設定される。識別「－」は、ＨＤＤ＄のＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）とが仮紐付けがされた状態であることを示す。識別「Ｂ」は、ＨＤＤ＄の故障Ｂが検出されたことを示す。

識別「Ｃ」は、ＨＤＤ＄の故障Ｃが検出されたことを示す。識別「Ｄ」は、ＨＤＤ＄の故障Ｄが検出されたことを示す。Ｂ、ＣおよびＤは、故障の種類を示す。故障Ｂ、故障Ｃおよび故障Ｄについての詳細な説明は後述する。識別「Ｏ」は、ＨＤＤ＄の故障が解消されたことを示す。

（運用監視サーバ２０１の機能的構成例）
図７は、運用監視サーバ２０１の機能的構成例を示すブロック図である。図７において、運用監視サーバ２０１は、第１の取得部７０１と、第２の取得部７０２と、生成部７０３と、更新部７０４と、出力部７０５と、を含む。第１の取得部７０１～出力部７０５は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０４などの記憶装置に記憶される。

第１の取得部７０１は、分散ストレージ＃ｉに関するソフトログ（初期）を取得する。ここで、分散ストレージ＃ｉは、ストレージサーバＳｉのＨＤＤ＄を用いて実現される分散ストレージシステムである。ソフトログ（初期）は、分散ストレージ＃ｉの運用開始時に分散ストレージソフト＃ｉによって認識されるＨＤＤ＄の仮想識別子と、ＯＳ＃ｉによって認識されるＨＤＤ＄が装着されたスロットの第１識別子との対応関係を示す。スロットは、ストレージサーバＳｉに接続するＨＤＤ＄を着脱可能な格納部である。スロットは、例えば、ＳＡＳカードのスロットである。

以下の説明では、ＨＤＤ＄の仮想識別子を「ＩＤ」と表記し、ＯＳ＃ｉによって認識されるＨＤＤ＄が装着されたスロットの第１識別子を「ＳＡＳ番号（ソフト）」と表記する場合がある。

具体的には、例えば、第１の取得部７０１は、分散ストレージソフト＃ｉから、第１のＨＤＤ情報（初期）を取得する。第１のＨＤＤ情報（初期）は、分散ストレージソフト＃ｉによってＨＤＤ＄に割り当てられたＩＤとデバイス名との対応関係を示す。デバイス名は、ストレージサーバＳｉのＯＳ＃ｉ上で見せるＨＤＤ＄の仮想的な名前（仮想デバイス名）である。デバイス名は、分散ストレージソフト＃ｉからＯＳ＃ｉに通知され、ＯＳ＃ｉによって認識される。

分散ストレージソフト＃ｉにおいて、ＨＤＤ＄のＩＤは、例えば、ＨＤＤ＿ＩＤリストをもとに割り当てられる。ＨＤＤ＿ＩＤリストは、ストレージシステム２００内のＨＤＤ＄に割り当てられるＩＤをリスト化した情報である。図１に示した第１対応情報１１０－１は、例えば、第１のＨＤＤ情報（初期）に相当する。

より詳細に説明すると、例えば、第１の取得部７０１は、分散ストレージ＃ｉの運用を開始する前に、「ｃｅｐｈ－ｖｏｌｕｍｅ ｌｖｍ ｌｉｓｔ」などのコマンドを実行することで、分散ストレージソフト＃ｉから第１のＨＤＤ情報（初期）を取得する。ここで、第１のＨＤＤ情報（初期）の具体例について説明する。

図８は、第１のＨＤＤ情報（初期）の具体例を示す説明図である。図８において、第１のＨＤＤ情報（初期）８００は、分散ストレージソフト＃ｉによってＨＤＤ＄に割り当てられたＩＤとデバイス名との対応関係を示す。例えば、ＩＤ「１」に対応するデバイス名は「／ｄｅｖ／ｓｄａ」である。

また、第１の取得部７０１は、例えば、ストレージサーバＳｉのＯＳ＃ｉから、第２のＨＤＤ情報（初期）を取得する。第２のＨＤＤ情報（初期）は、ＨＤＤ＄に割り当てられたデバイス名と、ストレージサーバＳｉが有するスロットのうちＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

分散ストレージソフト＃ｉによって割り当てられたデバイス名と、当該デバイス名のＨＤＤ＄が装着されたスロットとの紐付けはＯＳ＃ｉにより行われる。図１に示した第２対応情報１１０－２は、例えば、第２のＨＤＤ情報（初期）に相当する。

より詳細に説明すると、例えば、第１の取得部７０１は、分散ストレージ＃ｉの運用を開始する前に、「ｌｓ －ｌ ／ｄｅｖ／ｄｉｓｋ／ｂｙ－ｐａｔｈ」などのコマンドを実行することで、ＯＳ＃ｉから第２のＨＤＤ情報（初期）を取得する。ここで、第２のＨＤＤ情報（初期）の具体例について説明する。

図９は、第２のＨＤＤ情報（初期）の具体例を示す説明図である。図９において、第２のＨＤＤ情報（初期）９００は、ＨＤＤ＄に割り当てられたデバイス名と、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。例えば、デバイス名「／ｄｅｖ／ｓｄ０」に対応するＳＡＳ番号（ソフト）は「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ａａａａ」である。

第１の取得部７０１は、例えば、取得した第１のＨＤＤ情報（初期）と第２のＨＤＤ情報（初期）とに基づいて、ソフトログ（初期）を作成する。具体的には、例えば、第１の取得部７０１は、図８に示した第１のＨＤＤ情報（初期）８００と図９に示した第２のＨＤＤ情報（初期）９００に含まれるデバイス名を軸として、ＩＤとＳＡＳ番号（ソフト）との対応関係を特定することにより、図４に示したようなソフトログ（初期）４００を作成する。

これにより、分散ストレージ＃ｉの運用を開始する際の初期状態におけるＨＤＤ＄のＩＤとＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示すソフトログ（初期）を取得することができる。

第２の取得部７０２は、分散ストレージ＃ｉに関するハードログ（初期）を取得する。ここで、ハードログ（初期）は、分散ストレージ＃ｉの運用開始時に状態監視ハードＭｉによって認識される、ＨＤＤ＄が装着されたスロットの第２識別子と、ＨＤＤ＄の状態との対応関係を示す。

以下の説明では、状態監視ハードＭｉによって認識されるＨＤＤ＄が装着されたスロットの第２識別子を「ＳＡＳ番号（ハード）」と表記する場合がある。

具体的には、例えば、第２の取得部７０２は、状態監視ハードＭｉから、図５に示したようなハードログ（初期）５００を取得する。より詳細に説明すると、例えば、第２の取得部７０２は、状態監視ハードＭｉのデータベース（不図示）にアクセスして、ハードログ（初期）５００を取得する。データベースには、例えば、ストレージサーバＳｉのＣＰＵ、メモリ、ＨＤＤ＄などの状態を示す情報が記憶されている。

生成部７０３は、取得されたソフトログ（初期）とハードログ（初期）とに基づいて、分散ストレージ＃ｉに用いるＨＤＤ＄のＩＤとＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を示す対応情報を生成する。

具体的には、例えば、生成部７０３は、ソフトログ（初期）４００に含まれるＳＡＳ番号（ソフト）と、ハードログ（初期）５００に含まれるＳＡＳ番号（ハード）とを、出現順に対応付けることにより、図６に示したようなソフト／ハード対応テーブル６００を生成することにしてもよい。

以下の説明では、初期状態におけるソフト／ハード対応テーブル６００を「ソフト／ハード対応テーブル６００（初期状態）」と表記する場合がある。初期状態における各ＨＤＤ＄の故障状態および識別は、ソフト「○」、ハード「○」および識別「－」である。

また、第１の取得部７０１は、分散ストレージ＃ｉの運用中に、分散ストレージ＃ｉに関するソフトログ（運用時）を取得する。ソフトログ（運用時）は、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。図１に示した第３の情報１４０は、例えば、ソフトログ（運用時）に対応する。

具体的には、例えば、第１の取得部７０１は、分散ストレージ＃ｉの運用中に、分散ストレージソフト＃ｉから、第１のＨＤＤ情報（運用時）を取得する。第１のＨＤＤ情報（運用時）は、ＨＤＤ＄に割り当てられたＩＤのうち、分散ストレージソフト＃ｉが認識しているＩＤとデバイス名との対応関係を示す。

より詳細に説明すると、例えば、第１の取得部７０１は、分散ストレージ＃ｉの運用中に、定期的に、あるいは、管理者端末２０２（図２参照）からの指示に応じて、「ｃｅｐｈ－ｖｏｌｕｍｅ ｌｖｍ ｌｉｓｔ」などのコマンドを実行することで、分散ストレージソフト＃ｉから第１のＨＤＤ情報（運用時）を取得する。ここで、第１のＨＤＤ情報（運用時）の具体例について説明する。

図１０は、第１のＨＤＤ情報（運用時）の具体例を示す説明図である。図１０において、第１のＨＤＤ情報（運用時）１０００は、ＨＤＤ＄に割り当てられたＩＤのうち、分散ストレージソフト＃ｉが認識しているＩＤとデバイス名との対応関係を示す。ここでは、分散ストレージソフト＃によってＩＤ「２」が認識されなくなったため、ＩＤ「２」の情報が欠測している。

また、第１の取得部７０１は、分散ストレージ＃ｉの運用中に、ストレージサーバＳｉのＯＳ＃ｉから、第２のＨＤＤ情報（運用時）を取得する。第２のＨＤＤ情報（運用時）は、ＯＳ＃ｉが認識しているデバイス名と、ＨＤＤ＄が装着されたＳＡＳカードスロットとの対応関係を示す。

より詳細に説明すると、例えば、第１の取得部７０１は、分散ストレージ＃ｉの運用中に、定期的に、あるいは、管理者端末２０２からの指示に応じて、「ｌｓ －ｌ ／ｄｅｖ／ｄｉｓｋ／ｂｙ－ｐａｔｈ」などのコマンドを実行することで、ＯＳ＃ｉから第２のＨＤＤ情報（運用時）を取得する。ここで、第２のＨＤＤ情報（運用時）の具体例について説明する。

図１１は、第２のＨＤＤ情報（運用時）の具体例を示す説明図である。図１１において、第２のＨＤＤ情報（運用時）１１００は、ＨＤＤ＄に割り当てられたデバイス名と、ＨＤＤ＄が装着されたＳＡＳ番号（ソフト）との対応関係を示す。ここでは、分散ストレージソフト＃によって認識されなくなったＩＤ「２」のＨＤＤ＄の情報が欠測している。

第１の取得部７０１は、例えば、取得した第１のＨＤＤ情報（運用時）と第２のＨＤＤ情報（運用時）とに基づいて、ソフトログ（運用時）を作成する。具体的には、例えば、第１の取得部７０１は、図１０に示した第１のＨＤＤ情報（運用時）１０００と図１１に示した第２のＨＤＤ情報（運用時）１１００に含まれるデバイス名を軸として、ＩＤとＳＡＳ番号（ソフト）との対応関係を特定することにより、ソフトログ（運用時）を作成する。

これにより、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示すソフトログ（運用時）を取得することができる。ソフトログ（運用時）の具体例については、例えば、図１４を用いて後述する。

また、第２の取得部７０２は、分散ストレージ＃ｉの運用中に、分散ストレージ＃ｉに関するハードログ（運用時）を取得する。ハードログ（運用時）は、分散ストレージ＃ｉの運用中に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。図１に示した第４の情報１５０は、例えば、ハードログ（運用時）に対応する。

具体的には、例えば、第２の取得部７０２は、分散ストレージ＃ｉの運用中に、状態監視ハードＭｉから、ハードログ（運用時）を取得する。より詳細に説明すると、例えば、第２の取得部７０２は、状態監視ハードＭｉのデータベース（不図示）にアクセスして、ハードログ（運用時）を取得する。ハードログ（運用時）の具体例については、例えば、図１５を用いて後述する。

更新部７０４は、取得されたソフトログ（運用時）から特定される故障箇所のＳＡＳ番号（ソフト）と、取得されたハードログ（運用時）から特定される故障箇所のＳＡＳ番号（ハード）とに基づいて、生成された対応情報におけるＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を更新する。

ソフトログ（運用時）では、例えば、分散ストレージソフト＃ｉによって認識されなくなったＨＤＤ＄のＩＤは非表示となる。このため、更新部７０４は、例えば、ソフトログ（運用時）とソフト／ハード対応テーブル６００とを比較して、欠測となっているＩＤに対応するＳＡＳ番号（ソフト）を、故障箇所のＳＡＳ番号（ソフト）として特定する。

なお、比較対象となるソフト／ハード対応テーブル６００は、最新のソフト／ハード対応テーブル６００である。例えば、分散ストレージ＃ｉの運用開始後に最初に取得されたソフトログ（運用時）と比較するソフト／ハード対応テーブル６００は、ソフト／ハード対応テーブル６００（初期状態）である。

ハードログ（運用時）では、例えば、状態監視ハードＭｉによってハードウェア的（物理的）な故障が検出されたＨＤＤ＄のＳＡＳ番号（ハード）は、欠測となる。また、ハードログ（運用時）では、状態監視ハードＭｉによってソフトウェア的な故障が検出されたＨＤＤ＄の状態は、Ａｖａｉｌａｂｌｅとなる。

このため、更新部７０４は、例えば、ハードログ（運用時）とソフト／ハード対応テーブル６００とを比較して、欠測またはＡｖａｉｌａｂｌｅとなっているＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ハード）として特定する。

なお、比較対象となるソフト／ハード対応テーブル６００は、最新のソフト／ハード対応テーブル６００である。例えば、分散ストレージ＃ｉの運用開始後に最初に取得されたハードログ（運用時）と比較するソフト／ハード対応テーブル６００は、ソフト／ハード対応テーブル６００（初期状態）である。

そして、更新部７０４は、ソフト／ハード対応テーブル６００において、特定した故障箇所のＳＡＳ番号（ソフト）と、特定した故障箇所のＳＡＳ番号（ハード）とが対応していない場合、例えば、故障箇所のＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替える。

これにより、更新部７０４は、ソフト側の故障位置を固定し、ハード側の故障位置をソフト側の故障位置に合わせることによって、故障位置の違いを修正する。ハード側の故障位置とは、ハードログから特定される故障位置である。ソフト側の故障位置とは、ソフトログから特定される故障位置である。

なお、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所のＳＡＳ番号（ソフト）と、故障箇所のＳＡＳ番号（ハード）とが対応していない場合に、故障箇所のＳＡＳ番号（ソフト）を、故障箇所のＳＡＳ番号（ハード）に対応するＳＡＳ番号（ソフト）と入れ替えることにしてもよい。すなわち、ハード側の故障位置を固定し、ソフト側の故障位置をハード側の故障位置に合わせることによって、故障位置の違いを修正することにしてもよい。

また、ソフトログ（運用時）から故障箇所のＳＡＳ番号（ソフト）が特定されず、ハードログ（運用時）から故障箇所のＳＡＳ番号（ハード）が特定される場合がある。例えば、分散ストレージソフト＃ｉの誤認識により、ハードウェア的な故障が発生しているにもかかわらず、ソフト側で故障が検知されない場合がある。

この場合、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所のＳＡＳ番号（ハード）に対応するＩＤ（仮想識別子）に、特定の識別子を付与することにしてもよい。特定の識別子は、ソフトウェア故障およびハードウェア故障のうちハードウェア故障のみが検出されたことを示す。

また、故障箇所のＳＡＳ番号（ハード）のＨＤＤ＄の故障が解消された後に、ソフト／ハード対応テーブル６００において、そのＳＡＳ番号（ハード）の入れ替えが行われることがある。更新部７０４は、ソフト／ハード対応テーブル６００において、ＨＤＤ＄の故障が解消されたＳＡＳ番号（ハード）を他のＳＡＳ番号（ハード）と入れ替える際に、特定の識別子を、他のＳＡＳ番号（ハード）に対応するＩＤに付け替える。

これにより、以降において、ソフト／ハード対応テーブル６００のＳＡＳ番号（ハード）の入れ替えが行われても、ＩＤに付与された特定の識別子からハードウェア故障のみが検出された箇所を特定することができる。

以下、更新部７０４の具体的な処理例について説明する。以下の説明では、ソフトウェア的な故障を「ソフトウェア故障」と表記し、ハードウェア的な故障を「ハードウェア故障」と表記する場合がある。また、ソフトログ（運用時）およびハードログ（運用時）をまとめて「ソフト／ハードログ（運用時）」と表記する場合がある。

例えば、更新部７０４は、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００とを比較した結果に基づいて、ＨＤＤ＄の故障の種別を特定し、特定した故障の種別に応じて、ソフト／ハード対応テーブル６００を更新する。

ここで、図１２を用いて、ＨＤＤ＄の故障の種別について説明する。

図１２は、ＨＤＤ＄の故障の種別を示す説明図である。図１２において、故障種別テーブル１２００は、ソフト／ハードログへの情報の現れ方によってＨＤＤ＄の故障を分類するための情報である。ここでは、故障の種別としては、故障Ａ、故障Ｂ、故障Ｃおよび故障Ｄがある。

故障Ａは、ソフトウェア故障およびハードウェア故障のいずれの故障も検出されていない状態を示す。故障Ａは、ソフトログ（運用時）ではＩＤが表示され、ハードログ（運用時）ではＯｐｅｒａｔｉｏｎａｌとなっているＨＤＤ＄に対応する。なお、故障Ａは、ＨＤＤ＄が正常な状態であることを示しているが、便宜上「故障Ａ」と表記している。

故障Ｂは、ソフトウェア故障およびハードウェア故障のうちハードウェア故障のみが検出された状態を示す。故障Ｂは、ソフトログ（運用時）ではＩＤが表示されているものの、ハードログ（運用時）ではＳＡＳ番号（ハード）が非表示（欠測）となっているＨＤＤ＄に対応する。故障Ｂに対する処置としては、例えば、ＨＤＤ交換が挙げられる。

故障Ｃは、ソフトウェア故障およびハードウェア故障のうちソフトウェア故障のみが検出された状態を示す。故障Ｃは、ソフトログ（運用時）ではＩＤが非表示となり、ハードログ（運用時）ではＡｖａｉｌａｂｌｅとなっているＨＤＤ＄に対応する。故障Ｃに対する処置としては、例えば、ソフト的な回復措置（失敗時：ＨＤＤ交換）が挙げられる。

故障Ｄは、ソフトウェア故障およびハードウェア故障が検出された状態を示す。故障Ｄは、ソフトログ（運用時）ではＩＤが非表示となり、ハードログ（運用時）ではＳＡＳ番号（ハード）が非表示となっているＨＤＤ＄に対応する。故障Ｄに対する処置としては、例えば、ＨＤＤ交換が挙げられる。

更新部７０４は、例えば、故障種別テーブル１２００を参照して、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。

ここで、事象数Ｉｓ，Ｉｈ，Ｉａ，Ｊｓ，Ｊｈ，Ｊａ，Ｘｓ，Ｘｈ，Ｘａを以下のように定義する。

Ｉｓ：ソフトログ（運用時）にＩＤが表示されないＨＤＤ＄の個数
Ｉｈ：ハードログ（運用時）にＳＡＳ番号（ハード）が表示されないＨＤＤ＄の個数
Ｉａ：ハードログ（運用時）にＡｖａｉｌａｂｌｅと表示されるＨＤＤ＄の個数

Ｊｓ：ソフト／ハード対応テーブル６００において、故障状態がソフト「×」となっているＨＤＤ＄の個数
Ｊｈ：ソフト／ハード対応テーブル６００において、故障状態がハード「×」となっているＨＤＤ＄の個数
Ｊａ：ソフト／ハード対応テーブル６００において、状態監視ハードＭｉによって検出された状態がＡｖａｉｌａｂｌｅとなっているＨＤＤ＄の個数

Ｘｓ＝Ｉｓ－Ｊｓ ・・・（１）
Ｘｈ＝Ｉｈ－Ｊｈ ・・・（２）
Ｘａ＝Ｉａ－Ｊａ ・・・（３）

Ｘｓ，Ｘｈ，Ｘａは、各事象の新規発生分を表している。Ｘｓは、ソフトログにＨＤＤ＄のＩＤが表示されない事象の新規発生分を表している。Ｘｈは、ハードログにＨＤＤ＄のＳＡＳ番号（ハード）が表示されない事象の新規発生分を表している。Ｘａは、ハードログにＨＤＤ＄の状態としてＡｖａｉｌａｂｌｅが表示された事象の新規発生分を表している。なお、初期状態では、（Ｊｓ，Ｊｈ，Ｊａ）は、「（Ｊｓ，Ｊｈ，Ｊａ）＝（０，０，０）」となる。

ここで、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を「ＮＢ，ＮＣ，ＮＤ」と表記する。この場合、Ｘｓ，ＸｈおよびＸａは、下記式（４）、（５）および（６）を用いて表すことができる。

Ｘｓ＝ＮＣ＋ＮＤ ・・・（４）
Ｘｈ＝ＮＢ＋ＮＤ ・・・（５）
Ｘａ＝ＮＣ ・・・（６）

例えば、更新部７０４は、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００とに基づいて、上記式（１）～（３）を用いて、（Ｘｓ，Ｘｈ，Ｘａ）を算出する。つぎに、更新部７０４は、上記式（４）～（６）を用いて、算出した（Ｘｓ，Ｘｈ，Ｘａ）から各故障Ｂ，Ｃ，Ｄの新規の故障発生数ＮＢ，ＮＣ，ＮＤを算出する。

例えば、（Ｘｓ，Ｘｈ，Ｘａ）が「（Ｘｓ，Ｘｈ，Ｘａ）＝（０，１，０）」の場合、（ＮＢ，ＮＣ，ＮＤ）は「（ＮＢ，ＮＣ，ＮＤ）＝（１，０，０）」となる。「（ＮＢ，ＮＣ，ＮＤ）＝（１，０，０）」は、故障Ｂが１個発生していることを示す。

また、（Ｘｓ，Ｘｈ，Ｘａ）が「（Ｘｓ，Ｘｈ，Ｘａ）＝（１，０，１）」の場合、（ＮＢ，ＮＣ，ＮＤ）は「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，０）」となる。「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，０）」は、故障Ｃが１個発生していることを示す。

また、（Ｘｓ，Ｘｈ，Ｘａ）が「（Ｘｓ，Ｘｈ，Ｘａ）＝（１，１，０）」の場合、（ＮＢ，ＮＣ，ＮＤ）は「（ＮＢ，ＮＣ，ＮＤ）＝（０，０，１）」となる。「（ＮＢ，ＮＣ，ＮＤ）＝（０，０，１）」は、故障Ｄが１個発生していることを示す。

また、（Ｘｓ，Ｘｈ，Ｘａ）が「（Ｘｓ，Ｘｈ，Ｘａ）＝（２，２，１）」の場合、（ＮＢ，ＮＣ，ＮＤ）は「（ＮＢ，ＮＣ，ＮＤ）＝（１，１，１）」となる。「（ＮＢ，ＮＣ，ＮＤ）＝（１，１，１）」は、故障Ｂ，Ｃ，Ｄがそれぞれ１個発生していることを示す。

例えば、更新部７０４は、算出した（ＮＢ，ＮＣ，ＮＤ）を参照して、新規の故障が発生したか否かを判断する。具体的には、例えば、更新部７０４は、（ＮＢ，ＮＣ，ＮＤ）の少なくともいずれかが１以上の場合、新規の故障が発生したと判断する。一方、（ＮＢ，ＮＣ，ＮＤ）が「（ＮＢ，ＮＣ，ＮＤ）＝（０，０，０）」の場合、更新部７０４は、新規の故障が発生していないと判断する。

なお、更新部７０４は、（Ｘｓ，Ｘｈ，Ｘａ）が「（Ｘｓ，Ｘｈ，Ｘａ）＝（０，０，０）」の場合に、新規の故障が発生していないと判断してもよい。また、更新部７０４は、（Ｘｓ，Ｘｈ，Ｘａ）が「（Ｘｓ，Ｘｈ，Ｘａ）≠（０，０，０）」の場合に、新規の故障が発生したと判断してもよい。

新規の故障が発生した場合、更新部７０４は、単数故障であるか複数故障であるかを判断する。ここで、単数故障は、ソフトログ（運用時）およびハードログ（運用時）の少なくともいずれかから一つの故障箇所が特定された場合に相当する。複数故障は、ソフトログ（運用時）およびハードログ（運用時）の少なくともいずれかから複数の故障箇所が特定された場合に相当する。

具体的には、例えば、更新部７０４は、算出した（ＮＢ，ＮＣ，ＮＤ）が、（１，０，０）、（０，１，０）および（０，０，１）のいずれかの場合に、単数故障であると判断する。一方、（ＮＢ，ＮＣ，ＮＤ）が（１，０，０）、（０，１，０）および（０，０，１）のいずれでもない場合に、更新部７０４は、複数故障であると判断する。

単数故障の場合、更新部７０４は、故障種別が故障Ｂ，Ｃ，Ｄのいずれであるかを判断する。ここで、故障種別が故障Ｂの場合、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所のＳＡＳ番号（ハード）に対応するＩＤ（仮想識別子）に、特定の識別子を付与する。また、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所（例えば、ＩＤ）に対応する識別に「Ｂ」を設定する。

なお、故障Ｂが発生した場合のソフト／ハード対応テーブル６００の更新例については、図２０～図２２を用いて後述する。

故障種別が故障Ｃの場合、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応していなければ、故障箇所のＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替える。また、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所（入れ替え先のＨＤＤ＄のＩＤ）に対応する識別に「Ｃ」を設定する。

なお、故障Ｃが発生した場合のソフト／ハード対応テーブル６００の更新例については、図１７～図２０を用いて後述する。

故障種別が故障Ｄの場合、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応していなければ、故障箇所のＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替える。また、更新部７０４は、ソフト／ハード対応テーブル６００において、故障箇所（入れ替え先のＨＤＤ＄のＩＤ）に対応する識別に「Ｄ」を設定する。

なお、故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例については、図１４～図１６を用いて後述する。

運用監視サーバ２０１は、ＨＤＤ＄の故障が解消されたことの通知を受け付けることにしてもよい。具体的には、例えば、運用監視サーバ２０１は、ソフト的な回復措置やＨＤＤ交換などのメンテナンスが実行された結果、管理者端末２０２から、ＨＤＤ＄の故障が解消されたことを示す故障解消通知を受け付ける。故障解消通知には、例えば、故障が解消されたＨＤＤ＄のＩＤ、ＳＡＳ番号（ソフト）、ＳＡＳ番号（ハード）の少なくともいずれかが含まれる。

運用監視サーバ２０１は、故障解消通知を受け付けた場合、ソフト／ハード対応テーブル６００の更新を行うことにしてもよい。具体的には、例えば、更新部７０４は、受け付けた故障解消通知に含まれるＩＤ（あるいは、ＳＡＳ番号（ソフト）、ＳＡＳ番号（ハード））に対応するソフト／ハード対応情報の識別に「Ｏ」を設定する。

また、複数故障の場合、更新部７０４は、例えば、メンテナンス手順対応情報を参照して、算出したＮＢとＮＣとＮＤとの組み合わせに対応するメンテナンス手順を特定する。ここで、メンテナンス手順対応情報は、故障Ｂの数と故障Ｃの数と故障Ｄの数との組み合わせと対応付けて、故障回復のためのメンテナンス手順を示す情報である。

故障Ｂの数は、ソフトウェア故障およびハードウェア故障のうちハードウェア故障のみが検出されたＨＤＤ＄の数である。故障Ｃの数は、ソフトウェア故障およびハードウェア故障のうちソフトウェア故障のみが検出されたＨＤＤ＄の数である。故障Ｄの数は、ソフトウェア故障およびハードウェア故障が検出されたＨＤＤ＄の数である。

ここで、図１３を用いて、メンテナンス手順対応情報の具体例について説明する。

図１３は、メンテナンス手順対応情報の具体例を示す説明図である。図１３において、メンテナンス手順対応表１３００は、メンテナンス手順対応情報の一例であり、例えば、メンテナンス手順情報１３００－１～１３００－７を含む。各メンテナンス手順情報１３００－１～１３００－７は、故障Ｂの数（ＮＢ）と故障Ｃの数（ＮＣ）と故障Ｄの数（ＮＤ）との組み合わせと対応付けて、故障回復のためのメンテナンス手順を示す。

例えば、メンテナンス手順情報１３００－１は、故障Ｂの数（ＮＢ＝１）と故障Ｃの数（ＮＣ＝１）と故障Ｄの数（ＮＤ＝０）との組み合わせに対応するメンテナンス手順「１回（ソフト回復×１、ＨＤＤ交換×１）」を示す。メンテナンス手順「１回（ソフト回復×１、ＨＤＤ交換×１）」は、故障回復に必要なメンテナンス回数が１回であり、１回のメンテナンスで、ソフト的な回復措置を１回、ＨＤＤ交換を１回実施すればよいことを示している。

例えば、メンテナンス手順情報１３００－３は、故障Ｂの数（ＮＢ＝０）と故障Ｃの数（ＮＣ＝１）と故障Ｄの数（ＮＤ＝１）との組み合わせに対応するメンテナンス手順「２回（ＨＤＤ交換×１⇒ソフト回復×１）」を示す。メンテナンス手順「２回（ＨＤＤ交換×１⇒ソフト回復×１）」は、故障回復に必要なメンテナンス回数が２回であり、１回目のメンテナンスで、ＨＤＤ交換を１回実施した後、故障再調査してソフト／ハード対応テーブル６００を更新してから、２回目のメンテナンスで、ソフト的な回復措置を１回実施すればよいことを示している。

具体的には、例えば、更新部７０４は、メンテナンス手順対応表１３００を参照して、算出したＮＢとＮＣとＮＤとの組み合わせに対応するメンテナンス手順を特定する。例えば、算出したＮＢとＮＣとＮＤとの組み合わせを「（ＮＢ，ＮＣ，ＮＤ）＝（１，１，０）」とする。この場合、更新部７０４は、故障Ｂの数（ＮＢ＝１）と故障Ｃの数（ＮＣ＝１）と故障Ｄの数（ＮＤ＝０）との組み合わせに対応するメンテナンス手順「１回（ソフト回復×１、ＨＤＤ交換×１）」を特定する。

また、算出したＮＢとＮＣとＮＤとの組み合わせを「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，１）」とする。この場合、更新部７０４は、故障Ｂの数（ＮＢ＝０）と故障Ｃの数（ＮＣ＝１）と故障Ｄの数（ＮＤ＝１）との組み合わせに対応するメンテナンス手順「２回（ＨＤＤ交換×１⇒ソフト回復×１）」を特定する。

出力部７０５は、特定されたメンテナンス手順を出力する。具体的には、例えば、出力部７０５は、図２に示した管理者端末２０２に障害発生レポートを送信することにしてもよい。障害発生レポートは、分散ストレージ＃ｉの管理者宛に通知される情報であり、特定されたメンテナンス手順を含む。

例えば、メンテナンス手順「１回（ソフト回復×１、ＨＤＤ交換×１）」によれば、分散ストレージ＃ｉの管理者は、ソフトログ（運用時）の欠測箇所に対応するＨＤＤ＄のソフト的な回復措置およびハードログ（運用時）の欠測箇所に対応するＨＤＤ＄の交換を実施すればよいことがわかる。

また、メンテナンス手順「２回（ＨＤＤ交換×１⇒ソフト回復×１）」によれば、分散ストレージ＃ｉの管理者は、１回目のメンテナンスで、ハードログ（運用時）の欠測箇所に対応するＨＤＤ＄の交換を実施すればよいことがわかる。また、分散ストレージ＃ｉの管理者は、その後故障再調査してソフト／ハード対応テーブル６００を更新してから、２回目のメンテナンスで、ソフトログ（運用時）の欠測箇所に対応するＨＤＤ＄のソフト的な回復措置を実施すればよいことがわかる。

なお、分散ストレージ＃ｉの管理者に通知される障害発生レポートの具体例については、図３３を用いて後述する。

運用監視サーバ２０１は、特定されたメンテナンス手順（例えば、障害発生レポート）を出力した結果、メンテナンスが実行されたことの通知を受け付けることにしてもよい。具体的には、例えば、運用監視サーバ２０１は、管理者端末２０２から、出力した障害発生レポートが示すメンテナンス（例えば、１回目のメンテナンス）が実行されたことを示すメンテナンス実施通知を受け付ける。

また、運用監視サーバ２０１は、メンテナンス実施通知を受け付けた場合、ソフト／ハード対応テーブル６００の更新を行うことにしてもよい。具体的には、例えば、第１の取得部７０１は、メンテナンス実施通知を受け付けたことに応じて、分散ストレージ＃ｉに関するソフトログ（運用時）を取得する。また、第２の取得部７０２は、メンテナンス実施通知を受け付けたことに応じて、分散ストレージ＃ｉに関するハードログ（運用時）を取得する。そして、更新部７０４は、取得されたソフトログ（運用時）から特定される故障箇所のＳＡＳ番号（ソフト）と、取得されたハードログ（運用時）から特定される故障箇所のＳＡＳ番号（ハード）とに基づいて、生成された対応情報におけるＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を更新する。

これにより、運用監視サーバ２０１は、障害発生レポートが示すメンテナンスが実行されると、その都度、ソフト／ハード対応テーブル６００の更新を行って、ＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を修正することができる。

なお、上述した説明では、運用監視サーバ２０１は、複数故障を判断するにあたり、ソフト／ハードログ（運用時）と最新のソフト／ハード対応テーブル６００とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出することにしたが、これに限らない。例えば、運用監視サーバ２０１は、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出して、複数故障を判断することにしてもよい。

（ソフト／ハード対応テーブル６００の更新例）
ここで、ソフト／ハード対応テーブル６００の更新例について説明する。まず、図１４～図１６を用いて、故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例について説明する。

図１４は、ソフト／ハードログ（運用時）の具体例を示す説明図（その１）である。図１４において、ソフトログ（運用時）１４０１は、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

ソフトログ（運用時）１４０１において、ソフトウェア的またはハードウェア的な故障が発生して分散ストレージソフト＃ｉによってＩＤが認識されなくなったＨＤＤ＄は、欠測となる。

また、ハードログ（運用時）１４０２は、分散ストレージ＃ｉの運用中に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。

ハードログ（運用時）１４０２において、ハードウェア的な故障が発生したＨＤＤ＄は、欠測となる。また、ハードログ（運用時）１４０２において、ソフトウェア的な故障が発生したＨＤＤ＃の状態には、Ａｖａｉｌａｂｌｅが設定される。

図１５および図１６は、故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図である。ここでは、図１４に示したソフトログ（運用時）１４０１およびハードログ（運用時）１４０２と、図６に示したソフト／ハード対応テーブル６００（初期状態）とを比較して、ソフト／ハード対応テーブル６００を更新する場合について説明する。

例えば、更新部７０４は、故障種別テーブル１２００を参照して、ソフト／ハードログ（運用時）１４０１，１４０２とソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。ここでは、（ＮＢ，ＮＣ，ＮＤ）は、「（ＮＢ，ＮＣ，ＮＤ）＝（０，０，１）」となる。これにより、更新部７０４は、故障Ｄが１個（単数故障）発生していることがわかる。

この場合、更新部７０４は、ソフトログ（運用時）１４０１と、ソフト／ハード対応テーブル６００（初期状態）のソフト部分とを比較して、欠測となっているＨＤＤ＄のＩＤを特定する。ここでは、欠測となっているＨＤＤ＄のＩＤ「２」が特定される。この場合、図１５に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＩＤ「２」のＨＤＤ＄の故障状態－ソフトに「×」を設定する。

なお、ソフト／ハード対応テーブル６００（テンポラリ）は、更新中のソフト／ハード対応テーブル６００の記憶内容を示す。

また、更新部７０４は、ハードログ（運用時）１４０２と、ソフト／ハード対応テーブル６００（初期状態）のハード部分とを比較して、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）「ＵＵＵＵ」が特定される。この場合、図１５に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」のＨＤＤ＄の故障状態－ハードに「×」を設定する。

つぎに、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する。ここでは、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｃｃｃｃ」と故障箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」とが対応していない。

この場合、図１６に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」を、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｃｃｃｃ」に対応するＳＡＳ番号（ハード）「ＲＲＲＲ」と入れ替える。そして、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＩＤに対応する識別に「Ｄ」を設定する。

これにより、故障Ｄが発生した際に、ソフト側の故障位置とハード側の故障位置とが異なる場合、ソフト側の故障位置を固定して、ハード側の故障位置をソフト側の故障位置に合わせることによって、故障位置の違いを修正することができる。なお、ソフト／ハード対応テーブル６００（更新）は、更新後のソフト／ハード対応テーブル６００の記憶内容を示す。

つぎに、図１７～図１９を用いて、故障Ｃが発生した場合のソフト／ハード対応テーブル６００の更新例について説明する。

図１７は、ソフト／ハードログ（運用時）の具体例を示す説明図（その２）である。図１７において、ソフトログ（運用時）１７０１は、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

また、ハードログ（運用時）１７０２は、分散ストレージ＃ｉの運用中に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。ハードログ（運用時）１７０２では、ソフトウェア的な故障が発生したＳＡＳ番号（ハード）「ＵＵＵＵ」のＨＤＤ＃の状態に、Ａｖａｉｌａｂｌｅが設定されている。

図１８および図１９は、故障Ｃが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図である。ここでは、図１７に示したソフトログ（運用時）１７０１およびハードログ（運用時）１７０２と、図６に示したソフト／ハード対応テーブル６００（初期状態）とを比較して、ソフト／ハード対応テーブル６００を更新する場合について説明する。

例えば、更新部７０４は、故障種別テーブル１２００を参照して、ソフト／ハードログ（運用時）１７０１，１７０２とソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。ここでは、（ＮＢ，ＮＣ，ＮＤ）は、「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，０）」となる。これにより、更新部７０４は、故障Ｃが１個（単数故障）発生していることがわかる。

この場合、更新部７０４は、ソフトログ（運用時）１７０１と、ソフト／ハード対応テーブル６００（初期状態）のソフト部分とを比較して、欠測となっているＨＤＤ＄のＩＤを特定する。ここでは、欠測となっているＨＤＤ＄のＩＤ「２」が特定される。この場合、図１８に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＩＤ「２」のＨＤＤ＄の故障状態－ソフトに「×」を設定する。

また、更新部７０４は、ハードログ（運用時）１７０２と、ソフト／ハード対応テーブル６００（初期状態）のハード部分とを比較して、状態がＡｖａｉｌａｂｌｅとなっているＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、状態がＡｖａｉｌａｂｌｅとなっているＨＤＤ＄のＳＡＳ番号（ハード）「ＵＵＵＵ」が特定される。この場合、図１８に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」の状態に「Ａｖａｉｌａｂｌｅ」を設定する。

つぎに、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する。ここでは、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｃｃｃｃ」と故障箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」とが対応していない。

この場合、図１９に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」を、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｃｃｃｃ」に対応するＳＡＳ番号（ハード）「ＲＲＲＲ」と入れ替える。そして、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＩＤに対応する識別に「Ｃ」を設定する。

これにより、故障Ｃが発生した際に、ソフト側の故障位置とハード側の故障位置とが異なる場合、ソフト側の故障位置を固定して、ハード側の故障位置をソフト側の故障位置に合わせることによって、故障位置の違いを修正することができる。

つぎに、図２０～図２２を用いて、故障Ｂが発生した場合のソフト／ハード対応テーブル６００の更新例について説明する。

図２０は、ソフト／ハードログ（運用時）の具体例を示す説明図（その３）である。図２０において、ソフトログ（運用時）２００１は、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

また、ハードログ（運用時）２００２は、分散ストレージ＃ｉの運用中に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。

図２１および図２２は、故障Ｂが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図である。ここでは、図２０に示したソフトログ（運用時）２００１およびハードログ（運用時）２００２と、図６に示したソフト／ハード対応テーブル６００（初期状態）とを比較して、ソフト／ハード対応テーブル６００を更新する場合について説明する。

例えば、更新部７０４は、故障種別テーブル１２００を参照して、ソフト／ハードログ（運用時）２００１，２００２とソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。ここでは、（ＮＢ，ＮＣ，ＮＤ）は、「（ＮＢ，ＮＣ，ＮＤ）＝（１，０，０）」となる。これにより、更新部７０４は、故障Ｂが１個（単数故障）発生していることがわかる。

この場合、更新部７０４は、ハードログ（運用時）２００２と、ソフト／ハード対応テーブル６００（初期状態）のハード部分とを比較して、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）「ＵＵＵＵ」が特定される。

この場合、図２１に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」のＨＤＤ＄の故障状態－ハードに「×」を設定する。ただし、故障Ｂの場合、ソフト側の故障位置が特定されないため、故障Ｃ，Ｄのような入れ替えは行われず、ハード側の故障位置は動かない。また、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」の状態に「－」を設定する。

つぎに、図２２に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」に対応するＩＤに、特定の識別子ａを付与する。そして、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＩＤに対応する識別に「Ｂ」を設定する。

これにより、故障Ｂが発生した際に、故障箇所のＨＤＤ＄のＩＤに、特定の識別子ａを付与することができる。

つぎに、故障箇所のＨＤＤ＄のＩＤに付与する特定の識別子ａの利用例について説明する。故障Ｂが検出された箇所について、故障解消後にソフト側の故障（故障Ｃまたは故障Ｄ）が発生した場合、旧故障Ｂと新故障（故障Ｃまたは故障Ｄ）とで干渉する。この場合、ハード側の故障位置を入れ替える際に、特定の識別子ａを移動させることで、故障Ｂを解消後のＨＤＤ＄を識別可能にする。

ここで、図２３～図２６を用いて、故障Ｂの後に故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例について説明する。

図２３は、ソフト／ハードログ（運用時）の具体例を示す説明図（その４）である。図２３において、ソフトログ（運用時）２３０１は、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

また、ハードログ（運用時）２３０２は、分散ストレージ＃ｉの運用中に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。

図２４～図２６は、故障Ｂの後に故障Ｄが発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図である。図２４において、ソフト／ハード対応テーブル６００（故障解消後）は、図２２に示したソフト／ハード対応テーブル６００（更新）の状態から、ＩＤ「５ａ」の故障Ｂが解消され、ＩＤ「５ａ」に対応する識別に「Ｏ」が設定された状態を示している。

ここでは、図２３に示したソフトログ（運用時）２３０１およびハードログ（運用時）２３０２と、図２４に示した故障Ｂの解消後のソフト／ハード対応テーブル６００（故障解消後）とを比較して、ソフト／ハード対応テーブル６００を更新する場合について説明する。

例えば、更新部７０４は、故障種別テーブル１２００を参照して、ソフト／ハードログ（運用時）２３０１，２３０２とソフト／ハード対応テーブル６００（故障解消後）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。ここでは、（ＮＢ，ＮＣ，ＮＤ）は、「（ＮＢ，ＮＣ，ＮＤ）＝（０，０，１）」となる。これにより、更新部７０４は、故障Ｄが１個（単数故障）発生していることがわかる。

この場合、更新部７０４は、ソフトログ（運用時）２３０１と、ソフト／ハード対応テーブル６００（故障解消後）のソフト部分とを比較して、欠測となっているＨＤＤ＄のＩＤを特定する。ここでは、欠測となっているＨＤＤ＄のＩＤ「５」が特定される。この場合、図２５に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＩＤ「５（図２５では、特定の識別子ａが付与されている）」のＨＤＤ＄の故障状態－ソフトに「×」を設定する。

また、更新部７０４は、ハードログ（運用時）２３０２と、ソフト／ハード対応テーブル６００（故障解消後）のハード部分とを比較して、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）「ＲＲＲＲ」が特定される。この場合、図２５に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＲＲＲＲ」のＨＤＤ＄の故障状態－ハードに「×」を設定する。

つぎに、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する。ここでは、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｆｆｆｆ」と故障箇所のＳＡＳ番号（ハード）「ＲＲＲＲ」とが対応していない。

この場合、図２６に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、故障箇所のＳＡＳ番号（ハード）「ＲＲＲＲ」を、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｆｆｆｆ」に対応するＳＡＳ番号（ハード）「ＵＵＵＵ」と入れ替える。

この際、更新部７０４は、ＩＤ「５」に付与された特定の識別子ａを、入れ替え前の故障箇所のＳＡＳ番号（ハード）「ＲＲＲＲ」に対応するＩＤ「２」に付け替える。そして、更新部７０４は、ソフト／ハード対応テーブル６００（更新）において、ＩＤ「５」に対応する識別「Ｏ」を、入れ替え前の故障箇所のＳＡＳ番号（ハード）「ＲＲＲＲ」に対応する識別に付け替える。また、更新部７０４は、故障箇所のＩＤ「５」に対応する識別に「Ｄ」を設定する。

このように、故障Ｂの解消後に故障Ｄが発生した際に、ハード側の故障位置をソフト側の故障位置に合わせるとともに、特定の識別子ａを入れ替え前の故障箇所のＳＡＳ番号（ハード）「ＲＲＲＲ」に対応するＩＤ「２」に移動させることができる。これにより、故障位置の違いを修正するとともに、故障Ｂが発生してＨＤＤ交換が行われたＨＤＤ＄を識別可能に管理することができる。以後も、故障Ｃまたは故障Ｄが発生し、旧故障Ｂと新故障（故障Ｃまたは故障Ｄ）とで干渉が起こるたびに、特定の識別子ａを移動させて、故障Ｂを解消した後の管理を続けることができる。

つぎに、図２７～図３１を用いて、複数故障が発生した場合のソフト／ハード対応テーブル６００の更新例について説明する。

図２７は、ソフト／ハードログ（運用時）の具体例を示す説明図（その５）である。図２７において、ソフトログ（運用時）２７０１は、分散ストレージ＃ｉの運用中に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

また、ハードログ（運用時）２７０２は、分散ストレージ＃ｉの運用中に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。

図２８～図３１は、複数故障が発生した場合のソフト／ハード対応テーブル６００の更新例を示す説明図である。ここでは、図２７に示したソフトログ（運用時）２７０１およびハードログ（運用時）２７０２と、図６に示したソフト／ハード対応テーブル６００（初期状態）とを比較して、ソフト／ハード対応テーブル６００を更新する場合について説明する。

例えば、更新部７０４は、故障種別テーブル１２００を参照して、ソフト／ハードログ（運用時）２７０１，２７０２とソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。ここでは、（ＮＢ，ＮＣ，ＮＤ）は、「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，１）」となる。これにより、更新部７０４は、故障Ｃ，Ｄが各１個（複数故障）発生していることがわかる。

この場合、更新部７０４は、ソフトログ（運用時）２７０１と、ソフト／ハード対応テーブル６００（初期状態）のソフト部分とを比較して、欠測となっているＨＤＤ＄のＩＤを特定する。ここでは、欠測となっているＨＤＤ＄のＩＤ「４，７」が特定される。この場合、図２８に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＩＤ「４，７」のＨＤＤ＄の故障状態－ソフトに「×」を設定する。

また、更新部７０４は、ハードログ（運用時）２７０２と、ソフト／ハード対応テーブル６００（初期状態）のハード部分とを比較して、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、欠測となっているＨＤＤ＄のＳＡＳ番号（ハード）「ＵＵＵＵ」が特定される。この場合、図２８に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」のＨＤＤ＄の故障状態－ハードに「×」を設定する。また、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」の状態に「－」を設定する。

また、更新部７０４は、ハードログ（運用時）２７０２と、ソフト／ハード対応テーブル６００（初期状態）のハード部分とを比較して、状態がＡｖａｉｌａｂｌｅとなっているＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、状態がＡｖａｉｌａｂｌｅとなっているＨＤＤ＄のＳＡＳ番号（ハード）「ＱＱＱＱ」が特定される。この場合、図２８に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ）において、特定したＳＡＳ番号（ハード）「ＱＱＱＱ」の状態に「Ａｖａｉｌａｂｌｅ」を設定する。

ここでは、故障Ｃ，Ｄが各１個（複数故障）発生しており、ソフト／ハード対応テーブル６００（テンポラリ）のどの事象発生箇所が、故障Ｃ，Ｄそれぞれに該当するか、一意的には決まらない。そこで、更新部７０４は、例えば、図１３に示したメンテナンス手順対応表１３００を参照して、算出したＮＢとＮＣとＮＤとの組み合わせに対応するメンテナンス手順を特定する。

算出したＮＢとＮＣとＮＤとの組み合わせは、「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，１）」である。このため、更新部７０４は、故障Ｂの数（ＮＢ＝０）と故障Ｃの数（ＮＣ＝１）と故障Ｄの数（ＮＤ＝１）との組み合わせに対応するメンテナンス手順「２回（ＨＤＤ交換×１⇒ソフト回復×１）」を特定する。

そして、出力部７０５は、特定したメンテナンス手順「２回（ＨＤＤ交換×１⇒ソフト回復×１）」を含む障害発生レポートを出力する。この場合、分散ストレージ＃ｉの管理者は、まず、ハードログ（運用時）２７０２の欠測箇所に対応するＨＤＤ＄の交換を実施して、故障Ｄを解消する。

故障Ｄの解消後に、分散ストレージ＃ｉの管理者は、例えば、管理者端末２０２から運用監視サーバ２０１にメンテナンス実施通知を送信する。運用監視サーバ２０１は、メンテナンス実施通知を受け付けると、分散ストレージ＃ｉに関するソフト／ハードログ（再調査）を取得し、ソフト／ハード対応テーブル６００の更新を行う。

ここで、図３２を用いて、故障Ｄ解消後のソフト／ハードログ（再調査）について説明する。

図３２は、ソフト／ハードログ（再調査）の具体例を示す説明図である。図３２において、ソフトログ（再調査）３２０１は、故障Ｄ解消後に分散ストレージソフト＃ｉによって認識されたＨＤＤ＄のＩＤと、ＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示す。

また、ハードログ（再調査）３２０２は、故障Ｄ解消後に状態監視ハードＭｉによって認識されたＨＤＤ＄が装着されたスロットのＳＡＳ番号（ハード）と、ＨＤＤ＄の状態との対応関係を示す。

更新部７０４は、図３２に示したソフトログ（再調査）３２０１およびハードログ（再調査）３２０２と、図２８に示したソフト／ハード対応テーブル６００（テンポラリ）とを比較して、ソフト／ハード対応テーブル６００を更新する。

例えば、更新部７０４は、故障種別テーブル１２００を参照して、ソフト／ハードログ（再調査）３２０１，３２０２とソフト／ハード対応テーブル６００（テンポラリ）とを比較した結果に基づいて、各故障Ｂ，Ｃ，Ｄの新規の故障発生数を算出する。ここでは、（ＮＢ，ＮＣ，ＮＤ）は、「（ＮＢ，ＮＣ，ＮＤ）＝（０，１，０）」となる。これにより、更新部７０４は、故障Ｃが１個（単数故障）発生していることがわかる。

この場合、更新部７０４は、ソフトログ（再調査）３２０１と、ソフト／ハード対応テーブル６００（テンポラリ）の故障状態－ソフトとを比較して、回復したＨＤＤ＄のＩＤを特定する。ここでは、回復したＨＤＤ＄のＩＤ「４」が特定される。この場合、図２９に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ２）において、特定したＩＤ「４」のＨＤＤ＄の故障状態－ソフトに「○」を設定する。

また、更新部７０４は、ハードログ（再調査）３２０２と、ソフト／ハード対応テーブル６００（テンポラリ）の故障状態－ハードとを比較して、回復したＨＤＤ＄のＳＡＳ番号（ハード）を特定する。ここでは、回復したＨＤＤ＄のＳＡＳ番号（ハード）「ＵＵＵＵ」が特定される。この場合、図２９に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ２）において、特定したＳＡＳ番号（ハード）「ＵＵＵＵ」のＨＤＤ＄の故障状態－ハードに「○」を設定する。

つぎに、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ２）において、回復した箇所のＳＡＳ番号（ソフト）と回復した箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する。ここでは、回復した箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｅｅｅｅ」と回復した箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」とが対応していない。

この場合、図３０に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ３）において、回復した箇所のＳＡＳ番号（ハード）「ＵＵＵＵ」を、回復した箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｅｅｅｅ」に対応するＳＡＳ番号（ハード）「ＴＴＴＴ」と入れ替える。そして、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ３）において、回復した箇所のＩＤ「４」に対応する識別に「Ｏ」を設定する。

また、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ２）において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する。ここでは、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｈｈｈｈ」と故障箇所のＳＡＳ番号（ハード）「ＱＱＱＱ」とが対応していない。

この場合、図３０に示すように、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ３）において、故障箇所のＳＡＳ番号（ハード）「ＱＱＱＱ」を、故障箇所のＳＡＳ番号（ソフト）「ＳＡＳ－ｘｘｘｘ－ｓｃｓｉ－ｈｈｈｈ」に対応するＳＡＳ番号（ハード）「ＷＷＷＷ」と入れ替える。そして、更新部７０４は、ソフト／ハード対応テーブル６００（テンポラリ３）において、故障箇所のＩＤ「７」に対応する識別に「Ｃ」を設定する。

つぎに、分散ストレージ＃ｉの管理者は、例えば、ソフトログ（再調査）３２０１の欠測箇所に対応するＨＤＤ＄のソフト的な回復措置を実施して、故障Ｃを解消する。故障Ｃが解消されると、図３１に示すように、ソフト／ハード対応テーブル６００（更新）において、回復した箇所のＩＤ「７」に対応する識別に「Ｏ」が設定される。

（障害発生レポートの具体例）
つぎに、図３３を用いて、分散ストレージ＃ｉの管理者に通知される障害発生レポートの具体例について説明する。

図３３は、障害発生レポートの具体例を示す説明図である。図３３において、障害発生レポート３３００は、分散ストレージ＃ｉの管理者に通知されるメンテナンス手順の一例である。障害発生レポート３３００によれば、管理者は、ＨＤＤ＄の複数故障（故障Ｂ：１箇所、故障Ｃ：１０箇所、故障Ｄ：１０箇所）が発生していることがわかる。

また、障害発生レポート３３００によれば、管理者は、故障回復のためのメンテナンス手順を特定することができる。例えば、まず、管理者は、ハードログの欠測箇所に対応するＨＤＤ＄の交換を実施する。つぎに、管理者は、故障状態の再調査を指示することで、ソフト／ハードログを取り直して、ソフト／ハード対応テーブル６００の更新を行う。

そして、管理者は、ソフトログの欠測箇所に対応するＨＤＤ＄のソフト的な回復措置を試して、結果ＮＧの場合はＨＤＤ交換を実施する。つぎに、管理者は、故障状態の再々調査を指示することで、ソフト／ハードログを取り直して、ソフト／ハード対応テーブル６００の更新を行う。そして、管理者は、ＨＤＤ＄の故障が解消されたことを確認する。

（運用監視サーバ２０１の運用監視処理手順）
つぎに、運用監視サーバ２０１の運用監視処理手順について説明する。まず、図３４を用いて、運用監視サーバ２０１の第１の運用監視処理手順について説明する。第１の運用監視処理は、例えば、分散ストレージ＃ｉの運用監視を開始する際に実行される。

図３４は、運用監視サーバ２０１の第１の運用監視処理手順の一例を示すフローチャートである。図３４のフローチャートにおいて、まず、運用監視サーバ２０１は、分散ストレージ＃ｉに関するソフトログ（初期）を取得する（ステップＳ３４０１）。つぎに、運用監視サーバ２０１は、分散ストレージ＃ｉに関するハードログ（初期）を取得する（ステップＳ３４０２）。

ステップＳ３４０１の処理は、例えば、ストレージサーバＳｉのＯＳ＃ｉおよび分散ストレージソフト＃ｉに対して、故障状況調査指示を送信することで得られる第１のＨＤＤ情報（初期）と第２のＨＤＤ情報（初期）とに基づいて取得される。ステップＳ３４０２の処理は、例えば、状態監視ハードＭｉに対して、故障状況調査指示をそれぞれ送信することにより行われる。なお、ステップＳ３４０１，Ｓ３４０２の処理は、実行順序が逆であってもよく、また、並列に実行されてもよい。

そして、運用監視サーバ２０１は、取得したソフトログ（初期）とハードログ（初期）とに基づいて、ソフト／ハード対応テーブル６００（初期状態）を生成して（ステップＳ３４０３）、本フローチャートによる一連の処理を終了する。

これにより、運用監視サーバ２０１は、分散ストレージ＃ｉに用いるＨＤＤ＄のＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）とを仮紐付けしたソフト／ハード対応テーブル６００（初期状態）を生成することができる。

つぎに、図３５を用いて、運用監視サーバ２０１の第２の運用監視処理手順について説明する。第２の運用監視処理は、例えば、分散ストレージ＃ｉの運用中に、定期的に、あるいは、管理者端末２０２からの指示に応じて実行される。

図３５は、運用監視サーバ２０１の第２の運用監視処理手順の一例を示すフローチャートである。図３５のフローチャートにおいて、まず、運用監視サーバ２０１は、分散ストレージ＃ｉに関するソフトログ（運用時）を取得する（ステップＳ３５０１）。つぎに、運用監視サーバ２０１は、分散ストレージ＃ｉに関するハードログ（運用時）を取得する（ステップＳ３５０２）。

ステップＳ３５０１の処理は、例えば、ストレージサーバＳｉのＯＳ＃ｉおよび分散ストレージソフト＃ｉに対して、故障状況調査指示を送信することで得られる第１のＨＤＤ情報（運用時）と第２のＨＤＤ情報（運用時）とに基づいて取得される。ステップＳ３５０２の処理は、例えば、状態監視ハードＭｉに対して、故障状況調査指示をそれぞれ送信することにより行われる。なお、ステップＳ３５０１，Ｓ３５０２の処理は、実行順序が逆であってもよく、また、並列に実行されてもよい。

そして、運用監視サーバ２０１は、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００とを比較した結果に基づいて、各事象Ｘｓ，Ｘｈ，Ｘａの新規発生数（Ｘｓ，Ｘｈ，Ｘａ）を算出する（ステップＳ３５０３）。なお、比較対象となるソフト／ハード対応テーブル６００は、最新のソフト／ハード対応テーブル６００である。

つぎに、運用監視サーバ２０１は、算出した新規発生数（Ｘｓ，Ｘｈ，Ｘａ）に基づいて、新規故障が発生したか否かを判断する（ステップＳ３５０４）。例えば、運用監視サーバ２０１は、「（Ｘｓ，Ｘｈ，Ｘａ）＝（０，０，０）」の場合に、新規故障が発生していないと判断する。また、運用監視サーバ２０１は、「（Ｘｓ，Ｘｈ，Ｘａ）≠（０，０，０）」の場合に、新規故障が発生したと判断する。

ここで、新規故障が発生していない場合（ステップＳ３５０４：Ｎｏ）、運用監視サーバ２０１は、本フローチャートによる一連の処理を終了する。

一方、新規故障が発生した場合（ステップＳ３５０４：Ｙｅｓ）、運用監視サーバ２０１は、算出した新規発生数（Ｘｓ，Ｘｈ，Ｘａ）に基づいて、各故障Ｂ，Ｃ，Ｄの新規故障発生数（ＮＢ，ＮＣ，ＮＤ）を算出する（ステップＳ３５０５）。そして、運用監視サーバ２０１は、算出した新規故障発生数（ＮＢ，ＮＣ，ＮＤ）に基づいて、ＨＤＤ＄の単数故障または複数故障のいずれであるかを判断する（ステップＳ３５０６）。

ここで、ＨＤＤ＄の単数故障の場合（ステップＳ３５０６：単数故障）、運用監視サーバ２０１は、ＨＤＤ単数故障処理を実行して（ステップＳ３５０７）、本フローチャートによる一連の処理を終了する。ＨＤＤ単数故障処理の具体的な処理手順については、図３６および図３７を用いて後述する。

一方、ＨＤＤ＄の複数故障の場合（ステップＳ３５０６：複数故障）、運用監視サーバ２０１は、ＨＤＤ複数故障処理を実行して（ステップＳ３５０８）、本フローチャートによる一連の処理を終了する。ＨＤＤ複数故障処理の具体的な処理手順については、図３８を用いて後述する。

これにより、運用監視サーバ２０１は、新規の故障が発生した場合に、単数故障であるか複数故障であるかに応じて、ＨＤＤ単数故障処理またはＨＤＤ複数故障処理を実行することができる。

つぎに、図３６および図３７を用いて、ステップＳ３５０７のＨＤＤ単数故障処理の具体的な処理手順について説明する。

図３６および図３７は、ＨＤＤ単数故障処理の具体的処理手順の一例を示すフローチャートである。図３６のフローチャートにおいて、まず、運用監視サーバ２０１は、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００とを比較した結果に基づいて、ソフト／ハード対応テーブル６００（テンポラリ）を作成する（ステップＳ３６０１）。

なお、ソフト／ハード対応テーブル６００（テンポラリ）は、例えば、図３５に示したステップＳ３５０３において、新規発生数（Ｘｓ，Ｘｈ，Ｘａ）を算出する際に合わせて作成することにしてもよい。

つぎに、運用監視サーバ２０１は、故障種別が「Ｂ」であるか否かを判断する（ステップＳ３６０２）。ここで、故障種別が「Ｂ」の場合（ステップＳ３６０２：Ｙｅｓ）、運用監視サーバ２０１は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＳＡＳ番号（ハード）に対応するＩＤに、特定の識別子ａを付与する（ステップＳ３６０３）。

そして、運用監視サーバ２０１は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＩＤに対応する識別に「Ｂ」を設定して（ステップＳ３６０４）、ＨＤＤ単数故障処理を呼び出したステップに戻る。

これにより、故障Ｂが発生した場合に、故障箇所のＨＤＤ＄のＩＤに特定の識別子ａを付与して、故障Ｂが発生したＨＤＤ＄を管理可能にすることができる。

また、ステップＳ３６０２において、故障種別が「Ｂ」ではない場合（ステップＳ３６０２：Ｎｏ）、運用監視サーバ２０１は、故障種別が「Ｃ」であるか否かを判断する（ステップＳ３６０５）。ここで、故障種別が「Ｃ」の場合（ステップＳ３６０５：Ｙｅｓ）、運用監視サーバ２０１は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する（ステップＳ３６０６）。

ここで、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応している場合（ステップＳ３６０６：Ｙｅｓ）、運用監視サーバ２０１は、ステップＳ３６０８に移行する。

一方、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応していない場合（ステップＳ３６０６：Ｎｏ）、運用監視サーバ２０１は、故障箇所のＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替える（ステップＳ３６０７）。

なお、運用監視サーバ２０１は、例えば、故障箇所のＳＡＳ番号（ハード）を入れ替える際に、入れ替え先のＩＤに特定の識別子ａが付与されている場合、入れ替え元のＩＤに特定の識別子ａを移動させる。

そして、運用監視サーバ２０１は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＩＤに対応する識別に「Ｃ」を設定して（ステップＳ３６０８）、ＨＤＤ単数故障処理を呼び出したステップに戻る。

これにより、故障Ｃが発生した場合に、ソフト／ハード対応テーブル６００において、ソフト側の故障位置を固定し、ハード側の故障位置をソフト側の故障位置に合わせることによって、ＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を修正することができる。

また、ステップＳ３６０５において、故障種別が「Ｃ」ではない場合（ステップＳ３６０５：Ｎｏ）、運用監視サーバ２０１は、図３７に示すステップＳ３７０１に移行する。

図３７のフローチャートにおいて、まず、運用監視サーバ２０１は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応しているか否かを判断する（ステップＳ３７０１）。

ここで、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応している場合（ステップＳ３７０１：Ｙｅｓ）、運用監視サーバ２０１は、ステップＳ３７０３に移行する。

一方、故障箇所のＳＡＳ番号（ソフト）と故障箇所のＳＡＳ番号（ハード）とが対応していない場合（ステップＳ３７０１：Ｎｏ）、運用監視サーバ２０１は、故障箇所のＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替える（ステップＳ３７０２）。

そして、運用監視サーバ２０１は、ソフト／ハード対応テーブル６００（テンポラリ）において、故障箇所のＩＤに対応する識別に「Ｄ」を設定して（ステップＳ３７０３）、ＨＤＤ単数故障処理を呼び出したステップに戻る。

これにより、故障Ｄが発生した場合に、ソフト／ハード対応テーブル６００において、ソフト側の故障位置を固定し、ハード側の故障位置をソフト側の故障位置に合わせることによって、ＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を修正することができる。

つぎに、図３８を用いて、ステップＳ３５０８のＨＤＤ複数故障処理の具体的な処理手順について説明する。

図３８は、ＨＤＤ複数故障処理の具体的処理手順の一例を示すフローチャートである。図３８のフローチャートにおいて、まず、運用監視サーバ２０１は、ソフト／ハードログ（運用時）とソフト／ハード対応テーブル６００とを比較した結果に基づいて、ソフト／ハード対応テーブル６００（テンポラリ）を作成する（ステップＳ３８０１）。

なお、ソフト／ハード対応テーブル６００（テンポラリ）は、例えば、図３５に示したステップＳ３５０３において、新規発生数（Ｘｓ，Ｘｈ，Ｘａ）を算出する際に合わせて作成することにしてもよい。

つぎに、運用監視サーバ２０１は、メンテナンス手順対応表１３００を参照して、算出したＮＢとＮＣとＮＤとの組み合わせに対応するメンテナンス手順を特定する（ステップＳ３８０２）。そして、運用監視サーバ２０１は、特定したメンテナンス手順を含む障害発生レポートを出力する（ステップＳ３８０３）。

つぎに、運用監視サーバ２０１は、メンテナンス実施通知を受け付けたか否かを判断する（ステップＳ３８０４）。メンテナンス実施通知は、障害発生レポートが示すメンテナンス（１回のメンテナンス）が実行されたことを示す。ここで、運用監視サーバ２０１は、メンテナンス実施通知を受け付けるのを待つ（ステップＳ３８０４：Ｎｏ）。

そして、運用監視サーバ２０１は、メンテナンス実施通知を受け付けた場合（ステップＳ３８０４：Ｙｅｓ）、ソフト／ハード対応テーブル６００を更新するテーブル更新処理を実行する（ステップＳ３８０５）。テーブル更新処理の具体的な処理手順については、図３９を用いて後述する。

つぎに、運用監視サーバ２０１は、テーブル更新処理が故障回復に必要なメンテナンス回数分実行されたか否かを判断する（ステップＳ３８０６）。故障回復に必要なメンテナンス回数は、メンテナンス手順から特定される。ここで、故障回復に必要なメンテナンス回数分実行されていない場合（ステップＳ３８０６：Ｎｏ）、運用監視サーバ２０１は、ステップＳ３８０４に戻る。

一方、故障回復に必要なメンテナンス回数分実行された場合（ステップＳ３８０６：Ｙｅｓ）、運用監視サーバ２０１は、ＨＤＤ複数故障処理を呼び出したステップに戻る。

これにより、ＨＤＤ＄の複数故障が発生した場合に、故障回復のためのメンテナンス手順を出力することができる。また、障害発生レポートが示すメンテナンスが実行されると、その都度、ソフト／ハード対応テーブル６００の更新を行って、ＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を修正することができる。

つぎに、図３９を用いて、ステップＳ３８０５のテーブル更新処理の具体的な処理手順について説明する。

図３９は、テーブル更新処理の具体的処理手順の一例を示すフローチャートである。図３９のフローチャートにおいて、まず、運用監視サーバ２０１は、分散ストレージ＃ｉに関するソフトログ（再調査）を取得する（ステップＳ３９０１）。つぎに、運用監視サーバ２０１は、分散ストレージ＃ｉに関するハードログ（再調査）を取得する（ステップＳ３９０２）。

ステップＳ３９０１の処理は、例えば、ストレージサーバＳｉのＯＳ＃ｉおよび分散ストレージソフト＃ｉに対して、故障状況調査指示を送信することで得られる第１のＨＤＤ情報（再調査）と第２のＨＤＤ情報（再調査）とに基づいて取得される。ステップＳ３９０２の処理は、例えば、状態監視ハードＭｉに対して、故障状況調査指示をそれぞれ送信することにより行われる。なお、ステップＳ３９０１，Ｓ３９０２の処理は、実行順序が逆であってもよく、また、並列に実行されてもよい。

そして、運用監視サーバ２０１は、ソフト／ハードログ（再調査）とソフト／ハード対応テーブル６００（テンポラリ）とを比較して、ソフト／ハード対応テーブル６００を更新して（ステップＳ３９０３）、テーブル更新処理を呼び出したステップに戻る。

これにより、障害発生レポートに示されたメンテナンスが実行されて、故障が解消される度に、ソフト／ハード対応テーブル６００の記憶内容を更新することができる。

以上説明したように、実施の形態にかかる運用監視サーバ２０１によれば、分散ストレージ＃ｉに関するソフトログ（初期）を取得し、状態監視ハードＭｉから分散ストレージ＃ｉに関するハードログ（初期）を取得し、取得したソフトログ（初期）とハードログ（初期）とに基づいて、ソフト／ハード対応テーブル６００（初期状態）を生成することができる。

これにより、分散ストレージ＃ｉに用いるＨＤＤ＄のＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）とを仮紐付けしたソフト／ハード対応テーブル６００（初期状態）を生成することができる。

また、運用監視サーバ２０１によれば、分散ストレージ＃ｉの運用中に、分散ストレージ＃ｉに関するソフトログ（運用時）を取得するとともに、分散ストレージ＃ｉに関するハードログ（運用時）を取得することができる。そして、運用監視サーバ２０１によれば、ソフトログ（運用時）およびハードログ（運用時）と、ソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、ソフト／ハード対応テーブル６００（初期状態）におけるＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を更新することができる。

これにより、ＨＤＤ＄の故障が発生した際に、ソフトログ（運用時）から特定される故障箇所とハードログ（運用時）から特定される故障箇所とを突き合わせて、故障位置の違い（矛盾）を修正することができ、故障箇所の特定を容易にすることができる。

また、運用監視サーバ２０１によれば、ソフト／ハード対応テーブル６００（初期状態）において、ソフトログ（運用時）から特定される故障箇所のＳＡＳ番号（ソフト）と、ハードログ（運用時）から特定される故障箇所のＳＡＳ番号（ハード）とが対応していない場合、故障箇所のＳＡＳ番号（ハード）を、故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替えることができる。

これにより、ハード側の故障位置をソフト側の故障位置に合わせることによって、故障位置の違いを修正することができる。また、ソフト側の故障位置を固定にすることで、ＳＡＳ番号の入れ替えにともなう他への影響を抑えることができる（例えば、ＯＳ、アプリ等に変更内容を通知しなくてもよい）。

また、運用監視サーバ２０１によれば、ソフトログ（運用時）およびハードログ（運用時）からソフトウェア故障のみが検出され、故障箇所のＳＡＳ番号（ハード）を故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替えた場合、入れ替え先のＨＤＤ＄のＩＤと対応付けて、故障種別「Ｃ」を設定することができる。

これにより、ソフトウェア故障のみが検出されたＨＤＤ＄を判別可能にすることができる。

また、運用監視サーバ２０１によれば、ソフトログ（運用時）およびハードログ（運用時）からソフトウェア故障およびハードウェア故障が検出され、故障箇所のＳＡＳ番号（ハード）を故障箇所のＳＡＳ番号（ソフト）に対応するＳＡＳ番号（ハード）と入れ替えた場合、入れ替え先のＨＤＤ＄のＩＤと対応付けて、故障種別「Ｄ」を設定することができる。

これにより、ソフトウェア故障およびハードウェア故障が検出されたＨＤＤ＄を判別可能にすることができる。

また、運用監視サーバ２０１によれば、ソフトログ（運用時）から故障箇所のＳＡＳ番号（ソフト）が特定されず、ハードログ（運用時）から故障箇所のＳＡＳ番号（ハード）が特定された場合、ソフト／ハード対応テーブル６００（初期状態）において、故障箇所のＳＡＳ番号（ハード）に対応するＩＤに、特定の識別子ａを付与することができる。特定の識別子ａは、ソフトウェア故障およびハードウェア故障のうちハードウェア故障のみが検出されたことを示す。

これにより、故障Ｂが発生したＨＤＤ＄を識別可能に管理することができる。

また、運用監視サーバ２０１によれば、故障箇所のＳＡＳ番号（ハード）のＨＤＤ＄の故障が解消された後に、ソフト／ハード対応テーブル６００において、ＨＤＤ＄の故障が解消されたＳＡＳ番号（ハード）を他のＳＡＳ番号（ハード）と入れ替える場合、特定の識別子ａを、他のＳＡＳ番号（ハード）に対応するＩＤに付け替えることができる。

これにより、ソフト／ハード対応テーブル６００のＳＡＳ番号（ハード）の入れ替えが行われても、ＩＤに付与された特定の識別子から故障Ｂが発生した箇所を特定することができる。

また、運用監視サーバ２０１によれば、ソフトログ（運用時）およびハードログ（運用時）と、ソフト／ハード対応テーブル６００（初期状態）とを比較した結果に基づいて、故障Ｂの数（ＮＢ）と故障Ｃの数（ＮＣ）と故障Ｄの数（ＮＤ）とを算出することができる。そして、運用監視サーバ２０１によれば、算出した故障Ｂの数（ＮＢ）と故障Ｃの数（ＮＣ）と故障Ｄの数（ＮＤ）とに基づいて、ＨＤＤ＄の単数故障であるか複数故障であるかを判断し、ＨＤＤ＄の単数故障の場合に、ソフト／ハード対応テーブル６００（初期状態）におけるＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との対応関係を更新することができる。

これにより、故障位置の違いを適切に修正可能な場合（単数故障）に、ソフト／ハード対応テーブル６００（初期状態）の更新を行うことができる。

また、運用監視サーバ２０１によれば、ＨＤＤ＄の複数故障の場合、メンテナンス手順対応表１３００を参照して、算出した故障Ｂの数（ＮＢ）と故障Ｃの数（ＮＣ）と故障Ｄの数（ＮＤ）との組み合わせに対応するメンテナンス手順を特定し、特定したメンテナンス手順を出力することができる。

これにより、ＨＤＤ＄の複数故障が発生した場合には、各故障Ｂ，Ｃ，Ｄの新規故障発生数に応じて、故障回復のためのメンテナンス手順を提示することができる。

また、運用監視サーバ２０１によれば、分散ストレージソフト＃ｉから第１のＨＤＤ情報（初期）を取得し、ストレージサーバＳｉのＯＳ＃ｉから第２のＨＤＤ情報（初期）を取得することができる。そして、運用監視サーバ２０１によれば、取得した第１のＨＤＤ情報（初期）と第２のＨＤＤ情報（初期）とに基づいて、ソフトログ（初期）を作成することによって、ソフトログ（初期）を取得することができる。

これにより、分散ストレージ＃ｉの運用を開始する際の初期状態におけるＨＤＤ＄のＩＤとＨＤＤ＄が装着されたスロットのＳＡＳ番号（ソフト）との対応関係を示すソフトログ（初期）を取得することができる。

これらのことから、運用監視サーバ２０１によれば、ＳＡＳ番号（ソフト）とＳＡＳ番号（ハード）との紐付けを行って、ＨＤＤ＄の故障箇所の特定を容易にすることで、ＨＤＤ＄の故障状況を管理しやすくすることができる。例えば、分散ストレージソフト＃ｉと状態監視ハードＭｉとが別々に開発されたものであっても、運用監視サーバ２０１でＨＤＤ＄の故障箇所を特定して故障状況を管理することができる。

なお、本実施の形態で説明した運用監視方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本運用監視プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本運用監視プログラムは、インターネット等のネットワークを介して配布してもよい。

また、本実施の形態で説明した情報処理装置１０１（運用監視サーバ２０１）は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣやＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）ストレージ装置の記憶装置を用いて分散ストレージを実現するストレージ制御ソフトウェアによって認識される記憶装置の仮想識別子と、前記ストレージ装置のＯＳによって認識される、前記ストレージ装置が有するスロットのうちの前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第１の情報を取得し、
前記記憶装置の死活状態を監視する状態監視回路から、前記状態監視回路によって認識される、前記記憶装置が装着されたスロットの第２識別子と、前記記憶装置の状態との対応関係を示す第２の情報を取得し、
前記第１の情報と前記第２の情報とに基づいて、前記記憶装置の仮想識別子と第１識別子と第２識別子との対応関係を示す対応情報を生成し、
前記分散ストレージの運用中に、前記ストレージ制御ソフトウェアによって認識された記憶装置の仮想識別子と前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第３の情報を取得するとともに、前記状態監視回路から前記記憶装置が装着されたスロットの第２識別子と前記記憶装置の状態との対応関係を示す第４の情報を取得し、
前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、前記対応情報における第１識別子と第２識別子との対応関係を更新する、
制御部を有することを特徴とする情報処理装置。

（付記２）前記制御部は、
前記対応情報において、前記第３の情報から特定される故障箇所の第１識別子と、前記第４の情報から特定される故障箇所の第２識別子とが対応していない場合、前記故障箇所の第２識別子を、前記故障箇所の第１識別子に対応する第２識別子と入れ替える、
ことを特徴とする付記１に記載の情報処理装置。

（付記３）前記制御部は、
前記第３の情報から故障箇所の第１識別子が特定されず、前記第４の情報から故障箇所の第２識別子が特定された場合、前記対応情報において、前記故障箇所の第２識別子に対応する仮想識別子に特定の識別子を付与する、
ことを特徴とする付記２に記載の情報処理装置。

（付記４）前記制御部は、
前記故障箇所の第２識別子の記憶装置の故障が解消された後に、前記対応情報において、当該第２識別子を他の第２識別子と入れ替える場合、前記特定の識別子を、前記他の第２識別子に対応する仮想識別子に付け替える、
ことを特徴とする付記３に記載の情報処理装置。

（付記５）前記制御部は、
前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、ハードウェア故障のみが検出された記憶装置の第１数と、ソフトウェア故障のみが検出された記憶装置の第２数と、ソフトウェア故障およびハードウェア故障が検出された記憶装置の第３数とを算出し、
算出した前記第１数と前記第２数と前記第３数とに基づいて、前記記憶装置の単数故障であるか複数故障であるかを判断し、
前記記憶装置の単数故障の場合に、前記対応情報における第１識別子と第２識別子との対応関係を更新する、
ことを特徴とする付記１～４のいずれか一つに記載の情報処理装置。

（付記６）前記制御部は、
前記記憶装置の複数故障の場合、ハードウェア故障のみが検出された記憶装置の数と、ソフトウェア故障のみが検出された記憶装置の数と、ソフトウェア故障およびハードウェア故障が検出された記憶装置の数との組み合わせと対応付けて、故障回復のためのメンテナンス手順を示す情報を参照して、算出した前記第１数と前記第２数と前記第３数との組み合わせに対応するメンテナンス手順を特定し、
特定した前記メンテナンス手順を出力する、
ことを特徴とする付記５に記載の情報処理装置。

（付記７）前記制御部は、
前記ストレージ制御ソフトウェアから、前記ストレージ制御ソフトウェアによって前記記憶装置に割り当てられた仮想識別子と仮想デバイス名との対応関係を示す第１対応情報を取得し、
前記ＯＳから、前記記憶装置に割り当てられた仮想デバイス名と、前記ストレージ装置が有するスロットのうちの前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第２対応情報を取得し、
前記第１対応情報と前記第２対応情報とに基づいて前記第１の情報を作成することによって、前記第１の情報を取得する、
ことを特徴とする付記１に記載の情報処理装置。

（付記８）前記制御部は、
前記第３の情報および前記第４の情報からソフトウェア故障のみが検出され、前記故障箇所の第２識別子を、前記故障箇所の第１識別子に対応する第２識別子と入れ替えた場合、入れ替え先の前記記憶装置の仮想識別子と対応付けて、ソフトウェア故障のみが検出されたことを示す情報を設定する、
ことを特徴とする付記２に記載の情報処理装置。

（付記９）前記制御部は、
前記第３の情報および前記第４の情報からソフトウェア故障およびハードウェア故障が検出され、前記故障箇所の第２識別子を、前記故障箇所の第１識別子に対応する第２識別子と入れ替えた場合、入れ替え先の前記記憶装置の仮想識別子と対応付けて、ソフトウェア故障およびハードウェア故障が検出されたことを示す情報を設定する、
ことを特徴とする付記２に記載の情報処理装置。

（付記１０）前記特定の識別子は、ソフトウェア故障およびハードウェア故障のうちハードウェア故障のみが検出されたことを示す、ことを特徴とする付記３または４に記載の情報処理装置。

（付記１１）ストレージ装置の記憶装置を用いて分散ストレージを実現するストレージ制御ソフトウェアによって認識される記憶装置の仮想識別子と、前記ストレージ装置のＯＳによって認識される、前記ストレージ装置が有するスロットのうちの前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第１の情報を取得し、
前記記憶装置の死活状態を監視する状態監視回路から、前記状態監視回路によって認識される、前記記憶装置が装着されたスロットの第２識別子と、前記記憶装置の状態との対応関係を示す第２の情報を取得し、
前記第１の情報と前記第２の情報とに基づいて、前記記憶装置の仮想識別子と第１識別子と第２識別子との対応関係を示す対応情報を生成し、
前記分散ストレージの運用中に、前記ストレージ制御ソフトウェアによって認識された記憶装置の仮想識別子と前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第３の情報を取得するとともに、前記状態監視回路から前記記憶装置が装着されたスロットの第２識別子と前記記憶装置の状態との対応関係を示す第４の情報を取得し、
前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、前記対応情報における第１識別子と第２識別子との対応関係を更新する、
処理をコンピュータに実行させることを特徴とする運用監視プログラム。

１０１ 情報処理装置
１０２ ストレージ装置
１０３ ストレージ制御ソフトウェア
１０４，＃ｉ ＯＳ
１０５ 状態監視回路
１１０ 第１の情報
１２０ 第２の情報
１３０ 対応情報
１４０ 第３の情報
１５０ 第４の情報
２００ ストレージシステム
２０１ 運用監視サーバ
２０２ 管理者端末
２１０ ネットワーク
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ディスクドライブ
３０４ ディスク
３０５ 通信Ｉ／Ｆ
３０６ 可搬型記録媒体Ｉ／Ｆ
３０７ 可搬型記録媒体
４００ ソフトログ（初期）
５００ ハードログ（初期）
６００ ソフト／ハード対応テーブル
７０１ 第１の取得部
７０２ 第２の取得部
７０３ 生成部
７０４ 更新部
７０５ 出力部
１２００ 故障種別テーブル
１３００ メンテナンス手順対応表
１４０１等 ソフトログ（運用時）
１４０２等 ハードログ（運用時）
３３００ 障害発生レポート
Ｍ１～Ｍｎ，Ｍｉ 状態監視ハード
Ｓ１～Ｓｎ，Ｓｉ ストレージサーバ
＃ｉ 分散ストレージソフト

Claims (7)

1. ストレージ装置の記憶装置を用いて分散ストレージを実現するストレージ制御ソフトウェアによって認識される記憶装置の仮想識別子と、前記ストレージ装置のＯＳによって認識される、前記ストレージ装置が有するスロットのうちの前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第１の情報を取得し、
   前記記憶装置の死活状態を監視する状態監視回路から、前記状態監視回路によって認識される、前記記憶装置が装着されたスロットの第２識別子と、前記記憶装置の状態との対応関係を示す第２の情報を取得し、
   前記第１の情報と前記第２の情報とに基づいて、前記記憶装置の仮想識別子と第１識別子と第２識別子との対応関係を示す対応情報を生成し、
   前記分散ストレージの運用中に、前記ストレージ制御ソフトウェアによって認識された記憶装置の仮想識別子と前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第３の情報を取得するとともに、前記状態監視回路から前記記憶装置が装着されたスロットの第２識別子と前記記憶装置の状態との対応関係を示す第４の情報を取得し、
   前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、前記対応情報における第１識別子と第２識別子との対応関係を更新する、
   制御部を有することを特徴とする情報処理装置。
2. 前記制御部は、
   前記対応情報において、前記第３の情報から特定される故障箇所の第１識別子と、前記第４の情報から特定される故障箇所の第２識別子とが対応していない場合、前記故障箇所の第２識別子を、前記故障箇所の第１識別子に対応する第２識別子と入れ替える、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記第３の情報から故障箇所の第１識別子が特定されず、前記第４の情報から故障箇所の第２識別子が特定された場合、前記対応情報において、前記故障箇所の第２識別子に対応する仮想識別子に特定の識別子を付与する、
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記制御部は、
   前記故障箇所の第２識別子の記憶装置の故障が解消された後に、前記対応情報において、当該第２識別子を他の第２識別子と入れ替える場合、前記特定の識別子を、前記他の第２識別子に対応する仮想識別子に付け替える、
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記制御部は、
   前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、ハードウェア故障のみが検出された記憶装置の第１数と、ソフトウェア故障のみが検出された記憶装置の第２数と、ソフトウェア故障およびハードウェア故障が検出された記憶装置の第３数とを算出し、
   算出した前記第１数と前記第２数と前記第３数とに基づいて、前記記憶装置の単数故障であるか複数故障であるかを判断し、
   前記記憶装置の単数故障の場合に、前記対応情報における第１識別子と第２識別子との対応関係を更新する、
   ことを特徴とする請求項１～４のいずれか一つに記載の情報処理装置。
6. 前記制御部は、
   前記記憶装置の複数故障の場合、ハードウェア故障のみが検出された記憶装置の数と、ソフトウェア故障のみが検出された記憶装置の数と、ソフトウェア故障およびハードウェア故障が検出された記憶装置の数との組み合わせと対応付けて、故障回復のためのメンテナンス手順を示す情報を参照して、算出した前記第１数と前記第２数と前記第３数との組み合わせに対応するメンテナンス手順を特定し、
   特定した前記メンテナンス手順を出力する、
   ことを特徴とする請求項５に記載の情報処理装置。
7. ストレージ装置の記憶装置を用いて分散ストレージを実現するストレージ制御ソフトウェアによって認識される記憶装置の仮想識別子と、前記ストレージ装置のＯＳによって認識される、前記ストレージ装置が有するスロットのうちの前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第１の情報を取得し、
   前記記憶装置の死活状態を監視する状態監視回路から、前記状態監視回路によって認識される、前記記憶装置が装着されたスロットの第２識別子と、前記記憶装置の状態との対応関係を示す第２の情報を取得し、
   前記第１の情報と前記第２の情報とに基づいて、前記記憶装置の仮想識別子と第１識別子と第２識別子との対応関係を示す対応情報を生成し、
   前記分散ストレージの運用中に、前記ストレージ制御ソフトウェアによって認識された記憶装置の仮想識別子と前記記憶装置が装着されたスロットの第１識別子との対応関係を示す第３の情報を取得するとともに、前記状態監視回路から前記記憶装置が装着されたスロットの第２識別子と前記記憶装置の状態との対応関係を示す第４の情報を取得し、
   前記第３の情報および前記第４の情報と前記対応情報とを比較した結果に基づいて、前記対応情報における第１識別子と第２識別子との対応関係を更新する、
   処理をコンピュータに実行させることを特徴とする運用監視プログラム。

Images