JP4643395B2 - ストレージシステム及びデータの移動方法 - Google Patents

ストレージシステム及びデータの移動方法 Download PDF

Info

Publication number
JP4643395B2
JP4643395B2 JP2005245386A JP2005245386A JP4643395B2 JP 4643395 B2 JP4643395 B2 JP 4643395B2 JP 2005245386 A JP2005245386 A JP 2005245386A JP 2005245386 A JP2005245386 A JP 2005245386A JP 4643395 B2 JP4643395 B2 JP 4643395B2
Authority
JP
Japan
Prior art keywords
volume
storage
migration
virtual
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005245386A
Other languages
English (en)
Other versions
JP2006099748A5 (ja
JP2006099748A (ja
Inventor
亨 高橋
達人 青島
伸夫 紅山
沢希 黒田
朋之 加地
哲也 丸山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2005245386A priority Critical patent/JP4643395B2/ja
Priority to US11/289,277 priority patent/US7395396B2/en
Publication of JP2006099748A publication Critical patent/JP2006099748A/ja
Publication of JP2006099748A5 publication Critical patent/JP2006099748A5/ja
Priority to US11/950,008 priority patent/US8230038B2/en
Application granted granted Critical
Publication of JP4643395B2 publication Critical patent/JP4643395B2/ja
Priority to US13/489,836 priority patent/US8799600B2/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、ストレージシステム及びデータ再配置制御装置に関する。
ストレージシステムは、例えば、ディスクアレイサブシステム等として呼ばれるストレージ装置を少なくとも一つ以上備えて構成される。このストレージ装置は、例えば、ハードディスクドライブや半導体メモリドライブ等のディスクドライブをアレイ状に配設し、RAID(Redundant Array of Independent Inexpensive Disks)に基づく記憶領域を提供する。ホストコンピュータ(以下、「ホスト」)は、ストレージ装置により提供される論理的な記憶領域にアクセスし、データの読み書きを行う。
ところで、例えば、企業や地方自治体、教育機関、金融機関、官公庁等の組織で管理されるデータ量は年々増加する一方であり、データ量の増加に伴ってストレージ装置の追加や置換が行われる。このようなデータ量の増大とストレージシステムの構成の複雑化に伴って、メール管理ソフトウェアやデータベース管理ソフトウェア等の各種アプリケーションプログラムのデータを、そのデータの価値に応じた適切な位置に配置し、ストレージシステムの利用効率を改善することが提案されている(特許文献1〜5)。
特開2003−345522号公報 特開2001−337790号公報 特開2001−67187号公報 特開2001−249853号公報 特開2004−70403号公報
上記の各特許文献では、ディスクの性能情報や利用情報に基づいて、一方のボリュームに記憶されているデータを他のボリュームにコピーさせ、データを再配置する技術が開示されている。
しかし、これらの文献に記載の技術では、各ボリューム単位に個別にデータを再配置する必要があり、ユーザが自由に定義した階層間でボリュームを移動させることができず、使い勝手が低い。また、前記各文献に記載の技術では、各ボリューム単位のデータ再配置を行うため、関連する一群のボリュームを一括して再配置させるのが難しい。さらに、前記各文献に記載の技術では、データの再配置のみに注目しており、再配置後の処理については何ら考慮されておらず、この点においても使い勝手が低い。
そこで、本発明の一つの目的は、複数のストレージ装置に分散されたデータをより簡単に再配置することができるストレージシステム及びデータ再配置制御装置を提供することにある。
本発明の一つの目的は、相互に関連する複数のボリュームにそれぞれ記憶されたデータを一括して再配置することにより、使い勝手を高めたストレージシステム及びデータ再配置制御装置を提供することにある。
本発明の一つの目的は、データ再配置後に必要な処理を自動的に実行させることにより、使い勝手を高めたストレージシステム及びデータ再配置制御装置を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。
上記課題を解決すべく、本発明のストレージシステムは、それぞれ少なくとも一つ以上のボリュームを有する複数のストレージ装置と、各ストレージ装置の有するボリュームを仮想的に一元管理する仮想化部と、各ボリュームの属性情報を管理するボリューム属性情報を記憶する記憶部と、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部と、を備える。
ここで、ポリシーは、ユーザが任意に設定可能であり、同一のボリュームが異なるストレージ階層に所属することもあり得る。また、ストレージ階層は、各ストレージ装置単位で、あるいは複数のストレージ装置にまたがって設定可能である。
例えば、各ポリシーをそれぞれ識別するためのポリシー識別情報と、該各ポリシー識別情報毎にそれぞれ対応付けられた階層構成条件とを含むストレージ階層管理情報を備え、各階層構成条件を満たすボリューム群によって、各ポリシーに応じたストレージ階層をそれぞれ生成することができる。そして、階層構成条件には、RAIDレベル、ドライブの種別、記憶容量、ストレージ装置の種別、使用状態のうち少なくともいずれか一つを含めることができる。
即ち、例えば、高性能なディスクから構成される高性能階層、低コストなディスクから構成される低コスト階層等のように、ストレージ階層は、ユーザの定義するポリシーに従って生成される。各ストレージ階層に属する一つまたは複数のボリュームは、同一のストレージ装置内に存在する場合もあるし、それぞれ異なるストレージ装置内に存在する場合もある。
各階層を定義づけるポリシーは、ユーザにより設定可能な階層構成条件によって決定される。例えば、高性能階層を定義する場合、ユーザは、高性能なディスクや高性能なストレージ装置を選択するための条件を階層構成条件として設定すればよい。また、例えば、低コスト階層を定義する場合、ユーザは、安価なディスクを選択するための条件を、階層構成条件として設定すればよい。これら各階層構成条件を満たすボリュームにより、そのストレージ階層が構成される。
あるストレージ階層に属するボリュームのデータを再配置する場合は、移動元のボリュームと移動先のストレージ階層とをそれぞれ指定すればよい。これにより、指定された移動元ボリュームのデータは、指定された移動先ストレージ階層に属するボリュームに移される。
再配置部は、複数のボリュームからなるグループ単位で、例えば、相互に関連した複数のボリュームからなるグループ単位で、指定された移動元ボリュームを再配置させることもできる。相互に関連した複数のボリュームとしては、例えば、同一のアプリケーションプログラムにより使用されるデータを記憶するボリューム群、同一のファイルシステムを構成するデータを記憶するボリューム群等を挙げることができる。なお、データ同士の関連性が乏しい場合であっても、グループ化することができる。
再配置部は、指定された移動元ボリュームを移動先のストレージ階層に移動させた後で、この移動されたボリュームに対して、移動先のストレージ階層に予め対応付けられている所定の処理を実行することもできる。所定の処理としては、例えば、リードオンリー等のようなアクセス属性の設定や、ボリュームの二重化等を挙げることができる。
再配置部は、指定された移動元ボリュームの記憶内容をコピー可能な移動先候補ボリュームを選択する移動先候補選択部と、この移動先候補選択部により選択された移動先候補ボリュームをユーザに提示する提示部とを備え、移動先候補選択部は、ボリューム属性情報を参照することにより、移動元ボリュームの有する各属性のうち予め設定された必須属性が一致するボリュームを移動先候補ボリュームとして選択することができる。
ボリューム属性情報は、静的属性と動的属性とを含んで構成可能であり、静的属性に含まれる所定の属性を前記必須属性として設定可能である。必須属性には、少なくともボリュームの記憶容量を含めることができる。
このように、再配置部は、移動元ボリュームの必須属性に一致するボリュームを、移動先候補ボリュームとして選択する。移動先候補選択部は、必須属性の一致する移動先候補ボリュームが複数存在する場合に、必須属性以外の他の属性の一致具合に基づいて、移動先候補ボリュームを一つだけ選択することができる。必須属性以外の属性としては、例えば、RAIDレベル、ディスク種別、ストレージ装置の機種等を挙げることができる。つまり、必須属性が一致するボリュームが複数抽出された場合は、これら各ボリュームのうち最も移動元ボリュームに近い構成を有するボリュームが移動先候補ボリュームとして選択される。
そして、再配置部は、移動先候補選択部により選択された移動先候補ボリュームを変更するための変更部を更に備えることができる。この変更部は、必須属性は一致するが選択されなかった移動先候補ボリュームの中から、移動先候補ボリュームを選択させることができる。
例えば、移動先候補ボリュームが特定のRAIDグループに集中したり、ランダムアクセスされるデータとシーケンシャルアクセスされるデータのように使用態様が異なるデータ群が同一のRAIDグループに存在しないように、変更部は、いったん選択された移動先候補ボリュームを変更させることができる。変更部は、ユーザからの指示に基づいて、移動先候補ボリュームの変更を行うことができる。
本発明の他の観点に従うデータ再配置制御装置は、複数のストレージ装置に分散して配置される複数のボリュームのデータ再配置を制御する。そして、各ボリュームは、仮想化部によって仮想的に一元管理されており、記憶部と制御部とを備えている。(A)記憶部には、(a1)少なくとも各ボリュームの識別情報、RAIDレベル、ドライブの種別、記憶容量、使用状態を含むボリュームの属性情報と、(a2)ユーザにより定義可能な複数のポリシーをそれぞれ識別するためのポリシー識別情報と、これら各ポリシー識別情報毎にそれぞれ対応付けられた階層構成条件とを含むストレージ階層管理情報と、をそれぞれ記憶することができる。(B)制御部は、ストレージ階層管理情報とボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部を備えることができる。
また、本発明に従う別のデータ再配置制御装置は、複数のストレージ装置がそれぞれ有するボリュームを一元管理し、前記各ボリュームに記憶されたデータの再配置を制御する装置であって、各ストレージ装置の有するボリュームを仮想的に一元管理する仮想化部と、各ボリュームの属性情報を管理するボリューム属性情報を記憶する記憶部と、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる再配置部と、を備える。
本発明は、例えば、以下のようなデータ再配置方法として捉えることもできる。即ち、複数のストレージ装置に分散された複数のボリュームに記憶されているデータを同一または異なるストレージ装置内のボリュームに再配置する方法であって、各ストレージ装置の有するボリュームは仮想的に一元管理されており、各ボリュームの属性情報をボリューム属性情報として管理し、複数のポリシーをそれぞれ予め設定し、これら複数のポリシーとボリューム属性情報とに基づいて複数のストレージ階層を生成し、移動元ボリューム及び移動先ストレージ階層をそれぞれ設定し、各ストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる。
本発明の手段、機能、ステップの少なくとも一部は、マイクロコンピュータにより読み込まれて実行されるコンピュータプログラムとして構成できる場合がある。このようなコンピュータプログラムは、例えば、ハードディスクや光ディスク等のような記憶媒体に固定して流通させることができる。または、インターネット等のような通信ネットワークを介して、コンピュータプログラムを供給することもできる。
以下、図面に基づき、本発明の実施の形態を説明する。図1は、本実施形態の全体概念を模式的に示す説明図である。以下に述べるように、本実施形態のストレージシステムは、複数のストレージ装置A〜Dを備えている。
各ストレージ装置A〜Dの有するボリュームは、仮想的に一元管理されており、ホスト(図2参照)は、複数のストレージ装置A〜Dを全体として一つの仮想的なストレージ装置として認識する。
各ストレージ装置A〜Dは、それぞれボリュームA1〜A4,B1〜B4,C1〜C4,D1〜D4を備えている。これら各ボリュームは、例えば、ハードディスクドライブや半導体メモリドライブあるいは光ディスクドライブ等の物理的な記憶ドライブにより提供される物理的な記憶領域上に設定される論理的な記憶領域である。
ここで、各ストレージ装置A〜Dは、それぞれ同一種類のドライブを備えることもできるし、あるいは、それぞれ異なる種類のドライブを混在させることもできる。従って、同一のストレージ装置内に位置するボリュームであっても、性能や価格等のボリューム属性がそれぞれ異なる場合がある。
ユーザは、ストレージシステムの有する各ボリュームを、複数のストレージ階層1〜3として任意にグループ化することができる。例えば、ある一つのストレージ階層1は、高信頼性階層として定義可能である。高信頼性階層は、例えば、ファイバチャネルディスク(FCディスク)等の高信頼性ドライブをRAID1で構成してなるボリューム群により構成される。また、他の一つのストレージ階層2は、例えば、低コスト階層として定義可能である。低コスト層は、例えば、SATA(Serial AT Attachment)ディスク等の安価なドライブをRAID5で構成してなるボリューム群により構成される。さらに、別の一つのストレージ階層3は、例えば、アーカイブ階層として定義可能である。アーカイブ階層は、例えば、所定容量未満の安価なディスク上に設定されるボリューム群から構成することができる。
図1に示すように、各ストレージ階層1〜3は、各ストレージ装置A〜Dを跨って仮想的に構成される。つまり、ユーザは、例えば、高信頼性階層、低コスト階層、高速応答性階層、アーカイブ階層等のように、ビジネス上の使用基準(ポリシー)に基づいて、ストレージシステムを構成する複数のボリュームを、所望のストレージ階層として自由に定義することができる。ポリシーは、ストレージシステムの構成とは独立して設定可能であるため、各ストレージ階層を構成する条件によっては、一部のボリュームが複数のストレージ階層に属する場合もあるし、あるいは、他の一部のボリュームがいずれのストレージ階層にも属さない場合も生じうる。
各ストレージ階層1〜3には、データ再配置対象となるボリューム群をそれぞれ設けることができる。一つの例として、ストレージ階層1に、二つのボリュームV1,V2からなるマイグレーショングループを示す。これら各ボリュームV1,V2は、例えば、同一のアプリケーションプログラムにより使用されるデータ群または同一のファイルシステムを構成するデータ群を記憶する等のように、互いに関連するボリュームである。
データの価値は、例えば時間の経過と共に低下していく。価値の高いデータは、高信頼性階層に置かれ、アプリケーションプログラムにより頻繁に利用される。時間の経過と共に価値が低下したデータは、他のストレージ階層に移動させるのが好ましい。高信頼性階層の記憶資源には限りがあるからである。
そこで、ユーザは、互いに関連する複数のボリュームV1,V2に記憶されているデータの再配置を検討し、例えば、ストレージ階層1からストレージ階層3(ここでは、アーカイブ階層)への移動を決定する。ユーザは、移動元ボリュームV1,V2の再配置を一括して指定し、ストレージ階層3への移動を指示する。
これにより、移動先のストレージ階層3では、マイグレーショングループを構成する各ボリュームV1,V2のデータをそれぞれ記憶可能なボリュームを選択し、これら選択されたボリュームにデータをコピーする。コピー完了後に、移動元ボリュームV1,V2のデータは削除することができ、空きボリュームとして再利用される。
ここで、各ストレージ階層1〜3には、各ストレージ階層1〜3のポリシーに応じて、それぞれ予め所定のアクションを対応づけることができる。ここで、アクションとは、そのストレージ階層内で実行される所定の情報処理、データ操作を意味する。例えば、高信頼性階層として定義されるストレージ階層1には、再配置されたデータの複製を生成する処理が予め対応づけられている。また、例えば、低コスト階層として定義されるストレージ階層2には、何のアクションも対応づけないようにすることもできる。さらに、例えば、アーカイブ階層として定義されるストレージ階層3には、再配置されたデータの複製を生成する処理と、リードオンリーのアクセス属性を設定する処理との複数の処理をアクションとして対応づけておくことができる。
マイグレーショングループを構成する各ボリュームV1,V2のデータが、ストレージ階層3に属するボリュームにコピーされると、ストレージ階層3に対応づけられている所定のアクションが自動的に実行される。ストレージ階層3に再配置されたデータは、その複製が生成されると共に、リードオンリーに設定され、改変が禁止される。
ここで、各ボリュームV1,V2のデータを再配置する場合、そのデータをコピー可能なボリュームが、移動先のストレージ階層内で選択される。各ボリュームは、それぞれ属性情報を有している。ボリューム属性情報としては、例えば、各ボリュームを識別するための識別情報、RAIDレベル、ディスク種別、記憶容量、使用中か否かを示す使用状態、所属するストレージ装置の機種等を挙げることができる。
これらのボリューム属性の全てが、移動元ボリューム(V1,V2)と、移動先候補のボリュームとの間で一致している必要はなく、一部の必須的な属性のみが一致していれば足りる。必須属性としては、例えば、記憶容量を挙げることができる。即ち、移動元ボリュームの記憶容量と同一またはそれ以上の記憶容量を有するボリュームを、移動先ボリュームとして選択することができる。
必須属性の一致するボリュームが必要数以上に検出された場合は、必須属性以外の他の属性の一致度を考慮し、より移動元ボリュームに近い属性を備えるボリュームを、移動先ボリュームとして選択することができる。一つの例として、ボリューム属性を必須属性とそれ以外の属性との二種類に大別したが、これに限らず、例えば、必須属性と、準必須属性と、その他の属性等のように、三種類以上の属性に分類し、各種類の属性に重みをつけて、ボリューム間の一致度を求める構成でもよい。一例として、ボリューム容量およびエミュレーションタイプを必須属性、それ以外の属性(RAIDレベル、ディスク種別等)をその他の属性(非必須属性)とすることができる。あるいは、エミュレーションタイプを必須属性、ボリューム容量を準必須属性、それ以外の属性を非必須属性とする構成でもよい。ボリューム容量を準必須属性とした場合、移動元ボリュームと移動先ボリュームの容量は必ずしも一致しなくともよいが、移動先ボリュームは移動元ボリュームと同一またはそれ以上の容量を持っていなければならない。また、ボリューム属性のうち使用状態はこれらの分類に含まれない例外的な属性であって、移動先ボリュームの使用状態は常に「空き」でなければならない。
図2は、ストレージシステムの全体構成を概略的に示すブロック図である。このストレージシステムは、それぞれ後述するように、例えば、複数のホスト10A,10B(特に区別しない場合は「ホスト10」)と、ボリューム仮想化装置20と、複数のストレージ装置30,40と、管理クライアント50と、ストレージ管理サーバ60とを含んで構成することができ、これらは、LAN(Local Area Network)等の通信ネットワークCN1を介して相互に接続されている。
各ホスト10A,10Bは、例えば、サーバ、パーソナルコンピュータ、ワークステーション、メインフレーム、携帯情報端末等のようなコンピュータシステムとして実現することができる。そして、例えば、複数のオープン系ホストと複数のメインフレーム系ホストとを、同一のストレージシステムに混在させることができる。
各ホスト10A,10Bは、例えば、アプリケーションプログラム(図中では「App」と略記)11A,11B(特に区別しない場合は「アプリケーションプログラム11」)と、HBA(Host Bus Adapter)12A,12B(特に区別しない場合は「HBA12」)とを備えることができる。これらアプリケーションプログラム11及びHBA12は、一つのホスト10について、それぞれ複数設けることができる。
アプリケーションプログラム11A,11Bとしては、例えば、電子メール管理プログラム、データベース管理プログラム、ファイルシステム等を挙げることができる。アプリケーションプログラム11A,11Bは、図外の複数のクライアント端末と別の通信ネットワークを介して接続されることができ、各クライアント端末からの要求に応じて情報処理サービスを提供することができる。
HBA12は、ストレージシステムとの間でデータの送受信を担当するもので、通信ネットワークCN2を介して、ボリューム仮想化装置20に接続されている。ここで、通信ネットワークCN2としては、例えば、LAN、SAN(Storage Area Network)、インターネット、専用回線等を挙げることができる。オープン系ホストの場合は、例えば、TCP/IP(Transmission Control Protocol/Internet Protocol)、FCP(Fibre Channel Protocol )、iSCSI(internet Small Computer System Interface)等のプロトコルに基づいて、データ転送が行われる。メインフレーム系ホストの場合は、例えば、FICON(Fibre Connection:登録商標)、ESCON(Enterprise System Connection:登録商標)、ACONARC(Advanced Connection Architecture:登録商標)、FIBARC(Fibre Connection Architecture:登録商標)等の通信プロトコルに従ってデータ転送が行われる。
このほか、各ホスト10A,10Bには、それぞれパス制御プログラム等の管理プログラム(不図示)を搭載してもよい。このような管理プログラムは、例えば、複数のHBA12間で負荷を分散させたり、障害発生時にはパスを切り替える等の処理を行う。
ボリューム仮想化装置(以下「仮想化装置」とも呼ぶ)20は、ストレージシステム内に存在するボリューム330,430等を仮想化し、一つの仮想的なストレージ装置に見せかけるものである。図3(a)に示すように、例えば、仮想化装置20は、各ホスト10に対して、識別情報LID001〜LID004で示す複数の論理ボリューム(LDEV)を提供する。これらの各論理ボリュームは、識別情報PID01〜PID04で示す別の論理ボリュームにそれぞれ対応づけられている。識別情報PIDを有する論理ボリュームが実際にデータを格納する実ボリュームであり、ホスト10が直接認識可能な論理ボリュームは、仮想ボリュームである。
仮想ボリュームと実ボリュームとのマッピングを制御することにより、ホスト10に対して透過的に、データの移動を行うことができる。例えば、図3(b)に示すように、実ボリューム(PID01)に記憶されているデータを、別の実ボリューム(PID02)に移動させる場合は、これら実ボリューム間でデータをコピーした後、実ボリュームと仮想ボリュームとのマッピングを設定し直せばよい。あるいは、仮想ボリューム(LID001)と仮想ボリューム(LID002)との間で、識別情報を交換することにより、ホスト10に意識されることなく、データ格納先のデバイスを変更することもできる。
このように、仮想化装置20は、ストレージシステム上に存在する多種多様な実ボリュームを仮想化して一元的に管理し、ホスト10に提供する。仮想化装置20は、後述のように、ストレージ装置内に設けることもできるし、あるいは、高機能なインテリジェント型スイッチに設けることもできる。さらに、後述のように、仮想化装置20とストレージ管理サーバ60とを同一のコンピュータ上に設けることもできる。
図2に戻る。各ストレージ装置30,40は、それぞれ論理ボリューム(実ボリューム)330,430を備えており、SAN等の通信ネットワークCN3を介して、仮想化装置20にそれぞれ接続されている。各ストレージ装置30,40は、ホスト10からの要求に応じて、ボリュームへのデータ読み書きを行う。ストレージ装置の構成例は、さらに後述する。
管理クライアント50は、例えば、パーソナルコンピュータやワークステーション、携帯情報端末等のコンピュータシステムとして構成されており、ウェブヴラウザ51を備えている。ユーザは、ウェブヴラウザ51を操作してストレージ管理サーバ60にログインすることにより、例えば、ストレージシステムに対して各種の指示を与えたり、ストレージシステム内の各種情報を取得することができる。
ストレージ管理サーバ60は、ストレージシステムのボリューム再配置等を管理するコンピュータシステムである。ストレージ管理サーバ60の構成例は、さらに後述するが、例えば、データ再配置管理部632と、ボリュームデータベース(図中「DB」)640とを備えることができる。
図4は、ストレージシステムのハードウェア構成を概略的に示すブロック図であり、仮想化装置20をストレージ装置として構成した場合を示す。
以下、本実施例では、仮想化装置20を、第3ストレージ装置20とも呼ぶ。第3ストレージ装置20は、それぞれ後述するように、例えば、複数のチャネルアダプタ(以下「CHA」)210と、複数のディスクアダプタ(以下「DKA」)220と、キャッシュメモリ230と、共有メモリ240と、接続制御部250,260と、記憶部270と、SVP280とを備えて構成することができる。
CHA210は、ホスト10や外部の第1ストレージ装置30及び第2ストレージ装置40との間のデータ授受を制御するもので、例えば、CPUやメモリ、入出力回路等を備えたマイクロコンピュータシステムとして構成可能である。各CHA210は、それぞれ複数の通信ポート211を備えることができ、各通信ポート211毎にそれぞれ個別にデータ授受を行うことができる。各CHA210は、それぞれ一種類の通信プロトコルに対応しており、ホスト10の種類に応じて用意される。但し、各CHA210がそれぞれ複数種類の通信プロトコルに対応する構成としてもよい。
DKA220は、記憶部270との間のデータ授受を制御する。DKA220は、CHA210と同様に、例えば、CPUやメモリ等を備えたマイクロコンピュータシステムとして構成することができる。各DKA220は、例えば、ホスト10から指定された論理ブロックアドレス(LBA)を物理ディスクのアドレスに変換等することにより、各ディスクドライブ271にアクセスし、データの読出しまたはデータの書込みを行う。なお、CHA210の機能とDKA220の機能とを一つまたは複数のコントローラ内に集約する構成としてもよい。
キャッシュメモリ230は、ホスト10から書き込まれたライトデータや、ホスト10に読み出されたリードデータを記憶するものである。キャッシュメモリ230は、例えば、揮発または不揮発のメモリから構成可能である。キャッシュメモリ230が揮発性メモリを含んで構成される場合、図示せぬバッテリ電源等によりメモリバックアップを行うことが好ましい。なお、図示は省略するが、キャッシュメモリ230は、リードキャッシュ領域とライトキャッシュ領域との2つの領域から構成することができ、ライトキャッシュ領域に格納されたデータは、多重記憶することができる。つまり、同一のデータがディスクドライブ271にも存在するリードデータは、仮に失われたとしても再びディスクドライブ271から読み出せば足りるので、多重化の必要はない。これに対し、ライトデータは、ストレージ装置20内においては、キャッシュメモリ230にのみ存在するため、多重化記憶させるのが信頼性の点で好ましい。もっとも、キャッシュデータを多重化して記憶させるか否かは、仕様による。
共有メモリ(あるいは制御メモリとも呼ばれる)240は、例えば、不揮発メモリから構成可能であるが、揮発メモリから構成してもよい。共有メモリ240には、例えば、マッピングテーブルT1のように、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数のメモリ240により多重管理することができる。マッピングテーブルT1の構成例については、後述する。
ここで、共有メモリ240及びキャッシュメモリ230は、それぞれ別々のメモリパッケージとして構成することもできるし、同一のメモリパッケージ内にキャッシュメモリ230及び共有メモリ240を設けてもよい。また、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。つまり、共有メモリとキャッシュメモリとは、同一のメモリとして構成することもできる。
第1の接続制御部(スイッチ部)250は、各CHA210と、各DKA220と、キャッシュメモリ230と、共有メモリ240とをそれぞれ相互に接続するものである。これにより、全てのCHA210,DKA220は、キャッシュメモリ230及び共有メモリ240にそれぞれ個別にアクセス可能である。接続制御部250は、例えば、超高速クロスバスイッチ等として構成することができる。第2の接続制御部260は、各DKA220と記憶部270とをそれぞれ接続するためのものである。
記憶部270は、多数のディスクドライブ271を備えて構成される。記憶部270は、各CHA210及び各DKA220等のコントローラ部分と共に同一の筐体内に設けることもできるし、コントローラ部分とは別の筐体内に設けることもできる。
記憶部270には、複数のディスクドライブ271を設けることができる。ディスクドライブ271としては、例えば、FCディスク(ファイバチャネルディスク)、SCSI(Small Computer System Interface)ディスク、SATA(Serial AT Attachment)ディスク等を用いることができる。また、記憶部270は、同一種類のディスクドライブから構成される必要はなく、複数種類のディスクドライブを混在させることもできる。
ここで、一般的には、FCディスク、SCSIディスク、SATAディスクの順番で、性能が低下する。例えば、アクセス頻度の多いデータ(価値の高いデータ等)は、高性能なFCディスクに記憶し、アクセス頻度の低いデータ(価値の低いデータ等)は、低性能なSATAディスクに記憶させる等のように、データの利用態様に応じて、ディスクドライブの種類を使い分けることができる。各ディスクドライブ271の提供する物理的な記憶領域上には、複数の論理的な記憶領域を階層化して設けることができる。記憶領域の構成については、さらに後述する。
SVP(Service Processor)280は、LAN等の内部ネットワークCN11を介して、各CHA210及び各DKA220とそれぞれ接続されている。図中では、SVP280とCHA210とだけを接続しているが、SVP280は、各DKA220にもそれぞれ接続することができる。SVP280は、ストレージ装置20内の各種状態を収集し、そのままで又は加工して、ストレージ管理サーバ60に提供する。
ボリューム仮想化を実現する第3ストレージ装置20は、ホスト10からのデータ入出力要求を処理する窓口であり、第1ストレージ装置30及び第2ストレージ装置40と通信ネットワークCN3を介して、それぞれ接続されている。なお、図中では、ストレージ装置20に二つのストレージ装置30,40を接続する状態を示すが、これに限らず、ストレージ装置20に一つのストレージ装置を接続してもよく、あるいは、ストレージ装置20に三つ以上のストレージ装置を接続してもよい。
第1ストレージ装置30は、例えば、コントローラ310と、第3ストレージ装置20と接続するための通信ポート311と、ディスクドライブ320とを備えて構成することができる。コントローラ310は、上述したCHA210及びDKA220の機能を実現するもので、第3ストレージ装置20及びディスクドライブ320とのデータ授受をそれぞれ制御する。
第1ストレージ装置30は、第3ストレージ装置20と同一または実質的に同一の構成を備えてもよいし、第3ストレージ装置20と異なる構成でもよい。第1ストレージ装置30は、第3ストレージ装置20との間で所定の通信プロトコル(例えば、FCやiSCSI等)に従ったデータ通信を行うことができ、ディスクドライブ320等の記憶ドライブ(記憶用デバイス)を備えていればよい。後述のように、第1ストレージ装置30の有する論理ボリュームは、第3ストレージ装置20の所定階層にマッピングされており、第3ストレージ装置20の内部ボリュームであるかのように使用される。
なお、本実施例では、物理的な記憶ドライブとして、ハードディスクを例示するが、本発明はこれに限定されない。記憶ドライブとしては、ハードディスク以外に、例えば、半導体メモリドライブ、磁気テープドライブ、光ディスクドライブ、光磁気ディスクドライブ等を用いることができる場合もある。
第2ストレージ装置40は、第1ストレージ装置30と同様に、例えば、コントローラ410と、ディスクドライブ420と、ポート411とを備えて構成可能である。第2ストレージ装置40は、第1ストレージ装置30と同一の構成を備えてもよいし、異なる構成であってもよい。
図5は、ストレージシステムの論理的な記憶構造に着目した構成説明図である。先に第3ストレージ装置20の構成から先に説明する。第3ストレージ装置20の記憶構造は、例えば、物理的記憶階層と論理的記憶階層とに大別することができる。物理的記憶階層は、物理的なディスクであるPDEV(Physical Device)271により構成される。PDEVは、ディスクドライブに該当する。
論理的記憶階層は、複数の(例えば2種類の)階層から構成することができる。一つの論理的階層は、VDEV(Virtual Device)272から構成可能である。他の一つの論理的階層は、LDEV(Logical Device)273から構成することができる。
VDEV272は、例えば、4個1組(3D+1P)、8個1組(7D+1P)等のような所定数のPDEV271をグループ化して構成することができる。グループに属する各PDEV271がそれぞれ提供する記憶領域が集合して一つのRAID記憶領域が形成される。このRAID記憶領域がVDEV272となる。
ここで、全てのVDEV272がPDEV271上に直接設けられるわけではなく、一部のVDEV272は、仮想的な中間デバイスとして生成可能である。このような仮想的なVDEV272は、外部のストレージ装置30,40が有するLU(Logical Unit)をマッピングするための受け皿となる。
LDEV273は、VDEV272上に、少なくとも一つ以上設けることができる。LDEV273は、VDEV272を固定長で分割することにより構成することができる。ホスト10がオープン系ホストの場合、LDEV273がLU274にマッピングされることにより、ホスト10は、LDEV273を一つの物理的なディスクボリュームとして認識する。オープン系のホスト10は、LUN(Logical Unit Number )や論理ブロックアドレスを指定することにより、所望のLDEV273にアクセスする。
LU274は、SCSIの論理ユニットとして認識可能なデバイスである。各LU274は、ポート211Aを介してホスト10に接続される。各LU274には、少なくとも一つ以上のLDEV273をそれぞれ関連付けることができる。一つのLU274に複数のLDEV273を関連付けることにより、LUサイズを仮想的に拡張することもできる。
CMD(Command Device)275は、ホスト10上で稼働するプログラムとストレージ装置のコントローラ(CHA210,DKA220)との間で、コマンドやステータスを受け渡すために使用される専用のLUである。ホスト10からのコマンドは、CMD275に書き込まれる。ストレージ装置のコントローラは、CMD275に書き込まれたコマンドに応じた処理を実行し、その実行結果をステータスとしてCMD275に書き込む。ホスト10は、CMD275に書き込まれたステータスを読出して確認し、次に実行すべき処理内容をCMD275に書き込む。このようにして、ホスト10は、CMD275を介して、ストレージ装置に各種の指示を与えることができる。
第3ストレージ装置20の外部接続用のイニシエータポート(External Port)211Bには、通信ネットワークCN3を介して、第1ストレージ装置30,第2ストレージ装置40がそれぞれ接続されている。第1ストレージ装置30は、複数のPDEV320と、PDEV320の提供する記憶領域上に設定されたLDEV330とを備えている。そして、各LDEV330は、LU340に関連付けられている。同様に、第2ストレージ装置40は、複数のPDEV420と、LDEV430とを備え、LDEV430はLU440に関連付けられている。
第1ストレージ装置30の有するLDEV330は、LU340を介して、第3ストレージ装置20のVDEV272(「VDEV2」)にマッピングされている。第2ストレージ装置40の有するLDEV430は、LU440を介して、第3ストレージ装置のVDEV272(「VDEV3」)にマッピングされている。
このように、第1,第2ストレージ装置30,40の有する実ボリューム(LDEV)を、第3ストレージ装置20の所定の論理階層にマッピングすることにより、第3ストレージ装置20は、外部に存在するボリューム330,430をあたかも自己の有するボリュームであるかのようにホスト10に対して見せかけることができる。なお、第3ストレージ装置20の外部に存在するボリュームを第3ストレージ装置30に取り込む方法としては、上記の例に限らない。
次に、図6は、ストレージ管理サーバ60のハードウェア構成の概略を示すブロック図である。ストレージ管理サーバ60は、例えば、通信部610と、制御部620と、メモリ630と、ボリュームデータベース640とを備えて構成可能である。
通信部610は、通信ネットワークCN1を介してデータ通信を行う。制御部620は、ストレージ管理サーバ60の全体制御を行う。メモリ630には、例えば、ウェブサーバプログラム631と、データ再配置管理プログラム632と、データベース管理システム633とが格納されている。
ボリュームデータベース640には、例えば、ボリューム属性管理テーブルT2と、ストレージ階層管理テーブルT3と、対応ホスト管理テーブルT4と、マイグレーショングループ管理テーブルT5と、アクション管理テーブルT6とが記憶されている。これら各テーブルの構成例は、さらに後述する。
ウェブサーバプログラム631は、制御部620に読み込まれて実行されることにより、ストレージ管理サーバ60上にウェブサーバ機能を実現させる。データ再配置管理プログラム632は、制御部620に読み込まれることにより、ストレージ管理サーバ60上にデータ再配置管理部を実現する。データベース管理システム633は、ボリュームデータベース640を管理する。なお、これらのウェブサーバ機能、データ再配置管理機能、データベース管理機能は、それぞれ並行して実行することができる。
図7は、マッピングテーブルT1の構成を示す説明図である。マッピングテーブルT1は、第1ストレージ装置30,第2ストレージ装置40がそれぞれ有するボリュームを、第3ストレージ装置20にマッピングさせるために使用される。マッピングテーブルT1は、第3ストレージ装置20の共有メモリ240に記憶させることができる。
マッピングテーブルT1は、例えば、LUNと、LDEV番号、LDEVの最大スロット数(容量)と、VDEV番号と、VDEVの最大スロット数(容量)と、デバイス種別と、パス情報とを対応づけることにより、構成することができる。パス情報は、第3ストレージ装置20内部の記憶領域(PDEV271)へのパスを示す内部パス情報と、第1ストレージ装置30または第2ストレージ装置40の有するボリュームへのパスを示す外部パス情報とに大別することができる。外部パス情報には、例えば、WWN(World Wide Name)とLUNとを含めることができる。
図8は、ボリューム属性管理テーブルT2の一例を示す。ボリューム属性管理テーブルT2は、ストレージシステムに分散する各ボリュームの属性情報を管理するためのものである。
ボリューム属性管理テーブルT2は、例えば、各仮想ボリューム毎に、その仮想ボリュームを特定する論理IDと、その仮想ボリュームに対応づけられる実ボリュームの物理IDと、RAIDレベルと、エミュレーションタイプと、ディスク種別と、記憶容量と、使用状態と、ストレージ装置の機種とを対応づけることにより、構成することができる。
ここで、RAIDレベルとは、例えば、RAID0,RAID1,RAID5等のRAID構成を示す情報である。エミュレーションタイプとは、そのボリュームの構造を示す情報であり、例えば、オープン系ホストに提供されるボリュームと、メインフレーム系ホストに提供されるボリュームとでは、エミュレーションタイプが相違する。使用状態とは、そのボリュームが使用されているか否かを示す情報である。機種とは、そのボリュームの存在するストレージ装置の機種を示す情報である。
また、論理IDとは、前記ボリューム仮想化装置20がホスト10に対して提供する論理ボリュームのIDであり、物理IDとは、各論理ボリュームに対応する実ボリュームの所在を示すIDである。物理IDは、実ボリュームを格納しているストレージ装置の装置番号と、該装置内におけるボリューム番号から構成される。
図9は、ストレージ階層管理テーブルT3の一例を示す。ストレージ階層管理テーブルT3は、例えば、ストレージ階層番号と、ストレージ階層名称と、そのストレージ階層を定義づける条件式と、自動的に実行させるアクションとを対応づけることにより、構成することができる。アクションは、必須の設定項目ではなく、アクションを対応づけずにストレージ階層を定義することもできる。
ストレージ階層名称には、ユーザ(システム管理者等)が所望の名称を設定することができる。例えば、ストレージ階層名称として、高信頼階層、低コスト階層、高速応答階層、アーカイブ階層等の名称を用いることもできる。条件式には、そのストレージ階層に所属すべきボリュームを抽出するための検索条件が設定される。検索条件は、そのストレージ階層のポリシーに応じて、ユーザにより設定される。
検索条件により、例えば、所定種類のディスクを所定のRAIDレベルで構成したボリュームを検出したり(「RAIDレベル=RAID1 and ディスク種別=FC」)、所定のストレージ装置に存在するボリュームを検出することができる(「機種=SS1」)。例えば、高信頼階層(#1)では、高い信頼性を有するFCディスクによりRAID1で冗長化したボリュームが選択される。これにより、高信頼階層を、信頼性の高いボリュームのみから構成することができる。低コスト階層(#2)では、安価なSATAディスクをRAID5で冗長化したボリュームが選択される。これにより、低コスト階層を、比較的小容量の安価なボリュームのみから構成可能である。高速応答階層(#3)では、高速応答が可能な機種に存在するディスクをストライピング(RAID0)したボリュームが選択される。これにより、高速応答階層を、I/O処理が速く、パリティ演算等の処理を必要としないボリュームのみから構成できる。アーカイブ階層(#4)では、安価なSATAディスクから構成され、かつ、所定容量未満の容量を有するボリュームが選択される。これにより、アーカイブ階層を、低コストのボリュームから構成することができる。
図9に示すように、ストレージ階層管理テーブルT3に設定された条件式に基づいて、ボリューム属性管理テーブルT2を検索することにより、各ストレージ階層に所属すべきボリューム群が検出される。ここで、ストレージ階層とボリューム群とは、明示的に直接関連付けられるのではなく、条件式を介して間接的に関連付けられている点に留意すべきである。これにより、ストレージシステムの物理構成が種々変化した場合でも、容易に対応することができる。
図10は、対応ホスト管理テーブルT4の一例を示す説明図である。対応ホスト管理テーブルT4は、例えば、仮想ボリュームを識別する論理IDと、その仮想ボリュームにアクセスするホストを特定するための情報(例えば、ドメイン名)と、その仮想ボリュームを利用するアプリケーションプログラムの名称とを対応づけることにより、構成することができる。
図11は、マイグレーショングループ管理テーブルT5の一例を示す説明図である。マイグレーショングループとは、データを再配置する場合の単位であり、本実施例では、相互に関連する複数のボリュームからマイグレーショングループを構成し、グループ単位で一括してデータを再配置できるようにしている。図10に示した対応ホスト管理テーブルT4を検索することにより、相互に関連するボリューム群を抽出することができる。
マイグレーショングループ管理テーブルT5は、例えば、グループ番号と、グループ名称と、そのグループに属するボリュームを特定する論理IDと、そのグループが現在所属するストレージ階層の名称とを対応づけることができる。マイグレーショングループの名称は、ユーザが自由に設定することができる。このように、各マイグレーショングループは、例えば、同一のアプリケーションプログラムにより使用されるデータ群を記憶するボリューム、または、同一のファイルシステムを構成するデータ群を記憶するボリュームを、グループ化することによって構成可能である。なお、例えば、マイグレーショングループを新たに設定した直後等のように、データ再配置を行っていない状態では、そのグループの属するストレージ階層名称は設定されない場合がある。
図12は、アクション管理テーブルT6の一例を示す説明図である。アクション管理テーブルT6は、ストレージ階層に予め設定されている所定の情報処理、データ操作の具体的内容を定義するものである。アクション管理テーブルT6は、例えば、アクションを識別するためのIDと、そのアクションの名称と、そのアクションで実行されるべきスクリプト(プログラム)とを対応づけることにより、構成することができる。従って、ストレージ階層管理テーブルT3にアクションIDが予め設定されている場合、そのアクションIDを検索キーとしてアクション管理テーブルT6を検索することにより、必要なアクションを実行することができる。
例えば、高信頼階層では、アクションID「A1」が設定されている。アクションID「A1」は、ミラーリングを行うもので、ボリュームの複製を生成するスクリプトが関連付けられている。従って、あるマイグレーショングループが高信頼階層に再配置された場合、ボリューム群の複製が生成される。また、アーカイブ階層では、アクションID「A3」が設定されている。アクションID「A3」は、データのアーカイブ処理を行うもので、アーカイブ処理に必要な複数のスクリプトが関連付けられている。一つのスクリプトは、アクセス属性をリードオンリーに設定するものであり、他の一つのスクリプトは、ボリューム群の複製を行うものである。なお、アクション管理テーブルT6中のID「A2」は、一度だけの書込みを許可するもので、いわゆるWORM(Write Once Read Meny)として知られている。このアクションIDには、アクセス属性をリードオンリーに設定するスクリプトが関連付けられている。
図13は、データ再配置の全体動作を簡略化して示す説明図である。データ再配置を行う場合、ユーザは、管理クライアント50を介してストレージ管理サーバ60にログインし、再配置させるマイグレーショングループ及び配置先のストレージ階層をそれぞれ指定する(S1)。
ストレージ管理サーバ60は、指定されたマイグレーショングループを構成する各ボリュームのそれぞれについて、移動先候補のボリュームを選択する(S2)。詳細はさらに後述するが、移動先候補ボリュームを選択する処理では、移動先として指定されたストレージ階層に所属する全ボリュームのうち、移動元ボリュームのデータをコピー可能なボリュームが一つ選択される。
ストレージ管理サーバ60による移動先候補ボリュームの選択結果は、例えば、ボリューム対応表T7のような形態で、ユーザに提示される(S3)。ボリューム対応表T7は、例えば、移動元ボリュームの論理IDと、移動先ボリュームの論理IDとを対応づけることにより、構成することができる。
ユーザは、ストレージ管理サーバ60から提示された再配置案(ボリューム対応表T7)を、ウェブヴラウザ51により確認する。ストレージ管理サーバ60からの提案をそのまま承認する場合は、所定のタイミングを見計らって再配置が実行される(S5)。ストレージ管理サーバ60からの提案を修正する場合は、ウェブヴラウザ51を介して、移動先ボリュームの論理IDを変更する(S4)。
図14は、移動先候補ボリュームを選択する処理を示すフローチャートである。この処理は、例えば、ユーザが、再配置対象のマイグレーショングループ及び再配置先(移動先)のストレージ階層を明示的に指定することにより、開始される。
ストレージ管理サーバ60(データ再配置管理プログラム632)は、移動元ボリュームの全てについて、移動先候補ボリュームを選択済か否かを判定する(S11)。ここでは、「NO」と判定されて、S12に移る。そして、ストレージ管理サーバ60は、ボリューム属性管理テーブルT2を参照することにより、移動先として指定されたストレージ階層に所属するボリューム群から、使用状態が「空き」であり、かつ、移動元ボリュームと必須属性の一致するボリュームを抽出する(S12)。
必須属性とは、ボリューム間のデータコピーを行うために必要な属性を意味し、一つでも必須属性が一致しない場合は、データコピーが不能である。本実施例では、必須属性として、例えば、記憶容量とエミュレーションタイプとを挙げることができる。即ち、本実施例では、移動元ボリュームと移動先ボリュームとは、最低限その記憶容量及びエミュレーションタイプが一致していなければならない。
次に、ストレージ管理サーバ60は、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定する(S13)。必須属性の一致する空きボリュームが一つだけ検出された場合は、そのボリュームを移動先候補ボリュームとして選択する(S14)。必須属性の一致する空きボリュームが全く発見されなかった場合、データ再配置を行うことはできないので、エラー処理を行い、ユーザに通知する(S16)。
必須属性の一致する空きボリュームが複数検出された場合、ストレージ管理サーバ60は、必須属性以外の他の属性(非必須属性)の一致度が最も高いボリュームを、移動先候補ボリュームとして選択する(S15)。例えば、RAIDレベル、ディスク種別、ストレージ装置の機種等のような他の属性項目がより多く一致するボリュームを、移動先候補ボリュームとして選択する。なお、非必須属性の各項目間に優劣を付けて、一致度を算出するようにしてもよい。また、非必須属性の一致度が等しいボリュームが複数存在する場合は、例えば、論理IDの小さいボリュームを選択することができる。
上記の処理は、移動対象のマイグレーショングループを構成する全てのボリュームについて、それぞれ実行される。そして、全ての移動元ボリュームについて、それぞれに対応する移動先候補ボリュームが選択された場合(S11:YES)、ストレージ管理サーバ60は、ボリューム対応表T7を生成してユーザに提示する(S17)。
ユーザは、ストレージ管理サーバ60から提示されたボリューム対応表T7を確認し、承認するか修正するかを決定する。ユーザの承認が得られた場合(S18:YES)、本処理は終了する。ユーザが変更を希望する場合(S18:NO)、ユーザは、ウェブヴラウザ51を介して、移動先候補ボリュームを手動で再設定する(S19)。そして、ユーザにより修正が完了すると、本処理は終了する。
図15は、再配置実行処理の概要を示すフローチャートである。ストレージ管理サーバ60(データ再配置管理プログラム632)は、ストレージ階層管理テーブルT3を参照することにより、移動先として指定されたストレージ階層に対応づけられているアクションを検出する(S21)。
次に、ストレージ管理サーバ60は、全ての移動元ボリュームについて再配置が完了したか否かを判定する(S22)。最初の処理では「NO」と判定されて次のステップS23に移る。そして、移動元ボリュームに記憶されているデータを、その移動元ボリュームに対応する移動先ボリュームにコピーし(S23)、移動元ボリュームから移動先ボリュームにアクセスパスを切り換える(S24)。このパスの切り替えは、図3(b)で示したパスの切り替え同様の処理を行うものである。これにより、ホスト10は、データ再配置を意識することなく、そのままの設定で所望のデータにアクセスすることができる。
ストレージ管理サーバ60は、移動元ボリュームから移動先ボリュームへのデータ移行が正常に完了したか否かを判定し(S25)、データ移行が正常に完了しなかった場合(S25:NO)、エラー処理を行って本処理を終了する。
データ移行が正常に終了した場合(S25:YES)、移動先のストレージ階層に対応づけられているアクションが存在するか否かをチェックする(S27)。移動先のストレージ階層にアクションが設定されている場合(S27:YES)、ストレージ管理サーバ60は、アクション管理テーブルT6を参照し、所定のスクリプトを実行し(S28)、S22に戻る。移動先のストレージ階層にアクションが設定されていない場合(S27:NO)、何もせずにS22に戻る。
このように、移動対象のマイグレーショングループに属する全てのボリュームについて、それぞれの記憶するデータが移動先ボリュームにコピーされ、アクセスパスが切り換えられる。そして、全ての移動元ボリュームについてデータ移行が完了すると(S22:YES)、本処理は終了する。
図16は、ボリューム対応表T7の具体例を示す説明図である。ストレージ管理サーバ60による移動先候補ボリュームの選定結果は、例えば、図16に示すように、移動元ボリューム及び移動先ボリュームを上下2段に配置することにより、表示可能である。移動元ボリューム及び移動先ボリュームのそれぞれについて、例えば、その論理ID、その所属するRAIDグループ番号、RAIDレベル、エミュレーションタイプ、記憶容量等の属性を併せて表示することができる。
ユーザは、図16の画面を確認することにより、データ再配置を実行させるか否かを判断することができる。移動先ボリュームを個別に変更する場合、ユーザは、モディファイボタンB1を操作する。このボタンB1を操作すると、図17に示す個別修正画面に遷移する。
図17に示す修正画面では、その上部に、移動元ボリューム(ソースボリューム)の論理IDと、移動元ボリュームのエミュレーションタイプ及び記憶容量とを表示させることができる。
画面の中央部には、現在選択されている移動先ボリュームの論理IDやRAIDグループ、RAIDレベル、物理ID、所属するストレージ装置の番号、実ボリュームの物理ID等を表示させることができる。
画面の下部には、指定された階層の中で移動元ボリュームと必須属性が一致する全ての候補ボリュームの一覧を表示させることができる。ユーザは、画面下部のボリューム一覧に表示されているボリュームの中からいずれか一つのボリュームを選択することができる。例えば、ストレージ管理サーバ60による初期選択結果が、特定のRAIDグループに属するボリュームに集中していたり、あるいは、シーケンシャルアクセスされるデータとランダムアクセスされるデータとが同一のRAIDグループに配置されていたりするような場合、そのRAIDグループの応答性が低下する。従って、ユーザは、特定のRAIDグループにデータが集中しないように、移動先候補ボリュームを個別に修正することができる。
本実施例は、上述のように構成されるため、以下の効果を奏する。本実施例では、予め設定された複数のポリシーとボリューム属性情報とに基づいてそれぞれ生成される複数のストレージ階層間で、指定された移動元ボリュームを指定されたストレージ階層に再配置させる構成を採用した。従って、ユーザは、希望のポリシーで自由にストレージ階層を定義し、ストレージ階層間でボリュームを再配置させることができ、ストレージシステムの使い勝手が向上する。特に、複数のストレージ装置が混在する複雑なストレージシステムにおいて、ユーザは、各ボリュームの特性等を詳しく考慮することなく、自己の設定したポリシーに従い、直感的な操作でデータを再配置することができる。
本実施例では、複数のボリュームからなるグループ単位で、データを再配置することができる。従って、上記のストレージ階層間でデータ再配置が可能な構成と相俟って、より一層ユーザの使い勝手を向上させることができる。
本実施例では、移動先のストレージ階層に予め所定のアクションを対応づけることができ、データ再配置の完了後に所定のアクションを実行させることができる。これにより、データ再配置に伴う付加的なサービスを自動的に実行することができ、ユーザの操作忘れ等を防止して、使い勝手を改善することができる。
本実施例では、必須属性の一致を前提条件とし、必須属性以外の属性の一致度が高いボリュームを移動先候補ボリュームとして選択する。従って、データ再配置に適切なボリュームを選択することができる。
図18に基づいて本発明の第2実施例を説明する。本実施例を含む以下の実施例は、第1実施例の変形例に相当する。本実施例の特徴は、第1実施例で述べたボリューム仮想化装置20とストレージ管理サーバ60とを、一つのボリューム仮想化装置70に集約した点にある。
本実施例のボリューム仮想化装置70は、例えば、ボリューム仮想化部71と、データ再配置部72と、ボリュームデータベース73とを備える。ボリューム仮想化部71は、第1実施例のボリューム仮想化装置20と同様の機能を実現する。データ再配置部72は、第1実施例におけるストレージ管理サーバ60のデータ再配置管理プログラム632と同様の機能を実現する。ボリュームデータベース73は、第1実施例のボリュームデータベース640と同様の各種テーブルを記憶する。
図19に基づいて、本発明の第3実施例を説明する。本実施例の特徴は、ボリューム属性管理テーブルT2に、動的な属性を追加し、動的な属性を考慮してストレージ階層を定義可能とした点にある。
本実施例のボリューム属性管理テーブルT2には、その右端に示すように、データ入出力の応答時間(I/O応答時間)も管理されている。このI/O応答時間は、例えば、定期的または不定期に、ストレージ管理サーバ60が各ストレージ装置20,30,40から収集して更新することができる。なお、図19中では、紙面の都合上、ストレージ装置の機種に代えてI/O応答時間を表示しているが、ストレージ装置の機種もボリューム属性の一つとして管理することができる。ここで、I/O応答時間は、テストI/Oを発行し、このI/Oの発行から応答までの時間を計測したものである。またこのI/O応答時間は、図9に示す条件式に含めることができる。
このように、本実施例では、RAIDレベルや記憶容量等の静的な属性に加えて、動的な属性も併せて管理するため、静的な属性と動的な属性の両方を考慮して、ストレージ階層を定義することができる。例えば、より高速な応答を求めるストレージ階層では、高速なディスク(FCディスク)上に設定され、最新のI/O応答時間が最も短いストレージ装置に存在するボリュームから構成することができる。
図20,図21に基づいて、本発明の第4実施例を説明する。本実施例の特徴は、ストレージシステムの構成変更(ストレージ装置の廃棄)に応じて、その構成変更に係るストレージ装置に記憶されているデータを、空いている適切なボリュームに自動的に再配置させる点にある。
図20は、本実施例に係るストレージシステムの全体概要を示す説明図である。このストレージシステムでは、第1実施例の構成に加えて、第4ストレージ装置80が新たに追加されている。第4ストレージ装置80は、例えば、ストレージ装置30,40のように構成することができる。なお、第4ストレージ装置80は、説明の便宜上追加されるもので、本発明の構成に必須の要素ではない。本発明は、複数のストレージ装置を備えていれば足りる。
本実施例では、一例として、第1ストレージ装置30を廃棄する場合を説明する。例えば、第1ストレージ装置30の耐用期限が切れたような場合に、第1ストレージ装置30は、廃棄が予定される。廃棄予定のストレージ装置30に記憶されているデータ群を、他のストレージ装置40,80(あるいは、第3ストレージ装置としてのボリューム仮想化装置20。以下同様)に移行させる場合を、図21の説明図に基づいて説明する。
図21に示すように、ユーザは、まず条件式を与え、ボリューム属性管理テーブルT2を検索させることにより、廃棄対象のストレージ装置30上にある「使用中」状態のボリューム群を検出させ、これらのボリュームからなるマイグレーショングループをユーザが定義する。図21において、廃棄対象のストレージ装置30には、「装置番号1」が設定されているものとする。図中
では、廃棄対象のストレージ装置30に存在する「使用中」状態のボリュームに、「退避データボリューム」というマイグレーショングループ名称を与えている。
次に、「装置番号が廃棄対象ストレージ装置の装置番号と異なる(装置番号≠1)」という条件によってストレージ階層を定義する。図中では、廃棄対象のストレージ装置30以外の他のストレージ装置40,80により構成されるストレージ階層に、「移行先階層」というストレージ階層名称を与えている。そして、ユーザは、「移行先階層」のストレージ階層を移動先として、前記マイグレーショングループ「退避データボリューム」の再配置を指示する。
以下、第1実施例で述べたと同様に、データ再配置管理プログラム632は、移動元として指定されたマイグレーショングループ「退避データボリューム」中に含まれる個々のボリュームについて、移動先として指定されたストレージ階層「移行先階層」から適切なボリュームをそれぞれ選択し、ユーザに提示する。
上述のように、ボリューム属性の「使用状態」が「空き」で、かつ、必須属性が一致するボリューム、または、「使用状態」が「空き」で、かつ、必須属性が一致し、さらに非必須属性の一致度も高いボリュームが、適切な移行先候補ボリュームとして選択され、ユーザに提示される。そして、ユーザが、データ再配置管理プログラム632によって提案されたボリュームの対応付けを承認すれば、再配置処理が実行され、廃棄対象ストレージ装置30上にある全てのデータは、他のストレージ装置40,80中の適切なボリュームに再配置される。
また、ストレージ装置の入換えを行う場合や、性能バランスを配慮して既存データの一部を新規に導入したストレージ装置に移行する場合には、「装置番号=新規に導入したストレージ装置の装置番号」という条件でストレージ階層「新規追加階層」を定義し、このストレージ階層を移動先に指定してデータ再配置を行えばよい。このように、本実施例からも明らかなように、本発明では、ストレージシステムの構成やポリシーに応じて、ユーザがストレージ階層を自在に定義することができ、関連するボリュームをマイグレーショングループとして一括指定し、グループ単位でデータ再配置を行うことができる。
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、マイグレーショングループは、必ずしも相互に関連するボリュームから構成する必要はなく、任意のボリュームを移動対象としてグループ化することもできる。また、第1ストレージ装置の階層、第2ストレージ装置の階層、第1ストレージ装置及び第2ストレージ装置の階層等のように、ストレージ装置を単位としてストレージ階層を設定することもできる。
図22、図23、図24に基いて、本発明の第5実施例を説明する。本実施例の特徴は、配置先として指定されたストレージ階層中に、あるボリュームの移動先として適切な空きボリュームがない場合に、移動先となる条件を満たしたボリュームを自動的に作成し、作成したボリュームを移動先候補としてボリュームの再配置を行う点にある。
図22は、本実施例における、移動先候補ボリュームを選択する処理を示すフローチャートである。図22中の多くのステップは、第1実施例の図14で示した移動先候補選択処理におけるステップと共通である。しかし、ストレージ管理サーバ60が、必須属性が一致する空きボリュームとして検出されたボリュームの数を判定するステップ(S13)を実行した結果、そのような空きボリュームが全く発見されなかった場合の処理が異なる。この場合、本実施例では、ボリューム作成処理(S31)を行い、再配置先のストレージ階層に属しており、かつ移動元ボリュームと必須属性が一致するボリュームの作成を試みる。
次に、ストレージ管理サーバ60は、必須属性が一致するボリュームの作成が成功したかどうかを判定し(S32)、成功した場合、作成したボリュームを移動先候補ボリュームとして選択する(S33)。また、作成したボリュームをボリューム属性管理テーブルT2に登録する(S34)。作成できなかった場合、データ再配置を行うことはできないので、エラー処理を行い、ユーザに通知する(S16)。
図23は、図22におけるボリューム作成処理(S31)の詳細を示すフローチャートである。
図23に示すボリューム作成処理では、ストレージ管理サーバ60は、まずボリューム仮想化装置20およびボリューム仮想化装置20に接続されたストレージ装置群の中から、1台のストレージ装置を選択する(S41)。次に、選択したストレージ装置が、作成すべきボリュームに関するストレージ装置要件を満たすかどうかを判定する(S42)。
ここで、ストレージ装置要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ストレージ装置の機種名、装置番号等、ストレージ装置の持つ属性に関わる条件(もしあれば)を指す。選択したストレージ装置がストレージ装置要件を満たす場合、ストレージ管理サーバ60は、選択したストレージ装置内にあるすべてのVDEVのうち、VDEV要件を満たすものの集合Sを求める(S43)。次に、集合Sの中から1個のVDEVを選択する(S44)。
ここで、VDEV要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ディスク種別、RAIDレベル等、VDEVの持つ属性に関わる条件(もしあれば)、および、移動元ボリュームのエミュレーションタイプを指す。
次に、ストレージ管理サーバ60は、選択したVDEV内にある未割当ての空き容量が、移動元ボリュームの容量(Q1)と同等以上の大きさであるかどうかを判定する(S45)。空き容量が移動元ボリュームの容量と同等以上である場合、そのVDEV内部に移動元ボリュームと同一の容量を持つボリューム(LDEV)を新たに作成し(S46)、呼び出し元に対してボリューム作成の成功を報告する。
ステップS45において、選択したVDEV内部に移動元ボリュームの容量と同等以上の空き容量がないと判定された場合、そのVDEV内部に移動先候補となるボリュームを作成することはできないので、ストレージ管理サーバ60は、集合S内に未調査の他のVDEVがないかどうかを判定する(S47)。
他にもVDEVがある場合、次のVDEVを選択し(S48)、ステップS44に戻る。集合S内にもはや未調査のVDEVがない場合、および、ステップS42において、選択したストレージ装置はストレージ装置要件を満たさないと判定された場合には、そのストレージ装置内部に移動先候補となるボリュームを作成することはできないので、ストレージ管理サーバ60は、他に未調査のストレージ装置がないかどうかを判定する(S49)。他にもストレージ装置がある場合、次のストレージ装置を選択し(S50)、ステップS42に戻る。もはや未調査のストレージ装置がない場合には、呼び出し元に対してボリューム作成の失敗を報告する。
このように、本実施例では、データ再配置の指示時点で存在していた空きボリューム群の中から移動先として適切なボリュームを選択するだけでなく、適切な空きボリュームが存在しなかった場合、未割当てのストレージ容量の中から移動先として適切なボリュームを作成することができるので、より柔軟なデータ再配置処理が可能となる。
なお、再配置処理の終了後、移動前のデータを保持していた移動元ボリュームは、ボリューム管理テーブルにおける使用状態を「空き」に変更して再利用可能な状態に戻してもよく、ボリューム自体を削除してストレージ装置の空き容量の一部に戻す構成としてもよい。
図24は、図22におけるボリューム作成処理(S31)の他の例を示すフローチャートである。これは、移動先のボリューム(LDEV)を複数のVDEVの空き領域から作成することを可能にしたものである。
図24に示すボリューム作成処理では、ストレージ管理サーバ60は、まずボリューム仮想化装置20およびボリューム仮想化装置20に接続されたストレージ装置群の中から、1台のストレージ装置を選択する(S41)。次に、選択したストレージ装置が、作成すべきボリュームに関するストレージ装置要件を満たすかどうかを判定する(S42)。
ここで、ストレージ装置要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ストレージ装置の機種名、装置番号等、ストレージ装置の持つ属性に関わる条件(もしあれば)を指す。選択したストレージ装置がストレージ装置要件を満たす場合、ストレージ管理サーバ60は、選択したストレージ装置内にあるすべてのVDEVのうち、VDEV要件を満たすものの集合Sを求める(S43)。次に、集合Sの中から1個のVDEVを選択する(S44)。
ここで、VDEV要件とは、配置先として指定されたストレージ階層を定義する諸条件のうち、ディスク種別、RAIDレベル等、VDEVの持つ属性に関わる条件(もしあれば)、および、移動元ボリュームのエミュレーションタイプを指す。次に、ストレージ管理サーバ60は、選択したVDEV内にある未割当ての空き容量が、移動元ボリュームの容量(Q1)と同等以上の大きさであるかどうかを判定する(S45)。空き容量が移動元ボリュームの容量と同等以上である場合、そのVDEV内部に移動元ボリュームと同一の容量を持つボリューム(LDEV)を新たに作成し(S46)、呼び出し元に対してボリューム作成の成功を報告する。
ステップS45で、移動元ボリュームの容量と同等以上の空き容量がない場合、そのVDEV内部の空き容量(Q2)を確保し(S81)、移動元ボリュームの容量(Q1)と確保した空き容量(Q2)の差分容量(Q3)を求める(S82)。この時点では、まだ移動元ボリュームと同等以上の容量が確保されていないので、ストレージ管理サーバ60は、集合S内に他のVDEVがあるかどうかを判定し(S83)、あれば次にそのVDEVを選択して、そのVDEV内にある未割当の空き容量が、差分容量(Q3)と同等以上の大きさであるかどうかを判断する(S84)。空き容量が差分容量(Q3)と同等以上の大きさである場合、そのVDEV内の空き容量と、これまでのVDEVから確保してきた空き容量を用いて移動元ボリュームと同一の容量を持つボリューム(LDEV)を新たに作成し(S85)、呼び出し元に対してボリューム作成の成功を報告する。
一方、ステップS84でVDEVの空き容量が差分容量Q3と同等以上でない場合、当該VDEVの空き容量(Q2)を確保し(S86)、残りの差分容量(Q3)を求め(S87)、ステップS83へ戻る。
ステップS83で、集合S内に他のVDEVがない場合、そのストレージ装置内では必要な空き容量を確保できないので、ストレージ管理サーバ60は、これまでに確保した空き容量を解放した後(S88)、他に未調査のストレージ装置がないかどうかを判定する(S49)。ステップS42において、選択したストレージ装置はストレージ装置要件を満たさないと判定された場合にも、同様にステップS49に移る。ステップS49において、他にもストレージ装置がある場合、次のストレージ装置を選択し(S50)、ステップS42に戻る。もはや未調査のストレージ装置がない場合には、呼び出し元に対してボリューム作成の失敗を報告する。
このように一つのVDEVから移動元のボリュームの容量を確保できない場合、空き容量を有する複数のVDEVから移動先候補となるボリューム(LDEV)を生成する。
なお、図23、図24のステップ41に、ストレージ装置を選択するようにしているが、ボリューム仮想化装置が、接続されているストレージ装置内のすべてのVDEVを一括管理することにより、ステップ41のストレージ装置の選択を省略し、ボリューム仮想化装置によって管理されたVDEVを順に選択する構成としても良い。
図25、図26、図27、図28、図29、図30に基いて、本発明の第6実施例を説明する。本実施例の特徴は、再配置先として指定されたストレージ階層に対応付けられたアクション中にレプリカの作成が含まれている場合に、再配置先を含む任意のストレージ階層をレプリカ作成先として指定できる点にある。
図25は、本実施例における、ストレージ階層とアクションとの対応付けを示す図である。本実施例では、スクリプト中でレプリカの作成を指示する場合、レプリカの作成先となるストレージ階層を、その名称によって明示的に指定する。図25に示すとおり、レプリカの作成先となるストレージ階層は、再配置先として指定されたストレージ階層自身と同一でもよく、また異なっていてもよい。
図26は、本実施例におけるボリューム属性管理テーブルT2の構成を示す図である。本実施例のボリューム属性管理テーブルでは、ボリュームの使用状態は「使用中」「空き」の2状態ではなく、「ソース」「レプリカ」「リザーブ」「空き」の4状態をとる。また、新たな属性として「ペア」が追加されている。
使用状態「ソース」は、そのボリュームがホストから参照されるユーザデータを保持していることを示す。使用状態「レプリカ」は、そのボリュームがユーザデータの複製であるレプリカを保持していることを示す。使用状態「リザーブ」は、そのボリュームが将来レプリカとして使うために予約されていることを示す。使用状態「空き」は、そのボリュームが以上の3状態のいずれでもなく、データの移動先やコピー先として新たに割当て可能であることを示す。
ボリュームの使用状態が「ソース」「レプリカ」「リザーブ」のいずれかである場合、そのボリュームの属性「ペア」は値を持つことができる。ボリュームの使用状態が「ソース」で、かつそのボリュームがレプリカを持っている場合、属性「ペア」の値は、対となるレプリカボリュームの論理IDを示す。(ただし、そのボリュームがレプリカを持たない場合、属性「ペア」の値は空となる。)ボリュームの使用状態が「レプリカ」の場合、属性「ペア」の値は、対となるソースボリュームの論理IDとなる。ボリュームの使用状態が「リザーブ」の場合、属性「ペア」には、そのボリュームと将来対となるソースボリュームの論理IDが設定される。
図27は、本実施例におけるデータ再配置処理の概略を示すフローチャートである。本実施例のデータ再配置処理では、マイグレーショングループの所定階層への再配置をユーザが指示し(S1)、移動先候補選択処理(S2)、ボリューム対応表の提示(S3)、移動先候補の修正(S4)を行った後、再配置実行処理(S5)を行う前に、レプリカボリュームリザーブ処理(S6)を実行する。
図28は、レプリカボリュームリザーブ処理(S6)の処理内容を示すフローチャートである。本実施例のレプリカボリュームリザーブ処理において、ストレージ管理サーバ60は、まずストレージ階層管理テーブルT3およびアクション管理テーブルT6を参照し、再配置先として指定されたストレージ階層に対応付けられたアクションを得る(S61)。
次に、取得したアクション中で、レプリカ作成が指示されているかどうかを判定する(S62)。レプリカ作成が指示されていない場合、または再配置先ストレージ階層にアクションが対応付けられていない場合は、レプリカボリュームのリザーブは不要であるため、処理を終了する。
アクション中でレプリカ作成が指示されている場合、ストレージ管理サーバ60は、移動元の全ボリュームについて既にレプリカボリュームがリザーブ済みであるかどうかを判定する(S63)。
最初はリザーブ済みではないため次のステップに進み、1個の移動元ボリュームに対応して1個のレプリカボリュームを選択する(S64)。ここで、レプリカボリュームとして選択できるのは、レプリカ作成先として指定されたストレージ階層に属しており、使用状態が「空き」で、移動先候補として選択されておらず、必須属性が移動元ボリュームと一致するボリュームである。
次に、ストレージ管理サーバ60は、そのようなボリュームが選択できたかどうかを判定する(S65)。選択できなかった場合、レプリカ作成に必要なボリュームが確保できなかったことになるため、エラー処理を行い(S67)、ユーザに通知する。なお、ここで図22のS31からS34の処理を実行してレプリカ作成に必要なボリュームを作成するようにしてもよい。
選択できた場合には、そのボリュームをリザーブし(S66)、ステップS63に戻り、移動元の全ボリュームについてレプリカボリュームのリザーブが済むまで同様の処理を繰り返す。ここで、あるボリュームをリザーブするとは、ボリューム属性管理テーブルT2において、そのボリュームの使用状態を「リザーブ」に変更し、かつそのボリュームの属性「ペア」に、対応する移動元ボリュームの論理IDを設定することである。
図29は、本実施例における、アクションスクリプト実行処理の詳細を示すフローチャートである。この処理は、図15に示す再配置実行処理のステップS28に相当し、1個の移動元ボリュームの記憶内容を対応する移動先ボリュームにコピーし、そのアクセスパス(論理ID)を切り替えた後に、移動先ボリュームを対象として、再配置先ストレージ階層に対応付けられたアクションを実行する処理である。
図29に示すアクションスクリプト実行処理において、ストレージ管理サーバ60は、まず対象となる移動先ボリュームに関して、未実行のアクションがあるかどうかを判定する(S71)。未実行のアクションがある場合、1個の未実行アクションを取り出し(S72)、その種別を判別する(S73)。
アクション種別がレプリカ作成であった場合、ストレージ管理サーバ60は、ボリューム管理テーブルT2を参照して、移動先ボリュームに対応してリザーブされているリザーブボリュームを取得する(S74)。ここで、移動先ボリュームに対応してリザーブされているリザーブボリュームとは、属性「ペア」の値として移動先ボリュームの論理IDを保持しているボリュームのことである。
次に、ストレージ管理サーバ60は、ボリューム仮想化装置20に対して、移動先ボリュームをプライマリ、リザーブボリュームをセカンダリとするペア関係を設定する(S75)。同時に、ボリューム属性管理テーブルT2上において、移動先ボリュームの属性「ペア」に対応するリザーブボリュームの論理IDを設定し、またリザーブボリュームの使用状態を「レプリカ」に変更する。
次に、ストレージ管理サーバ60は、ボリューム仮想化装置20に対して、ステップS75でペア関係を設定したボリューム間の同期化を指示する(S76)。これにより、移動先ボリューム(プライマリ)からリザーブボリューム(セカンダリ)へデータのコピーが行われ、両者の内容は同一となる。また、これ以降、プライマリボリュームの内容が書き換えられると、書き換えられた部分のデータがセカンダリボリュームにコピーされ、両者の内容は常に同一に保たれる。
以上の処理を行った後、ストレージ管理サーバ60は、ステップS71に戻って再び未実行アクションの有無を判定する。また、ステップS73においてアクション種別がレプリカ作成以外と判定された場合、アクション種別に対応した所定の処理を実行し(S77)、同じくステップS71に戻る。
ステップS71において、もはや未実行のアクションはないと判断されると、ストレージ管理サーバ60はアクションスクリプト実行処理を終了する。
図30は、本実施例のデータ再配置処理の過程の各段階における、ボリューム属性管理テーブルT2の状態の一例を示す図である。図30(a)は初期状態を示しており、必須属性(容量およびエミュレーションタイプ)が一致する3個のボリュームが登録されている。このうち、論理ID「001」のボリュームはユーザデータを保持しており、論理ID「006」および「007」のボリュームは空き状態である。この状態で、論理ID「001」のボリュームを移動元、論理ID「006」のボリュームを移動先とし、かつレプリカ作成を伴うデータ再配置が指示されたものとする。
図30(b)は、レプリカボリュームリザーブ処理(S6)において、論理ID「007」のボリュームがレプリカ用のリザーブボリュームとして選択された状態を示している。ボリューム「007」の使用状態は「リザーブ」となり、その属性「ペア」には移動元ボリュームの論理IDである「001」が設定される。
図30(c)は、データ再配置処理終了後の状態を示している。移動元ボリュームから移動先ボリュームにデータがコピーされた後、両者のアクセスパス(論理ID)の入れ替えが行われ、この時点では移動先ボリュームの論理IDが「001」となっている。論理ID「007」のボリュームはそのレプリカを保持しており、ソースとレプリカの両ボリュームは互いに属性「ペア」で参照しあっている。
このように、本実施例では、ストレージ階層に対応付けられたアクションの中で、任意のストレージ階層をレプリカ作成先として指定しておき、データの再配置処理が行われた場合に、再配置処理の一環として、他のストレージ階層(または再配置先と同一のストレージ階層)内に、移動したデータのレプリカを自動的に作成することができる。これにより、例えば高信頼階層の定義の一部として低コスト階層へのレプリカ作成を記述するなど、柔軟で有用性の高いストレージ階層定義が可能となる。
本発明の実施形態の概念を示す説明図である。 ストレージシステムの全体概要を示すブロック図である。 ストレージシステムに分散するボリュームを仮想化して管理する様子を模試的に示す説明図である。 ストレージシステムのハードウェア構成を示すブロック図である。 ストレージシステムの記憶構造を示す説明図である。 ストレージ管理サーバの構成を示すブロック図である。 マッピングテーブルの構成を示す説明図である。 ボリューム属性管理テーブルの構成を示す説明図である。 ストレージ階層管理テーブルの構成を示す説明図である。 対応ホスト管理テーブルの構成を示す説明図である。 マイグレーショングループ管理テーブルの構成を示す説明図である。 アクション管理テーブルの構成を示す説明図である。 データ再配置の全体動作の概要を示す説明図である。 移動先候補選択処理を示すフローチャートである。 再配置実行処理を示すフローチャートである。 データ再配置の計画案を提示する画面例を示す説明図である。 提示された計画を修正する画面例を示す説明図である。 本発明の第2実施例に係るストレージシステムの全体構成を簡略化して示すブロック図である。 本発明の第3実施例に係るストレージシステムで使用されるボリューム属性管理テーブルの構成を示す説明図である。 本発明の第4実施例に係るストレージシステムの全体概要を示すブロック図である。 マイグレーショングループ管理テーブルとストレージ階層管理テーブルとの関係を模式的に示す説明図である。 本発明の第5実施例に係る移動先候補選択処理を示すフローチャートである。 本発明の第5実施例に係るボリューム作成処理を示すフローチャートである。 本発明の第5実施例に係るボリューム作成処理を示す他のフローチャートである。 本発明の第6実施例に係るストレージ階層管理テーブルとアクション管理テーブルとの関係を模式的に示す説明図である。 本発明の第6実施例に係るボリューム属性管理テーブルの構成を示す説明図である。 本発明の第6実施例に係るデータ再配置処理を示すフローチャートである。 本発明の第6実施例に係るレプリカボリュームリザーブ処理を示すフローチャートである。 本発明の第6実施例に係るアクションスクリプト実行処理を示すフローチャートである。 本発明の第6実施例に係るボリューム属性管理テーブルの状態の変遷の例を模式的に示す図である。
符号の説明
1〜3…ストレージ階層、10…ホスト、11…アプリケーションプログラム、12…ホストバスアダプタ、20…ストレージ装置(ボリューム仮想化装置)、30,40,80…ストレージ装置、50…管理クライアント、51…ウェブヴラウザ、60…ストレージ管理サーバ、70…ボリューム仮想化装置、71…ボリューム仮想化部、72…データ再配置部、73…ボリュームデータベース、210…チャネルアダプタ、211…通信ポート、220…ディスクアダプタ、230…キャッシュメモリ、240…共有メモリ、250,260…接続制御部、270…記憶部、271…ディスクドライブ(PDEV)、272…仮想デバイス(VDEV)、273…論理ボリューム(LDEV)、274…LU、275…コマンドデバイス(CMD)、310,410…コントローラ、311,411…通信ポート320,420…ディスクドライブ、330,430…論理ボリューム、610…通信部、620…制御部、630…メモリ、631…ウェブサーバプログラム、632…データ再配置管理プログラム(データ再配置管理部)、633…データベース管理システム、640…ボリュームデータベース、CN…通信ネットワーク、T1…マッピングテーブル、T2…ボリューム属性管理テーブル、T3…ストレージ階層管理テーブル、T4…対応ホスト管理テーブル、T5…マイグレーショングループ管理テーブル、T6…アクション管理テーブル、T7…ボリューム対応表

Claims (10)

  1. 各々がコントローラと当該コントローラに接続される複数のディスクドライブから構成される物理的なボリュームを有する、複数のストレージ装置と、
    前記複数のストレージ装置と接続され、物理的なボリュームと仮想的なボリュームとの間の対応関係を管理し、計算機からの当該仮想的なボリュームへのアクセスを受け付ける仮想化部と、
    複数のストレージ階層と各ストレージ階層に属する一以上の仮想的なボリュームとの対応関係を管理する管理部とを有し、
    前記仮想的なボリュームは前記計算機からアクセス先として認識されるボリュームであり、
    前記仮想化部は一の物理的なボリュームを複数の仮想的なボリュームと対応付けており、
    前記管理部は、前記仮想的なボリューム毎に当該仮想的なボリュームの属性情報を管理し、当該仮想的なボリュームの属性情報に基づいて、当該仮想的なボリュームが属するストレージ階層を作成し、
    前記管理部は更に、ストレージ階層と所定の処理とを関連付けて管理し、
    前記管理部が、各々異なる仮想的なボリュームを示す複数の識別情報から選択された一の移動元となる仮想的なボリュームを示す識別情報と、移動先となるストレージ階層を指定するための情報とを受信すると、
    前記管理部の制御によって、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
    前記移動元の仮想的なボリュームのデータが、当該移動元の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から前記移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域へコピーされ、
    前記仮想化部は、前記移動元の仮想的なボリュームの識別情報を、当該移動元の仮想的なボリュームに代えて前記移動先の仮想的なボリュームに割り当て
    データのコピー後に、前記管理部は前記移動先となるストレージ階層に対応付けられた前記所定の処理を実行することを特徴とするストレージシステム。
  2. 請求項1記載のストレージシステムであって、
    前記管理部は、複数の仮想的なボリュームから構成されるマイグレーショングループを管理しており、前記管理部が移動元の仮想的なボリュームを指定するための情報として当該マイグレーショングループを指定するための情報を受信した場合に、
    前記管理部の制御によって、指定された前記マイグレーショングループに属する複数の仮想的なボリューム各々について、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
    前記マイグレーショングループに属する複数の仮想的なボリューム各々のデータが、当該仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から当該各仮想的なボリュームの移動先として選択された移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域へコピーされ、
    前記仮想化部は、前記マイグレーショングループに属する複数の仮想的なボリューム各々の識別情報を、当該各仮想的なボリュームの移動先として選択された前記移動先の仮想的なボリュームに割り当てることを特徴とするストレージシステム。
  3. 請求項2記載のストレージシステムであって、
    前記管理部は、複数の仮想的なボリュームの中から相互に所定の関連性のある仮想的なボリュームを複数特定し、特定された複数の仮想的なボリュームを有する前記マイグレーショングループを作成することを特徴とするストレージシステム。
  4. 請求項2記載のストレージシステムであって、前記マイグレーショングループには、同じアプリケーションによって使用されるデータを格納している複数の仮想的なボリュームが含まれることを特徴とするストレージシステム。
  5. 請求項1記載のストレージシステムであって、前記所定の処理とは、仮想的なボリュームの属性をRead Only属性に変更する処理、若しくは仮想的なボリュームの複製を生成する処理であることを特徴とするストレージシステム。
  6. 各々がコントローラと当該コントローラに接続される複数のディスクドライブから構成される物理的なボリュームを有する複数のストレージ装置と、
    前記複数のストレージ装置と接続され、物理的なボリュームと仮想的なボリュームとの間の対応関係を管理し、計算機からの当該仮想的なボリュームへのアクセスを受け付ける仮想化部と、
    データの移動を管理する管理部とを有するストレージシステムにおけるデータの移動方法であって、
    前記仮想的なボリュームは、前記計算機からアクセス先として認識されるボリュームであって、
    前記仮想化部は、一の物理的なボリュームを複数の仮想的なボリュームと対応付けており、
    前記管理部は、前記仮想的なボリューム毎に当該仮想的なボリュームの属性情報を管理し、当該仮想的なボリュームの属性情報に基づいて、当該仮想的なボリュームが属するストレージ階層を作成し、
    前記管理部は更に、ストレージ階層と所定の処理とを関連付けて管理し、
    前記管理部が、各々異なる仮想的なボリュームを示す複数の識別情報から選択された一の移動元となる仮想的なボリュームを示す識別情報と、移動先となるストレージ階層を指定するための情報とを受信すると、
    前記管理部の制御によって、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
    前記移動元の仮想的なボリュームのデータが、当該移動元の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から前記移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域へコピーされ、
    前記仮想化部は、前記移動元の仮想的なボリュームの識別情報を、当該移動元の仮想的なボリュームに代えて前記移動先の仮想的なボリュームに割り当て、
    データのコピー後に、前記管理部は前記移動先となるストレージ階層に対応付けられた前記所定の処理を実行することを特徴とするデータの移動方法
  7. 請求項6記載のデータの移動方法であって、
    前記管理部は、複数の仮想的なボリュームから構成されるマイグレーショングループを管理し、
    前記管理部が移動元の仮想的なボリュームを指定するための情報として当該マイグレーショングループを指定するための情報を受信した場合に、
    前記管理部の制御によって、指定された前記マイグレーショングループに属する複数の仮想的なボリューム各々について、指定された前記移動先となるストレージ階層に対応付けられた仮想的なボリュームの中から移動先の仮想的なボリュームが選択され、
    前記マイグレーショングループに属する複数の仮想的なボリューム各々のデータが、当該仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域から当該各仮想的なボリュームの移動先として選択された移動先の仮想的なボリュームに対応付けられた物理的なボリューム内の記憶領域にコピーされ、
    前記仮想化部は、前記マイグレーショングループに属する複数の仮想的なボリューム各々の識別情報を、当該各仮想的なボリュームの移動先として選択された前記移動先の仮想的なボリュームに割り当てることを特徴とするデータの移動方法。
  8. 請求項7記載のデータの移動方法であって、
    前記管理部は、複数の仮想的なボリュームの中から相互に所定の関連性のある仮想的なボリュームを複数特定し、特定された複数の仮想的なボリュームを有する前記マイグレーショングループを作成することを特徴とするデータの移動方法。
  9. 請求項記載のデータの移動方法であって、
    前記管理部は、同じアプリケーションによって使用されるデータを格納している複数の仮想的なボリュームを用いて前記マイグレーショングループを作成することを特徴とするデータの移動方法。
  10. 請求項記載のデータの移動方法であって、前記所定の処理とは、仮想的なボリュームの属性をRead Only属性に変更する処理、若しくは仮想的なボリュームの複製を生成する処理であることを特徴とするデータの移動方法。
JP2005245386A 2004-08-30 2005-08-26 ストレージシステム及びデータの移動方法 Expired - Fee Related JP4643395B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2005245386A JP4643395B2 (ja) 2004-08-30 2005-08-26 ストレージシステム及びデータの移動方法
US11/289,277 US7395396B2 (en) 2004-08-30 2005-11-30 Storage system and data relocation control device
US11/950,008 US8230038B2 (en) 2004-08-30 2007-12-04 Storage system and data relocation control device
US13/489,836 US8799600B2 (en) 2004-08-30 2012-06-06 Storage system and data relocation control device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004250327 2004-08-30
JP2005245386A JP4643395B2 (ja) 2004-08-30 2005-08-26 ストレージシステム及びデータの移動方法

Related Child Applications (2)

Application Number Title Priority Date Filing Date
JP2007003606A Division JP4643597B2 (ja) 2004-08-30 2007-01-11 ストレージシステム及びデータ再配置制御装置
JP2007280358A Division JP4842909B2 (ja) 2004-08-30 2007-10-29 ストレージシステム及びデータ再配置制御装置

Publications (3)

Publication Number Publication Date
JP2006099748A JP2006099748A (ja) 2006-04-13
JP2006099748A5 JP2006099748A5 (ja) 2007-03-01
JP4643395B2 true JP4643395B2 (ja) 2011-03-02

Family

ID=36239429

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005245386A Expired - Fee Related JP4643395B2 (ja) 2004-08-30 2005-08-26 ストレージシステム及びデータの移動方法

Country Status (1)

Country Link
JP (1) JP4643395B2 (ja)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4900784B2 (ja) * 2006-04-13 2012-03-21 株式会社日立製作所 ストレージシステム及びストレージシステムのデータ移行方法
JP4856467B2 (ja) * 2006-05-01 2012-01-18 株式会社日立製作所 ストレージ資源管理システム、ストレージ資源管理方法および管理計算機
JP5103786B2 (ja) * 2006-05-15 2012-12-19 富士通株式会社 制御プログラム、制御装置、制御方法
JP4896593B2 (ja) * 2006-06-05 2012-03-14 株式会社日立製作所 性能監視方法、計算機及び計算機システム
JP4863814B2 (ja) * 2006-08-04 2012-01-25 株式会社日立製作所 記憶媒体グループの故障を抑えるストレージシステム
JP4939154B2 (ja) 2006-09-14 2012-05-23 株式会社日立製作所 ストレージ装置及び構成設定方法
JP4930934B2 (ja) * 2006-09-29 2012-05-16 株式会社日立製作所 データマイグレーション方法及び情報処理システム
JP4949791B2 (ja) 2006-09-29 2012-06-13 株式会社日立製作所 ボリューム選択方法及び情報処理システム
JP4757165B2 (ja) 2006-10-04 2011-08-24 株式会社日立製作所 計算機システム、データ移行監視方法及びデータ移行監視プログラム
JP2008102590A (ja) 2006-10-17 2008-05-01 Hitachi Ltd ストレージシステムの運用管理方法およびストレージシステム
JP4235220B2 (ja) * 2006-10-25 2009-03-11 株式会社日立製作所 計算機システムおよびデータ移行方法
JP4914173B2 (ja) 2006-10-30 2012-04-11 株式会社日立製作所 再配置システムおよび再配置方法
JP2008140221A (ja) 2006-12-04 2008-06-19 Hitachi Ltd ストレージシステム及び管理方法並びに管理装置
JP4935331B2 (ja) * 2006-12-06 2012-05-23 日本電気株式会社 ストレージシステムと記憶領域の選択方法並びにプログラム
JP5158074B2 (ja) * 2007-03-20 2013-03-06 富士通株式会社 ストレージ管理プログラム、ストレージ管理方法、ストレージ管理装置およびストレージシステム
JP5130764B2 (ja) * 2007-03-28 2013-01-30 日本電気株式会社 ストレージシステムおよびその省電力化方法ならびにプログラム
JP5087309B2 (ja) 2007-04-24 2012-12-05 株式会社日立製作所 管理装置及び管理方法
JP4893716B2 (ja) 2008-08-28 2012-03-07 富士通株式会社 バックアップ装置、バックアップ方法およびバックアッププログラム
JP5172574B2 (ja) * 2008-09-29 2013-03-27 株式会社日立製作所 アプリケーションデータのバックアップ構成構築に用いる管理計算機
JP4727705B2 (ja) * 2008-10-31 2011-07-20 株式会社日立製作所 階層型ストレージシステム
JP2010128985A (ja) 2008-11-28 2010-06-10 Hitachi Ltd ストレージ管理サーバ、ストレージ構成の再配置方法
CN101419616A (zh) 2008-12-10 2009-04-29 阿里巴巴集团控股有限公司 一种数据同步方法及装置
JP2010257020A (ja) 2009-04-22 2010-11-11 Hitachi Ltd データマイグレーション管理装置及び管理方法
US9773033B2 (en) * 2009-05-22 2017-09-26 International Business Machines Corporation Storing and retrieving volumes in a database by volume attributes
JP5286192B2 (ja) 2009-08-12 2013-09-11 株式会社日立製作所 ストレージシステムの容量を管理する管理計算機及びストレージシステムの容量管理方法
JP5278254B2 (ja) * 2009-09-02 2013-09-04 日本電気株式会社 ストレージシステム、データ記憶方法及びプログラム
US8402214B2 (en) * 2009-09-16 2013-03-19 Hitachi, Ltd. Dynamic page reallocation storage system management
US8566550B2 (en) * 2009-09-22 2013-10-22 Hitachi, Ltd. Application and tier configuration management in dynamic page reallocation storage system
JP5241671B2 (ja) 2009-10-05 2013-07-17 株式会社日立製作所 記憶装置のデータ移行制御方法
US8458424B2 (en) 2010-02-08 2013-06-04 Hitachi, Ltd. Storage system for reallocating data in virtual volumes and methods of the same
JP5070315B2 (ja) 2010-04-28 2012-11-14 株式会社日立製作所 ストレージ装置及びストレージ装置におけるデータ階層管理方法
WO2012039062A1 (ja) 2010-09-24 2012-03-29 株式会社日立製作所 ストレージ装置における複数の記憶デバイスを複数の階層に振り分ける方法及びシステム
JP5341259B2 (ja) * 2010-10-07 2013-11-13 株式会社日立製作所 マイグレーション先の決定を支援する方法及び管理システム
CN103080894A (zh) * 2010-12-28 2013-05-01 株式会社日立制作所 存储系统、存储系统的管理方法和程序
JP5602957B2 (ja) * 2011-08-01 2014-10-08 株式会社日立製作所 第1記憶制御装置及び第1記憶制御装置の制御方法
WO2013093994A1 (ja) 2011-12-19 2013-06-27 富士通株式会社 ストレージシステム、データリバランシングプログラム及びデータリバランシング方法
JP5269216B2 (ja) * 2012-01-16 2013-08-21 株式会社日立製作所 データマイグレーション方法及び情報処理システム
JP6035991B2 (ja) 2012-08-15 2016-11-30 富士通株式会社 ストレージ制御方法、およびストレージ制御装置
JP5501504B2 (ja) * 2013-04-01 2014-05-21 株式会社日立製作所 記憶装置のデータ移行制御方法
US10180798B2 (en) 2014-10-27 2019-01-15 Hitachi, Ltd. Method and apparatus to configure information technology infrastructure
US20160378846A1 (en) * 2015-06-26 2016-12-29 Intel Corporation Object based storage cluster with multiple selectable data handling policies
US10564881B2 (en) 2018-05-31 2020-02-18 International Business Machines Corporation Data management in a multitier storage system
US11119654B2 (en) * 2018-07-10 2021-09-14 International Business Machines Corporation Determining an optimal storage environment for data sets and for migrating data sets
US11269780B2 (en) * 2019-09-17 2022-03-08 Micron Technology, Inc. Mapping non-typed memory access to typed memory access
US11494311B2 (en) 2019-09-17 2022-11-08 Micron Technology, Inc. Page table hooks to memory types
US11650742B2 (en) 2019-09-17 2023-05-16 Micron Technology, Inc. Accessing stored metadata to identify memory devices in which data is stored
US10963396B1 (en) * 2019-09-17 2021-03-30 Micron Technology, Inc. Memory system for binding data to a memory namespace
CN113535069A (zh) * 2020-04-22 2021-10-22 联想企业解决方案(新加坡)有限公司 数据存储系统、计算设备及数据存储系统的构建方法

Also Published As

Publication number Publication date
JP2006099748A (ja) 2006-04-13

Similar Documents

Publication Publication Date Title
JP4643395B2 (ja) ストレージシステム及びデータの移動方法
JP5178854B2 (ja) ストレージシステム及びデータ再配置制御装置
JP4842909B2 (ja) ストレージシステム及びデータ再配置制御装置
US8799600B2 (en) Storage system and data relocation control device
JP4643597B2 (ja) ストレージシステム及びデータ再配置制御装置
JP4690765B2 (ja) ストレージ管理システム、ストレージ管理サーバ、データ再配置制御方法およびデータ再配置制御プログラム
US7581061B2 (en) Data migration using temporary volume to migrate high priority data to high performance storage and lower priority data to lower performance storage
JP4990322B2 (ja) データ移動管理装置及び情報処理システム
JP4648751B2 (ja) 記憶制御システム及び記憶制御方法
JP4889985B2 (ja) ストレージ階層を考慮したボリュームグループを管理する方法
US8161262B2 (en) Storage area dynamic assignment method
US7587553B2 (en) Storage controller, and logical volume formation method for the storage controller
JP4555036B2 (ja) ストレージ装置及びストレージ装置のデバイス切替制御方法
EP2399190B1 (en) Storage system and method for operating storage system
JP2006127028A (ja) 記憶システム及び記憶制御装置
JP2007072813A (ja) ストレージシステム、ファイル移動方法、及びコンピュータプログラム
JP2008134712A (ja) ファイル共有システム、ファイル共有装置及びファイル共有用ボリュームの移行方法
JP2006134021A (ja) ストレージシステム及びストレージシステムの構成管理方法
US8732428B2 (en) Computer system and its control method
JP5052257B2 (ja) 記憶システム及び記憶制御装置

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20061114

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070111

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070111

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20070111

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20070206

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20070226

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070410

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070608

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070828

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071029

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080219

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080421

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20080424

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20081128

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101108

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101202

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131210

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees