JP2019191929A - 性能分析方法および管理計算機 - Google Patents

Abstract

【課題】規模にかかわらず計算機システムの性能が分析可能になる。【解決手段】管理計算機による計算機システムの性能分析方法であって、前記管理計算機は、プロセッサと、前記プロセッサが実行するプログラムが格納された記憶装置とを備え、前記計算機システムは、複数のリソースから構成され、前記プロセッサは、前記リソース間の性能データの変化の相関に基づき、前記複数のリソースを複数のリソースグループに分割し、分割された前記リソースグループ毎に性能データを分析する。【選択図】図７

Description

本発明は、性能分析方法および管理計算機に関する。

近年、情報システム（計算機システム）を活用したサービスが一般的となっており、情報システムが大規模化している。また、情報システムでは、物理的な故障以外に、リソース性能の逼迫によるレスポンス劣化なども発生し、その発生の原因には、上位アプリケーションの処理の活発化などもあるが、物理的で部分的な故障なども遠因となるなど、原因が複雑に絡み合い、大規模化していることもあって、その分析は難しい。

例えば特許文献１が開示するように従来の運用管理手法においては、性能監視ソフトウェアの出力項目に対して、ある閾値を設定し、閾値を超えたことを契機に、通常の稼働状態では生じないような性能上の挙動を発見する実現例が多い。

米国特許第９４８５１６０号明細書

特許文献１に開示されたような従来の運用管理方法を用いても、大規模化した情報システムでは、性能監視ソフトウェアの出力項目が膨大な数になり、原因が複雑に絡み合うため、その分析は難しい。

そこで、本発明は、規模にかかわらず計算機システムの性能を分析可能にすることを目的とする。

本発明に係る代表的な性能分析方法は、管理計算機による計算機システムの性能分析方法であって、前記管理計算機は、プロセッサと、前記プロセッサが実行するプログラムが格納された記憶装置とを備え、前記計算機システムは、複数のリソースから構成され、前記プロセッサは、前記リソース間の性能データの変化の相関に基づき、前記複数のリソースを複数のリソースグループに分割し、分割された前記リソースグループ毎に性能データを分析することを特徴とする。

本発明によれば、規模にかかわらず計算機システムの性能が分析可能になる。

計算機システムの例を示す図である。 ストレージ装置の例を示す図である。 管理コンピュータの例を示す図である。 ストレージ構成情報の例を示す図である。 ストレージ性能情報の例を示す図である。 インスタンス構成情報の例を示す図である。 ストレージ性能分析プログラムの構成の例を示す図である。 リソースグループ管理テーブルの例を示す図である。 リソースグループの算出の例を示す図である。 リソース階層とリソースグループの例を示す図である。 リソースグループの計算とモデル学習の処理フローの例を示す図である。 モデル評価の処理フローの例を示す図である。 データセンタの例を示す図である。 分散ソフトウェアストレージ環境の例を示す図である。

本実施例によれば、複数のワークロードにより共有される計算機システム（ストレージ装置）の性能分析において、効率的な分析を可能にする方法および装置が提供される。

＜物理構成および論理構成＞
計算機システムの例を図１に示す。図１に示す計算機システムは、一つ以上のサーバ装置１０、一つ以上のストレージ装置１００、管理コンピュータ２００、およびそれらを相互に接続するネットワーク５０から構成される。なお、サーバ装置１０ａとサーバ装置１０ｂのいずれかを特定せずに指し示す場合、符号を１０（サーバ装置１０）と表し、他の符号も同じ形式で表す。

サーバ装置１０ではアプリケーション１３が稼働し、計算機システムの利用者（ユーザ）に対して情報サービスを提供する。ユーザは、クライアントコンピュータ２５０を介してサーバ装置１０を利用する。

クライアントコンピュータ２５０とストレージ装置１００、あるいはサーバ装置１０とストレージ装置１００により、ネットワーク５０は必ずしも共有される必要はなく、例えばサーバ装置１０とストレージ装置１００とを接続する目的で、専用のネットワーク６０が構成されてもよい。

あるいは、アプリケーション１３（サーバ装置１０）と利用者（クライアントコンピュータ２５０）の通信をサービスネットワークとして設け、管理コンピュータ２００とサーバ装置１０の通信を管理ネットワークとして設けるなど、利用目的に合わせて別々に図示を省略したネットワークが構成されてもよい。

サーバ装置１０はアプリケーション１３を稼働させるための一般的な計算機アーキテクチャを備える。複数のサーバ装置１０の構成は同一である必要はなく、サーバ装置１０で直接的にＯＳ１２（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が稼働するベアメタルサーバ装置であるサーバ装置１０ａであってもよい。

あるいは、アプリケーション１３とＯＳ１２が利用する論理的なシステム領域（インスタンス１１）を動的に分割あるいは多重化する目的で、仮想化ソフトウェア２０または図示を省略したコンテナエンジンをさらに稼働させる仮想化サーバ装置であるサーバ装置１０ｂであってもよい。

一般にクラウドサービスでは、これらシステム領域自体や、システム領域内に構築されたアプリケーション環境、さらにはアプリケーションが提供するＩＴサービスに対して従量課金を行う方式が採用されている。

ここでは、これらユーザが利用するサービスの対象でありシステム領域に準ずる環境がインスタンス１１である。また、インスタンス１１においてアプリケーション１３がもたらす処理負荷、およびインスタンス１１そのものが稼働するために必要な処理負荷のことを合わせてワークロードと呼び、これらはユーザの利用状況により動的に変化する。

ネットワーク５０は、ネットワーク５０を介して通信する装置をそれぞれ相互に直結してもよいが、複数の通信経路を構成するために、一つ以上の図示を省略したネットワークスイッチまたはルータを含んでもよい。また役割や伝送されるデータの特性に合わせて物理的、論理的に分割されていても良く、その分割は従来技術において一般的なものが利用されてもよい。

このために、ＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）のように論理的にネットワーク空間を分割し多重化する技術が用いられてもよい。また、専用のネットワーク６０は、例えばＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）のように専用の物理装置および通信プロトコルが使用されるものであってもよい。

そして、サーバ装置１０とストレージ装置１００は、ネットワーク５０または専用のネットワーク６０を介して相互に通信するための通信プロトコルに準拠したネットワークインタフェースを有する。

ストレージ装置１００は不揮発性の記憶装置であり、サーバ装置１０が利用可能であるようにデータを保管し、データを複製するなどの機能を提供する。サーバ装置１０からデータが格納される記憶領域は、一般にストレージデバイスとして認識され、その記憶領域をストレージ装置１００は論理的なボリューム１０１として制御する。

ボリューム１０１には、ＯＳ１２が記憶領域を管理するためのファイルシステムが構成される。仮想化ソフトウェア２０が稼動する場合には、ボリューム１０１をさらに区分するためにファイルシステム上のファイルとして仮想ディスク１０２が構成されることもあるが、記憶装置としてストレージ装置１００が備えるべき機能はいずれの例によらず同一である。

本実施例においては記憶装置の一般的な実装例に従い、ストレージ装置１００が制御する対象はボリューム１０１であり、そのうえでサーバ装置１０がどのように仮想ディスク１０２を作成するかの情報は、ストレージ装置１００に無い。

管理コンピュータ２００は、計算機システムの構成や稼働状態を集中的に管理するためのものであり、計算機システムの運用管理を担当する管理者が主に利用する。管理コンピュータ２００は必ずしも単一のものが共有される必要はなく、信頼性向上のための冗長化または負荷分散の目的で複数構成されていてもよい。また、管理コンピュータ２００は管理以外の処理に利用されてもよい。

図２はストレージ装置１００の例を示す図である。ストレージ装置１００は、ストレージ装置１００の構成を管理し、記憶装置として動作するためのストレージコントローラ１５０を備える。ストレージコントローラ１５０の構造はコンピュータアーキテクチャに準じている。

ストレージコントローラ１５０は、プロセッサ１５１、メモリ１５２、通信インタフェースであるストレージポート６１とＮＩＣ５１（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）、キャッシュ１５３、バックエンドインタフェースであるＳＡＳ−ＩＦ１５４、およびそれらを相互に接続するデータバス１５６を備える。

ストレージポート６１またはキャッシュ１５３はストレージ装置１００の入出力性能に直接的に関係するため、接続されるサーバ装置１０の数に応じて複数搭載されてもよい。ストレージポート６１またはキャッシュ１５３以外を含めたストレージコントローラ１５０が、ストレージ装置１００に複数具備されてもよい。

ストレージコントローラ１５０において、サーバ装置１０からのデータの読み書き要求を処理するため、プロセッサ１５１はメモリ１５２に格納されたストレージ制御プログラム１５５ａを読み出してプロセスとして実行する。

