JP2005056077A

JP2005056077A - データベース制御方法

Info

Publication number: JP2005056077A
Application number: JP2003285215A
Authority: JP
Inventors: Frederico Mashel; マシエル・フレデリコ; Daisuke Ito; 大輔伊藤; Kazutomo Ushijima; 一智牛嶋; Shinji Fujiwara; 真二藤原
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-08-01
Filing date: 2003-08-01
Publication date: 2005-03-03
Also published as: US7167854B2; US20050027719A1

Abstract

【課題】無共有型データベースにおいて、ホストとストレージの動的な構成変更を迅速に行う。
【解決手段】複数のホスト１１〜１４でそれそれ実行されるプロセス２４〜２９が、ストレージ装置３０のデータにアクセスする無共有型のデータベースと、ホスト１１〜１４とストレージ装置３０を管理するシステム管理機構７０及びＤＢ管理機構１０とを有し、プロセス２４〜２９は、ストレージ装置の一つまたは複数のディスク５１〜５４を専有してアクセスし、ホストの数を追加または削減するときには、プロセス２４〜２９の割り当てをホスト１１〜１４の間で変更する。
【選択図】図２

Description

本発明は、データベース、特に無共有型のデータベース処理をするホストの台数またはデータベースのデータを保存するディスクの追加または削減に関する。

データベース（以下、ＤＢ）処理（検索など）性能を向上する方法として、複数のＣＰＵと複数のディスクを同時に使用し、処理を並列化することが良く用いられる。この並列化を実現するアーキテクチャの一つとして、図６に示す無共有型（Shared−nothing）データベースがある。無共有型データベースは、複数のホスト１１〜１４（サーバ等の、ＣＰＵを持つ情報処理装置）と複数のディスク８１〜８４からなる。各ホストは、データベース処理を行う一つまたは複数のＤＢプロセス（処理を行うジョブ）２０〜２３を実行する。（本発明では、「データベース」を表などのデータでなく、情報処理装置、ネットワーク、ストレージからなりデータベース処理を行うシステムという意味で使用する）。

無共有型データベースの特長として、各ホスト１１〜１４はそれぞれのホストに属するディスクのみをアクセスする。例えば、ホスト１１はディスク８１をアクセスするが、ディスク８２〜８４をアクセスしない。必要な場合、ホスト１１〜１４はホスト１１〜１４の間でデータを交換してデータベース処理をする（このデータ交換は図示しない）。これで各ホストを同期させることが少なくなり、データベースのスケーラビリティを向上する。

無共有型データベースのＤＢ管理機構１１０は、データベースをアクセスするクライアントのクエリー（問い合わせ）を受け、処理をホスト１１〜１４に分配し、ホスト１１〜１４の処理結果をまとめ、クエリーの結果をクライアント（図示省略）に返す。

無共有型データベースの例として、HiRDBやDB2がある（DB2についてはIBM、「IBM DB2 Universal Database Administration Guide: Planning」、「平成１５年７月１日検索」、インターネット＜http://www.linguistik.uni-erlangen.de/tree/pdf/DB2/db2d0e50.pdf＞、SC09-4822-00を参照。図６に示したホスト１１〜１４はDB2のパーティションに相当する）。

無共有型データベースを拡張するとき、ホスト１１〜１４とディスク８１〜８４を追加する。以降、図６の破線の角丸四角形に囲まれているホスト１３、１４とディスク８３、８４が追加された例について説明する。

ホスト１３、１４を追加した時点では、追加するディスク８３、８４にデータがないため、ホスト１３、１４は処理ができない。その結果、処理がホスト１１と１２に集中し、効率的な並列化ができない。

この問題の解決方法としてデータを再配分する機能を持つ（IBM、「IBM DB2 Universal Database Administration Guide: Performance」、SC09-4821-00参照）。以降、この再配分の機能を「リバランス」と呼ぶ。リバランスするとき、ＤＢプロセス２０〜２３がディスク８１〜８４をアクセスしながらデータを交換し、データを均等にディスク８１〜８４に再配分する。その結果、データベースの処理性能が向上する。HiRDB（「HiRDB7」、日立製作所、「平成１５年７月１日検索」、インターネット＜ＵＲＬ：http://www.hitachi.co.jp/Prod/comp/soft1/hirdb/index.html＞）では、オンラインで（処理を中断しないで）リバランスを行うことができる。

データベースを含むシステムの管理者がシステムを運用するために、システム管理機構１７０を使用する（上記図６では、データベース以外のシステムのコンポーネントを省略した）。システム管理機構１７０はデータベースなどの、システムの各コンポーネントの性能や可用性をモニタリングし、管理者が指定したポリシーにより各コンポーネントを制御する。システム管理機構１７０の例として、ＪＰ１が知られている（「Job Management Partner Version 6i」、日立製作所、「平成１５年７月１日検索」、インターネット＜ＵＲＬ：http://www.hitachi.co.jp/Prod/comp/soft1/jp1/html/sei.html＞）。

一方、共有型（Shared−data）のデータベースでは、ハードウェア構成の動的な変更を可能にするものが知られている（特許文献１）。
米国特許第６４０５２８４号明細書

しかしながら、上記のような無共有型データベースにおいては、以下のような問題がある。

