JP4220174B2

JP4220174B2 - ストレージシステムのコンテンツ更新方法

Info

Publication number: JP4220174B2
Application number: JP2002104965A
Authority: JP
Inventors: マシエル・フレデリコ
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-04-08
Filing date: 2002-04-08
Publication date: 2009-02-04
Anticipated expiration: 2022-04-08
Also published as: US7143256B2; US20030191840A1; JP2003296035A

Description

【０００１】
【発明の属する技術分野】
本発明は、ストレージ機構、特に共有ストレージに保存されているコンテンツの更新に関する。
【０００２】
【従来の技術】
インターネットに接続しているデータセンタでは、普通複数のレイヤ（層）から構成される。
【０００３】
図１５に、フロント・エンド・レイヤと呼ばれる、インターネットに最も近いレイヤの構成を示す。負荷分散機５１は、インターネット５０からのアクセスを複数のサーバ５０１〜５０５に分散する。
【０００４】
これらのサーバ５０１〜５０５はＷｅｂやＦＴＰ等のサービスを提供する。各サーバ５０１〜５０５には、一つあるいは複数のハードディスクからなるストレージ装置５１１〜５１５がそれぞれ装備される。これらのストレージ装置５１１〜５１５が、そのデータセンタが処理する各Ｗｅｂサイト、ＦＴＰサイト等（以下、単にサイトという）のコンテンツを保存する。
【０００５】
これらサーバ５０１〜５０５を管理する管理サーバ４０は、一つあるいは複数のハードディスクからなるストレージ装置４１を備え、このストレージ装置４１がサイトのコンテンツのマスタコピーを保存し、マスタコピーが更新されたら各サーバ５０１〜５０５のコンテンツを更新する（以降、更新されたコンテンツを「新しいコンテンツ」、更新される前のコンテンツを「古いコンテンツ」と呼ぶ）。
【０００６】
しかし、サーバ５０１〜５０５がアクセスされる最中にコンテンツが更新される場合に様々なエラーが生じる可能性があるため、管理サーバ４０は次の手順でコンテンツを更新する。
【０００７】
まず、負荷分散機５１の設定を変更し、サーバ５０１をサイトから分離する（その後、インターネット５０からのアクセスがこのサーバ５０１に転送されなくなる）。
【０００８】
そして、新しいコンテンツ（あるいは古いコンテンツと新しいコンテンツとの差分）をストレージ装置４１からサーバ５０１のストレージ装置５１１にコピーする。
【０００９】
最後に、負荷分散機５１の設定を元に戻し、サーバ５０１をサイトに再び追加する。管理サーバ４０が上記の３つのステップをサーバ５０２からサーバ５０５に繰り返すことにより、サイト全体のコンテンツを更新する。そして、サーバ５０１〜５０５を一つずつ更新するため、更新の最中にでもサイトをアクセスすることが可能であり、そしてサイトの性能はサーバ５０１〜５０５一台分のみ低下する。
【００１０】
近年、サーバ５０１〜５０５の密度が向上してきたが、図１５のように各サーバ５０１〜５０５がストレージ装置５１１〜５１５を持つことは密度の向上を制限する。そして、上記のようなサイトやサーバ群を複数管理するデータセンタでは、コンピュータシステムの消費電力の上昇も近年課題になってきており、消費電力の削減が望まれてきた。
【００１１】
ストレージ装置を集約するものとしては、例えば、「http://www.hitachi.co.jp/Prod/comp/storage/diskarray/what#san/nas.html」（以下、文献１）あるいは「ftp://download.intel.com/ebusiness/pdf/prod/infiniband/wp012501.pdf」（以下、文献２）で開示されるように、ローカルのストレージ装置を持たない複数のサーバが、ネットワーク等を介して一つのストレージ装置を共有するものが知られており、各サーバにストレージ装置を設けない分、サーバの消費電力（及びコンピュータシステムの冷却に要する電力）を低減すると共に小型化を推進してデータセンタなどにおけるサーバの配置密度を向上できる。
【００１２】
【発明が解決しようとする課題】
しかしながら、上記後者の従来例（文献１、２）は、上記図１５の従来例に比べて有利な点がある一方、ストレージ装置に格納されたコンテンツの更新が課題となる。つまり上記後者の例では、共有するストレージ装置の一つのボリュームを複数のサーバで共有する場合、このボリュームのコンテンツを更新するときには、このボリュームをアクセスしている全てのサーバをサイトから分離する必要がある。これはサイトの大きな性能低下、あるいはサイトへのアクセスの中断となる。
【００１３】
これを回避するためには、更新するコンテンツを別のボリュームに格納しておき、サーバのアクセスを切り換えていくことになるが、この場合、現用のボリュームと更新用のボリュームがそれぞれ必要となってしまい、更新用のボリュームを物理的なストレージ装置で確保しなければならないため、必要とするストレージ装置の容量が増大することになり、サーバからストレージ装置を削減した割にはストレージ装置の容量または数が増大してしまい、サーバ及びストレージ装置を合わせた電力消費の低減及び小型化を推進できない、という問題があった。
【００１４】
そこで本発明は、上記問題点に鑑みてなされたもので、複数のサーバで共有されるストレージ装置の数を削減して小型化及び消費電力の低下を図るとともに、サービスの低下を抑制しながら記憶内容の更新を行うことを目的とする。
【００１５】
【課題を解決するための手段】
本発明は、上記のコンテンツ更新の問題を解決するために、新しいコンテンツを保存するための仮想ボリューム２２（第２の仮想ボリューム）を生成し、この仮想ボリューム２２を図１６に示すストレージ機構１４〜１６（すなわち、仮想ボリューム２１と異なった仮想ボリューム）で実現する代わりに、図２で示すように仮想ボリューム２１（第１の仮想ボリューム）のストレージ機構１１〜１３で実現し、これらのストレージ機構１１〜１３を徐々に仮想ボリューム２１から仮想ボリューム２２に移動してから古いコンテンツと新しいコンテンツの差分を、仮想ボリューム２２へ移動したストレージ機構へ書き込む。
【００１６】
【発明の効果】
したがって、本発明によれば、仮想ボリューム２１のデータの更新を、新規に生成した仮想ボリューム２２へストレージ機構を移動してデータの差分を書き込むことにより、より数少ないディスク（ストレージ機構）でデータ（コンテンツ）の更新を実行しながら、コンテンツの更新を行うので、システム全体の性能低下を抑制でき、仮想ボリューム２１、２２を含む共有ストレージ装置を含むシステムの密度向上及び消費電力削減と、システムのサービス維持を両立させることができる。
【００１７】
【発明の実施の形態】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００１８】
図１は、本発明をＷｅｂサイト（以下、サイトという）に適用した一例を示し、インターネット５０からのアクセスを複数のサーバ（情報処理装置）５２１〜５２５に分散する負荷分散機（経路制御手段）５１と、これらサーバ５２１〜５２５が提供するコンテンツを格納したストレージ装置１と、これらのサーバ５２１〜５２５及びストレージ装置１を管理する管理サーバ４０とからＷｅｂサイトが構成される。
【００１９】
図１においてサーバ５２１〜５２５はストレージ装置を持たず、その代わりに共有ストレージ装置１を複数のサーバ５２１〜５２５で共有し、このストレージ装置１には、Ｗｅｂサイトのコンテンツを保存する仮想ボリューム２１が設定され、各サーバ５２１〜５２５は仮想ボリューム２１をアクセスする。なお、各サーバ５２１〜５２５と共有ストレージ装置１は、内部ネットワーク５２を介して接続されている。
【００２０】
この仮想ボリューム２１は複数のサーバ５２１〜５２５からアクセスされるため、仮想ボリューム２１には前記従来例の図１５で示したストレージ装置５１１〜５１５の複数台分の性能が必要である。
【００２１】
一方、仮想ボリューム２１は前記従来例の図１５に示したストレージ装置５１１〜５１５と同じコンテンツを持つため、同じ容量で十分である。このため、仮想ボリューム２１の構成としては、ＲＡＩＤ−１（ミラーリングとも呼ばれる）の構成が考えられる（“ＢｕｉｌｄｉｎｇＳｔｏｒａｇｅＮｅｔｗｏｒｋｓ”、ＩＳＢＮ０−０７−２１２０５０−９参照、以下参考文献３と呼ぶ）。
【００２２】
ここで、複数のサーバ５２１〜５２５で共有ストレージ装置１を共有するため、共有ストレージ装置１には仮想化エンジン（仮想化ソフトウェア）２０が設けられる。この仮想化エンジン２０が複数のストレージ装置１１〜１３の間でＲＡＩＤ−１の構成で仮想ボリューム２１を実現する。
【００２３】
そして、仮想化エンジン２０が仮想ボリューム２１のコンテンツのキャッシュを行うとともに、ストレージ装置１１〜１３間の最適化（仮想ボリューム２１へのアクセスをストレージ装置１１〜１３の間で分散すること等）を実現する。このキャッシュと最適化により、入出力の効率を向上し、例えば図１に示すとおり５台のサーバ５２１〜５２５に必要な性能を、３台のストレージ装置１１〜１３で実現できる。そして、このストレージ装置１１〜１３に相当するローカルストレージ装置を各サーバ５２１〜５２５から削減しているため、フロント・エンド・レイヤの密度の向上、そして消費電力の削減の効果がある。
【００２４】
ここで、共有ストレージ装置１の仮想化エンジン２０は、管理サーバ４０の管理ソフトウェア６０からの指令に応じて、仮想ボリュームの作成、削除、ボリューム間でのストレージ装置の移動を行い、また、各サーバ５２１〜５２５からのアクセスに応じてデータ（コンテンツ）を読み出す。
【００２５】
次に、共有ストレージ装置１の仮想ボリューム２１に格納されたコンテンツの更新について説明する。
【００２６】
図２〜図４は、コンテンツの更新の概要を示し、管理サーバ４０からの指令に基づいて仮想化エンジン２０が仮想ボリューム２２を作成し、この新規な仮想ボリューム２２に対して管理サーバ４０がデータの移動を行い、データの移動が完了した後には、古いコンテンツを保存していた仮想ボリューム２１を削除するものである。
【００２７】
まず、図２では、新しいコンテンツを保存するための仮想ボリューム２２を新規に作成する。この新規な仮想ボリューム２２に、既存の仮想ボリューム２１のストレージ装置１１を移動する。すなわち、ストレージ装置１１が所属するボリュームを既存の仮想ボリューム２１から新規に作成した仮想ボリューム２２に切り換える。
【００２８】
この時点では、仮想ボリューム２２のコンテンツとしてストレージ装置１１のコンテンツを使用するため、仮想ボリューム２１と仮想ボリューム２２は同じコンテンツを持つ。
【００２９】
その後、管理サーバ４０が古いコンテンツとの差分を仮想ボリューム２２のストレージ装置１１にコピーする。ここでは、古いコンテンツと新しいコンテンツの差分を仮想ボリューム２２のストレージ装置１１に書き込むものとする。この時点で、仮想ボリューム２２が新しいコンテンツを保存する。
【００３０】
そして、管理サーバ４０はサーバ５２１〜５２５が提供するコンテンツを更新するために、負荷分散機５１に対してサーバ５２１〜５２５を一台ずつサイトから分離（接続の解除）するよう順次指令して、サーバ５２１〜５２５は、サイトから切り離されている期間に、アクセスするボリュームを古いコンテンツ（仮想ボリューム２１）から新しいコンテンツ（仮想ボリューム２２）に変更する。なお、サーバーのサイトからの切り離しは、管理サーバ４０が負荷分散機５１に対してルーティングを変更するよう指令することで行われる。
【００３１】
そして、管理サーバ４０は、アクセスする仮想ボリュームの切り換えが終了すると、負荷分散機５１に対して、新しいコンテンツ（仮想ボリューム２２）をアクセスするサーバ５２１〜５２５をサイトに組み込むよう指令する。
【００３２】
このように、管理サーバ４０は、サーバ５２１〜５２５が提供するコンテンツを更新する（すなわち、サーバ５２１〜５２５がアクセスするコンテンツを一台ずつ仮想ボリューム２１から仮想ボリューム２２に変更する）。
【００３３】
そして、新しいコンテンツ（仮想ボリューム２２のデータ）をアクセスするサーバが多くなったら、図３に示すとおり、更にストレージ装置１２を仮想ボリューム２２に移動する。この移動も上記と同様であり、ストレージ装置１２が所属するボリュームを既存の仮想ボリューム２１から新規に作成した仮想ボリューム２２に切り換える。
【００３４】
ストレージ装置１２は、この時点で古いコンテンツ（仮想ボリューム２１のデータ）を保存するため、仮想化エンジン２０の処理によりストレージ装置１１から、古いコンテンツと新しいコンテンツとの差分をストレージ装置１２に書き込み、ストレージ装置１２のコンテンツを新しいコンテンツにする。
【００３５】
そして、この操作は、ストレージ装置１１とストレージ装置１２のコンテンツを同じにするため、仮想ボリューム２２でのＲＡＩＤ−１動作が可能となる。
【００３６】
最後に、図４に示すとおり、ストレージ装置１３を仮想ボリューム２２に移動する。そのときに、上記と同じく、ストレージ装置１１と１２からコンテンツの差分をストレージ装置１３に書き込む。その後、仮想ボリューム２１にストレージ装置が残らないため、仮想ボリューム２１を削除する。
【００３７】
上記更新の手順の一例としては、次の順番が考えられる（下記に「サーバを仮想ボリューム２２に変更する」というステップは、負荷分散機５１との分離と追加を含む）。
（１）仮想ボリューム２２を実現する（図２）
（２）サーバ５２１を仮想ボリューム２２に変更する
（３）サーバ５２２を仮想ボリューム２２に変更する
（４）ストレージ装置１２を仮想ボリューム２２に移動する（図３）
（５）サーバ５２３を仮想ボリューム２２に変更する
（６）サーバ５２４を仮想ボリューム２２に変更する
（７）サーバ５２５を仮想ボリューム２２に変更する
（８）ストレージ装置１３を仮想ボリューム２２に移動する（図６）
上記に述べたとおり、ストレージ装置１２〜１３を仮想ボリューム２１から新たな仮想ボリューム２２に移動するときに、これらストレージ装置１２〜１３に古いコンテンツと新しいコンテンツとの差分を書き込む。
【００３８】
このコピー（書き込み）のために、従来のＲＡＩＤ−１方法を拡張する。下記に、従来のＲＡＩＤ−１方法を説明したあと、本発明の方法を説明する。
【００３９】
まず、図１と図５を使用して従来のＲＡＩＤ−１の動作を説明する（図５が図１の状態に関係する）。
【００４０】
仮想ボリューム２１へのコンテンツ更新（データの書き込み）が行なわれたとき、仮想化エンジン２０は各ストレージ装置１１〜１３にその書き込みを行う。
【００４１】
仮想化エンジン２０は、仮想ボリューム２１への書き込みの状態を管理するために更新表３０〜３３を持つ。図５において更新表３０〜３３の「レ」印は、対応するストレージ装置１１〜１３のブロック３０に書き込みが完了したことを意味する。
【００４２】
仮想化エンジン２０は、仮想ボリューム２１への書き込みが行なわれたとき、書き込み対象のブロックの「レ」印を全て削除してから、各ストレージ装置への書き込みを行う。各ストレージ装置の反応が異なり、そして性能向上のために各ストレージ装置１１〜１３における複数の更新と読み出しの実行順番を選択するため、これらの書き込みが同時に行なわれない。このため、ある時点で、更新表３０〜３３のあるブロック３０に、更新されたストレージ装置と更新されていないストレージ装置が存在する（図５ではブロック２がその例である）。
【００４３】
仮想ボリューム２１からデータを読み出すときに（データがキャッシュになければ）読み出し対象とするブロックの、「レ」印が付いているストレージ装置１１〜１３からデータを読み出せる。
【００４４】
上記の動作は、更新管理の他に、仮想ボリューム２１からストレージ装置１１〜１３の一時的な分離も可能にする。
【００４５】
これは例えば仮想ボリューム２１更新中の、コンテンツのスナップショットのバックアップを作ることに役に立つ。例えば、ストレージ装置１１を仮想ボリューム２１から分離し、ストレージ装置１１のデータをテープ等のバックアップ装置にコピーし、その後にストレージ装置１１を仮想ボリューム２１に再び追加する。
【００４６】
ストレージ装置１１が分離している間に欄３１に関するの更新管理を継続する。その間に仮想ボリューム２１が更新された場合、欄３１の「レ」印が削除され、ストレージ装置１１を再び追加したときにこれらのブロックが更新される（参考文献３参照）。
【００４７】
以上は、従来のＲＡＩＤ−１の動作である。次に図６を使用して本発明の動作を説明する（図６は図２の状態に関係する。図６の符号１７、１８、１９の波線で示した図形は仮想ボリュームやストレージ装置でなく、共有ストレージ装置１内の空きスロットを示す）。
【００４８】
本発明の仮想化エンジン２０では、仮想ボリューム２２を作成するとき、その時点の更新表３０〜３３を複写し、新しい仮想ボリューム２２のための更新表３４〜３７を作成する。
【００４９】
そして、図４のように、全てのストレージ装置１１〜１３を仮想ボリューム２２に移動したときに、仮想ボリューム２１と一緒に更新表３０〜３３を削除する。
【００５０】
仮想ボリューム２２へ移動するストレージ装置（図６ではストレージ装置１１）の、仮想ボリューム２１での欄（図６では欄３１）を無効にし（図６では×マークで示す）、その時点以降その欄の「レ」印の更新を行なわない。
【００５１】
一方、まだ移動されていないストレージ装置（図６ではストレージ装置１２と１３）の、仮想ボリューム２２での空きスロット（図６では空きスロット１８と１９）にストレージ装置があることを想定し、更新表の欄（図６では欄３６と３７）の更新を、従来どおりに行なう。
【００５２】
このため、仮想ボリューム２２への書き込みが行なわれたら、空きスロット１８、１９の「レ」印が削除されるが、書き込みができないため「レ」印が付かない。仮想ボリューム２２にストレージ装置を移動したときに、「レ」印が付けられていないブロックが更新されるので、更新されたブロックのみ（すなわち、データの差分）がこの移動されたストレージ装置に書き込まれる。
【００５３】
つまり、このデータ以外、仮想ボリューム２２を作成した時点の、仮想ボリューム２１で書き込まれていなかったデータも書き込まれる。そのデータが既に仮想ボリューム２１で書き込まれていれば、二重書き込みとなる。しかし、仮想ボリューム２２を作成するときに、仮想ボリューム２１に更新されていないブロックがない、あるいは非常に少ないと考えられるため、二重書き込みによる性能低下が小さい。
【００５４】
そして、本発明のストレージ装置１１〜１３の移動は、古いコンテンツを保存している仮想ボリューム２１から、新しいコンテンツを保存する仮想ボリューム２２へストレージ装置１１〜１３が順次追加され、追加されたストレージ装置１１〜１３は上記更新表に基づいて書き込みが行われて、更新されたコンテンツを保存することになる。
【００５５】
次に、管理サーバ４０の管理ソフトウェア６０で実行されるコンテンツの更新処理について、図７のフローチャートを参照しながら説明する。なお、図７のフローチャートは、インターネット５０側からコンテンツの更新要求があったとき、または、管理サーバ４０でコンテンツの更新を行う際に実行されるもので、ここでは、管理サーバ４０のストレージ装置４１に更新する新たなコンテンツが既に保存されているものとする。
【００５６】
まず、ステップ６０１では、共有ストレージ装置１の仮想化エンジン２０に対して新規の仮想ボリューム２２（図２参照）を作成する命令を送信する。
【００５７】
次に、ステップ６０２では、新しいコンテンツと古いコンテンツとの差分を仮想ボリューム２２に書き込む。これで仮想ボリューム２２が、新しいコンテンツを保存することになる。
【００５８】
そして、ステップ６０３では、共有ストレージ装置１の仮想ボリューム２１（古いコンテンツ）にアクセスしているサーバ（ホスト）５２１〜５２５を、新たに作成した仮想ボリューム２２（新しいコンテンツ）にアクセスするよう、各サーバ５２１〜５２５及び負荷分散機５１に指令する。
【００５９】
このステップ６０３では、次の３つの処理を含み、上記（２）、（３）、（５）〜（７）に相当する。
（Ａ）負荷分散機５１に対して一つのサーバをサイトから切り離すように指令する。
（Ｂ）次に、サイトから分離したサーバに対してアクセスするボリュームを仮想ボリューム２１から新しいコンテンツを含む仮想ボリューム２２に切り換えるよう指令する。
（Ｃ）アクセス先を仮想ボリューム２２に変更したサーバを再びサイトに接続するよう、負荷分散機５１に指令する。
【００６０】
以上（Ａ）〜（Ｃ）の処理を実行することで、一つのサーバが一旦サイトから切り離されている間に、サーバがアクセスするボリュームを更新されたコンテンツを含む仮想ボリューム２２に切り換える。
【００６１】
次に、ステップ６０４では、ストレージ装置１１〜１３を仮想ボリューム２１から仮想ボリューム２２へ移動するか否かを判定する。
【００６２】
この判定は、仮想ボリューム２１、２２の負荷とストレージ装置の数などから判定が行われ、その一例としては、
【００６３】
【数１】

