JP2022124054A - ストレージシステム、ストレージ装置及びストレージ装置管理方法 - Google Patents

Abstract

【課題】ストレージ装置の状態に応じた適正な運用を実現すること。【解決手段】ネットワーク経由で接続されたホストに第１のボリュームを提供する第１のストレージ装置と、前記第１のボリュームのリモートコピー先である第２のボリュームを含む複数のボリュームを提供する第２のストレージ装置とを有するストレージシステムであって、前記第２のストレージ装置の前記第２のボリューム及び他の前記複数のボリュームのサービス品質に係る規定群であるポリシーセットを複数記憶する記憶部と、前記第１のボリューム及び前記第２のストレージ装置の状態に応じて、複数の前記ポリシーセットから使用するポリシーセットを選択するポリシー選択部とを備えたことを特徴とする。かかる構成及び動作によれば、フェイルオーバーの前後や、縮退の有無などに応じたポリシーセットを選択して、ストレージ装置の運用を適正に行うことができる。【選択図】図９

Description

本発明は、ストレージシステム、ストレージ装置及びストレージ装置管理方法に関する。

企業内で利用されるストレージシステムでは、一般的に１以上の装置を冗長に構成し、システムの可用性や信頼性を向上させて運用される。

特許文献１には、可用性を向上させることができるストレージシステムが開示される。特許文献１によれば、第１のストレージ装置の第１のボリュームと、第２のストレージの第２のボリュームとは同一のボリュームとしてホストに提供される。この結果、ホストからは、前記第１のボリュームと第２のボリュームは違う経路を経由して接続される同一のボリュームとして認識することができる。

特許文献２には、第１のストレージ装置の第１のボリュームと第２のストレージ装置の第２のボリュームとがそれぞれ同じ仮想ＩＤをホスト計算機に応答するＨｉｇｈＡｖａｉｌａｂｉｌｉｔｙ（ＨＡ）ペア構成が開示されている。

特許文献２によれば、第１ストレージ装置または第２ストレージ装置が、仮想ＩＤをコピー先として指定したデータコピー指示をホストから受信すると、コピー先ボリュームが存在するストレージ装置に応じて、第１ボリュームまたは第２ボリュームのいずれかをコピー元ボリュームとして選択し、コピー元ボリュームからコピー先ボリュームにデータをコピーする。

また、ストレージシステムにおいては、ストレージ装置に接続される特定のホストやボリュームからのアクセスを他のホストやボリュームへのアクセスよりも優先的に処理することにより、一定の帯域や性能といったサービスレベル保証（ＳＬＡ）を実現するＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）機能が広く実装されている。

米国特許出願 第２００９／０２７１５８２号明細書 国際公開 第２０１５／１８９９２５号

第１のストレージ装置の第１のボリューム（以降、Ｐｒｉｍａｒｙ Ｖｏｌｕｍｅ （ＰＶＯＬ）と呼ぶ）と、第２のストレージ装置の第２のボリューム（以降、Ｓｅｃｏｎｄａｒｙ Ｖｏｌｕｍｅ （ＳＶＯＬ）と呼ぶ）との間でＨＡペアを構成することにより、例えば、前記第１のストレージ装置で障害が発生し、前記ＰＶＯＬへのアクセスが不能となった場合でも、アクセス先ボリュームを前記ＰＶＯＬから前記ＳＶＯＬに自動的に切り替え（フェイルオーバー）されることで、ホストはその運用を継続できる。

しかしながら、フェイルオーバーのみを目的として、前記第１のストレージ装置と同一の構成を持つ前記第２のストレージ装置として備えておくことは運用コストが高い。

そこで企業では、前記第２のストレージ装置をより効率的に活用するため、前記第２のストレージ装置はＨＡペアにおけるフェイルオーバー先として以外にも、前記第１のボリュームのデータバックアップソースとしての利用や、データの参照を目的としたバッチ処理、開発・テストなどの前記第１のストレージ装置や前記ＰＶＯＬを利用するホストへの影響なく実施されることが好ましい、２次的な目的で活用することで効率化を図る運用がなされる場合がある。

このような運用において、例えば前記ＰＶＯＬについて、ＩＯ性能や帯域を保証するＳＬＡをする目的でＱｏＳ設定することを考えた場合、前述の通り、前記第１のストレージ装置の障害発生時においても、前記第２のストレージ装置にフェイルオーバーされることでホストの運用が継続されるフェイルオーバー後の運用を考慮すると、前記ＰＶＯＬに適用したＱｏＳ設定を前記ＳＶＯＬにおいても同様に適用したいと想定される。

しかし、前記のＱｏＳ設定は前記第１のストレージ装置の装置性能や利用状況に基づいて設計されるものであり、たとえ、前記第１のストレージ装置と前記第２のストレージ装置の装置構成が同一だとしても、その利用状況や負荷状況は異なるものであると考えられる。このため、前記第２のストレージ装置において前記のＱｏＳ設定を同様に適用しても、フェイルオーバー後に第２のストレージ装置においてＱｏＳ設定が意図通りのＳＬＡを満たせるとは限らない。

このため、前記第１のストレージ装置から前記第２のストレージ装置へフェイルオーバーする場合において、前記第１のストレージ装置において実現されるＳＬＡを満たせるよう、前記第２のストレージ装置においてＱｏＳを設定することが求められる。また、フェイルオーバーに限らず、ストレージ装置に部分的な障害が生じた縮退の発生によりストレージ装置の状態が変化した場合にも、かかる変化に応じて適切なＱｏＳの設定を用いることが望ましい。時刻や曜日などでストレージ装置の処理量が異なる場合にも同様である。
そこで、本願発明は、ストレージ装置の状態に応じた適正な運用を実現する技術について開示する。

代表的な本発明のストレージシステムの一つは、ネットワーク経由で接続されたホストに第１のボリュームを提供する第１のストレージ装置と、前記第１のボリュームのリモートコピー先である第２のボリュームを含む複数のボリュームを提供する第２のストレージ装置とを有するストレージシステムであって、前記第２のストレージ装置の前記第２のボリューム及び他の前記複数のボリュームのサービス品質に係る規定群であるポリシーセットを複数記憶する記憶部と、前記第１のボリューム及び前記第２のストレージ装置の状態に応じて、複数の前記ポリシーセットから使用するポリシーセットを選択するポリシー選択部とを備えたことを特徴とする。
また、代表的な本発明のストレージ装置の一つは、ネットワーク経由で接続されたホストにボリュームを提供するストレージ装置であって、前記ボリュームのサービス品質に係る規定群であるポリシーセットを複数記憶する記憶部と、自装置の状態に応じて複数の前記ポリシーセットから使用するポリシーセットを選択するポリシー選択部とを備えたことを特徴とする。
また、代表的な本発明のストレージ装置管理方法の一つは、ネットワーク経由で接続されたホストに第１のボリュームを提供する第１のストレージ装置と、前記第１のボリュームのリモートコピー先である第２のボリュームを含む複数のボリュームを提供する第２のストレージ装置とを管理するストレージ装置管理方法であって、前記第２のストレージ装置の前記第２のボリューム及び他の前記複数のボリュームのサービス品質に係る規定群であるポリシーセットを記憶部に複数格納するステップと、前記第１のボリューム及び前記第２のストレージ装置の状態を判定するステップと、前記第１のボリューム及び前記第２のストレージ装置の状態に応じて、複数の前記ポリシーセットから使用するポリシーセットを選択するステップとを含むことを特徴とする。

本発明によれば、ストレージ装置の状態に応じた適正な運用を実現することができる。前記した以外の課題、構成および効果は、以下の実施例の説明により明らかにされる。

ストレージ装置 ＨＡペア構成におけるフェイルオーバー 管理情報 ＬＤＥＶ管理テーブル ＨＡペア管理テーブル ＱｏＳポリシー管理テーブル ＱｏＳポリシーＧｒ管理テーブル ＬＤＥＶ稼働情報テーブル ＨＡペアの状態に応じたＱｏＳポリシー自動適用フロー ＱｏＳポリシリスク検知フロー

本発明の実施例について、図面を参照して説明する。

なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、実施例の中で説明されている要素の組み合わせの全てが発明の解決手段に必須であるとは限らない。また、以下の説明では、「ｘｘｘテーブル」、「ｘｘｘ リスト」、「ｘｘｘＤＢ」、「ｘｘｘキュー」等の表現で各種の情報を説明することがあるが、各種情報はテーブル、リスト、ＤＢ、キュー、等以外のデータ構造で表現されていてもよい。そのため、データ構造に依存しないことを示すため、「ｘｘｘのテーブル」、「ｘｘｘリスト」、「ｘｘｘＤ Ｂ」、「ｘｘｘキュー」等を「ｘｘｘ情報」と称することがある。

さらに、以下の説明では各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

また、以下の説明では、後述する本発明の実施例は、汎用コンピュータ上で稼動するソフトウエアで実装してもよいし、専用ハードウエア又はソフトウエアとハードウエアの組み合わせで実装してもよい。

また、以下の説明では、「プログラム」を主語として処理を説明することがあるが、プログラムはプロセッサ（例えば、ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ） によって実行されることによって、定められた処理を記憶資源（例えば、メモリ）、通信Ｉ／Ｆ、ポートを用いて処理を実行するため、プロセッサを主語として説明してもよい。

また、以下の説明では、プログラムを主語として説明された処理は、プロセッサを有する計算機（例えば、計算ホスト、ストレージ装置）が行う処理としてもよい。また、以下の説明では、「コントローラ」の表現で、プロセッサ又はプロセッサが行う処理の一部又は全部を行うハードウエア回路を指してもよい。プログラムは、プログラムソース（例えば、プログラム配布サーバや、計算機が読み取り可能な記憶メディア）から各計算機にインストールされてもよい。この場合、プログラム配布サーバはＣＰＵと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶している。そして、配布プログラムをＣＰＵが実行することで、プログラム配布サーバのＣＰＵは配布対象のプログラムを他の計算機に配布する。

また、以下の説明では、「ＰＤＥＶ」は、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよい。ＰＤＥＶは、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）でよい。ストレージシステムに異なる種類のＰＤＥＶが混在していてもよい。

また、以下の説明では、「ＲＡＩＤ」は、Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓの略である。ＲＡＩＤグループは、複数のＰＤＥＶ（典型的には同種のＰＤＥＶ）で構成され、そのＲＡＩＤグループに関連付けられたＲＡＩＤレベルに従いデータを記憶する。ＲＡＩＤグループは、パリティグループ（Ｐａｒｉｔｙ Ｇｒｏｕｐ ： ＰＧ）と呼ばれてもよい。パリティグループは、例えば、パリティを格納するＲＡＩＤグループのことでよい。

また、以下の説明では、「ＶＯＬ」はボリュームの略であり、物理的な記憶デバイスまたは、論理的な記憶デバイスでもよい。ＶＯＬは、実体的なＶＯＬ（ＲＶＯＬ）であってもよいし、仮想的なＶＯＬ（ＶＶＯＬ）であってもよい。「ＲＶＯＬ」は、そのＲＶＯＬを有するストレージシステムが有する物理的な記憶資源（例えば、１以上のＲＡＩＤグループ）に基づくＶＯＬでよい。「ＶＶＯＬ」は、外部接続ＶＯＬ（ＥＶＯＬ）と、容量拡張ＶＯＬ（ＴＰＶＯＬ）と、スナップショットＶＯＬとのうちのいずれでもよい。ＥＶＯＬは、外部のストレージシステムの記憶空間（例えばＶＯＬ）に基づいており、ストレージ仮想化技術に従うＶＯＬでよい。ＴＰＶＯＬは、複数の仮想領域（仮想的な記憶領域）で構成されており容量仮想化技術（典型的にはＴｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ）に従うＶＯＬでよい。

また、以下の説明では、「プール（ＰＯＯＬ）」は、論理的な記憶領域（例えば複数のプールＶＯＬの集合）であり、用途ごとに用意されてよい。例えば、プールとして、ＴＰプールと、スナップショットプールとのうちの少なくとも１種類があってよい。ＴＰプールは、複数のページ（実体的な記憶領域）で構成された記憶領域でよい。ストレージコントローラが、ホストシステム（以下、ホスト）から受信したライト要求が指定するアドレスが属する仮想領域（ＴＰＶＯＬの仮想領域）にページが割り当てられていない場合、その仮想領域（ライト先仮想領域）にＴＰプールからページを割り当てる（ライト先仮想領域にページが割り当て済であってもページが新たにライト先仮想領域に割り当てられてもよい）。ストレージコントローラは、割り当てられたページに、そのライト要求に付随するライト対象データを書き込んでよい。スナップショットプールは、オリジナルのＶＯＬから退避されたデータが格納される記憶領域でよい。１つのプールが、ＴＰプールとしてもスナップショットプールとしても使用されてもよい。「プールＶＯＬ」は、プールの構成要素となるＶＯＬでよい。プールＶＯＬは、ＲＶＯＬであってもよいしＥＶＯＬであってもよい。

また、以下の説明では、ホストから認識されるＶＯＬ（ホストに提供されるＶＯＬ）を「ＬＤＥＶ」と言う。以下の説明では、ＬＤＥＶは、ＴＰＶＯＬ（又はＲＶＯＬ）であり、プールは、ＴＰプールである。しかし、本発明は、容量拡張技術（Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇ）が採用されていないストレージ装置にも適用できる。

また、以下の説明では、「ＰＶＯＬ（Ｐｒｉｍａｒｙ ＶＯＬ）」はバックアップ、レプリケーション、スナップショットの元ボリュームとなるＬＤＥＶのことであり、「ＳＶＯＬ（Ｓｅｃｏｎｄａｒｙ ＶＯＬ）」はバックアップ、レプリケーション、スナップショット先となるＬＤＥＶのことで良い。