第一の課題は、無共有型データベース拡張の柔軟性不足である。無共有型データベースを拡張するとき、ホストとそれらに対応するディスクを同時に拡張する必要がある。しかしながら、無共有型データベースにおいては、ホストとディスクを別々に拡張することができないため、処理能力（ホスト台数）とストレージの容量と性能（ディスク台数）を適切にバランスすることが難しい、という問題があった。

例えば、図６において、ホスト１３、１４を追加する場合、これらのホストに対応するディスク８３、８４も追加する必要がある。追加した時点ではディスク（物理ディスク）８３、８４にデータが入っていないため、既に稼動しているホスト１１、１２のディスク８１、８２から新たに追加したディスク８３、８４にデータを再配分する必要がある。

この再配分の際に、ホスト１１、１２はデータベース処理に加えて再配分処理が必要になり、ホスト１１、１２の負荷が過大になって、データベース処理が遅延する場合がある。また、再配分処理には時間を要し、特に、大規模なデータベースでは、再配分処理に１日程度の時間を要する場合がある。このため、無共有型データベースを迅速に拡張するのは難しい、という問題があった。

第二の課題は、データベース再構成時間に関する。近年、システムの効率を向上し、コストを削減するために、グリッド技術が採用されてきて、この中でシステム再構成を行う。システム再構成の方法は様々な形態があるが、次の例が挙げられる。
（１）Ｗｅｂサイト等の、アクセスのピークが生じたときにホスト台数を増やす。
（２）昼間オンラインで処理するシステムの一部を、夜間（オンライン負荷が軽減したとき）にバッチ処理に変更する。
（３）特定の時期（セール、期末集中、連休等）に処理のピークが生じたときにホスト台数を増やす。

これらの３つの再構成を実現するシステムの一例として、VPDCがある（Mineyoshi Masuda, Yutaka Yoshimura, Toshiaki Tarui, Toru Shonai, Mamoru Sugie,「VPDC: Virtual Private Data Center (A Flexible and Rapid Workload-Management System), The 8th IFIP/IEEE International Symposium on Integrated Network Management (IM2003), March 2003参照」）。

しかしながら、上記システム再構成の中で、データベースの再構成は、ホストまたはディスクの、追加または削減を意味する。この再構成を実現する方法としてはリバランスが考えられる。この、リバランスは処理量が多く、前述の再配分処理と同様に、多大な時間を要する。特に、オンラインでリバランスを行うとき、リバランスと通常のデータベース処理が同時に行われるため、リバランス時間が更に長くなる。従来、リバランスはめったにしないことであったため、その処理時間は問題にならなかったが、システム再構成を頻繁に行う場合にはリバランスを使用できない、という問題があった。

そこで本発明は、上記問題点に鑑みてなされたもので、無共有型データベースにおいて、ホストとストレージの動的な構成変更を迅速に行うことを目的とする。

本発明は、複数の情報処理装置でそれそれ実行されるプロセスが、ストレージのデータにアクセスする無共有型のデータベースと、前記情報処理装置とストレージを管理する管理手段とを有し、前記プロセスは、管理手段によって設定された前記ストレージの一つまたは複数のボリュームを専有してアクセスしてデータベース処理を行い、前記情報処理装置の数を追加または削減するときには、前記管理手段が前記プロセスの割り当てを情報処理装置の間で変更する。

また、複数の情報処理装置でそれそれ実行されるプロセスが、仮想ボリュームを含むストレージのデータにアクセスする無共有型のデータベースと、前記情報処理装置とストレージを管理する管理手段とを有し、ストレージは仮想ボリュームを物理ボリュームに関連付けてデータのアクセスを行い、前記プロセスは、管理手段によって設定された前記ストレージの一つまたは複数の仮想ボリュームを専有してアクセスし、前記情報処理装置または物理ボリュームを追加または削減するときには、前記管理手段が、前記プロセスに設定される仮想ボリュームと物理ボリュームの割り当て変更を、前記ストレージに起動させる。

したがって、本発明は、無共有型データベースを処理する複数の情報処理装置の間で、割り当ての変更によりプロセスを移動することで、情報処理装置の数の追加と削減を行うことで、無共有型データベースの情報処理装置の追加、削減を迅速かつ容易に行うことができ、さらに、リバランスを不要にして可用性を高めることができる。

また、物理ボリュームを追加または削減するときには、管理手段が、プロセスに設定される仮想ボリュームと物理ボリュームの割り当て変更をストレージで起動するようにしたので、無共有型データベースを物理ボリュームの追加または削減を迅速かつ容易に行うことができる。

これにより、情報処理装置と物理ボリュームを別々に拡張することを可能となり、無共有型データベースの動的な再構成を迅速に実現できる。このため、データベースの処理能力（情報処理装置の台数）と、ストレージの容量と性能（物理ボリュームの数）を適切にバランスすることが可能となる。この他に、前記従来例より速いデータベース再構成を可能にする。これにより、無共有型データベースが対応できる分野（予想できないピークの対応、昼間のオンライン処理と夜間バッチの切り換え、等）を広げることが可能となる。

以下、本発明の実施形態の説明を３つの実施形態に分けて説明する。第１実施形態ではホストの追加／削減方法を、第２実施形態ではディスクの追加／削減方法を、第３実施形態では追加／削減の決定方法を説明する。