ストレージ制御プログラム１５５ａは、データの読み書き要求を処理する以外に、ストレージポート６１の流量管理機能、ボリューム１０１のデータを複製する装置内コピー機能、あるいは別のストレージ装置筐体に複製（レプリケーション）する装置間コピー機能を提供するためのプログラムを含んでもよい。

さらに、ストレージ制御プログラム１５５ａは、キャッシュ１５３の利用上限を設定するキャッシュ管理機能、記憶領域の利用頻度に合わせて割り当てるドライブ装置の種類を変更するストレージメディア階層化機能、あるいはユーザインタフェースとなるＷｅｂサーバ機能などを提供するためのプログラムを含んでもよい。

なお、上記のコピー機能など、データの読み書き要求の処理以外の付加的機能のことを、説明を簡単にするため、以下では単にストレージ機能と呼ぶ。ストレージ機能を提供するには、データの読み書き要求の処理と同一の、ストレージ装置１００のリソースを消費しており、アプリケーション１３によるワークロードとは別に、ストレージ装置１００に処理負荷を与える。

また、メモリ１５２には、ストレージ装置１００の性能情報を管理するための性能管理インタフェース１５５ｂのプログラムと、構成情報を管理するための構成管理インタフェース１５５ｃのプログラムが格納される。これらのプログラムは、外部から情報が変更されたり、外部から情報が参照されたりするためのプログラムである。

ただし、外部との情報のインタフェースを提供できれば、別の実施形態であってもよく、これらのプログラムはストレージ制御プログラム１５５ａに含まれてもよい。

ストレージ装置１００は、データを格納するために複数のドライブ装置１０５を備える。ここでいうドライブ装置１０５は、いわゆるＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）のことを指しており、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）など複数のドライブ装置１０５を協働させる機構により信頼性や入出力性能を高める。

ストレージ装置１００においてドライブ装置１０５の構成は一定でなく、故障や容量不足によってドライブ装置１０５の単位で交換・増減設が実施されうる。ドライブ装置１０５は図２に示すＨＤＤの構成以外に、ＳＳＤまたはフラッシュメモリ装置であって容量、レイテンシ、あるいは転送帯域が異なるドライブ装置１０５が混載されてもよい。

ストレージ装置１００は、ドライブ装置１０５を使用可能にするため、ドライブ装置１０５に対応したＳＡＳ−ＩＦ１５４とストレージ制御プログラム１５５ａを備える。そして、計算機システムの役務を実現するためには、ストレージ装置１００の各部位が継続的に正常動作することが重要である。

しかしながら、ストレージ装置１００は、構成する部品点数が多いことから、単純に故障や障害を検出することが難しく、大量の監視データから情報を集約するための効率的な管理に基づく性能分析が必要となる。本実施例の一つの目的は、ストレージ装置１００のようなストレージシステムにおけるリソース性能を分析し、異常な挙動を発見することにある。

前述の通り、ストレージ装置１００はサーバ装置１０に対して、論理的にはボリューム１０１を提供する。ボリューム１０１は、ドライブ装置１０５と異なり、物理的に対応する有形物が直接的に存在しないという意味で、論理的な構造である。

ストレージ装置１００はドライブ装置１０５の記憶領域をそのままボリューム１０１として構成するのではなく、ＲＡＩＤグループ１０４やストレージプール１０６といった論理的な構造をさらに有しており、ストレージコントローラ１５０によってこれらの構成が管理される。

例えば、複数台のドライブ装置１０５が一つのＲＡＩＤグループ１０４を構成し、ＲＡＩＤグループ１０４の記憶容量は一つ以上のＲＡＩＤグループ１０４から構成されるストレージプール１０６として管理される。

さらに、サーバ装置１０に提供されるための仮想ボリューム１０７は、ストレージプール１０６から割り当てられ、ＳＡＮ６０およびストレージポート６１などを介してサーバ装置１０と接続されることで、サーバ装置１０からストレージデバイスとして認識される。

ストレージプール１０６から動的に割り当てられた仮想ボリューム１０７を仮想ボリュームと呼んで区別する場合もあるが、サーバ装置１０からボリューム１０１と仮想ボリューム１０７とはいずれもストレージデバイスとして認識される。

その他、ストレージポート６１またはＳＡＮ６０を構成するスイッチ類は、ボリューム１０１および仮想ボリューム１０７とサーバ装置１０との通信可否を制御する目的で、ＬＵＮセキュリティ（ＨＳＤ：Ｈｏｓｔ Ｓｔｏｒａｇｅ Ｄｏｍａｉｎ）またはゾーニングといったアクセス制御を行う場合もある。

また、複数のボリューム１０１のそれぞれに対してキャッシュ１５３の特定の領域それぞれが割り当てられ、入出力性能を高める働きをする。サーバ装置１０から出力されたデータは、階層的に連なる論理的な構造および物理的な構造を経てドライブ装置１０５に記録される。

ただし、ストレージ装置１００あるいはストレージコントローラ１５０を含む一般のブロックストレージシステムが、ボリューム１０１に記録されたデータがどのような構造であるか、どのような意味を持つかといった使用状況を検出することは極めて困難である。

これは、サーバ装置１０のＯＳ１２や仮想化ソフトウェア２０などストレージ装置１００外部の処理により、ボリューム１０１にさらにファイルシステムが作成されたり、仮想ディスク１０２が作成されたりするが、ストレージ装置１００はこれらの作成に関する管理情報を他のデータと区別していないためである。

コピー機能や容量削減機能など、ストレージコントローラ１５０が提供するストレージ機能のなかには、物理的な構造に限らず、ボリューム１０１、仮想ボリューム１０７、あるいはストレージプール１０６の論理的な構造を適用対象とするものがあってもよい。

性能や容量などの特性は、ボリューム１０１、仮想ボリューム１０７、あるいはストレージプール１０６に関連付けられるため、ユーザがストレージ要件を設定する際の一つの表現形式として、このような論理的な構造が使用される場合がある。

例えば、ユーザが、システムのテスト用途には大容量で低速なストレージプール１０６を割り当てる場合、またはプロダクション環境には他システムと共用しない独立した高速なストレージプール１０６を割り当てる場合、設定に論理的な構造が使用される。

ストレージ装置１００の性能を監視する際には、物理的な構造のみならず論理的な構造についても性能値が測定される。上述の通り、物理的には別々の構造であっても、一つの論理的な構造が定義されている場合、協調して動作するため、論理的な構造についても性能値が測定される。

以下では特に断らない限り、測定対象となる構成要素のことをリソース、指標とすべき性能値のことをメトリクスと呼ぶ。リソースとは、例えばボリューム１０１またはキャッシュ１５３のことであり、メトリクスとは、例えば使用率、転送量、応答時間、あるいは単位時間あたり処理入出力数（ＩＯＰＳ）のことである。

性能値は、技術的に計測可能であっても監視の対象とならない場合もあり、本実施例において、ストレージ装置１００の外部から利用可能なメトリクスであるか否かは、管理コンピュータ２００の監視プログラム（ストレージ性能管理プログラム２０２）により定義される。

また、入出力に関わる基本的な機能以外のストレージ機能は、ストレージ装置１００に処理負荷を加える構成要素であるから、ストレージコントローラ１５０で稼働するストレージ機能を実現するためのプロセスやタスクを一種のリソースと定義することがある。そして、他のリソースと同様に、ストレージ機能に関するリソースの実行状況も、ストレージ性能管理プログラム２０２によって観測され、管理されてもよい。

図３は管理コンピュータ２００の例を示す図である。本実施例における管理コンピュータ２００では、ストレージ装置１００を管理するためのストレージ管理プログラム群と、サーバ装置１０で稼働するインスタンスを管理するためのインスタンス管理プログラム群とが、稼働する。

管理コンピュータ２００自体は、一般的なコンピュータであってもよく、プログラムを実行するプロセッサ２７１、プログラムとデータが格納される記憶装置２７２、ネットワーク５０と接続するためのＮＩＣ２７３を備える。記憶装置２７２は、メモリ、ＨＤＤ、あるいはＳＤＤなどであってもよい。

ストレージ管理プログラム群は、ストレージ性能分析プログラム２０１、ストレージ性能管理プログラム２０２、ストレージ構成管理プログラム２０４を含む。ストレージ構成管理プログラム２０４は、ストレージ装置１００のストレージコントローラ１５０と連携して、ストレージ装置１００の物理的構造および論理的構造の情報を、変更したり、取得してストレージ構成管理データベース２０５に格納したりするためのプログラムである。

ストレージ性能管理プログラム２０２は、ストレージ装置１００と連携して、ストレージ装置１００が有する各リソースの性能を取得してストレージ性能履歴データベース２０３に蓄積するためのプログラムである。