以下、本実施形態を詳細に説明する。

図１は、本実施例に係るストレージ装置の構成例を示す。

ストレージ装置１００に、ネットワーク１１０を介して１以上のホスト１０７が接続されている。また、ストレージ装置１００に管理システム１０８が接続されている。ネットワーク１１０は例えばＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）やｉＳＣＳＩ （Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）である。

ホスト１０７は、ホストシステムの略であり、１以上のホストである。ホスト１０７は、Ｈ－Ｉ／Ｆ ホストインタフェース１０９を有しており、ホストインタフェース１０９経由で、アクセス要求（ライト要求又はリード要求）をストレージ装置１００に送信したり、アクセス要求の応答（例えば、ライト完了を含んだライト応答、又は、リード対象チャンクを含んだリード応答）を受信したりする。ホストインタフェース１０９は、例えば、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）又はＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）である。

ストレージ装置１００は、複数のドライブ１０１と、複数のドライブ１０１に接続されたストレージコントローラ１０６とを有する。複数のドライブ１０１を含んだ１以上のＲＡＩＤグループが構成されていてよい。

管理システム１０８は、ストレージ装置１００の構成及び状態を管理する。管理システム１０８、Ｍ－Ｉ／Ｆ 管理インタフェースデバイス１２０を有しており、管理インタフェースデバイス１２０が接続される管理ネットワーク１１１経由で、ストレージ装置１００に命令を送信したりその命令の応答を受信したりする。管理インタフェースデバイス１２０は、例えばＮＩＣである。

また、管理システム１０８はストレージ装置１００を管理するサーバやＰＣ上で実行されるソフトウエアで良いし、ストレージ装置１００に接続されるホスト１０７の管理を行うセキュリティアプライアンスやソフトウエアの機能として実装されても良い。

統合管理システム１２１は、複数の拠点における複数のストレージ装置１００の構成及び稼働状態の管理や監視を行う、例えばクラウド１１９上で実行される管理ソフトウエアである。統合管理システム１２１は管理ネットワーク１１１を経由して、管理対象のストレージ装置１００と通信し、各々のストレージ装置１００の構成情報や稼働情報を収集する。

管理用コントローラ１１８は、ストレージ装置１００を管理するための機能を提供するコントローラであり、管理システム１０８や統合管理システム１２１から命令を受信したり、命令へ応答を返信し、管理システム１０８や統合管理システム１２１にストレージ装置１００の構成情報や稼働情報を送信したり、ストレージ装置１００の設定や構成の変更を実行する。管理用コントローラ１１８は、例えばＢａｓｅｂｏａｒｄ Ｍｉｃｒｏ Ｃｏｎｔｒｏｌｌｅｒ（ＢＭＣ）である。

ストレージコントローラ１０６は、Ｆ－Ｉ／Ｆ フロントエンドインタフェース１１６と、Ｂ－Ｉ／Ｆ バックエンドインタフェース１１７と、Ｒ－Ｉ／Ｆ レプリケーションインタフェース１２２と、ＣＭ キャッシュメモリ１０５と、ＮＶＲＡＭ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ ＲＡＭ）１０４と、プロセッサパッケージ１１３Ａ及びプロセッサパッケージ１１３Ｂと、それらの要素間の通信を中継する中継器１１２とを有する。中継器１１２は、例えばバス又はスイッチである。

フロントエンドインタフェース１１６は、ストレージ装置１００に接続されるホスト１０７と通信するインタフェースであり、例えば、ＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）やｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）のインタフェースである。

バックエンドインタフェース１１７は、ドライブ１０１と通信するインタフェースである。バックエンドインタフェース１１７は、Ｅ／Ｄ回路（暗号化及び復号化のためのハードウェア回路）を含んでいてよい。具体的には、例えば、Ｂ－Ｉ／Ｆバックエンドインタフェース１１７は、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ （Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）コントローラを含んでいてよく、ＳＡＳコントローラが、Ｅ／Ｄ回路を含んでいてよい。

レプリケーションインタフェース１２２は、複数のストレージ装置１００の間においてＨＡ構成を構成する際に用いるインタフェースであり、ネットワーク１１０を介して、ＨＡを構成する他のストレージ装置１００と接続される。レプリケーションインタフェース１２２は、例えば、ＦＣやｉＳＣＳＩである。

ＣＭキャッシュメモリ１０５（例えばＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）には、ドライブ１０１に書き込まれるデータ又はドライブ１０１から読み出されたデータがプロセッサパッケージ１１３により一時格納される。ＮＶＲＡＭ１０４には、電断時にバッテリ（図示せず）から電力を受けたプロセッサパッケージ１１３によりキャッシュメモリ１０５内のデータ（例えばダーティデータ（ドライブ１０１に書き込まれていないデータ））が退避される。

ストレージコントローラ１０６は、プロセッサパッケージ１１３Ａ及びプロセッサパッケージ１１３Ｂによりクラスタが構成されている。プロセッサパッケージ１１３Ａ（プロセッサパッケージ１１３Ｂ）は、ＤＲＡＭ１１５Ａ（ＤＲＡＭ１１５Ｂ）と、ＣＰＵ１１４Ａ（ＣＰＵ１１４Ｂ）とを有する。ＤＲＡＭ１１５Ａ（ＤＲＡＭ１１５Ｂ）には、ＣＰＵ１１４Ａ（ＣＰＵ１１４Ｂ）に実行される制御プログラム１０２Ａ（制御プログラム１０２Ｂ）と、ＣＰＵ１１４Ａ（ＣＰＵ１１４Ｂ）により参照又は更新される管理情報１０３Ａ（管理情報１０３Ｂ）とが格納される。ＣＰＵ１１４Ａ（ＣＰＵ１１４Ｂ）に制御プログラム１０２Ａ（制御プログラム１０２Ｂ）が実行されることにより、例えば、ストレージ装置１００のＩ／Ｏ処理、アドレスの変換処理が実行される。制御プログラム１０２Ａ（制御プログラム１０２Ｂ）及び管理情報１０３（管理情報１０３Ｂ）のうちの少なくとも一方が、複数のプロセッサパッケージ１１３Ａ及びプロセッサパッケージ１１３Ｂに共有の記憶領域（例えばＣＭ１０５）に格納されてもよい。

＜ＨＡペア構成におけるフェイルオーバーの例＞

図２は、本実施例に係るＨＡペア構成におけるフェイルオーバーの構成例を示す。

ここでは、複数のストレージ装置１００の間で構成したＨＡペア構成において、フェイルオーバーを行う例を示し、本願技術が解決したい課題について具体例を用いて説明する。

図２は、ストレージ装置１００Ａとストレージ装置１００Ｂの間において、ＨＡペア構成が構成されており、ストレージ装置１００ＡのＰＶＯＬ２０１Ａ及びＰＶＯＬ２０１Ｂが、ペア装置のストレージ装置１００ＢのＳＶＯＬ２００Ａ及びＳＶＯＬ２００Ｂに各々ペアとして関連付けられている。

また、ＰＶＯＬ２０１Ａに関連付けられたＳＶＯＬ２００Ａ、ＰＶＯＬ２０１Ｂに関連付けられたＳＶＯＬ２００Ｂ間は、ネットワーク１１０を介したリモートコピー２０４により内容が同期される。この際の同期方式はＰＶＯＬ２０１Ａ、ＰＶＯＬ２０１Ｂへのデータ更新と同期する方式でも良いし、非同期でＰＶＯＬ２０１Ａ、ＰＶＯＬ２０１Ｂへの更新差分データをＳＶＯＬ２００Ａ、ＳＶＯＬ２００Ｂに反映する方式でも良い。

ここで、一般的な構成例としては、ストレージ装置１００Ａとストレージ装置１００Ｂは、システムの可用性を考慮して各々の装置が物理的に距離のある拠点にされていても良いし、近接距離、例えば、同じデータセンタ内に同床して設置されていても良い。

また、ストレージ装置１００Ａでは、ホスト１０７Ａ、ホスト１０７Ｃがストレージ装置１００Ｂでは、ホスト１０７Ａ、ホスト１０７Ｄ、ホスト１０７Ｅがそれぞれ対応するＶＯＬとの間にパスを形成し接続され運用されている。

また、統合管理システム１２１は管理ネットワーク１１１を介してストレージ装置１００Ａおよびストレージ装置１００Ｂの構成情報や性能情報を定期的に監視しており、ストレージ管理者は統合管理システム１２１を介して各ストレージ装置の状態監視や、統合管理システム１２１への指示により各ストレージ装置の構成や設定変更を行うことができる。

また、ホスト１０７Ａでは可用性が要求されるような重要なアプリケーションが実行されており、運用の可用性を担保するため、ネットワーク１１０を介して、ペアを構成するストレージ装置１００ＡのＰＶＯＬ２０１ＡとＰＶＯＬ２０１Ｂおよびストレージ装置１００ＢのＳＶＯＬ２００ＡとＳＶＯＬ２００Ｂとの間にアクセス可能なパスが定義される。

通常時ホスト１０７ＡはＰＶＯＬ２０１ＡとＰＶＯＬ２０１Ｂにアクセスすることで運用されるが、例えば、ストレージ装置１００Ａが障害などでＰＶＯＬ２０１ＡやＰＶＯＬ２０１Ｂへのアクセスが不能な場合は、フェイルオーバー２０５により、ストレージ装置１００ＢのＳＶＯＬ２００ＡやＳＶＯＬ２００Ｂへアクセス先を切り替えることにより運用を継続することで可用性を担保した運用がなされる。

ここで、フェイルオーバー２０５はＨＡペアを構成するストレージ装置１００により障害が検知され、ストレージ装置１００Ａがホスト１０７Ａに通知することでホスト１０７Ａによりフェイルオーバー２０５が実行されても良いし、ホスト１０７Ａによる都合でフェイルオーバー２０５が実行されても良い。

以上のような構成において、例えば、可用性が要求されるような重要なアプリケーションが実行されているホスト１０７Ａに対しては、性能安定性の観点から、そのアクセスに対するＩ／Ｏ帯域やＩＯ Ｐｅｒ Ｓｅｃｏｎｄ （ＩＯＰＳ） などの一定のサービスレベルを保証したい場合が考えられる。そこで、ＰＶＯＬ２０１Ａ、ＰＶＯＬ２０１Ｂに対してＱｏＳの設定を行うことで、装置を共有するＶＯＬ２０２Ｃへのアクセスにより、ホスト１０７Ａのアクセスが阻害されることを防ぎ、サービスレベルを一定に保つことを行う。

また、ホスト１０７Ａはフェイルオーバー２０５を実行することで、そのアクセス先をＨＡペアであるＳＶＯＬ２００Ａ、ＳＶＯＬ２００Ｂに切り替えることがあるが、その場合においても、ＰＶＯＬ２０１Ａ、ＰＶＯＬ２０１Ｂと同様のサービスレベルをＳＶＯＬ２００Ａ、ＳＶＯＬ２００Ｂにおいて保証したい場合があると考えられる。

しかしながら既に説明した通り、ストレージ装置１００Ａとストレージ装置１００Ｂは接続されているホストや定義されるＶＯＬ数や装置への負荷状況（ワークロード）が異なるため、ＰＶＯＬ２０１Ａ、ＰＶＯＬ２０１Ｂに設定したＱｏＳを同様にＳＶＯＬ２００Ａ、ＳＶＯＬ２００Ｂに設定したとしても、期待するサービスレベルが必ずしも維持されるとは限らない。

また、ＨＡペア構成は正副最低２以上のストレージ装置１００を必要とすることから、必然的にその運用コストが高い。このため、運用コストやストレージ装置１００の稼働率を高めて運用効率を向上させる目的で、正常時の副側装置（例えば、ストレージ装置１００Ｂ）においては、実際にフェイルオーバー２０５が実行されるまでは他の２次的な用途にも活用するような運用がなされる場合が考えられる。

そこで、本発明ではフェイルオーバーの状況に応じた複数種類のＱｏＳポリシーを予め設定しておくことで、ＨＡペア構成における副側装置（例えば、ストレージ装置１００Ｂ）においてフェイルオーバー２０５が実際に実行されるまでの間、ホスト１０７Ｄやホスト１０７Ｅにより、２次的な用途で利用されているＶＯＬ２０２Ｄ、ＶＯＬ２０２Ｅなどのアクセスを優先し、一方で、フェイルオーバー２０５が実行され、ホスト１０７Ａのアクセスがストレージ装置１００Ｂ側に切り替った場合は、ＱｏＳのポリシーを切り替えて適用し、ＳＶＯＬ２００Ａ、ＳＶＯＬ２００Ｂのアクセスを優先することで、例えば、ホスト１０７Ａが期待するサービスレベルがフェイルオーバー２０５の実行後においても維持できるようにＱｏＳを制御する。

また、統合管理システム１２１により、予め設定された複数種類のＱｏＳポリシーについて、例えば、各ストレージ装置の構成や性能情報などの稼働情報を利用した予測により、フェイルオーバー２０５実行後にサービスレベルの維持が困難であると判断する場合、ストレージ管理者にリスクを警告または実現可能なＱｏＳポリシーの提案を行うことで、フェイルオーバー２０５実行後においても、ＱｏＳポリシーの不整合やサービスレベル破綻が生じないように制御する。

なお、どのＱｏＳのポリシーを各ストレージ装置１００適用するのかを判断するのは、ストレージ装置１００自体によって行われても良いし、統合管理システム１２１により判断し、各ストレージ装置１００に対してＱｏＳの設定変更を命令する方式でも良い。

以上のようにして、ＨＡペア構成において、フェイルオーバー２０５前後の状態を加味して適切なＱｏＳを設定できるようにすることで、システムの安定稼働に必要なサービスレベルと可用性を維持しながら、フェイルオーバー２０５が実際に生じるまでの間は副側装置における運用効率を高めることができ、システム運用の効率化が図られる。