＜全体の構成＞
図１は、無共有型（Shared−nothing）データベースの一例を示す。

無共有型データベースは、複数のホスト１１、１２（データベースサーバ等の、ＣＰＵやメモリ及びＩ／Ｏ等を持つ情報処理装置）と複数のディスク８１〜８４から構成される。各ホストは、データベース処理を行う一つまたは複数のデータベースプロセス（以下ＤＢプロセス）２４〜２７を実行する。（本発明では、「データベース」を表などのデータでなく、情報処理装置、ネットワーク、ストレージからなりデータベース処理を行うシステムという意味で使用する）。なお、各ＤＢプロセス２０〜２３は、処理を行うジョブを示す。なお、図中ホスト１３、１４は、後述するように追加されるホストを示す。

各ホスト１１、１２では複数のＤＢプロセス２４〜２７がそれぞれ実行されており、各ＤＢプロセス２４〜２７は、割り当てられたディスク（またはボリューム）５１〜５４との間でデータの読み書きを行う。

これらのディスク５１〜５４は、システム管理機構７０によって制御されるストレージ装置３０に収装される。そして、このストレージ装置３０は、ストレージエリアネットワーク（以下、ＳＡＮ）６０を介して各ホスト１１〜１４に接続される。なお、ＳＡＮ６０も、システム管理機構７０によって制御されるもので、複数のスイッチやループ型接続で構成される。

ＳＡＮ６０及びストレージ装置３０は、ＤＢプロセス間のディスク（またはボリューム）共有手段としてとして機能する。

ホスト１１、１２は、データベース管理機構（以下、ＤＢ管理機構）１０からの指令を受けて、データベース処理を行うものである。このＤＢ管理機構１０は、クライアント９０からのリクエストを受けて、実際に処理を行うＤＢプロセスまたはディスク（またはボリューム）を決定する。そして、ＤＢ管理機構１０は、各ＤＢプロセスからのデータベース処理結果をクライアント９０へ返信する。

なお、ＤＢ管理機構１０は、例えば、所定のハードウェア（サーバ等）上で機能するプラグラムなどで構成され、換言すれば、ＤＢ管理機構１０がフロントエンドサーバであり、ホスト１１〜１４がバックエンドサーバである。

ＤＢ管理機構１０は、データベースシステム全体を監視し、管理するシステム管理機構７０によって制御される。システム管理機構７０は、上述の「ＪＰ１」等のようにデータベースなどのシステムの各コンポーネントの性能や可用性をモニタリングし、システム管理者が指定したポリシーにより各コンポーネントを制御する。

例えば、システム管理機構７０は、各ホスト１１、１２の処理負荷を監視し、処理負荷が大きくなるとＤＢ管理機構１０にホストの追加を指令したり、ＳＡＮ６０やストレージ装置３０に対して各ＤＢプロセス２４〜２７に割り当てるディスク５１〜５４の変更を指令する。なお、システム管理機構７０による各ホスト１１、１２の処理負荷の検出は、ＤＢ管理機構１０を介して検出したり、あるいは各ホスト１１、１２から直接検出しても良い。

また、システム管理機構７０は、各ＤＢプロセス２４〜２７に対応するディスク５１〜５４の割り当てを変更する際には、ＳＡＮ６０やストレージ装置３０に割り当ての変更を指令する。

＜ホストの追加、削除＞
次に、図１において、ホスト１１、１２にホスト１３、１４を追加する際の一例について説明する。

データベース処理を実行中のＤＢプロセス２４〜２７は、ディスク５１〜５４に対応している（対応関係及びディスクのアクセス経路を図中曲線の点線で示す）。例えば、図中ホスト１１のプロセス２４はディスク５１にアクセスを行い、プロセス２５はディスク５２にアクセスを行い、各プロセス間では異なるディスクにアクセスしてデータベース処理を実行している。

データベースシステムの再構成として、このデータベースにホスト１３と１４を追加する。システム管理機構７０の指令に基づいてＤＢ管理機構１０が各ホストに指令を行い、４つのＤＢプロセス２４〜２７を４つのホスト１１〜１４に再配分すると、ホスト１１〜１４が一つのＤＢプロセス２４〜２７をそれぞれ実行することになる。プロセスの起動と終了でこれを実現するために、ホスト１１と１２それぞれで一つのＤＢプロセス２５、２７を終了し、ホスト１３、１４では、一つのＤＢプロセス２８、２９をそれぞれ起動する。

図２に再構成の第二ステップを示す。ここでは、ＤＢ管理機構１０がホスト１３、１４でＤＢプロセス２８、２９を起動した。ホスト１３のＤＢプロセス２８がホスト１１のＤＢプロセス２５の代わりに、そしてホスト１４ＤＢプロセス２９がホスト１２のＤＢプロセス２７の代わりに処理を行う。

図３で再構成の最後のステップを示す。まず、ＤＢ管理機構１０はシステム管理機構７０の指令に基づいて、ＤＢプロセス２５がアクセスしていたディスク５２をＤＢプロセス２８にアクセスさせ、そしてＤＢプロセス２７がアクセスしていたディスク５４をＤＢプロセス２９にアクセスさせる。そしてＤＢプロセス２５と２７を終了する。