ストレージ性能分析プログラム２０１は、本実施例を特徴付ける主たる構成要素であり、ストレージ性能管理プログラム２０２により提供される性能情報を分析することで、大量の性能情報を少数の統計量に集約したり、特徴的な挙動を抽出したりするためのプログラムである。

計算機システムを性能の観点で分析し、運用管理の業務に活用する役割として、主にストレージ性能分析プログラム２０１を使用する者を指して分析者と呼ぶことがある。

インスタンス管理プログラム群は、インスタンス構成管理プログラム２０６を含む。インスタンス構成管理プログラム２０６は、サーバ装置１０と連携して、サーバ装置１０のインスタンスの構成を、変更したり、取得してインスタンス構成管理データベース２０７に蓄積したりするためのプログラムである。

インスタンス管理プログラム群は、ストレージ構成管理プログラム群と逐一同期する必要がないという意味で、ストレージ構成管理プログラム群から独立である。例えばセルフサービスといったクラウドシステムに一般的な運用形態では、ユーザが許可された範囲内でリソースを自由に消費し、インスタンスの作成や変更と、仮想ディスク１０２の作成と変更とが独立に行われる。

そして、ボリューム１０１はストレージ管理プログラム群で管理されるが、ボリューム１０１でどのように仮想ディスク１０２が構成されようと、ストレージ管理プログラム群は管理しない。

例えば、アプリケーション１３の要件に応じて大容量の記憶領域が必要であれば、インスタンスが複数のボリューム１０１を束ねて利用し仮想ディスク１０２を拡張してもよい。また、あるインスタンスが使用するボリューム１０１の容量に余剰があれば、別のインスタンスが使用する仮想ディスク１０２を同じボリューム１０１に作成して、そのボリューム１０１を共有させてもよい。

ボリューム１０１のこれらの使い方はサーバ装置１０の管理において行われるため、管理コンピュータ２００のストレージ管理プログラム群は、このような使い方を管理せず、このような使い方の情報を有しない。

このような界面により、クラウドシステムは管理負荷のかかる物理インフラストラクチャの構成変更と、インスタンスの構成変更とを分離し、ユーザが必要とするリソースを必要とした時点で提供する機能を実現している。

インスタンスのリソース要件は、ユーザが実行させるアプリケーション１３のハードウェア要件に依存することから、インスタンス管理プログラム群はユーザに由来するワークロードの状態の情報を得る。他方で、インスタンス管理プログラム群と独立していることから、ストレージ管理プログラム群がユーザのワークロードの状態の情報を得ない。

以上で説明した管理コンピュータ２００の四つのプログラムは、計算機システムを管理するためのものであり、以下では説明のため単に管理プログラムと総称することがある。なお、便宜的に管理プログラムをストレージ管理プログラム群およびインスタンス管理プログラム群に分けたが、必ずしも分ける必要はなく、あるいは別の構成のプログラムであってもよい。

また、四つの管理プログラムは、単一の管理コンピュータ２００で稼働させる必要はなく、複数のコンピュータに分散して稼動させてもよい。各管理プログラムは、ユーザに情報を表示し、また入力させるためのユーザインタフェースをさらに備えていてもよく、他のプログラムと連携するための一般的な形式によるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を備えていてもよい。

図４は、ストレージ構成管理プログラム２０４およびストレージ構成管理データベース２０５によって管理されるストレージ構成情報２１０の例を示す図である。図４に示したストレージ構成情報２１０は、ストレージ装置１００の一部のコンポーネント（リソース）についての例であり、ポート構成情報２１０ａ、プール構成情報２１０ｂ、およびＲＡＩＤグループ構成情報２１０ｃを含む。

その他のストレージ構成情報として、例えばプロセッサ１５１やキャッシュ１５３などのリソースについてのストレージ構成情報があってもよい。ポート構成情報２１０ａは、ストレージポート６１を表すポート列２１０ｄの情報に対し、ＬＵＮセキュリティを表すＨＳＤ列２１０ｅの情報とボリューム１０１を表すボリューム列２１０ｆの情報が対応付けらえる。

プール構成情報２１０ｂは、ストレージプール１０６を表すプール列２１０ｇの情報に対し、ボリューム１０１を表すボリューム列２１０ｆの情報とＲＡＩＤグループ１０４を表すＲＧ列２１０ｈの情報が対応付けられる。

ＲＡＩＤグループ構成情報２１０ｃは、ＲＡＩＤグループ１０４を表すＲＧ列２１０ｈの情報に対し、ドライブ装置１０５を表すドライブ装置列２１０ｉの情報が対応付けられる。ストレージ構成情報２１０に含まれる情報は、リソース種別において重複しない一意な名前を表しており、少なくとも単一のストレージ装置１００内部で唯一の識別子である。

このため、識別子がたどられることにより、ストレージ構成情報２１０は、例えば、「Ｐｏｒｔ １Ｃ」のストレージポート６１に接続される「ＶＬ ０２：４０」のボリューム１０１が、「ＳＰ００１」のストレージプール１０６から割り当てられており、このストレージプール１０６を構成する「ＲＧ００１」と「ＲＧ００２」のＲＡＩＤグループ１０４に属する複数のドライブ装置１０５であることを表す。

リソースに関して、ストレージ構成管理プログラム２０４が管理する情報には他にも、例えばボリューム１０１の割り当て容量やストレージ機能の実行状態などの情報が含まれるが、それらは図４に示したような識別子を用いてリソースが識別され、そのリソースの属性値として管理される。

その属性値を参照するために、例えば、識別子を主キーとして属性値を保持する別のデータ構造を参照するような処理であってもよく、ストレージ構成管理プログラム２０４の実行により、他の管理プログラムの実行による問い合わせに応じて、ストレージ装置１００の構成情報を参照させてもよい。

図５は、ストレージ性能管理プログラム２０２およびストレージ性能履歴データベース２０３によって管理されるストレージ性能情報２１１の例を示す図である。ストレージ性能情報２１１は、リソースＩＤ２１１ｂおよびメトリクス２１１ｃに対して、時系列の数値データ（性能値）が格納される。時系列のインデックスは時刻２１１ａであり、時間経過に対して蓄積されることで時刻２１１ａの時刻的に後の方向に数値データが増加する。

リソースＩＤ２１１ｂはリソースを識別するための識別子である。図５では、リソースとして、ストレージポート６１（「Ｐｏｒｔ ０Ｆ」）、キャッシュ１５３（「Ｃａｃｈｅ００１」）、ストレージプール１０６（「ＳＰ１０２」）、およびＲＡＩＤグループ１０４（「ＲＧ０３０」）の例を示す。

ストレージポート６１についてのメトリクス２１１ｃ−１や、キャッシュ１５３についてのメトリクス２１１ｃ−２、ストレージプール１０６についてのメトリクス２１１ｃ−３、およびＲＡＩＤグループ１０４についてのメトリクス２１１ｃ−４の例に示すように、各リソースは一つ以上のメトリクスを備える。

メトリクス２１１ｃは、リソースの種別によって異なっており、同一の種別のリソースについては共通である。また、各種のストレージ機能が動作する場合、その処理タスクの実行有無がストレージ性能情報２１１に含まれてもよく、計算を容易にするため稼働状態が例えば二値（実行中を１、待機中を０、など）として数値化されてもよい。

ストレージ性能情報２１１のなかには、何等かの理由で性能値を記録できなかった（欠損値となる）時間帯があったり、リソースの種別によって性能値の取得可能な時間間隔（サンプリングレート）が異なっていたりといった場合の他、ストレージ性能管理プログラム２０２の不良によって実際と異なる性能値が記録される場合が起こりうる。

これらの性能値については、一般的な手法により分析の前処理段階で除去、補間、あるいは修正されてもよい。また、性能値のデータの量は時間経過につれて増大し、管理コンピュータ２００において相応の記憶容量を消費する。

このため、予め設定された一定の保存期間を経て削除されるが、ここでは後述する分析処理に必要な期間のデータが保存され呼び出し可能であるように、ストレージ性能管理プログラム２０２が制御する。

図６は、インスタンス構成管理プログラム２０６およびインスタンス構成管理データベース２０７によって管理されるインスタンス構成情報２１２の例を示す図である。図６は説明のため、三つのインスタンス１１の例であり、それぞれのＩＤが「Ａ００１」、「Ａ００２」、および「Ｂ３３０」についての情報を、インスタンス構成情報２１２−１、インスタンス構成情報２１２−２、およびインスタンス構成情報２１２−３で示している。

インスタンス構成情報２１２には、詳細な各構成情報を分類して一般カテゴリ２１２ａ、サーバカテゴリ２１２ｂ、ネットワークカテゴリ２１２ｃ、およびストレージカテゴリ２１２ｄの設定値が含まれる。

