(57)【要約】      （修正有）【課題】リソースのリソース状態情報を適切に管理することができるストレージシステムを提供する。【解決手段】代表ノードと、複数のリソースを含んで構成される複数の一般ノードと、を含んで構成されるストレージシステムであって、一般ノードは、その第１記憶部に、自身の複数のリソースの各々の状態を示すリソース状態情報を記憶する。代表ノードは、その第２記憶部に、複数の一般ノードから収集したリソース状態情報を記憶し、受信したリクエストに基づいて、一般ノードの第１記憶部からリソース状態情報を取得するか、第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報をリクエストの発行元に送信する。【選択図】図２
2020013226.tif 000002
【特許請求の範囲】
【請求項１】
代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムであって、
前記一般ノードは、その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶し、
前記代表ノードは、
その第２記憶部に、前記複数の一般ノードから収集したリソース状態情報を記憶し、
受信したリクエストに基づいて、前記一般ノードの第１記憶部からリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する
ことを特徴とするストレージシステム。
【請求項２】
前記代表ノードは、
複数のリソースを含んで構成され、
その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶し、
その第２記憶部に、前記複数の一般ノード及び前記代表ノードの第１の記憶部から収集したリソース状態情報を記憶している
ことを特徴とする請求項１に記載のストレージシステム。
【請求項３】
前記代表ノードは、前記第２記憶部から前記リクエストにかかるリソース状態情報を取得可能か判断し、取得不可と判断した場合に、前記一般ノードの第１記憶部からリソース状態情報を取得する
ことを特徴とする請求項１に記載のストレージシステム。
【請求項４】
前記一般ノードが各リソースからリソース状態情報を取得する頻度は、前記代表ノードが前記一般ノードから前記リソース状態情報を取得する頻度よりも高く、
前記一般ノードが各リソースから取得するリソース状態情報の容量は、前記代表ノードが一般ノードから取得する前記リソース状態情報の容量よりも大きい
ことを特徴とする請求項１に記載のストレージシステム。
【請求項５】
前記代表ノードが前記リソース状態情報の履歴を保存する期間は、前記一般ノードが前記リソース状態情報の履歴を保存する期間よりも長い
ことを特徴とする請求項４に記載のストレージシステム。
【請求項６】
前記代表ノードは、サマリ化されたリソース状態情報を記憶する
ことを特徴とする請求項１に記載のストレージシステム。
【請求項７】
前記サマリ化されたリソース状態情報は、時間方向でサマリ化されており、
前記リクエストに含まれる時間の指定に基づいて、前記リソース状態情報を取得するノードを決定する
ことを特徴とする請求項６に記載のストレージシステム。
【請求項８】
前記サマリ化されたリソース状態情報は、複数の一般ノードのリソース状態情報をまとめることでサマリ化されており、
前記リクエストに含まれるノードの指定に基づいて、前記リソース状態情報を取得するノードを決定する
ことを特徴とする請求項６に記載のストレージシステム。
【請求項９】
前記一般ノードからリソース状態情報を取得するとした場合に取得を行う前記一般ノードの数に基づいて、前記一般ノードまたは前記第２記憶部のいずれからリソース状態情報を取得するかを決定する
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１０】
前記代表ノードは、前記一般ノードからリソース状態情報を取得する場合、リソース状態情報の対象となるリソースが前記複数の一般ノードの何れかに設けられかを示す履歴情報または前記リソースが移動しうる範囲を示す範囲情報と基づいて、前記一般ノードを特定してリソース状態情報の取得を行う、
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１１】
前記代表ノードとして、主代表ノードと、副代表ノードとが設けられ、
前記主代表ノードは、
前記受信したリクエストの対象となっている一般ノードを特定し、
前記代表ノードと一般ノードの管理関係を規定した管理情報に基づき、前記特定した一般ノードを管理する代表ノードを特定して、前記特定された代表ノードにリクエストを取得させ、
前記特定された代表ノードは、
前記リクエストを取得して、前記一般ノードからリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する、
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１２】
前記主代表ノードは、前記主代表ノードおよび前記副代表ノードの状態を示すノード状態情報に基づいて、前記リクエストを前記特定された代表ノードである副代表ノードに処理させるか否かを判定し、前記処理させると判定した場合、前記副代表ノードに前記リクエストを転送する、
ことを特徴とする請求項１１に記載のストレージシステム。
【請求項１３】
前記一般ノードは、前記複数のリソースのうちリソース状態情報が閾値を超えるリソースのリソース状態情報を記憶する、
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１４】
代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムにおける情報管理方法であって、
前記一般ノードが、その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶する第１のステップと、
前記代表ノードが、その第２記憶部に、前記複数の一般ノードから収集したリソース状態情報を記憶する第２のステップと、
前記代表ノードが、受信したリクエストに基づいて、前記一般ノードの第１記憶部からリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する第３のステップと、
を備えることを特徴とする情報管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はストレージシステムおよび情報管理方法に関し、例えばリソースのリソース状態情報を管理するストレージシステムおよび情報管理方法に適用して好適なものである。
【背景技術】
【０００２】
従来、複数のストレージ装置（以下では、ストレージノードと適宜称する。）を組み合わせて１つのクラスタとして扱えるように構成されたストレージシステムにおいて、各ストレージノードにおけるリソースの稼働情報を管理する方式として、収集方式または分散保存方式が用いられている。
【０００３】
ここで、収集方式は、全てのストレージノードの稼働情報を特定のストレージノード（以下では、代表ノードと適宜称する。）が管理し、ストレージ管理ソフト等からのリクエストに応じて、要求対象の稼働情報を返送する方式である（特許文献１参照）。分散保存方式は、各ストレージノードが稼働情報を保持し、代表ノードは、ストレージ管理ソフト等からのリクエストに応じて、各ストレージノードに対して、要求対象の稼働情報を保持しているかを問い合わせ、各ストレージノードからの問い合わせ結果より要求対象の稼働情報を取得して返送する方式である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２０１１／０１５３６０３号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、ストレージシステムでは、障害が発生したときに、代表ノードでないストレージノードが代表ノードに昇格することを考慮して、昇格を許容するストレージノードについては、代表ノードに必要となるディスク容量を確保しなければならない。よって、代表ノードに必要となるディスク容量を小さくすることが求められている。この点、収集方式では、代表ノードに全てのストレージノードの稼働情報が保持されるので、代表ノードに必要となるディスク容量が大きくなってしまう問題がある。
【０００６】
他方、分散保存方式では、各ストレージノードに稼働情報が保持されるので、代表ノードに必要となるディスク容量を小さくすることができる。しかしながら、分散保存方式では、ストレージ管理ソフト等からのリクエストがあるたびに、各ストレージノードに対して、要求対象の稼働情報を保持しているかを問い合わせることになり、システム全体のＣＰＵの負荷が増大してしまう問題がある。
【０００７】
本発明は以上の点を考慮してなされたもので、各ストレージノードのリソースのリソース状態情報（例えば、稼働情報）を適切に管理することができるストレージシステムを提案しようとするものである。
【課題を解決するための手段】
【０００８】
かかる課題を解決するため本発明においては、代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムであって、前記一般ノードは、その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶し、前記代表ノードは、その第２記憶部に、前記複数の一般ノードから収集したリソース状態情報を記憶し、受信したリクエストに基づいて、前記一般ノードの第１記憶部からリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信するようにした。
【０００９】
また本発明においては、代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムにおける情報管理方法であって、前記一般ノードが、その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶する第１のステップと、前記代表ノードが、その第２記憶部に、前記複数の一般ノードから収集したリソース状態情報を記憶する第２のステップと、前記代表ノードが、受信したリクエストに基づいて、前記一般ノードの第１記憶部からリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する第３のステップと、を設けるようにした。
【００１０】
上記構成では、リソース状態情報を一般ノードに記憶し、一般ノードから収集したリソース状態情報を代表ノードに記憶することで、受信したリクエストに応じて取得先を変更することで、例えば、代表ノードに必要となるディスク容量の削減と、一般ノードへの問い合わせの低減とを実現できるようになる。このように、リソース状態情報を適切に管理することで、例えば、ストレージシステムを正常な状態に迅速かつ容易に保つことができるようになる。
【発明の効果】
【００１１】
本発明によれば、保守性の高いストレージシステムを実現することができる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態によるストレージシステムに係る構成の一例を示す図である。
【図２】第１の実施の形態による稼働情報の収集処理に係る構成の一例を示す図である。
【図３】第１の実施の形態による稼働情報の参照処理に係る構成の一例を示す図である。
【図４】第１の実施の形態によるストレージノードのハードウェア資源に係る構成の一例を示す図である。
【図５】第１の実施の形態によるストレージクラスタに係る論理構成の一例を示す図である。
【図６】第１の実施の形態によるメモリに記憶されるデータの一例を示す図である。
【図７】第１の実施の形態による構成情報の一例を示す図である。
【図８】第１の実施の形態によるストレージノード管理情報の一例を示す図である。
【図９】第１の実施の形態によるモニタ管理情報の一例を示す図である。
【図１０】第１の実施の形態によるモニタ情報の一例を示す図である。
【図１１】第１の実施の形態によるサマリモニタ情報の一例を示す図である。
【図１２】第１の実施の形態によるモニタ情報収集処理に係る処理手順の一例を示す図である。
【図１３】第１の実施の形態による第１サマリモニタ情報収集処理に係る処理手順の一例を示す図である。
【図１４】第１の実施の形態による第２サマリモニタ情報収集処理に係る処理手順の一例を示す図である。
【図１５】第１の実施の形態によるリクエスト応答処理に係る処理手順の一例を示す図である。
【図１６】第１の実施の形態による取得先詳細決定処理に係る処理手順の一例を示す図である。
【図１７】第２の実施の形態によるストレージシステムに係る構成の一例を示す図である。
【図１８】第２の実施の形態によるストレージノード管理情報の一例を示す図である。
【図１９】第２の実施の形態によるリクエスト受信時処理に係る処理手順の一例を示す図である。
【図２０】第３の実施の形態によるストレージシステムに係る構成の一例を示す図である。
【図２１】第３の実施の形態によるストレージノード管理情報の一例を示す図である。
【図２２】第３の実施の形態によるリクエスト受信時処理に係る処理手順の一例を示す図である。
【図２３】第４の実施の形態によるモニタ管理情報の一例を示す図である。
【図２４】第４の実施の形態によるモニタ情報収集処理に係る処理手順の一例を示す図である。
【発明を実施するための形態】
【００１３】
以下図面について、本発明の一実施の形態を詳述する。
【００１４】
（１）第１の実施の形態
図１において、１は全体として第１の実施の形態によるストレージシステムを示す。
【００１５】
ストレージシステム１は、ストレージノード１００（ＳｔｏｒａｇｅＮｏｄｅ）と、管理ノード１１０（ＣｏｎｔｒｏｌｌｅｒＮｏｄｅ）と、コンピュートノード１２０（ＣｏｍｐｕｔｅＮｏｄｅ）と、を含んで構成される。
【００１６】
ストレージノード１００、管理ノード１１０、およびコンピュートノード１２０は、フロントエンドネットワーク１３０（ストレージサービスネットワーク）を介して互いに通信可能に接続されている。また、ストレージノード１００間は、バックエンドネットワーク１４０を介して互いに通信可能に接続されている。
【００１７】
なお、フロントエンドネットワーク１３０とバックエンドネットワーク１４０とは、同一でもあってもよい。また、フロントエンドネットワーク１３０とバックエンドネットワーク１４０の他に、管理用ネットワークが設けられていてもよい。例えば、ストレージノード１００と管理ノード１１０とは、管理用ネットワークを介して互いに通信可能に接続されていてもよい。
【００１８】
ネットワーク（フロントエンドネットワーク１３０とバックエンドネットワーク１４０と管理用ネットワークとのうち少なくとも１つ）は、冗長化されていてもよい。ネットワークは，有線であってもよいし、無線であってもよい。また、ネットワークは、異なる種類のネットワークであってもよい。
【００１９】
ストレージシステム１では、１以上のストレージノード１００を含んでストレージクラスタ１５０が構成されている。ストレージクラスタ１５０では、ストレージクラスタ１５０内でデータの分散する範囲を示すプロテクションドメイン１６０が定義されている。プロテクションドメイン１６０には、一または複数のストレージノード１００が含まれる。なお、プロテクションドメイン１６０は、定義されていなくてもよい（これは、ストレージクラスタ１５０で１つプロテクションドメイン１６０が１つ定義されていることと等しいともいえる）。
【００２０】
かかるストレージシステム１では、各ストレージノード１００に係るリソースの稼働情報が管理されている。以下、詳細について説明する。
【００２１】
図２は、ストレージシステム１における稼働情報の収集処理に係る構成の一例を示す図である。図２では、ストレージノード１００として、ストレージノード２１０，２２０が示されている。
【００２２】
ストレージノード２１０，２２０は、リクエスト制御部２１１，２２１と、ストレージ制御ソフト２１２，２２２と、ＯＳ付属モニタプログラム２１３，２２３と、モニタ情報収集部２１４，２２４と、を備える。また、ストレージノード２１０，２２０は、モニタ情報収集部２１４，２２４により収集されたモニタ情報２１５，２２５を格納するローカル時系列ＤＢ２１６，２２６を備える。
【００２３】
なお、ストレージノード２１０，２２０の各々を区別しないときは、「ストレージノード１００」と称する。リクエスト制御部２１１，２２１の各々を区別しないときは、「リクエスト制御部２０１」と称する。ストレージ制御ソフト２１２，２２２の各々を区別しないときは、「ストレージ制御ソフト２０２」と称する。ＯＳ付属モニタプログラム２１３，２２３の各々を区別しないときは、「ＯＳ付属モニタプログラム２０３」と称する。モニタ情報収集部２１４，２２４の各々を区別しないときは、「モニタ情報収集部２０４」と称する。モニタ情報２１５，２２５の各々を区別しないときは、「モニタ情報２０５」と称する。ローカル時系列ＤＢ２１６，２２６の各々を区別しないときは、「ローカル時系列ＤＢ２０６」と称する。
【００２４】
付言するならば、ストレージ制御ソフト２０２は、ストレージノード１００に１つ設けられる例を挙げて説明するが、設けられる個数および種類に制限はなく、複数個あってもよいし、複数種類あってもよい。ＯＳ付属モニタプログラム２０３は、ストレージノード１００に１つ設けられる例を挙げて説明するが、設けられる個数および種類に制限はなく、複数個あってもよいし、複数種類あってもよい。
【００２５】
リクエスト制御部２０１は、管理ノード１１０等からリクエストを受け付ける。ストレージ制御ソフト２０２は、例えば、ストレージコントローラに搭載される基本ソフトウェアであり、ストレージノード１００の稼働状態を示す稼働情報（例えば、モニタ情報２０５）を取得する。ＯＳ付属モニタプログラム２０３は、例えば、ストレージノード１００のＯＳ（Operating System）に付属されているプログラムであり、ストレージノード１００の稼働状態を示す稼働情報（例えば、モニタ情報２０５）を取得する。モニタ情報収集部２０４は、ストレージ制御ソフト２０２およびＯＳ付属モニタプログラム２０３から稼働情報（例えば、モニタ情報２０５）を収集する。
【００２６】
ここで、モニタ情報２０５は、容量情報（例えば、capacity）、性能情報（例えば、ＩＯＰＳ（Input / Output Per Second））、障害予兆情報（例えば、ＳＳＤ（Solid State Drive）寿命等のＳＭＡＲＴ（Self-Monitoring Analysis and Reporting Technology）情報）など、ストレージノード１００を構成するリソース（物理的なリソースおよび／または論理的なリソース）の稼働状態を示す情報である。モニタ情報２０５は、カウンタ値（例えば、ＩＯカウント）であってもよいし、瞬時値（例えば、ＩＯＰＳ）であってもよい。また、モニタ情報２０５は、モニタ情報２０５がカウント値である場合に、ローカル時系列ＤＢ２０６への保存時に瞬時値に変換されるものであってもよい。
【００２７】
本実施の形態では、図２に示すように、ストレージノード２１０は、管理ノード１１０からリクエストを受け付ける代表ノードである。代表ノードであるストレージノード２１０は、更に、サマリモニタ情報２１７を格納するサマリモニタＤＢ２１８と、振分情報２１９とを備える。以下では、ストレージノード２１０は、「代表ノード」と適宜に称し、代表ノードでないストレージノード２２０は、「一般ノード」と適宜に称する。なお、各一般ノードと代表ノードとの通信のネットワークは、フロントエンドネットワーク１３０とバックエンドネットワーク１４０との何れを利用してもよい。
【００２８】
なお、代表ノードは、複数のリソースを含んで構成され、その第１記憶部（例えば、ローカル時系列ＤＢ２１６）に、自身の上記複数のリソースの各々の状態を示すリソース状態情報（例えば、モニタ情報２０５、稼働情報）を記憶し、その第２記憶部（例えば、サマリモニタＤＢ２１８）に、上記複数の一般ノード及び上記代表ノードの第１の記憶部から収集したリソース状態情報を記憶しているが、この構成に限られるものではない。例えば、代表ノードは、ローカル時系列ＤＢ２１６を有することなく、サマリモニタＤＢ２１８と振分情報２１９とを有する専用のストレージノードとなってもよい。また、代表ノードは、２個以上存在してよい。２個以上である場合、振分情報２１９およびサマリモニタＤＢ２１８のサマリモニタ情報２１７は、代表ノード間でコピーして複製を保持してもよいし、分散して保持してもよい。
【００２９】
また、リクエスト制御部２０１については、代表ノードと一般ノードとで同じプログラムであってもよいし、異なるプログラムであってもよい。モニタ情報収集部２０４については、代表ノードと一般ノードとで同じプログラムであってもよいし、異なるプログラムであってもよい。
【００３０】
サマリモニタ情報２１７は、稼働情報を集計した情報である集計情報（サマリ化されたリソース状態情報）である。例えば、サマリモニタ情報２１７は、日常的に取得される利用の頻度が相対的に高い情報であり、モニタ情報２０５が時間方向でサマリ化（例えば、１秒単位の情報６０カウントが分単位の情報に集約）された情報、または複数の一般ノードのモニタ情報２０５をまとめることでサマリ化（例えば、１ノードの全Ｖｏｌｕｍｅが１リソースとして集約）された情報である。
【００３１】
サマリモニタ情報２１７については、後述するように、一般ノードから定期的に送信されて収集されてもよいし、代表ノードのモニタ情報収集部２１４が各一般ノードへ問い合わせて収集されてもよい。代表ノードのモニタ情報収集部２１４が各一般ノードへ問い合わせる場合、各一般ノードのリクエスト制御部２２１を経由してもよいし、各一般ノードのモニタ情報収集部２２４を経由してもよいし、直接ローカル時系列ＤＢ２２６に問い合わせてもよい。
【００３２】
なお、本実施の形態では、代表ノードがサマリモニタ情報２１７を記憶する構成を例に挙げて説明するが、これに限られるものではない。例えば、代表ノードは、サマリモニタ情報２１７ではなく、一般ノードから収集したモニタ情報２２５（リソース状態情報）を記憶する構成であってもよい。かかる構成にておいて、上記一般ノードが各リソースからリソース状態情報を取得する頻度は、上記代表ノードが上記一般ノードから上記リソース状態情報を取得する頻度よりも高く、上記一般ノードが各リソースから取得するリソース状態情報の容量は、上記代表ノードが一般ノードから取得する上記リソース状態情報の容量よりも大きい構成としてもよい。
【００３３】
振分情報２１９は、現在の構成情報、リソースの過去の移動履歴を示す（リソースが何れかの一般ノードに設けられたことを示す）履歴情報、稼働情報が分散し得るストレージノード１００の範囲を示す（リソースが移動し得る一般ノードの範囲を示す）範囲情報などを含んで構成される。付言するならば、履歴情報は、リソースがどのストレージノード１００に存在していたかの履歴を示す情報である。例えば、履歴情報には、時間情報が含まれ、履歴情報は、どの時間にどのストレージノード１００に存在していたかを識別可能な情報であってもよい。
【００３４】
＜稼働情報の収集手順＞
図２を用いて、ストレージシステム１における稼働情報（モニタ情報２０５およびサマリモニタ情報２１７）の主な収集手順を説明する。
（手順１）
モニタ情報収集部２０４は、モニタ情報２０５のソースとなるプログラムまたはプロセス群から稼働情報を取得し、モニタ情報２０５としてローカル時系列ＤＢ２０６に定期的に（秒単位などの細かい時間間隔で）保存する。
【００３５】
（手順２）
モニタ情報収集部２０４は、時刻方向にモニタ情報２０５を集約し、またはリソース毎にモニタ情報２０５を集約し、集約した情報をサマリモニタ情報２１７として代表ノードのサマリモニタＤＢ２１８に定期的に（分単位などの粗い時間間隔で）保存する。モニタ情報収集部２０４は、平均値、合計値、最小値、最大値、最近の値、最も古い値の何れかとしてモニタ情報２０５を集約（集計）する。なお、値の集計方法については、限定しない。例えば、記載した集計方法以外の集計方法として、中央値の計算などを採用してもよい。
【００３６】
（手順３）
モニタ情報収集部２０４は、全ストレージノード１００から収集したサマリモニタ情報２１７に基づいて情報を集約し、更に大きな単位（例えば、ストレージクラスタ１５０ごと）のサマリモニタ情報２１７として保存する。
【００３７】
このように、ストレージノード１００では、非日常的（例えば、問題の発生時）に取得されるリソース毎のモニタ情報２０５（例えば、秒程度、リソースをＫｅｙ情報とする）を定期的にローカル時系列ＤＢ２０６に保存する。
【００３８】
他方、代表ノードであるストレージノード２１０では、各ストレージノード１００で保存するモニタ情報２０５に加え、日常的（例えば、定期的）に取得されるサマリモニタ情報２１７（例えば、分程度、時刻をＫｅｙとする）をサマリモニタＤＢ２１８に保存する。
【００３９】
図３は、ストレージシステム１における稼働情報（モニタ情報２０５およびサマリモニタ情報２１７）の参照処理に係る構成の一例を示す図である。
【００４０】
＜稼働情報の参照手順＞
図３を用いて、ストレージシステム１における稼働情報の主な参照手順を説明する。
（手順１）
代表ノードのリクエスト制御部２１１は、管理ノード１１０の管理クライアント２４１からのリクエストを受け付ける。
【００４１】
（手順２）
代表ノードのリクエスト制御部２１１は、稼働情報の取得先の振分に必要な振分情報２１９を取得（取得）する。
【００４２】
（手順３）
代表ノードのリクエスト制御部２１１は、リクエストの内容と振分情報２１９とに基づいて、問い合わせるストレージノード１００と、返すべき稼働情報とを判断する。より具体的には、リクエスト制御部２１１は、リクエストに含まれる内容（リソース毎の稼働情報であるかクラスタ全体の稼働情報であるか、リソースの最新の稼働情報であるか１０時から１１時までといった所定期間（履歴）の稼働情報であるか、同時に要求するリソースの数、など）と振分情報２１９とに基づいて、返す稼働情報（モニタ情報２０５またはサマリモニタ情報２１７）と稼働情報を問い合わせるストレージノード１００とを判断する。
【００４３】
（手順４）
代表ノードのリクエスト制御部２１１は、問い合わせるべきストレージノード１００に必要な稼働情報を問い合わせる。なお、リクエスト制御部２１１は、各ストレージノード１００への問い合わせは一度に送出してもよいし、何度かに分割して送出してもよい。
【００４４】
（手順５）
サマリモニタＤＢ２１８または各ストレージノード１００により、必要な稼働情報が取得される。
【００４５】
（手順６）
代表ノードのリクエスト制御部２１１は、必要な稼働情報を受け取る。
【００４６】
なお、リクエスト制御部２０１間の通信は、フロントエンドネットワーク１３０を利用してもよいし、バックエンドネットワーク１４０を利用してもよい。
【００４７】
（手順７）
代表ノードのリクエスト制御部２１１は、集めた稼働情報を整形し、管理クライアント２４１に返す。
【００４８】
なお、本実施の形態では、代表ノードがリクエスト受け付けているが、これに限られるものではなく、一般ノードのリクエスト制御部２２１でリクエストを受け付け、代表ノードにリクエストを転送してもよい（管理ノード１１０との通信処理と、稼働情報の収集に係る処理とを分散して担当するようにしてもよい）。また、振分情報２１９とサマリモニタＤＢ２１８とをコピーして持つ複数の代表ノード間でリクエストを転送し、処理負荷を低減するように構成してもよい。
【００４９】
付言するならば、管理クライアント２４１は、ストレージノード１００のリソースの状態を管理する管理部の一例であり、ストレージノード１００に存在してもよいし、ストレージシステム１の外部に存在してもよい。また、リクエスト制御部２０１に対するリクエストは、ストレージノード１００内の任意のプログラム、プロセス等から送信される構成であってもよい。
【００５０】
図４は、ストレージノード１００のハードウェア資源に係る構成の一例を示す図である。
【００５１】
ストレージノード１００は、一般的な汎用コンピュータ（例えば、サーバ装置）である。ストレージノード１００は、ＣＰＵ（Central Processing Unit）４１０、メモリ４２０、複数のドライブ（ＮＶＭｅ（Non-Volatile Memory Express）ドライブ４３０、ＳＡＳ（Serial Attached SCSI）ドライブ４４０、ＳＡＴＡ（Serial Advanced Technology Attachment）ドライブ４５０など）、ＨＢＡ（Host Bus Adapter）４６０、およびＮＩＣ（Network Interface Card）４７０を含んで構成される。
【００５２】
なお、ドライブは、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）の他、不揮発メモリ（ＳＣＭ（Storage Class Memory））等であってもよい。ＨＢＡ４６０は、例えば、フロントエンドネットワーク１３０向けであり、ＦＣ（Fibre Channel）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＩｎｆｉｎｉＢａｎｄなどであり、特に制限されるものではない。ＮＩＣ４７０は、例えば、バックエンドネットワーク１４０向けであり、ＦＣ、Ｅｔｈｅｒｎｅｔ、ＩｎｆｉｎｉＢａｎｄなどであり、特に制限されるものではない。
【００５３】
ストレージノード１００では、各ハードウェア資源が１つ設けられる例を示したが、各ハードウェア資源の個数は、特に限定されるものではなく、１つであってもよいし、複数であってもよい。
【００５４】
図５は、ストレージクラスタ１５０に係る論理構成の一例を示す図である。
【００５５】
ストレージクラスタ１５０は、一または複数のプロテクションドメイン１６０を含み、プロテクションドメイン１６０内には、１つ以上のプール５１０（Ｐｏｏｌ）が設けられている。プール５１０は、ストレージノード１００を跨って設けられていてもよいし、ストレージノード１００内に閉じて設けられていてもよい。また、管理の容易化のためにプール５１０が階層構造になっていてもよい。階層構造の例としては、ストレージノード１００内に閉じるプール５１０を１つ以上組み合わせて構成されてもよいし、ストレージノード１００を跨ったプール５１０とストレージノード１００内に閉じるプール５１０とを１つ以上組み合わせて構成されてもよいし、その他の構成であってもよい。
【００５６】
プール５１０の物理記憶領域は、同一のプロテクションドメイン１６０内の1つ以上のドライブ５２０または１つ以上のチャンク５３０（ドライブ５２０の物理記憶領域を分割したもの）から割り当てられる。
【００５７】
ボリューム５４０（Ｖｏｌｕｍｅ）は、プール５１０から切り出される。ボリューム５４０は、ストレージノード１００内に閉じて設けられてもよいし、ストレージノード１００を跨って設けられてもよい。
【００５８】
なお、プール５１０を定義せず、ボリューム５４０に直接１つ以上のドライブ５２０または１つ以上のチャンク５３０を割り当ててもよい。
【００５９】
ポート５５０（Ｐｏｒｔ）とボリューム５４０との関係は、多対多、多対１、１対多、１対１の何れであってもよい。また、これらの関係は、ストレージノード１００を跨っていてもよいし、ストレージノード１００内に閉じていてもよい。なお、これらの関係は、ストレージ制御ソフト２０２と構成情報とによって管理される。
【００６０】
ストレージノード１００の稼働情報の収集処理および参照処理は、上述したストレージ構成に限られるものではなく（特定のストレージ構成だけでなく）、任意のストレージ構成に適用可能である。例えば、プロテクションドメイン１６０が定義されていない構成に適用可能であり、プール５１０が設けられていない構成にも適用可能である。また、プール５１０とドライブ５２０との間にＲＡＩＤ（Redundant Arrays of Inexpensive Disks）レベルを表現する仮想的なグループを挟んだ構成にも適用可能である。
【００６１】
図６は、メモリ４２０に記憶されるデータの一例を示す図である。
【００６２】
リクエスト制御部２０１は、管理ノード１１０からのリクエスト受け付け、当該リクエストで要求される稼働情報を自装置または他のストレージノード１００から取得し、取得した稼働情報を管理ノード１１０に送信する。
【００６３】
ストレージ制御ソフト２０２は、構成情報６０１の設定、リソースの利用率などの監視、ストレージデバイスの仮想化などの機能を実現するプログラム群である。ストレージ制御ソフト２０２には、外部とのインタフェースを担うフロントエンドドライバ、ボリューム等へのＩ／Ｏを管理するコントローラドライバ、キャッシュとドライブ（物理ディスク）とのインタフェースを担うバックエンドドライバなどが含まれる。より具体的には、ストレージ制御ソフト２０２は、プール５１０、ドライブ５２０、ボリューム５４０、ポート５５０等を監視し、モニタ情報２０５のもとになる情報（ＩＯＰＳ、転送速度など）を管理する。
【００６４】
ＯＳ付属モニタプログラム２０３は、ｔｏｐコマンド、ｓａｒコマンドなどにより、モニタ情報２０５のもとになる情報（ＣＰＵ４１０の利用率、メモリ４２０の利用率など）を取得する。
【００６５】
モニタ情報収集部２０４は、１つ設けられていてもよいし、収集対象となるプログラム、プロセス、または収集対象のリソースごとに１個以上設けられていてよい。
【００６６】
構成情報６０１には、稼働情報の取得先の振分に用いられる情報が含まれる。構成情報６０１については、図７を用いて後述する。ストレージノード管理情報６０２には、ストレージノード１００の管理に用いられる情報が含まれる。ストレージノード管理情報６０２については、図８を用いて後述する。モニタ管理情報６０３には、稼働情報の収集に用いられる情報が含まれる。モニタ管理情報６０３については、図９を用いて後述する。
【００６７】
なお、モニタ情報２０５、ローカル時系列ＤＢ２０６、サマリモニタ情報２０７、サマリモニタＤＢ２０８、構成情報６０１、ストレージノード管理情報６０２、およびモニタ管理情報６０３は、メモリ４２０ではなく、ドライブ５２０に保存される構成であってもよい。
【００６８】
本実施の形態では、サマリモニタ情報２０７とサマリモニタＤＢ２０８とは、代表ノードのみが有する。なお、サマリモニタ情報２０７については、代表ノード間で複製を持ってよいし、分散して保存してもよい。構成情報６０１およびストレージノード管理情報６０２は、各ストレージノード１００が持ってもよいし、代表ノードだけが持ってもよい。
【００６９】
ストレージノード１００の機能（リクエスト制御部２０１、ストレージ制御ソフト２０２、ＯＳ付属モニタプログラム２０３、モニタ情報収集部２０４、ローカル時系列ＤＢ２０６、サマリモニタＤＢ２０８など）は、例えば、ＣＰＵ４１０がプログラムをメモリ４２０に読み出して実行すること（ソフトウェア）により実現されてもよいし、専用の回路などのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。また、ストレージノード１００の機能の一部は、ストレージノード１００と通信可能な他のコンピュータにより実現されてもよい。
【００７０】
図７から図１１を用いて、ストレージシステム１で用いられる各種情報（テーブル）について説明する。なお、テーブル形式ではなく、ＪＳＯＮ（JavaScript（登録商標） Object Notation）といった記述形式など、他の形式で値を保持する構成であってもよい。
【００７１】
図７は、構成情報６０１の一例（構成情報テーブル）を示す図である。構成情報テーブルは、リソース種別ごとに設けられる。なお、同じリソース種別でも異なるリソースＩＤ（identification）ごとに別のテーブルとしてもよい。付言するならば、リソースＩＤごとに別のテーブルとする場合、当該テーブルのリソースＩＤは不要となる。また、図７では、構成情報テーブルとして、ボリューム５４０の構成情報テーブル７０１とプール５１０の構成情報テーブル７０２とチャンク５３０の構成情報テーブル７０３とを示し、他のリソースの構成情報テーブルについては、図示を省略している。
【００７２】
構成情報テーブルには、ストレージノード１００を構成するためのリソースの情報、当該リソースの関連情報、および当該リソースの移動履歴を示す履歴情報が格納される。
【００７３】
リソースとしては、ストレージクラスタ１５０、プール５１０、ドライブ５２０、プール５１０またはボリューム５４０に物理記憶領域を割り当てるドライブ５２０内のチャンク５３０、ボリューム５４０、ポート５５０、コンピュートノード１２０（ホスト）とポート５５０とボリューム５４０とのパス等が挙げられる。
【００７４】
例えば、ボリューム５４０の構成情報テーブル７０１には、リソースの情報（リソースＩＤ、容量、および名前の情報）、リソースの関連情報（ＰＤ（Protection Domain）ＩＤ、ＰｏｏｌＩＤ、およびＮｏｄｅＩＤの情報）、および履歴情報（移動履歴）が対応付けられて格納されている。
【００７５】
リソースＩＤは、ボリューム５４０を識別可能な識別子を示す。以降、全ての識別子は、数字であってもよいし、文字列であってもよいし、数字と文字列との組合せであってもよい。容量は、ボリューム５４０に割り当てられた容量を示す。名前は、ボリューム５４０に設定された名前を示す。
【００７６】
ＰＤＩＤは、ボリューム５４０が含まれるプロテクションドメイン１６０を識別可能な識別子を示す。なお、プロテクションドメイン１６０は、複数のストレージノード１００を持つ論理区画であり、データ（稼働情報）が分散する可能性のある範囲を示す。ＰＤＩＤは、初期の環境構築時にユーザにより設定される。
【００７７】
ＰｏｏｌＩＤは、ボリューム５４０が切り出されたプール５１０を識別可能な識別子を示す。ＮｏｄｅＩＤは、ボリューム５４０が設けられるストレージノード１００を識別可能な識別子を示す。
【００７８】
移動履歴は、ボリューム５４０が過去に移動して設けられたストレージノード１００を示す。なお、移動履歴は、テーブル内の１カラムとして保持してもよいし、時刻ごとに別の構成情報テーブルとして保持してもよい。また、移動履歴は、ストレージノード１００内のボリューム５４０の移動、フェイルオーバー等により移動が発生した場合に更新される。
【００７９】
また、ボリューム５４０の構成情報テーブル７０１と同様に、プール５１０の構成情報テーブル７０２には、例えば、リソースの情報（リソースＩＤ、容量、名前などの情報）、リソースの関連情報（例えば、ＰＤＩＤ）等の情報が対応付けられて格納されている。また、例えば、チャンク５３０の構成情報テーブル７０３には、リソースの情報（リソースＩＤ、容量などの情報）、リソースの関連情報（ＰＤＩＤ、関連プールＩＤなどの情報）等の情報が対応付けられて格納されている。
【００８０】
図８は、ストレージノード管理情報６０２の一例（ストレージノード管理情報テーブル８０１）を示す図である。ストレージノード管理情報テーブル８０１には、ノードＩＤ、ＩＰアドレス（Internet Protocol Address）、役割、および状態の情報が対応付けられて格納されている。
【００８１】
ノードＩＤは、ストレージノード１００を識別可能な識別子を示す。
【００８２】
ＩＰアドレスは、通信に用いられるストレージノード１００に割り当てられる識別情報の一例である。ＩＰアドレスは、ＩＰｖ４（Internet Protocol version 4）であってもよいし、ＩＰｖ６（Internet Protocol version 6）であってもよい。また、ＩＰアドレスでなく、ＦＣで通信をするためのＷＷＮ（World Wide Name）であってもよいし、その他のプロトコルでの通信に用いられる識別情報であってもよい。
【００８３】
役割は、ストレージノード１００の役割を示す。役割としては、代表ノードの中でも管理クライアント２４１からリクエストを代表して制御する主代表ノードと主代表ノードではない副代表ノードとの区別があってもよいし、複数の代表ノードが同じ役割としてもよい（どの代表ノードがリクエストを制御してもよい）。なお、役割は、初回の環境構築時に決定されるが、主代表ノードが障害発生時に副代表ノードの中から１台が多数決、ＩＤ順などにより、主代表ノードに昇格することにより変更されてもよい。付言するならば、多数決のロジックで選出する場合、代表ノードの数は、奇数個とすることが好適である。
【００８４】
状態は、ストレージノード１００が正常に動作しているか否かの状態（正常または異常）を示す。
【００８５】
図９は、モニタ管理情報６０３の一例（モニタ管理情報テーブル９０１）を示す図である。モニタ管理情報テーブル９０１には、モニタ情報種別、リソース種別、メトリック、収集周期、構成条件、および保持期間の情報が対応付けられて格納されている。モニタ管理情報テーブル９０１は、クラスタ全体で共通で設けられてもよいし、ストレージノード１００毎に設けられてもよい。
【００８６】
モニタ情報種別は、稼働情報の種別（モニタ情報２０５「詳細」またはサマリモニタ情報２０７「サマリ」）を示す。リソース種別は、リソースの種別を示す。メトリックは、リソースの状態（例えば、稼働状態）を評価するための指標を示す。メトリックについては、リソースごとに、一または複数設定可能であり、任意のメトリックを設定可能である。
【００８７】
収集周期は、メトリックのデータ（メトリック値）を収集する周期を示す。収集周期は、固定であってもよいし、可変であってもよい。可変の場合は、ユーザまたはプログラムによって適宜に変更される。なお、例えば、収集周期を空欄にすることで、メトリック値を収集しないようにしてもよい。また、収集周期については、リソース種別の単位で設定可能な構成であってもよいし、メトリック単位で設定可能な構成であってもよいし、メトリックを複数組み合わせた集合ごとに設定可能な構成であってもよいし、構成条件の単位で設定可能な構成であってもよい。
【００８８】
構成条件は、ストレージシステム１の構成に応じて設けられる条件を示す。図９では、ストレージシステム１で設けられているボリューム５４０の個数（指標の一例）が１００個以下、１０１個以上が構成条件として設定された例が示されている。
【００８９】
ここで、構成条件は、１つの指標で規定されてもよいし、複数の指標の組み合わせで規定されてもよい。また、構成条件は、設けられなくてもよい。また、構成条件については、リソース種別の単位で設定可能な構成であってもよいし、メトリック単位で設定可能な構成であってもよいし、メトリックを複数組み合わせた集合ごとに設定可能な構成であってもよい。
【００９０】
保持期間は、収集したメトリックのデータを保持する期間を示す。例えば、サマリモニタ情報２０７の保存期間（上記代表ノードがリソース状態情報の履歴を保存する期間）は、モニタ情報２０５の保存期間（上記一般ノードが上記リソース状態情報の履歴を保存する期間）よりも長い。保持期間は、固定であってもよいし、可変であってもよい。可変の場合は、ユーザまたはプログラムによって適宜に変更される。また、保持期間については、リソース種別の単位で設定可能な構成であってもよいし、メトリック単位で設定可能な構成であってもよいし、メトリックを複数組み合わせた集合ごとに設定可能な構成であってもよいし、構成条件の単位で設定可能な構成であってもよい。
【００９１】
かかる保持期間により、モニタ情報２０５は、一定期間保持されると、モニタ情報収集部２０４によって削除される。同様に、サマリモニタ情報２１７は、一定期間保持されると、モニタ情報収集部２１４によって削除される。
【００９２】
モニタ管理情報６０３を変更する方法については、特に限定されるものではない。例えば、管理クライアント２４１からリクエスト制御部２０１経由でモニタ管理情報６０３を更新する方法であってもよいし、設定ファイルを読み込むことによりモニタ管理情報６０３を更新する方法であってもよいし、その他の方法であってもよい。
【００９３】
図１０は、モニタ情報２０５の一例（モニタ情報テーブル）を示す図である。モニタ情報テーブルについては、リソースの種別ごとに設けられる例を挙げて説明するが、これに限られるものではなく、リソースごとに設けられてもよい。なお、図１０では、モニタ情報テーブルとして、ボリューム５４０のモニタ情報テーブル１００１とプール５１０のモニタ情報テーブル１００２とを示し、他のリソースのモニタ情報テーブルについては、図示を省略している。
【００９４】
モニタ情報テーブルには、リソースＩＤ、時刻、メトリックの情報が対応付けられて格納されている。
【００９５】
リソースＩＤは、リソースを識別可能な識別子を示す。時刻は、モニタ管理情報６０３の収集周期に従って値（ストレージノード１００の時刻）が設定される。メトリックには、基本的には、モニタ管理情報６０３で設定されたメトリック値が設定される。ただし、メトリックについては、追加も削除も可能である。なお、メトリックが追加になった場合、過去の情報は、例えば、空欄とする。
【００９６】
例えば、ボリューム５４０のモニタ情報テーブル１００１には、リソースＩＤ、時刻、メトリック（ＩＯＰＳ、ＴｒａｎｓｆｅｒＲａｔｅ（転送速度）など）の情報が対応付けられて格納されている。また、プール５１０のモニタ情報テーブル１００２には、リソースＩＤ、時刻、メトリック（使用量、圧縮率など）の情報が対応付けられて格納されている。
【００９７】
図１１は、サマリモニタ情報２０７の一例（サマリモニタ情報テーブル１１０１）を示す図である。図１１では、サマリモニタ情報テーブル１１０１がストレージノード１００ごとに設けられる例を示すが、これに限られるものではなく、例えば、クラスタごとに設けられてもよい。また、メモリ使用領域を効率よく利用するために、リソースごとに別のテーブルとしてもよい。
【００９８】
サマリモニタ情報テーブル１１０１には、一般ノードから受信したサマリモニタ情報２０７、および全体情報（リソース種別ごとに、ストレージノード１００、ストレージクラスタ１５０等のまとまりで、サマリモニタ情報２０７が集約された情報）が格納される。例えば、全体情報については、一のストレージノード１００にボリューム５４０が１００個ある場合に、１００個のボリューム５４０の集約値（合計値、平均値、最大値、最小値、直近の値、最も古い値など）を１つのメトリックとして保持してよい。
【００９９】
本実施の形態では、同一時刻の全体情報の取得を容易にするために、代表ノードの時刻をキー（Ｋｅｙ）とするケースを例に挙げて説明する。より具体的には、代表ノードでは、１分間隔で時刻（タイムスタンプ）を記憶し、１分の間に一般ノードから受信したサマリモニタ情報２０７を同一の時刻のサマリモニタ情報２０７としてサマリモニタ情報２０７に格納する。この際、当該時刻ごとに、サマリモニタ情報２０７を集約して全体情報として格納する。なお、上述した構成に限られるものではなく、代表ノードは、一般ノードから受信したサマリモニタ情報２０７をそのまま記憶し、全体情報がリクエストで要求されたときに、当該リクエストで指定された時間のサマリモニタ情報２０７を特定して集約する構成であってもよい。
【０１００】
時刻には、モニタ管理情報６０３の収集周期に従って値（代表ノードの時刻）が設定される。収集周期が長いメトリックについては、前の周期と同じ値を設定してもよい。
【０１０１】
なお、リソースＩＤが異なるリソース種別間でもユニークである場合、リソース種別は設けられなくてもよい。
【０１０２】
図１２〜図１６を用いて、ストレージシステム１における各種処理を説明する。
【０１０３】
図１２は、モニタ情報収集処理に係る処理手順の一例を示す図である。以下では、モニタ情報収集処理が定期的に実行される例を挙げて説明するが、これに限られるものではなく、例えば、モニタ情報収集処理が指定時間に実行されてもよいし、その他のタイミングで実行されてもよい。
【０１０４】
ステップＳ１２０１では、モニタ情報収集部２０４は、モニタ管理情報６０３を確認（参照）する。
【０１０５】
ステップＳ１２０２では、モニタ情報収集部２０４は、モニタ管理情報６０３の構成条件を満たす収集周期を確認する。
【０１０６】
ステップＳ１２０３では、モニタ情報収集部２０４は、確認された収集周期のメトリック（特定メトリック）について、前回の取得時刻から収集周期の時間が経過したか否かを判定する。モニタ情報収集部２０４は、経過したと判定した場合、ステップＳ１２０４に処理を移し、経過していないと判定した場合、ステップＳ１２０３の処理を行う。
【０１０７】
ステップＳ１２０４では、モニタ情報収集部２０４は、ターゲットとなるプログラム（本実施の形態の例では、ストレージ制御ソフト２０２またはＯＳ付属モニタプログラム２０３）から特定メトリックのデータ（メトリック値）を取得する。なお、ターゲットとなるプログラムは、それぞれのモニタ情報２０５のソースとなる情報をＩＯ実行中に保持している。例えば、フロントエンドドライバは、ＲｅａｄＩＯカウントなどを保持している。
【０１０８】
ステップＳ１２０５では、モニタ情報収集部２０４は、取得したメトリック値をモニタ情報２０５としてローカル時系列ＤＢ２０６に保存する。この際、モニタ情報収集部２０４は、必要に応じてデータ形式を変換する。例えば、モニタ情報収集部２０４は、累積値（例えば、ＩＯカウント）を瞬時値（例えば、ＩＯＰＳ）に変換してもよい。
【０１０９】
ステップＳ１２０６では、モニタ情報収集部２０４は、全ての収集対象のメトリックのメトリック値の収集が完了したか否かを判定する。モニタ情報収集部２０４は、完了したと判定した場合、モニタ情報収集処理を終了し、完了していないと判定した場合、ステップＳ１２０３に処理を移す。
【０１１０】
なお、上述のステップＳ１２０３からステップＳ１２０６までの処理では、確認された収集周期のメトリックについてメトリック値が収集される構成を示したが、これに限られるものではなく、例えば、モニタ管理情報テーブル９０１の最初のレコードから順に処理対象とし、収集周期および構成条件を満たすメトリックのメトリック値を収集してもよいし、他の構成によりメトリック値を収集するようにしてもよい。また、定期実行間隔を、収集周期と等しくする場合は、ステップＳ１２０２およびステップＳ１２０３の処理が省略されてよい。
【０１１１】
図１３は、各ストレージノード１００で実行される第１サマリモニタ情報収集処理に係る処理手順の一例を示す図である。以下では、第１サマリモニタ情報収集処理が定期的に実行される例を挙げて説明するが、これに限られるものではなく、例えば、第１サマリモニタ情報収集処理が指定時間に実行されてもよいし、その他のタイミングで実行されてもよい。
【０１１２】
ステップＳ１３０１では、モニタ情報収集部２０４は、ストレージノード１００内の全リソースの共通のタイムスタンプ（例えば、自ストレージノード１００の現在の時刻）を確認する。
【０１１３】
ステップＳ１３０２では、モニタ情報収集部２０４は、モニタ管理情報６０３を確認（参照）する。
【０１１４】
ステップＳ１３０３では、モニタ情報収集部２０４は、モニタ管理情報６０３の構成条件を満たす収集周期を確認する。
【０１１５】
ステップＳ１３０４では、モニタ情報収集部２０４は、確認された収集周期のメトリック（特定メトリック）について、前回の取得時刻から収集周期の時間が経過したか否かを判定する。モニタ情報収集部２０４は、経過したと判定した場合、ステップＳ１３０５に処理を移し、経過していないと判定した場合、ステップＳ１３０４の処理を行う。なお、集約に用いられるメトリックの数は、集約対象（集約処理）によって異なり、一または複数となる。
【０１１６】
ステップＳ１３０５では、モニタ情報収集部２０４は、ターゲットとなるプログラムまたはローカル時系列ＤＢ２０６から特定メトリックに係るメトリック値を取得する。なお、メトリック値の取得については、ステップＳ１３０５の処理に限られるものではなく、例えば、モニタ情報収集部２０４は、後述のサマリデータの計算において、前回との差分を求める場合、例えば、前回のデータをメモリ４２０に記憶し、記憶したデータを用いるようにしてもよい。
【０１１７】
ステップＳ１３０６では、モニタ情報収集部２０４は、取得したメトリック値に基づいて、サマリデータを計算（合計値など）する。例えば、モニタ情報収集部２０４は、１秒単位の６０カウントのデータを１分単位のデータに集約する（時間単位の集約処理）。また、例えば、モニタ情報収集部２０４は、複数のリソースのメトリック値を一のリソースのメトリック値に集約する（リソース種別単位の集約処理）。
【０１１８】
ステップＳ１３０７では、モニタ情報収集部２０４は、モニタ情報収集部２０４が代表ノードに設けられていない場合、集約したメトリック値（サマリデータ）を代表ノードに送信し、モニタ情報収集部２０４が代表ノードに設けられている場合、サマリデータをサマリモニタ情報２１７としてサマリモニタＤＢ２１８に保存する。付言するならば、モニタ情報収集部２０４は、ストレージノード管理情報６０２を参照することで代表ノードを把握可能であり、代表ノードは、受信したサマリデータをサマリモニタ情報２１７としてサマリモニタＤＢ２１８に保存する。
【０１１９】
ステップＳ１３０８では、モニタ情報収集部２０４は、全ての収集対象のメトリックのメトリック値の収集が完了したか否かを判定する。モニタ情報収集部２０４は、完了したと判定した場合、第１サマリモニタ情報収集処理を終了し、完了していないと判定した場合、ステップＳ１３０４に処理を移す。
【０１２０】
なお、第１サマリモニタ情報収集処理では、各ストレージノード１００が定期的にサマリデータを送信する場合を例に挙げて説明したが、これに限られるものではなく、例えば、代表ノードの取得要求に応じて一般ノードがサマリデータを算出して送信する構成としてもよい。また、定期実行間隔を、収集周期と等しくする場合は、ステップＳ１３０３およびステップＳ１３０４の処理が省略されてよい。
【０１２１】
図１４は、代表ノード（ストレージノード２１０）で実行される第２サマリモニタ情報収集処理に係る処理手順の一例を示す図である。以下では、第２サマリモニタ情報収集処理が定期的に実行される例を挙げて説明するが、これに限られるものではなく、例えば、第２サマリモニタ情報収集処理が指定時間に実行されてもよいし、その他のタイミングで実行されてもよい。また、定期実行間隔を、収集周期と等しくする場合は、ステップＳ１４０３およびステップＳ１４０４の処理が省略されてよい。
【０１２２】
ステップＳ１４０１では、モニタ情報収集部２１４は、ストレージシステム１内の全リソースの共通のタイムスタンプ（例えば、代表ノードの現在の時刻）を確認する。
【０１２３】
ステップＳ１４０２では、モニタ情報収集部２１４は、モニタ管理情報６０３を確認（参照）する。
【０１２４】
ステップＳ１４０３では、モニタ情報収集部２１４は、モニタ管理情報６０３の構成条件を満たす収集周期を確認する。
【０１２５】
ステップＳ１４０４では、モニタ情報収集部２１４は、確認された収集周期のメトリック（特定メトリック）について、前回の取得時刻から収集周期の時間が経過したか否かを判定する。モニタ情報収集部２１４は、経過したと判定した場合、ステップＳ１４０５に処理を移し、経過していないと判定した場合、ステップＳ１４０４の処理を行う。なお、集約に用いられるメトリックの数は、集約対象（集約処理）によって異なり、一または複数となる。
【０１２６】
ステップＳ１４０５では、モニタ情報収集部２１４は、サマリモニタＤＢ２１８から特定メトリックに係るサマリモニタ情報２１７（メトリック値）を取得する。なお、メトリック値の取得については、ステップＳ１４０５の処理に限られるものではなく、例えば、モニタ情報収集部２１４は、後述のサマリデータの計算において、前回との差分を求める場合、例えば、前回のデータをメモリ４２０に記憶し、記憶したデータを用いるようにしてもよい。
【０１２７】
ステップＳ１４０６では、モニタ情報収集部２１４は、取得したメトリック値に基づいて、サマリデータ（合計値など）を計算する。例えば、モニタ情報収集部２１４は、一のクラスタに属する全ストレージノード１００のデータをクラスタ単位のデータに集約する（リソース種別単位の集約処理）。より具体的には、モニタ情報収集部２１４は、一のクラスタに属する全ストレージノード１００におけるボリューム５４０の使用容量の合計値を算出したり、一のクラスタに属する全ストレージノード１００におけるボリューム５４０のＩＯＰＳの合計値を算出したりする。
【０１２８】
ステップＳ１４０７では、モニタ情報収集部２１４は、集約したメトリック値（サマリデータ）をサマリモニタ情報２１７としてサマリモニタＤＢ２１８に保存する。
【０１２９】
ステップＳ１４０８では、モニタ情報収集部２１４は、全ての収集対象のメトリックのメトリック値の収集が完了したか否かを判定する。モニタ情報収集部２１４は、完了したと判定した場合、第２サマリモニタ情報収集処理を終了し、完了していないと判定した場合、ステップＳ１４０４に処理を移す。
【０１３０】
図１５は、代表ノード（ストレージノード２１０）で実行されるリクエスト応答処理に係る処理手順の一例を示す図である。リクエスト応答処理は、代表ノードのリクエスト制御部２１１が管理ノード１１０からリクエストを受け付けたことに基づいて実行される。
【０１３１】
ステップＳ１５０１では、リクエスト制御部２１１は、管理ノード１１０からリクエストを受け付ける。
【０１３２】
ステップＳ１５０２では、リクエスト制御部２１１は、リクエストのみで稼働情報の取得先がサマリモニタＤＢ２１８であるか否かを判定する。リクエスト制御部２１１は、リクエストのみで稼働情報の取得先がサマリモニタＤＢ２１８であると判定できた場合、ステップＳ１５０３に処理を移し、リクエストのみで稼働情報の取得先がサマリモニタＤＢ２１８であると判定できなかった場合、ステップＳ１５０４に処理を移す。
【０１３３】
例えば、リクエスト制御部２１１は、リクエスト内に時刻もリソースＩＤも指定されていない場合、現在の最新の全リソースのサマリモニタ情報２１７が要求されていると判断し、リクエストのみで稼働情報の取得先がサマリモニタＤＢ２１８であると判定する。
【０１３４】
また、例えば、リクエスト制御部２１１は、リクエスト内にリソースＩＤが指定されているが、時刻が指定されていない場合、かつ、要求対象がモニタ情報２０５であることが明示的に指定されていない場合、現在の最新の指定されたリソースのサマリモニタ情報２１７が要求されていると判断し、リクエストのみで稼働情報の取得先がサマリモニタＤＢ２１８であると判定する。
【０１３５】
ステップＳ１５０３では、リクエスト制御部２１１は、サマリモニタＤＢ２１８に問い合わせ、リクエストで要求されている稼働情報を取得し、ステップＳ１５０９に処理を移す。
【０１３６】
このように、代表ノードは、第２記憶部（例えば、サマリモニタＤＢ２１８、サマリモニタ情報テーブル１１０１、メモリ４２０、ドライブ）に記憶された集計情報（例えば、サマリモニタ情報２１７）をリクエストにおいて要求していると判定した場合、第２記憶部から集計情報を取得して管理部（例えば、管理ノード１１０、管理クライアント２４１、ストレージノード１００内の任意のプログラム、プロセス）に送信する。
【０１３７】
この際、集計情報が管理部から要求される頻度が相対的に高い情報である場合、上記構成によれば、構成情報６０１の確認をすることなく、リクエストの解析により取得先を決定することができるので、リクエストに対する応答性能を高めることができる。
【０１３８】
より広義には、代表ノードは、上記第２記憶部から上記リクエストにかかるリソース状態情報を取得可能か判断し、取得不可と判断した場合に、上記一般ノードの第１記憶部からリソース状態情報を取得することを特徴とする。かかる構成によれば、第２記憶部からリソース状態情報を優先して取得することができるので、リクエストに対する応答性能を高めることができる。
【０１３９】
ステップＳ１５０４では、リクエスト制御部２１１は、振分情報２１９（構成情報６０１など）を参照する。
【０１４０】
ステップＳ１５０５では、リクエスト制御部２１１は、取得先詳細決定処理を行う。なお、取得先詳細決定処理については、図１６を用いて後述するが、取得先詳細決定処理では、リクエストで要求されている稼働情報の取得先のストレージノード１００が決定される。
【０１４１】
ステップＳ１５０６では、リクエスト制御部２１１は、稼働情報の取得先がサマリモニタＤＢ２１８であるか否かを判定する。リクエスト制御部２１１は、稼働情報の取得先がサマリモニタＤＢ２１８であると判定した場合、ステップＳ１５０３に処理を移し、稼働情報の取得先がサマリモニタＤＢ２１８でないと判定した場合、ステップＳ１５０７に処理を移す。
【０１４２】
ステップＳ１５０７では、リクエスト制御部２１１は、稼働情報の取得先として決定した一または複数のストレージノード１００（決定ノード）のリクエスト制御部２０１にリクエストで要求されている稼働情報を問い合わせる。なお、問い合わせを受けたリクエスト制御部２０１は、リクエストで要求されている稼働情報をローカル時系列ＤＢ２０６に問い合わせ、ローカル時系列ＤＢ２０６から取得した稼働情報を代表ノード（リクエスト制御部２１１）に送信する。
【０１４３】
ステップＳ１５０８では、リクエスト制御部２１１は、リクエストで要求されている稼働情報を決定ノードから取得し、ステップＳ１５０９に処理を移す。
【０１４４】
ステップＳ１５０９では、リクエスト制御部２１１は、取得した稼働情報を整形する。
【０１４５】
ステップＳ１５１０では、リクエスト制御部２１１は、リクエストを送信した管理ノード１１０に、整形した稼働情報を送信（レスポンス返却）し、リクエスト応答処理を終了する。
【０１４６】
図１６は、取得先詳細決定処理に係る処理手順の一例を示す図である。
【０１４７】
ステップＳ１６０１では、リクエスト制御部２１１は、リクエストにおいて詳細情報（モニタ情報２０５）が明示的に要求されているか否かを判定する。リクエスト制御部２１１は、詳細情報が明示的に要求されていると判定した場合、ステップＳ１６０２に処理を移し、詳細情報が明示的に要求されていないと判定した場合、ステップＳ１６０６に処理を移す。
【０１４８】
ステップＳ１６０２では、リクエスト制御部２１１は、構成情報６０１に基づいて、指定されているリソースについて移動履歴に値が格納されているか否か（移動履歴がわかっているか否か）を判定する。リクエスト制御部２１１は、移動履歴に値が格納されていると判定した場合、ステップＳ１６０３に処理を移し、移動履歴に値が格納されていないと判定した場合、ステップＳ１６０４に処理を移す。
【０１４９】
ステップＳ１６０３では、リクエスト制御部２１１は、移動履歴に基づいて、リソースが存在していたストレージノード１００（群）を特定し、ステップＳ１６０５に処理を移す。
【０１５０】
このように、代表ノードは、リクエストを解析し、管理部から所定のリソース状態情報（例えば、モニタ情報２０５）が要求されているか否かを判定し、所定のリソース状態情報が要求されていると判定したとき、履歴情報（例えば、構成情報６０１の移動履歴）に基づいて、所定のリソース状態情報に係るリソースが設けられていた一般ノード（要求されているリソース状態情報を保持する一般ノード）を特定する。かかる特定により、リソース状態情報の取得先を適切に絞ることができるので、不要な問い合わせによるストレージノード１００への負荷をなくすとともに、リクエストに対する応答性能を高めることができる。
【０１５１】
ステップＳ１６０４では、リクエスト制御部２１１は、プロテクションドメイン１６０、チャンク５３０等の関係に基づいて、リソースが存在していた可能性のあるストレージノード１００（群）を特定し、ステップＳ１６０５に処理を移す。
【０１５２】
このように、代表ノードは、リクエストを解析し、管理部から所定のリソース状態情報（例えば、モニタ情報２０５）が要求されているか否かを判定し、所定のリソース状態情報が要求されていると判定したとき、範囲情報（例えば、構成情報６０１）に基づいて、所定のリソース状態情報に係るリソースが移動し得る範囲の一般ノードを特定する。かかる特定により、リソース状態情報の取得先をある程度絞ることができるので、取得先を絞らない場合と比べて、不要な問い合わせによるストレージノード１００への負荷が減るとともに、リクエストに対する応答性能を高めることができる。
【０１５３】
より広義には、上記代表ノードは、上記一般ノードからリソース状態情報を取得する場合、リソース状態情報の対象となるリソースが上記複数の一般ノードの何れかに設けられかを示す履歴情報または上記リソースが移動しうる範囲を示す範囲情報と基づいて、上記一般ノードを特定してリソース状態情報の取得を行うことを特徴とする。
【０１５４】
ステップＳ１６０５では、リクエスト制御部２１１は、特定したストレージノード１００（群）に問い合わせると決定し、取得先詳細決定処理を終了する。
【０１５５】
ステップＳ１６０６では、リクエスト制御部２１１は、ストレージノード１００から稼働情報を取得するか否かを判定する。リクエスト制御部２１１は、ストレージノード１００から稼働情報を取得すると判定した場合、ステップＳ１６０２に処理を移し、ストレージノード１００から稼働情報を取得しないと判定した場合、ステップＳ１６０７に処理を移す。
【０１５６】
例えば、リクエスト制御部２１１は、リクエスト内で指定されたリソースの数が一定数よりも少ない場合、ストレージノード１００から稼働情報を取得すると判定してもよい。この場合、一定数は、状況によって異なってもよい。例えば、取得するモニタ情報２０５のカウント数と問い合わせるストレージノード１００数との多寡（比率）を比較して決定してもよいし、時刻をキーとするデータをリソースごとに参照する応答性能を測定しておいて、問い合わせるストレージノード１００数と応答性能と比較して決定してもよい。
【０１５７】
なお、過去にボリューム５４０がストレージノード１００間を移動している可能性があるため、移動履歴を見て複数のストレージノード１００に問い合わせる場合もある（ステップＳ１６０３参照）。また、メモリサイズの問題で移動履歴を保持しきれない場合、移動の可能性のあるプロテクションドメイン１６０内のストレージノード１００全て、または関連のあるチャンク５３０のあるストレージノード１００全てというように、移動履歴がなくても複数問い合わせることがある（ステップＳ１６０４参照）。
【０１５８】
また、例えば、リクエスト制御部２１１は、リクエスト内で指定されたリソースの数が一定数よりも多い場合、サマリモニタＤＢ２１８から稼働情報を取得すると判定してもよい。
【０１５９】
稼働情報の履歴が指定されている場合は、各ストレージノード１００に問い合わせるのが通常であるが、ある一定個数以上同時に指定されると、代表ノードにあるサマリモニタＤＢ２１８が持つ、時刻をキーに持つサマリモニタ情報２１７を参照した方が参照処理の効率がよくなる。例えば、取得する稼働情報の時刻のカウント数が１０００より多いときは、１０００のストレージノード１００に問い合わせるよりも、サマリモニタＤＢ２１８の持つサマリモニタ情報２１７を参照して返した方が速い場合があり、その場合は、リクエスト制御部２１１は、サマリモニタＤＢ２１８から返すと判断する。
【０１６０】
このように、上記代表ノードは、上記一般ノードからリソース状態情報を取得するとした場合に取得を行う上記一般ノードの数に基づいて、上記一般ノードまたは上記第２記憶部のいずれからリソース状態情報を取得するかを決定する。
【０１６１】
ステップＳ１６０７では、リクエスト制御部２１１は、サマリモニタＤＢ２１８に問い合わせると決定し、取得先詳細決定処理を終了する。
【０１６２】
このように、代表ノードは、リクエストを解析し、第１記憶部（例えば、ローカル時系列ＤＢ２０６、モニタ情報テーブル、メモリ４２０、ドライブ）に記憶されたリソース状態情報を要求する指定がリクエストにないと判定した場合、一般ノードの応答性能に基づいて、第１記憶部からリソース状態情報を取得するか、第２記憶部から集計情報を取得するかを決定する。かかる構成では、取得にかかる処理が速い方が取得先として決定されるので、リクエストに対する応答性能を高めることができる。
【０１６３】
上述した第１の実施の形態では、例えば、ストレージシステムは、代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムであって、上記一般ノードは、その第１記憶部に、自身の上記複数のリソースの各々の状態を示すリソース状態情報を記憶し、上記代表ノードは、その第２記憶部に、上記複数の一般ノードから収集したリソース状態情報を記憶し、受信したリクエストに基づいて、上記一般ノードの第１記憶部からリソース状態情報を取得するか、上記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を上記リクエストの発行元に送信することを特徴とする。
【０１６４】
上述した構成では、リソース状態情報を一般ノードに保持し、一般ノードから収集したリソース状態情報を代表ノードに保持し、受信したリクエストに基づいて取得先を変更することで、代表ノードに必要となるディスク容量を低減し、かつ、ストレージシステム全体のＣＰＵの負荷を低減することができる。
【０１６５】
また、上述した構成によれば、例えば、管理する一般ノードが増えた場合であっても、各一般ノードのリソース状態情報を適切に管理することができる。
【０１６６】
（２）第２の実施の形態
ストレージシステムが大規模になる（管理するストレージノードの数が多い）と、一の代表ノードで管理ノードからのリクエストに対する全てのリクエスト受信時処理を行うと、応答性能が劣化する問題がある。この点、本実施の形態では、主代表ノードと副代表ノードとでリクエスト受信時処理を分担し、応答性能を向上する。
【０１６７】
本実施の形態では、代表ノードとして、主代表ノードと副代表ノードとが設けられ、各代表ノードで担当するストレージノードの範囲が定められている点が、第１の実施の形態と主に異なる。
【０１６８】
図１７〜図１９を用いて、本実施の形態を説明する。なお、第１の実施の形態の構成と同じ構成については、同じ符号を用いてその説明を適宜省略する。
【０１６９】
図１７は、本実施の形態におけるストレージシステム２に係る構成の一例を示す図である。ストレージシステム２は、ストレージノード１７１０（主代表ノード）、ストレージノード２１０（副代表ノード）、ストレージノード２２０（一般ノード）などを含んで構成される。
【０１７０】
主代表ノードであるストレージノード１７１０は、管理ノード１１０からリクエストを受け付けたり、副代表ノードにリクエストを転送したりするリクエスト制御部１７１１と、担当する一般ノードのストレージノード２２０が規定されたストレージノード管理情報１７１２とを備える。なお、ストレージノード管理情報１７１２については、図１８を用いて後述する。また、リクエスト制御部１７１１については、図１９を用いて後述する。
【０１７１】
主代表ノードは、リクエストの受信時に、例えば、副代表ノードにリクエストを転送する。副代表ノードは、リクエストを受信すると、自身の担当する範囲内で第１の実施形態の代表ノードと同様の処理を実施する。
【０１７２】
＜稼働情報の参照手順＞
稼働情報の主な参照手順について説明する。
（手順１）
主代表ノードのリクエスト制御部１７１１は、管理ノード１１０の管理クライアント２４１からのリクエストを受け付ける。
【０１７３】
（手順２）
主代表ノードのリクエスト制御部１７１１は、ストレージノード管理情報１７１２に基づいて、代表ノードの情報を取得する。
【０１７４】
（手順３）
主代表ノードのリクエスト制御部１７１１は、リクエストの内容に基づいて、副代表ノードにリクエストを転送する。
【０１７５】
（手順４）
各代表ノードのリクエスト制御部２１１，１７１１は、振分情報２１９に基づいて稼働情報の取得先の振分に必要な情報を取得する。
【０１７６】
（手順５）
各代表ノードのリクエスト制御部２１１，１７１１は、リクエストの内容と振分情報２１９とに基づいて、問い合わせるストレージノード１００と、返すべき稼働情報とを判断する。
【０１７７】
（手順６）
各代表ノードのリクエスト制御部２１１，１７１１は、問い合わせるべきストレージノード１００に必要な稼働情報を問い合わせる。なお、リクエスト制御部２１１，１７１１は、各ストレージノード１００への問い合わせは一度に送出してもよいし、何度かに分割して送出してもよい。
【０１７８】
（手順７）
サマリモニタＤＢ２１８または各ストレージノード１００により、必要な稼働情報が取得される。
【０１７９】
（手順８）
主代表ノードのリクエスト制御部１７１１は、必要な稼働情報を受け取る。
【０１８０】
（手順９）
主代表ノードのリクエスト制御部１７１１は、集めた稼働情報を整形し、管理クライアント２４１に返す。
【０１８１】
図１８は、ストレージノード管理情報１７１２の一例（ストレージノード管理情報テーブル１８０１）を示す図である。ストレージノード管理情報テーブル１８０１では、ストレージノード管理情報６０２の情報に加えてフォールトセットの情報が対応付けられて格納されている。
【０１８２】
フォールトセットは、同時に障害が発生してもストレージシステム２全体が停止しないストレージノード１００の集合を示す識別情報である。例えば、同一のラック、同じ電源、同じスイッチを利用するストレージノード１００群に、同じフォールトセットが対応付けられる。フォールトセットが同じストレージノード１００群は、各代表ノードが担当する範囲となる。なお、フォールトセットは、例えば、初回の環境構築時に設定される。
【０１８３】
本実施の形態では、フォールトセットごとに代表ノードが設定される。複数の代表ノードのうちの１つが主代表ノードとして設定され、残りが副代表ノードとして設定される。
【０１８４】
代表ノードの担当範囲については、上述したフォールトセットを用いるものに限られるものではない。例えば、フォールトセットのように固定されるものではなく、担当範囲の設定が動的に変更される構成（例えば、ストレージノード１００の数に応じて、代表ノードおよび一般ノードの数が決定され、代表ノードに属する一般ノードを識別可能な識別情報が動的に割り振られる等）であってもよい。
【０１８５】
図１９は、リクエスト制御部１７１１によるリクエスト受信時処理に係る処理手順の一例を示す図である。リクエスト受信時処理は、主代表ノードのリクエスト制御部１７１１が管理ノード１１０からリクエストを受け付けたことに基づいて実行される。
【０１８６】
ステップＳ１９０１では、リクエスト制御部１７１１は、管理ノード１１０からリクエストを受け付ける。
【０１８７】
ステップＳ１９０２では、リクエスト制御部１７１１は、リクエストの内容とストレージノード管理情報１７１２とに基づいて、副代表ノードにリクエストを転送する。例えば、リクエスト制御部１７１１は、リクエストの内容を解析し、特定のボリューム５４０の指定された時間内の稼働情報を要求するものであったと判定した場合、振分情報２１９に基づいて特定のボリューム５４０が設けられるストレージノード２２０を特定し、ストレージノード管理情報１７１２に基づいて、特定したストレージノード２２０を担当する副代表ノードを特定し、特定した副代表ノードにリクエストを転送する。なお、副代表ノードにリクエストを転送しない場合については、第１の実施の形態と同様であるので、図示および説明を省略する。
【０１８８】
ステップＳ１９０３では、リクエスト応答処理が行われる。なお、リクエスト応答処理は、図１５に示した処理と基本的に同様であり、リクエストの送信元および送信先が管理ノード１１０ではなく、主代表ノードとなる。
【０１８９】
ステップＳ１９０４では、リクエスト制御部１７１１は、各副代表ノードから返却された稼働情報を整形する。
【０１９０】
ステップＳ１９０５では、リクエスト制御部１７１１は、管理ノード１１０に整形した稼働情報を送信し、リクエスト受信時処理を終了する。
【０１９１】
上述した第２の実施の形態において、例えば、ストレージシステムでは、上記主代表ノードは、上記受信したリクエストの対象となっている一般ノードを特定し、上記代表ノードと一般ノードの管理関係を規定した管理情報（例えば、ストレージノード管理情報１７１２）に基づき、上記特定した一般ノードを管理する代表ノードを特定して、上記特定された代表ノードにリクエストを取得させ、上記特定された代表ノードは、上記リクエストを取得して、上記一般ノードからリソース状態情報を取得するか、上記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を上記リクエストの発行元に送信することを特徴とする。
【０１９２】
上述した構成では、複数の代表ノードでリクエスト応答処理が分担されるので、リクエスト応答処理にかかる負荷を分散させることができる。
【０１９３】
また、上述した構成では、例えば、管理する一般が増えた場合であっても、代表ノードで担当する一般ノードを制限することで、代表ノードの負荷を高めることなく、各一般ノードのリソース状態情報を適切に管理することができる。
【０１９４】
なお、本実施の形態では、代表ノードは、共通の振分情報２１９を備える構成を例に挙げて説明したが、これに限られるものではない。例えば、各代表ノードは、分担する範囲の振分情報（構成情報）を備えるようにしてもよい。かかる構成によれば、振分情報の情報量を少なくすることができるので、稼働情報を問い合わせる一般ノードの特定（検索）にかかる時間を低減することができる。
【０１９５】
（３）第３の実施の形態
ストレージシステムが大規模になる（管理するストレージノードの数が多い）と、一の代表ノードで管理ノードからのリクエストに対する全てのリクエスト応答処理を行うと、応答性能が劣化する問題がある。この点、本実施の形態では、主代表ノードが副代表ノードの状態に応じてリクエスト応答処理を分担させ、応答性能を向上する。
【０１９６】
副代表ノードの状態については、副代表ノードが最新の状態であるか否か、副代表ノードの処理負荷が高いか否か等、様々な状態が想定される。以下では、主代表ノードは、副代表ノードが有する構成情報のバージョン（どの時点の構成情報を有しているか否か、最新の構成情報を有しているか否か等）を判定し、副代表ノードにリクエストを転送して処理を分担させる構成を例に挙げて説明する。
【０１９７】
図２０〜図２２を用いて、本実施の形態を説明する。なお、第１の実施の形態の構成と同じ構成については、同じ符号を用いてその説明を適宜省略する。
【０１９８】
図２０は、本実施の形態におけるストレージシステム３に係る構成の一例を示す図である。ストレージシステム３は、ストレージノード２０１０（主代表ノード）と、ストレージノード２０２０（副代表ノード）と、ストレージノード２２０（一般ノード）とを含んで構成される。
【０１９９】
主代表ノードであるストレージノード２０１０は、リクエスト制御部２０１１、ストレージ制御ソフト２０１２、ＯＳ付属モニタプログラム２０１３、モニタ情報収集部２０１４、モニタ情報２０１５、ローカル時系列ＤＢ２０１６、サマリモニタ情報２０１７、サマリモニタＤＢ２０１８、第１振分情報２０１９Ａ、および第２振分情報２０１９Ｂを含んで構成される。なお、主代表ノードの構成要素２０１２〜２０１８については、第１の実施の形態の代表ノードの構成要素２１２〜２１８と同様であるので、その説明を省略する。
【０２００】
リクエスト制御部２０１１は、管理ノード１１０からのリクエストを受信すると、第１振分情報２０１９Ａに基づいて稼働情報の取得先の副代表ノードを選択し、選択した副代表ノードにリクエストを転送する。なお、リクエスト制御部２０１１は、取得先として副代表ノードを選択しない場合、受信したリクエストの内容と第２振分情報２０１９Ｂとに基づいて、稼働情報を取得するストレージノード１００と返すべき稼働情報とを判断する。
【０２０１】
ここで、第１振分情報２０１９Ａは、代表ノードの状態を示すノード状態情報の一例であり、管理ノード１１０からのリクエストの振分に用いられる情報である。より具体的には、第１振分情報２０１９Ａは、代表ノードの負荷を分散するために、どの代表ノードにリクエストを振り分ければよいかを判断するための情報である。例えば、第１振分情報２０１９Ａは、第２振分情報２０１９Ｂ（例えば、構成情報６０１）が同期された時間を含む情報（例えば、後述のストレージノード管理情報）である。ストレージノード管理情報の一例については、図２１に示す。
【０２０２】
第２振分情報２０１９Ｂは、稼働情報の場所の特定に用いられる情報である。例えば、第２振分情報２０１９Ｂは、振分情報２１９と同様の情報であり、主代表ノードおよび副代表ノード間で同期（複製）される。
【０２０３】
副代表ノードであるストレージノード２０２０は、リクエスト制御部２０２１、ストレージ制御ソフト２０２２、ＯＳ付属モニタプログラム２０２３、モニタ情報収集部２０２４、モニタ情報２０２５、ローカル時系列ＤＢ２０２６、および第２振分情報２０２７を含んで構成される。なお、副代表ノードの構成要素２０２１〜２０２６については、第１の実施の形態の代表ノードの構成要素２１１〜２１６と同様であるので、その説明を省略する。
【０２０４】
第２振分情報２０２７は、第２振分情報２０１９Ｂが同期（複製）されたものである。リクエスト制御部２０２１は、転送されたリクエストの内容と第２振分情報２０２７とに基づいて、稼働情報を取得するストレージノード１００と返すべき稼働情報とを判断する。
【０２０５】
なお、主代表ノードのリクエスト制御部２０１１と、副代表ノードのリクエスト制御部２０２１と、一般ノードのリクエスト制御部２２１とは、同じプログラムで実現されてもよいし、異なるプログラムで実現されてもよい。
【０２０６】
＜稼働情報の参照手順＞
稼働情報の主な参照手順について説明する。
（手順１）
主代表ノードのリクエスト制御部２０１１は、管理ノード１１０の管理クライアント２４１からのリクエストを受け付ける。
【０２０７】
（手順２）
主代表ノードのリクエスト制御部２０１１は、リクエストの振分に用いる第１振分情報２０１９Ａを取得する。
【０２０８】
（手順３）
主代表ノードのリクエスト制御部２０１１は、第１振分情報２０１９Ａに基づいて、リクエストの振分先の代表ノード（自身または副代表ノード）を選択する。
【０２０９】
（手順４）
主代表ノードのリクエスト制御部２０１１は、選択した代表ノードが副代表ノードである場合、当該副代表ノードにリクエストを転送する。
【０２１０】
（手順５）
各代表ノード（例えば、リクエスト制御部２０１１，２０２１）は、稼働情報の取得に用いる第２振分情報（例えば、第２振分情報２０１９Ｂ，２０２７）を取得する。
【０２１１】
（手順６）
各代表ノード（例えば、リクエスト制御部２０１１，２０２１）は、第２振分情報（例えば、第２振分情報２０１９Ｂ，２０２７）に基づいて、稼働情報の取得先の振分に必要な情報を取得する。
【０２１２】
（手順７）
各代表ノード（例えば、リクエスト制御部２０１１，２０２１）は、リクエストの内容と第２振分情報（例えば、第２振分情報２０１９Ｂ，２０２７）とに基づいて、問い合わせるストレージノード１００と、返すべき稼働情報とを判断する。
【０２１３】
（手順８）
各代表ノード（例えば、リクエスト制御部２０１１，２０２１）は、問い合わせるべきストレージノード１００に必要な稼働情報を問い合わせる。なお、リクエスト制御部２０１１，２０２１は、各ストレージノード１００への問い合わせは一度に送出してもよいし、何度かに分割して送出してもよい。
【０２１４】
（手順９）
サマリモニタＤＢ２０１８または各ストレージノード１００により、必要な稼働情報が取得される。
【０２１５】
（手順１０）
主代表ノードのリクエスト制御部２０１１は、必要な稼働情報を受け取る。
【０２１６】
（手順１１）
主代表ノードのリクエスト制御部２０１１は、集めた稼働情報を整形し、管理クライアント２４１に返す。
【０２１７】
図２１は、ストレージノード管理情報の一例（ストレージノード管理情報テーブル２１０１）を示す図である。
【０２１８】
ストレージノード管理情報テーブル２１０１には、ストレージノード管理情報６０２に加えて、構成情報同期時刻の情報が対応付けられて格納されている。
【０２１９】
構成情報同期時刻は、代表ノード間で構成情報６０１（第２振分情報２０１９Ｂ，２０２７）が同期される時刻を示す。
【０２２０】
ここで、最新の稼働情報を取得するリクエストがきている場合、構成情報６０１の同期時刻が最新である必要があるが、過去の稼働情報を取得するリクエストがきている場合、構成情報６０１の同期時刻が古い時刻であっても、当該過去よりも新しい時刻であれば問題ない。なお、構成情報６０１が最新であるときは、何れのリクエストの場合でも問題ない。つまり、各代表ノードが保持する構成情報６０１が同期された時刻に基づいて、リクエストの振分処理が可能となる。
【０２２１】
ここで、リクエストの振分処理に用いられる情報は、構成情報同期時刻の情報に限られるものではなく、ストレージノード１００のＣＰＵ４１０の負荷など、ストレージノード１００のリソースの使用量などを採用してもよい。なお、リクエストの振分処理に用いられる情報は、主代表ノードにより定期的に各副代表ノードに問い合わせて更新される構成であってもよいし、各副代表ノードから主代表ノードに情報が送信されて更新される構成であってもよいし、記録媒体を介して更新される構成であってもよい。
【０２２２】
図２２は、リクエスト制御部２０１１によるリクエスト受信時処理に係る処理手順の一例を示す図である。リクエスト受信時処理は、主代表ノードのリクエスト制御部２０１１が管理ノード１１０からリクエストを受け付けたことに基づいて実行される。
【０２２３】
ステップＳ２２０１では、リクエスト制御部２０１１は、管理ノード１１０からリクエストを受け付ける。
【０２２４】
ステップＳ２２０２では、リクエスト制御部２０１１は、リクエストの条件を満たす副代表ノードが存在するか否かを判定する。例えば、リクエスト制御部２０１１は、最新の稼働情報を取得するリクエストであると判断した場合、最新の構成情報６０１（主代表ノードと同じ更新日時の構成情報６０１）を有する副代表ノードが存在するか否かを判定する。また、例えば、リクエスト制御部２０１１は、過去の稼働情報を取得するリクエストであると判断した場合、当該過去よりも新しい更新日時の構成情報６０１を有する副代表ノードが存在するか否かを判定する。
【０２２５】
リクエスト制御部２０１１は、リクエストの条件を満たす副代表ノードが存在すると判定した場合、ステップＳ２２０３に処理を移し、リクエストの条件を満たす副代表ノードが存在しないと判定した場合、ステップＳ２２０６に処理を移す。
【０２２６】
ステップＳ２２０３では、リクエスト制御部２０１１は、リクエストの条件を満たす副代表ノードを１つ選択し、選択した副代表ノードにリクエストを転送する。
【０２２７】
ステップＳ２２０４では、リクエスト制御部２０１１は、リクエスト応答処理が行われる。なお、リクエスト応答処理は、図１５に示した処理と基本的に同様であり、リクエストの送信元および送信先が管理ノード１１０ではなく、主代表ノードとなる。
【０２２８】
ステップＳ２２０５では、リクエスト制御部２０１１は、各副代表ノードから返却された稼働情報を整形する。
【０２２９】
ステップＳ２２０６では、リクエスト制御部２０１１は、リクエスト応答処理を行う。なお、リクエスト応答処理は、図１５に示した処理と基本的に同様であるので、その説明を省略する。
【０２３０】
ステップＳ２２０７では、リクエスト制御部２０１１は、管理ノード１１０に整形した稼働情報を送信し、リクエスト受信時処理を終了する。
【０２３１】
上述した第３の実施の形態において、例えば、ストレージシステムでは、上記主代表ノードは、上記主代表ノードおよび上記副代表ノードの状態を示すノード状態情報（例えば、構成情報同期時刻の情報、主代表ノードおよび副代表ノードのＣＰＵの使用率）に基づいて、上記リクエストを上記特定された代表ノードである副代表ノードに処理させるか否かを判定し、上記処理させると判定した場合、上記副代表ノードに上記リクエストを転送することを特徴とする。
【０２３２】
上述した構成によれば、主代表ノードおよび副代表ノード間で構成情報（第２振分情報）の同期に時間を要する場合に、整合性を持って処理をするために、各代表ノード間の同期具合（同期時刻）を加味し、リクエストを振り分けることができる。
【０２３３】
また、代表ノードの状態をリソースの状態とする場合には、代表ノード間で処理負荷に差があるときに、リソースにかかる負荷を加味し、例えば、負荷が最も低い代表ノードにリクエストを振り分けることができる。
【０２３４】
本実施の形態によれば、代表ノードの状態に応じてリクエスト応答処理を行うことができるので、リクエストに対する応答性能を高めることができる。
【０２３５】
（４）第４の実施の形態
大規模なストレージシステムにおいて、稼働情報を時系列に常に保存すると、ディスクの使用量が膨大になる問題がある。この点、本実施の形態では、ディスクの使用量を削減するために、常に記憶するのではなく、問題があると考えられる場合に稼働情報を記憶する。
【０２３６】
図２３および図２４を用いて、本実施の形態を説明する。なお、第１の実施の形態の構成と同じ構成については、同じ符号を用いてその説明を適宜省略する。
【０２３７】
図２３は、モニタ管理情報の一例（モニタ管理情報テーブル２３０１）を示す図である。モニタ管理情報テーブル２３０１には、モニタ管理情報６０３に加えて、閾値上限および閾値下限の情報が対応付けられて格納されている。
【０２３８】
リソースのメトリック値が閾値を超えた場合（リソースのメトリック値が閾値上限を上回った場合、または、リソースのメトリック値が閾値下限を下回った場合）、当該メトリック値がモニタ情報２０５としてローカル時系列ＤＢ２０６に記憶される処理が行われる。
【０２３９】
閾値上限および／または閾値下限は、固定であってもよいし、可変であってもよいし、ユーザにより設定されてもよいし、プログラムにより自動で変更されてもよい。例えば、自動で変更する例としては、ベースライン監視のように一定時間の傾向を取得してプログラムが通常状態を学習し、通常状態の範囲を閾値上限および閾値下限と設定する方法が挙げられる。また、閾値上限および閾値下限の両方が設けられる構成を例に挙げて説明するが、これに限られるものではなく、閾値上限または閾値下限の何れか１つが設けられる構成であってもよい。
【０２４０】
図２４は、本実施の形態におけるモニタ情報収集処理に係る処理手順の一例を示す図である。図１２に示すモニタ情報収集処理と同じ処理には、同じ符号を用いて、その説明を省略する。
【０２４１】
ステップＳ２４０１では、モニタ情報収集部２０４は、取得したメトリック値が閾値を超えるか否か（上限閾値を上回るか否かと閾値下限を下回るか否かと）を判定する。モニタ情報収集部２０４は、取得したメトリック値が閾値を超えると判定した場合、ステップＳ２４０２に処理を移し、取得したメトリック値が閾値を超えないと判定した場合、ステップＳ１２０６に処理を移す。
【０２４２】
ステップＳ２４０２では、モニタ情報収集部２０４は、構成情報６０１に基づいて、取得したメトリック値のメトリックに関連するリソース（関連リソース）があるか否かを判定する。モニタ情報収集部２０４は、関連リソースがあると判定した場合、ステップＳ２４０３に処理を移し、関連リソースがないと判定した場合、ステップＳ１２０５に処理を移す。関連リソースとは、パスが張られている一連のリソースのことをいう。
【０２４３】
ステップＳ２４０３では、モニタ情報収集部２０４は、関連リソースのメトリック値を取得し、ステップＳ１２０５に処理を移す。
【０２４４】
このように、メトリック値が閾値を超えるときに、当該メトリックを単純に保存するだけでなく、ストレージシステムでは関連リソースに問題がある可能性があるため、関連リソースのメトリック値が閾値を超えていなくても保存する。付言するならば、関連リソースのメトリック値を取得することで、例えば、ボリューム５４０の異常が確認されたとき、プール５１０、ドライブ５２０、ポート５５０などのリソースのメトリック値を全て付き合わせることで、ストレージシステムとしての異常を把握できるようになる。
【０２４５】
なお、サマリモニタ情報２１７についても上述の内容と同様であるので、図示およびその説明を省略する。
【０２４６】
また、メトリック値が閾値を超えなくなっても、一定期間（例えば、数分）、メトリック値を保存するように構成してもよい。
【０２４７】
本実施の形態によれば、リソース状態情報が閾値を超える場合にリソース状態情報を記憶するので、ディスクの使用量を削減することができる。
【０２４８】
（５）他の実施の形態
なお上述の実施の形態においては、本発明をストレージシステムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、ストレージ装置、情報管理方法に広く適用することができる。
【０２４９】
また、上記の説明において各機能を実現するプログラム、テーブル、ファイル等の情報は、他のコンピュータ、メモリ、ハードディスク、ＳＳＤ等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０２５０】
また、上述した構成については、本発明の要旨を超えない範囲において、適宜に、変更したり、組み替えたり、組み合わせたり、省略したりしてもよい。
【０２５１】
上述した構成によれば、リソース状態情報を適切に管理することで、例えば、ストレージシステムを正常な状態に迅速かつ容易に保つことができるようになる。
【０２５２】
また、上述した構成によれば、保守性の高いストレージシステムを実現することができる。
【符号の説明】
【０２５３】
１……ストレージシステム、１００……ストレージノード、１１０……管理ノード、１２０……コンピュータノード、１３０……フロントエンドネットワーク、１４０……バックエンドネットワーク、１５０……ストレージクラスタ、１６０……プロテクションドメイン。
【図１】
2020013226.tif 000003
【図２】
2020013226.tif 000004
【図３】
2020013226.tif 000005
【図４】
2020013226.tif 000006
【図５】
2020013226.tif 000007
【図６】
2020013226.tif 000008
【図７】
2020013226.tif 000009
【図８】
2020013226.tif 000010
【図９】
2020013226.tif 000011
【図１０】
2020013226.tif 000012
【図１１】
2020013226.tif 000013
【図１２】
2020013226.tif 000014
【図１３】
2020013226.tif 000015
【図１４】
2020013226.tif 000016
【図１５】
2020013226.tif 000017
【図１６】
2020013226.tif 000018
【図１７】
2020013226.tif 000019
【図１８】
2020013226.tif 000020
【図１９】
2020013226.tif 000021
【図２０】
2020013226.tif 000022
【図２１】
2020013226.tif 000023
【図２２】
2020013226.tif 000024
【図２３】
2020013226.tif 000025
【図２４】
2020013226.tif 000026
【手続補正書】
【提出日】令和1年5月29日(2019.5.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムであって、
前記一般ノードは、その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶し、
前記代表ノードは、
その第２記憶部に、前記複数の一般ノードから収集したリソース状態情報を記憶し、
受信したリクエストに基づいて、前記一般ノードの第１記憶部からリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する
ことを特徴とするストレージシステム。
【請求項２】
前記代表ノードは、
複数のリソースを含んで構成され、
その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶し、
その第２記憶部に、前記複数の一般ノード及び前記代表ノードの第１の記憶部から収集したリソース状態情報を記憶している
ことを特徴とする請求項１に記載のストレージシステム。
【請求項３】
前記代表ノードは、前記第２記憶部から前記リクエストにかかるリソース状態情報を取得可能か判断し、取得不可と判断した場合に、前記一般ノードの第１記憶部からリソース状態情報を取得する
ことを特徴とする請求項１に記載のストレージシステム。
【請求項４】
前記一般ノードが各リソースからリソース状態情報を取得する頻度は、前記代表ノードが前記一般ノードから前記リソース状態情報を取得する頻度よりも高い
ことを特徴とする請求項１に記載のストレージシステム。
【請求項５】
前記代表ノードが前記リソース状態情報の履歴を保存する期間は、前記一般ノードが前記リソース状態情報の履歴を保存する期間よりも長い
ことを特徴とする請求項１に記載のストレージシステム。
【請求項６】
前記代表ノードは、サマリ化されたリソース状態情報を記憶する
ことを特徴とする請求項１に記載のストレージシステム。
【請求項７】
前記サマリ化されたリソース状態情報は、時間方向でサマリ化されており、
前記リクエストに含まれる時間の指定に基づいて、前記リソース状態情報を取得するノードを決定する
ことを特徴とする請求項６に記載のストレージシステム。
【請求項８】
前記サマリ化されたリソース状態情報は、複数の一般ノードのリソース状態情報をまとめることでサマリ化されており、
前記リクエストに含まれるノードの指定に基づいて、前記リソース状態情報を取得するノードを決定する
ことを特徴とする請求項６に記載のストレージシステム。
【請求項９】
前記一般ノードからリソース状態情報を取得するとした場合に取得を行う前記一般ノードの数に基づいて、前記一般ノードまたは前記第２記憶部のいずれからリソース状態情報を取得するかを決定する
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１０】
前記代表ノードは、前記一般ノードからリソース状態情報を取得する場合、リソース状態情報の対象となるリソースが前記複数の一般ノードの何れかに設けられかを示す履歴情報または前記リソースが移動しうる範囲を示す範囲情報と基づいて、前記一般ノードを特定してリソース状態情報の取得を行う、
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１１】
前記代表ノードとして、主代表ノードと、副代表ノードとが設けられ、
前記主代表ノードは、
前記受信したリクエストの対象となっている一般ノードを特定し、
前記代表ノードと一般ノードの管理関係を規定した管理情報に基づき、前記特定した一般ノードを管理する代表ノードを特定して、前記特定された代表ノードにリクエストを取得させ、
前記特定された代表ノードは、
前記リクエストを取得して、前記一般ノードからリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する、
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１２】
前記主代表ノードは、前記主代表ノードおよび前記副代表ノードの状態を示すノード状態情報に基づいて、前記リクエストを前記特定された代表ノードである副代表ノードに処理させるか否かを判定し、前記処理させると判定した場合、前記副代表ノードに前記リクエストを転送する、
ことを特徴とする請求項１１に記載のストレージシステム。
【請求項１３】
前記一般ノードは、前記複数のリソースのうちリソース状態情報が閾値を超えるリソースのリソース状態情報を記憶する、
ことを特徴とする請求項１に記載のストレージシステム。
【請求項１４】
代表ノードと、複数のリソースを含んで構成される一般ノードを複数と、を含んで構成されるストレージシステムにおける情報管理方法であって、
前記一般ノードが、その第１記憶部に、自身の前記複数のリソースの各々の状態を示すリソース状態情報を記憶する第１のステップと、
前記代表ノードが、その第２記憶部に、前記複数の一般ノードから収集したリソース状態情報を記憶する第２のステップと、
前記代表ノードが、受信したリクエストに基づいて、前記一般ノードの第１記憶部からリソース状態情報を取得するか、前記第２記憶部からリソース状態情報を取得するかを決定し、決定した取得先から取得したリソース状態情報を前記リクエストの発行元に送信する第３のステップと、
を備えることを特徴とする情報管理方法。