を満たすときに、ステップ６０５へ進んでストレージ装置１１〜１３の移動を行う一方、そうでない場合には、ステップ６０６に進む。ただし、仮想ボリューム２１、２２の負荷としてサーバの接続数とし、仮想ボリューム２１の最後のストレージ装置の場合には、負荷＝サーバ接続数が０でなければ、そのままステップ６０６に進む。
【００６４】
ここで、仮想ストレージ装置の負荷としては、接続しているサーバの数としたが、これに限定されるものではなく、「負荷」としてホスト（サーバ）数、アクセス負荷（秒当たりのバイト数）等が考えられる。
【００６５】
ステップ６０５では、共有ストレージ装置１の仮想化エンジン２０に対して古いコンテンツを保存している仮想ボリューム２１のストレージ装置を、新しい仮想ボリューム２２へ移動するよう指令する。
【００６６】
そして、ステップ６０６では、古いコンテンツを保存している仮想ボリューム２１にアクセスしているサーバがあるか否かを判定して、仮想ボリューム２１にアクセスしているサーバがあればステップ６０３の処理に進んで、アクセスする仮想ボリューム２２の切り換えを行う。
【００６７】
以上により、管理サーバ４０の管理ソフトウェア６０は、共有ストレージ装置１に対して仮想ボリュームの作成を指令してから、更新するコンテンツまたは更新するコンテンツの差分をストレージ装置４１から共有ストレージ装置１に書き込んだ後、各仮想ボリュームの負荷を見ながら、共有ストレージ装置１のストレージ装置１１〜１３を仮想ボリューム２２へ移動してコンテンツの更新を行うとともに、負荷分散機５１によってサイトから切り離したサーバは、アクセスする仮想ボリュームを順次切り換えていく。
【００６８】
次に、図８〜図１０を参照しながら共有ストレージ装置１の仮想化エンジン２０で行われる処理の一例について説明する。
【００６９】
図８は仮想化エンジン２０のメインルーチンを、図９は新規ボリューム作成のサブルーチンを、図１０はストレージ装置移動のサブルーチンをそれぞれ示す。
【００７０】
まず、図８において、ステップ６１１、６１２では、命令（指令）の受信を待って、管理サーバ４０から命令を受信すると、ステップ６１３で新規ボリューム作成の命令かを判定し、ステップ６１５ではストレージ装置の移動命令であるかを判定する。
【００７１】
そして、新規ボリューム作成の命令を受信した場合にはステップ６１４に進んで新たな仮想ボリュームを作成し、ストレージ装置の移動命令を受信した場合にはステップ６１６に進んで仮想ボリューム２１から２２へストレージ装置１１〜１３を移動する。
【００７２】
なお、その他の命令を受信した場合にはステップ６１７で命令に応じた処理を行う。その他の命令として、例えば、上記で説明した従来技術の仮想ボリュームからストレージ装置を分離するための命令、再び追加するための命令などが挙げられる。
【００７３】
上記ステップ６１１〜６１７を繰り返すことで、管理サーバ４０やサーバ５２１〜５２５からの命令に応じた処理を行う。
【００７４】
次に、上記ステップ６１４で行われる新規ボリュームの作成処理について図９のフローチャートを参照しながら説明する。
【００７５】
図９において、ステップ６３１では、共有ストレージ装置１内に、更新したコンテンツを保存するための仮想ボリューム２２を作成するとともに、上記図６で説明したように更新表３０〜３３を複写して新たな更新表３４〜３７を作成する。
【００７６】
そして、ステップ６１６では、古いコンテンツを保存している仮想ボリューム２１から、ひとつのストレージ装置１１を新たに作成した仮想ボリューム２２に移動させる。
【００７７】
これにより、仮想ボリューム２２を作成した時点ではストレージ装置数が０であるが、上記ステップ６１６の処理によって、最初のストレージ装置の移動を完了させておく。
【００７８】
次に、上記ステップ６１６で行われるストレージ装置の移動処理の一例を、図１０に示すフローチャートを用い説明する。
【００７９】
まず、ステップ６４１では、上記図６で示した更新表のように、ストレージ装置（例えば、１１）の更新欄３１の一列を無効にして、このストレージ装置を古いコンテンツを保存している仮想ボリューム２１から分離する。
【００８０】
次に、仮想ボリューム２１から分離されたストレージ装置を新たなコンテンツを保存する仮想ボリューム２２に接続し、仮想ボリューム２２には新たなストレージ装置が追加され、上記更新表３４〜３７に基づいて、追加されたストレージ装置には更新したコンテンツの差分が書き込まれる。
【００８１】
次に、ステップ６４３では、古いコンテンツを保存する仮想ボリューム２１に、まだ移動が行われていないストレージ装置の有無を判定し、移動するストレージ装置がなくなった場合にはステップ６４４へ進んで古いコンテンツを保存していた仮想ボリューム２１及び更新欄３１を削除してから終了する。
【００８２】
なお、移動するストレージ装置が仮想ボリューム２１にある場合では、そのまま処理を終了する。
【００８３】
こうして、データの書き込みのとき、仮想ボリューム２１、２２間でのストレージ装置１１〜１３の移動を所定数ずつ（ここでは、ひとつずつ）行い、かつ、サーバ５２１〜５２５のアクセス先の変更も所定数（ここではサーバをひとつ）ずつ行うため、インターネット５０側からの要求に応答しながら、ひとつの共有ストレージ装置１内でコンテンツの更新を円滑に行うことができるのである。
【００８４】
そして、共有ストレージ装置１の複数のストレージ装置１１〜１３を、順次古いコンテンツを保存する仮想ボリューム２１から新しいコンテンツを保存する仮想ボリューム２２へ移動し、移動した仮想ボリューム２２において新たなコンテンツの更新を行うので、共有ストレージ装置１は前記従来例で述べたような更新用の物理的なストレージ装置を必要としないため、サイト全体、すなわち、ストレージ装置を持たない複数のサーバ５２１〜５２５と共有ストレージ装置１の小型化と消費電力の削減とを推進できるのである。
【００８５】
そして、サーバ５２１〜５２５及び共有ストレージ装置１の小型化により、システム全体の密度を向上させることが可能となり、また、ストレージ装置１１〜１３の移動に当たっては、アクセス負荷に応じて移動する数を決定するので、コンテンツの更新を行う際に、サイトの性能低下を最小限に留めることができ、前記従来例のように、サイトへのアクセスの中断やサイトの大きな性能低下を引き起こすことが無くなり、可用性の高いサイトを構築することが可能となる。
【００８６】
本発明はすでに記載した実施の形態、あるいはその変形例に限定されるのではなく、以下に例示する変形例あるいは他の変形例によっても実現可能であることは言うまでもない。また、上記複数の実施の形態あるいはその変形例として記載の技術、あるいは以下の変形例の組み合わせによっても実現できる。
【００８７】
（変形例１）本発明は、インターネット５０に接続するデータセンタ、そしてフロント・エンド・レイヤに制限されておらず、複数のサーバ等の情報処理装置がストレージ装置を共有する場合に使用できる。
【００８８】
（変形例２）本発明は図１、そして図２〜図６の、共有ストレージ装置１に限定されるものではなく、他の構成であってもよい。例えば、図１１で示すように、仮想化エンジン２０が仮想化装置２３にあり、そしてストレージ装置１１〜１３が仮想化装置２３と分離され、ネットワーク５３を介して接続されている構成とすることもでき、仮想化装置２３がネットワーク５３を介して複数のストレージ装置１１〜１３をアクセスすることになる。
【００８９】
図１２にさらに別の構成を示す。この構成では、サーバ５２１〜５２５と管理サーバ４０の中に仮想化エンジン５３１〜５３６をそれぞれ装備し、各サーバがネットワーク５２を介して複数のストレージ装置１１〜１３に接続されるものである。
【００９０】
この構成では、仮想化エンジン５３１〜５３６が分散しているため、動作が以上の実施例と異なる。
【００９１】
すなわち、管理サーバ４０の仮想化エンジンの５３６のみが上記図６で示した更新表３０〜３３、３４〜３７を持つ。
【００９２】
管理サーバ４０が仮想ボリューム２２の作成やストレージ装置１２、１３の移動をするときに、各仮想化エンジン５３１〜５３５にその命令を送信する必要がある。
【００９３】
そして、これらの動作を二つのステップで実現する。仮想ボリューム２２を作成するとき、一つ目のステップとして各仮想化エンジン５３１〜５３５でストレージ装置１１を分離し、そして二つ目のステップとして仮想ボリューム２２を実現する。
【００９４】
ストレージ装置１２、１３の移動のとき、一つ目のステップとして、各仮想化エンジン５３１〜５３５で移動するストレージ装置１２、１３を分離し、二つ目のステップとして差分を更新してからストレージ装置１２、１３を仮想ボリューム２２に追加する。上記の各更新では、コンテンツを全てアップデートする（すなわち、サーバ５２１〜５２５がアクセスしていない間に更新されるストレージ装置１１〜１３の更新表３０〜３３、３４〜３７の欄に全て「レ」印をつけるまで待つ）。これは、各サーバ５２１〜５２５が更新表３０〜３３、３４〜３７を持たないため、各ストレージ装置１１〜１３のコンテンツが全て更新されていることを前提にする。
（変形例３）また、本発明は３つのストレージ装置１１〜１３で共有されるストレージ群（共有ストレージ装置１）を構成したが、ストレージ装置１１〜１３の数は任意に設定すればよく、２つ以上のストレージ装置で実現できる。
【００９５】
（変形例４）また、上記実施形態においては、図１５、図１、図１１、図１２で示したように、ネットワーク５２と５３を介してサーバ５２１〜５２５とストレージ装置１１〜１３を接続したが、ネットワークの代わりに、直接接続も可能であり、また、負荷分散機５１とサーバ５２１〜５２５の間の接続をネットワークで実現することも考えられる。
【００９６】
（変形例５）また、本発明は、上記図５と図６にて説明したＲＡＩＤ−１に適用した例について述べたが、これに限定されるものではなく、他のＲＡＩＤ−１実現方法にも適用できる。
【００９７】
（変形例６）上記実施形態において、ストレージ装置１１〜１３はディスクに制限しておらず、例えばそれぞれのストレージ装置１１〜１３が更にＲＡＩＤで構成されていてもい。例えば、日立のＨＯＭＲＣＦ（Hitachi Open Multiple RAID Coupling Feature）は複数のボリュームの間でＲＡＩＤ−１と同様なミラーリングを実現するが、各ボリュームをＲＡＩＤとして構成することが可能である（“ＨＯＭＲＣＦユーザガイド”参照）。
【００９８】
（変形例７）また、上記の図６の動作の説明は、仮想ボリューム２２を作成したあと、この仮想ボリューム２１が更新されないことを前提にしたが、仮想ボリューム２１が更新されたとき、書き込みの前に、このボリュームのストレージ装置（図６ではストレージ装置１２と１３）の更新表の欄（図６では欄３２と３３）の「レ」印だけでなく、仮想ボリューム２２に対応する欄（図６では３６と３７）も削除する。このため、ストレージ装置（図６では１２と１３）を仮想ボリューム２２に移動したときに、これらのブロックが再び仮想ボリューム２２のコンテンツに変更される。
【００９９】
（変形例８）また、本発明では、管理サーバ４０が仮想化エンジン２０、５３１〜５３５に命令を送り、仮想ボリューム２１、２２の間でストレージ装置１２、１３を移動すると述べたが、本発明はこの動作に限定されるものではない。例えば、仮想化エンジン２０、５３１〜５３５が、各仮想ボリューム２１、２２へのアクセス負荷を測定し、及びまたは各仮想ボリューム２１、２２をアクセスしているサーバ５２１〜５２５の台数を調べ、この負荷及びまたは台数のある関数で各仮想ボリューム２１、２２のストレージ装置１１〜１３の台数を決定することが考えられる。
【０１００】
この関数として、まず、各仮想ボリューム２１、２２のアクセス負荷の比例に応じて、ストレージ装置１１〜１３を合わせることが考えられる。そして、負荷の増加を測定して、移動が必要な時点を予想することも考えられる。
【０１０１】
本変形例の構成における管理サーバ４０及び各サーバ５２１〜５２５で行われる処理を図１３、図１４のフローチャートに示す。
【０１０２】
図１３は、管理サーバ４０での処理を示し、上記図７のフローチャートからステップ６０４、６０５を削除したもので、仮想ボリューム２２の作成命令を各仮想化エンジン２０、５３１〜５３５へ送信した後、仮想ボリューム２２のコンテンツを更新し、次に、負荷分散機５１によりルーティングを制御してサーバ５２１〜５２５をサイトから順次切り離し、その間にアクセスする仮想ボリュームを変更するものである。
【０１０３】
図１４は、各仮想化エンジン２０、５３１〜５３５で行われる処理を示し、上記図８のフローチャートにおけるステップ６１５を削除する一方、ステップ６０４（上記図７参照）をステップ６１７の後に設けたものである。
【０１０４】
この場合、管理サーバ４０からの命令がない場合には、ステップ６０４でストレージ装置１２〜１３の移動条件を判定し、移動条件が成立した場合にはステップ６１６でストレージ装置の移動を行い、移動条件が成立しない場合には、ステップ６１１に戻ってループを繰り返すものである。
【０１０５】
（変形例９）上記実施形態においては、ストレージ装置１１〜１３がブロックストレージの場合を示したが、本発明はこの形態に限定されるものではなく、例えばファイルベースのストレージ装置（ＮＡＳ：Ｎｅｔｗｏｒｋ−ＡｔｔａｃｈｅｄＳｔｏｒａｇｅ）にも適用できる。ＮＡＳ装置の場合の実現方法の例として、各ファイルに更新表３０〜３３を作成することが考えられる（ブロックの欄３０はファイルの中のブロックを示す）。仮想ボリューム２２を作成するとき、全ての更新表３０〜３３をコピーする。そして、ファイルを削除したときにその更新表３０〜３３を削除する。
【０１０６】
（変形例１０）上記実施形態においては、ストレージ装置を一つずつ新しい仮想ボリュームへ移動する例について述べたが、ストレージ装置を移動して新しい仮想ボリューム２２を作成する動作と、仮想ボリューム２１、２２の間でストレージ装置を移動する動作は、移動するストレージ装置の数を複数とすることもでき、仮想ボリューム２１から複数のストレージ装置を切り離して、これらのストレージ装置で新しい仮想ボリューム２２を作成し、その後、仮想ボリューム２１から２２へのストレージ装置の移動を複数個ずつ行ってもよい。
【０１０７】
なお、本発明を実施するためのプログラムは、それ単独であるいは他のプログラムと組み合わせて、ディスク記憶装置等のプログラム記憶媒体に記憶された販売することができる。また、本発明を実施するためのプログラムは、すでに使用されている通信を行うプログラムに追加される形式のプログラムでもよく、あるいはその通信用のプログラムの一部を置換する形式のプログラムでも良い。
【０１０８】
また、外部から受信したコマンドまたは設定情報のうち少なくとも一方に基づいて前記第二ボリュームを生成することを特徴とする請求項１に記載のストレージ方法であってもよい。
【０１０９】
また、外部から受信したコマンドまたは設定情報のうち少なくとも一方に基づいて、前記第一ボリュームから分離したストレージ機構を前記第二ボリュームに移動し、保存データの差分を書き込むことを特徴とする請求項１に記載のストレージ方法であってもよい。
【０１１０】
また、送信したコマンドまたは設定情報のうち少なくとも一方に基づいて前記第二ボリュームを生成することを特徴とする請求項１に記載のストレージ方法であってもよい。
【０１１１】
また、送信したコマンドまたは設定情報のうち少なくとも一方に基づいて、前記第一ボリュームから分離したストレージ機構を前記第二ボリュームに移動し、保存データの差分を書き込むことを特徴とする請求項１に記載のストレージ方法であってもよい。
【０１１２】
今回開示した実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び内容の範囲での全ての変更が含まれることが意図される。
【図面の簡単な説明】
【図１】本発明の実施形態を示し、Ｗｅｂサイトの概略構成図。
【図２】共有ストレージ装置に仮想ボリュームを生成し、ひとつのストレージ装置を移動した状態を示す説明図。
【図３】生成した仮想ボリュームに、さらにストレージ装置を移動した状態を示す説明図。
【図４】生成した仮想ボリュームに、全てのストレージ装置を移動し、古いコンテンツを保存していたボリュームを削除した状態を示す説明図。
【図５】従来のＲＡＩＤ−１の動作を示す説明図で、ストレージ装置と更新表の関係を示す。
【図６】本発明におけるＲＡＩＤ−１の動作を示す説明図で、ボリューム及びストレージ装置と更新表の関係を示す。
【図７】管理サーバで行われる処理の一例を示すフローチャート。
【図８】仮想化エンジンで行われる処理の一例を示すフローチャートでメインルーチンを示す。
【図９】同じく、新規ボリュームを作成するサブルーチンである。
【図１０】同じく、ストレージ装置の移動を行うサブルーチンである。
【図１１】他の形態のＷｅｂサイトの概略構成図である。
【図１２】さらに他の形態のＷｅｂサイトの概略構成図である。
【図１３】同じく管理サーバで行われる処理の一例を示すフローチャート。
【図１４】同じく仮想化エンジンで行われる処理の一例を示すフローチャート。
【図１５】従来例を示し、ストレージ装置を備える複数のサーバで構成されたＷｅｂサイトの概略構成図。
【図１６】複数の仮想ボリュームにそれぞれストレージ装置を収容した場合の概略構成図。
【符号の説明】
１共有ストレージ装置
１１〜１３ストレージ装置
２０仮想化エンジン
２１、２２仮想ボリューム
４０管理サーバ
５１負荷分散機
５２１〜５２５サーバ