一般カテゴリ２１２ａは、例えばインスタンス１１に付与された名称や、構成変更において完全な権限を有する所有者、インスタンス１１が稼動させる複数のアプリケーション１３から構成されるシステム名、インスタンス１１が物理サーバ装置であるか、あるいは仮想化ソフトウェア２０上の仮想マシンまたはコンテナであるかを示す種別といった情報を含む。

例えばＷｅｂ３階層アプリケーションや、データベースの冗長化、モジュール毎のＯＳ分離など、ＩＴシステムは一般に、単一のサービスを提供するためのものであっても複数のインスタンス１１から構成される場合が多い。

システム名は、これら複数のアプリケーション１３やインスタンス１１のまとまりを管理する目的で付与されており、インスタンス構成管理プログラム２０６はユーザが稼働させるワークロードの使用状況を取得するための情報を有している。

サーバカテゴリ２１２ｂは、例えば使用されているサーバ装置１０の識別子、割り当てられているＣＰＵに関する情報、およびメモリ（ＲＡＭ）の容量といったサーバ装置１０に関する情報を含む。

一般カテゴリ２１２ａの種別が「物理」、つまり物理サーバ装置であった場合にはこれらの割り当て量は変更が難しいものの、種別が「仮想」、つまりインスタンス１１が仮想マシンやコンテナであった場合には比較的柔軟に変更することが可能であり、仮想化ソフトウェア２０の機能によってはサーバ装置１０の搭載量を超えて仮想的なＣＰＵ数またはメモリ量を割り当てること（オーバーコミット）も可能である。

ネットワークカテゴリ２１２ｃは、例えばインスタンス１１が備えるネットワークインタフェースの情報を含む。インスタンス１１の種別により物理インタフェースであるか仮想インタフェースであるかは異なるものの、ＩＰアドレス、ネットワークゲートウェイ、あるいはＶＬＡＮ ＩＤなど、インスタンス１１がネットワーク５０を介してサービスを提供するのに必要なネットワーク設定の情報が含まれる。

ただし、一般的にセキュリティの観点から、インスタンス構成情報２１２がユーザに開示される場合には、管理コンピュータ２００がサーバ装置１０の構成を制御する目的で設定されるネットワーク５０の設定は秘匿されてもよい。

ストレージカテゴリ２１２ｄは、例えば記憶領域を識別するディスクＩＤや、その種別、およびその容量などを、作成元のボリューム１０１の情報とともに含む。図６に例示されるように、記憶領域は唯一である必要はなく、インスタンス１１のアプリケーション１３の要件に応じて複数の記憶領域であってもよい。

また、仮想マシンやコンテナにより構成されるインスタンス１１は主にファイル形式の仮想ディスク１０２を使用するが、要件に応じてボリューム１０１を物理サーバ装置と同様に使用してもよく、その種別を明示するために一般カテゴリ２１２ａとは別にストレージ種別を保持してもよい。

なお、前述の通り、インスタンス構成情報２１２をユーザに提示し、一定の権限を与えてインスタンスの作成や構成変更などの作業を委譲するセルフサービスは、昨今のクラウドシステムにおいて一般的に行われている運用形態である。

また、クラウドシステムにおいては一般に、管理者による人手を介さずに構成変更を行うため、具体的な構成変更作業の手順や実行方法は管理ソフトウェアにより自動化されることが多い。

これらの自動化管理ソフトウェアについては。インスタンス管理プログラム群と密接に連携するが、本実施例に特徴的な処理でなく、一般的な管理ソフトウェアにより実現可能であるため、ここでは説明を省略する。ただし、このような管理プログラム、特にストレージ性能分析プログラムに関わる各部の詳細については、本実施例に特徴的な処理と合わせて後述する。

前述の通り、管理コンピュータ２００は負荷分散などの目的に応じて複数接続されてもよい。特に分析プログラムのために、要求される計算能力が比較的高いものになることが想定されるため、複数の管理コンピュータ２００による負荷分散は有効である。

並列化またはインメモリでの処理によって、この要求に対処する際には、管理プログラムの他に並列計算のためのクラスタ管理機能、またはメモリのステージング管理機能が必要になるが、いずれも一般的な処理フレームワークで実現可能であり、本実施例に特徴的な機能ではないため説明を省略する。

＜分析プログラムの構成および機能＞
図７は、ストレージ性能分析プログラム２０１の構成の例を示す図である。ストレージ性能分析プログラム２０１は、主にデータを加工するために前処理部２０１ａ、モデル処理部２０１ｂ、および後処理部２０１ｃを備え、また、本実施例に特徴的な機能を実現するために、グループ化計算モジュール２０１ｄ、リソースグループ管理テーブル２０１ｅ、およびグループ評価モジュール２０１ｆを備える。

さらに、モデル処理部２０１ｂは、機械学習によって分析を行うためのモデル学習モジュール２０１ｇおよびモデル評価モジュール２０１ｈを備え、ストレージ性能分析プログラム２０１の各処理の実行手順は、分析ジョブ管理モジュール２０１ｉによって制御される。

ストレージ性能分析プログラム２０１は、ストレージ装置１００を性能の観点からモデル化し、通常の動作とは異なる挙動を検出するためのものである。図１に示した計算機システムにおいて、ストレージ性能分析プログラム２０１が実現すべき機能は大別して、性能データの学習および評価の二つであり、それぞれ主にモデル学習モジュール２０１ｇおよびモデル評価モジュール２０１ｈの処理により実現される。

ストレージ性能分析プログラム２０１は、管理コンピュータ２００が収集し、ストレージ性能管理プログラム２０２が管理するストレージ装置１００の性能データ（学習用データ２１５）から、ストレージ装置１００の稼動状態を表現する数理モデルを作成するためのものである。

一旦数理モデルが作成されれば、その後の性能データ（評価用データ２１６）が数理モデル作成時と比べて乖離しているか、乖離している場合はどの程度であるかを定量化することができる。

ここでは、性能データから数理モデルを作成する処理のことを学習と呼び、数理モデルを使ってストレージ装置１００が正常状態であるか否かを判定する処理のことを評価と呼ぶ。このような数理モデルに関する処理と、その前後で必要となる処理（前処理および後処理）とを含み、評価の判定が正常でなければ、知見（分析結果２１７）として異常なリソースを検出するための一連のデータ処理を総称して分析と呼ぶ。

図７の例では、前処理、数理モデルに関する処理、および後処理を担う処理部をそれぞれ前処理部２０１ａ、モデル処理部２０１ｂ、および後処理部２０１ｃとして示した。数理モデルの種類は一般に、様々なものが知られており、学習および評価の実現方式やアルゴリズムも複数あるが、ここでは説明を簡単にするため代表的な一例を説明する。

ただし、以下に説明する本実施例の特徴的な分析は、主に性能データの前処理にかかわるものであり、その前処理は、以下で説明する数理モデルの代表的な一例に限定されることなく、かつ数理モデルの種類によらず共通的に適用可能である。

複数のワークロードが混在する性能データを単一の数理モデルとして学習した場合、特定のワークロードの挙動が異常であっても、合成された数理モデルからは異常と判定できない恐れがある。従って、学習により精度のよい数理モデルを作成するには、個々のワークロードに関係するリソース群を特定し、学習対象となる性能データを区分することが望ましい。

一般に、メトリクスの多い問題（次元の高い多変数問題）については統計学的に精度の高い数理モデルを得ることは数理的に困難であるから、真に挙動を特徴づける性能データを選択して分析することが評価結果の精度を左右すると言える。

ストレージ装置１００の構成の情報に基づいて、リソース同士の関連を算出する方法もあるが、本実施例が対象とするように、ストレージ構成管理データベース２０５には、インスタンス１１またはアプリケーション１３とストレージ装置１００のリソースとの関連の情報を保持していないため、ストレージ構成管理プログラム２０４はワークロード毎にリソース同士の関連性を計算することができない。

ストレージ構成管理プログラム２０４とインスタンス構成管理プログラム２０６とを何らかの方法で連携させ、関連付けを達成したとしても、インスタンス１１の作成状況や利用状況はユーザの使い方により動的に変化するため、関連性の計算が終わった時点において実際の稼働状態を反映した計算結果が得られるとは考えにくい。

また、別の方法として、統計学的に主成分分析（ＰＣＡ、Ｐｒｉｎｃｉｐｌｅ Ｃｏｍｐｏｎｅｎｔ Ａｎａｌｙｓｉｓ）などの手法を用いてメトリクスの中から顕著なもの（分散が大きいもの）を抽出し、問題の次元（ここではメトリクス数に相当）を削減する方法もある。

