(57)【要約】容量割当制御部３４は、容量管理情報格納部３３に格納されているデータを参照して、現在の空き容量が所定の閾値未満となった監視対象資源に対して、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを、自サイト内の実ボリュームで対応できない場合にはｉＳＣＳＩプロトコルを用いて他サイト（リモートサイト５０）にアクセスしてその実ボリューム７０を借用して、該監視対象資源に追加容量を割り当てる制御を行う。また、その後、集約部３５によって、上記借用した他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、借用していた他サイトの実ボリュームは返却してもよい。
2005001700.tif 000002
【特許請求の範囲】
【請求項１】
ストレージ仮想化が行われているサイトにおけるサーバにおいて、
自サイト内の実ボリューム全体に関する空き実容量と、自サイト内の各監視対象資源毎の容量割当情報を格納する容量管理情報格納手段と、
現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる容量割当制御手段と、
を有することを特徴とするサーバ。
【請求項２】
前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する集約手段を更に有することを特徴とする請求項１記載のサーバ。
【請求項３】
前記容量割当制御手段は、前記ストレージ仮想化に基づく「ボリュームの動的容量追加」機能を実行することで前記監視対象資源に追加容量を割り当てることを特徴とする請求項１記載のサーバ。
【請求項４】
前記集約手段は、前記ストレージ仮想化に基づく仮想化制御により一時的にミラー状態を構成する「実ボリュームの動的再配置」機能を実行することで、前記データを前記空き領域に集約することを特徴とする請求項２記載のサーバ。
【請求項５】
前記借用した他サイトの実ボリュームへのアクセスは、ＩＰを利用したＳＣＳＩプロトコルを用いることを特徴とする請求項１〜４の何れかに記載のサーバ。
【請求項６】
ストレージ仮想化が行われているサイトにおけるストレージ容量管理方法であって、
自サイト内の任意の監視対象資源の容量拡張が必要と判定した場合、自サイト内の実ボリュームによって該監視対象資源への割当容量を増加できるか否かを判定し、
自サイト内の実ボリュームによって該監視対象資源への割当容量を増加できると判定した場合には、自サイト内の実ボリュームを用いて該監視対象資源への割当容量を拡張し、
自サイト内の実ボリュームによって該監視対象資源の割当容量を増加できないと判定した場合には、他サイトの実ボリュームを借用することを特徴とするストレージ容量管理方法。
【請求項７】
前記他サイトの実ボリュームの借用後、自サイトの空き実容量に余裕ができた場合には、該他サイトの実ボリュームに格納したデータを自サイトに集約して、前記他サイトの実ボリュームは返却することを特徴とする請求項６記載のストレージ容量管理方法。
【請求項８】
前記借用した他サイトの実ボリュームへのアクセスは、ＩＰを利用したＳＣＳＩプロトコルを用いることを特徴とする請求項６または７記載のストレージ容量管理方法。
【請求項９】
コンピュータに、
仮想ボリュームと実ボリュームの対応関係を規定する仮想化管理データを格納する機能と、
自サイト内の実ボリューム全体に関する全実容量、空き実容量、割当て実容量と、自サイト内の各監視対象資源毎に、少なくともその監視対象資源の現在の空き容量を格納する機能と、
前記現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる機能と、
を実現させるためのプログラム。
【請求項１０】
前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する機能を更に前記コンピュータに実現させるための請求項９記載のプログラム。
【請求項１１】
コンピュータに、
仮想ボリュームと実ボリュームの対応関係を規定する仮想化管理データを格納する機能と、
自サイト内の実ボリューム全体に関する全実容量、空き実容量、割当て実容量と、自サイト内の各監視対象資源毎に、少なくともその監視対象資源の現在の空き容量を格納する機能と、
前記現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる機能と、
を実行させるためのプログラムを格納した前記コンピュータ読み取り可能な記録媒体。
【請求項１２】
前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する機能を更に前記コンピュータに実現させるための請求項１１記載の記録媒体。
【発明の詳細な説明】
【技術分野】  本発明は、ストレージ・ネットワークに対するストレージ仮想化が施されたシステムに係わり、特に各情報処理資源に対する容量の割当て、容量追加を自動的に行う制御方法等に関する。
【背景技術】  近年、ストレージ技術分野に関して、ストレージ・ネットワーク技術により、ネットワーク化とインテリジェト化が進んでいる。サーバへの従属から脱却し、サーバプラットフォームから独立したストレージは、今や自立したコンピューティング・プラットフォームへと進化しつつある。
このようなストレージ・ネットワーク技術として、従来、例えばＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）等が知られている。ＳＡＮは、主にＦｉｂｒｅ  Ｃｈａｎｎｅｌ技術を使って、サーバとストレージ間をつなぐ専用ネットワークを構築するものである。クライアント−サーバ間を結ぶＬＡＮとは別に、サーバとストレージ間をＳＡＮとして結ぶ構成となっており、複数のストレージ装置を単一のシステムとしてイメージすることで一元管理する。ストレージをサーバから独立させることにより、ディスクミラーによるデータ保護、ＬＡＮフリー／サーバレス・バックアップ、ディザスタ・リカバリといったストレージ独自のソリューションの導入が可能になった。Ｆｉｂｒｅ  Ｃｈａｎｎｅｌのハブやスイッチを使って、ＬＡＮ同様に拡張性の高い柔軟なネットワークを構築することが可能であり、ストレージの許容量、管理等の向上をはかることができる。
また、ＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）は、ファイルサーバを接続するようにＩＰネットワークに接続して使用するネットワークストレージである。ＳＡＮではクライアントがサーバ経由でしかストレージにアクセスできないのに対して、ＮＡＳではサーバのみならずクライアントからもストレージに直接アクセスすることができる。
更に近年、上記ストレージ・ネットワークに対して、ストレージ仮想化（Ｓｔｏｒａｇｅ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）技術が登場してきている。従来のＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）がストレージの物理的統合であったのに対して、ストレージ仮想化はストレージを論理的に統合する。
上記ＳＡＮは、ストレージをサーバから分離独立させ、全ファイルを物理的に集約した。しかし、ＳＡＮを構成するストレージ上のデータは、論理的には相変わらずサーバのＯＳやアプリケーションと密接に関係している。ストレージ上にあるさまざまなサーバのデータは、物理的には一箇所に存在しているが、論理的には一つの管理単位として全く統合されていない。ストレージ・ネットワークとしてのＳＡＮの機能をより高めるためには、ＳＡＮを構成するストレージ上のデータを論理的にもサーバから独立させ、ストレージ装置側で物理的かつ論理的に一括して制御し管理できるようにする必要がある。そのための技術が、ストレージ仮想化技術である。
ストレージ仮想化では、サーバのＯＳやアプリケーションから見たストレージの論理ビューとストレージ内の物理的インプリメンテーションを分離する。つまり、外側から見たストレージの見え方とストレージの物理的な存在を分離する。ディスク本体は、かなり以前から仮想化されている。ＲＡＩＤ技術によって、シリンダ、トラック、ディスクのブロック配置といった個々のディスク装置レベルで仮想化が実現された結果、ハードウェアレベルでのミラーリングやストライピングが実現された。ストレージ仮想化技術は、同様なことをストレージ・ネットワーク全体で実現する。
ここで、仮想化ということに関しては、仮想メモリ（ページング処理、スワッピング処理）が非常に有名であるが、上記の通り、ストレージ仮想化は、このような仮想メモリの技術とは全く異なるものである。従って、例えば、特許文献１、特許文献２、特許文献３等のように、仮想メモリ（ページング処理またはスワッピング処理あるいは両方）に係わる発明は、本発明とは全く関係のない技術分野の発明である。
上記ストレージ仮想化技術に関して、既に以下に図１３〜図１８で説明する機能が使用できるようになっている。すなわち、以下に図１３、図１４で説明する「ボリュームの仮想化」機能、図１５で説明する「ボリュームを仮想化と非仮想化の間で出し入れする」機能、図１６で説明する「ボリュームの動的容量追加」機能、図１７で説明する「ユーザデータのミラーリング」機能、図１８で説明する「実ボリュームの動的再配置」機能が知られている。また、近年、ＩＰ経由のＳＣＳＩアクセス技術（ｉＳＣＳＩ）が知られている。尚、これらの既存技術は、例えば非特許文献１、非特許文献２、非特許文献３、非特許文献４、非特許文献５等に紹介されている。また、既にこれらの機能を備えた製品（例えばＩＰＳｔｏｒ等）が発売されている。尚、ＩＰＳｔｏｒについては、例えば非特許文献６のホームページ上で紹介されている。
図１３にそのイメージを示す「ボリュームの仮想化」機能は、ストレージ仮想化技術において当たり前の機能であるが、一応説明するならば、当該機能によって、ホスト２００から見えるボリュームを抽象化して仮想ボリュームとし、この仮想ボリュームに対応するデータが実際に存在する実ボリュームの所在や構成は、ホスト２００からは見えなくしている。よって、図１３に示すように、ホスト２００から見える１つの仮想ボリュームＶ１（例えば２ＧＢ）は、実際には２つの実ボリュームＲ１、Ｒ２（例えば各々、１ＧＢずつ）より成っているかもしれない。当然、その逆も有り得る。尚、仮想ボリュームと実ボリュームとの対応関係等は不図示の仮想化サーバがその管理情報に基づいて一元管理しており、ホスト２００は、任意のデータが必要な場合、仮想化サーバを介して、データの取得等を行う。尚、仮想化サーバは、独立した１つのサーバとして構成される例に限らず、例えばホスト２００自体が仮想化サーバの機能を有する構成で、ホスト２００内のアプリケーション等が当該仮想化サーバ機能を介してストレージにアクセスするものであってもよい。
また、上記仮想ボリュームと実ボリュームとの対応関係を示す管理情報は、例えば図１４（ａ）に示すようにユーザデータを格納する実ボリュームＲ１，Ｒ２，Ｒ３上に置いてもよいし、図１４（ｂ）に示すようにユーザデータを格納する実ボリュームＲ１，Ｒ２，Ｒ３とは異なるボリューム２２０にまとめて管理情報を配置してもよい。
次に、上記「ボリュームを仮想化と非仮想化の間で出し入れする」機能について説明する。この機能によれば、図１５（ａ）、（ｂ）に示すように、実ボリュームＲ１上のユーザデータを他の実ボリュームに移すこと（コピー）をしなくてもそのまま仮想配下に置いて使用することができるし（その際、管理情報２２０に仮想ボリュームＶ１と実ボリュームＲ１との対応関係を登録する）、その逆に仮想化された状態から非仮想化の状態に戻すこともできる。
次に、上記「ボリュームの動的容量追加」機能について説明する。
ホストから直接実ボリュームを使用しているときにその実ボリュームの容量を増やすには、ホストの運転を停止して、必要な容量の別の実ボリュームを用意して、この別の実ボリュームにユーザデータをコピーし、その後ホストの業務を再開しなければならない。しかし、仮想ボリュームであれば、ホストを停止することなく容量追加を実現できる。そのイメージを図１６に示す。図１６には、仮想ボリュームＶ１の容量は、例えば最初は実ボリュームＲ１に対応するＶ１−１の分の容量のみであったが、その後、実ボリュームＲ２，Ｒ３，Ｒ４に対応するＶ１−２、Ｖ１−３、Ｖ１−４の分の容量を次々と動的に追加していくイメージを示す。図１６では、例えば仮想化サーバ２３０が、仮想ボリュームと実ボリュームとの対応関係を示す管理データ２３１を保持して仮想化制御を行っており、上記容量追加の際には、実ボリュームＲ２，Ｒ３，Ｒ４と仮想ボリュームＶ１（Ｖ１−２、Ｖ１−３、Ｖ１−４）との対応関係を、新たに管理データ２３１に登録することになる。
次に、上記「ユーザデータのミラーリング」機能について説明する。
既によく知られているように、ストレージ仮想化においては、ミラーリングを構成することができる。つまり、図１７（ａ）に示すようにストレージ仮想化した状態から、図１７（ｂ）に示すようにホスト２００から見えるひとつの仮想ボリュームＶ１に対応する実ボリュームを二重にして、２つの実ボリュームＲ１，Ｒ５上に全く同じデータ１を置くことで、一方の実ボリュームに障害が発生しても、他方の実ボリュームを用いることで、ホストの業務が停止することを防止できる。
次に、上記「実ボリュームの動的再配置」機能について説明する。
これは、まず図１８（ａ）に示すように１つの仮想ボリュームＶ１に対応する実ボリュームＲ１がひとつである状態から、一旦、上記ミラーリング機能により図１８（ｂ）に示すように新たな実ボリュームＲ５を追加して実ボリュームを二重にして、追加した実ボリュームＲ５に元々あった実ボリュームＲ１のデータ１をコピーする。その後、図１８（ｃ）に示すように元々あった実ボリュームＲ１を切り離して、追加した実ボリュームＲ５だけを仮想ボリュームＶ１に対応付ける。勿論、ホスト２００からは、このようなユーザデータ１の実際の格納位置の変更は見えない。このようにすることで、ユーザデータ１の実際の存在場所（実ボリューム）を、ホスト２００の業務無停止で変更することができる。
次に、ＩＰ経由のＳＣＳＩアクセス技術（ｉＳＣＳＩ）について説明する。
上記ＳＡＮには多くの利点がある一方で、Ｆｉｂｒｅ  Ｃｈａｎｎｅｌという比較的新しい技術に基づいている為、コストが高いという問題がある。また、接続距離に関しても最高で１０（ｋｍ）という限界がある。この為に考えられたのがＩＰ−ＳＡＮ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ−ＳＡＮ）であり、その代表的な例がｉＳＣＳＩである。
ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ）とは、概略的には、コンピュータとストレージ間のデータ通信を、ＩＰパケットで包んだＳＣＳＩコマンドを使ってＩＰネットワーク上で行うためのプロトコル規格のことであり、現在、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）でドラフト規格が公開されており、標準化作業が進められている。
ｉＳＣＳＩは、ストレージ機器で一般的なＳＣＳＩコマンドを採用したことにより、既存のアプリケーションとの高い互換性を維持したまま、ネットワーク・ストレージへの対応が行えることを特徴としている。
これまでのＳＣＳＩでは、各種制御やデータ転送のためのコマンドとともに物理的な伝送路も規定されていたが、ｉＳＣＳＩではＳＣＳＩのコマンド部分を取り出し、伝送路にＩＰネットワークを採用することで汎用性を高めている。ｉＳＣＳＩを採用することで、現在ＳＡＮの伝送路として一般的に利用されているＦｉｂｒｅ  Ｃｈａｎｎｅｌの代わりとして、安価なイーサネット用のスイッチング・ハブやルータなどを使ってサーバとストレージの接続が行えるようになる。さらに伝送路にＩＰネットワークを用いるため、インターネットを使って遠隔地にあるストレージにデータをバックアップするといった用途にも応用可能である。
ｉＳＣＳＩでは、このように既存のＳＣＳＩ技術とＩＰ／イーサネット技術のメリットを活かした規格化が行われており、ストレージ・プロトコルの新たな標準規格としてサーバ／ストレージ業界の期待が集まっている。
ｉＳＣＳＩを採用した場合の構成例を図１９に示す。図１９では、ローカルサイト２４０内の任意の業務サーバ２５０はＳＣＳＩドライバ２５２、ＮＩＣ（ＬＡＮ）ドライバ２５３を有し、任意の業務プログラム２５１が、例えば接続、切り離し、情報取得、読み出し、書き込み等のコマンドを含むＳＣＳＩデータを発行すると、このＳＣＳＩデータをＩＰパケットにカプセル化して、リモートサイト２６０に送信する。図示の通り、ｉＳＣＳＩプロトコルによるパケットの構成は、従来のＩＰ通信プロトコルによるパケット構成であるＩＰヘッダ部とデータ部より成るが、このデータ部に上記業務プログラム２５１により発行されたＳＣＳＩデータをはめ込む形となる。
リモートサイト２６０側では、ＮＩＣ（ＬＡＮ）ドライバ２７１、ＳＣＳＩドライバ２７２を有する仮想化サーバ２７０等が、受信したｉＳＣＳＩデータをＳＣＳＩデータに変換し直して、実ボリューム２８０に対して要求されたコマンドに応じた処理を実行してローカルサイト２４０に返信する（例えば、データ読み出しであれば、要求されたデータを読み出して、これをローカルサイト２４０に返信する）。
ところで、近年、インターネットの急速な普及や静止画、動画等の大容量データの利用量が急増する等した為、コンピュータネットワーク市場におけるデータ量が急増し、この膨大なデータを記憶する為にデータ記憶装置の増設の機会も急増している。最初から大容量のデータ記憶装置を導入することも考えられるが、初期導入コストが嵩むことになる。また、急激な容量需要に対して、タイムリーに容量を提供すること、所謂ストレージ・オン・デマンドが望まれるようになっている。
このようなストレージ容量の増加・追加に関して、例えば特許文献４、５，６，７記載の発明が提案されている。
特許文献４記載の発明は、現用系と予備系の各系に外部記憶装置を備えた情報処理システムにおいて、外部記憶装置の容量拡張に伴う論理装置の容量の拡張または数の増大を、オンラインで的確に行うことができるようにする手法であり、既に外部記憶装置の容量が拡張された場合を前提にした話であり、外部記憶装置（実ボリューム）自体の容量拡張を管理・制御する話ではない。
特許文献５記載の発明は、データ記憶装置への初期投資の低減化、データ記憶装置の容易な容量増設を実現するものであるが、ここでいう容量増設とは、例えばその図１に示すように、データ記憶装置の使用者のサイト内のデータ記憶装置に、予め、初期導入容量分のディスク装置に加えて、使用者の増大意思以上のディスク装置（増設容量）を搭載しており、使用者が、当該事前に搭載した増設容量の範囲内で、使用領域を容易に拡大できることを意味している。よって、使用者のサイト内のデータ記憶装置の容量が、物理的に増大するものではない。
また、特許文献６記載の発明は、個人用コンピュータの補助記憶装置の容量を仮想的に容易に拡張できるようにする発明であるが、容量拡張といっても、個人用コンピュータが空き容量不足になったら、古いファイルをファイルサーバに転送して、転送済みファイルを削除することで、個人用コンピュータにおける空きエリアを作成することで、容量不足を解決するものである。よって、あくまでも擬似的な容量拡張であり、また個人用コンピュータが空き容量不足となる毎に古いファイルを探してファイルサーバに転送して転送済みファイルを削除するという余計な処理負荷が発生する。更に、個人用コンピュータだけでなくファイルサーバまでもが空き容量不足となった場合には、更に別のファイルサーバを利用することで対応するが、当該別のファイルサーバへの更なるデータ転送という処理負荷が増える。また、サイト内の全てのサーバ（ＬＡＮで接続されたサーバ）を用いても空き容量不足となった場合には対応できない。また、この発明では、データの処理単位がファイルのみであり、ファイルシステムには適用できるが、例えばデータベース管理システムの使用領域も処理できるというものではない。
また、特許文献７記載の発明は、ストレージのレンタルサービスに係わる発明である。このサービスは、ユーザ自らストレージを用意するのではなく、契約に基づいて一定期間（例えば１ヶ月）ストレージサービスプロバイダ（ＳＳＰ）サイトにあるストレージの容量を利用し対価を払うものである。特許文献７記載の発明は、この様なストレージのレンタルサービスに係わり、ストレージ提供者が、ストレージ使用者の過去のストレージ使用量に基づいて、将来のストレージ使用量を予測して、予測結果をストレージ使用者に通知する。ストレージ使用者は、この通知により、使用できるデータ量を拡張したり、縮小する等、契約内容を再設定して最適な契約内容でストレージのレンタルサービスを受けることができる。
上記ストレージのレンタルサービスでは、ユーザ自らストレージを用意するのではなく、ストレージ提供者からレンタルして、レンタル量を支払うが、使用するストレージ容量が非常に大きければ、多額のレンタル量が必要となる。
また、上述した従来技術では、例えば管理者等により容量不足の判断や、容量拡張／縮小（容量追加／減少）を指示する操作を行う必要があり、人的負担が大きかった。
以上のことより、基本的には自サイト内の自前のストレージを用いて、サイト内の各情報処理資源（例えばデータベース、ファイルシステム等）にその時々で必要な容量を割り当てることで対応し、自サイト内の全ストレージを用いても容量不足となった場合に、外部のサーバのストレージを利用し、必要が無くなり次第返却することができるようにすることが望まれ、更にこれらをコンピュータにより自動的に処理することが望まれる。
本発明の課題は、自サイト内の実ボリュームのストレージ仮想化により自サイト内の各情報処理資源に随時必要な容量を割り当てると共に、もし自サイト内の実ボリュームのみでは対応できない（実容量不足）場合には、外部のサーバの実ボリュームを一時的に利用し、必要なくなったら返却することを自動的に行えるストレージ容量管理方法、そのサーバ、記録媒体を提供することである。
【特許文献１】    特開平１１−１５７３２号公報
【特許文献２】    特開平１０−４０１６９号公報
【特許文献３】    特開平６−１９７９６号公報
【特許文献４】    特開平８−２４１２２０号公報
【特許文献５】    特開２００２−３１２６８９号公報
【特許文献６】    特開平９−１８５５３６号公報
【特許文献７】    特開２００２−３１２６９９号公報
【非特許文献１】    ＮＥＴＷＯＲＫ  ＷＯＲＬＤ  ２００２年９月号；ｐ１５４−１５７
【非特許文献２】    コンピュートピア別冊  データストレージ・レポート２００２（株式会社コンピュータ・エージ社）；ｐ２１，２２，２３，３４，３８，３９
【非特許文献３】    日経コンピュータ２００２．５．６；ｐ１３４−１４１「進化するストレージ（前編）」
【非特許文献４】    「ストレージ・ネットワーキング仮想化技術」、根来  元；ＵＮＩＳＹＳ  ＴＥＣＨＮＯＬＯＧＹ  ＲＥＶＩＥＷ  第７４号、ＡＵＧ．２００２
【非特許文献５】    ｈｔｔｐ：／／ｗｗｗ．ｓｎｉａ．ｏｒｇ／ｅｄｕｃａｔｉｏｎ／ｔｕｔｏｒｉａｌｓ／ｖｉｒｔｕａｌｉｚａｔｉｏｎ／上でダウンロードサービス提供されている“ＳＮＩＡ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ  Ｔｕｔｏｒｉａｌ”
【非特許文献６】    ｈｔｔｐ：／／ｗｗｗ．ｆａｌｃｏｎｓｔｏｒ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｃｏｍｐｅｔｉｔｉｖｅ／
【発明の開示】
本発明によるストレージ容量管理方法を実行するサーバは、ストレージ仮想化が行われているサイトにおけるサーバにおいて、自サイト内の実ボリューム全体に関する空き実容量と、自サイト内の各監視対象資源毎の容量割当情報を格納する容量管理情報格納手段と、現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる容量割当制御手段とを有するように構成する。
まず、上記自サイト内は、上記従来のストレージ仮想化が行われている。
そして、上記容量割当制御手段は、自サイト内の各情報処理資源（例えば業務サーバ等）の空き容量を監視しており、予め設定されている所定の閾値等を用いることで、容量追加の必要性を判定する。そして、もし容量追加が必要であると判定したら、基本的には自サイト内の実ボリュームを用いて、その情報処理資源に必要な容量を割り当てる。また、もし自サイト内の実ボリュームでは対応できない場合でも、他サイトの実ボリュームを借用することで対応できる。
また、例えば、上記サーバは、前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する集約手段を更に有するように構成してもよい。
つまり、例えば一時的に容量不足となっても、後に自サイトの容量不足が解消する等して、他サイトから借用し続ける必要がなくなったら、借用していた実ボリュームは返却するようにしてもよい。このように、必要に応じて一時的に借用して後に返却するという柔軟な対応が可能となる。また、これは、自サイトは借用のみで他サイトは貸出のみという意味ではなく、各サイトが相互に借用／貸出する構成としてもよい。これによって、各サイトは、自サイトの空き容量に余裕がある場合には他サイトに貸し出し、余裕がない場合には他サイトから借用することができ、自サイトに余分な空き容量を多めに確保しておく等の必要がなくなる。
また、例えば、前記容量割当制御手段は、前記ストレージ仮想化に基づく「ボリュームの動的容量追加」機能を実行することで前記監視対象資源に追加容量を割り当てることができる。
また、例えば、前記集約手段は、前記ストレージ仮想化に基づく仮想化制御により一時的にミラー状態を構成する「実ボリュームの動的再配置」機能を実行することで、前記データを前記空き領域に集約することができる。
また、例えば、前記借用した他サイトの実ボリュームへのアクセスは、ＩＰを利用したＳＣＳＩプロトコルを用いる。上記従来技術で説明したように、ｉＳＣＳＩを採用することで様々なメリットが得られる。
また、以上の処理は、ほとんど自動化されているので、管理者等が各情報処理資源の空き容量状況を監視して容量増加／減少を指示する必要はなく、人的負担を軽減できる。更に、従来技術で述べた通り、他サイトの実ボリュームを借用すると、通常、借用期間に応じたレンタル料金が掛かるが、本発明では、集約手段によって自動的に、必要が無くなったら借用ボリュームを返却するので、本当に必要な期間だけレンタルでき、不必要に長期間レンタルすることでコスト高になるという事態を回避できる。すなわち、本発明では、ストレージレンタル料金に係わるコスト削減効果も得られる。
【図面の簡単な説明】  本発明は、後述する詳細な説明を、下記の添付図面と共に参照すればより明らかになるであろう。
図１は、本例によるストレージ容量管理手法を実現するシステム全体の概略的な構成図である。
図２は、ローカルサイト側の仮想化サーバによって実行される全体処理の概略フローチャート図である。
図３は、図２のステップＳ１１の処理のイメージを示す図である。
図４は、図２のステップＳ１２の処理のイメージを示す図である。
図５は、図２のステップＳ１３の処理のイメージを示す図である。
図６は、図２のステップＳ１４の処理のイメージを示す図である。
図７（ａ）は、ローカルサイト側の仮想化サーバによる借用先、借用容量等の管理の為の管理データの一例を示す図である。
図７（ｂ）は、リモートサイト側の仮想化サーバによる供給先、供給容量等の管理の為の管理データの一例を示す。
図８（ａ）は、ローカルサイト側の仮想化サーバによる初期設定及び監視処理を示すフローチャート図である。
図８（ｂ）は、リモートサイト側の仮想化サーバによる処理を示すフローチャート図である。
図８（ｃ）は、ローカルサイト側で実ボリュームが追加されたときの仮想化サーバによる処理である。
図９（ａ）は、ステップＳ２６の容量の確認・追加処理の詳細フローチャート図である。
図９（ｂ）は、図９（ａ）の処理において容量の追加要求が行われた場合のステップＳ３３の処理のうちの貸出処理の詳細フローチャート図である。
図１０（ａ）は、ローカル集約表示のフラグをオンする処理を示す図ある。
図１０（ｂ）は、ステップＳ２５のローカル集約処理の詳細フローチャート図である。
図１０（ｃ）は、図１０（ｂ）の処理において領域の返却要求が行われた場合のステップＳ３３の処理のうちの返却処理の詳細フローチャート図である。
図１１は、本例のストレージ容量管理方法を実行するコンピュータ（仮想化サーバ）のハードウェア構成の一例を示す図である。
図１２は、プログラムを記録した記録媒体、プログラムのダウンロードの一例を示す図である。
図１３は、従来の「ボリュームの仮想化」機能を説明する為の図（その１）である。
図１４（ａ）、（ｂ）は、従来の「ボリュームの仮想化」機能を説明する為の図（その２）である。
図１５（ａ）、（ｂ）は、従来の「ボリュームを仮想化と非仮想化の間で出し入れする」機能を説明する為の図である。
図１６は、従来の「ボリュームの動的容量追加」機能を説明する為の図である。
図１７（ａ）、（ｂ）は、従来の「ユーザデータのミラーリング」機能を説明する為の図である。
図１８（ａ）〜（ｃ）は、従来の「実ボリュームの動的再配置」機能を説明する為の図である。
図１９は、従来の「ＩＰ経由のＳＣＳＩアクセス」（ｉＳＣＳＩ）を説明する為の図である。
【発明を実施するための最良の形態】  以下、図面を参照して、本発明の実施の形態について説明する。
まず、ここで、「ボリューム」（実ボリューム、仮想ボリューム）という用語について説明しておく。
一般に、ＳＣＳＩ入出力要求で使うアドレスは、ターゲットポート番号、装置番号（Ｌｏｇｉｃａｌ  Ｕｎｉｔ  Ｎｕｍｂｅｒ）、ブロック番号である。ターゲットポート番号は、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅと呼ばれるポートのチップに埋め込まれた識別番号である。装置番号は、現在では１ポート当り最大２５６個指定可能となっている。ブロック番号は、装置内を固定長のブロックで構成し、そのブロックに付けた番号である。上記「ボリューム」とは上記装置番号に関係し、実ボリュームは上記装置番号のＬＵ（Ｌｏｇｉｃａｌ  Ｕｎｉｔ）のことであり、これを仮想化したものが仮想ボリューム（仮想ＬＵとも呼ばれている）である。
図１は、本例によるストレージ容量管理手法を実現するシステム全体の概略的な構成図である。
図１において、ローカルサイト１０は任意のサイトであり、リモートサイト５０は、ローカルサイト１０側でストレージ容量不足となった場合に容量を供給する他のサイトである。
ローカルサイト１０内には、上記従来のストレージ・ネットワークに対して上記従来のストレージ仮想化が施されており、ローカルサイト１０内のストレージは仮想化サーバ３０が管理している。ローカルサイト１０内の各種アプリケーションサーバ（図では一例として業務サーバ２０）は、ＳＣＳＩプロトコルに従って仮想化サーバ３０にアクセスする構成となっており、業務サーバ２０、仮想化サーバ３０とも、ＳＣＳＩドライバ２２、３１を有する。業務サーバ２０において任意の業務プログラム２１が実行された結果、任意のデータへのアクセス（例えばＲＥＡＤ／ＷＲＩＴＥ等）が必要になると、仮想化サーバ３０を介してストレージにアクセスする。
仮想化サーバ３０は、上記従来技術により、各ストレージを管理し、仮想化制御を行っている。仮想化サーバ３０は、更に、ＮＩＣ（ＬＡＮ）ドライバ３２を備え、ＮＩＣ（ＬＡＮ）ドライバ３２は不図示のＬＡＮに接続しており、ｉＳＣＳＩプロトコルを用いて他のサイト（リモートサイト５０）にアクセスする。
また、仮想化サーバ３０は、容量管理情報格納部３３、容量割当制御部３４、集約部３５を有する。
容量管理情報格納部３３は、少なくとも自サイト（ローカルサイト１０）内の実ボリューム全体に関する空き実容量と、自サイト内の各監視対象資源毎の現在の容量割当情報を格納する。
容量割当制御部３４は、この容量管理情報格納部３３に格納されているデータを参照して、現在の空き容量が予め設定されている所定の閾値未満となった監視対象資源に対して、自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイト（リモートサイト５０）に借用要求を出してその実ボリューム７０を借用して、該監視対象資源に追加容量を割り当てる制御を行う。その後、借用した実ボリューム７０を利用する場合には、上記ｉＳＣＳＩプロトコルを用いてアクセスすることになる。
集約部３５は、上記他サイトの実ボリューム７０を借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、借用していた他サイトの実ボリューム７０は返却する。
一方、リモートサイト５０においてもＮＩＣ（ＬＡＮ）ドライバ６１、ＳＣＳＩドライバ６２を有する仮想化サーバ６０を設ける。仮想化サーバ６０は、ローカルサイト１０への実ボリューム７０の貸出（供給）の管理を行う。
このように、ローカルサイト１０、リモートサイト５０の両方のサイトにおいて仮想化サーバが介在する構成とし、仮想化サーバは、ＳＣＳＩとｉＳＣＳＩの間のプロトコル変換、及び実ボリュームの借用と貸出（供給）の関係を管理している（勿論、従来のストレージ仮想化制御も行っている）。
尚、図１に示す構成は一例であり、これに限るわけではなく、例えばホストが仮想化サーバの機能を備える構成であってもよい。
図２は、ローカルサイト１０の仮想化サーバ３０によって実行される全体処理の概略フローチャート図である。
図２において、仮想化サーバ３０は、任意のときに、実ボリュームを仮想制御下に置く処理を実行する（ステップＳ１１）。その際、上記従来技術の「実ボリュームを仮想化と非仮想化の間で出し入れする機能」を用いることにより、実ボリュームをそのまま仮想化配下に置くことができるので、仮想制御下への移行の為のデータ複写は不要であり、これによって業務停止時間を短くすることができる。尚、ステップＳ１１の処理対象の実ボリュームは、例えば急激に容量不足に陥るおそれのある実ボリューム等である。
上記ステップＳ１１の処理のイメージを、図３に示す。
図３において、仮想化サーバ３０は、管理データ３３（仮想化管理データ）に基づいで、仮想ボリュームと実ボリュームの対応関係の管理を行っている。これ自体は、上記従来技術であるので、特に説明しない。上記ステップＳ１１の処理では、仮想化サーバ３０は、新たに仮想制御下に置いた実ボリュームＲ１と仮想ボリュームＶ１との対応関係を管理データ３３に登録することになる。
その後、任意のときに、任意の情報処理資源への割当容量が不足状態になったら、ローカルサイト１０内の実ボリュームを用いて、上記従来技術の「ボリュームの動的容量追加機能」によって、業務無停止で割当容量を増やす。これは、予め設定・記憶されている仮想化配下の容量追加に関する不図示のポリシー（例えば、残り容量２０（％）を切ったら、容量を４０（％）追加する等のポリシー）に従って、上記割当容量が不足状態になったか否かの判定、及び割当容量を増やす処理を、自動的に実行する（ステップＳ１２）。
上記ステップＳ１２の処理のイメージを図４に示す。
図４において、仮想化サーバ３０は、仮想ボリュームと実ボリュームとの対応関係を示す管理データ３３に基づいて、ストレージ仮想化制御を行っている。尚、図４に示す処理イメージは、従来技術の説明における図１６と略同様であるので、ここでは特に詳細には説明しない。
本例の手法では、上記割当容量の追加は、ローカルサイト１０内の実ボリュームを用いるだけでなく、リモートサイト５０の実ボリューム７０を借用して行うこともできる。特に、ローカルサイト１０内の実ボリュームのみでは割当容量の増加を行うことができない状態になった場合に（実ボリューム不足状態）、一時的に、リモートサイト５０の実ボリューム７０を借用することで対応するものである（ステップＳ１３）。この為に、図５にそのイメージを示すように、ローカルサイト１０側の仮想化サーバ３０は、仮想ボリュームと実ボリュームの対応関係を管理すると共に、管理データ３４（一例を図７（ａ）に示す）によって、ローカルサイト１０内の実ボリュームだけでなく、リモートサイト５０から借用した実ボリューム７０も含めて、各情報処理資源に対する容量割当の管理を行っている。
図５に示す例では、仮想ボリュームＶ１−１、Ｖ１−４はローカルサイト１０内の実ボリュームＲ１，Ｒ４と対応付け、仮想ボリュームＶ１−２、Ｖ１−３はリモートサイト５０内の実ボリュームＲ２，Ｒ３と対応付けて管理している。尚、図５の図上において、各ボリューム内に示す１，２，３，４等の番号は、各ボリュームに格納されるデータを意味する。他の図面についても同様である。
一方、リモートサイト側の仮想化サーバ６０は、管理データ６３（一例を図７（ｂ）に示す）によって、自己の実ボリューム７０の貸し出し管理を行っている。また、両サイト１０−５０間のデータアクセスの為の接続にはｉＳＣＳＩプロトコルを用いる。
尚、図７（ａ）、（ｂ）に示す上記管理データ３４、６３の詳細については、後に説明する。
このように、リモートサイト５０の実ボリューム７０を借用することで容量不足に対応する一方で、その後、ローカルサイト１０側の空き容量に余裕が生じた場合、リモートサイト５０側に退避させていたデータを、ローカルサイト１０側に集約する処理を行う（ステップＳ１４）。これには、上記従来技術の「実ボリュームの動的再配置」を用いる。この「実ボリュームの動的再配置」によれば、複数のリモートサイト５０の実ボリューム７０に分散しているデータであってもローカルサイト１０側に集約させることができる。
上記ステップＳ１４の処理のイメージを図６に示す。
図６は、図５に示すようにローカルサイト１０の実ボリュームＲ１，Ｒ４、リモートサイト５０の実ボリュームＲ２，Ｒ３に各々格納していたデータ１，２，３，４を、ローカルサイト１０側の空き容量に余裕ができる等して新たに確保できた実ボリュームＲ５にコピーする様子を示している。その際、従来技術で説明した「実ボリュームの動的再配置」を実行し、一旦、図１８（ｂ）と同様のミラー状態にした後で、図１８（ｃ）と同様に、元々あった実ボリュームＲ１，Ｒ４は切り離し、リモートサイト５０から借用していた実ボリュームＲ２，Ｒ３は返却して、追加した実ボリュームＲ５だけを仮想ボリュームＶ１（Ｖ１−１〜Ｖ１−４）に対応させる。
図７（ａ）に、上記ローカルサイト１０側の管理データ３４の一例を示す。図７（ｂ）に、上記リモートサイト５０側の管理データ６３の一例を示す。
図７（ａ）において、各ローカルサイト１０（サイト１〜サイトｎ）は、それぞれ、上記管理データ３４として、サイト内共通の情報８０、監視対象資源ｉ毎の情報９０を有する。
サイト内共通の情報８０は、借用先の位置８１、実容量全体８２、空き実容量８３、割当て実容量８４より成る。尚、図７（ａ）の図上に示す算出式や、図７〜図１０の図中に示す（８１）〜（１２３）までの括弧番号は、図７（ａ）、（ｂ）に示す各データ構成に付した参照符号を用いて示している。これにより、図上の説明を簡略化している。例えば図７（ａ）の図上においてサイト内共通の情報８０の右側に算出式「（８２）＝（８３）＋（８４）」と記してあるが、これは「実容量全体８２＝空き実容量８３＋割当て実容量８４」を意味することになる。図７〜図１０の図上に示す括弧番号についても同様である。
上記借用先の位置８１は、実ボリューム７０を借用しているリモートサイト５０のＩＰアドレスである。実容量全体８２は、当該ローカルサイト１０内の実ボリュームの総容量である。空き実容量８３は、当該ローカルサイト１０内の実ボリュームの総空き容量である。割当て実容量８４は、現在当該ローカルサイト１０内の各情報処理資源ｉに対して当該ローカルサイト１０内の実ボリュームから割り当てている容量の総和である。つまり、全ての資源ｉにおける全ての割当領域ｊの長さ１０１の総和である。つまり、
割当て実容量８４＝Σｉ，ｊ（長さ１０１）
である。
監視対象資源ｉ毎の情報９０は、監視対象９１、容量上限９２、現行容量９３、追加閾値９４、追加単位９５、監視間隔９６、及びローカル集約表示９７より成る。更に、ローカルサイト１０内の実ボリュームからその監視対象資源ｉに割り当てている領域に関する情報１００（以下、自サイトからの割当情報１００と記す）、リモートサイト５０から借用している実ボリュームからその監視対象資源ｉに割り当てている領域に関する情報１１０（以下、外部からの割当情報１１０と記す）を有する。
監視対象９１は、監視対象資源ｉ（例えば、ＤＢ（データベース）テーブル、ファイルシステム等）の名称又は識別ＩＤ等である。
容量上限９２は、当該ローカルサイト１０内の実ボリュームとリモートサイト５０から借用する実ボリュームとを併せた容量の上限値（容量拡張の上限値）である。
現行容量９３は、当該ローカルサイト１０内の実ボリュームとリモートサイト５０から借用する実ボリュームとを併せた容量の現在使用値である。つまり、
現行容量９３＝Σｉ（長さ１０１）＋Σｋ（長さ１１１）
である。
追加閾値９４は、容量追加するか否かの判定（後述する）に用いられる閾値である。
追加単位９５は、容量追加すると判定された場合に当該資源ｉに追加する容量の値（例えば２（ＧＢ）追加等）である。
監視時間９６は、後述する空き容量をチェックする処理を行う時間間隔または時刻である。
ローカル集約表示９７は、例えばフラグであり、フラグオンの場合には、後述する「リモートサイトに分散させていた全データをローカルサイトに集める処理」を実行する。
自サイトからの情報１００は、ローカルサイト１０の実ボリュームから現在当該資源ｉに割り当てている記憶領域に関する情報であり、各割当領域ｊ毎に、その先頭アドレス１０２と長さ１０１が格納される。
外部からの情報１１０は、リモートサイト５０の実ボリュームから現在当該資源ｉに割り当てている記憶領域に関する情報であり、各割当領域ｋ毎に、その先頭アドレス１１２と長さ１１１が格納される。
一方、リモートサイト５０側の管理データ６３としては、図７（ｂ）に示すように、貸出先サイト１〜ｎ毎に貸出情報１２０を保持する。
貸出情報１２０は、貸出先の位置１２１、貸出上限１２２、現行貸出容量１２３より成る。貸出先の位置１２１は、貸出先のローカルサイト１０のＩＰアドレスである。貸出上限１２２は、当該貸出先のローカルサイト１０への貸出容量の上限値である。現行貸出容量１２３は、当該貸出先のローカルサイト１０への現在の貸出容量である。
尚、貸出先の位置１２１、貸出上限１２２、借用先の位置８１、監視対象９１、容量上限９２、追加閾値９４、追加単位９５、監視間隔９６は、ポリシーとして事前に設定するが、運用中に変更することもできる。
図８（ａ）は、ローカルサイト１０側の仮想化サーバ３０による初期設定及び監視処理を示すフローチャート図である。
図８（ａ）において、仮想化サーバ３０は、初期設定処理の際には、まず、実容量全体８２、空き実容量８３、及び割当て実容量８４の値を初期化する（ステップＳ２１）。続いて、監視対象資源ｉ毎に、上記の通り、借用先の位置８１、監視対象９１、容量上限９２、追加閾値９４、追加単位９５、監視間隔９６については、ポリシーとして事前に設定する。更に、現行容量９３、ローカル集約表示９７、長さ１０１、先頭アドレス１０２、長さ１１１、先頭アドレス１１２の値を初期化する（ステップＳ２２）。
上記初期設置処理後は、随時、ステップＳ２３〜ステップＳ２６の監視処理を実行する。
まず、監視間隔９６によって規定される監視処理起動時刻が到来するまでは、待機状態となっている。監視処理起動時刻が到来したら、各監視対象資源ｉ毎にステップＳ２４〜Ｓ２６の処理を繰り返し実行し、全ての監視対象資源ｉについての処理が完了したら、次の監視処理起動時刻が到来するまで再び待機状態となる。ステップＳ２４〜Ｓ２６の処理は、まず、処理対象の監視対象資源ｉに関する情報９０の中のローカル集約表示９７を参照して、フラグオンか否かを判定する（ステップＳ２４）。フラグオンである場合には（ステップＳ２４，ＹＥＳ）、ローカル集約処理（詳しくは図１０（ｂ）で説明）を実行する（ステップＳ２５）。フラグオフであった場合には（ステップＳ２４，ＮＯ）、容量の確認・追加処理（詳しくは図９（ａ）で説明）を実行する（ステップＳ２６）。
図８（ｂ）は、リモートサイト５０側の仮想化サーバ６０による処理を示すフローチャート図である。
図８（ｂ）において、仮想化サーバ６０は、まず、貸出先の位置１２１、貸出上限１２２については、ポリシーとして事前に設定する（ステップＳ３１）。また、現行貸出容量１２３の値を初期化する（ステップＳ３２）。
以上、初期設定処理を行った後は、各ローカルサイト１０からの貸出要求に応じて貸出処理（詳しくは図９（ｂ）で説明）を実行し、あるいは各ローカルサイト１０からの返却要求に応じて返却処理（詳しくは図１０（ｃ）で説明）を実行する（ステップＳ３３）。
図８（ｃ）は、ローカルサイト側で実ボリュームが追加される場合にストレージ管理者が起動することによって実行される処理を示す図である。ローカルサイトの実ボリュームを当仮想化管理の配下に置く場合に、ストレージ管理者が個々の実ボリュームを指定して当該処理を起動する。この処理では、ステップＳ２６において追加された容量分を、実容量全体８２と空き実容量８３の両方に加算する（ステップＳ４１）。
図９（ａ）は、上記ステップＳ２６の容量の確認・追加処理の詳細フローチャート図である。この処理は、容量割当制御部３４によって実行される。
図９（ｂ）は、図９（ａ）の処理において容量の追加要求が行われた場合のステップＳ３３の処理のうちの貸出処理の詳細フローチャート図である。
ローカルサイト１０側の仮想化サーバ３０は、上記ステップＳ２４の処理においてローカル集約表示９７がフラグオンではなかった場合に、図９（ａ）に示す処理を実行する。
仮想化サーバ３０は、まず、監視対象資源ｉの空き容量を得る（ステップＳ５１）。すなわち、監視対象のデータベース又はファイルシステムの空き容量を得る。取得方法は、例えばデータベース又はファイルシステムに固有の容量管理インタフェース（コマンド等）を使用する方法等がある。
続いて、取得した空き容量が追加閾値９４より小さく（ステップＳ５２，ＹＥＳ）且つ「現行容量９３＋追加単位９５＜容量上限９２」である場合すなわち所定単位の容量追加を行っても容量拡張の上限値を超えない場合には（ステップＳ５３，ＹＥＳ）、ステップＳ５４以降の処理に移り、そうでなければ当該処理は終了する。
次に、「追加単位９５＜空き実容量８３」であるか否かを判定する（ステップＳ５４）。すなわち、自サイト内の実ボリュームによって容量追加に対応できるか否かを判定する。自サイト内で対応できる場合には（ステップＳ５４，ＹＥＳ）、ローカルサイト１０内の実ボリュームの空き領域から、追加単位９５分の容量を獲得し（ステップＳ５５）、獲得した領域の先頭アドレスと長さを、それぞれ、割当領域ｊの先頭アドレス１０２、長さ１０１に格納する（ステップＳ５６）。そして、空き実容量８３、割当て実容量８４を、それぞれ、以下の通り更新する（ステップＳ５７）。
空き実容量８３＝空き実容量８３−追加単位９５
割当て実容量８４＝割当て実容量８４＋追加単位９５
また、当該処理対象の資源ｉに関する現行容量９３の値も、以下の通り更新する。
現行容量９３＝現行容量９３＋追加単位９５
最後に、処理対象資源ｉに容量追加して（ステップＳ５９）、本処理は終了する。尚、ステップＳ５９の処理は、上記従来の「ボリュームの動的容量追加」の処理を実行するものである。
一方、上記ステップＳ５４の判定において、自サイト内の実ボリュームによって容量追加に対応できないと判定された場合には（ステップＳ５４，ＮＯ）、リモートサイト５０から借用することになる。
すなわち、借用先の位置８１によって示されるリモートサイト５０に対して、追加単位９５分の容量の借用を要求する（ステップＳ６０）。
リモートサイト５０側では、この借用要求を受信すると（ステップＳ７１）、まず「追加単位９５＋現行貸出容量１２３≦貸出上限１２２」であるか否かを判定する（ステップＳ７２）。すなわち、要求元のローカルサイト１０に現在貸し出している容量に、要求された追加単位９５分を加えても、当該ローカルサイト１０への貸出容量の上限値を越えないか否かを判定し、もし上限値を越えてしまう場合には（ステップＳ７２，ＮＯ）、要求元のローカルサイト１０に対して“貸出上限を超えてしまうので、これ以上貸出し出来ない（失敗）”旨を返答する（ステップＳ７６）。
一方、追加単位９５分を更に貸し出しても貸出上限１２２を越えない場合には（ステップＳ７２，ＹＥＳ）、自己の実ボリュームから追加単位９５分の空き領域を獲得すると共に（ステップＳ７３）、現行貸出容量１２３の値を更新、すなわち「現行貸出容量１２３＝現行貸出容量１２３＋追加単位９５」とし（ステップＳ７４）、貸出位置（獲得した記憶領域の先頭アドレス、長さ）を、要求元のローカルサイト１０に返信する（ステップＳ７５）。
ローカルサイト１０側では、上記ステップＳ７６による返答、すなわち失敗の返答を受けた場合には（ステップＳ６１，ＮＯ）、借用上限超えの処理を行って（ステップＳ６３）、本処理を終了する。ステップＳ６３の処理は、例えば、そのリモートサイトからはそれ以上借用できないことを記録することで、その後は、そのリモートサイトには容量を要求しないようにする処理である（但し、返却後は、再び借用要求を出せるようにしてもよい）。あるいは、ステップＳ６３の処理は、ローカルサイトのストレージ管理者の端末に対して、「借用上限超え」を知らせるメッセージを出力する処理であってもよい。このメッセージを見たストレージ管理者は、以下の対応をとることで、ローカルサイト１０の空き容量不足を解消する。
・不要なデータを削除して空き容量を増やす。
・新たに実ボリュームを追加して、空き状態の実ボリュームを作る（尚、その際、ストレージ管理者が起動することによって図８（ｃ）の処理が実行されるようにしてもよい）。
・複数の実ボリュームにまばらに割り当てられた小さなデータ群を、１つの実ボリュームに集めることで、空き状態の実ボリュームを作る。
・アクセス頻度の低い実ボリュームにあるデータを二次媒体（磁気テープやＤＶＤ等）に退避させて、実ボリュームを空き状態にする。
一方、上記ステップＳ７５による返答、すなわち借用成功して貸出位置のデータが返信されてきた場合には（ステップＳ６１，ＹＥＳ）、当該貸出位置データ（獲得した記憶領域の先頭アドレス、長さ）を、外部からの割当情報１１０の先頭アドレス１１２、長さ１１１に格納し（ステップＳ６２）、続いて上記ステップＳ５８、Ｓ５９の処理を実行する。
図１０（ａ）〜（ｃ）は、図８（ａ）のステップＳ２５のローカル集約処理に係わる各処理を示すフローチャート図である。
図１０（ａ）は、ローカル集約表示９７のフラグをオンする処理（ステップＳ８１）を示す。ステップＳ８１の処理は、例えばユーザ等が任意の資源ｉを指定して、その全容量をローカルサイト１０側に集約する旨の指示を入力した場合に実行される。
図１０（ｂ）は、上記ステップＳ２５のローカル集約処理の詳細フローチャート図である。この処理は、集約部３５によって実行される。
図１０（ｃ）は、図１０（ｂ）の処理において領域の返却要求が行われた場合のステップＳ３３の処理のうちの返却処理の詳細フローチャート図である。
ローカルサイト１０側の仮想化サーバ３０は、上記ステップＳ２４の処理においてローカル集約表示９７がフラグオンであった場合に、図１０（ｂ）に示す処理を実行する。
まず、「現行容量９３＜空き実容量８３」であるか否かを判定する（ステップＳ９１）。すなわち、空き実容量９３が、ローカルサイト１０とリモートサイト５０を併せた資源ｉの現在の使用容量を上回るか否かを判定する。つまり、ローカルサイト１０側への集約を行うのに必要な空き容量があるか否かを判定するものであり、もし必要な空き容量がない場合には（ステップＳ９１，ＮＯ）、本処理は終了する。
もし、集約に必要な空き容量がある場合には（ステップＳ９１、ＹＥＳ）、ローカルサイト１０内の実ボリュームから、現行容量９３分の容量を獲得する（ステップＳ９２）。つまり、現在ローカルサイト１０とリモートサイト５０に分散配置しているデータを移動させる移行先の記憶領域を確保しておく。また、これに伴って、一旦、空き実容量８３、割当て実容量８４の値を更新しておく（ステップＳ９３）。すなわち、
空き実容量８３＝空き実容量８３−現行容量９３
割当て実容量８４＝割当て実容量８４＋現行容量９３
としておく。
続いて、上記獲得した移行先の記憶領域の先頭アドレス及び長さを、自サイトからの割当情報１００の先頭アドレス１０２、長さ１０１にそれぞれ設定し（ステップＳ９４）、移行先ボリュームを作成する（ステップＳ９５）。
そして、上記従来技術の「実ボリュームの動的再配置」処理を実行することで、現在ローカルサイト１０とリモートサイト５０に分散配置しているデータを、上記ステップＳ９２で獲得した記憶領域に移動させる。つまり、データを集約する（ステップＳ９６）。
このようにしてデータを新たな記憶領域に移したら、このデータの為にリモートサイト５０から借用していた記憶領域を返却する。すなわち、当該借用していた記憶領域に関する割当領域ｋの先頭アドレス１１２と長さ１１１を付加した返却要求を、借用先の位置８１のＩＰアドレスのリモートサイト５０へと送信する（ステップＳ９７）。
リモートサイト５０側の仮想化サーバ６０は、この返却要求を受信すると（ステップＳ１１１）、この返却要求に付加されている上記先頭アドレス１１２と長さ１１１によって示される記憶領域を空き状態にする（ステップＳ１１２）。続いて、返却要求したローカルサイト１０に関する貸出情報１２０における現行貸出容量１２３の値を「現行貸出容量１２３＝現行貸出容量１２３−返却された長さ１１１」により更新する（ステップＳ１１３）。
そして、返却処理完了を、返却要求したローカルサイト１０に通知する（ステップＳ１１４）。
この通知を受けたローカルサイト１０の仮想化サーバ３０は、外部からの割当情報１１０の中で上記返却した割当領域ｋの情報を削除する（ステップＳ９８）。また、上記新たな記憶領域に移動させたデータの移動元の記憶領域のうち、リモートサイト５０の分は上記の通り返却したが、ここでローカルサイト１０の分を空き領域とする（ステップＳ９９）。これに伴い、空き領域とした記憶領域に関する割当領域ｊの情報を削除する。また、空き実容量８３、割当て実容量８４の値を更新する（ステップＳ１００）。すなわち、
空き実容量８３＝空き実容量８３＋移行先の割当領域ｊの長さ１０１
割当て実容量８４＝割当て実容量８４−移行先の割当領域ｊの長さ１０１
としておく。
最後に、ローカル集約表示９７をフラグオフして（ステップＳ１０１）、本処理を終了する。
以上説明したように、本例のストレージ容量管理方法、当該方法を実行するコンピュータ（サーバ等）、当該方法をコンピュータに実行させる為のプログラム、当該プログラムを記録した記録媒体等によれば、各情報処理資源において容量追加が必要となった場合、基本的には自サイト内の実ボリュームを割り当てて対応し、自サイト内では対応できない場合には他サイトから借用することで対応できる。また、後に自サイトの容量不足が解消する等して、他サイトから借用し続ける必要がなくなったら、借用していた実ボリュームは返却するようにしてもよい。
これによって、例えば、容量需要の急増等を考慮して予め自サイト内に余分な実ボリュームを用意しておかなくても、容量不足になったときには他サイトからレンタルすれば済む。また、これら一連の処理は、ほとんど自動化されているので、管理者等が各情報処理資源の空き容量状況を監視して容量増加／減少を指示する必要はなく、人的負荷が軽減できる。また、他サイトの実ボリュームを借用すると、通常、借用期間に応じたレンタル料金が掛かるが、本例の手法では、必要が無くなったら自動的に借用ボリュームを返却するので、本当に必要な期間だけレンタルでき、不必要に長期間レンタルすることでコスト高になるという事態を回避できる。すなわち、ストレージのレンタル料金に係わるコスト削減効果も得られる。
また、上述した説明では、ローカルサイト１０側が借用のみ、リモートサイト側５０が貸し出しのみを行う構成を示したが、これに限らず、各サイトが相互に借用／貸出する構成としてもよい。これによって、各サイトは、自サイトの空き容量に余裕がある場合には他サイトに貸し出し、余裕がない場合には他サイトから借用することができ、自サイトに余分な空き容量を多めに確保しておく等の必要がなくなる。
尚、上述した説明では、ｉＳＣＳＩプロトコルを用いたが、これに限るものではなく、他の“ＩＰを利用したＳＣＳＩプロトコル”（例えばＳＡＮ−ＩＰ、ＦＣ−ＩＰ、ｉＦＣＰ等）であってもよい。
図１１は、上記ストレージ容量管理方法を実行するコンピュータ１３０（仮想化サーバ３０、６０）のハードウェア構成の一例を示す図である。
同図に示すコンピュータ１３０は、ＣＰＵ１３１、メモリ１３２、入力装置１３３、出力装置１３４、外部記憶装置１３５、媒体駆動装置１３６、ネットワーク接続装置１３７等を有し、これらがバス１３８に接続された構成となっている。同図に示す構成は一例であり、これに限るものではない。
ＣＰＵ１３１は、当該コンピュータ１３０全体を制御する中央処理装置である。
メモリ１３２は、プログラム実行、データ更新等の際に、外部記憶装置１３５（あるいは可搬型記録媒体１３９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１３１は、メモリ１３２に読み出したプログラム／データを用いて、上記図８〜図１０等に示すストレージ容量管理方法を実現する処理を実行する。
入力装置１３３は、例えばキーボード、マウス、タッチパネル等である。
出力装置１３４は、例えばディスプレイ、プリンタ等である。
外部記憶装置１３５は、例えば磁気ディスク装置、光ディスク装置、光磁気ディスク装置等であり、上記ストレージ容量管理方法の処理をコンピュータ１３０に実行させる為のプログラム／データ（図８〜図１０の処理プログラム、図７のデータ等）が格納されている。
媒体駆動装置１３６は、可搬型記録媒体１３９に記憶されているプログラム／データ等を読み出す。可搬型記録媒体１３９は、例えば、ＦＤ（フレキシブルディスク）、ＣＤ−ＲＯＭ、メモリカード、ＤＶＤ、光磁気ディスク等である。
ネットワーク接続装置１３７は、ネットワークに接続して、外部の情報処理装置とプログラム／データ等の送受信を可能にする構成である。
図１２は、上記プログラムを記録した記録媒体、プログラムのダウンロードの一例を示す図である。
図示のように、上記本発明の機能を実現するプログラム／データが記憶されている可搬型記録媒体１３９からコンピュータ１３０側に読み出して、メモリ１３２に格納し実行するものであってもよいし、また、上記プログラム／データは、ネットワーク接続装置１３７により接続しているネットワーク１５０（インターネット等）を介して、外部のサーバ１４０の記憶部１４１に記憶されているプログラム／データをダウンロードするものであってもよい。
また、本発明は、装置／方法に限らず、上記プログラム／データを格納した記録媒体（可搬型記録媒体１３９等）自体として構成することもできるし、上記プログラム自体として構成することもできる。
【産業上の利用の可能性】
以上、詳細に説明したように、発明の自サイト内の実ボリュームのストレージ仮想化により自サイト内の各情報処理資源に随時必要な容量を割り当てると共に、もし自サイト内の実ボリュームのみでは対応できない（実容量不足）場合には、外部のサーバの実ボリュームを一時的に利用し、必要なくなったら返却することを自動的に行える。よって、自サイト内の実ボリュームを十分に利用でき、且つ外部サイトの実ボリュームを借用することで急激な容量需要等に対しても対応できると共に必要がなくなったら借用した容量を返却する等、柔軟な対応ができる。更にこれら自サイト内の実ボリュームを各情報処理資源に必要量割当てること、自サイト内で対応できない状況にあることを判断すること、外部サイトから借用することを、コンピュータにより自動的に処理できるので、ユーザが判断／操作する手間が掛からない。
【図１】
2005001700.tif 000003
【図２】
2005001700.tif 000004
【図３】
2005001700.tif 000005
【図４】
2005001700.tif 000006
【図５】
2005001700.tif 000007
【図６】
2005001700.tif 000008
【図７】
2005001700.tif 000009
【図８】
2005001700.tif 000010
【図９】
2005001700.tif 000011
【図１０】
2005001700.tif 000012
【図１１】
2005001700.tif 000013
【図１２】
2005001700.tif 000014
【図１３】
2005001700.tif 000015
【図１４】
2005001700.tif 000016
【図１５】
2005001700.tif 000017
【図１６】
2005001700.tif 000018
【図１７】
2005001700.tif 000019
【図１８】
2005001700.tif 000020
【図１９】
2005001700.tif 000021
【手続補正書】
【提出日】平成17年11月9日(2005.11.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ストレージ仮想化が行われているサイトにおけるサーバにおいて、
自サイト内の実ボリューム全体に関する空き実容量と、自サイト内の各監視対象資源毎の容量割当情報を格納する容量管理情報格納手段と、
現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる容量割当制御手段と、
を有することを特徴とするサーバ。
【請求項２】
前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する集約手段を更に有することを特徴とする請求項１記載のサーバ。
【請求項３】
前記容量割当制御手段は、前記ストレージ仮想化に基づく「ボリュームの動的容量追加」機能を実行することで前記監視対象資源に追加容量を割り当てることを特徴とする請求項１記載のサーバ。
【請求項４】
前記集約手段は、前記ストレージ仮想化に基づく仮想化制御により一時的にミラー状態を構成する「実ボリュームの動的再配置」機能を実行することで、前記データを前記空き領域に集約することを特徴とする請求項２記載のサーバ。
【請求項５】
前記借用した他サイトの実ボリュームへのアクセスは、ＩＰを利用したＳＣＳＩプロトコルを用いることを特徴とする請求項１〜４の何れかに記載のサーバ。
【請求項６】
ストレージ仮想化が行われているサイトにおけるストレージ容量管理方法であって、
自サイト内の任意の監視対象資源の容量拡張が必要と判定した場合、自サイト内の実ボ
リュームによって該監視対象資源への割当容量を増加できるか否かを判定し、
自サイト内の実ボリュームによって該監視対象資源への割当容量を増加できると判定した場合には、自サイト内の実ボリュームを用いて該監視対象資源への割当容量を拡張し、
自サイト内の実ボリュームによって該監視対象資源の割当容量を増加できないと判定した場合には、他サイトの実ボリュームを借用することを特徴とするストレージ容量管理方法。
【請求項７】
前記他サイトの実ボリュームの借用後、自サイトの空き実容量に余裕ができた場合には、該他サイトの実ボリュームに格納したデータを自サイトに集約して、前記他サイトの実ボリュームは返却することを特徴とする請求項６記載のストレージ容量管理方法。
【請求項８】
前記借用した他サイトの実ボリュームへのアクセスは、ＩＰを利用したＳＣＳＩプロトコルを用いることを特徴とする請求項６または７記載のストレージ容量管理方法。
【請求項９】
コンピュータに、
仮想ボリュームと実ボリュームの対応関係を規定する仮想化管理データを格納する機能と、
自サイト内の実ボリューム全体に関する全実容量、空き実容量、割当て実容量と、自サイト内の各監視対象資源毎に、少なくともその監視対象資源の現在の空き容量を格納する機能と、
前記現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる機能と、
を実現させるためのプログラム。
【請求項１０】
前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する機能を更に前記コンピュータに実現させるための請求項９記載のプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージ・ネットワークに対するストレージ仮想化が施されたシステムに係わり、特に各情報処理資源に対する容量の割当て、容量追加を自動的に行う制御方法等に関する。
【背景技術】
【０００２】
近年、ストレージ技術分野に関して、ストレージ・ネットワーク技術により、ネットワーク化とインテリジェト化が進んでいる。サーバへの従属から脱却し、サーバプラットフォームから独立したストレージは、今や自立したコンピューティング・プラットフォームへと進化しつつある。
【０００３】
このようなストレージ・ネットワーク技術として、従来、例えばＳＡＮ（Storage Area Network）やＮＡＳ（Network Attached Storage）等が知られている。ＳＡＮは、主にＦｉｂｒｅ  Ｃｈａｎｎｅｌ技術を使って、サーバとストレージ間をつなぐ専用ネットワークを構築するものである。クライアント−サーバ間を結ぶＬＡＮとは別に、サーバとストレージ間をＳＡＮとして結ぶ構成となっており、複数のストレージ装置を単一のシステムとしてイメージすることで一元管理する。ストレージをサーバから独立させることにより、ディスクミラーによるデータ保護、ＬＡＮフリー／サーバレス・バックアップ、ディザスタ・リカバリといったストレージ独自のソリューションの導入が可能になった。Fibre Channel のハブやスイッチを使って、ＬＡＮ同様に拡張性の高い柔軟なネットワークを構築することが可能であり、ストレージの許容量、管理等の向上をはかることができる。
【０００４】
また、ＮＡＳ（Network Attached Storage）は、ファイルサーバを接続するようにＩＰネットワークに接続して使用するネットワークストレージである。ＳＡＮではクライアントがサーバ経由でしかストレージにアクセスできないのに対して、ＮＡＳではサーバのみならずクライアントからもストレージに直接アクセスすることができる。
【０００５】
更に近年、上記ストレージ・ネットワークに対して、ストレージ仮想化（Storage Virtualization）技術が登場してきている。従来のＳＡＮ（Storage Area Network）やＮＡＳ（Network Attached Storage）がストレージの物理的統合であったのに対して、ストレージ仮想化はストレージを論理的に統合する。
【０００６】
上記ＳＡＮは、ストレージをサーバから分離独立させ、全ファイルを物理的に集約した。しかし、ＳＡＮを構成するストレージ上のデータは、論理的には相変わらずサーバのＯＳやアプリケーションと密接に関係している。ストレージ上にあるさまざまなサーバのデータは、物理的には一箇所に存在しているが、論理的には一つの管理単位として全く統合されていない。ストレージ・ネットワークとしてのＳＡＮの機能をより高めるためには、ＳＡＮを構成するストレージ上のデータを論理的にもサーバから独立させ、ストレージ装置側で物理的かつ論理的に一括して制御し管理できるようにする必要がある。そのための技術が、ストレージ仮想化技術である。
【０００７】
ストレージ仮想化では、サーバのＯＳやアプリケーションから見たストレージの論理ビューとストレージ内の物理的インプリメンテーションを分離する。つまり、外側から見たストレージの見え方とストレージの物理的な存在を分離する。ディスク本体は、かなり以前から仮想化されている。ＲＡＩＤ技術によって、シリンダ、トラック、ディスクのブロック配置といった個々のディスク装置レベルで仮想化が実現された結果、ハードウェアレベルでのミラーリングやストライピングが実現された。ストレージ仮想化技術は、同様なことをストレージ・ネットワーク全体で実現する。
【０００８】
ここで、仮想化ということに関しては、仮想メモリ（ページング処理、スワッピング処理）が非常に有名であるが、上記の通り、ストレージ仮想化は、このような仮想メモリの技術とは全く異なるものである。従って、例えば、特許文献１、特許文献２、特許文献３等のように、仮想メモリ（ページング処理またはスワッピング処理あるいは両方）に係わる発明は、本発明とは全く関係のない技術分野の発明である。
【０００９】
上記ストレージ仮想化技術に関して、既に以下に図１３〜図１８で説明する機能が使用できるようになっている。すなわち、以下に図１３、図１４で説明する「ボリュームの仮想化」機能、図１５で説明する「ボリュームを仮想化と非仮想化の間で出し入れする」機能、図１６で説明する「ボリュームの動的容量追加」機能、図１７で説明する「ユーザデータのミラーリング」機能、図１８で説明する「実ボリュームの動的再配置」機能が知られている。また、近年、ＩＰ経由のＳＣＳＩアクセス技術（ｉＳＣＳＩ）が知られている
。尚、これらの既存技術は、例えば非特許文献１、非特許文献２、非特許文献３、非特許文献４、非特許文献５等に紹介されている。また、既にこれらの機能を備えた製品（例えばＩＰＳｔｏｒ等）が発売されている。尚、ＩＰＳｔｏｒについては、例えば非特許文献６のホームページ上で紹介されている。
【００１０】
図１３にそのイメージを示す「ボリュームの仮想化」機能は、ストレージ仮想化技術において当たり前の機能であるが、一応説明するならば、当該機能によって、ホスト２００から見えるボリュームを抽象化して仮想ボリュームとし、この仮想ボリュームに対応するデータが実際に存在する実ボリュームの所在や構成は、ホスト２００からは見えなくしている。よって、図１３に示すように、ホスト２００から見える１つの仮想ボリュームＶ１（例えば２ＧＢ）は、実際には２つの実ボリュームＲ１、Ｒ２（例えば各々、１ＧＢずつ）より成っているかもしれない。当然、その逆も有り得る。尚、仮想ボリュームと実ボリュームとの対応関係等は不図示の仮想化サーバがその管理情報に基づいて一元管理しており、ホスト２００は、任意のデータが必要な場合、仮想化サーバを介して、データの取得等を行う。尚、仮想化サーバは、独立した１つのサーバとして構成される例に限らず、例えばホスト２００自体が仮想化サーバの機能を有する構成で、ホスト２００内のアプリケーション等が当該仮想化サーバ機能を介してストレージにアクセスするものであってもよい。
【００１１】
また、上記仮想ボリュームと実ボリュームとの対応関係を示す管理情報は、例えば図１４（ａ）に示すようにユーザデータを格納する実ボリュームＲ１，Ｒ２，Ｒ３上に置いてもよいし、図１４（ｂ）に示すようにユーザデータを格納する実ボリュームＲ１，Ｒ２，Ｒ３とは異なるボリューム２２０にまとめて管理情報を配置してもよい。
【００１２】
次に、上記「ボリュームを仮想化と非仮想化の間で出し入れする」機能について説明する。この機能によれば、図１５（ａ）、（ｂ）に示すように、実ボリュームＲ１上のユーザデータを他の実ボリュームに移すこと（コピー）をしなくてもそのまま仮想配下に置いて使用することができるし（その際、管理情報２２０に仮想ボリュームＶ１と実ボリュームＲ１との対応関係を登録する）、その逆に仮想化された状態から非仮想化の状態に戻すこともできる。
【００１３】
次に、上記「ボリュームの動的容量追加」機能について説明する。
ホストから直接実ボリュームを使用しているときにその実ボリュームの容量を増やすには、ホストの運転を停止して、必要な容量の別の実ボリュームを用意して、この別の実ボリュームにユーザデータをコピーし、その後ホストの業務を再開しなければならない。しかし、仮想ボリュームであれば、ホストを停止することなく容量追加を実現できる。そのイメージを図１６に示す。図１６には、仮想ボリュームＶ１の容量は、例えば最初は実ボリュームＲ１に対応するＶ１−１の分の容量のみであったが、その後、実ボリュームＲ２，Ｒ３，Ｒ４に対応するＶ１−２、Ｖ１−３、Ｖ１−４の分の容量を次々と動的に追加していくイメージを示す。図１６では、例えば仮想化サーバ２３０が、仮想ボリュームと実ボリュームとの対応関係を示す管理データ２３１を保持して仮想化制御を行っており、上記容量追加の際には、実ボリュームＲ２，Ｒ３，Ｒ４と仮想ボリュームＶ１（Ｖ１−２、Ｖ１−３、Ｖ１−４）との対応関係を、新たに管理データ２３１に登録することになる。
【００１４】
次に、上記「ユーザデータのミラーリング」機能について説明する。
既によく知られているように、ストレージ仮想化においては、ミラーリングを構成することができる。つまり、図１７（ａ）に示すようにストレージ仮想化した状態から、図１７（ｂ）に示すようにホスト２００から見えるひとつの仮想ボリュームＶ１に対応する実ボリュームを二重にして、２つの実ボリュームＲ１，Ｒ５上に全く同じデータ１を置くことで、一方の実ボリュームに障害が発生しても、他方の実ボリュームを用いることで、ホストの業務が停止することを防止できる。
【００１５】
次に、上記「実ボリュームの動的再配置」機能について説明する。
これは、まず図１８（ａ）に示すように１つの仮想ボリュームＶ１に対応する実ボリュームＲ１がひとつである状態から、一旦、上記ミラーリング機能により図１８（ｂ）に示すように新たな実ボリュームＲ５を追加して実ボリュームを二重にして、追加した実ボリュームＲ５に元々あった実ボリュームＲ１のデータ１をコピーする。その後、図１８（ｃ）に示すように元々あった実ボリュームＲ１を切り離して、追加した実ボリュームＲ５だけを仮想ボリュームＶ１に対応付ける。勿論、ホスト２００からは、このようなユーザデータ１の実際の格納位置の変更は見えない。このようにすることで、ユーザデータ１の実際の存在場所（実ボリューム）を、ホスト２００の業務無停止で変更することができる。
【００１６】
次に、ＩＰ経由のＳＣＳＩアクセス技術（ｉＳＣＳＩ）について説明する。
上記ＳＡＮには多くの利点がある一方で、Fibre Channelという比較的新し い技術に基づいている為、コストが高いという問題がある。また、接続距離に関しても最高で１０(km)という限界がある。この為に考えられたのがＩＰ−ＳＡＮ(Internet Protocol-SAN)であり、その代表的な例がｉＳＣＳＩである。
【００１７】
ｉＳＣＳＩ(Internet Small Computer Systems Interface)とは、概略的には、コンピュータとストレージ間のデータ通信を、ＩＰパケットで包んだSCSIコマンドを使ってＩＰネットワーク上で行うためのプロトコル規格のことであり、現在、IETF（Internet Engineering Task Force）でドラフト規格が公開されて おり、標準化作業が進められている。
【００１８】
ｉＳＣＳＩは、ストレージ機器で一般的なＳＣＳＩコマンドを採用したことにより、 既存のアプリケーションとの高い互換性を維持したまま、ネットワーク・ストレージへの対応が行えることを特徴としている。
【００１９】
これまでのＳＣＳＩでは、各種制御やデータ転送のためのコマンドとともに物理的な伝送路も規定されていたが、ｉＳＣＳＩではＳＣＳＩのコマンド部分を取り出し、 伝送路にＩＰネットワークを採用することで汎用性を高めている。ｉＳＣＳＩを採用することで、現在ＳＡＮの伝送路として一般的に利用されているFibre Channelの代わりとして、安価なイーサネット用のスイッチング・ハブやルータなどを使ってサーバとストレージの接続が行えるようになる。さらに伝送路にＩＰネットワークを用いるため、インターネットを使って遠隔地にあるストレージにデータをバックアップするといった用途にも応用可能である。
【００２０】
ｉＳＣＳＩでは、このように既存のＳＣＳＩ技術とＩＰ／イーサネット技術のメリッ トを活かした規格化が行われており、ストレージ・プロトコルの新たな標準規格としてサーバ／ストレージ業界の期待が集まっている。
【００２１】
ｉＳＣＳＩを採用した場合の構成例を図１９に示す。図１９では、ローカルサイト２４０内の任意の業務サーバ２５０はＳＣＳＩドライバ２５２、ＮＩＣ（ＬＡＮ）ドライバ２５３を有し、任意の業務プログラム２５１が、例えば接続、切り離し、情報取得、読み出し、書き込み等のコマンドを含むＳＣＳＩデータを発行すると、このＳＣＳＩデータをＩＰパケットにカプセル化して、リモートサイト２６０に送信する。図示の通り、ｉＳＣＳＩプロトコルによるパケットの構成は、従来のＩＰ通信プロトコルによるパケット構成であるＩＰヘッダ部とデータ部より成るが、このデータ部に上記業務プログラム２５１により発行されたＳＣＳＩデータをはめ込む形となる。
【００２２】
リモートサイト２６０側では、ＮＩＣ（ＬＡＮ）ドライバ２７１、ＳＣＳＩドライバ２７２を有する仮想化サーバ２７０等が、受信したｉＳＣＳＩデータをＳＣＳＩデータに変換し直して、実ボリューム２８０に対して要求されたコマンドに応じた処理を実行してローカルサイト２４０に返信する（例えば、データ読み出しであれば、要求されたデータを読み出して、これをローカルサイト２４０に返信する）。
【００２３】
ところで、近年、インターネットの急速な普及や静止画、動画等の大容量データの利用量が急増する等した為、コンピュータネットワーク市場におけるデータ量が急増し、この膨大なデータを記憶する為にデータ記憶装置の増設の機会も急増している。最初から大容量のデータ記憶装置を導入することも考えられるが、初期導入コストが嵩むことになる。また、急激な容量需要に対して、タイムリーに容量を提供すること、所謂ストレージ・オン・デマンドが望まれるようになっている。
【００２４】
このようなストレージ容量の増加・追加に関して、例えば特許文献４，５，６，７記載の発明が提案されている。
特許文献４記載の発明は、現用系と予備系の各系に外部記憶装置を備えた情報処理システムにおいて、外部記憶装置の容量拡張に伴う論理装置の容量の拡張または数の増大を、オンラインで的確に行うことができるようにする手法であり、既に外部記憶装置の容量が拡張された場合を前提にした話であり、外部記憶装置（実ボリューム）自体の容量拡張を管理・制御する話ではない。
【００２５】
特許文献５記載の発明は、データ記憶装置への初期投資の低減化、データ記憶装置の容易な容量増設を実現するものであるが、ここでいう容量増設とは、例えばその図１に示すように、データ記憶装置の使用者のサイト内のデータ記憶装置に、予め、初期導入容量分のディスク装置に加えて、使用者の増大意思以上のディスク装置（増設容量）を搭載しており、使用者が、当該事前に搭載した増設容量の範囲内で、使用領域を容易に拡大できることを意味している。よって、使用者のサイト内のデータ記憶装置の容量が、物理的に増大するものではない。
【００２６】
また、特許文献６記載の発明は、個人用コンピュータの補助記憶装置の容量を仮想的に容易に拡張できるようにする発明であるが、容量拡張といっても、個人用コンピュータが空き容量不足になったら、古いファイルをファイルサーバに転送して、転送済みファイルを削除することで、個人用コンピュータにおける空きエリアを作成することで、容量不足を解決するものである。よって、あくまでも擬似的な容量拡張であり、また個人用コンピュータが空き容量不足となる毎に古いファイルを探してファイルサーバに転送して転送済みファイルを削除するという余計な処理負荷が発生する。更に、個人用コンピュータだけでなくファイルサーバまでもが空き容量不足となった場合には、更に別のファイルサーバを利用することで対応するが、当該別のファイルサーバへの更なるデータ転送という処理負荷が増える。また、サイト内の全てのサーバ（ＬＡＮで接続されたサーバ）を用いても空き容量不足となった場合には対応できない。また、この発明では、データの処理単位がファイルのみであり、ファイルシステムには適用できるが、例えばデータベース管理システムの使用領域も処理できるというものではない。
【００２７】
また、特許文献７記載の発明は、ストレージのレンタルサービスに係わる発明である。このサービスは、ユーザ自らストレージを用意するのではなく、契約に基づいて一定期間（例えば１ヶ月）ストレージサービスプロバイダ（ＳＳＰ）サイトにあるストレージの容量を利用し対価を払うものである。特許文献７記載の発明は、この様なストレージのレンタルサービスに係わり、ストレージ提供者が、ストレージ使用者の過去のストレージ使用量に基づいて、将来のストレージ使用量を予測して、予測結果をストレージ使用者に通知する。ストレージ使用者は、この通知により、使用できるデータ量を拡張したり、縮小する等、契約内容を再設定して最適な契約内容でストレージのレンタルサービスを受けることができる。
【００２８】
上記ストレージのレンタルサービスでは、ユーザ自らストレージを用意するのではなく、ストレージ提供者からレンタルして、レンタル量を支払うが、使用するストレージ容量が非常に大きければ、多額のレンタル量が必要となる。
【００２９】
また、上述した従来技術では、例えば管理者等により容量不足の判断や、容量拡張／縮小（容量追加／減少）を指示する操作を行う必要があり、人的負担が大きかった。
以上のことより、基本的には自サイト内の自前のストレージを用いて、サイト内の各情報処理資源（例えばデータベース、ファイルシステム等）にその時々で必要な容量を割り当てることで対応し、自サイト内の全ストレージを用いても容量不足となった場合に、外部のサーバのストレージを利用し、必要が無くなり次第返却することができるようにすることが望まれ、更にこれらをコンピュータにより自動的に処理することが望まれる。
【００３０】
本発明の課題は、自サイト内の実ボリュームのストレージ仮想化により自サイト内の各情報処理資源に随時必要な容量を割り当てると共に、もし自サイト内の実ボリュームのみでは対応できない（実容量不足）場合には、外部のサーバの実ボリュームを一時的に利用し、必要なくなったら返却することを自動的に行えるストレージ容量管理方法、そのサーバ、記録媒体を提供することである。
【特許文献１】特開平１１−１５７３２号公報
【特許文献２】特開平１０−４０１６９号公報
【特許文献３】特開平６−１９７９６号公報
【特許文献４】特開平８−２４１２２０号公報
【特許文献５】特開２００２−３１２６８９号公報
【特許文献６】特開平９−１８５５３６号公報
【特許文献７】特開２００２−３１２６９９号公報
【非特許文献１】NETWORK WORLD 2002年９月号；p154-157
【非特許文献２】コンピュートピア別冊  データストレージ・レポート２００２（株式会社コンピュータ・エージ社）；p21,22,23,34,38,39
【非特許文献３】日経コンピュータ2002.5.6；p134-141「進化するストレージ（前編）」
【非特許文献４】「ストレージ・ネットワーキング仮想化技術」、根来  元；  UNISYS TECHNOLOGY REVIEW 第７４号、AUG.2002
【非特許文献５】http://www.snia.org/education/tutorials/virtualization/上でダウン ロードサービス提供されている“SNIA Virtualization Tutorial”
【非特許文献６】http://www.falconstor.co.jp/products/competitive/
【発明の開示】
【００３１】
本発明によるストレージ容量管理方法を実行するサーバは、ストレージ仮想化が行われているサイトにおけるサーバにおいて、自サイト内の実ボリューム全体に関する空き実容量と、自サイト内の各監視対象資源毎の容量割当情報を格納する容量管理情報格納手段と、現在の空き容量が所定の閾値未満となった監視対象資源に対して、前記自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイトの実ボリュームを借用して該監視対象資源に追加容量を割り当てる容量割当制御手段とを有するように構成する。
【００３２】
まず、上記自サイト内は、上記従来のストレージ仮想化が行われている。
そして、上記容量割当制御手段は、自サイト内の各情報処理資源（例えば業務サーバ等）の空き容量を監視しており、予め設定されている所定の閾値等を用いることで、容量追加の必要性を判定する。そして、もし容量追加が必要であると判定したら、基本的には自サイト内の実ボリュームを用いて、その情報処理資源に必要な容量を割り当てる。また、もし自サイト内の実ボリュームでは対応できない場合でも、他サイトの実ボリュームを借用することで対応できる。
【００３３】
また、例えば、上記サーバは、前記他サイトの実ボリュームの借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、前記他サイトの実ボリュームは返却する集約手段を更に有するように構成してもよい。
【００３４】
つまり、例えば一時的に容量不足となっても、後に自サイトの容量不足が解消する等して、他サイトから借用し続ける必要がなくなったら、借用していた実ボリュームは返却するようにしてもよい。このように、必要に応じて一時的に借用して後に返却するという柔軟な対応が可能となる。また、これは、自サイトは借用のみで他サイトは貸出のみという意味ではなく、各サイトが相互に借用／貸出する構成としてもよい。これによって、各サイトは、自サイトの空き容量に余裕がある場合には他サイトに貸し出し、余裕がない場合には他サイトから借用することができ、自サイトに余分な空き容量を多めに確保しておく等の必要がなくなる。
【００３５】
また、例えば、前記容量割当制御手段は、前記ストレージ仮想化に基づく「ボリュームの動的容量追加」機能を実行することで前記監視対象資源に追加容量を割り当てることができる。
【００３６】
また、例えば、前記集約手段は、前記ストレージ仮想化に基づく仮想化制御により一時的にミラー状態を構成する「実ボリュームの動的再配置」機能を実行することで、前記データを前記空き領域に集約することができる。
【００３７】
また、例えば、前記借用した他サイトの実ボリュームへのアクセスは、ＩＰを利用したＳＣＳＩプロトコルを用いる。上記従来技術で説明したように、ｉＳＣＳＩを採用することで様々なメリットが得られる。
【００３８】
また、以上の処理は、ほとんど自動化されているので、管理者等が各情報処理資源の空き容量状況を監視して容量増加／減少を指示する必要はなく、人的負担を軽減できる。更に、従来技術で述べた通り、他サイトの実ボリュームを借用すると、通常、借用期間に応じたレンタル料金が掛かるが、本発明では、集約手段によって自動的に、必要が無くなったら借用ボリュームを返却するので、本当に必要な期間だけレンタルでき、不必要に長期間レンタルすることでコスト高になるという事態を回避できる。すなわち、本発明では、ストレージレンタル料金に係わるコスト削減効果も得られる。
【発明を実施するための最良の形態】
【００３９】
以下、図面を参照して、本発明の実施の形態について説明する。
まず、ここで、「ボリューム」（実ボリューム、仮想ボリューム）という用語について説明しておく。
【００４０】
一般に、ＳＣＳＩ入出力要求で使うアドレスは、ターゲットポート番号、装置番号（Logical Unit Number）、ブロック番号である。ターゲットポート番号は、World Wide Nameと呼ばれるポートのチップに埋め込まれた識別番号である。装置番号は、現在では１ポート当り最大２５６個指定可能となっている。ブロック番号は、装置内を固定長のブロックで構成し、そのブロックに付けた番号である。上記「ボリューム」とは上記装置番号に関係し、実ボリュームは上記装置番号のＬＵ（Logical Unit）のことであり、これを仮想化したものが仮想ボリューム（仮想ＬＵとも呼ばれている）である。
【００４１】
図１は、本例によるストレージ容量管理手法を実現するシステム全体の概略的な構成図である。
図１において、ローカルサイト１０は任意のサイトであり、リモートサイト５０は、ローカルサイト１０側でストレージ容量不足となった場合に容量を供給する他のサイトである。
【００４２】
ローカルサイト１０内には、上記従来のストレージ・ネットワークに対して上記従来のストレージ仮想化が施されており、ローカルサイト１０内のストレージは仮想化サーバ３０が管理している。ローカルサイト１０内の各種アプリケーションサーバ（図では一例として業務サーバ２０）は、ＳＣＳＩプロトコルに従って仮想化サーバ３０にアクセスする構成となっており、業務サーバ２０、仮想化サーバ３０とも、ＳＣＳＩドライバ２２、３１を有する。業務サーバ２０において任意の業務プログラム２１が実行された結果、任意のデータへのアクセス（例えばＲＥＡＤ／ＷＲＩＴＥ等）が必要になると、仮想化サーバ３０を介してストレージにアクセスする。
【００４３】
仮想化サーバ３０は、上記従来技術により、各ストレージを管理し、仮想化制御を行っている。仮想化サーバ３０は、更に、ＮＩＣ（ＬＡＮ）ドライバ３２を備え、ＮＩＣ（ＬＡＮ）ドライバ３２は不図示のＬＡＮに接続しており、ｉＳＣＳＩプロトコルを用いて他のサイト（リモートサイト５０）にアクセスする。
【００４４】
また、仮想化サーバ３０は、容量管理情報格納部３３、容量割当制御部３４、集約部３５を有する。
容量管理情報格納部３３は、少なくとも自サイト（ローカルサイト１０）内の実ボリューム全体に関する空き実容量と、自サイト内の各監視対象資源毎の現在の容量割当情報を格納する。
【００４５】
容量割当制御部３４は、この容量管理情報格納部３３に格納されているデータを参照して、現在の空き容量が予め設定されている所定の閾値未満となった監視対象資源に対して、自サイト内の実ボリューム全体の空き実容量に応じて、自サイト内の実ボリュームで対応可能な場合には自サイト内の実ボリュームを用いて該監視対象資源に追加容量を割り当て、自サイト内の実ボリュームで対応できない場合には、他サイト（リモートサイト５０）に借用要求を出してその実ボリューム７０を借用して、該監視対象資源に追加容量を割り当てる制御を行う。その後、借用した実ボリューム７０を利用する場合には、上記ｉＳＣＳＩプロトコルを用いてアクセスすることになる。
【００４６】
集約部３５は、上記他サイトの実ボリューム７０を借用後、自サイトの実ボリュームに空き領域を確保できる場合、該他サイトの実ボリュームに格納したデータを該自サイトの空き領域に集約して、借用していた他サイトの実ボリューム７０は返却する。
【００４７】
一方、リモートサイト５０においてもＮＩＣ（ＬＡＮ）ドライバ６１、ＳＣＳＩドライバ６２を有する仮想化サーバ６０を設ける。仮想化サーバ６０は、ローカルサイト１０への実ボリューム７０の貸出（供給）の管理を行う。
【００４８】
このように、ローカルサイト１０、リモートサイト５０の両方のサイトにおいて仮想化サーバが介在する構成とし、仮想化サーバは、ＳＣＳＩとｉＳＣＳＩの間のプロトコル変換、及び実ボリュームの借用と貸出（供給）の関係を管理している（勿論、従来のストレージ仮想化制御も行っている）。
【００４９】
尚、図１に示す構成は一例であり、これに限るわけではなく、例えばホストが仮想化サーバの機能を備える構成であってもよい。
図２は、ローカルサイト１０の仮想化サーバ３０によって実行される全体処理の概略フローチャート図である。
【００５０】
図２において、仮想化サーバ３０は、任意のときに、実ボリュームを仮想制御下に置く処理を実行する（ステップＳ１１）。その際、上記従来技術の「実ボリュームを仮想化と非仮想化の間で出し入れする機能」を用いることにより、実ボリュームをそのまま仮想化配下に置くことができるので、仮想制御下への移行の為のデータ複写は不要であり、これによって業務停止時間を短くすることができる。尚、ステップＳ１１の処理対象の実ボリュームは、例えば急激に容量不足に陥るおそれのある実ボリューム等である。
【００５１】
上記ステップＳ１１の処理のイメージを、図３に示す。
図３において、仮想化サーバ３０は、管理データ３３（仮想化管理データ）に基づいて、仮想ボリュームと実ボリュームの対応関係の管理を行っている。これ自体は、上記従来技術であるので、特に説明しない。上記ステップＳ１１の処理では、仮想化サーバ３０は、新たに仮想制御下に置いた実ボリュームＲ１と仮想ボリュームＶ１との対応関係を管理データ３３に登録することになる。
【００５２】
その後、任意のときに、任意の情報処理資源への割当容量が不足状態になったら、ローカルサイト１０内の実ボリュームを用いて、上記従来技術の「ボリュームの動的容量追加機能」によって、業務無停止で割当容量を増やす。これは、予め設定・記憶されている仮想化配下の容量追加に関する不図示のポリシー（例えば、残り容量２０（％）を切ったら、容量を４０（％）追加する等のポリシー）に従って、上記割当容量が不足状態になったか否かの判定、及び割当容量を増やす処理を、自動的に実行する（ステップＳ１２）。
【００５３】
上記ステップＳ１２の処理のイメージを図４に示す。
図４において、仮想化サーバ３０は、仮想ボリュームと実ボリュームとの対応関係を示す管理データ３３に基づいて、ストレージ仮想化制御を行っている。尚、図４に示す処理イメージは、従来技術の説明における図１６と略同様であるので、ここでは特に詳細には説明しない。
【００５４】
本例の手法では、上記割当容量の追加は、ローカルサイト１０内の実ボリュームを用いるだけでなく、リモートサイト５０の実ボリューム７０を借用して行うこともできる。特に、ローカルサイト１０内の実ボリュームのみでは割当容量の増加を行うことができない状態になった場合に（実ボリューム不足状態）、一時的に、リモートサイト５０の実ボリューム７０を借用することで対応するものである（ステップＳ１３）。この為に、図５にそのイメージを示すように、ローカルサイト１０側の仮想化サーバ３０は、仮想ボリュームと実ボリュームの対応関係を管理すると共に、管理データ３４（一例を図７（ａ）に示す）によって、ローカルサイト１０内の実ボリュームだけでなく、リモートサイト５０から借用した実ボリューム７０も含めて、各情報処理資源に対する容量割当の管理を行っている。
【００５５】
図５に示す例では、仮想ボリュームＶ１−１、Ｖ１−４はローカルサイト１０内の実ボリュームＲ１，Ｒ４と対応付け、仮想ボリュームＶ１−２、Ｖ１−３はリモートサイト５０内の実ボリュームＲ２，Ｒ３と対応付けて管理している。尚、図５の図上において、各ボリューム内に示す１，２，３，４等の番号は、各ボリュームに格納されるデータを意味する。他の図面についても同様である。
【００５６】
一方、リモートサイト側の仮想化サーバ６０は、管理データ６３（一例を図７（ｂ）に示す）によって、自己の実ボリューム７０の貸し出し管理を行っている。また、両サイト１０−５０間のデータアクセスの為の接続にはｉＳＣＳＩプロトコルを用いる。
【００５７】
尚、図７（ａ）、（ｂ）に示す上記管理データ３４、６３の詳細については、後に説明する。
このように、リモートサイト５０の実ボリューム７０を借用することで容量不足に対応する一方で、その後、ローカルサイト１０側の空き容量に余裕が生じた場合、リモートサイト５０側に退避させていたデータを、ローカルサイト１０側に集約する処理を行う（ステップＳ１４）。これには、上記従来技術の「実ボリュームの動的再配置」を用いる。この「実ボリュームの動的再配置」によれば、複数のリモートサイト５０の実ボリューム７０に分散しているデータであってもローカルサイト１０側に集約させることができる。
【００５８】
上記ステップＳ１４の処理のイメージを図６に示す。
図６は、図５に示すようにローカルサイト１０の実ボリュームＲ１，Ｒ４、リモートサイト５０の実ボリュームＲ２，Ｒ３に各々格納していたデータ１，２，３，４を、ローカルサイト１０側の空き容量に余裕ができる等して新たに確保できた実ボリュームＲ５にコピーする様子を示している。その際、従来技術で説明した「実ボリュームの動的再配置」を実行し、一旦、図１８（ｂ）と同様のミラー状態にした後で、図１８（ｃ）と同様に、元々あった実ボリュームＲ１，Ｒ４は切り離し、リモートサイト５０から借用していた実ボリュームＲ２，Ｒ３は返却して、追加した実ボリュームＲ５だけを仮想ボリュームＶ１（Ｖ１−１〜Ｖ１−４）に対応させる。
【００５９】
図７（ａ）に、上記ローカルサイト１０側の管理データ３４の一例を示す。図７（ｂ）に、上記リモートサイト５０側の管理データ６３の一例を示す。
図７（ａ）において、各ローカルサイト１０（サイト１〜サイトｎ）は、それぞれ、上記管理データ３４として、サイト内共通の情報８０、監視対象資源ｉ毎の情報９０を有する。
【００６０】
サイト内共通の情報８０は、借用先の位置８１、実容量全体８２、空き実容量８３、割当て実容量８４より成る。尚、図７（ａ）の図上に示す算出式や、図７〜図１０の図中に示す（８１）〜（１２３）までの括弧番号は、図７（ａ）、（ｂ）に示す各データ構成に付した参照符号を用いて示している。これにより、図上の説明を簡略化している。例えば図７（ａ）の図上においてサイト内共通の情報８０の右側に算出式「（８２）＝（８３）＋（８４）」と記してあるが、これは「実容量全体８２＝空き実容量８３＋割当て実容量８４」を意味することになる。図７〜図１０の図上に示す括弧番号についても同様である。
【００６１】
上記借用先の位置８１は、実ボリューム７０を借用しているリモートサイト５０のＩＰアドレスである。実容量全体８２は、当該ローカルサイト１０内の実ボリュームの総容量である。空き実容量８３は、当該ローカルサイト１０内の実ボリュームの総空き容量である。割当て実容量８４は、現在当該ローカルサイト１０内の各情報処理資源ｉに対して当該ローカルサイト１０内の実ボリュームから割り当てている容量の総和である。つまり、全ての資源ｉにおける全ての割当領域ｊの長さ１０１の総和である。つまり、
割当て実容量８４＝Σi,j（長さ１０１）
である。
【００６２】
監視対象資源ｉ毎の情報９０は、監視対象９１、容量上限９２、現行容量９３、追加閾値９４、追加単位９５、監視間隔９６、及びローカル集約表示９７より成る。更に、ローカルサイト１０内の実ボリュームからその監視対象資源ｉに割り当てている領域に関する情報１００（以下、自サイトからの割当情報１００と記す）、リモートサイト５０から借用している実ボリュームからその監視対象資源ｉに割り当てている領域に関する情報１１０（以下、外部からの割当情報１１０と記す）を有する。
【００６３】
監視対象９１は、監視対象資源ｉ（例えば、ＤＢ（データベース）テーブル、ファイルシステム等）の名称又は識別ＩＤ等である。
容量上限９２は、当該ローカルサイト１０内の実ボリュームとリモートサイト５０から借用する実ボリュームとを併せた容量の上限値（容量拡張の上限値）である。
【００６４】
現行容量９３は、当該ローカルサイト１０内の実ボリュームとリモートサイト５０から借用する実ボリュームとを併せた容量の現在使用値である。つまり、
現行容量９３＝Σｉ（長さ１０１）＋Σｋ（長さ１１１）
である。
【００６５】
追加閾値９４は、容量追加するか否かの判定（後述する）に用いられる閾値である。
追加単位９５は、容量追加すると判定された場合に当該資源ｉに追加する容量の値（例えば２（ＧＢ）追加等）である。
【００６６】
監視時間９６は、後述する空き容量をチェックする処理を行う時間間隔または時刻である。
ローカル集約表示９７は、例えばフラグであり、フラグオンの場合には、後述する「リモートサイトに分散させていた全データをローカルサイトに集める処理」を実行する。
【００６７】
自サイトからの情報１００は、ローカルサイト１０の実ボリュームから現在当該資源ｉに割り当てている記憶領域に関する情報であり、各割当領域ｊ毎に、その先頭アドレス１０２と長さ１０１が格納される。
【００６８】
外部からの情報１１０は、リモートサイト５０の実ボリュームから現在当該資源ｉに割り当てている記憶領域に関する情報であり、各割当領域ｋ毎に、その先頭アドレス１１２と長さ１１１が格納される。
【００６９】
一方、リモートサイト５０側の管理データ６３としては、図７（ｂ）に示すように、貸出先サイト１〜ｎ毎に貸出情報１２０を保持する。
貸出情報１２０は、貸出先の位置１２１、貸出上限１２２、現行貸出容量１２３より成る。貸出先の位置１２１は、貸出先のローカルサイト１０のＩＰアドレスである。貸出上限１２２は、当該貸出先のローカルサイト１０への貸出容量の上限値である。現行貸出容量１２３は、当該貸出先のローカルサイト１０への現在の貸出容量である。
【００７０】
尚、貸出先の位置１２１、貸出上限１２２、借用先の位置８１、監視対象９１、容量上限９２、追加閾値９４、追加単位９５、監視間隔９６は、ポリシーとして事前に設定するが、運用中に変更することもできる。
【００７１】
図８（ａ）は、ローカルサイト１０側の仮想化サーバ３０による初期設定及び監視処理を示すフローチャート図である。
図８（ａ）において、仮想化サーバ３０は、初期設定処理の際には、まず、実容量全体８２、空き実容量８３、及び割当て実容量８４の値を初期化する  （ステップＳ２１）。続いて、監視対象資源ｉ毎に、上記の通り、借用先の位置８１、監視対象９１、容量上限９２、追加閾値９４、追加単位９５、監視間隔９６については、ポリシーとして事前に設定する。更に、現行容量９３、ローカル集約表示９７、長さ１０１、先頭アドレス１０２、長さ１１１、先頭アドレス１１２の値を初期化する（ステップＳ２２）。
【００７２】
上記初期設置処理後は、随時、ステップＳ２３〜ステップＳ２６の監視処理を実行する。
まず、監視間隔９６によって規定される監視処理起動時刻が到来するまでは、待機状態となっている。監視処理起動時刻が到来したら、各監視対象資源ｉ毎にステップＳ２４〜Ｓ２６の処理を繰り返し実行し、全ての監視対象資源ｉについての処理が完了したら、次の監視処理起動時刻が到来するまで再び待機状態となる。ステップＳ２４〜Ｓ２６の処理は、まず、処理対象の監視対象資源ｉに関する情報９０の中のローカル集約表示９７を参照して、フラグオンか否かを判定する（ステップＳ２４）。フラグオンである場合には（ステップＳ２４，ＹＥＳ）、ローカル集約処理（詳しくは図１０（ｂ）で説明）を実行する（ステップＳ２５）。フラグオフであった場合には（ステップＳ２４，ＮＯ）、容量の確認・追加処理（詳しくは図９（ａ）で説明）を実行する（ステップＳ２６）。
【００７３】
図８（ｂ）は、リモートサイト５０側の仮想化サーバ６０による処理を示すフローチャート図である。
図８（ｂ）において、仮想化サーバ６０は、まず、貸出先の位置１２１、貸出上限１２２については、ポリシーとして事前に設定する（ステップＳ３１）。また、現行貸出容量１２３の値を初期化する（ステップＳ３２）。
【００７４】
以上、初期設定処理を行った後は、各ローカルサイト１０からの貸出要求に応じて貸出処理（詳しくは図９（ｂ）で説明）を実行し、あるいは各ローカルサイト１０からの返却要求に応じて返却処理（詳しくは図１０（ｃ）で説明）を実行する（ステップＳ３３）。
【００７５】
図８（ｃ）は、ローカルサイト側で実ボリュームが追加される場合にストレージ管理者が起動することによって実行される処理を示す図である。ローカルサイトの実ボリュームを当仮想化管理の配下に置く場合に、ストレージ管理者が個々の実ボリュームを指定して当該処理を起動する。この処理では、ステップＳ２６において追加された容量分を、実容量全体８２と空き実容量８３の両方に加算する（ステップＳ４１）。
【００７６】
図９（ａ）は、上記ステップＳ２６の容量の確認・追加処理の詳細フローチャート図である。この処理は、容量割当制御部３４によって実行される。
図９（ｂ）は、図９（ａ）の処理において容量の追加要求が行われた場合のステップＳ３３の処理のうちの貸出処理の詳細フローチャート図である。
【００７７】
ローカルサイト１０側の仮想化サーバ３０は、上記ステップＳ２４の処理においてローカル集約表示９７がフラグオンではなかった場合に、図９（ａ）に示す処理を実行する。
仮想化サーバ３０は、まず、監視対象資源ｉの空き容量を得る（ステップＳ５１）。すなわち、監視対象のデータベース又はファイルシステムの空き容量を得る。取得方法は、例えばデータベース又はファイルシステムに固有の容量管理インタフェース（コマンド等）を使用する方法等がある。
【００７８】
続いて、取得した空き容量が追加閾値９４より小さく（ステップＳ５２，ＹＥＳ）且つ「現行容量９３＋追加単位９５＜容量上限９２」である場合すなわち所定単位の容量追加を行っても容量拡張の上限値を超えない場合には（ステップＳ５３，ＹＥＳ）、ステップＳ５４以降の処理に移り、そうでなければ当該処理は終了する。
【００７９】
次に、「追加単位９５＜空き実容量８３」であるか否かを判定する（ステップＳ５４）。すなわち、自サイト内の実ボリュームによって容量追加に対応できるか否かを判定する。自サイト内で対応できる場合には（ステップＳ５４，ＹＥＳ）、ローカルサイト１０内の実ボリュームの空き領域から、追加単位９５分の容量を獲得し（ステップＳ５５）、獲得した領域の先頭アドレスと長さを、それぞれ、割当領域ｊの先頭アドレス１０２、長さ１０１に格納する（ステップＳ５６）。そして、空き実容量８３、割当て実容量８４を、それぞれ、以下の通り更新する（ステップＳ５７）。
【００８０】
空き実容量８３＝空き実容量８３−追加単位９５
割当て実容量８４＝割当て実容量８４＋追加単位９５
また、当該処理対象の資源ｉに関する現行容量９３の値も、以下の通り更新する。
【００８１】
現行容量９３＝現行容量９３＋追加単位９５
最後に、処理対象資源ｉに容量追加して（ステップＳ５９）、本処理は終了する。尚、ステップＳ５９の処理は、上記従来の「ボリュームの動的容量追加」の処理を実行するものである。
【００８２】
一方、上記ステップＳ５４の判定において、自サイト内の実ボリュームによって容量追加に対応できないと判定された場合には（ステップＳ５４，ＮＯ）、リモートサイト５０から借用することになる。
【００８３】
すなわち、借用先の位置８１によって示されるリモートサイト５０に対して、追加単位９５分の容量の借用を要求する（ステップＳ６０）。
リモートサイト５０側では、この借用要求を受信すると（ステップＳ７１）、まず「追加単位９５＋現行貸出容量１２３≦貸出上限１２２」であるか否かを判定する（ステップＳ７２）。すなわち、要求元のローカルサイト１０に現在貸し出している容量に、要求された追加単位９５分を加えても、当該ローカルサイト１０への貸出容量の上限値を越えないか否かを判定し、もし上限値を越えてしまう場合には（ステップＳ７２，ＮＯ）、要求元のローカルサイト１０に対して“貸出上限を超えてしまうので、これ以上貸出し出来ない（失敗）”旨を返答する（ステップＳ７６）。
【００８４】
一方、追加単位９５分を更に貸し出しても貸出上限１２２を越えない場合には（ステップＳ７２，ＹＥＳ）、自己の実ボリュームから追加単位９５分の空き領域を獲得すると共に（ステップＳ７３）、現行貸出容量１２３の値を更新、すなわち「現行貸出容量１２３＝現行貸出容量１２３＋追加単位９５」とし（ステップＳ７４）、貸出位置（獲得した記憶領域の先頭アドレス、長さ）を、要求元のローカルサイト１０に返信する（ステップＳ７５）。
【００８５】
ローカルサイト１０側では、上記ステップＳ７６による返答、すなわち失敗の返答を受けた場合には（ステップＳ６１，ＮＯ）、借用上限超えの処理を行って（ステップＳ６３）、本処理を終了する。ステップＳ６３の処理は、例えば、そのリモートサイトからはそれ以上借用できないことを記録することで、その後は、そのリモートサイトには容量を要求しないようにする処理である  （但し、返却後は、再び借用要求を出せるようにしてもよい）。あるいは、ステップＳ６３の処理は、ローカルサイトのストレージ管理者の端末に対して、「借用上限超え」を知らせるメッセージを出力する処理であってもよい。このメッセージを見たストレージ管理者は、以下の対応をとることで、ローカルサイト１０の空き容量不足を解消する。
・不要なデータを削除して空き容量を増やす。
・新たに実ボリュームを追加して、空き状態の実ボリュームを作る（尚、その際、ストレージ管理者が起動することによって図８（ｃ）の処理が実行されるようにしてもよい）。
・複数の実ボリュームにまばらに割り当てられた小さなデータ群を、１つの実ボリュームに集めることで、空き状態の実ボリュームを作る。
・アクセス頻度の低い実ボリュームにあるデータを二次媒体（磁気テープやＤＶＤ等）に退避させて、実ボリュームを空き状態にする。
【００８６】
一方、上記ステップＳ７５による返答、すなわち借用成功して貸出位置のデータが返信されてきた場合には（ステップＳ６１，ＹＥＳ）、当該貸出位置データ（獲得した記憶領域の先頭アドレス、長さ）を、外部からの割当情報１１０の先頭アドレス１１２、長さ１１１に格納し（ステップＳ６２）、続いて上記ステップＳ５８、Ｓ５９の処理を実行する。
【００８７】
図１０（ａ）〜（ｃ）は、図８（ａ）のステップＳ２５のローカル集約処理に係わる各処理を示すフローチャート図である。
図１０（ａ）は、ローカル集約表示９７のフラグをオンする処理（ステップＳ８１）を示す。ステップＳ８１の処理は、例えばユーザ等が任意の資源ｉを指定して、その全容量をローカルサイト１０側に集約する旨の指示を入力した場合に実行される。
【００８８】
図１０（ｂ）は、上記ステップＳ２５のローカル集約処理の詳細フローチャート図である。この処理は、集約部３５によって実行される。
図１０（ｃ）は、図１０（ｂ）の処理において領域の返却要求が行われた場合のステップＳ３３の処理のうちの返却処理の詳細フローチャート図である。
【００８９】
ローカルサイト１０側の仮想化サーバ３０は、上記ステップＳ２４の処理においてローカル集約表示９７がフラグオンであった場合に、図１０（ｂ）に示す処理を実行する。
まず、「現行容量９３＜空き実容量８３」であるか否かを判定する（ステップＳ９１）。すなわち、空き実容量９３が、ローカルサイト１０とリモートサイト５０を併せた資源ｉの現在の使用容量を上回るか否かを判定する。つまり、ローカルサイト１０側への集約を行うのに必要な空き容量があるか否かを判定するものであり、もし必要な空き容量がない場合には（ステップＳ９１，ＮＯ）、本処理は終了する。
【００９０】
もし、集約に必要な空き容量がある場合には（ステップＳ９１、ＹＥＳ）、ローカルサイト１０内の実ボリュームから、現行容量９３分の容量を獲得する（ステップＳ９２）。つまり、現在ローカルサイト１０とリモートサイト５０に分散配置しているデータを移動させる移行先の記憶領域を確保しておく。また、これに伴って、一旦、空き実容量８３、割当て実容量８４の値を更新しておく（ステップＳ９３）。すなわち、
空き実容量８３＝空き実容量８３−現行容量９３
割当て実容量８４＝割当て実容量８４＋現行容量９３
としておく。
【００９１】
続いて、上記獲得した移行先の記憶領域の先頭アドレス及び長さを、自サイトからの割当情報１００の先頭アドレス１０２、長さ１０１にそれぞれ設定し（ステップＳ９４）、移行先ボリュームを作成する（ステップＳ９５）。
【００９２】
そして、上記従来技術の「実ボリュームの動的再配置」処理を実行することで、現在ローカルサイト１０とリモートサイト５０に分散配置しているデータを、上記ステップＳ９２で獲得した記憶領域に移動させる。つまり、データを集約する（ステップＳ９６）。
【００９３】
このようにしてデータを新たな記憶領域に移したら、このデータの為にリモートサイト５０から借用していた記憶領域を返却する。すなわち、当該借用していた記憶領域に関する割当領域ｋの先頭アドレス１１２と長さ１１１を付加した返却要求を、借用先の位置８１のＩＰアドレスのリモートサイト５０へと送信する（ステップＳ９７）。
【００９４】
リモートサイト５０側の仮想化サーバ６０は、この返却要求を受信すると  （ステップＳ１１１）、この返却要求に付加されている上記先頭アドレス１１２と長さ１１１によって示される記憶領域を空き状態にする（ステップＳ１１２）。
続いて、返却要求したローカルサイト１０に関する貸出情報１２０における現行貸出容量１２３の値を「現行貸出容量１２３＝現行貸出容量１２３−返却された長さ１１１」により更新する（ステップＳ１１３）。
【００９５】
そして、返却処理完了を、返却要求したローカルサイト１０に通知する（ステップＳ１１４）。
この通知を受けたローカルサイト１０の仮想化サーバ３０は、外部からの割当情報１１０の中で上記返却した割当領域ｋの情報を削除する（ステップＳ９８）。また、上記新たな記憶領域に移動させたデータの移動元の記憶領域のうち、リモートサイト５０の分は上記の通り返却したが、ここでローカルサイト１０の分を空き領域とする（ステップＳ９９）。これに伴い、空き領域とした記憶領域に関する割当領域ｊの情報を削除する。また、空き実容量８３、割当て実容量８４の値を更新する（ステップＳ１００）。すなわち、
空き実容量８３＝空き実容量８３＋移行先の割当領域ｊの長さ１０１
割当て実容量８４＝割当て実容量８４−移行先の割当領域ｊの長さ１０１
としておく。
【００９６】
最後に、ローカル集約表示９７をフラグオフして（ステップＳ１０１）、本処理を終了する。
以上説明したように、本例のストレージ容量管理方法、当該方法を実行するコンピュータ（サーバ等）、当該方法をコンピュータに実行させる為のプログラム、当該プログラムを記録した記録媒体等によれば、各情報処理資源において容量追加が必要となった場合、基本的には自サイト内の実ボリュームを割り当てて対応し、自サイト内では対応できない場合には他サイトから借用することで対応できる。また、後に自サイトの容量不足が解消する等して、他サイトから借用し続ける必要がなくなったら、借用していた実ボリュームは返却するようにしてもよい。
【００９７】
これによって、例えば、容量需要の急増等を考慮して予め自サイト内に余分な実ボリュームを用意しておかなくても、容量不足になったときには他サイトからレンタルすれば済む。また、これら一連の処理は、ほとんど自動化されているので、管理者等が各情報処理資源の空き容量状況を監視して容量増加／減少を指示する必要はなく、人的負荷が軽減できる。また、他サイトの実ボリュームを借用すると、通常、借用期間に応じたレンタル料金が掛かるが、本例の手法では、必要が無くなったら自動的に借用ボリュームを返却するので、本当に必要な期間だけレンタルでき、不必要に長期間レンタルすることでコスト高になるという事態を回避できる。すなわち、ストレージのレンタル料金に係わるコスト削減効果も得られる。
【００９８】
また、上述した説明では、ローカルサイト１０側が借用のみ、リモートサイト側５０が貸し出しのみを行う構成を示したが、これに限らず、各サイトが相互に借用／貸出する構成としてもよい。これによって、各サイトは、自サイトの空き容量に余裕がある場合には他サイトに貸し出し、余裕がない場合には他サイトから借用することができ、自サイトに余分な空き容量を多めに確保しておく等の必要がなくなる。
【００９９】
尚、上述した説明では、ｉＳＣＳＩプロトコルを用いたが、これに限るものではなく、他の“ＩＰを利用したＳＣＳＩプロトコル”（例えばＳＡＮ−ＩＰ、ＦＣ−ＩＰ、ｉＦＣＰ等）であってもよい。
【０１００】
図１１は、上記ストレージ容量管理方法を実行するコンピュータ１３０（仮想化サーバ３０、６０）のハードウェア構成の一例を示す図である。
【０１０１】
同図に示すコンピュータ１３０は、ＣＰＵ１３１、メモリ１３２、入力装置１３３、出力装置１３４、外部記憶装置１３５、媒体駆動装置１３６、ネットワーク接続装置１３７等を有し、これらがバス１３８に接続された構成となっている。同図に示す構成は一例であり、これに限るものではない。
【０１０２】
ＣＰＵ１３１は、当該コンピュータ１３０全体を制御する中央処理装置である。
メモリ１３２は、プログラム実行、データ更新等の際に、外部記憶装置１３５（あるいは可搬型記録媒体１３９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１３１は、メモリ１３２に読み出したプログラム／データを用いて、上記図８〜図１０等に示すストレージ容量管理方法を実現する処理を実行する。
【０１０３】
入力装置１３３は、例えばキーボード、マウス、タッチパネル等である。
出力装置１３４は、例えばディスプレイ、プリンタ等である。
外部記憶装置１３５は、例えば磁気ディスク装置、光ディスク装置、光磁気ディスク装置等であり、上記ストレージ容量管理方法の処理をコンピュータ１３０に実行させる為のプログラム／データ（図８〜図１０の処理プログラム、図７のデータ等）が格納されている。
【０１０４】
媒体駆動装置１３６は、可搬型記録媒体１３９に記憶されているプログラム／データ等を読み出す。可搬型記録媒体１３９は、例えば、ＦＤ（フレキシブルディスク）、ＣＤ−ＲＯＭ、メモリーカード、ＤＶＤ、光磁気ディスク等である。
【０１０５】
ネットワーク接続装置１３７は、ネットワークに接続して、外部の情報処理装置とプログラム／データ等の送受信を可能にする構成である。  
【０１０６】
図１２は、上記プログラムを記録した記録媒体、プログラムのダウンロードの一例を示す図である。
図示のように、上記本発明の機能を実現するプログラム／データが記憶されている可搬型記録媒体１３９からコンピュータ１３０側に読み出して、メモリ１３２に格納し実行するものであってもよいし、また、上記プログラム／データは、ネットワーク接続装置１３７により接続しているネットワーク１５０（インターネット等）を介して、外部のサーバ１４０の記憶部１４１に記憶されているプログラム／データをダウンロードするものであってもよい。
【０１０７】
また、本発明は、装置／方法に限らず、上記プログラム／データを格納した記録媒体（可搬型記録媒体１３９等）自体として構成することもできるし、上記プログラム自体として構成することもできる。
【産業上の利用の可能性】
【０１０８】
以上、詳細に説明したように、発明の自サイト内の実ボリュームのストレージ仮想化により自サイト内の各情報処理資源に随時必要な容量を割り当てると共に、もし自サイト内の実ボリュームのみでは対応できない（実容量不足）場合には、外部のサーバの実ボリュームを一時的に利用し、必要なくなったら返却することを自動的に行える。よって、自サイト内の実ボリュームを十分に利用でき、且つ外部サイトの実ボリュームを借用することで急激な容量需要等に対しても対応できると共に必要がなくなったら借用した容量を返却する等、柔軟な対応ができる。更にこれら自サイト内の実ボリュームを各情報処理資源に必要量割当てること、自サイト内で対応できない状況にあることを判断すること、外部サイトから借用することを、コンピュータにより自動的に処理できるので、ユーザが判断／操作する手間が掛からない。
【０１０９】
本発明は、後述する詳細な説明を、下記の添付図面と共に参照すればより明らかになるであろう。
【図面の簡単な説明】
【０１１０】
【図１】本例によるストレージ容量管理手法を実現するシステム全体の概略的な構成図である。
【図２】ローカルサイト側の仮想化サーバによって実行される全体処理の概略フローチャート図である。
【図３】図２のステップS１１の処理のイメージを示す図である。
【図４】図２のステップS１２の処理のイメージを示す図である。
【図５】図２のステップS１３の処理のイメージを示す図である。
【図６】図２のステップS１４の処理のイメージを示す図である。
【図７】（ａ）は、ローカルサイト側の仮想化サーバによる借用先、借用容量等の管理の為の管理データの一例を示す図であり、（ｂ）は、リモートサイト側の仮想化サーバによる供給先、供給容量等の管理の為の管理データの一例を示す。
【図８】（ａ）は、ローカルサイト側の仮想化サーバによる初期設定及び監視処理を示すフローチャート図であり、（ｂ）は、リモートサイト側の仮想化サーバによる処理を示すフローチャート図であり、（ｃ）は、ローカルサイト側で実ボリュームが追加されたときの仮想化サーバによる処理である。
【図９】（ａ）は、ステップＳ２６の容量の確認・追加処理の詳細フローチャート図であり、（ｂ）は、図９（ａ）の処理において容量の追加要求が行われた場合のステップＳ３３の処理のうちの貸出処理の詳細フローチャート図である。
【図１０】（ａ）は、ローカル集約表示のフラグをオンする処理を示す図あり、（ｂ）は、ステップＳ２５のローカル集約処理の詳細フローチャート図であり、（ｃ）は、図１０（ｂ）の処理において領域の返却要求が行われた場合のステップＳ３３の処理のうちの返却処理の詳細フローチャート図である。
【図１１】本例のストレージ容量管理方法を実行するコンピュータ（仮想化サーバ）のハードウェア構成の一例を示す図である。
【図１２】プログラムを記録した記録媒体、プログラムのダウンロードの一例を示す図である。
【図１３】従来の「ボリュームの仮想化」機能を説明する為の図（その１）である。
【図１４】（ａ）、（ｂ）は、従来の「ボリュームの仮想化」機能を説明する為の図（その２）である。
【図１５】（ａ）、（ｂ）は、従来の「ボリュームを仮想化と非仮想化の間で出し入れする」機能を説明する為の図である。
【図１６】従来の「ボリュームの動的容量追加」機能を説明する為の図である。
【図１７】（ａ）、（ｂ）は、従来の「ユーザデータのミラーリング」機能を説明する為の図である。
【図１８】（ａ）〜（ｃ）は、従来の「実ボリュームの動的再配置」機能を説明する為の図である。
【図１９】従来の「ＩＰ経由のＳＣＳＩアクセス」（ｉＳＣＳＩ）を説明する為の図である。
【国際調査報告】
2005001700.tif 000022
2005001700.tif 000023
2005001700.tif 000024
2005001700.tif 000025