以下、本実施形態を詳細に説明する。

図３は、本願実施例のストレージ装置における管理情報の構成例を示す。

管理情報１０３は、複数の管理テーブルを含む。管理テーブルとして、例えば、ＬＤＥＶに関する情報を保持するＬＤＥＶ管理テーブル３０１、ＨＡペア構成を管理する情報を保持するＨＡペア管理テーブル３００、ＱｏＳポリシーを管理する情報を保持するＱｏＳポリシー管理テーブル３０２、複数のＱｏＳポリシーをグループとして管理するための情報を保持するＱｏＳポリシーＧｒ管理テーブル３０３、ＬＤＥＶ毎の稼働情報を管理するＬＤＥＶ稼働情報テーブル３０４、などで構成され、管理情報１０３Ａ及び管理情報１０３Ｂ間、またはストレージ装置１００Ａ及びストレージ装置１００Ｂ間で少なくとも一部の情報が同期してもよい。

図４は、本願実施例のストレージ装置の管理情報におけるＬＤＥＶ管理テーブルの構成例を示す。

ＬＤＥＶ管理テーブル３０１は、「ＰＶＯＬ」や「ＳＶＯＬ」などのＬＤＥＶ毎にエントリ（レコード）を有する。各エントリーが格納する情報は、ＬＤＥＶ番号４００、ＬＤＥＶ容量４０１、ＶＯＬ種別４０２、データ削減有効４０４、プール番号４０３、ＰＧ番号４０５および｛データ移行対象｝である。

ＬＤＥＶ番号４００は当該ＬＤＥＶの識別番号を表す。

ＬＤＥＶ容量４０１は当該ＬＤＥＶの容量を表す。

ＶＯＬ種別４０２は当該ＬＤＥＶの種別を表し、（例えば、「ＲＶＯＬ」または「ＴＰＶＯＬ」またはスナップショットのＳＶＯＬなど）を表す。

データ削減有効４０４は当該ＬＤＥＶにおいてデータ圧縮や重複排除といったデータ削減機能が有効かどうかの属性を表す。

プール番号４０３は、例えば、「ＥＶＯＬ」、「ＴＰＶＯＬ」や「ＳＶＯＬ」といった論理的な容量を持つＬＤＥＶにおいて、それらのＬＤＥＶが関連付けられているプールの識別番号を表し、プール番号４０３が関連付けられているプール内の領域からデータ格納領域が割り当てられる。一方で、例えば「ＲＶＯＬ」など物理的な容量を持つＬＤＥＶにおいては、ＬＤＥＶがプールに関連付けられることはないため「Ｎ／Ａ」となる。

ＰＧ番号４０５は、例えば「ＲＶＯＬ」など、物理的な容量を持つＬＤＥＶにおいて、関連付けられたパリティグループ（ＰＧ）の識別番号を示し、一方で、例えば「ＥＶＯＬ」、「ＴＰＶＯＬ」や「ＳＶＯＬ」といった論理的な容量を持つＬＤＥＶでは直接関連付けられるＰＧは存在しないため、「Ｎ／Ａ」となる。

図５は、本願実施例のストレージ装置の管理情報におけるＨＡペア管理テーブルの構成例を示す。

ＨＡペア管理テーブル３００は、ＨＡペア毎にエントリーを有する。各エントリーが格納する情報は、ペア番号５００、｛利用可能｝、ＰＶＯＬＬＤＥＶ番号５０２、ペア装置ＩＤ５０３、ＳＶＯＬＬＤＥＶ番号５０４、同期方式５０５、ペア状態５０６、及び仮想ＩＤ５０７といった情報を格納する。

ペア番号５００は、ストレージ装置１００が管理するＨＡペアの番号である。ＰＶＯＬＬＤＥＶ番号５０２は、ペアを構成するＰＶＯＬ２０１のＬＤＥＶ番号４００である。ペア装置ＩＤ５０３は、ＰＶＯＬＬＤＥＶ番号５０２とペア関係となるＳＶＯＬ２００の属するストレージ装置１００を識別するＩＤである。｛ＳＶＯＬＨＤＥＶ番号｝は、ＳＶＯＬの属するストレージ装置におけるＬＤＥＶ番号４００である。同期方式５０５は、ペアを構成するＰＶＯＬ２０１とＳＶＯＬ２００のデータを同期するタイミングを指定する情報で、ペアを構成するＰＶＯＬ２０１とＳＶＯＬ２００のデータをＰＶＯＬ２０１へのデータライトと同期してＰＶＯＬ２０１とＳＶＯＬ２００の内容を同期する「ＳＹＮＣ」方式と、ＰＶＯＬのデータライトとは非同期にＰＶＯＬ２０１とＳＶＯＬ２００の内容を同期する「ＡＳＹＮＣ」方式などを指定する。ペア状態５０６は、ＰＶＯＬ２０１およびＳＶＯＬ２００で構成されるペアの状態を示し、例えば、データを同期したペア状態を構成していれば「ＰＡＩＲ」であり、データを同期していないペアを構成していれば「ＰＳＵＳ」である。仮想ＩＤ５０７は、ペアを構成するＰＶＯＬ２０１とＳＶＯＬ２００を同一のＬＤＥＶとホスト１０７が認識することが可能な仮想のＬＤＥＶのＩＤである。

図６は、本願実施例のストレージ装置の管理情報におけるＱｏＳポリシー管理テーブルの構成例を示す。

ＱｏＳポリシー管理テーブル３０２は、ＱｏＳのポリシー毎にエントリを有する。各エントリーが格納する情報は、ポリシー番号６００、ＬＤＥＶ番号４００、ＩＯ種別６０１、最大ＩＯＰＳ６０２、最小ＩＯＰＳ６０３、最大帯域６０４、及び最小帯域６０５、といった情報を格納する。

ポリシー番号６００は、ＱｏＳポリシーの管理番号である。ＬＤＥＶ番号４００は、ポリシー番号６００のＱｏＳポリシーにより制御される対象のＬＤＥＶのＬＤＥＶ番号４００を示す。ＩＯ種別６０１は、ポリシー番号６００のＱｏＳポリシーにより制御されるＩＯの種類を指定する情報で、例えばＬＤＥＶに対するリードアクセスが制御対象であれば「Ｒ」、ライトアクセスが制御対象であれば「Ｗ」となる。最大ＩＯＰＳ６０２は、ＱｏＳ対象のＬＤＥＶに対して許容する最大ＩＯＰＳを指定する情報で、例えば「５０００」であれば毎秒５０００回のＩＯ処理を上限にストレージ装置１００が処理を行い、超過する場合はＩＯ処理を受け付けないことで、当該ＬＤＥＶのＩＯ処理が指定された負荷以上ならないように制御するために用いる。最小ＩＯＰＳ６０３は、ＱｏＳ対象のＬＤＥＶに対して許容する最小ＩＯＰＳを指定する情報で、例えば「２５００」であれば毎秒２５００回のＩＯ処理を最小限ストレージ装置１００が行うように制御することで、ＬＤＥＶへのＩＯアクセスを保証する。最大帯域６０４は、ＱｏＳ対象のＬＤＥＶに対して許容する最大のＩＯ帯域を指定する情報で、例えば「２００ＭＢ／ｓ」であれば２００ＭＢ／ｓのＩＯ帯域を上限にストレージ装置１００が処理を行い、超過する場合はＩＯ処理を受け付けないことで、当該ＬＤＥＶのＩＯ処理帯域が指定された負荷以上ならないように制御するために用いる。最小帯域６０５は、ＱｏＳ対象のＬＤＥＶに対して許容する最小のＩＯ帯域を指定する情報で、例えば「５０ＭＢ／ｓ」であれば５０ＭＢ／ｓのＩＯ帯域を最小限ストレージ装置１００が行うように制御することで、ＬＤＥＶへのＩＯアクセスを保証する。