各ホストのデータベース処理でディスク５１〜５４のデータをキャッシュするため、図３の中で次のような順番で、ディスク５２、５４をアクセスするプロセス２５、２７、２８、２９を切り換える（但し、本発明はこの順番に制限されていない）。
（１）データベース処理を中断する。
（２）ＤＢプロセス２５、２７に関するキャッシュをディスク５２、５４にフラッシュする。
（３）ＤＢプロセス２４、２６、２８、２９でデータベース処理を再開する。
（４）ＤＢプロセス２５、２７を終了する。

図３では、システム管理機構７０はＤＢプロセス２５、２７、２８、２９に対応するディスク５２、５４の割り当てを変更するために、ストレージ装置３０またはストレージエリアネットワーク６０の装置の設定を変更する。この設定変更の例として、ストレージエリアネットワーク６０スイッチやストレージ装置３０のＶＬＡＮ／ゾーニング等のパーティショニングの設定変更がある。なお、システム管理機構７０は、ディスクの共有に関する設定変更について、ＤＢ管理機構１０へ通知する。

通常、全てのホスト１１〜１４に全てのディスク５１〜５４へのアクセスを許可せず、各ホストが使用中のディスク５１〜５４のアクセスだけを許可する。その実現方法（従来技術）として、ストレージエリアネットワーク６０を複数のパーティションに分ける手法が知られている。

しかし、本発明では、あるディスク５１〜５４を使用しているホスト１１〜１４が変更されるため、アクセスを引き継ぐホスト１１〜１４からのアクセスを共有可能にするためにパーティショニング設定を変更し、例えばこのディスク５１〜５４をこのホスト１１〜１４と同じパーティションにする。これにより、新たに追加されたホスト１３、１４のＤＢプロセス２８、２９で、ホスト１１、１２のＤＢプロセス２５、２７がアクセスしていたディスク５２、５４へのアクセスが可能となるのである。

つまり、図１の状態で、ディスク５１をパーティションＡ、ディスク５２をパーティションＢ、ディスク５３をパーティションＣ、ディスク５４をパーティションＤとし、システム管理機構７０はパーティションＡ、Ｂをホスト１１に割り当ててアクセスを許可し、パーティションＣ、Ｄをホスト１２に割り当ててアクセス許可を与える。

図２でホスト１３、１４を追加したときに、パーティションＢのアクセス許可をホスト１１、１３に与え、パーティションＤのアクセス許可をホスト１２、１４に与え、新たに追加されたホスト１３、１４が稼働中のディスク５２、５４にアクセスできるようにする。このとき、パーティションＢはホスト１１、１３で共有され、パーティションＤはホスト１２、１４で共有される。

次に、図３の状態となって、ホスト１１、１２のＤＢプロセス２５、２７が終了した後には、パーティションＢのアクセス許可をホスト１３のみに変更し、パーティションＤのアクセス許可をホスト１４に変更する。こうして、パーティションＢ、Ｄは新たに追加したホスト１３、１４のみからアクセス可能に変更される。

この実施形態をまとめると、ＤＢプロセス２４〜２９の起動／終了で、ホスト１１〜１４当たりのＤＢプロセス２４〜２９の数をできるだけ均等にする。これで、無共有型データベースによる迅速なホスト１１〜１４の追加／削減が可能となり、最終的にデータベース処理性能の迅速な調整を可能にする。また、稼動中ＤＢプロセス２４〜２９の総数が変化せず、無共有型データベースの形態を大きく変更する必要がなくなって、既存の無共有型データベース製品を少ない工数でスケラービリティに富んだデータベースシステムとすることができる。

なお、上記では、ホストの追加処理について述べたが、詳述はしないが、上記と逆の手順でＤＢプロセスの停止、起動、終了を行うことで、ホストの削除処理を行うことができる。

また、ホスト１３、１４の追加と、ＤＢプロセスの移動の際には、ストレージ装置３０のディスク５１〜５４をパーティションに分けて、パーティション毎のアクセス許可を変更するようにしたので、システムに障害が生じた場合の影響を受けにくくして、冗長性の高いデータベースシステムとすることができる。

＜ディスクの追加、削除＞
第２の実施形態では、ディスクの追加／削減について述べる。ここでは、従来の技術であるストレージ仮想化とストレージ最適化を使用するため、まずこれらを説明する。

ストレージの仮想化では、ストレージ装置３０がホスト１１〜１４に仮想ディスクを見せ、各ホストがこれらの仮想ディスクを通常のディスクとしてアクセスする（本明細書では、「ディスク」に「仮想」か「物理」という指示がなければ、どちらでも良いことを意味する。例えば、図１〜図３のディスク５１〜５４は物理ディスクでも仮想ディスクでも良い）。

そして、ストレージ装置３０はこれらの仮想ディスクのデータを物理ディスクにマッピングして記録する。ストレージ装置３０の中で仮想化を実現する機構を「仮想化エンジン」と呼ぶ。なお、この種のディスク仮想化方法としては、米国特許第6,216,202号などを適用することができる。

図４にストレージ仮想化を採用した無共有型データベースの一例を示す。なお、図４は図３と同じ状態を示すが、ストレージ装置３０が仮想化を使用している点で相違する。