しかしながら、メトリクスの抽出作業は、用いる手法により異なっており、分析者の試行錯誤による経験や前提知識などの主観に頼らざるを得ない。その結果、対象とする性能データを取得した時間帯によっては、影響のあるワークロードに由来するメトリクスを棄却する可能性がある。

さらには、特にＰＣＡなど変換を伴う方法によれば、抽出結果が加重平均などメトリクスの合成量となりメトリクスが本来持っていた物理的な意味から乖離してしまうという欠点がある。

そこで本実施例では、リソース間の相関係数の高さにより複数のグループに分類し、同じグループに属するリソースの性能データをまとめることで部分問題へ分割する。ここでのリソースは、ストレージ装置１００内の物理的または論理的な構成要素であるが、物理的な意味でいえば、接続された関係にあり同じワークロードにより使用されるリソースは、その階層によらず時間軸に対して類似の（相関の高い）挙動を示す。

それら相関の高いリソース、またはそのメトリクス同士の組み合わせによるグループを、便宜的にここではリソースグループと呼ぶこととし、リソースグループにより性能データと数理モデルを分割（分類）することをグループ化などと呼ぶ。

なお、メトリクスの中でも、同一のリソースに由来するメトリクスは、相関が高いことが自明であるので、同じリソースグループに分類されてもよい。さらに、相関係数に基づいてリソースグループを算出する方法によっては、同じリソースが複数のリソースグループに重複して計上されてもよく、性能データを分割（分類）する際には冗長なデータが保持されてもよい。

また、予め設定された閾値以下の使用頻度であってほぼ使われておらず、どのリソースとも予め設定された閾値より相関が低いリソースについては、その他であることを表す別のグループが設けられて、その別のグループに分類されてもよい。

グループ化計算モジュール２０１ｄは、各リソースの相関を用いてリソースグループを計算するためのものであり、前処理部２０１ａで参照できるようにするため、その算出結果をリソースグループ管理テーブル２０１ｅに格納する。前処理部２０１ａは、グループ化計算モジュール２０１ｄの算出結果に従って性能データ（学習用データ２１５および評価用データ２１６）を分割（分類）するためのものである。

前処理部２０１ａは、リソースグループ管理テーブル２０１ｅを参照することで、グループ化計算モジュール２０１ｄが同一のグループであると算出したリソースの組について、性能データの中からリソースおよびメトリクスの系列を選択して部分的なデータを作成する。グループ評価モジュール２０１ｆと後処理部２０１ｃについては後で説明する。

図８は、グループ化計算モジュール２０１ｄによって算出されたリソースグループの情報であって、リソースグループ管理テーブル２０１ｅの例を示す図である。リソースグループは相関の高いリソースまたはメトリクス同士の組である。

リソースグループ管理テーブル２０１ｅには、リソースグループの識別子（グループＩＤ列２０１ｅ−１）に対してリソースの識別子（リソースＩＤ列２０１ｅ−２）およびメトリクス（メトリクス列２０１ｅ−３）が保持される。

説明を簡単にするため、リソースＩＤ列２０１ｅ−２に保持されるリソースの識別子は、ストレージ構成管理プログラム２０４が扱うストレージ構成情報２１０の識別子と同一とする。ただし、名寄せの仕組みによって別途対応付けることが可能であれば、異なる識別子が用いられてもよい。

同様に、メトリクス列２０１ｅ−３に保持されるメトリクスについても、原則としてストレージ性能管理プログラム２０２が扱うストレージ性能情報２１１のメトリクスと同一とする。

また、状態が観測可能であれば、稼働中のストレージ機能を表すタスクがリソースの一種として計上されていてもよく、リソースグループ管理テーブル２０１ｅの最終行の「Ｃｏｐｙ Ｔａｓｋ ２６」は、コピー機能を稼働させるタスクをリソースとして保持する例である。ただし前述の通り、ここで保持できるリソースは、ストレージ性能管理プログラム２０２によって性能データが提供されるものに限る。

リソースグループの識別子（グループＩＤ列２０１ｅ−１）はリソースの集合を示すいわゆるラベルであり、識別子が時間変化に対して一定であることよりも、どのリソースとどのリソースが同じグループに分類されるかを保持することのほうが重要である。従って、リソースグループの識別子は、同じ学習用データ２１５から算出されたものについて可換である。

グループ評価モジュール２０１ｆは、時間経過に対して（例えば定期的に）複数の世代のリソースグループを記録し、それらを比較する。ストレージ装置１００にリソースの構成変更があれば、あるいはアプリケーション１３の大幅な作成または削除があれば、リソースグループはそれに対応して変化し、数理モデルがストレージ装置１００の挙動と乖離することで分析の精度が低下する。

そのため、複数の世代を比較して予め設定された閾値を超える顕著な差異があれば、計算機システムに大きな変更があったとみなし、数理モデルを作成しなおすことで、分析の精度を改善できる可能性がある。従って、グループ評価モジュール２０１ｆによってグループ化計算モジュール２０１ｄの出力値に予め設定された閾値を超える変化があったことを検出された場合、数理モデルの再計算を行ってもよい。

リソースグループは後述するように、主に性能データを用いて計算されるものであるから、ストレージ構成情報２１０を詳細に解析せずともシステムの構成変更を検知し、システムの実際の状態に数理モデルを追従させることができる。

モデル処理部２０１ｂにおいて、モデル学習モジュール２０１ｇが学習用データ２１５から数理モデルを学習し、モデル評価モジュール２０１ｈが性能データ（評価用データ２１６）に対して評価を行う。

モデル学習モジュール２０１ｇおよびモデル評価モジュール２０１ｈが使用する数理モデルは同一のものであるが、前処理部２０１ａにおいてグループ化され分割された学習用データ２１５の部分集合毎に複数の数理モデルが作成（学習）される。各数理モデルの学習および評価は、部分集合毎に独立して実行可能であるから、それらを並列実行することで全体の処理時間を短縮する効果が見込まれる。

モデル学習モジュール２０１ｇによる数理モデルの学習、およびその数理モデルを使用したモデル評価モジュール２０１ｈによる評価は、一般的な分析手法が適用可能であって、いわゆる異常検知を行うアルゴリズムである。

このようなアルゴリズムには、ＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）や各種クラスタ分析を利用するものが知られているが、ここではデータセットが得られないことを想定した教師なし機械学習の一つである、ｋ平均法を用いた処理を一例として説明する。

まず、学習用データ２１５をストレージ装置１００の正常状態を表すデータとし、前処理部２０１ａにおいて前述のグループ化やスケーリングなどを施す。モデル学習モジュール２０１ｇでは、前処理を経た学習用データ２１５が各メトリクスを軸とする多次元空間上の集合であるとみなし、ｋ平均法によるクラスタリングが行なわれる。

ここでの学習用データ２１５は、ストレージ装置１００の各リソースの正常状態における時系列性能値であり、ワークロードの特性または時間帯による利用度合いを反映した複数のクラスタに分けられる。

これらのクラスタは正常状態におけるストレージ装置１００の振る舞いを表しているため、例えばクラスタ中心からの距離（スケーリングされている場合はマハラノビス距離）が状態の異常さを表す定量指標であり、これを異常度と呼ぶ。

従って、このようなクラスタリングに基づく数理モデルはリソースグループ毎に分割された多次元空間において定義される、ｋ平均法によって得られたクラスタ中心およびクラスタの大きさを表す標準偏差として定式化される。モデル評価モジュール２０１ｈは評価用データ２１６に対して最近傍クラスタ中心からの距離を計算し、異常度を算出する。

前処理部２０１ａは、モデル処理部２０１ｂで処理を行うのに適切な形式となるように、学習用データ２１５と評価用データ２１６を加工するためのものである。前処理部２０１ａは、データ分析の分野で行われる一般的な前処理と、必要に応じて本計算機システムに特有な前処理とが組み合わせられてもよい。

前処理は基本的に学習用データ２１５および評価用データ２１６の両者に対して共通した処理であるが、詳細な設定（例えば欠損値の補間処理などの設定）は共通しなくてもよい。一般的な前処理は例えば、ストレージ性能情報２１１に含まれる可能性のある欠損値、不正値、または外れ値に対応するための加工や、異なる単位のメトリクスを扱うための正規化を含むスケーリングの処理である。

本計算機システムに特有な前処理は、リソースＩＤとメトリクスＩＤなどの対応付け、および性能データ（評価用データ２１６）をリソースグループの定義（リソースグループ管理テーブル２０１ｅの情報）に従って分割（分類）するグループ化処理を含む。