図７は、本願実施例のストレージ装置の管理情報におけるＱｏＳポリシーＧｒ管理テーブルの構成例を示す。

ＱｏＳポリシーＧｒ管理テーブル３０３は、ＱｏＳの適用ポリシーをグループとして一括管理するためのテーブルであり、各エントリーが格納する情報は、ポリシーＧｒ番号７００適用条件７０１、詳細条件７０３及び適用ポリシー７０２といった情報を格納する。

ポリシーＧｒ番号７００は、複数のＱｏＳポリシーをグループとして一括管理するためのグループ番号である。適用条件７０１は、当該のＱｏＳポリシーグループを適用する条件を表し、例えば、ＨＡペアにおける正常時の副側装置（ストレージ装置１００Ｂ）では、正常時に適用するべきＱｏＳポリシーを定義する場合であれば当該フィールドは「ＨＡセカンダリ」であり、フェイルオーバー時においては「ＨＡプライマリ」となる。また、詳細条件７０３は適用条件７０１における詳細条件であり、例えば適用条件７０１が「ＨＡプライマリ」であり、詳細条件７０３が「ＣＴＬ正常」であれば、当該装置において、ＨＡペア状態がプライマリであり、ＣＴＬが正常な状態で適用するＱｏＳポリシーの定義となる。また、適用条件７０１および詳細条件７０３のフィールドは、当該エントリーのＱｏＳポリシーを適用するべき条件を表すものであるので、ＨＡペアの条件に限定される必要はなく、例えばストレージ装置１００において生じる各種のイベントや状態、時刻などに応じて様々な条件を定義できて良い。適用ポリシー７０２は、当該のＱｏＳポリシーグループにより一括適用されるポリシー番号６００の集合を表す。

図８は、本願実施例のストレージ装置の管理情報におけるＬＤＥＶ稼働情報テーブルの構成例を示す。

ＬＤＥＶ稼働情報テーブル３０４は、タイムスタンプ８０４が示す時刻毎に対応するＬＤＥＶ毎の稼働情報を格納するテーブルが対応づいており、ストレージコントローラ１０６により一定期間のＬＤＥＶ毎にその稼働情報を各エントリーの値として格納する。各エントリーが格納する情報は、ＬＤＥＶ番号４００リードＩＯＰＳ８００ライトＩＯＰＳ８０１リード帯域８０２及びライト帯域８０３といった情報を格納する。

ＬＤＥＶ番号４００は対象のＬＤＥＶのＬＤＥＶ番号４００を表す。リードＩＯＰＳ８００は、監視対象のＬＤＥＶにおける毎秒のリードＩＯの処理回数を表す。ライトＩＯＰＳ８０１は、監視対象のＬＤＥＶにおける毎秒のライトＩＯの処理回数を表す。リード帯域８０２は、監視対象のＬＤＥＶにおける毎秒のリードＩＯにより生じるデータ帯域を表す。ライト帯域８０３は、監視対象のＬＤＥＶにおける毎秒のライトＩＯにより生じるデータ帯域を表す。
＜ＨＡペアの状態に応じたＱｏＳポリシー自動適用フロー＞

図９は、本願実施例のストレージ装置におけるＨＡペアの状態に応じたＱｏＳポリシー自動適用フローの処理例を示す。

この処理フローは概して、ＨＡペア構成を構成するストレージ装置１００において、ＨＡペアの状態に応じて適切なＱｏＳポリシーを選択して適用するための処理フローである。

ステップ９００で、ＱｏＳポリシーＧｒ管理テーブル３０３を参照する。

ステップ９０１で、ストレージコントローラ１０６によりＨＡペアのＨＡ状態をチェックする。その後、ステップ９０２へ進む。

ステップ９０２で、自装置にフェイルオーバー２０５されているかどうかをチェックし、自装置がプライマリ側となっている場合はステップ９０３へ進み、自装置がセカンダリ側となっている場合はステップ９０７へ進む。

ステップ９０３で、ストレージコントローラ１０６が縮退状態になっているかどうかをチェックし、障害等が生じて縮退状態であればステップ９０４へ進み、正常であればステップ９０６へ進む。

ステップ９０４でＱｏＳポリシーＧｒ管理テーブル３０３を参照し、適用条件７０１が“ＨＡプライマリ”で詳細条件７０３が“ＣＴＬ縮退”となっている適用ポリシー７０２を選択する。その後、ステップ９０５へ進む。

また、ステップ９０６ではＱｏＳポリシーＧｒ管理テーブル３０３を参照し、適用条件７０１が“ＨＡプライマリ”で詳細条件７０３が“ＣＴＬ正常”となっている適用ポリシー７０２を選択する。その後、ステップ９０５へ進む。

一方、ステップ９０２で自装置がセカンダリ側であれば、ステップ９０７で、ストレージコントローラ１０６が縮退状態になっているかどうかをチェックし、障害等が生じて縮退状態であればステップ９０８へ進み、正常であればステップ９０９へ進む。

ステップ９０８でＱｏＳポリシーＧｒ管理テーブル３０３を参照し、適用条件７０１が“ＨＡセカンダリ”で詳細条件７０３が“ＣＴＬ縮退”となっている適用ポリシー７０２を選択する。その後、ステップ９０５へ進む。

また、ステップ９０９ではＱｏＳポリシーＧｒ管理テーブル３０３を参照し、適用条件７０１が“ＨＡセカンダリ”で詳細条件７０３が“ＣＴＬ正常”となっている適用ポリシー７０２を選択する。その後、ステップ９０５へ進む。

ステップ９０５で適用ポリシー７０２のポリシー番号６００に従って各ＬＤＥＶのＱｏＳを設定する。
＜ＱｏＳポリシリスク検知フロー＞

図１０は、本願実施例のストレージ装置におけるＱｏＳポリシリスク検知フローの処理例を示す。