ホスト１１〜１４は、ストレージ装置３０の仮想化エンジン３１が作成した仮想ディスク４１〜４４をアクセスする（仮想ディスクを点線で示す）。そして仮想化エンジン３１は仮想ディスク４１〜４４のデータを物理ディスク５１〜５４にマッピングして記録する（このマッピングを、仮想ディスク４１〜４４と物理ディスク５１〜５４の間の点線で示す）。

次に、ストレージ最適化は性能を向上するために、仮想ディスク４１〜４４と物理ディスク５１〜５４とのマッピングを変更する方法である。この機能の例として、日立CruiseControl（Hitachi Data Systems社、「Hitachi CruiseControl」を参照）、そしてEMC社のSymmetrix Optimizer（EMC社、「EMC ControlCenter Symmetrix Optimizer」を参照）、特開平９−０６９０３１号公報等がある。

ストレージ最適化は仮想ディスク４１〜４４の内容を変更しない（物理ディスク５１〜５４の内容のみを変更する）。このため、最適化は仮想ディスク４１〜４４をアクセスしているホスト１１〜１４（とＤＢプロセス２４〜２９等のプロセス）にはトランスペアレントであり、ホスト１１〜１４から物理ディスク５１〜５４を透過的に読み書きすることができる。

次に、物理ディスクを追加／削減するとき、上述のストレージ仮想化と最適化を活用する。

この例として、図５では図４の状態から２つの物理ディスク５５、５６を追加して、最適化を行った結果を示す。具体的には、最適化はディスク５１、５２のデータの一部をディスク５５に、ディスク５３、５４のデータの一部をディスク５６に移動またはコピーする。

ディスクの性能（ReadまたはWriteの速度）は物理ディスク５１〜５６の数に比例するため、最適化が仮想ディスク４１〜４４のデータを４台（物理ディスク５１〜５４）から６台（物理ディスク５１〜５６）の物理ディスクに再配分することでストレージの性能が向上し、この結果、データベース処理能力が向上する。

ストレージ最適化を行うとき、物理ディスク５１〜５６の間でデータの移動またはコピーが生じる。このコピーはストレージ装置３０の内部で行われ、物理ディスク５１〜５６をシーケンシャル(順次)にアクセスするため、高速である。

これに対して前記リバランスでは、あるホスト１１〜１４のＤＢプロセス２４〜２９がＳＡＮ６０経由でデータを読み出し、内容を解析して、必要な場合に他のホスト１１〜１４のＤＢプロセス２４〜２９にデータを送信して、最後にこのデータがＳＡＮ６０経由で書き込まれる。このため、ストレージ最適化はリバランスより速く、短い時間のデータベース再構成に適する。

データベースとストレージを連携して管理するシステム管理機構７０の例として、EMC Database Tunerがある（EMC社、「EMC Database Tuner」参照）。これはデータベースとストレージ装置３０の性能をモニタリングして、両者の情報を連携して、ボトルネックがどこにあるかを解析する。

この従来技術に対して本発明では、図５に示すとおり、システム管理機構７０はストレージ装置３０で最適化を起動し、データベースのニーズに合ったストレージの性能調整を可能にする。これにより、データベース再構成に必要なストレージとの連携を実現することができる。

システム管理機構７０は最適化の起動の際に、ホストの台数や必要な性能など、最適化に必要なパラメータを加えることができる。ストレージ装置３０はこれらのパラメータをベースにして、使用する物理ディスク５１〜５６の数と、仮想ディスク４１〜４４と物理ディスク５１〜５６とのマッピングを決定する。

この第２の実施形態をまとめると、システム管理機構７０がストレージ装置３０に最適化に必要なパラメータを転送し、最適化処理を起動することで、物理ディスクの追加／削減を実現し、データベースに必要なストレージ性能の調整を可能にする。ストレージ仮想化と最適化のため、物理ディスク追加／削減はトランスペアレントであり、既存の無共有型データベースに加える変更を最小限としながら、スケーラビリティの高い無共有型データベースを提供できる。

＜追加、削除の決定＞
第３の実施形態では、ホストまたはディスクの追加または削除の決定について、追加／削減のタイミング、そして追加／削減する資源の量、などを決定する方法について述べる。この第３の実施形態に基づいて、上記第１または第２実施形態のホスト１１〜１４とディスク５１〜５６の追加／削減方法を行うことができる。

この第３の実施形態では、管理者がデータベースをいつ、どの程度の量の資源に変更するかを決定して、システム管理機構７０にこれらを指定することが最も簡単な決定方法である。この後、システム管理機構７０がＤＢ管理機構１０等を制御して、ホスト１１〜１４またはディスク５１〜５６の追加／削減を行う。

もう一つの決定方法として、システムの管理者がシステム管理機構７０に必要なデータベース性能（スループットや応答時間）や容量を指定することが挙げられる。この場合、システム管理機構７０が実際の性能や容量を測定し、指定した性能や容量を得るためにＤＢ管理機構１０等を制御してデータベースを再構成する。