後処理部２０１ｃは、数理モデルの評価結果をさらに加工し、分析結果として整形するためのものである。例えば、後処理部２０１ｃは、異常度が許容範囲内であるか否かを予め設定された閾値で判定し、要因と推定されるメトリクスなどの付加的情報とともに分析結果２１７として管理コンピュータ２００の他の管理プログラムに出力したり、管理者に表示できるようにしたりする。

異常度の判定に用いられる閾値（正値）は、性能データが正規分布に従うと仮定してパーセンタイルの概念から例えば標準偏差の２倍としてもよい。ｋ平均法によるモデル化では、異常度は単に、対象とする多次元空間において正常状態と異なる振る舞いをしているか否かを与える指標であり、どのメトリクスが要因となっているかという情報までは含んでいない。

異常度が高く、性能上の問題と判定される傾向が検出された場合には、後処理部２０１ｃによって要因となりえるメトリクスを推定する処理を別途実行することが望ましい。最も簡便には、後処理部２０１ｃが、クラスタ中心からの距離が大きい成分（メトリクス）から順に複数を列挙してもよい。

以上のストレージ性能分析プログラム２０１内の各処理部および各モジュールにかかる処理の実行は、分析ジョブ管理モジュール２０１ｉの処理により制御される。例えば、分析ジョブ管理モジュール２０１ｉは、評価用データ２１６の入力に応じて前処理部２０１ａ、モデル処理部２０１ｂ、後処理部２０１ｃを順序的に実行させるためのものである。

また、分析ジョブ管理モジュール２０１ｉの処理は、必要に応じて（何らかの予め設定された条件を判定して）学習用データ２１５からリソースグループの算出および数理モデルの学習を行って分析処理の精度を持続的に改善してもよい。

ストレージ性能分析プログラム２０１内で各手順が実行される際、分析ジョブ管理モジュール２０１ｉの処理は、分析を実施する管理者に対して事前に承認を得るほか、事前に定義された頻度に応じて定期的に各手順を実行させる、あるいはグループ評価モジュール２０１ｆなどの各部の処理結果に応じて別の処理を開始させてもよい。

図９は、リソースグループの算出についての例を示す図である。グループ化計算モジュール２０１ｄは、各リソースについてのメトリクス同士について計算される相関行列に基づいてリソースグループを算出する。

ストレージ性能管理プログラム２０２から得られた学習用データ２１５を、各メトリクスについての時系列データ（ストレージ性能情報２１１）とし相関を計算すると（相関計算２２０）、対象の総メトリクス数を次数に持つ相関行列２２１が得られる。

ここでの相関とは、ある二つのメトリクスを組とすると、一方のメトリクスの時間変化に対して他方のメトリクスの値が比例して変化する場合（正の相関）または半比例して変化する場合（負の相関）に高くなり、値の変化が同調していなければ低くなる量である。

相関行列２２１は一般に対称行列であり、その行または列方向を新たなベクトルとみなし、所定のリソースグループ数２２２によってクラスタリング２２３することで相関の高いメトリクス同士を同じグループ（クラスタ）に分類する。

このようにグループに属するリソースの組、またはリソースに付随するメトリクスの組をリソースグループと定義する。算出されたリソースグループは、図８に示したリソースグループ管理テーブル２０１ｅのような形式で表現される。

図１に示した計算機システムにおいて複数のストレージ装置１００が接続される場合には、ストレージ装置１００の識別子を別途組み合わせるか、リソースＩＤが複数のストレージ装置１００をまたがって唯一となるよう付与されてもよい。

図５に示したストレージ性能情報２１１のように、リソースは複数のメトリクスを持つ。各リソースの複数のメトリクスについてリソースグループを計算してもよいが、同一リソースの複数のメトリクスは当然に相関が高いものとみなせるので、代表的なメトリクス（代表メトリクス）が一つ選び出され、相関行列が計算されてもよい。

代表メトリクスの選び方は、少なくとも同じリソース種別に対して共通であるとする。例えば、あるストレージポートＡの代表メトリクスをＩＯＰＳとしたとき、その他のストレージポートＢ以降も代表メトリクスをＩＯＰＳとする。

一つのリソースに対して複数のメトリクスを用いて計算した場合には、異なるリソースグループに単一のリソースが重複して選択される（同一リソースのメトリクスが異なるグループにクラスタリングされる）可能性がある。

一方で、代表メトリクスとしてリソース毎に一つのメトリクスを用いて相関を計算した場合には、リソースが重複なくグループ化される。ただし、代表メトリクスを用いる場合は、同じリソースに属するメトリクスがすべて同一のリソースグループに属するものとする。

リソースグループの数２２２は、数理モデルの学習に用いるデータの次元数が数理モデルの精度に関わるため、計算機システムの構成に合わせて適切に定めるのが望ましい。そもそも、ワークロードの特性を加味するというのが、本実施例の基本的なアプローチである。

このアプローチからすれば、ユーザや用途が独立しているワークロードの数（アプリケーション１３数や複数のアプリケーションから構成されるシステム数）を用いて、リソースグループの数２２２を決定することが適切な可能性が高い。

しかしながら、前述のようにストレージ装置１００内にはストレージポート６１のような、より少数でかつ共有される構造があり、共有される構造では互いに影響を受けるため、ストレージ装置１００を使用するワークロードは独立でない。

さらに、アプリケーション１３の情報はインスタンス構成管理プログラム２０６のようにストレージ管理プログラム群の外で管理されており、ストレージ性能分析プログラム２０１はワークロードの影響範囲を判別できない。そこで本実施例では、ストレージ装置１００内の各部を複数のリソース階層に分けた時に最小であるリソースの要素数を用いてリソースグループの数２２２を決定する。

図１０は、リソース階層とリソースグループの例を示す図である。図１０に示すように、ストレージ装置１００を構成する各リソースは任意に接続されるのではなく、階層的に接続される。

ストレージ装置１００は、各ストレージポート６１からなるストレージポート層５００ａ、キャッシュ１５３の各割り当て領域５０１ｂからなるキャッシュ層５００ｂ、各プロセッサ１５１のコア５０１ｃからなるプロセッサ層５００ｃ、およびストレージ機能の実行プロセス５０１ｄからなるストレージ機能層５００ｄの各階層を含む。

さらにストレージ装置１００は、各ボリューム１０１からなるボリューム層５００ｅ、各ストレージプール１０６からなるストレージプール層５００ｆ、各ＲＡＩＤグループ１０４からなるＲＡＩＤグループ層５００ｇの各階層を含む。

従って、各リソース同士で相関を調べると、同じ階層内の別のリソース同士よりも、上下に接する階層それぞれにあるリソース同士で相関が高くなる。ここでは、各リソース階層の要素と相関が高く、より少数でかつ対象のリソース全体において支配的であるという意味でこの最小数のリソースを結節点と呼ぶことにする。

結節点のより実際的な例は、本実施例におけるストレージプール１０６である。ストレージプール１０６は、ボリューム１０１とＲＡＩＤグループ１０４の間にあって、入出力処理を集約する構造であるほか、ストレージプール１０６にドライブ装置１０５のメディア配分が管理される。

あるいは、本実施例において、ストレージプール１０６をユーザのテナント用環境、本番用環境、またはテスト用環境など一定用途のシステムを構築する単位として割り当てる運用が行われることがあるなど、ユーザによるシステムの使用法とある程度関連した構造であると言える。

実験的にも図１０に示すように、例えば特定のストレージプール「ＳＰ００２」に対して相関を調べると、各階層から相関の高いリソースが選出され、一つのリソースグループを構成することが多い。

本実施例ではこのように、相関の高いリソース同士が、特定のワークロードの影響を受けて動作しているものとする。結節点をリソースグループの数の決定の基本とし、さらにストレージ装置１００または計算機システムの運用に関する知見に基づく設定を利用して、例えばストレージ機能の同時稼働タスク数を結節点の数に加味してリソースグループの数を決定してもよい。

また前述のように、他のどのリソースとも相関の低いリソースを分類するためのリソースグループが設けられて、このようにして設けられたリソースグループの数が、結節点に基づく数に加算されてもよい。その他、対象の挙動を集約するようなリソース階層を選択する限りにおいて、例外的に結節点となるリソース階層が分析者により選ばれてもよい。

例えば、ストレージプール１０６の数よりも少数のプロセッサ１５１が搭載される環境（ストレージ装置１００）において、分析者がストレージプール１０６を支配的であると考えてストレージプール１０６を選択すれば、その選択によりストレージプール１０６に基づいてリソースグループの数が決定されてもよい。

より具体的には、例えばプロセッサ１５１の処理能力を多く消費するようなストレージ機能がほとんど使用されておらず、記憶領域の広範囲にわたってデータ変更が生じるような用途においては、プロセッサ１５１よりもストレージプール１０６のほうが、ストレージ装置１００の挙動を律速するリソース階層である。

