IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022182584
(43)【公開日】2022-12-08
(54)【発明の名称】ストレージシステム
(51)【国際特許分類】
   G06F 3/06 20060101AFI20221201BHJP
   G06F 13/10 20060101ALI20221201BHJP
   G06F 11/07 20060101ALI20221201BHJP
   G06F 11/34 20060101ALI20221201BHJP
【FI】
G06F3/06 301Z
G06F3/06 301X
G06F13/10 340A
G06F11/07 140M
G06F11/07 193
G06F11/34 133
【審査請求】有
【請求項の数】15
【出願形態】OL
(21)【出願番号】P 2021090224
(22)【出願日】2021-05-28
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】山本 貴大
(72)【発明者】
【氏名】坂下 悠貴
(72)【発明者】
【氏名】伊藤 晋太郎
(72)【発明者】
【氏名】揚妻 匡邦
【テーマコード(参考)】
5B042
【Fターム(参考)】
5B042GA34
5B042JJ29
5B042KK04
(57)【要約】
【課題】ノードを追加したときにシステム性能がスケールアウトすると共に、1つのボリュームについても性能をスケールアウトし得るストレージシステムを提供する。
【解決手段】複数の領域を含むボリュームを1以上のホストに提供するための処理を行うプロセッサを備える複数のノードと、プロセッサと接続され、ボリュームのデータを記憶する1以上の記憶デバイスとを備えるストレージシステムであって、複数のノードの各々は、自ノードが提供するボリュームの負荷およびボリュームの領域を複数に分割した領域の負荷を監視し、監視している一のボリュームの負荷が閾値以上であると判定した第1のノードは、一のボリュームの領域を複数に分割した領域の負荷と負荷分散のポリシとに応じて、一のボリュームに含まれる一部の領域を第1のノードとは異なる第2のノードのボリュームに移動するようにした。
【選択図】図1
【特許請求の範囲】
【請求項1】
複数の領域を含むボリュームを1以上のホストに提供するための処理を行うプロセッサを備える複数のノードと、前記プロセッサと接続され、前記ボリュームのデータを記憶する1以上の記憶デバイスとを備えるストレージシステムであって、
前記複数のノードの各々は、自ノードが提供するボリュームの負荷および前記ボリュームの領域を複数に分割した領域の負荷を監視し、
監視している一のボリュームの負荷が閾値以上であると判定した第1のノードは、前記一のボリュームの領域を複数に分割した領域の負荷と負荷分散のポリシとに応じて、前記一のボリュームに含まれる一部の領域を前記第1のノードとは異なる第2のノードのボリュームに移動する、
ストレージシステム。
【請求項2】
前記第1のノードは、前記一のボリュームの負荷が閾値未満であると判定した場合、前記第2のノードのボリュームから、前記一部の領域を前記一のボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項3】
前記第1のノードは、前記第2のノードとして、前記一部の領域を移動した後のボリュームの負荷が閾値を超えないノードを選択する、
請求項1に記載のストレージシステム。
【請求項4】
前記複数のノードの各々には、前記1以上の記憶デバイスの少なくとも1つが対応して設けられ、
前記複数のノードの各々は、自ノードに割り当てられている領域のデータを、自ノードに設けられている記憶デバイスに記憶し、
前記第1のノードは、前記一のボリュームの容量が提供可能な容量を超えると判定した場合、前記一部の領域を前記第2のノードのボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項5】
前記複数のノードの各々は、自ノードが提供するボリュームに対するリードの負荷と、前記ボリュームに対するライトの負荷とを監視し、
前記第1のノードは、前記一のボリュームに対するリードの負荷が第1の閾値以上であると判定した場合、前記一部の領域を前記第2のノードのボリュームに移動し、前記一のボリュームに対するライトの負荷が前記第1の閾値とは異なる第2の閾値以上であると判定した場合、前記一部の領域を前記第2のノードのボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項6】
前記第1のノードは、前記複数のノードに対して前記一のボリュームに含まれる領域を均等に割り振り、前記第1のノードとは異なるノードに割り振った領域を、前記ノードのボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項7】
前記第1のノードは、前記一のボリュームの負荷が前記閾値を下回るまで、前記一のボリュームに含まれる領域を1つずつ、前記第1のノードとは異なるノードのボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項8】
前記一のボリュームが、複数のホストに提供されている場合、前記第1のノードは、前記複数のホストの各々がアクセスする領域をまとめてホストごとの移動対象とし、ホストごとの移動対象の領域を、前記第1のノードとは異なるノードのボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項9】
前記第1のノードは、自ノードが提供しているボリュームのうち前記一のボリュームとは異なる他のボリュームを前記第1のノードとは異なるノードに移動し、前記第2のノードのボリュームから、前記一部の領域を前記一のボリュームに移動する、
請求項1に記載のストレージシステム。
【請求項10】
前記一部の領域が移動された前記第2のノードのボリュームと、前記一部の領域にアクセスするホストとの間にパスが設定されていない場合、前記第2のノードおよび前記ホストは、前記パスを設定する、
請求項1に記載のストレージシステム。
【請求項11】
前記複数のノードの各々は、自ノードのボリュームの負荷が特定のホストに偏っていると判定した場合、前記特定のホストとのパスが最適属性であることを前記特定のホストに通知する、
請求項1に記載のストレージシステム。
【請求項12】
前記複数のノードの各々は、自ノードのボリュームの負荷が前記特定のホストに偏っていないと判定した場合、前記ボリュームに定義されている全てのパスが最適属性であることを前記パスが設定されている全てのホストに通知する、
請求項11に記載のストレージシステム。
【請求項13】
前記1以上の記憶デバイスは、前記複数のノードに共通して設けられている、
請求項1に記載のストレージシステム。
【請求項14】
前記第1のノードは、前記第2のノードに前記一部の領域を移動する際、前記一部の領域を管理するためのデータを更新し、前記1以上の記憶デバイスに記憶される前記一部の領域のデータを移動しない、
請求項13に記載のストレージシステム。
【請求項15】
前記複数のノードが提供するボリュームについて、当該ボリュームの領域の移動先ノードの数に応じたスループットと応答時間とを計算して出力する計算機を備える、
請求項1に記載のストレージシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、ボリュームの負荷を分散する技術に関する。
【背景技術】
【0002】
特許文献1は、複数のサーバをネットワークで接続して、各サーバのローカルストレージをストレージ制御ソフトウェアにより統合して、1つのストレージプールとして提供し、当該ストレージプールからボリュームを提供するストレージシステムについて開示している。上記ストレージシステムは、当該ボリュームにデータを書き込む際に、異なるサーバに格納されるデータを組み合わせ、パリティを計算し、データとは異なるサーバに格納することで、サーバ障害からデータを保護する。上記ストレージシステムでは、サーバの追加により、ストレージの容量と性能とをスケールアウトできることが特徴となっている。
【0003】
また、特許文献1は、ボリュームへ書き込まれたデータについてアクセス頻度を採取し、アクセス頻度の高いデータは、ローカルストレージに格納し、アクセス頻度の低いデータは異なるサーバのストレージ(ここでは、リモートストレージと呼ぶ)に格納するようにデータ配置を変更する技術についても開示している。ホストがボリュームのデータにアクセスする際は、ボリュームのローカルストレージを割り当てたサーバにアクセスし、当該サーバにて、データがローカルストレージにあるか、リモートストレージにあるかを判定し、リモートストレージにある場合は、異なるサーバにアクセスを転送し、データへのアクセスを行う。このように、アクセス頻度の高いデータをローカルストレージに格納しておくことで、ネットワークを介することなくデータへアクセスできるため、ホストに対して高速に応答することができる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】米国特許出願公開第2016/0371145号明細書
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献1に記載の技術に基づいてホストにボリュームを提供する場合、ボリュームへのアクセスは、必ずローカルストレージを有するサーバを経由してからアクセスする。このため、1つのボリュームの性能がローカルストレージを有するサーバの性能が上限となる。上記ストレージシステムは、サーバの追加により、性能がスケールアウトすることが特徴である。特許文献1で開示されている技術では、システム性能(複数のボリュームの合計性能)は、サーバを追加することで、スケールアウトできるが、1つのボリュームの性能は、サーバを追加してもスケールアウトすることができない。
【0006】
本発明は、以上の点を考慮してなされたもので、サーバ(ノード)を追加したときにシステム性能がスケールアウトすると共に、1つのボリュームについても性能をスケールアウトし得るストレージシステム等を提案しようとするものである。
【課題を解決するための手段】
【0007】
かかる課題を解決するため本発明においては、複数の領域を含むボリュームを1以上のホストに提供するための処理を行うプロセッサを備える複数のノードと、前記プロセッサと接続され、前記ボリュームのデータを記憶する1以上の記憶デバイスとを備えるストレージシステムであって、前記複数のノードの各々は、自ノードが提供するボリュームの負荷および前記ボリュームの領域を複数に分割した領域の負荷を監視し、監視している一のボリュームの負荷が閾値以上であると判定した第1のノードは、前記一のボリュームの領域を複数に分割した領域の負荷と負荷分散のポリシとに応じて、前記一のボリュームに含まれる一部の領域を前記第1のノードとは異なる第2のノードのボリュームに移動するようにした。
【0008】
上記構成では、一のボリュームの負荷が高まったときに、当該ボリュームの一部の領域が他のノードのボリュームに移動されるので、例えば、ノードを追加した場合、一のボリュームについても性能をスケールアウトすることができるようになる。
【発明の効果】
【0009】
本発明によれば、一のボリュームの性能をスケールアウトし得るストレージシステムを実現することができる。
【図面の簡単な説明】
【0010】
図1】第1の実施の形態によるボリュームのデータの割り当て変更の概要を示すイメージ図である。
図2】第1の実施の形態によるストレージシステムに係る物理構成の一例を示す図である。
図3】第1の実施の形態によるストレージシステムに係る論理構成の一例を示す図である。
図4】第1の実施の形態によるメモリ内の情報の一例を示す図である。
図5】第1の実施の形態によるクラスタ管理テーブルの一例を示す図である。
図6】第1の実施の形態によるデータ保護セット管理テーブルの一例を示す図である。
図7】第1の実施の形態によるストレージプール管理テーブルの一例を示す図である。
図8】第1の実施の形態によるボリューム管理テーブルの一例を示す図である。
図9】第1の実施の形態によるモニタ情報管理テーブルの一例を示す図である。
図10】第1の実施の形態によるフロントエンドパス管理テーブルの一例を示す図である。
図11】第1の実施の形態によるリード処理に係るフローチャートの一例を示す図である。
図12】第1の実施の形態によるライト処理に係るフローチャートの一例を示す図である。
図13A】第1の実施の形態によるモニタ情報採取処理に係るフローチャートの一例を示す図である。
図13B】第1の実施の形態によるモニタ情報採取処理に係るフローチャートの一例を示す図である。
図14】第1の実施の形態によるリバランス要否判定処理に係るフローチャートの一例を示す図である。
図15】第1の実施の形態によるリソース割当決定処理に係るフローチャートの一例を示す図である。
図16】第1の実施の形態によるリソース割当決定処理に係るフローチャートの一例を示す図である。
図17】第1の実施の形態によるリソース移動処理に係るフローチャートの一例を示す図である。
図18】第1の実施の形態によるフロントエンドパス設定処理に係るフローチャートの一例を示す図である。
図19】第1の実施の形態によるフロントエンドパス設定処理に係るフローチャートの一例を示す図である。
図20】第1の実施の形態によるクラスタ構成変更処理に係るフローチャートの一例を示す図である。
図21A】第1の実施の形態によるGUIの一例を示す図である。
図21B】第1の実施の形態によるGUIの一例を示す図である。
図22】第2の実施の形態によるストレージシステムに係る構成の一例を示す図である。
図23】第2の実施の形態によるリソース移動処理に係るフローチャートの一例を示す図である。
【発明を実施するための形態】
【0011】
(I)第1の実施の形態
以下、本発明の一実施の形態を詳述する。ただし、本発明は、実施の形態に限定されるものではない。
【0012】
本実施の形態に係るストレージシステムにおいては、ボリュームの領域を複数のスライスと呼ぶ領域に分割し、スライス単位で複数のサーバ計算機に領域を割り当て、ボリュームへのアクセス負荷をモニタリングする。本ストレージシステムでは、主にスライスが割り当てられたサーバ計算機に負荷が生じ、アクセス負荷が低く1つのサーバ計算機でボリュームが要求する性能を提供できる場合は、ボリュームを構成するスライスを1つのサーバ計算機に集約するように割り当てを制御する。また、ストレージシステムでは、アクセス負荷が高く1つのサーバ計算機でボリュームが要求する性能を提供できない場合は、ボリュームを構成するスライスを複数のサーバ計算機に分散して割り当てるように制御する。また、本ストレージシステムでは、ホストがボリュームのデータにアクセスする際は、各サーバ計算機にてアクセス先のスライスがどのサーバ計算機に割り当たっているか判定することで、アクセス時の負荷が特定のサーバ計算機に偏らないようにする。
【0013】
これにより、ボリュームのアクセス負荷が1つのサーバ計算機で充足する場合、必ずローカルストレージのデータに対してアクセスできるため、ホストに対して、高速に応答することができる。また、ボリュームのアクセス負荷が1つのサーバ計算機では充足しない場合、複数のサーバ計算機でアクセスを処理することでホストに対して高いスループット(IOPS:Input/Output Per Seconds)を提供できる。また、これらの制御は、ユーザが意識することなく、ストレージシステムが自動で行うため、ユーザは、特許文献1に記載のストレージシステムと変わらない運用負荷で上記の利益を得ることができる。
【0014】
本ストレージシステムによれば、1つのボリュームに対してもサーバ計算機の追加に合わせて、容量および性能をスケールアウトし、ボリュームのアクセス負荷に応じて、応答時間とスループットとを自動で好適な状態に変更できる。
【0015】
次に、本発明の実施の形態を図面に基づいて説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。特に限定しない限り、各構成要素は、単数でも複数でも構わない。
【0016】
なお、以下の説明では、同種の要素を区別しないで説明する場合には、枝番を含む参照符号のうちの共通部分(枝番を除く部分)を使用し、同種の要素を区別して説明する場合は、枝番を含む参照符号を使用することがある。例えば、物理領域を特に区別しないで説明する場合には、「物理領域121」と記載し、個々の領域を区別して説明する場合には、「物理領域121-1」、「物理領域121-2」のように記載することがある。
【0017】
本明細書等における「第1」、「第2」、「第3」等の表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は、文脈毎に用いられ、1つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
【0018】
図1は、ストレージシステムにおいて、ボリュームのデータの割り当て変更の概要を示すイメージ図である。ストレージシステム110からストレージシステム120に構成を変更する場合を例に挙げて説明する。
【0019】
ストレージシステム110では、ホスト101にボリューム102が接続されており、ボリューム102内のデータ105A,105B,105Cが、ノード100A内のストレージプール103Aへ割り当てられている。ノード100Aは、ボリューム102に割当たったデータ105へのアクセス負荷をモニタリングする。モニタリングの結果、ストレージシステム110は、ノード100Aで提供できる性能を超える負荷を検出した場合、ボリューム102のデータ105B,105Cをノード100B,100Cに移動し、負荷を分散し、ストレージシステム120の状態に遷移する。本制御により、ボリューム102の高負荷時は、多数のノード100に処理を分散することで単体のボリューム102について高い性能を提供できるようにする。
【0020】
ストレージシステム120では、ホスト101にボリューム102が接続されている。ボリューム102内のデータ105Aがノード100A内のストレージプール103Aに割り当てられている。データ105Bがノード100B内のストレージプール103Bに割り当てられている。データ105Cがノード100C内のストレージプール103Cに割り当てられている。ノード100A,100B,100Cは、ボリューム102に割当たったデータ105A,105B,105Cへのアクセス負荷をモニタリングする。モニタリングの結果、ストレージシステム120は、各データ105のアクセス負荷がノード100Aで提供できる性能を超えない負荷であることを検出した場合、ボリューム102のデータ105B,105Cをノード100Aへ移動し、負荷を集約し、ストレージシステム110の状態に遷移する。本制御により、ボリューム102の低負荷時は、単一ノード100で処理を集約することでネットワークの利用効率を高め、ストレージシステム全体について、高い性能を提供できるようにする。
【0021】
図2は、ストレージシステム200に係る物理構成の一例を示す図である。
【0022】
ストレージシステム200には、1以上のサイト201が設けられてもよい。各サイト201は、ネットワーク202を介して通信可能に接続される。ネットワーク202は、例えば、WAN(Wide Area Network)であるが、WANに限定するものではない。
【0023】
サイト201は、データセンタ等であり、1以上のノード100を含んで構成される。
【0024】
ノード100は、一般的なサーバ計算機の構成を備えてよい。ノード100は、例えば、プロセッサ211、メモリ212等を含む1以上のプロセッサパッケージ213、1以上のドライブ214、1以上のポート215を含んで構成される。各構成要素は、内部バス216を介して接続されている。
【0025】
プロセッサ211は、例えば、CPU(Central Processing Unit)であり、各種の処理を行う。
【0026】
メモリ212は、ノード100の機能を実現する上で必要な制御用の情報を格納したり、データを格納したりする。また、メモリ212は、例えば、プロセッサ211により実行されるプログラムを格納する。メモリ212は、揮発性のDRAM(Dynamic Random Access Memory)であってもよいし、不揮発のSCM(Storage Class Memory)であってもよいし、その他の記憶デバイスであってもよい。
【0027】
ドライブ214は、各種のデータ、プログラム等を記憶する。ドライブ214は、SAS(Serial Attached SCSI)またはSATA(Serial Advanced Technology Attachment)接続のHDD(Hard Disk Drive)やSSD(Solid State Drive)、NVMe(Non-Volatile Memory Express)接続のSSDの他、SCM等であってもよく、記憶デバイスの一例である。
【0028】
ポート215は、ネットワーク220に接続され、サイト201内の他のノード100と通信可能に接続されている。ネットワーク220は、例えば、LAN(Local Area Network)であるが、LANに限定するものではない。
【0029】
ストレージシステム200に係る物理構成は、上述の内容に限定されるものではない。例えば、ネットワーク220,202については、冗長化されていてもよい。また、例えば、ネットワーク220は、管理用のネットワークとストレージ用のネットワークとで分離してもよく、接続規格は、Ethernet(登録商標)、Infiniband、無線でもよく、接続トポロジも図2に示す構成に限定しない。
【0030】
なお、ホスト101は、ノード100と同じ構成要素を備えてもよく、ホスト101の物理構成については、その説明を省略する。
【0031】
図3は、ストレージシステム200に係る論理構成の一例を示す図である。ストレージシステム200では、ストレージ仮想化が行われ、複数の物理領域が仮想的に統合され、ストレージプール312として利用される。さらに、ストレージシステム200では、シンプロビジョニングにより、各ホスト101が現在利用している容量だけが割り当てられている。
【0032】
より具体的には、図3に示すように、ドライブ214は、データ、パリティ等を格納する物理的な領域であるデータ格納領域を有する。データ格納領域のうちの全部または一部の領域であり、連続した領域である論理ドライブ318は、ノード100を跨る複数の論理ドライブ318を組み合わせてパリティグループ317を構築する。
【0033】
パリティグループ317は、複数のノード100のドライブ214の論理ドライブ318から構成される。例えば、データ保護ポリシが2D1Pである場合、異なるノード100のドライブ214から確保した3つの論理ドライブ318でパリティグループ317が構成される。
【0034】
ここで、データ保護ポリシとしては、例えば、EC(Erasure Coding)がある。なお、ECとしては、データローカリティを保持しない第1の方式と、データローカリティを保持する第2の方式(例えば、国際公開第2016/52665号に記載の方式)とがあるが、ストレージシステム200には、何れの方式も適用可能である。なお、本実施の形態では、第2の方式を適用したケースを例に挙げて主に説明する。
【0035】
付言するならば、例えば、第1の方式の2D1PのECでは、ライト要求のデータを第1のデータと第2のデータとに分け、第1のデータを第1のノード100に格納し、第2のデータを第2のノード100に格納し、第1のデータおよび第2のデータで計算されたパリティを第3のノード100に格納することで冗長化が行われる。また、例えば、第2の方式の2D1PのECでは、ライト要求のデータを第1のデータと第2のデータとに分け、第1のデータおよび第2のデータを第1のノード100(自ノード100)に格納し、第1のデータのパリティを第2のノード100に格納し、第2のデータのパリティを第3のノード100に格納することで冗長化が行われる。
【0036】
パリティグループ317からは、プールボリューム316が切り出される。プールボリューム316は、各ノード100のストレージプール312に容量を割り当てる単位である。1つのパリティグループ317から1つのプールボリューム316が切り出されてもよいし、複数のプールボリューム316が切り出されてよい。
【0037】
付言するならば、例えば、データ保護ポリシが2D1Pである場合、データの格納領域として利用できるのは、パリティグループ317に割り当てられた論理ドライブ318の総量の2/3となり、パリティの格納領域として利用できるのは、パリティグループ317に割り当てられた論理ドライブ318の総量の1/3となる。つまり、プールボリューム316として切り出せる最大の容量は、データ保護ポリシに応じて異なる。
【0038】
切り出されたプールボリューム316は、ストレージプール312にアタッチされる。ストレージプール312は、1以上のプールボリューム316を含んで構成される。ストレージプール312からは、アプリケーション301により利用される仮想ボリューム313が切り出される。つまり、ストレージプログラム311は、利用者の要求に応じた容量を、ドライブ214に割り当てず、仮想ボリューム313として割り当てる。
【0039】
ストレージプール312から仮想ボリューム313を切り出す際、複数のストレージプール312から仮想ボリューム313の領域をスライス314として部分的に切り出し、スライス314を束ねることで仮想ボリューム313を構築する。スライス314は、ストレージプール312に対して、仮想的に割り当てられた領域であり、仮想ボリューム313を作成した時点では、物理的な領域が割り当てられない。スライス314には、1以上のページ315が割り当てられる。例えば、ストレージプログラム311は、アプリケーション301からライト要求を受信した場合、新規のライトであるときは、仮想ボリューム313のスライス314にページ315(より詳細には、ページ315に紐づく論理ドライブ318の物理領域)を割り当てる。なお、ページ315には、プールボリューム316のページが対応付けられている。更新のライトであるときは、ストレージプログラム311は、割り当てたページ315に紐づく論理ドライブ318の物理領域を特定してデータを更新する。なお、ライト要求のデータ(または後述の中間データ)は、データの冗長化に係る他のノード100に転送されてパリティが更新される。
【0040】
仮想ボリューム313とアプリケーション301とは、フロントエンドパス320(以降、単にパスとも記述する)で接続される。フロントエンドパス320の接続および設定は、ストレージプログラム311とホスト101上で動作するパス設定プログラム302とにより制御される。なお、図3では、スライス314を第1のノード100「Node0」から第2のノード100「Node1」に移動した後、移動先(割当先)の第2のノード100「Node1」にフロントエンドパス320が設定されていない例を示している。この場合、一度、第1のノード100「Node0」を経由してスライス314の割当先の第2のノード100「Node1」にIOコマンドが転送されて処理される。ただし、後述するように、移動先の第2のノード100「Node1」にフロントエンドパス320が設定され、最適化が行われることが好適である。
【0041】
このように、ストレージプログラム311は、ドライブ214を共有のストレージプール312として管理し、仮想ボリューム313に書き込まれたデータ量に応じてドライブ214に容量を割り当てる。これにより、使用されないドライブ214の無駄をなくし、効率的な運用が行わる。
【0042】
以下では、データを更新するにあたり、当該データは、ライト要求を受領したノード100のドライブ214(ローカルドライブ)に格納される構成(データローカリティを維持し、リード時のネットワークオーバヘッドを排除する構成)を例に挙げて主に説明する。
【0043】
なお、データにアクセスするアプリケーション301は、ホスト101に設けられて動作するものであってもよいし、ストレージプログラム311と同一ノード100に設けられて動作するものであってもよいし、別のノード100に設けられて動作するものであってもよい。
【0044】
図4は、メモリ212内の情報(ドライブ214からメモリ212に読み出される情報)の一例を示す図である。なお、制御情報テーブル410、各種のプログラム(ストレージプログラム311等)は、実行中はメモリ212上に展開されるが、停電等に備えてドライブ214等の不揮発な領域に格納されている。
【0045】
制御情報テーブル410には、クラスタ構成管理テーブル411、データ保護セット管理テーブル412、ストレージプール管理テーブル413、ボリューム管理テーブル414、モニタ情報管理テーブル415、およびフロントエンドパス管理テーブル416が含まれる。各テーブルについては、図5図10を用いて後述する。
【0046】
ストレージプログラム311は、リード処理プログラム421、ライト処理プログラム422、モニタ情報採取処理プログラム423、リバランス要否判定処理プログラム424、リソース割当決定処理プログラム425、リソース移動処理プログラム426、フロントエンドパス設定処理プログラム427、およびクラスタ構成変更処理プログラム428を備える。なお、パス設定プログラム302は、フロントエンドパス設定処理プログラム427を備える。
【0047】
ノード100の機能(リード処理プログラム421、ライト処理プログラム422、モニタ情報採取処理プログラム423、リバランス要否判定処理プログラム424、リソース割当決定処理プログラム425、リソース移動処理プログラム426、ストレージプログラム311のフロントエンドパス設定処理プログラム427、クラスタ構成変更処理プログラム428等)は、例えば、プロセッサ211がドライブ214に格納されたプログラムをメモリ212に読み出して実行すること(ソフトウェア)により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。また、ノード100の機能の一部は、ノード100と通信可能な他のコンピュータにより実現されてもよい。
【0048】
ホスト101の機能(例えば、パス設定プログラム302のフロントエンドパス設定処理プログラム427)は、例えば、プロセッサ211がドライブ214に格納されたプログラムをメモリ212に読み出して実行すること(ソフトウェア)により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。また、ホスト101の機能の一部は、ホスト101と通信可能な他のコンピュータにより実現されてもよい。
【0049】
図5は、クラスタ構成管理テーブル411の一例を示す図である。
【0050】
クラスタ構成管理テーブル411は、サイト201、ノード100、ドライブ214の構成を管理するための情報を格納する。
【0051】
クラスタ構成管理テーブル411は、サイト構成管理テーブル510、ノード構成管理テーブル520、およびドライブ構成管理テーブル530を含んで構成される。なお、ストレージシステム200は、サイト構成管理テーブル510を管理し、サイト201は、サイト201内の複数のノード構成管理テーブル520を管理し、ノード100は、ノード100内の複数のドライブ構成管理テーブル530を管理する。
【0052】
サイト構成管理テーブル510は、サイト201に係る構成(サイト201とノード100との関係等)を示す情報を格納する。より具体的には、サイト構成管理テーブル510は、サイトID511と、状態512と、ノードIDリスト513とが対応付けられた情報を格納する。
【0053】
サイトID511は、サイト201を識別可能な識別情報である。状態512は、サイト201の状態を示す状態情報(NORMAL、WARNING、FAILURE等)である。ノードIDリスト513は、サイト201に設けられるノード100を識別可能な識別情報のリストである。
【0054】
ノード構成管理テーブル520は、サイト201ごとに設けられ、サイト201に設けられるノード100に係る構成(ノード100とドライブ214との関係等)を示す情報を格納する。より具体的には、ノード構成管理テーブル520は、ノードID521と、状態522と、ドライブIDリスト523とが対応付けられた情報を格納する。
【0055】
ノードID521は、ノード100を識別可能な識別情報である。状態522は、ノード100の状態を示す状態情報(NORMAL、WARNING、FAILURE等)である。ドライブIDリスト523は、ノード100に設けられるドライブ214を識別可能な識別情報のリストである。
【0056】
ドライブ構成管理テーブル530は、ノード100ごとに設けられ、ノード100に設けられるドライブ214に係る構成を示す情報を格納する。より具体的には、ドライブ構成管理テーブル530は、ドライブID531と、状態532と、サイズ533とが対応付けられた情報を格納する。
【0057】
ドライブID531は、ドライブ214を識別可能な識別情報である。状態532は、ドライブ214の状態を示す状態情報(NORMAL、WARNING、FAILURE等)である。サイズ533は、ドライブ214の容量を示す情報(TB(テラバイト)、GB(ギガバイト)等)である。
【0058】
図6は、データ保護セット管理テーブル412の一例を示す図である。
【0059】
データ保護セット管理テーブル412は、論理ドライブ318を組み合わせて構成したパリティグループ317の構成を管理するための制御情報を格納する。
【0060】
データ保護セット管理テーブル412は、プールボリューム管理テーブル610、パリティグループ管理テーブル620、論理ドライブ管理テーブル630、およびストライプマッピングテーブル640を含んで構成される。
【0061】
プールボリューム管理テーブル610は、パリティグループ317から切り出されたプールボリューム316に係る情報を格納する。より具体的には、プールボリューム管理テーブル610は、プールボリュームID611と、サイズ612と、パリティグループID613と、論理ドライブID614とが対応付けられた情報を格納する。
【0062】
プールボリュームID611は、パリティグループ317から切り出されたプールボリューム316を識別可能な識別情報である。サイズ612は、プールボリューム316の容量を示す情報(TB(テラバイト)、GB(ギガバイト)等)である。パリティグループID613は、プールボリューム316が属するパリティグループ317を識別可能な識別情報である。論理ドライブID614は、プールボリューム316に格納するデータ領域を提供する論理ドライブ318を識別可能な識別情報である。
【0063】
パリティグループ管理テーブル620は、パリティグループ317に係る情報を格納する。より具体的には、パリティグループ管理テーブル620は、パリティグループID621と、冗長化ポリシ622と、論理ドライブIDリスト623とが対応付けられた情報を格納する。
【0064】
パリティグループID621は、パリティグループ317を識別可能な識別情報である。冗長化ポリシ622は、パリティグループ317の冗長化方法に関する設定である。論理ドライブIDリスト623は、パリティグループ317に割り当てられた論理ドライブ318を識別可能な識別情報のリストである。
【0065】
論理ドライブ管理テーブル630は、論理ドライブ318に係る情報(開始オフセットからサイズ分だけドライブ214の物理領域を切り出して論理ドライブ318として管理するための情報)を格納する。より具体的には、論理ドライブ管理テーブル630は、論理ドライブID631と、開始オフセット632と、サイズ633と、ドライブID634とが対応付けられた情報を格納する。
【0066】
論理ドライブID631は、論理ドライブ318を識別可能な識別情報である。開始オフセット632は、ドライブ214から論理ドライブ318を切り出すときの開始位置を示す情報である。サイズ633は、論理ドライブ318の容量を示す情報(ブロックの数)である。ここでブロックとは、ドライブ214へのアクセス単位を意味しており、典型的には、1ブロックのサイズは、512Byteである。ただし、ブロックのサイズは、512Byteに限定せず、4KB、8KB等でもよい。ドライブID634は、論理ドライブ318が切り出されている記憶資源を識別可能な識別情報(論理ドライブ318がどのドライブ214から切り出されているかを示す情報)である。
【0067】
ストライプマッピングテーブル640は、パリティグループ317に係る情報(データおよびパリティの格納先アドレスを計算するための情報)を格納する。一例として、ストライプマッピングテーブル640が、EC(2D1P)のストライプマッピングテーブル641、およびMirror(2-Replication)のストライプマッピングテーブル642の情報を格納するケースについて説明する。2D1Pとは、2つのデータの組み合わせで1つのパリティを算出し、データを保護することを意味する。
【0068】
ストライプマッピングテーブル641,642は、あるデータ領域の物理LBA(Logical Block Address)に対して、パリティ領域の物理LBA(冗長化先ノード)を特定するために使用する。
【0069】
ストライプマッピングテーブル641,642は、表、配列形式等で格納されており、横軸の要素としてノードIDに対応する情報を保持し、縦軸の要素としてアドレスに対応する情報を保持している。横軸の情報は、直接的にノードIDの情報を格納していてもよいし、ストライプマッピングテーブル641,642の横軸のIDとノードIDとを対応づける別のテーブルを介して管理されていてもよい。縦軸の情報は、直接的にLBAの情報を格納している必要はなく、例えばLBAから縦軸のIDへは以下のように変換することができる。
【0070】
RowID = LBA mod Rowmax
(Rowmaxは、ストライプマッピングテーブル641,642では「6」となる)
【0071】
図7は、ストレージプール管理テーブル413の一例を示す図である。
【0072】
ストレージプール管理テーブル413は、ストレージプール312の構成を管理するための制御情報を格納する。ストレージプール管理テーブル413は、ストレージプール情報テーブル710を含んで構成される。
【0073】
ストレージプール情報テーブル710は、ストレージプール312に係る情報を格納する。より具体的には、ストレージプール情報テーブル710は、ストレージプールID711と、合計容量712と、使用容量713と、ノードID714と、プールボリュームIDリスト715とが対応付けられた情報を格納する。
【0074】
ストレージプールID711は、ストレージプール312を識別可能な識別情報である。合計容量712は、ストレージプール312に割り当てられた合計容量を示す情報(TB(テラバイト)、GB(ギガバイト)等)である。使用容量713は、ストレージプール312で使用している容量を示す情報(TB(テラバイト)、GB(ギガバイト)等)である。ノードID714は、ストレージプール312を提供するノード100を識別可能な識別情報である。プールボリュームIDリスト715は、ストレージプール312に割り当てられたプールボリューム316を識別可能な識別情報のリストである。
【0075】
図8は、ボリューム管理テーブル414の一例を示す図である。
【0076】
ボリューム管理テーブル414は、仮想ボリューム313の構成情報と、ノード100間に割り当てられたスライス314の構成情報と、シンプロビジョニング機能のための制御情報とを格納する。
【0077】
ボリューム管理テーブル414は、仮想ボリューム管理テーブル810、スライス管理テーブル820、およびページマッピングテーブル830を含んで構成される。
【0078】
仮想ボリューム管理テーブル810は、仮想ボリューム313に係る情報(仮想ボリューム313と仮想ボリューム313に割り当てられたスライス314との対応関係を示す情報等)を格納する。より具体的には、仮想ボリューム管理テーブル810は、仮想ボリュームID811と、サイズ812と、スライスIDリスト813と、最大分散度814とが対応付けられた情報を格納する。
【0079】
仮想ボリュームID811は、仮想ボリューム313を識別可能な識別情報である。サイズ812は、仮想ボリューム313の容量を示す情報(TB(テラバイト)、GB(ギガバイト)等)である。スライスIDリスト813は、仮想ボリューム313に割り当てられたスライス314を識別可能な識別情報のリストである。最大分散度814は、仮想ボリューム313に割り当てるスライス314を分散させるノード数の最大値である。これを超えた数のノード100には、スライス314が割り当てられないように制御される。
【0080】
スライス管理テーブル820は、仮想ボリューム313に割り当てたスライス314に係る情報(スライス314とスライス314に対応するストレージプール312との対応関係を示す情報等)を格納する。より具体的には、スライス管理テーブル820は、スライスID821と、サイズ822と、ストレージプールID823と、状態824とが対応付けられた情報を格納する。
【0081】
スライスID821は、スライス314を識別可能な識別情報である。サイズ822は、スライス314の容量を示す情報(TB(テラバイト)、GB(ギガバイト)、Logical Block数等)である。ストレージプールID823は、スライス314に対応するストレージプール312を識別可能な識別情報である。2つのストレージプール312間でスライス314を移動中の場合、ストレージプールID823は、移動前後のストレージプール312を識別可能な識別情報を格納する。状態824は、スライス314の状態を示す情報である。状態824には、正常(Normal)、障害状態(Failure)、2つのストレージプール312間を移動中(Migrating)といった状態がある。
【0082】
ページマッピングテーブル830は、仮想ボリューム313に割り当てたページ315に係る情報(ページ315とプールボリューム316との対応関係を示す情報等)を格納する。より具体的には、ページマッピングテーブル830は、ページID831と、仮想ボリュームID832と、仮想ボリュームLBA833と、サイズ834と、プールボリュームID835と、プールボリュームLBA836とが対応付けられた情報を格納する。
【0083】
ページID831は、ページ315を識別可能な識別情報である。仮想ボリュームID832は、ページ315が割り当てられている仮想ボリューム313を識別可能な識別情報である。仮想ボリュームLBA833は、仮想ボリューム313におけるページ315の位置を特定可能な情報であり、例えば、仮想ボリューム313の最初のページ315から何番目であるかを示す情報である。なお、ページ315は、ストレージプログラム311が仮想ボリューム313にアクセスする単位である。サイズ834は、ページ315の容量を示す情報(TB(テラバイト)、GB(ギガバイト)、Logical Block数等)である。プールボリュームID835は、ページ315に対応するプールボリューム316を識別可能な識別情報である。プールボリュームLBA836は、ストレージプール312におけるプールボリューム316の位置を特定可能な情報であり、例えば、ストレージプール312の最初のプールボリューム316から何番目であるかを示す情報である。
【0084】
なお、サイズ834は、全てのページ315で同じであってもよいし、ページ315ごとに異なっていてもよい。
【0085】
付言するならば、ストレージプログラム311は、仮想ボリューム313のアドレスからストレージプール312のアドレスへの変換を行う際にページマッピングテーブル830を参照する。また、ストレージプログラム311は、新規ライトを受領する度に、ページ315の割当て(ページマッピングテーブル830へのレコードの追加)を行う。
【0086】
図9は、モニタ情報管理テーブル415の一例を示す図である。
【0087】
モニタ情報管理テーブル415は、ノード100で動作するプロセスのプロセッサ211、ドライブ214、およびポート215の使用量と、仮想ボリューム313のスライス314、およびフロントエンドパス320に対するアクセス頻度とを管理するためのするための制御情報を格納する。
【0088】
モニタ情報管理テーブル415は、プロセッサモニタ情報管理テーブル910、ドライブモニタ情報管理テーブル920、ネットワークモニタ情報管理テーブル930、スライスモニタ情報管理テーブル940、フロントエンドパスモニタ情報管理テーブル950を含んで構成される。
【0089】
プロセッサモニタ情報管理テーブル910は、プロセッサ211に係る情報(プロセスとプロセッサ211の使用量との関係を示す情報)を格納する。より具体的には、ノードID911と、プロセッサID912と、プロセスID913と、プロセス名914と、使用率915とが対応付けられた情報を格納する。
【0090】
ノードID911は、ノード100を識別可能な識別情報である。プロセッサID912は、ノード100内に複数のプロセッサコアが搭載されている場合にプロセッサコアを識別可能な識別情報である。プロセスID913は、ノード100で動作するプログラムを識別可能な識別情報である。プロセス名914は、ノード100で動作するプログラムを識別可能な文字列情報である。使用率915は、ノード100で動作するプログラムが動作するプロセッサコアの占有率を示す。例えば、ストレージプログラム311の使用率が50%である場合、ストレージプログラム311が動作するプロセッサコア動作周波数の半分を占有していることを意味する。
【0091】
ドライブモニタ情報管理テーブル920は、ドライブ214に係る情報(ドライブ214の使用量の関係を示す情報)を格納する。より具体的には、ドライブID921と、リードIOPS922と、ライトIOPS923と、リード転送量924と、ライト転送量925と、使用率926とが対応付けられた情報を格納する。
【0092】
ドライブID921は、ドライブ214を識別可能な識別情報である。リードIOPS922は、当該ドライブ214に対してのリードコマンドの秒間あたりの処理数である。ライトIOPS923は、当該ドライブ214に対してのライトコマンドの秒間あたりの処理数である。リード転送量924は、当該ドライブ214に対してのリードコマンドの秒間あたりのデータ転送量である。ライト転送量925は、当該ドライブ214に対してのライトコマンドの秒間あたりのデータ転送量である。使用率926は、当該ドライブ214の負荷度合いを示し、100%となった場合、当該ドライブ214は、それ以上I/Oを処理できず、ドライブ214が受領したI/O要求は待たされることになる。
【0093】
ネットワークモニタ情報管理テーブル930は、ネットワーク220に接続されているポート215に係る情報(ポート215の使用量の関係を示す情報)を格納する。より具体的には、ノードID931と、NIC(Networtk Interface Card)ID932と、送信転送量933と、受信転送量934と、最大転送量935とが対応付けられた情報を格納する。
【0094】
ノードID931は、ノード100を識別可能な識別情報である。NIC ID932は、ノード100内に複数のNIC(ポート215)が搭載されている場合にNICを識別可能な識別情報である。なお、本実施の形態では、NICが1つのポート215を備える場合を例に挙げて説明する。送信転送量933は、当該NICに対しての送信処理の秒間あたりの転送量である。受信転送量934は、当該NICに対しての受信処理の秒間あたりの転送量である。最大転送量935は、当該NICで処理可能な送受信の秒間あたりの最大転送量である。
【0095】
スライスモニタ情報管理テーブル940は、スライス314へのアクセス頻度の情報を格納する。より具体的には、スライスモニタ情報管理テーブル940は、スライスID941と、リードカウンタ942と、ライトカウンタ943と、リード転送量944と、ライト転送量945と、モニタ開始時刻946とが対応付けられた情報を格納する。
【0096】
スライスID941は、スライス314を識別可能な識別情報である。リードカウンタ942は、当該スライス314をリードした回数を管理するための情報である。ライトカウンタ943は、当該スライス314に対してライトした回数を管理するための情報である。リード転送量944は、当該スライス314をリードした転送量を管理するための情報である。ライト転送量945は、当該スライス314に対してライトした転送量を管理するための情報である。モニタ開始時刻946は、当該スライス314に対するアクセスの監視が開始された時間を示す情報である。
【0097】
フロントエンドパスモニタ情報管理テーブル950は、フロントエンドパス320へのアクセス頻度の情報を格納する。より具体的には、フロントエンドパスモニタ情報管理テーブル950は、パスID951と、リードIOPS952と、ライトIOPS953と、リード転送量954と、ライト転送量955とが対応付けられた情報を格納する。
【0098】
パスID951は、フロントエンドパス320を識別可能な識別情報である。リードIOPS952は、当該フロントエンドパス320に対してのリードコマンドの秒間あたりの処理数である。ライトIOPS953は、当該フロントエンドパス320に対してのライトコマンドの秒間あたりの処理数である。リード転送量954は、当該フロントエンドパス320に対してのリードコマンドの秒間あたりのデータ転送量である。ライト転送量955は、当該フロントエンドパス320に対してのライトコマンドの秒間あたりのデータ転送量である。
【0099】
図10は、フロントエンドパス管理テーブル416の一例を示す図である。
【0100】
フロントエンドパス管理テーブル416は、フロントエンドパス320の構成を管理するための制御情報を格納する。フロントエンドパス管理テーブル416は、フロントエンドパス情報テーブル1010を含んで構成される。
【0101】
フロントエンドパス情報テーブル1010は、フロントエンドパス320に係る情報を格納する。より具体的には、フロントエンドパス情報テーブル1010は、パスID1011と、仮想ボリュームID1012と、InitiatorID1013と、ALUA設定1014と、接続ノードID1015とが対応付けられた情報を格納する。
【0102】
パスID1011は、フロントエンドパス320を識別可能な識別情報である。仮想ボリュームID1012は、フロントエンドパス320が割り当てられた仮想ボリューム313を識別可能な識別情報である。InitiatorID1013は、フロントエンドパス320の接続先であるホスト101を識別可能な識別情報である。ALUA設定1014は、ストレージシステム200にとって、対応するフロントエンドパス320が好適であるかどうかの設定を示す情報である。ALUA設定1014に基づく情報を、ホスト101に通知することで、ホスト101は、好適なパスへI/Oリクエストを発行することができ、ストレージシステム200の処理効率を向上させることができる。接続ノードID1015は、フロントエンドパス320を有するノードIDを識別可能な識別情報である。
【0103】
図11は、リード処理に係るフローチャートの一例を示す図である。リード処理では、アプリケーション301からのデータのリード処理要求を受けて、自ノード100のドライブ214からデータが読み出される。なお、リード処理要求では、リード先(例えば、LUN(Logical Unit Number)のような仮想ボリュームID、LBAのようなアドレス等)が指定されている。アクセス先(ドライブ214等)が障害状態である場合、冗長データからリード対象のデータが修復されて応答される。以下、詳細について説明する。
【0104】
ステップS1101では、リード処理プログラム421は、アクセス先LBAからスライスIDを計算する。より具体的には、リード処理プログラム421は、仮想ボリューム管理テーブル810を参照し、スライスIDリスト813の先頭のスライスから仮想ボリューム313のLBAが連続的に割り当てられているとき、リストを順に辿ることでアクセス先のLBAに該当するスライスIDを取得する。
【0105】
ステップS1102では、リード処理プログラム421は、ステップS1101で取得したスライスID(対象スライス)が自身のノード100(自系ノード)に割り当てられているか否かを判定する。より具体的には、リード処理プログラム421は、スライス管理テーブル820を参照し、該当するスライスIDに対応するストレージプールIDを取得する。次に、リード処理プログラム421は、ストレージプール情報テーブル710を参照し、取得したストレージプールIDに対応するノードIDを取得する。リード処理プログラム421は、取得したノードIDと自系ノードのノードIDとを比較し、同じノードIDである場合、対象スライス(アクセス先のスライス314)が自系ノードに割り当たっていると判定する。リード処理プログラム421は、取得したノードIDと自系ノードのノードIDとが異なるノードIDである場合、対象スライスは、他のノード100(他系ノード)に割り当たっていると判定する。リード処理プログラム421は、対象スライスが自系ノードに割り当てたられていると判定した場合、ステップS1105に処理を移し、対象スライスが自系ノードに割り当てられていないと判定した場合、ステップS1103に処理を移す。
【0106】
ステップS1103では、リード処理プログラム421は、対象スライスを割り当てた先の他系ノードにリード処理要求を転送する。
【0107】
ステップS1104では、リード処理プログラム421は、ステップS1103にて転送したリード処理要求の実行結果を待ち受け、実行結果を受信し、ステップS1111に処理を移す。
【0108】
ステップS1105では、リード処理プログラム421は、アクセス先の領域に関しての排他制御を取得する。
【0109】
ステップS1106では、リード処理プログラム421は、リード処理要求のデータについて、ストレージプール312にページ315が未割当てであるか否かを判定する。リード処理プログラム421は、未割当てであると判定した場合、ステップS1107に処理を移し、未割当てでないと判定した場合、ステップS1108に処理を移す。
【0110】
ステップS1107では、リード処理プログラム421は、データがないことを示す0データを生成し、ステップS1110に処理を移す。
【0111】
ステップS1108では、リード処理プログラム421は、アクセス先のアドレス(割当先アドレス)を取得する。
【0112】
ステップS1109では、リード処理プログラム421は、自系ノードのドライブ214(ローカルドライブ)からデータを読み出す。
【0113】
ステップS1110では、リード処理プログラム421は、取得した排他制御を解放する。
【0114】
ステップS1111では、リード処理プログラム421は、ホスト101にリード処理結果を応答する。
【0115】
ステップS1112では、リード処理プログラム421は、モニタ情報採取処理を実行する。なお、モニタ情報採取処理については、図13Bを用いて後述する。
【0116】
図12は、ライト処理に係るフローチャートの一例を示す図である。ライト処理では、アプリケーション301からのライト処理要求を受けて、自系ノードのドライブ214にデータが書き込まれ、さらに他系ノードのドライブ214に冗長データ(パリティ)が書き込まれる。なお、ライト処理要求では、ライト先(例えば、LUNのような仮想ボリュームID、LBAのようなアドレス等)が指定されている。以下、詳細について説明する。
【0117】
ステップS1201では、ライト処理プログラム422は、アクセス先LBAからスライスIDを計算する。より具体的には、ライト処理プログラム422は、仮想ボリューム管理テーブル810を参照し、スライスIDリスト813の先頭のスライスから仮想ボリューム313のLBAが連続的に割り当てられているとき、リストを順に辿ることでアクセス先のLBAに該当するスライスIDを取得する。
【0118】
ステップS1202では、ライト処理プログラム422は、ステップS1201で取得したスライスID(対象スライス)が自系ノードに割り当てられているか否かを判定する。なお、ライト処理プログラム422は、リード処理プログラム421で説明した方法と同様に判定する。ライト処理プログラム422は、対象スライスが自系ノードに割り当てられていると判定した場合、ステップS1205に処理を移し、対象スライスが自系ノードに割り当てられていないと判定した場合、ステップS1203に処理を移す。
【0119】
ステップS1203では、ライト処理プログラム422は、対象スライスを割り当てた先の他系ノードにライト処理要求を転送する。
【0120】
ステップS1204では、ライト処理プログラム422は、ステップS1203にて転送したライト処理要求の実行結果を待ち受け、実行結果を受信し、ステップS1224に処理を移す。
【0121】
ステップS1205では、ライト処理プログラム422は、アクセス先の領域に関しての排他制御を取得する。
【0122】
ステップS1206では、ライト処理プログラム422は、対象スライスの状態が移動中であるか否かを判定する。より具体的には、ライト処理プログラム422は、スライス管理テーブル820を参照し、アクセス先となるスライス314のスライスIDに対応する状態が、Migratingである場合、移動中であると判定し、Migratingでない場合、移動中でないと判定する。ライト処理プログラム422は、移動中であると判定した場合、ステップS1207に処理を移し、移動中でないと判定した場合、ステップS1209に処理を移す。
【0123】
ステップS1207では、ライト処理プログラム422は、対象スライスの移動先のノード100(移動先ノード)にライト処理要求を転送する。
【0124】
ステップS1208では、ライト処理プログラム422は、ステップS1207にて転送したライト処理要求の実行結果を待ち受け、実行結果を受信し、ステップS1209に処理を移す。
【0125】
ステップS1209では、ライト処理プログラム422は、ライト処理要求のデータについて、ストレージプール312にページ315が未割当てであるか否かを判定する。ライト処理プログラム422は、未割当てであると判定した場合、ステップS1210に処理を移し、未割当てでないと判定した場合、ステップS1211に処理を移す。
【0126】
ステップS1210では、ライト処理プログラム422は、自系ノードのドライブ214の論理ドライブ318が関連付けられているプールボリューム316(自系プールボリューム)にページ315を割り当てる。
【0127】
ステップS1211では、ライト処理プログラム422は、アクセス先のアドレス(割当先アドレス)を取得する。
【0128】
ステップS1212では、ライト処理プログラム422は、書込み前のデータ(旧データ)を読み込む。ライト処理プログラム422は、読み込み先のドライブ214またはノード100が障害状態である場合、リード処理プログラム421で説明したようにパリティから読み込み対象のデータを復元して、旧データを読み込む。
【0129】
ステップS1213では、ライト処理プログラム422は、中間データを生成する。中間データは、データを部分的に更新するときに作成する一時的なデータであり、新旧の差分を示すデータである。例えば、旧データのストライプが「A1-A2-AP」である場合、中間データは、次のように求められる。
【0130】
AP(旧パリティ)=A1(旧データ) XOR A2(旧データ)
A1(新データ) XOR A1(旧データ)=M(中間データ)
なお、新パリティについては、次のように求められる。
AP(旧パリティ) XOR M(中間データ)=AP(新パリティ)
【0131】
ステップS1214では、ライト処理プログラム422は、冗長化先のノード100に中間データ(パリティ更新要求)を送信する。なお、ライト処理プログラム422は、冗長度に応じて(冗長度が2以上である場合、2以上のノード100に)中間データを転送する。
【0132】
ステップS1215では、ライト処理プログラム422は、自系ノードのドライブ214に新データを書き込む。
【0133】
ステップS1216では、冗長化先のノード100のライト処理プログラム422は、中間データを受信する。
【0134】
ステップS1217では、冗長化先のノード100のライト処理プログラム422は、排他制御を取得する。
【0135】
ステップS1218では、冗長化先のノード100のライト処理プログラム422は、自系ノードのドライブ214から旧パリティを読み出す。
【0136】
ステップS1219では、冗長化先のノード100のライト処理プログラム422は、中間データと旧パリティとから新パリティを計算する。
【0137】
ステップS1220では、冗長化先のノード100のライト処理プログラム422は、自系ノードのドライブ214に新パリティを書き込む。
【0138】
ステップS1221では、冗長化先のノード100のライト処理プログラム422は、取得した排他制御を解放し、中間データを転送してきたノード100にパリティ更新結果を応答する。
【0139】
ステップS1222では、ライト処理プログラム422は、冗長化先のノード100から書込み応答を受信する。
【0140】
ステップS1223では、ライト処理プログラム422は、取得した排他制御を解放する。
【0141】
ステップS1224では、ライト処理プログラム422は、ホスト101にライト処理結果を応答する。
【0142】
ステップS1225では、ライト処理プログラム422は、モニタ情報採取処理を実行する。なお、モニタ情報採取処理については、図13Bを用いて後述する。
【0143】
図13Aは、プロセッサ211と、ドライブ214と、およびネットワーク220に関するモニタ情報採取処理に係るフローチャートの一例を示す図である。
【0144】
ステップS1301では、モニタ情報採取処理プログラム423は、プロセッサ211のモニタ情報をテーブルに登録する。より具体的には、プロセッサモニタ情報管理テーブル910にあるように、モニタ情報採取処理プログラム423は、ノード100ごと、プロセスごと、プロセッサコアごとにプロセッサの使用率の情報を収集し、当該テーブルの情報を更新する。図示はしていないが、使用率以外の情報(IDLE、IOWAIT、ハイパーバイザ上の仮想マシンとして実行していれば、STEAL等)が取得され、テーブルに加えられてもよい。
【0145】
ステップS1302では、モニタ情報採取処理プログラム423は、ドライブ214のモニタ情報をテーブルに登録する。より具体的には、ドライブモニタ情報管理テーブル920にあるように、モニタ情報採取処理プログラム423は、ドライブ214ごとに、リードIOPSと、ライトIOPSと、リード転送量と、ライト転送量との情報を収集し、当該テーブルの情報を更新する。図示はしていないが、これら以外の情報(リード応答時間、ライト応答時間、キューサイズ等)が取得され、テーブルに加えられてもよい。
【0146】
ステップS1303では、モニタ情報採取処理プログラム423は、ネットワーク220(NIC)のモニタ情報をテーブルに登録する。より具体的には、ネットワークモニタ情報管理テーブル930にあるように、モニタ情報採取処理プログラム423は、ノード100ごとのNICごとに、送信転送量と、受信転送量と、最大転送量との情報を収集し、当該テーブルの情報を更新する。図示はしていないが、これら以外の情報(パケットドロップ数、再送パケット数等)が取得され、テーブルに加えられてもよい。
【0147】
ステップS1304では、モニタ情報採取処理プログラム423は、一定時間処理を停止し、その後、ステップS1301に処理を移す。つまり、図13Aのモニタ情報採取処理は、周期的に実行される。
【0148】
図13Bは、スライス314のアクセス頻度、およびフロントエンドパス320のアクセス頻度に関するモニタ情報採取処理に係るフローチャートの一例を示す図である。
【0149】
ステップS1311では、モニタ情報採取処理プログラム423は、I/Oを受信したフロントエンドパス320のモニタ情報とアクセス先のスライス314のモニタ情報とを取得する。より具体的には、モニタ情報採取処理プログラム423は、アクセスを受信したフロントエンドパス320に該当するフロントエンドパスモニタ情報管理テーブル950のレコード、およびアクセス先のスライス314に該当するスライスモニタ情報管理テーブル940のレコードを取得する。
【0150】
ステップS1312では、モニタ情報採取処理プログラム423は、受信したI/Oタイプは、リードであるか否かを判定する。モニタ情報採取処理プログラム423は、リードであると判定した場合、ステップS1313に処理を移し、リードでない(ライトである)と判定した場合、ステップS1315に処理を移す。
【0151】
ステップS1313では、モニタ情報採取処理プログラム423は、ステップS1311で取得したレコードの現行リードカウンタに受領したI/Oのカウントを加算する。ここで、IOPSは、秒間当たりの処理量であるので、モニタ情報採取処理プログラム423は、1秒毎にカウンタ値を確定させる、つまり、1秒経過したときに発生したカウンタ値を計算することでIOPSを求め、ステップS1311で取得したレコードのリードIOPSに設定する。
【0152】
ステップS1314では、モニタ情報採取処理プログラム423は、ステップS1311で取得したレコードの現行リード転送量に受領したI/Oの転送量を加算する。
【0153】
ステップS1315では、モニタ情報採取処理プログラム423は、ステップS1311で取得したレコードの現行ライトカウンタに受領したI/Oのカウントを加算する。また、モニタ情報採取処理プログラム423は、1秒毎にカウンタ値を確定させる、つまり、1秒経過したときに発生したカウンタ値を計算することでIOPSを求め、ステップS1311で取得したレコードのライトIOPSに設定する。
【0154】
ステップS1316では、モニタ情報採取処理プログラム423は、ステップS1311で取得したレコードの現行ライト転送量に受領したI/Oの転送量を加算する。
【0155】
図14は、リバランス要否判定処理に係るフローチャートの一例を示す図である。本処理は、ストレージシステム200により周期的に実行されてもよいし、ユーザ(手動)により任意の契機に実行されてもよいし、リード処理またはライト処理の完了後に実行されてもよいし、後述のクラスタ構成変更処理の実行後に実行されてもよい。
【0156】
ステップS1401では、リバランス要否判定処理プログラム424は、ストレージプール312の使用率が上限閾値以上のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、ストレージプール312の使用率が上限閾値以上のノード100が存在すると判定した場合、ステップS1405に処理を移し、存在しないと判定した場合、ステップS1402に処理を移す。
【0157】
ステップS1402では、リバランス要否判定処理プログラム424は、プロセッサ211の使用率が上限閾値以上のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、プロセッサ211の使用率が上限閾値以上のノード100が存在すると判定した場合、ステップS1405に処理を移し、存在しないと判定した場合、ステップS1403に処理を移す。
【0158】
ステップS1403では、リバランス要否判定処理プログラム424は、ドライブ214の使用率が上限閾値以上のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、ドライブ214の使用率が上限閾値以上のノード100が存在すると判定した場合、ステップS1405に処理を移し、存在しないと判定した場合、ステップS1404に処理を移す。
【0159】
ステップS1404では、リバランス要否判定処理プログラム424は、ネットワーク220(NIC)の使用率が上限閾値以上のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、ネットワーク220の使用率が上限閾値以上のノード100が存在すると判定した場合、ステップS1405に処理を移し、存在しないと判定した場合、ステップS1406に処理を移す。
【0160】
ステップS1405では、リバランス要否判定処理プログラム424は、リソース割当決定処理(分散ポリシ)を実行する。なお、リソース割当決定処理(分散ポリシ)については、図15を用いて後述する。
【0161】
ステップS1406では、リバランス要否判定処理プログラム424は、プロセッサ211の使用率が下限閾値未満のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、プロセッサ211の使用率が下限閾値未満のノード100が存在すると判定した場合、ステップS1409に処理を移し、存在しないと判定した場合、ステップS1407に処理を移す。
【0162】
ステップS1407では、リバランス要否判定処理プログラム424は、ドライブ214の使用率が下限閾値未満のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、ドライブ214の使用率が下限閾値未満のノード100が存在すると判定した場合、ステップS1409に処理を移し、存在しないと判定した場合、ステップS1408に処理を移す。
【0163】
ステップS1408では、リバランス要否判定処理プログラム424は、ネットワーク220(NIC)の使用率が下限閾値未満のノード100が存在するか否かを判定する。リバランス要否判定処理プログラム424は、ネットワーク220の使用率が下限閾値未満のノード100が存在すると判定した場合、ステップS1409に処理を移し、存在しないと判定した場合、処理を終了する。
【0164】
ステップS1409では、リバランス要否判定処理プログラム424は、リソース割当決定処理(集約ポリシ)を実行する。なお、リソース割当決定処理(集約ポリシ)については、図16を用いて後述する。
【0165】
なお、ステップS1402~ステップS1404、および、ステップS1406~ステップS1408は、ノード100の負荷を判定するものであり、ノード100に仮想ボリューム313が1つ設けられている場合は、仮想ボリューム313の負荷を判定するものでもある。
【0166】
また、図14で説明したリソース割当決定処理を実行するか否かを判定するためのメトリクスは、プロセッサ211、ドライブ214、ポート215以外にも仮想ボリューム313に対するIOPSおよび/または転送量を用いてもよい。IOPSまたは転送量をメトリクスとして用いる場合、リードとライトとで異なる閾値を設けて判定してもよい。
【0167】
また、各ノード100は、自系ノードの負荷を低減するために、自系ノードが提供している仮想ボリューム313のうち、領域を移動していない仮想ボリューム313を他系ノードに移動してもよい。これにより、移動している領域がある仮想ボリューム313に、当該領域を戻すことが(当該領域を移動)できる場合がある。
【0168】
図15は、分散ポリシに基づくリソース割当決定処理に係るフローチャートの一例を示す図である。
【0169】
ステップS1501では、リソース割当決定処理プログラム425は、各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)が上限閾値以上のノード100を移動元のノード100(移動元ノード)に選択し、移動対象とする仮想ボリューム313を選択する。言い換えると、リソース割当決定処理プログラム425は、プロセッサ211、ドライブ214、ネットワーク220の負荷に余裕のないノード100を選択し、データの移動元(ここでは分散元ともいえる)の仮想ボリューム313を選択する。
【0170】
より具体的には、リソース割当決定処理プログラム425は、リバランス要否判定処理のステップS1402、ステップS1403、またはステップS1404で選択されたノード100に定義された仮想ボリューム313を選択する。例えば、リソース割当決定処理プログラム425は、仮想ボリューム313を選択する際、ストレージプログラム311と同じノード100にアプリケーション301が動作するHCI(Hyper-Converged Infrastracture)構成をとっている場合、同じノード100内のアプリケーション301が使用している仮想ボリューム313を避けて選択する。これは、同じノード100内のアプリケーション301が使用している仮想ボリューム313を選択し、分散させるとアプリケーション301は、ネットワーク220を介してデータへアクセスすることになり、処理効率が低下するためである。
【0171】
付言するならば、ステップS1403、またはステップS1404で選択されたノード100に定義された仮想ボリューム313が1つである場合、リソース割当決定処理プログラム425は、当該仮想ボリューム313を選択する。
【0172】
ステップS1502では、リソース割当決定処理プログラム425は、仮想ボリューム313またはストレージシステム200に設定された分散ポリシを判定する。リソース割当決定処理プログラム425は、分散ポリシがボリューム単位分散ポリシであると判定した場合、ステップS1503に処理を移し、分散ポリシがスライス単位最大分散ポリシ(スライス単位均等分散ポリシ)であると判定した場合、ステップS1506に処理を移し、分散ポリシがスライス単位最小分散ポリシであると判定した場合、ステップS1509に処理を移す。
【0173】
ボリューム単位分散ポリシは、仮想ボリューム313単位で負荷が分散されるポリシである。ボリューム単位分散ポリシでは、仮想ボリューム313単位でまとめてスライス314が移動される。ボリューム単位分散ポリシでは、仮想ボリューム313単位でスライス314が移動されるため、常にデータの集約が保たれた状態で負荷分散を行うことができる。
【0174】
スライス単位最大分散ポリシは、スライス314単位で負荷が分散されるポリシである。スライス単位最大分散ポリシでは、仮想ボリューム313に設定された最大分散度のノード数だけスライス314が分散される。スライス単位最大分散ポリシでは、最大分散度でスライス314が分散されるため、高負荷なノード100(仮想ボリューム313)を迅速に負荷分散することができる。
【0175】
スライス単位最小分散ポリシは、スライス314単位で負荷が分散されるポリシである。スライス単位最小分散ポリシでは、仮想ボリューム313内のスライス314が1つずつ分散されていく。スライス単位最小分散ポリシでは、1つずつスライス314が分散されていくことで、データのローカリティを可能な限り保ちつつ、最小限の負荷だけを高負荷なノード100(仮想ボリューム313)から逃がすことで過負荷状態を回避する。
【0176】
これらの分散ポリシは、ユーザが仮想ボリューム313に対して、事前に設定してもよいし、ストレージシステム200が状況に応じて分散ポリシを自動で選択してもよい。ストレージシステム200が自動でポリシを選択する方法の一例として、基本的には、ストレージシステム200は、ボリューム単位分散ポリシを適用しておき、仮想ボリューム313が1つのノード100の性能で不足する場合に、スライス単位最大分散ポリシまたはスライス単位最小分散ポリシに切り替える。加えて、ストレージシステム200は、仮想ボリューム313の負荷が突発的に高くなった場合は、スライス単位最大散ポリシを適用し、仮想ボリューム313の負荷が緩やかに高くなった場合は、スライス単位最小分散ポリシを適用する。
【0177】
ステップS1503、ステップS1504、およびステップS1505では、リソース割当決定処理プログラム425は、仮想ボリューム313単位でスライス314を移動するための前処理を行う。
【0178】
ステップS1503では、リソース割当決定処理プログラム425は、選択した仮想ボリューム313内の全てのスライス314をスライスグループとしてグルーピングする。例えば、リソース割当決定処理プログラム425は、スライス管理テーブル820から移動対象のスライスIDをメモリ212上にリストとして格納する。
【0179】
ステップS1504では、リソース割当決定処理プログラム425は、計算したスライスグループを移動対象として設定する。
【0180】
ステップS1505では、リソース割当決定処理プログラム425は、移動先ノード数を「1ノード」に設定する。
【0181】
ステップS1506、ステップS1507、およびステップS1508では、リソース割当決定処理プログラム425は、仮想ボリューム313に設定された最大分散度でスライス314を移動するための前処理を行う。
【0182】
ステップS1506では、リソース割当決定処理プログラム425は、選択した仮想ボリューム313内の全てのスライス314を仮想ボリューム313に設定された最大分散度で分割し、スライスグループとしてグルーピングする。例えば、リソース割当決定処理プログラム425は、グルーピングする際、選択した仮想ボリューム313にアクセスするホスト101が複数存在する場合で、かつ、ホスト101ごとにアクセス対象のスライス314に偏り(ローカリティ)がある場合、ホスト101ごとのアクセス対象のスライス314をグルーピングする。また、例えば、リソース割当決定処理プログラム425は、スライスモニタ情報管理テーブル940を確認し、仮想ボリューム313内の全てのスライス314を最大分散度のノード100で負荷が均等になるようにグルーピングしてもよい。
【0183】
ステップS1507では、リソース割当決定処理プログラム425は、計算したスライスグループを移動対象として設定する。
【0184】
ステップS1508では、リソース割当決定処理プログラム425は、移動先ノード数を最大分散度と同値に設定する。
【0185】
ステップS1509、ステップS1510、およびステップS1511では、リソース割当決定処理プログラム425は、最小分散度(つまり1スライス)でスライス314を移動するための前処理を行う。
【0186】
ステップS1509では、リソース割当決定処理プログラム425は、選択した仮想ボリューム313内からスライス314を1つ選択する。
【0187】
ステップS1510では、リソース割当決定処理プログラム425は、選択したスライス314を移動対象として設定する。
【0188】
ステップS1511では、リソース割当決定処理プログラム425は、移動先ノード数を「1ノード」に設定する。
【0189】
ステップS1512では、リソース割当決定処理プログラム425は、移動対象を1つ選択する。前処理で、スライスグループが作られた場合は、リソース割当決定処理プログラム425は、スライスグループを移動対象として選択し、スライス314がそのまま選択された場合は、スライス314を移動対象として選択する。
【0190】
ステップS1513では、リソース割当決定処理プログラム425は、移動先とするノード100を1つ選択する。リソース割当決定処理プログラム425は、移動先ノードの選択方法の一例として、移動元ノードを除き、各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)の負荷に余裕のあるノード100を選択する方法がある。
【0191】
ステップS1514では、リソース割当決定処理プログラム425は、選択した移動対象を移動先ノードに移動した場合の移動先ノードの各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)の負荷を計算する。
【0192】
ステップS1515では、リソース割当決定処理プログラム425は、ステップS1514で計算した移動先ノードの各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)の負荷が閾値を超過していないかを判定する。リソース割当決定処理プログラム425は、1つでも閾値を超過しているメトリクスがあると判定した場合、ステップS1513に処理を移し、全てのメトリクスにおいて閾値を超過していないと判定した場合、ステップS1516に処理を移す。なお、各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)の上限閾値とステップS1515の各メトリクスの閾値とは、同じであってもよいし、異なっていてもよい。
【0193】
ステップS1516では、リソース割当決定処理プログラム425は、ステップS1515で判定したノード100を移動先ノードとして選択する。
【0194】
ステップS1517では、リソース割当決定処理プログラム425は、全ての移動対象に対して判定を完了したか否かを判定する。リソース割当決定処理プログラム425は、全ての移動対象に対して判定が完了している場合、ステップS1518に処理を移し、全ての移動対象に対して判定が完了していない場合、ステップS1512に処理を移す。
【0195】
ステップS1518では、リソース割当決定処理プログラム425は、移動対象としてスライスグループまたはスライス314を対象にして、リソース移動処理を実行する。リソース移動処理については、図17を用いて後述する。
【0196】
ステップS1519では、リソース割当決定処理プログラム425は、閾値を超過していたノード100(仮想ボリューム313)の負荷が閾値未満となったか否かを判定する。リソース割当決定処理プログラム425は、閾値未満でないと判定した場合、ステップS1501に処理を移し、閾値未満であると判定した場合、処理を終了する。
【0197】
図16は、集約ポリシに基づくリソース割当決定処理に係るフローチャートの一例を示す図である。
【0198】
ステップS1601では、リソース割当決定処理プログラム425は、各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)が下限閾値未満のノードを移動先ノードに選択する。言い換えると、リソース割当決定処理プログラム425は、プロセッサ211、ドライブ214、ネットワーク220等の負荷に余裕のあるノード100(仮想ボリューム313)を選択し、データの移動先(ここでは集約先ともいえる)のノード100とする。例えば、リソース割当決定処理プログラム425は、リバランス要否判定処理のステップS1406、ステップS1407、またはステップS1408で選択されたノード100を選択する。
【0199】
ステップS1602では、リソース割当決定処理プログラム425は、ステップS1601で選択した移動先ノードに、スライス314が分散した仮想ボリューム313が存在するか否かを判定する。リソース割当決定処理プログラム425は、スライス314が分散した仮想ボリューム313が存在すると判定した場合、ステップS1604に処理を移し、スライス314が分散した仮想ボリューム313が存在しないと判定した場合、ステップS1603に処理を移す。
【0200】
ステップS1603では、リソース割当決定処理プログラム425は、ステップS1601で選択した移動先ノード以外のノード100に、スライス314が分散した仮想ボリューム313が存在するか否かを判定する。リソース割当決定処理プログラム425は、スライス314が分散した仮想ボリューム313が存在すると判定した場合、ステップS1604に処理を移し、スライス314が分散した仮想ボリューム313が存在しないと判定した場合、集約対象(移動対象)の仮想ボリューム313は存在しないため、処理を終了する。
【0201】
上述したように、ステップS1602とステップS1603とでは、リソース割当決定処理プログラム425は、移動対象の仮想ボリューム313を選択する。リソース割当決定処理プログラム425は、選択する際、移動先ノードとして選択したノード100上の仮想ボリューム313を優先的に選択することで、集約時のスライス314の移動量を削減する効果がある。
【0202】
ステップS1604では、リソース割当決定処理プログラム425は、選択した仮想ボリューム313を移動対象に選択する。
【0203】
付言するならば、リソース割当決定処理プログラム425は、仮想ボリューム313の負荷に余裕のあるノード100があり、当該仮想ボリューム313のスライス314が分散している場合、当該ノード100を移動先ノードとし、当該仮想ボリューム313のスライス314が分散している仮想ボリューム313を移動対象に選択することがある。
【0204】
ステップS1605では、リソース割当決定処理プログラム425は、移動対象ボリューム内のスライス314を1つ選択する。選択の方法としては、例えば、スライスモニタ情報管理テーブル940を参照し、移動対象ボリューム内のスライス314から処理負荷の高いスライス314を選択する。
【0205】
ステップS1606では、リソース割当決定処理プログラム425は、選択したスライス314を移動先ノードに移動した場合の各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)の負荷を計算する。
【0206】
ステップS1607では、リソース割当決定処理プログラム425は、ステップS1606で計算したスライス314を移動後の各メトリクス(プロセッサ211、ドライブ214、ネットワーク220等)の負荷が閾値を超過していないかを判定する。リソース割当決定処理プログラム425は、1つでも閾値を超過しているメトリクスがあると判定した場合、処理を終了し、全てのメトリクスにおいて閾値を超過していないと判定した場合、ステップS1608に処理を移す。
【0207】
ステップS1608では、リソース割当決定処理プログラム425は、移動対象のスライス314を対象にして、移動対象の仮想ボリューム313を提供するノード100にリソース移動処理の実行を要求する。リソース移動処理については、図17を用いて後述する。
【0208】
ステップS1609では、リソース割当決定処理プログラム425は、移動対象ボリューム内の全てのスライス314に対して、移動するか否かの判定を行ったかを判定する。リソース割当決定処理プログラム425は、全てのスライス314に対して移動するか否かの判定を行った場合、処理を終了し、全てのスライス314に対して移動するか否かの判定を行っていない場合、ステップS1605に処理を移し、まだ未判定のスライス314に対して処理を行う。
【0209】
図17は、リソース移動処理に係るフローチャートの一例を示す図である。リソース移動処理では、処理対象のスライス314について、現在割当たっているストレージプール312から別ノード100のストレージプール312へ割当先が移動される。リソース移動処理プログラム426は、スライス314の割当先を移動するにあたり、スライス314に書き込まれたデータを移動元のストレージプール312から読み出し、移動先のストレージプール312へ書き出す。
【0210】
ステップS1701では、リソース移動処理プログラム426は、移動対象のスライス314の状態を移動中に更新する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820から移動対象のスライス314のレコードを取得し、状態824の値を「Miggrating」に更新する。
【0211】
ステップS1702では、リソース移動処理プログラム426は、移動対象のスライス314の先頭オフセットを取得する。より具体的には、リソース移動処理プログラム426は、ページマッピングテーブル830を参照し、移動対象のスライス314のスライスIDに該当するレコードを参照し、プールボリュームIDとプールボリュームLBAとを取得する。次に、リソース移動処理プログラム426は、プールボリューム管理テーブル610を参照し、取得したプールボリュームIDに該当するレコードを参照し、論理ドライブIDを取得する。次に、リソース移動処理プログラム426は、論理ドライブ管理テーブル630を参照し、取得した論理ドライブIDに該当するレコードを取得し、ドライブIDと開始オフセットを取得し、先に取得しているプールボリュームLBAからアクセス先のドライブ214のアドレスを求める。例えば、リソース移動処理プログラム426は、以下のように計算する。
【0212】
アクセス先アドレス = 開始オフセット + プールボリュームLBA
【0213】
ステップS1703では、リソース移動処理プログラム426は、アクセス先の領域の排他制御を取得する。
【0214】
ステップS1704では、リソース移動処理プログラム426は、処理対象のオフセットのデータについて、ストレージプール312にページ315が未割当てであるか否かを判定する。リソース移動処理プログラム426は、未割当てであると判定した場合、ステップS1707に処理を移し、未割当てでないと判定した場合、ステップS1705に処理を移す。
【0215】
ステップS1705では、リソース移動処理プログラム426は、取得したオフセットに該当するスライス314の移動元のストレージプール312の領域にリードを発行する。より具体的には、リード処理が実行される。なお、リード処理の動作は、図11で説明したとおりである。
【0216】
ステップS1706では、リソース移動処理プログラム426は、取得したオフセットに該当するスライス314の移動先のストレージプール312の領域にステップS1705で読み取ったデータでライトを発行する。ライト先として、移動元のスライス314に対してライトを発行する。移動元のスライス314では、ライト処理プログラム422内にてステップS1206の分岐で、Yesの判定となり、移動先のスライス314へデータの書き込みがなされる。ただし、ステップS1706のライト発行先は、移動先のスライス314としてもよい。なお、ライト処理の動作は、図12で説明したとおりである。
【0217】
ステップS1707では、リソース移動処理プログラム426は、アクセス先の領域の排他制御を解放する。
【0218】
ステップS1708では、リソース移動処理プログラム426は、現在処理対象としているアクセス先のオフセットが移動対象のスライス314の終端オフセットであるか否かを判定する。リソース移動処理プログラム426は、終端オフセットであると判定した場合、ステップS1710に処理を移し、終端オフセットでないと判定した場合、ステップS1709に処理を移す。
【0219】
ステップS1709では、リソース移動処理プログラム426は、移動対象のスライス314の次のオフセットを取得する。
【0220】
ステップS1710では、リソース移動処理プログラム426は、移動対象のスライス314の制御情報に関する排他制御を取得する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820のアクセス先のスライス314のスライスIDに該当するレコードの排他制御を取得する。
【0221】
ステップS1711では、リソース移動処理プログラム426は、スライス314を割当てるストレージプール312の情報を更新する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820のストレージプールID823の情報を、移動元のストレージプールIDから移動先のストレージプールIDに更新する。
【0222】
ステップS1712では、リソース移動処理プログラム426は、移動対象のスライス314の制御情報に関する排他制御を解放する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820のアクセス先のスライス314のスライスIDに該当するレコードの排他制御を解放する。
【0223】
ステップS1713では、リソース移動処理プログラム426は、移動対象のスライス314の状態を正常に更新する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820から移動対象のスライス314のレコードを取得し、状態824の値を「Normal」に更新する。
【0224】
ステップS1714では、リソース移動処理プログラム426は、移動対象のスライス314を全て移動したか否かを判定する。リソース移動処理プログラム426は、全ての移動対象のスライス314を移動していない判定した場合、ステップS1701に処理を移し、全ての移動対象のスライス314を移動したと判定した場合、処理を終了する。
【0225】
図18は、フロントエンドパス設定処理に係るフローチャートの一例を示す図である。
【0226】
ステップS1801では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311にスライス314の移動があったか否かを問合せる。
【0227】
ステップS1802では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、スライス314の移動の有無を判定し、パス設定プログラム302に応答する。より具体的には、ストレージプログラム311は、現在時刻までのスライス314の移動記録と、パス設定プログラム302から前回問い合わせられたときの時刻情報とをログとして保存しておき、パス設定プログラム302からの前回の問い合わせ時刻以降に、スライス314の移動記録が更新されているか確認する。ストレージプログラム311のフロントエンドパス設定処理プログラム427は、スライス314の移動記録が更新されている場合、移動があったと判定し、更新がなかった場合、移動はなかったと判定し、判定結果をパス設定プログラム302に応答する。
【0228】
ステップS1803では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311からの応答を受信する。
【0229】
ステップS1804では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311からの応答内容に基づき、スライス314の移動があったか否かを判定する。パス設定プログラム302のフロントエンドパス設定処理プログラム427は、スライス314の移動があったと判定した場合、ステップS1805に処理を移し、スライス314の移動がなかったと判定した場合、処理を終了する。
【0230】
ステップS1805では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、移動したスライス314の情報をストレージプログラム311に問い合わせる。
【0231】
ステップS1806では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、移動したスライス314と、当該スライス314を含む仮想ボリューム313との情報をパス設定プログラム302に応答する。
【0232】
ステップS1807では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311からの応答を受信する。
【0233】
ステップS1808では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、移動したスライス314の移動先ノード(移動したスライス314を含む仮想ボリューム313)にパス320が設定されているか否かを確認する。パス設定プログラム302のフロントエンドパス設定処理プログラム427は、フロントエンドパス320を設定済みであると判定した場合、処理を終了し、フロントエンドパス320を未設定であると判定した場合、ステップS1809に処理を移す。
【0234】
ステップS1809では、フロントエンドパス設定処理プログラム427は、移動したスライス314を含む仮想ボリューム313について、当該スライス314の移動先ノードとのフロントエンドパス320の確立を要求する。パス設定プログラム302とストレージプログラム311と間での具体的なパス確立の手順は、iSCSI(Internet Small Computer System Interface)、Fiber Channelのプロトコル等に基づく。
【0235】
ステップS1810では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、パス設定プログラム302から要求された仮想ボリューム313とホスト101とのパス情報をフロントエンドパス情報テーブル1010に登録し、パス設定プログラム302に応答する。
【0236】
ステップS1811では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311からパス設定完了の応答を受信する。
【0237】
図19は、SCSI(Small Computer System Interface)規格のALUA(Asymmetric Logical Unit Access)のメカニズムに基づきフロントエンドパス320の設定を最適化する際のフロントエンドパス設定処理に係るフローチャートの一例を示す図である。
【0238】
ステップS1901では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、処理対象の仮想ボリューム313を選択する。より具体的には、処理対象の仮想ボリューム313については、定義された全ての仮想ボリューム313に対して周期的に選択してもよいし、リード処理またはライト処理の実行の完了後に、当該処理においてアクセスのあった仮想ボリューム313を選択してもよい。
【0239】
ステップS1902では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、仮想ボリューム313に接続されたホスト101を処理対象として選択する。より具体的には、処理対象のホスト101については、処理対象の仮想ボリューム313に定義された全てのホスト101を選択してもよいし、リード処理またはライト処理の実行の完了後に、当該処理においてアクセスのあったホスト101を選択してもよい。
【0240】
ステップS1903では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、選択した仮想ボリューム313と選択したホスト101と間のパスの情報を取得する。より具体的には、フロントエンドパス設定処理プログラム427は、フロントエンドパス情報テーブル1010を参照し、選択した仮想ボリューム313の仮想ボリュームIDと、選択したホスト101のInitiatorIDとに該当するレコードを取得する。
【0241】
ステップS1904では、フロントエンドパス設定処理プログラム427は、ステップS1903で取得したフロントエンドパス320へのI/Oの発行比率を計算する。より具体的には、フロントエンドパス設定処理プログラム427は、フロントエンドパスモニタ情報管理テーブル950のリードIOPS952とライトIOPS953とを参照し、パスAにリードおよびライトのIOPSが合計900IOPS発行されており、パスBにリードおよびライトのIOPSが合計100IOPS発行されている場合、パスAとパスBのI/O発行比率を、パスA:パスB=9:1と計算する。加えて、フロントエンドパス設定処理プログラム427は、同様にリードおよびライトの転送量についても、比率を計算し、IOPSと転送量とで各パスのI/Oの発行比率の分散が大きい方を最終的な比率として採用してもよいし、IOPSと転送量との比率の平均値を最終的な比率として採用してもよい。
【0242】
ステップS1905では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、I/Oの発行比率が特定のフロントエンドパス320(ホスト101)に偏っているか否かを判定する。例えば、フロントエンドパス設定処理プログラム427は、各フロントエンドパス320へのI/O発行比率の分散を計算し、分散が閾値を上回っている場合に偏りが発生していると判定する。ストレージプログラム311のフロントエンドパス設定処理プログラム427は、特定のフロントエンドパス320にI/Oの発行比率が偏っていると判定した場合、ステップS1906に処理を移し、特定のフロントエンドパス320にI/Oの発行比率が偏っていないと判定した場合、ステップS1907に処理を移す。
【0243】
ステップS1906では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、I/Oの発行比率が高いフロントエンドパス320を「Optimize(最適パス)」に設定する。例えば、フロントエンドパス設定処理プログラム427は、フロントエンドパス情報テーブル1010を参照し、I/Oの発行比率が閾値より高いフロントエンドパス320のパスIDと一致するレコードのALUA設定1014を「Optimize」に更新し、I/Oの発行比率が閾値より高くないフロントエンドパス320のパスIDと一致するレコードのALUA設定1014を、「Non-Optimize」に更新する。
【0244】
ステップS1907では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、選択した仮想ボリューム313に定義された全てのフロントエンドパス320について「Optimize(最適パス)」に設定(いわゆるラウンドロビンに設定)する。
【0245】
ステップS1908では、ストレージプログラム311のフロントエンドパス設定処理プログラム427は、パス設定プログラム302に、「Optimize」に設定したフロントエンドパス320の情報(最適化情報)を通知する。図19では、ストレージプログラム311からパス設定プログラム302へ通知を発行する形式で情報を伝達するが、パス設定プログラム302からストレージプログラム311に問い合わせる形式で情報を伝達してもよい。
【0246】
ステップS1909では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311からフロントエンドパス320の最適化情報を受領する。
【0247】
ステップS1910では、パス設定プログラム302のフロントエンドパス設定処理プログラム427は、ストレージプログラム311から受信したフロントエンドパス320を「Optimize(最適パス)」に設定する。以降、アプリケーション301は、最適パスに対して優先的にI/Oを発行するように制御される。
【0248】
図20は、クラスタ構成変更処理に係るフローチャートの一例を示す図である。
【0249】
ステップS2001では、クラスタ構成変更処理プログラム428は、ユーザからのクラスタ操作要求を受信する。
【0250】
ステップS2002では、クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求が仮想ボリューム313の作成または削除の要求であるか否かを判定する。クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求が仮想ボリューム313の作成または削除の要求であると判定した場合、ステップS2007に処理を移し、受信したクラスタ操作要求が仮想ボリューム313の作成または削除の要求でないと判定した場合、ステップS2003に処理を移す。
【0251】
ステップS2003では、クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求が仮想ボリューム313の拡張または縮小の要求であるか否かを判定する。クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求が仮想ボリューム313の拡張または縮小の要求であると判定した場合、ステップS2007に処理を移し、受信したクラスタ操作要求が仮想ボリューム313の拡張または縮小の要求でないと判定した場合、ステップS2004に処理を移す。
【0252】
ステップS2004では、クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求がドライブ214の増設または減設の要求であるか否かを判定する。クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求がドライブ214の増設または減設の要求であると判定した場合、ステップS2007に処理を移し、受信したクラスタ操作要求がドライブ214の増設または減設の要求でないと判定した場合、ステップS2005に処理を移す。
【0253】
ステップS2005では、クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求がノード100の増設または減設の要求であるか否かを判定する。クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求がノード100の増設または減設の要求であると判定した場合、ステップS2007に処理を移し、受信したクラスタ操作要求がノード100の増設または減設の要求でないと判定した場合、ステップS2006に処理を移す。
【0254】
ステップS2006では、クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求がサイト201の増設または減設の要求であるか否かを判定する。クラスタ構成変更処理プログラム428は、受信したクラスタ操作要求がサイト201の増設または減設の要求であると判定した場合、ステップS2007に処理を移し、受信したクラスタ操作要求がサイト201の増設または減設の要求でないと判定した場合、ステップS2001に処理を移す。
【0255】
ステップS2007では、クラスタ構成変更処理プログラム428は、ユーザから要求された操作を実行する。
【0256】
ステップS2008では、クラスタ構成変更処理プログラム428は、リバランス要否判定処理を実行する。なお、リバランス要否判定処理については、図14を用いて説明したので、その説明を省略する。
【0257】
図21Aは、ユーザが操作可能なボリュームの設定画面(GUI:Graphical User Interface)の一例を示す図である。ボリューム設定画面2101は、ストレージシステム200と通信可能に接続された所定の計算機(例えば、管理サーバ等)に出力される。
【0258】
ボリューム設定画面2101は、仮想ボリューム313ごとの設定が行われる画面である。ボリューム設定画面2101は、ボリュームID2102および分散度2103の情報を設定可能に構成される。
【0259】
ボリュームID2102は、設定対象とする仮想ボリューム313を指定する項目である。分散度2103は、設定対象の仮想ボリューム313のスライス314を分散するノード数の最大値の情報(最大分散度)を設定可能な項目である。
【0260】
図21Bは、ストレージシステム200がユーザに提示するボリューム性能予測画面2111(GUI)の一例を示す図である。ボリューム性能予測画面2111は、ストレージシステム200と通信可能に接続された所定の計算機(例えば、管理サーバ等)に出力される。
【0261】
ボリューム性能予測画面2111は、ボリューム性能予測情報2112とメッセージ2120とを含んで構成される。
【0262】
ボリューム性能予測情報2112は、確認対象の仮想ボリューム313について、最大分散度とスループット(IOPS)と応答時間とに関する情報をユーザに提示する。ボリューム性能予測情報2112は、分散度情報2113、スループット情報2114、応答時間情報2115、予測スループット情報2116、予測応答時間情報2117、現行分散度情報2118、および目標性能値情報2119を含んで構成される。
【0263】
分散度情報2113は、最大分散度に関する情報を含む。スループット情報2114は、IOPSに関する情報を含む。応答時間情報2115は、応答時間に関する情報を含む。予測スループット情報2116は、該当する最大分散度におけるスループットの予測値に関する情報を含む。予測応答時間情報2117は、該当する最大分散度における応答時間の予測値に関する情報を含む。現行分散度情報2118は、確認対象の仮想ボリューム313に現在設定されている最大分散度に関する情報を含む。目標性能値情報2119は、確認対象の仮想ボリューム313に現在設定されている目標とする(ユーザが期待する)スループットおよび応答時間の性能値に関する情報を含む。
【0264】
メッセージ2120は、現行分散度情報2118に基づく予測応答時間情報2117が目標性能値情報2119を超過する場合、または、現行分散度情報2118に基づく予測スループット情報2116が目標性能値情報2119未満となる場合、ストレージシステム200は、ユーザに対して、現在の最大分散度では目標性能値を達成できない旨を提示する。また、メッセージ2120は、現在の設定値から最大分散度を変更したときに予測性能が目標性能値を満たせるか否かをユーザに提示する。
【0265】
本実施の形態によれば、1つのボリュームについて容量および性能をスケールアウトすることができる。
【0266】
(II)第2の実施の形態
図22は、本実施の形態のストレージシステム2200に係る構成の一例を示す図である。第1の実施の形態と同じ構成については、同じ符号を用いて説明を省略する。
【0267】
ストレージシステム2200は、図2の構成に加えて、ドライブボックス2201を含んで構成される。ドライブボックス2201は、例えば、プロセッサ211、メモリ212等を含む1以上のプロセッサパッケージ213、1以上のドライブ214、1以上のポート215を含んで構成される。各構成要素は、内部バス216を介して接続されている。
【0268】
ポート215は、ネットワーク2202に接続され、サイト201内のノード100と通信可能に接続されている。ネットワーク2202は、例えば、LAN、SAN(Storage Area Network)、SAS(Serial Attached SCSI)であるが、これらに限定するものではない。
【0269】
プロセッサ211では、ドライブボックス2201に対する、I/O処理プログラムが動作しており、必要に応じて、データの圧縮処理、ドライブボックス2201内のドライブ214に対するRAID処理等を実施してもよい。また、ドライブボックス2201は、上記に加えて、専用のハードウェアであるASIC(Application Specific Integrated Circuit)が搭載されていてもよく、ASICは、データ圧縮処理、パリティ演算処理等を備えていてもよい。
【0270】
図23は、本実施の形態におけるリソース移動処理に係るフローチャートの一例を示す図である。リソース移動処理では、リバランス要否判定処理の結果を受けて、リバランスが必要となった場合にノード100間でスライス314を移動する。
【0271】
第1の実施の形態との違いについて説明する。本実施の形態では、スライス314内のデータは、ノード100間で共有されたドライブボックス2201に配置される。このため、ノード100間でスライス314を移動する場合も仮想ボリューム313とスライス314の割り当てとに関する制御情報を更新するだけでよく、データ自体は移動する必要はない。以下、詳細について説明する。
【0272】
ステップS2301では、リソース移動処理プログラム426は、移動対象のスライス314の状態を移動中に更新する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820から移動対象のスライス314のレコードを取得し、状態824の値を「Miggrating」に更新する。
【0273】
ステップS2302では、リソース移動処理プログラム426は、移動対象のスライス314の制御情報に関する排他制御を取得する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820のアクセス先のスライス314のスライスIDに該当するレコードの排他制御を取得する。
【0274】
ステップS2303では、リソース移動処理プログラム426は、スライス314を割当てるストレージプール312の情報を更新する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820のストレージプールID823の情報を、移動元のストレージプールIDから移動先のストレージプールIDに更新する。
【0275】
ステップS2304では、リソース移動処理プログラム426は、移動対象のスライス314の制御情報に関する排他制御を解放する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820のアクセス先のスライス314のスライスIDに該当するレコードの排他制御を解放する。
【0276】
ステップS2305では、リソース移動処理プログラム426は、移動対象のスライス314の状態を正常に更新する。より具体的には、リソース移動処理プログラム426は、スライス管理テーブル820から移動対象のスライス314のレコードを取得し、状態824の値を「Normal」に更新する。
【0277】
本実施の形態によれば、データを移動することなく、1つのボリュームについて性能をスケールアウトすることができる。
【0278】
(III)付記
上述の実施の形態には、例えば、以下のような内容が含まれる。
【0279】
上述の実施の形態においては、本発明をストレージシステムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。
【0280】
また、上述の実施の形態においては、スライスモニタ情報管理テーブル940は、スライスID941と、リードカウンタ942と、ライトカウンタ943と、リード転送量944と、ライト転送量945と、モニタ開始時刻946とが対応付けられた情報を格納する場合について述べたが、本発明はこれに限らない。例えば、スライスモニタ情報管理テーブル940は、スライスID941と、リードIOPSと、ライトIOPSと、リード転送量944と、ライト転送量945とが対応付けられた情報を格納するようにしてもよい。
【0281】
また、上述の実施の形態においては、フロントエンドパスモニタ情報管理テーブル950は、パスID951と、リードIOPS952と、ライトIOPS953と、リード転送量954と、ライト転送量955とが対応付けられた情報を格納する場合について述べたが、本発明はこれに限らない。例えば、フロントエンドパスモニタ情報管理テーブル950は、パスID951と、リードカウンタと、ライトカウンタと、リード転送量954と、ライト転送量955と、モニタ開始時刻とが対応付けられた情報を格納するようにしてもよい。
【0282】
また、上述の実施の形態において、各テーブルの構成は一例であり、1つのテーブルは、2以上のテーブルに分割されてもよいし、2以上のテーブルの全部または一部が1つのテーブルであってもよい。
【0283】
また、上述の実施の形態において、図示および説明した画面は、一例であり、受け付ける情報が同じであるならば、どのようなデザインであってもよい。
【0284】
また、上述の実施の形態において、図示および説明した画面は、一例であり、提示する情報が同じであるならば、どのようなデザインであってもよい。
【0285】
また、上述の実施の形態において、統計値として分散および平均値を用いる場合について説明したが、統計値は、分散および平均値に限るものではなく、最大値、最小値、最大値と最小値との差、最頻値、中央値、標準偏差等の他の統計値であってもよい。
【0286】
上述した実施の形態は、例えば、以下の特徴的な構成を有する。
【0287】
(1)
複数の領域を含むボリューム(例えば、仮想ボリューム313)を1以上のホスト(例えば、ホスト101)に提供するための処理を行うプロセッサ(例えば、プロセッサ211、プロセッサパッケージ213)を備える複数のノード(例えば、ノード100)と、上記プロセッサと接続され、上記ボリュームのデータを記憶する1以上の記憶デバイス(例えば、ドライブ214、ドライブボックス2201)とを備えるストレージシステム(例えば、ストレージシステム200、ストレージシステム2200)は、上記複数のノードの各々は、自ノードが提供するボリュームの負荷および上記ボリュームの領域を複数に分割した領域の負荷を監視し、監視している一のボリュームの負荷が閾値以上であると判定した第1のノードは、上記一のボリュームの領域を複数に分割した領域の負荷と負荷分散のポリシ(ボリューム単位分散ポリシ、スライス単位最大分散ポリシ、スライス単位最小分散ポリシ等)とに応じて、上記一のボリュームに含まれる一部の領域を上記第1のノードとは異なる第2のノードのボリュームに移動する(例えば、図15参照)。
【0288】
上記ボリュームの負荷は、例えば、自ノードのプロセッサの使用率、自ノードの記憶デバイスへのI/O量、自ノードの記憶デバイスへのI/Oレスポンス、自ノードのネットワークインターフェースへのI/O量、自ノードのネットワークインターフェースへのI/Oレスポンス、ボリュームに対するIOPS、および、ボリュームに対する転送量の少なくとも1つである。
【0289】
上記構成では、一のボリュームの負荷が高まったときに、当該ボリュームの一部の領域が他のノードのボリュームに移動されるので、例えば、ノードを追加した場合、一のボリュームについても性能をスケールアウトすることができるようになる。
【0290】
(2)
上記第1のノードは、上記一のボリュームの負荷が閾値未満であると判定した場合(例えば、図14参照)、上記第2のノードのボリュームから、上記一部の領域を上記一のボリュームに移動する(例えば、図16参照)。
【0291】
上記構成では、例えば、領域が移動されているボリュームの負荷が低い場合、当該ボリュームに当該領域が集約されるので、当該ボリュームのスループットを向上させ、当該ボリュームのレイテンシを低下させることができる。
【0292】
(3)
上記第1のノードは、上記第2のノードとして、上記一部の領域を移動した後のボリュームの負荷が閾値を超えないノードを選択する(例えば、ステップS1514~ステップS1516参照)。
【0293】
上記構成では、例えば、移動先ノードのボリュームが過負荷になってしまい、更に移動しなければならない事態を回避することができる。
【0294】
(4)
上記複数のノードの各々には、上記1以上の記憶デバイスの少なくとも1つが対応して設けられ(例えば、図2参照)、上記複数のノードの各々は、自ノードに割り当てられている領域のデータを、自ノードに設けられている記憶デバイスに記憶し(例えば、図12参照)、上記第1のノードは、上記一のボリュームの容量が提供可能な容量を超えると判定した場合(例えば、ステップS1401参照)、上記一部の領域を上記第2のノードのボリュームに移動する。
【0295】
上記構成によれば、例えば、各ノードが提供するボリュームは、ストレージシステムが備える記憶デバイス分、容量を利用できるようになる。
【0296】
(5)
上記複数のノードの各々は、自ノードが提供するボリュームに対するリードの負荷(例えば、リードIOPS、リード転送量、リードカウンタ等)と、上記ボリュームに対するライトの負荷(例えば、ライトIOPS、ライト転送量、ライトカウンタ等)とを監視し、上記第1のノードは、上記一のボリュームに対するリードの負荷が第1の閾値以上であると判定した場合、上記一部の領域を上記第2のノードのボリュームに移動し、上記一のボリュームに対するライトの負荷が上記第1の閾値とは異なる第2の閾値以上であると判定した場合、上記一部の領域を上記第2のノードのボリュームに移動する。
【0297】
ボリュームに対するリードとライトとでは、ノードにかかる負荷が異なるが、上記構成では、それぞれに対して監視を行い、別の閾値を設けることで、例えば、より適切にボリュームの負荷を判定することができる。
【0298】
(6)
上記第1のノードは、上記複数のノードに対して上記一のボリュームに含まれる領域を均等に割り振り(例えば、ステップS1506、ステップS1507)、上記第1のノードとは異なるノードに割り振った領域を、上記ノードのボリュームに移動する。
【0299】
上記構成では、例えば、移動する領域による負荷が均等になるようにボリュームの領域を移動することができる。
【0300】
(7)
上記第1のノードは、上記一のボリュームの負荷が上記閾値を下回るまで、上記一のボリュームに含まれる領域を1つずつ(例えば、ステップS1509、ステップS1510)、上記第1のノードとは異なるノードのボリュームに移動する。
【0301】
上記構成では、例えば、データのローカリティを極力保ち、最小限の負荷をボリュームから逃すことができる。
【0302】
(8)
上記一のボリュームが、複数のホストに提供されている場合、上記第1のノードは、上記複数のホストの各々がアクセスする領域をまとめてホストごとの移動対象とし(例えば、ステップS1506、ステップS1507)、ホストごとの移動対象の領域を、上記第1のノードとは異なるノードのボリュームに移動する。
【0303】
上記構成では、例えば、ホストごとにアクセスする領域が違う場合に、ホストがアクセスする領域をまとめて移動することができる。
【0304】
(9)
上記第1のノードは、自ノードが提供しているボリュームのうち上記一のボリュームとは異なる他のボリュームを上記第1のノードとは異なるノードに移動し、上記第2のノードのボリュームから、上記一部の領域を上記一のボリュームに移動する。
【0305】
上記構成では、例えば、第1のノードは、一のボリュームとは異なる他のボリュームをまるごと別のノードに移動することにより、移動した領域を集めることができる場合がある。
【0306】
(10)
上記一部の領域が移動された上記第2のノードのボリュームと、上記一部の領域にアクセスするホストとの間にパスが設定されていない場合、上記第2のノードおよび上記ホストは、上記パスを設定する(例えば、図18参照)。
【0307】
上記構成では、領域が移動された第2のノードのボリュームと当該領域にアクセスするホストとの間にパスが設定されていない場合、パスが設定されるので、例えば、当該領域に対するアクセスがあった際、第1のノードを介することなくデータをやり取りすることができるようになる。
【0308】
(11)
上記複数のノードの各々は、自ノードのボリュームの負荷が特定のホストに偏っていると判定した場合、上記特定のホストとのパスが最適属性であることを上記特定のホストに通知する(例えば、ステップS1904~ステップS1906、ステップS1908)。
【0309】
上記構成によれば、例えば、ボリュームの負荷が特定のホストに偏っている場合、特定のホストに優先的にI/Oが発行されるようになる。
【0310】
(12)
上記複数のノードの各々は、自ノードのボリュームの負荷が上記特定のホストに偏っていないと判定した場合、上記ボリュームに定義されている全てのパスが最適属性であることを上記パスが設定されている全てのホストに通知する(例えば、ステップS1904、ステップS1905、ステップS1907、ステップS1908)。
【0311】
上記構成によれば、ボリュームの負荷が特定のホストに偏っていない場合、当該ボリュームにアクセスする全てのホストに均等にI/Oが発行されるようになる。
【0312】
(13)
上記1以上の記憶デバイス(例えば、ドライブボックス2201)は、上記複数のノードに共通して設けられている。
【0313】
上記構成では、ノードのコンピュート部分と記憶部分とが分かれたことにより、例えば、プロセッサの使用率が余っているが、記憶デバイスの容量が不足している場合、コンピュート部分を増やすことなく、記憶部分を増やすことができる。
【0314】
(14)
上記第1のノードは、上記第2のノードに上記一部の領域を移動する際、上記一部の領域を管理するためのデータ(例えば、スライス管理テーブル820)を更新し、上記1以上の記憶デバイスに記憶される上記一部の領域のデータを移動しない(例えば、図23参照)。
【0315】
上記構成では、どのノードからも、均等にデータにアクセスできるようになっているので、例えば、ノード間でボリュームの負荷を分散するときは、ボリュームのオーナー権(排他権、メタデータ)を移すだけで、ボリュームの負荷を分散できる。
【0316】
(15)
上記複数のノードが提供するボリュームについて、当該ボリュームの領域の移動先ノードの数に応じたスループットと応答時間とを計算して出力する計算機(例えば、管理サーバ)を備える。
【0317】
上記構成によれば、例えば、ユーザは、領域の移動先ノードの数(例えば、最大分散度)を容易に決定することができる。
【0318】
上記複数のノードの各々は、ボリュームに含まれる領域単位で、ボリュームの負荷を監視する(例えば、図13B)。
【0319】
上記ストレージシステムは、1つのボリュームが分散可能な最大のノードの数をユーザが指定するためのGUIを出力する計算機を備える(図21A)。
【0320】
また上述した構成については、本発明の要旨を超えない範囲において、適宜に、変更したり、組み替えたり、組み合わせたり、省略したりしてもよい。
【0321】
「A、B、およびCのうちの少なくとも1つ」という形式におけるリストに含まれる項目は、(A)、(B)、(C)、(AおよびB)、(AおよびC)、(BおよびC)または(A、B、およびC)を意味することができると理解されたい。同様に、「A、B、またはCのうちの少なくとも1つ」の形式においてリストされた項目は、(A)、(B)、(C)、(AおよびB)、(AおよびC)、(BおよびC)または(A、B、およびC)を意味することができる。
【符号の説明】
【0322】
100……ノード、101……ホスト、200……ストレージシステム。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13A
図13B
図14
図15
図16
図17
図18
図19
図20
図21A
図21B
図22
図23