もう一つの決定方法として、システム管理機構７０がホスト１１〜１４とストレージ装置３０をモニタリングして、どれかがボトルネックになっているか（または、どれかが性能の余裕があるか）を調べ、ボトルネックになっている資源の追加（または余裕がある資源の削減）をする。これで、システム管理機構７０がホスト１１〜１４とストレージ装置３０の性能をバランスする。

さらに、もう一つの決定方法として、管理者がポリシーを作成し、システム管理機構７０に記録することが挙げられる。これらのポリシーの例として、まずサービスレベル（各顧客やユーザに提供する最低の性能や容量）の指定がある。そして、スケジュール（セールの日やバッチ／オンライン処理の切り替え時間、等）もポリシーとして記録することができる。この場合、システム管理機構７０がこれらのポリシーに従う（指定されたサービスレベルを得るために、あるいは指定された時間に、データベースを再構成する）。これにより、ホスト及びディスクの追加、削除処理を自動化することができる。

なお、システム管理機構７０がデータベースにホスト１１〜１４またはディスク５１〜５６等の資源を追加するときに、ブローカリングが必要なときがある。これは、システムの中でどの資源を使用できるかを調べ、この中で使用する資源を選び、その資源をデータベースに予約することである。そして、資源を削減するときに、これらの資源を自由にし、他の用途に使用可能にすることである。

上記ブローカリングは、例えば、リソース（ホストまたはストレージ）の追加を行う場合に、システム管理機構７０が、グリッドコンピューティングのリソースの管理を行うブローカ（図示省略）に対して、リソースの予約及び取得、解約及び返却を行うものである。

例えば、リソースの追加を行う場合には、システム管理機構７０が、グリッドコンピューティングのリソースの管理を行うブローカに対して、リソースの予約を行う。その後、ブローカからの許可に応じてリソースを取得して、データベースに組み込む。

一方、使用したリソースを削除する場合には、システム管理機構７０が、使用していたリソースの削除を行い、その後、ブローカに対して、リソースの予約の解除を行い、リソースを返却する。なお、リソースの予約の解除と削除は同時に行っても良い。

こうして、リソースの予約と取得、予約の解除（解約）と返却をブローカへ要求することで、リソースの追加または削除を行うことができる。

この実施形態をまとめると、本発明ではシステム管理機構７０が管理者の指示、管理者が指定した性能や時間、データベースのボトルネック、あるいは管理者が指定したポリシーにしたがって再構成を起動する。そして、再構成の中で、ブローカリングを行って、資源の取得と返却をする。

＜＜変形例＞＞
本発明はすでに記載した実施の形態あるいはその変形例に限定されるのではなく、以下に例示する変形例あるいは他の変形例によっても実現可能であることは言うまでもない。また、上記複数の実施形態あるいはその変形例として記載の技術あるいは以下の変形例の組み合わせによっても実現できる。

（変形例１）
本明細書の説明や図を分かりやすくするために、ＤＢプロセス毎に一つのディスクを属した。しかし、本発明はこの構成に制限されておらず、各ＤＢプロセス２０〜２３が一つまたは複数のディスク８１〜８４、４１〜４４、５１〜５４をアクセスすることが可能である。

（変形例２）
本明細書の説明や図を分かりやすくするために、ＤＢプロセスが物理ディスク５１〜５４か仮想ディスク４１〜４４をアクセスすると述べた。しかし、本発明はこの形態に制限されておらず、仮想／物理ディスクの一部のみ、例えばオペレーティングシステムまたはデータベースが作成したパーティションのみをアクセスすることもある。

（変形例３）
図１以降、ストレージとしてストレージエリアネットワーク６０に接続したストレージ装置３０を示している。しかし、本発明はこの形態に制限されていない。第１実施形態では、複数の物理または仮想ディスクを複数のホストからのアクセスを可能にする手段で十分である。また、第２実施形態では、複数の仮想ディスクを複数のホストからのアクセスを可能にする仮想化エンジンで十分である。例えば、第１と第２実施形態では、ストレージエリアネットワーク６０を使用せずに、ストレージ装置３０の複数のポートを直接ホスト１１〜１４に接続することが可能である（これらの直接接続は「ストレージエリアネットワーク」と呼ばれる場合がある）。そして、第１実施形態ではストレージ装置３０を使用せず、複数の物理ディスク５１〜５４を直接ストレージエリアネットワーク６０に接続することが可能である。

（変形例４）
第１実施形態ではＤＢプロセス２４〜２９の起動と終了で、ホスト１１〜１４のＤＢプロセス２４〜２９の数を均等にする。しかし、本発明はその形態に制限していない。例えば、各ホスト１１〜１４で予め（例えば、データベースの起動時に）必要なＤＢプロセス２４〜２９の数を起動しておいて、ホスト１１〜１４は追加／削減の時に終了せず、これらのＤＢプロセス２４〜２９を使用する。この場合、「必要なＤＢプロセス２４〜２９の数」として、ホスト１１〜１４により異なったＤＢプロセス２４〜２９の数を起動することが可能である（この場合、例えば、ホスト１１、１２それぞれに２つのＤＢプロセス２４〜２７、ホスト１３、１４それぞれに１つのＤＢプロセス２８、２９を起動する）。

（変形例５）
第２実施形態に仮想化エンジン３１がストレージ装置３０の中にあるが、本発明はこの形態に制限されていない。例えば、仮想化エンジン３１が、ストレージエリアネットワーク６０、ホスト１１〜１４のオペレーティングシステム、そしてＤＢプロセス２０〜２９の中にあっても良い。