一方で、共有される度合が低くワークロードを集約しないリソース階層や、リソース内の構成要素であって他のリソース階層と関連しない構成要素は、結節点として不適切である。具体的には例えば、ボリューム１０１は複数のワークロードに共有されることは少ないし、物理的に搭載されるキャッシュ１５３の回路基板の枚数は他の論理的なリソースとは直接的に関連しないという点においていずれも結節点として不適切である。

リソース階層とリソース階層に含まれるリソースのリソース識別子は、ストレージ構成管理プログラム２０４によって取得される。このために、ストレージ構成管理プログラム２０４は、一般に管理プログラムと連携するために提供されているインタフェース（ＡＰＩ）を調べることで、外部仕様となるリソース種別や名称を取得してもよい。

＜分析プログラムの処理フロー＞
図１１は、リソースグループの計算の処理フロー５１０および学習用データ２１５のモデル学習の処理フロー５１１の例を示す図である。処理フロー５１０と処理フロー５１１は同期して実行される必要はないが、処理フロー５１１において処理フロー５１０の実行により作成されたリソースグループが使用される。

処理フロー５１０では、ストレージ性能分析プログラム２０１により入力される性能データからリソースグループを算出する。処理フロー５１０が開始される契機には、例えば分析者による指示、計算機システムの構成変更の頻度に応じた定期的な起動、あるいは学習用データ２１５または評価用データ２１６の到着の検出などがある。ただし、処理フロー５１０の実行制御は分析ジョブ管理モジュール２０１ｉによる。

ステップ５１２において、グループ化計算モジュール２０１ｄは性能データを入力する。入力される性能データに対して、欠損値の処理またはスケーリングなどの前処理部２０１ａによる前処理と同じ前処理が適用されてもよい。

ステップ５１３において、グループ化計算モジュール２０１ｄはリソースグループの数を定める。リソースグループの数は、結節点が静的に与えられる場合、事前に設定され結節点の数が、そのままリソースグループの数として定められてもよい。

また、リソースグループの数が動的に変更される場合は、ストレージ構成管理プログラム２０４の実行によりストレージ構成情報２１０の情報として結節点の数が取得され、取得された結節点の数が、リソースグループの数として定められてもよい。ここで、ストレージ構成管理プログラム２０４の実行により与えられる情報は、結節点の数であって、それ以外のストレージ構成情報２１０の情報を含まなくてもよい。

ステップ５１４において、グループ化計算モジュール２０１ｄは、入力された性能データから時系列のメトリクスを抽出し、抽出されたメトリクスから相関行列を計算する。さらに、算出された相関行列をステップ５１３において定めたリソースグループの数でクラスタリングする。

ステップ５１５において、グループ化計算モジュール２０１ｄは、クラスタリングにより得られたリソースまたはメトリクスのクラスタそれぞれをリソースグループとして算出する。ここで、代表メトリクスが用いられた場合は、同一リソースに含まれる代表メトリクス以外のメトリクスも、代表メトリクスと同一リソースグループに含まれるとしてリソースグループの情報が修正される。

ステップ５１６において、グループ評価モジュール２０１ｆは、グループ化計算モジュール２０１ｄから、リソースグループの計算結果を取得し、過去に算出されたリソースグループと比較し、予め設定された閾値を超える差異がないと判定すると、処理フロー５１０の処理を完了する。

ステップ５１６において、グループ評価モジュール２０１ｆは、予め設定された閾値を超える差異があると判定すると、ステップ５１７に進む。なお過去に算出されたリソースグループが存在しない場合、すなわち初期化された直後のストレージ性能分析プログラム２０１の実行の場合、ステップ５１６の比較をせずにステップ５１７に進み。

ステップ５１７において、グループ化計算モジュール２０１ｄまたはグループ評価モジュール２０１ｆは、リソースグループの計算結果を用いてリソースグループ管理テーブル２０１ｅを更新する。

ステップ５１７が実行されてリソースグループが更新される際には、数理モデルの精度が変化することが予想されるため、ステップ５１７が実行されると数理モデルを再度作成するように処理フロー５１１が開始されてもよい。

あるいは、学習用データ２１５から数理モデルを作成するためのモデル学習の処理フロー５１１を開始する契機は、例えば分析者による指示、システムの構成変更の頻度に応じた定期的な起動、あるいは学習用データ２１５の到着の検出などであってもよい。ただし、処理フロー５１１の実行制御は分析ジョブ管理モジュール２０１ｉによる。

ステップ５１８において、ストレージ性能管理プログラム２０２が、予め設定された長さの学習用データ２１５を取得する。これにより、数理モデルの作成に十分な長さの性能データが確保される。

ステップ５１９において、前処理部２０１ａは、学習用データ２１５に対し前処理を適用する。ここでの前処理は、欠損値の処理、不正値の処理、または正規化を含むスケーリングなどデータ分析の分野で一般的な前処理のほか、学習用データ２１５に固有の処理を含んでもよい。

ステップ５２０において、前処理部２０１ａは、リソースグループ管理テーブル２０１ｅに保持されたリソースグループの定義に従い、学習用データ２１５を分割する。学習用データ２１５が分割されて部分データにされ、モデル学習の手順は部分データ毎に並列に実行される。

ステップ５２１において、モデル処理部２０１ｂのモデル学習モジュール２０１ｇは、部分データ毎に数理モデルを作成する。なお、部分データ毎に並列に実行する場合、部分データは互いに独立であるため、モデル学習として他の数理モデルの作成が完了することを待ち合わせる必要はない。

ステップ５２２において、モデル学習モジュール２０１ｇは、モデル評価モジュール２０１ｈと共有するためのモデル定義が更新される。本実施例における数理モデルは、リソースグループの定義に基づき構成される多次元空間上のクラスタ中心やクラスタの標準偏差である。数理モデルの更新が省略される条件の設定があってもよい。

図１２は、評価用データ２１６のモデル評価の処理フローの例を示す図である。図１２に示した処理フローは、評価用データ２１６の異常度を算出するためのモデル評価の処理フロー５３０と、その後処理からなる。

モデル評価の処理フロー５３０を開始する契機としては、例えば分析者による指示、システムの構成変更の頻度に応じた定期的な起動、あるいは評価用データ２１６の到着の検出などがある。ただし、処理フロー５３０および後処理の実行制御は分析ジョブ管理モジュール２０１ｉによる。

ステップ５３１において、ストレージ性能管理プログラム２０２は、評価用データ２１６を入力する。評価用データ２１６の長さは、数理モデルの要件および期待される分析対象の要件に依存する。より具体的には例えば、数理モデルが複数点の平均や時系列における差分を要求する場合は、一定度の長さが必要となる。この長さは予め設定されてもよい。

ステップ５３２において、前処理部２０１ａは、評価用データ２１６に対し前処理を適用する。ここでの前処理は、前述の学習時におけるステップ５１９と同様である。ステップ５３３において、前処理部２０１ａは、リソースグループ管理テーブル２０１ｅに保持されたリソースグループの定義に従い、評価用データ２１６を分割して部分データにする。

この分割のためのリソースグループの定義は、モデル学習時と同一である。仮に評価中にリソースグループの定義が更新された場合、分析ジョブ管理モジュール２０１ｉによって評価の処理フロー５３０が中止される。分割が完了した時点で、以降のモデル評価の手順は各部分データについて並列に実行される。

ステップ５３４において、モデル処理部２０１ｂのモデル評価モジュール２０１ｈは、部分データ毎に異常度を評価する。ここで使用される数理モデルは、モデル学習時と同一である。仮に評価中に数理モデルの定義が更新された場合には、分析ジョブ管理モジュール２０１ｉによってステップ５３４が中止される。

ステップ５３５において、後処理部２０１ｃは、異常度を大きくする要因となっているリソースを特定する。分析の要件上、要因となっているリソース（およびメトリクス）を特定する必要がない場合はステップ５３５が省略される（スキップされる）。分析の要件条の必要性は予め設定されてもよい。

また、評価用データ２１６として入力された性能データについて異常度が小さく、正常な稼動状態にあると判断できる場合にも、例えば異常度と予め設定された閾値とが比較されて異常度が小さいと判定された場合にも、ステップ５３５は省略されてよい。

ステップ５３６において、後処理部２０１ｃは、分析処理の分析結果２１７を出力する。他の管理プログラムとの連携に必要であれば、後処理部２０１ｃは、リソースグループ毎の異常度やその要因と特定されたものを列挙して分析結果２１７とし、分析結果２１７を特定のデータ構造に整形してもよいし、ユーザに提示する場合はユーザに提示するための形式に整形してもよい。