この処理フローは概して、統合管理システム１２１により実行されるものであり、統合管理システム１２１は、監視対象のストレージ装置１００において構成されているＨＡペアについて、プライマリ側装置のＰＶＯＬにおいて設定されているＱｏＳ設定が、セカンダリ側装置のＳＶＯＬにおいてフェイルオーバー後に適用されるＱｏＳポリシーとして設定されているかをチェックする。チェックの結果、設定されていない場合は、統合管理システム１２１は、ストレージ管理者に警告をし、前記ＰＶＯＬにおいて設定されているＱｏＳ設定をＳＶＯＬのフェイルオーバー後に適用されるＱｏＳポリシーにとして設定する。また、統合管理システム１２１は、前記フェイルオーバー後にセカンダリ側で適用されるＱｏＳポリシーにおけるＱｏＳ設定値について、セカンダリ側のストレージ装置の処理能力が十分であるか否かをチェックし、不足であれば警告やＱｏＳ設定値の制御を行う。例えば、ＱｏＳを設定していないＬＤＥＶなどの過去の稼働率を参照し、フェイルオーバー後のＱｏＳポリシーに基づく処理がセカンダリ側のストレージ装置１００で利用可能なＩＯ帯域やＩＯＰＳを超過する場合は、ＱｏＳを設定していない高負荷なＬＤＥＶに対してＱｏＳを設定することにより、ＳＶＯＬへのフェイルオーバー後におけるＱｏＳ設定値を実現可能とする。

ステップ１０００で、統合管理システム１２１により監視対象のストレージ装置１００におけるＨＡペア管理テーブル３００を参照する。

ステップ１００１で、ＨＡペアにおけるＰＶＯＬのＬＤＥＶ番号４００を取得する。

ステップ１００２で、ＨＡペアにおけるＳＶＯＬのＬＤＥＶ番号４００を取得する。

ステップ１００３で、ＨＡペアにおけるペア装置ＩＤ５０３を取得する。

ステップ１００４で、ペア装置のＱｏＳポリシーＧｒ管理テーブル３０３を参照し、フェイルオーバー発生後のＱｏＳポリシーを取得する。具体的には、適用条件７０１が「ＨＡプライマリ」となっているエントリーの適用ポリシー７０２を取得する。

ステップ１００６で、当該ＳＶＯＬにおけるＱｏＳポリシーをＱｏＳポリシー管理テーブル３０２から取得する。

ステップ１００７で、当該ＳＶＯＬにおいてＱｏＳポリシーが設定されているかをチェックし、ＱｏＳポリシーが未設定であればステップ１００５へ進み、設定されていればステップ１００８へ進む。

ステップ１００８で、ペア装置のＬＤＥＶ稼働情報テーブル３０４を参照し、装置における稼働情報を取得する。

ステップ１００９で、ペア装置における稼働情報と現在設定されているＱｏＳポリシーＧｒ設定から、各ＬＤＥＶに対してＱｏＳポリシーで設定されている設定項目（例えば最大／最小ＩＯＰＳまたはＩＯ帯域）が装置の稼働情報を鑑みて装置能力を超過していないかを判断し、ＱｏＳポリシーで設定されている項目が実現可能かを判断する。

ステップ１０１０で、ＱｏＳポリシーで設定されている項目が実現不能、リスクが高いと判断されるである場合はステップ１０１２へ進み、実現可能と判断される場合は終了する。

ステップ１０１２で、ペア装置においてＱｏＳが設定されていないＬＤＥＶのうち、ＬＤＥＶ稼働情報から稼働率が高い高負荷なＬＤＥＶに対してＱｏＳポリシーを設定する。このときのＱｏＳポリシーの決定方法は、例えば当該ＬＤＥＶの稼働情報における平均値または前記ＱｏＳが設定されていないＬＤＥＶ全体の平均値などに基づき、ＱｏＳポリシーＧｒにより設定されるＱｏＳポリシーが装置能力を超過しない範囲の値を求めればよい。

ステップ１００５で、ストレージ管理者にＳＶＯＬにおいてＱｏＳが設定されていない旨を警告し、ペア装置にフェイルオーバー後にＳＶＯＬにおいてＳＬＡが保証されない旨を警告する。

ステップ１０１１で、ＰＶＯＬに設定されているＱｏＳポリシーを同様にＳＶＯＬに適用し、ステップ１００８～ステップ１０１０で当該ポリシーが実現可能かをチェックする。

上述してきたように、本実施例に係るストレージシステムは、ネットワーク経由で接続されたホストにボリュームを提供するストレージ装置１００を有し、前記ボリュームのサービス品質に係る規定群であるポリシーセットを複数記憶する記憶部と、前記ストレージ装置の状態に応じて複数の前記ポリシーセットから使用するポリシーセットを選択するポリシー選択部とを備える。
かかる構成及び動作により、ストレージ装置の状態に応じた適正な運用を実現することができる。
ここで、ポリシーセットは、ＱｏＳポリシーグループに対応する。
また、記憶部は、ストレージ装置１００のＤＲＡＭ１１５であってもよいし、統合管理システム１２１が有する記憶領域でもよい。
また、ポリシー選択部は、統合管理システム１２１であってもよいし、ストレージ装置１００のＣＰＵ１１４であってもよい。

また、ストレージシステムは、第１のストレージ装置１００Ａに障害が発生した場合にストレージ装置１００ＡのＰＶＯＬ２０１から第２のストレージ装置１００ＢのＳＶＯＬ２００へのフェイルオーバーを実行する冗長構成を有し、前記記憶部は、前記第２のストレージ装置１００Ｂが前記フェイルオーバーの実行前に用いるポリシーセットと、前記フェイルオーバーの実行後に用いるポリシーセットとを記憶し、前記フェイルオーバーの実行後に用いるポリシーセットでは、前記フェイルオーバーの実行前に用いるポリシーセットに比べて、第２のボリュームに割り当てる性能が高く、他の複数のボリュームへに割り当てる性能が低い。
かかる構成及び動作により、前記第１のストレージ装置と前記第２のストレージ装置との間でＨＡペアを構成し、前記ＰＶＯＬにおいてＱｏＳを用いたＳＬＡ保証を行う場合において、前記ＳＶＯＬに対してフェイルオーバーを実施する場合でも、前記ＰＶＯＬと同等のＱｏＳを用いたＳＬＡ保証を前記ＳＶＯＬにおいて実現することができる。

また、前記第２のストレージ装置が前記フェイルオーバーの実行前に用いるポリシーセットは、前記ホストに係るデータ処理とは独立に行う処理を優先する規定群であり、前記第２のストレージ装置が前記フェイルオーバーの実行後に用いるポリシーセットは、前記ホストに係るデータ処理を優先する規定群である。
かかる構成及び動作により、例えば、前記第２のストレージ装置ではフェイルオーバーが発生するまでの間、２次的な目的で利用するホストやアプリケーションからのＩＯを優先するようにＱｏＳを設定し、フェイルオーバー後においては、前記ＳＶＯＬへのＩＯが優先されるようにＱｏＳを設定することができる。