Claims

複数のストレージ機構から構成された第１の仮想ボリュームを含むストレージ装置と、
前記ストレージ装置を管理する管理サーバと、を備えたストレージシステムにおいて、前記複数のストレージ機構に同一のコンテンツを格納し、前記管理サーバが前記ストレージ装置に格納されたコンテンツを更新するストレージシステムのコンテンツ更新方法であって、
前記管理サーバが、前記ストレージ装置に対して新たな仮想ボリュームを第２の仮想ボリュームとして生成させる第１の手順と、
前記管理サーバが、前記第１の仮想ボリュームから同一のコンテンツを格納した複数のストレージ機構のうちのひとつを前記第１の仮想ボリュームから分離して第２の仮想ボリュームへ切り替える第２の手順と、
前記管理サーバが、前記第２の仮想ボリュームへ移動した前記ストレージ機構のコンテンツを新たなコンテンツに更新する第３の手順と、
前記第２の手順から前記第３の手順を繰り返し、前記第１の仮想ボリュームのストレージ機構を順次第２の仮想ボリュームへ移動する第４の手順と、
を含むことを特徴とするストレージシステムのコンテンツ更新方法。
前記第３の手順は、
前記第２の仮想ボリュームに移動したストレージ機構に対して更新前のコンテンツと更新後のコンテンツとの差分のデータを書き込むことを特徴とする請求項１に記載のストレージシステムのコンテンツ更新方法。
前記第４の手順は、
前記第１の仮想ボリュームと第２の仮想ボリュームのアクセス負荷またはアクセスする情報処理装置の数のうち少なくとも一方に基づいて、前記第２の仮想ボリュームのストレージ機構の数を決定する手順をさらに含み、前記決定した数を満たすまで前記第２の手順から前記第３の手順を繰り返して実行することを特徴とする請求項１に記載のストレージシステムのコンテンツ更新方法。
前記第４の手順が完了した後に、前記ストレージ装置にアクセする情報処理装置のアクセス先を前記第１の仮想ボリュームから前記第２の仮想ボリュームへ切り替える第６の手順と、
前記第１の仮想ボリュームを削除する第７の手順と、
をさらに有することを特徴とする請求項１に記載のストレージシステムのコンテンツ更新方法。