本実施例によれば、計算機システムの中で記憶装置として共有されるストレージ装置１００において、ワークロードとの関連を加味してリソース性能を効率的に分析する分析手法が提供される。様々なワークロードが混在しており、性能データも混在しているため、顕著な挙動がモデル化できない場合においても、ワークロード毎に有効な成分を抽出してモデル化することができる。

性能データ同士の相関からリソースグループを算出することにより、対象システムの厳密で完全な構成情報が入手できない場合においても、精度の高い分析が可能となる。また、部分データ毎にモデルの学習および評価を独立に行えることから、分析処理を並列化し、分析処理にかかる所要時間を短縮することができる。

本実施例においては、ストレージ装置１００を対象として性能情報の分析の例を説明したが、本実施例が提供する分析は、他の対象についても容易に拡張可能である。例えば、図１３に示すようにデータセンタを対象とする場合には、ストレージ装置１００の他、サーバ装置１０、ネットワークスイッチ５５０、電源装置５５１、および図示を省略した空調設備などのファシリティも分析の対象となるように拡張可能である。

図１３に示した例では、例えば装置の種別が同じ装置は同じ階層としてリソースの階層を定義し、ネットワークスイッチ５５０またはＶＬＡＮ ＩＤなどを結節点とすることでリソースグループが定義されてもよい。

さらには、図１３に示したデータセンタにネットワーク仮想化技術またはストレージ仮想化技術と組み合わせられた場合、コントローラアプライアンスを結節点とすることで、リソースグループが定義され、その定義されたリソースグループを用いて、本実施例で説明した分析を適用してもよい。

例えば図１４に示すように、分散ソフトウェアストレージ環境の実装例では、サーバ装置１０ｃ、１０ｄに仮想マシンインスタンス１１ｃ、１１ｄと共存する形で、あるいはサーバ装置１０ｅを占有する形で、分散ストレージコントローラ５６０が一種の仮想マシンとして稼動し、サーバ装置１０ｃ〜１０ｅ内蔵のドライブ装置が、ＬＡＮ５０に接続された図示省略の各ノードへ共有可能なボリューム５６１として提供される。

図１４のような場合は、複数のサーバ装置１０の連携により記憶領域が提供され、データの保存先も動的に変更されるが、例えば分散ストレージコントローラ５６０を結節点としてリソースグループが定義され、本実施例で説明した分析を適用することで、ワークロードの特性が反映されたモデル化が可能である。

一般にデータセンタ内には、多数かつ提供者が異なるハードウェアやソフトウェアが混在するため、管理体系と論理構成が一様でなく、データセンタ内のシステムの詳しい構成情報を得ることが困難である。そのような場合であっても、本実施例のようにリソースグループが定義されて分析可能となる。

以上で説明したように、大規模な次元数の大きい性能データの分析を、より低次元数かつ複数の部分問題に変換することが可能になるので、モデル化の精度を向上できる。また、使用するデータの局所化により、分析処理を実行する管理コンピュータのリソースを効率的に利用でき、分析処理の並列化により求解にかかる所要時間を短縮できる。

さらには、完全な構成情報を必要としないため、構成情報が不足している場合や誤っている場合、最新の構成情報が入手できない場合などにおいても、精度の高いモデル化が可能である。関連性の高いものの組み合わせの変化を検出することによって、リソース構成の変更やワークロードの変更が行われたことを推定することも可能となる。

２０１：ストレージ性能分析プログラム
２０１ａ：前処理部
２０１ｂ：モデル処理部
２０１ｄ：グループ化計算モジュール
２０１ｅ：リソースグループ管理テーブル

Claims (13)

1. 管理計算機による計算機システムの性能分析方法であって、
   前記管理計算機は、
   プロセッサと、
   前記プロセッサが実行するプログラムが格納された記憶装置とを備え、
   前記計算機システムは、
   複数のリソースから構成され、
   前記プロセッサは、
   前記リソース間の性能データの変化の相関に基づき、前記複数のリソースを複数のリソースグループに分割し、
   分割された前記リソースグループ毎に性能データを分析すること
   を特徴とする性能分析方法。
2. 請求項１に記載の性能分析方法であって、
   前記複数のリソースは、複数の階層で構成され、前記複数の階層のうちの一つの階層に属するリソースを結節点とし、
   前記プロセッサは、
   前記リソースグループの数を前記結節点の数に基づき決定し、
   前記リソース間の性能データの変化の相関と、前記結節点の数とに基づき、前記複数のリソースを前記複数のリソースグループに分割すること
   を特徴とする性能分析方法。
3. 請求項２に記載の性能分析方法であって、
   前記計算機システムは、
   前記複数のリソースが複数のリソース階層を構成し、
   前記プロセッサは、
   前記リソースグループの数を、前記リソース階層毎のリソースの数の最小数を結節点の数とすること
   を特徴とする性能分析方法。
4. 請求項２に記載の性能分析方法であって、
   前記計算機システムは、
   複数のストレージプールを備えたストレージ装置を備え、
   前記プロセッサは、
   前記複数のストレージプールの数を前記結節点の数とすること
   を特徴とする性能分析方法。
5. 請求項２に記載の性能分析方法であって、
   前記プロセッサは、
   予め設定された数を前記結節点の数とすること
   を特徴とする性能分析方法。
6. 請求項２に記載の性能分析方法であって、
   前記プロセッサは、
   前記リソースの性能データとして、前記リソース毎に複数のメトリクスの値を、前記計算機システムから取得し、
   取得された前記メトリクス毎の値を時系列に蓄積し、
   蓄積された前記メトリクスの値の時刻の経過に従った変化と、蓄積された他の前記メトリクスの値の時刻の経過に従った変化との相関を計算することにより、前記リソース間の性能データの変化の相関を得ること
   を特徴とする性能分析方法。
7. 請求項６に記載の性能分析方法であって、
   前記プロセッサは、
   蓄積された一つの前記リソースの前記複数のメトリクスの中から一つの代表メトリクスを選択することにより、蓄積された前記複数のリソースそれぞれの前記代表メトリクスを選択し、
   前記代表メトリクスの値の時刻の経過に従った変化と、他の前記代表メトリクスの値の時刻の経過に従った変化との相関を計算することにより、前記リソース間の性能データの変化の相関を得ること
   を特徴とする性能分析方法。
8. 請求項７に記載の性能分析方法であって、
   前記プロセッサは、
   前記代表メトリクスの値の時刻の経過に従った変化と、他の前記代表メトリクスの値の時刻の経過に従った変化との相関を計算することにより、前記リソース間の性能データの変化の相関を得て、
   得られた前記リソース間の性能データの変化の相関に基づき、複数の前記代表メトリクスを前記複数のリソースグループに分割し、
   前記代表メトリクスそれぞれの属する前記リソースの他の前記メトリクスを、前記代表メトリクスそれぞれと同じ前記リソースグループに分割することにより、前記複数のリソースを前記複数のリソースグループに分割すること
   を特徴とする性能分析方法。
9. 請求項６に記載の性能分析方法であって、
   前記プロセッサは、
   前記複数のリソースグループを記録し、
   記録された前記複数のリソースグループを比較し、
   比較された前記複数のリソースグループに、予め設定された閾値を超える差異があれば、性能データを分析するための前記リソースグループを変更すること
   を特徴とする性能分析方法。
10. 請求項９に記載の性能分析方法であって、
    前記プロセッサは、
    分割された前記リソースグループ毎に学習して数理モデルを作成し、
    作成された数理モデルを用いて、分割された前記リソースグループ毎に評価することにより、性能データを分析すること
    を特徴とする性能分析方法。
11. 請求項１０に記載の性能分析方法であって、
    前記プロセッサは、
    比較された前記複数のリソースグループに、予め設定された閾値を超える差異があれば、性能データを分析するための前記リソースグループを変更し、
    前記リソースグループの変更が、前記評価の途中であれば、前記評価を中止すること
    を特徴とする性能分析方法。
12. 複数のリソースから構成される計算機システムを性能分析する管理計算機であって、
    前記管理計算機は、
    プロセッサと、
    前記プロセッサが実行するプログラムが格納された記憶装置とを備え、
    前記プロセッサは、
    前記リソース間の性能データの変化の相関に基づき、前記複数のリソースを複数のリソースグループに分割し、
    分割された前記リソースグループ毎に性能データを分析すること
    を特徴とする管理計算機。
13. 請求項１２に記載の管理計算機であって、
    前記複数のリソースは、複数の階層で構成され、前記複数の階層のうちの一つの階層に属するリソースを結節点とし、
    前記プロセッサは、
    前記リソースグループの数を前記結節点の数に基づき決定し、
    前記リソース間の性能データの変化の相関と、前記結節点の数とに基づき、前記複数のリソースを前記複数のリソースグループに分割すること
    を特徴とする管理計算機。

Images