（変形例６）
本明細書の図では、ＤＢ管理機構１０、ホスト１１〜１４、システム管理機構７０の間の矢印は接続でなく、通信を表現するため、これらの間で任意のネットワーク接続が考えられる。そして、システム管理機構７０がホスト１１〜１４を直接設定し、管理情報（ＣＰＵ負荷、入出力負荷など）を取得しても良い。

（変形例７）
第２実施形態では、システム管理機構７０からストレージ装置３０への、ホスト台数や必要な性能などの最適化に必要なパラメータの指定について述べた。しかし、この発明はこれらのパラメータ、特に処理や入出力負荷に関するパラメータに制限していない。

上記変形例２に述べたとおり、オペレーティングシステムまたはデータベースがディスク４１〜４４にパーティションを作成することがある。各パーティションのアクセス負荷が異なる場合がある。ＤＢ管理機構１０が指定するパラメータのもう一つの例として、各ディスク４１〜４４でのパーティションの位置をストレージ装置３０に伝えることが挙げられる。ストレージ装置３０が仮想ディスク４１〜４４全体でなく、そのパーティション毎の負荷を測定して、最適化を計画することにより、より良い最適化を実現できる。この最適化の例として、仮想ディスク４１〜４４と物理ディスク５１〜５６とのマッピングをパーティションの境界で分けることが挙げられる。

（変形例８）
以上の説明にはシステム管理機構７０が再構成を決定し、ストレージ装置３０またはストレージエリアネットワーク６０を制御する。しかし、本発明はこの形態に制限されておらず、例えばＤＢ管理機構１０が代わりにこれらの動作の全てまたは一部を担うことが可能である。この場合、ＤＢ管理機構１０が再構成の決定、ストレージ装置３０またはストレージエリアネットワーク６０の制御等をするようにしても良い。

（変形例９）
ＤＢプロセス２４〜２９がそれぞれディスク５１〜５６のキャッシュを持つ。このため、ホスト追加／削減の場合、あるディスク（例えば、ディスク５２）を使用しているＤＢプロセス１１〜１４を切り換えるとき（この例では、ＤＢプロセス２５からＤＢプロセス２８）、ディスクを受ける側のＤＢプロセス（ＤＢプロセス２８）のキャッシュは受けたディスク（ディスク５２）のデータを持たない。その結果、このＤＢプロセス（ＤＢプロセス２８）の性能がしばらく低下し、データベース全体の性能が低下する。

この問題の解決方法として、ＤＢプロセス２４〜２９を切り換える間に、これらのＤＢプロセス２４〜２９の間でキャッシュメモリの内容の全てまたは一部を転送することが考えられる。今後、InfiniBand（InfiniBand Trade Association,「InfiniBand Architecture Specification Volume 1 Release 1.0.a」、2001参照）のような、ホスト１１〜１４のＣＰＵを介さないでメモリ間でデータを直接転送できるネットワークやストレージエリアネットワーク６０が普及するため、キャッシュの内容を高速に転送できる。

キャッシュの中身を転送している間に、データベース処理を中断する必要がある（このため、この転送のタイミングとして、既に処理が中断している、キャッシュの内容をディスク５１〜５４へのフラッシュするときと同時に行うことが適するが、本発明はこのタイミングに制限されていない）。キャッシュの中身の転送は時間がかかるが、その後のデータベース性能が高いため、有利である。

なお、プロセスマイグレーションを使用した場合、プロセスが持つデータの一部としてキャッシュを転送することが考えられる。

（変形例１０）
本発明は、検索などのデータベース処理を行うＤＢプロセス２４〜２９に制限されておらず、データベースの中でこれらに関連を持つ他のプロセスにも適用できる。

以上は変形例である。なお、本発明を実施するためのプログラムは、それ単独であるいは他のプログラムと組み合わせて、ディスク記憶装置等のプログラム記憶媒体に記憶された販売することができる。また、本発明を実施するためのプログラムは、すでに使用されている通信を行うプログラムに追加される形式のプログラムでもよく、あるいはその通信用のプログラムの一部を置換する形式のプログラムでも良い。

また、請求項５の発明において、前記管理手段は、前記第１のプロセスがアクセスしていた前記ボリュームを、前記第２のプロセスにアクセスさせるため、前記ボリュームに対する第１及び第２の情報処理装置の割り当てを、マッピングの設定により変更する。

また、請求項５の発明において、前記管理手段は、前記第１のプロセスがアクセスしていた前記ボリュームを、前記第２のプロセスにアクセスさせるため、前記ボリュームに対する第１及び第２の情報処理装置のアクセス許可を、パーティションの設定により変更する。

以上のように、本発明に係るデータベース制御方法では、無共有型データベースのホストやディスクの追加や削減を容易且つ迅速に行うことができるので、無共有型データベースが対応可能な分野（予想できないピークの対応、昼間のオンライン処理と夜間バッチの切り換え、等）を広げ、可用性に富んだデータベースシステムを構築できる。
に適用することができる。