また、前記ポリシー選択部は、前記第２のストレージ装置の処理能力と、前記第２のストレージ装置が前記フェイルオーバーの実行後に用いるポリシーセットとを比較し、前記第２のストレージ装置の処理能力に不足がある場合に警告を行う。
かかる構成及び動作により、ストレージ管理者はフェイルオーバー時のＳＬＡについてリスクがある場合は、事前に知ることができるため、フェイルオーバー時におけるＳＬＡに起因する障害発生を予防できる。

また、前記ストレージ装置は、コントローラの縮退運用が可能であり、前記記憶部は、前記縮退運用が不要である場合に用いるポリシーセットと前記縮退運用中に用いるポリシーセットとを記憶する。
かかる構成及び動作により縮退の発生によりストレージ装置の状態が変化した場合にも、その変化に応じて適切なＱｏＳの設定を用いることができる。

また、前記記憶部は、時間に応じて異なる複数のポリシーセットを記憶し、前記ポリシー選択部は、その時点に対応したポリシーセットを選択する構成とすれば、時刻や曜日による処理量の変化に応じた適切なＱｏＳの設定を用いることができる。

以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態のみに限定する趣旨ではない。本発明は他の形態でも実施することが可能である。

１００ ストレージ装置、１０１ ドライブ、１０２ 制御プログラム、１０３ 管理情報、１０４ ＮＶＲＡＭ、１０５ キャッシュメモリ、１０６ ストレージコントローラ、１０７ ホスト、１０８ 管理システム、１０９ ホストインタフェース、１１０ ネットワーク、１１１ 管理ネットワーク、１１２ 中継器、１１３ プロセッサパッケージ、１１４ ＣＰＵ、１１５ ＤＲＡＭ、１１６ フロントエンドインタフェース、１１７ バックエンドインタフェース、１１８ 管理用コントローラ、１１９ クラウド、１２０ 管理インタフェースデバイス、１２１ 統合管理システム、１２２ レプリケーションインタフェース、２００ ＳＶＯＬ、２０１ ＰＶＯＬ、２０２ ＶＯＬ、２０３ リモートペア、２０４ リモートコピー、２０５ フェイルオーバー、３００ ＨＡペア管理テーブル、３０１ ＬＤＥＶ管理テーブル、３０２ ＱｏＳポリシー管理テーブル、３０３ ＱｏＳポリシーＧｒ管理テーブル、３０４ ＬＤＥＶ稼働情報テーブル、４００ ＬＤＥＶ番号、４０１ ＬＤＥＶ容量、４０２ ＶＯＬ種別、４０３ プール番号、４０４ データ削減有効、４０５ ＰＧ番号、５００ ペア番号、５０１ 利用可能号、５０２ ＰＶＯＬＬＤＥＶ番号、５０３ ペア装置ＩＤ、５０４ ＳＶＯＬＬＤＥＶ番号、５０５ 同期方式、５０６ ペア状態、５０７ 仮想ＩＤ、６００ ポリシ番号、６０１ ＩＯ種別、６０２ 最大ＩＯＰＳ、６０３ 最小ＩＯＰＳ、６０４ 最大帯域、６０５ 最小帯域、７００ ポリシーＧｒ番号、７０１ 適用条件、７０２ 適用ポリシー７０３ 詳細条件、８００ リードＩＯＰＳ、８０１ ライトＩＯＰＳ、８０２ リード帯域、８０３ ライト帯域、８０４ タイムスタンプ

Claims (8)

1. ネットワーク経由で接続されたホストに第１のボリュームを提供する第１のストレージ装置と、前記第１のボリュームのリモートコピー先である第２のボリュームを含む複数のボリュームを提供する第２のストレージ装置とを有するストレージシステムであって、
   前記第２のストレージ装置の前記第２のボリューム及び他の前記複数のボリュームのサービス品質に係る規定群であるポリシーセットを複数記憶する記憶部と、
   前記第１のボリューム及び前記第２のストレージ装置の状態に応じて、複数の前記ポリシーセットから使用するポリシーセットを選択するポリシー選択部と
   を備えたことを特徴とするストレージシステム。
2. 前記第１のストレージ装置に障害が発生した場合に前記第１のボリュームから前記第２のボリュームへのフェイルオーバーを実行する冗長構成を有し、
   前記記憶部は、前記第２のストレージ装置が前記フェイルオーバーの実行前に用いるポリシーセットと、前記フェイルオーバーの実行後に用いるポリシーセットとを記憶し、
   前記フェイルオーバーの実行後に用いるポリシーセットでは、前記フェイルオーバーの実行前に用いるポリシーセットに比べて、前記第２のボリュームに割り当てる性能が高く、前記他の複数のボリュームへに割り当てる性能が低い
   ことを特徴とする請求項１に記載のストレージシステム。
3. 前記第２のストレージ装置が前記フェイルオーバーの実行前に用いるポリシーセットは、前記ホストに係るデータ処理とは独立に行う処理を優先する規定群であり、前記第２のストレージ装置が前記フェイルオーバーの実行後に用いるポリシーセットは、前記ホストに係るデータ処理を優先する規定群であることを特徴とする請求項２に記載のストレージシステム。
4. 前記ポリシー選択部は、前記第２のストレージ装置の処理能力と、前記第２のストレージ装置が前記フェイルオーバーの実行後に用いるポリシーセットとを比較し、前記第２のストレージ装置の処理能力に不足がある場合に警告を行うことを特徴とする請求項２に記載のストレージシステム。
5. 前記第１のストレージ装置及び／又は前記第２のストレージ装置は、コントローラの縮退運用が可能であり、
   前記記憶部は、前記縮退運用が不要である場合に用いるポリシーセットと前記縮退運用中に用いるポリシーセットとを記憶する
   ことを特徴とする請求項１に記載のストレージシステム。
6. 前記記憶部は、時間に応じて異なる複数のポリシーセットを記憶し、
   前記ポリシー選択部は、その時点に対応したポリシーセットを選択する
   ことを特徴とする請求項１に記載のストレージシステム。
7. ネットワーク経由で接続されたホストにボリュームを提供するストレージ装置であって、
   前記ボリュームのサービス品質に係る規定群であるポリシーセットを複数記憶する記憶部と、
   自装置の状態に応じて複数の前記ポリシーセットから使用するポリシーセットを選択するポリシー選択部と
   を備えたことを特徴とするストレージ装置。
8. ネットワーク経由で接続されたホストに第１のボリュームを提供する第１のストレージ装置と、前記第１のボリュームのリモートコピー先である第２のボリュームを含む複数のボリュームを提供する第２のストレージ装置とを管理するストレージ装置管理方法であって、
   前記第２のストレージ装置の前記第２のボリューム及び他の前記複数のボリュームのサービス品質に係る規定群であるポリシーセットを記憶部に複数格納するステップと、
   前記第１のボリューム及び前記第２のストレージ装置の状態を判定するステップと、
   前記第１のボリューム及び前記第２のストレージ装置の状態に応じて、複数の前記ポリシーセットから使用するポリシーセットを選択するステップと
   を含むことを特徴とするストレージ装置管理方法。
   

Images