本発明の一例を示すシステム構成図で、ホストを追加する場合の第１ステップを示す。同じくシステム構成図で、ホストを追加する場合の第２ステップを示す。同じくシステム構成図で、ホストを追加する場合の第３ステップを示す。同じくシステム構成図で、ディスクを追加する場合の第１ステップを示す。同じくシステム構成図で、ディスクを追加する場合の第２ステップを示す。従来例を示す、無共有型データベースのシステム構成図。

符号の説明

１０システム管理機構
７０データベース管理機構
１１〜１４ホスト（データベースサーバ）
２４〜２７プロセス
６０ストレージエリアネットワーク（ＳＡＮ）

Claims

複数の情報処理装置でそれそれ実行されるプロセスが、ストレージのデータにアクセスする無共有型のデータベースと、前記情報処理装置とストレージを管理する管理手段とを有し、
前記プロセスは、管理手段によって設定された前記ストレージの一つまたは複数のボリュームを専有してアクセスし、
前記情報処理装置の数を追加または削減するときには、前記管理手段が前記プロセスの割り当てを情報処理装置の間で変更することを特徴とするデータベース制御方法。
前記情報処理装置の数を追加する際に、前記管理手段は、前記複数の情報処理装置のうち既存の第１の情報処理装置で実行されているプロセスを、追加された第２の情報処理装置に移動させることを特徴とする請求項１に記載のデータベース制御方法。
前記情報処理装置の数を追加する際に、前記管理手段は、前記複数の情報処理装置のうち既存の第１の情報処理装置で実行されている第１のプロセスを停止し、
前記第１のプロセスがアクセスしていた前記ボリュームを、追加された第２の情報処理装置で実行される第２のプロセスにアクセスさせることを特徴とする請求項１に記載のデータベース制御方法。
前記情報処理装置の数を削減する際に、前記管理手段は、前記複数の情報処理装置のうち既存の第１の情報処理装置で実行されている第１のプロセスの処理を停止し、
前記第１のプロセスがアクセスしていた前記ボリューム、削除対象となっていない第２の情報処理装置で実行される第２のプロセスにアクセスさせることを特徴とする請求項１に記載のデータベース制御方法。
前記管理手段は、前記第１のプロセスがアクセスしていた前記ボリュームを、前記第２のプロセスにアクセスさせるため、前記ボリュームに対する第１の情報処理装置の割り当てまたはアクセス許可を、追加された第２の情報処理装置に変更することを特徴とする請求項３または請求項４に記載のデータベース制御方法。
前記情報処理装置の数を追加または削減する際に、前記第１のプロセスが有する前記ボリュームのキャッシュを、第２のプロセスに転送することを特徴とする請求項３または請求項４に記載のデータベース制御方法。
前記管理手段は、情報処理装置の数を追加するときに、追加する情報処理装置を予約し、削減するときに、削減予定または削減した情報処理装置の予約を解除することを特徴とする請求項１に記載のデータベース制御方法。
前記管理手段は、情報処理装置の数を追加または削減するとき、管理者が設定した指示、データベースの要求処理能力や容量、予め設定したポリシーの少なくとも一つに基づいて、追加または削減する情報処理装置の量を決定し、この追加または削減を起動することを特徴とする請求項１に記載のデータベース制御方法。
複数の情報処理装置でそれそれ実行されるプロセスが、仮想ボリュームを含むストレージのデータにアクセスする無共有型のデータベースと、前記情報処理装置とストレージを管理する管理手段とを有し、
ストレージは、仮想ボリュームを物理ボリュームに関連付けてデータのアクセスを行い、
前記プロセスは、管理手段によって設定された前記ストレージの一つまたは複数の仮想ボリュームを専有してアクセスし、
前記情報処理装置または物理ボリュームを追加または削減するときには、前記管理手段が、前記プロセスに設定される仮想ボリュームと物理ボリュームの割り当て変更を、前記ストレージに起動させることを特徴とする請求項８に記載のデータベース制御方法。
前記仮想ボリュームと物理ボリュームの割り当て変更は、前記起動に関連して、
前記ボリュームをアクセスする前記情報処理装置の数、アクセス負荷、前記仮想ボリューム中のデータベースのデータ領域の少なくとも一つを割り当て変更に使用する情報として前記管理手段からストレージに転送し、前記割り当て変更を起動することを特徴とする請求項９に記載のデータベース制御方法。
前記管理手段は、情報処理装置または物理ボリュームを追加するときに、追加する物理ボリュームを予約し、削減するときに、削減予定または削減した物理ボリュームの予約を解除することを特徴とする請求項９に記載のデータベース制御方法。
前記管理手段は、情報処理装置または物理ボリュームを追加または削減するとき、管理者が設定した指示、データベースの要求処理能力や容量、予め設定したポリシーの少なくとも一つに基づいて、追加または削減する情報処理装置の数または物理ボリュームの容量を決定し、この追加または削減を起動することを特徴とする請求項９に記載のデータベース制御方法。
前記管理手段は、システム全体を監視する監視手段を有することを特徴とする請求項１または請求項９に記載のデータベース制御方法。
前記管理手段は、データベースの処理要求をクライアントから受けて、前記複数の情報処理装置にデータベースの処理を割り当てる処理指令手段を有することを特徴とする請求項１または請求項９に記載のデータベース制御方法。