JP3817818B2

JP3817818B2 - 二重化ボリュームの等価性保証処理装置および二重化ボリュームの等価性保証処理方法

Info

Publication number: JP3817818B2
Application number: JP06079297A
Authority: JP
Inventors: 匡史加藤; 治秋葉; 耕太郎岡崎
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1997-03-14
Filing date: 1997-03-14
Publication date: 2006-09-06
Anticipated expiration: 2017-03-14
Also published as: JPH10254787A

Description

【０００１】
【発明の属する技術分野】
本発明は二重化ボリュームの等価性保証処理装置に関する。
【０００２】
【従来の技術】
コンピュータシステムの複雑化、巨大化、連続運転化などの要求の進展にともないデータを保持するファイル装置の台数、容量も大きくなり、その一部に障害があっても、利用者への影響を与えないように運転を継続しながら故障の修復を並行して行えるようにすることが要請されている。その方法のひとつに二重化ボリュームあるいはファイルの二重化の技術が使われている。
【０００３】
すなわち、データを書き込むファイルを二重に別ボリュームに用意して同一のデータを同時に２個所の異なるボリュームに書き込む。これらのデータを読むときには二重化して記憶されたデータのいずれかを読み出すようにしている。どちらのボリュームにも同じ内容のデータが記憶されていることすなわちデータの等価性を保証しているのでいずれかのボリュームが正常に読めればよいことになる。
【０００４】
ハードの障害によりいずれかのボリュームが読み書きできない状態になると、障害を起こした装置を切り離し、一時的にそこに搭載したボリュームについては二重化を中止して正常に動作する装置のボリュームにのみ読み書きすることで、切り離した装置の修理を並行して行いながら、ボリュームを利用するシステムは運用を続けることができる。しかし、停電などによるシステムの突然の停止にみまわれた時には二重化ボリュームのデータの等価性が保証されないという状態になる。
【０００５】
二重化ボリュームの運用は正常な運用状態および上記のような異常状態において、従来は次のように処理している。
まず、システムを正常に停止する時には、システムに搭載されている二重化ボリュームの各々について、二重化ボリュームが更新中である場合は、更新を完了させ二重化ボリュームの等価性を保証した後、不揮発性媒体上にあるボリューム状態管理表１に等価性保証完了状態であることを表示して設定し、システムを停止して電源を切断する。
【０００６】
システムの起動時には、図８に示すようにステップＳ８１、ステップＳ８２でシステムに搭載されている二重化ボリュームの各々について、ボリューム状態管理表１を検査し、ボリュームの状態により以下の処理を行う。
【０００７】
▲１▼等価性保証完了状態が設定されている場合
ボリューム状態管理表に二重化運用中状態を設定した後、二重化ボリューム運用を開始する。すなわち読み込みはどちらか片方のボリュームから行い、書き込みは両方のボリュームに行う（ステップＳ８５）。
【０００８】
▲２▼二重化運用中状態が設定されている場合
システム運用中に強制電源切断や停電によりシステムが停止した後のシステム起動時の状態である。このときは（ステップＳ８３）どちらか片方のボリュームを複写元ボリューム、他方のボリュームを複写先ボリュームとし、ボリューム状態管理表１に等価性保証処理中および複写元ボリューム名を設定した後、複写元ボリュームの内容を全て複写先ボリュームへ複写する（以降これを全面等価性保証処理と呼ぶ）。全面等価性保証処理中でも、ボリュームへの読み出し書き込みは可能であるが、二重化状態ではないため、複写元ボリュームに障害が起きると、このボリュームは使用できなくなる。全面等価性保証処理が完了すると、ボリューム状態管理表１に二重化運用中状態を設定する（ステップＳ８５）。
【０００９】
▲３▼等価性保証処理中状態が設定されている場合
全面等価性保証処理が完了する前にシステムが停止した後のシステム起動時の状態である（ステップＳ８４）。ボリューム状態管理表１により、複写元ボリューム、複写先ボリュームを決め、全面等価性保証処理を開始する。全面等価性保証処理が完了すると、ボリューム状態管理表に二重化運用中状態を設定する（ステップＳ８５）。
【００１０】
【発明が解決しようとする課題】
上記したように電源の強制切断や停電によりシステムが停止した後、システムを起動すると、システム内の全ての二重化ボリュームに対して、全面等価性保証処理が必要となる。全面等価性保証処理は、ボリュームの全領域を複写するため、Ｉ／Ｏの負荷が業務の効率に与える影響が無視できない。業務に影響を与えない範囲で、全面等価性保証処理を行おうとすると、システム内の全ての二重化ボリュームの全面等価性保証処理の完了までに長い時間が必要となり、信頼性の観点から問題となる。大規模データベースのように大容量のデータを持つシステムでは深刻な問題である。例えば、５００ＧＢのデータを５ＭＢ／秒の速度で全面等価性保証処理をした場合に必要となる時間は単純に計算しても２８時間であり１日以上も業務が止まってしまう。
【００１１】
二重化ボリュームの更新前に必ず更新ログ（どのボリュームのどのブロックを更新するか）を採取し、不揮発化する方法が考えられる。この場合は電源の強制切断や停電によりシステムが停止しても、どのボリュームのどのブロックが更新中であったかが分かるので、その部分だけの等価を保証すれば良い。しかし、この方法はデータ更新に加え更新ログの採取が必要となるため、全ての更新処理のＩ／Ｏレスポンスが約２倍劣化する。
【００１２】
すなわち、上記したように停電など突然の電源断によるシステムの異常終了後のシステムの起動時における二重化ボリュームの全面等価性保証処理のシステム運用、業務運用におよぼす効率低下の影響が課題でありその解決策が求められていた。
【００１３】
ところが、アプリケーションプログラムの中には、複数のデータ更新からなる一連の手続きのアトミシティ（原子性すなわち複数のデータの更新をすべて行うか、あるいは全く行わないか、いずれかの状態とすること）を保証するため、アプリケーションそれ自身の論理で更新ログを採取している場合がある（例えばデータベース管理システムによるトランザクション処理）。アプリケーションプログラムが採取している更新ログには更新中のデータのアドレスが含まれており、これを用いればシステムが異常停止したときにも更新中の可能性のあるデータの存在する部分が限定されるので短時間で等価性を保証することができることになる。
【００１４】
本発明はこのような点にかんがみて、アプリケーションプログラムの論理により等価性保証が可能な領域はアプリケーションプログラムで等価性保証を行うことにより等価性保証が必要な領域を少なくし、等価性保証処理に必要な時間、資源（ＣＰＵ使用量、Ｉ／Ｏ回数）を少なくする手段を提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記の課題は下記の如くに構成された二重化ボリュームの等価性保証処理装置によって解決される。
【００１６】
図１は、本発明の構成図である。
図において、１はボリューム状態管理表、４は全面等価性保証処理手段、１０は本発明の手段を示し、２はアプリ別等価性保証処理対象領域管理表であり、５はアプリ別等価性保証処理手段、３は等価性保証処理選択手段である。
【００１７】
等価性の保証処理を行うとき等価性保証処理選択手段３はアプリ別等価性保証処理対象領域管理表２によりアプリケーションプログラムで等価性保証が可能なボリューム領域を知り、各アプリ別等価性保証処理手段５を選択して起動する。ボリューム状態管理表１にある他のボリューム領域については等価性保証処理選択手段３は全面等価性保証処理手段４を起動して従来の全面複写による全面等価性保証処理が行われるようにしている。このようにして上記アプリケーションプログラムがアクセスするボリュームについては必要な部分についてのみ等価性保証処理を行うので時間の短縮、省資源という上記課題が解決される。
【００１８】
【発明の実施の形態】
図２は本発明の実施の形態の構成図である。図には二重化ボリュームを含むコンピュータシステムをプロセッサ２０、不揮発性媒体２１および二重化ボリューム群（２９ａ、２９ｂなど）の３つの部分に分けて示している。
【００１９】
プロセッサ２０がシステムの制御をつかさどり。本発明の手段に対応した３つの部分からなる。
２２はアプリ別等価性保証処理部であり、アプリケーションプログラムが扱うデータベースの更新処理をトランザクション単位で複数のデータについてまとめて更新するかあるいはいずれも更新しないかのどちらかの状態を保証する必要があるとき、すなわちアトミシティを保証する処理を行っている場合には、このアプリケーションプログラムが更新の対象とするデータベースについての等価性保証処理を分担するものである。
【００２０】
２４は従来技術として備わっている全面等価性保証処理部を示す。これは、システムの異常停止の場合、ボリューム上のどこのブロックが書き込み中であったかが分からず、ボリュームのいずれの部分が内容の等価性が崩れているのか特定できないので、そのボリューム全体について二重化された片方のボリュームから他方へ全面複写を行い等価性を保証するものである。
【００２１】
２３は上記２２あるいは２４の二つの等価性保証の手段を選択して起動し全二重化ボリュームについて等価性保証処理する等価性保証処理選択部である。
２１は上記等価性を保証する手段が参照し、また二重化ボリュームの運用の状態や等価性保証処理の状態を記憶する不揮発性媒体である。これらの二重化ボリュームの最新の状態は電源断などの異常事態においても保持するため磁気ディスク装置などの不揮発性媒体に記録する必要がある。
【００２２】
詳細は後述するが２５は二重化ボリューム状態管理表である。２６はアプリ別等価性保証対象領域管理表である。上記２０に示した等価性保証処理の手段はこれらの管理表の示す内容に基づき等価性保証処理を行う。
【００２３】
２９ａは二重化ボリュームＡである。これは物理的に異なるＸ系装置２８ａｘとＹ系装置２８ａｙ上に構成されている。すなわちＸ系装置上のボリュームとＹ系装置上の二重化された論理的なボリュームが二重化ボリュームＡである。二重化ボリュームＡにはデータとしてデータベースＤＡＴＡａが記録されるようになっている。また、このＤＡＴＡａはアプリケーションプログラムが上記説明したデータのアトミシティを保証するためにデータそのものに付随してチェックポイント情報（ＣＫＰ情報ａ）およびデータ更新情報ａを更新ログとして二重化ボリュームＡ上に記録している。したがって二重化ボリュームＡはアプリケーションプログラムによる等価性保証処理の対象となっている。
【００２４】
二重化ボリュームＢの構成も同様である。ただし、このボリュームにのっているデータはこれを使用しているアプリケーションプログラムが特に更新ログをとるようなことをしていないので２７ｂに記録されるものはデータのみである。したがって二重化ボリュームＢは全面等価性保証処理の対象となるものである。
【００２５】
図３はボリューム状態管理とアプリ別等価性保証処理対象の関連説明図である。図３（ａ）はボリューム状態管理表３１を示し、図２に示した二重化ボリュームＡ、Ｂの他にＣ，Ｄ合計４個の二重化ボリュームの運用状態例を示している。ボリューム状態管理表３１は二重化対象ボリューム名に対応してアクセス禁止フラグ、二重化ボリューム状態、複写元ボリューム、等価性保証処理タイプを示すように構成している。
【００２６】
二重化ボリューム状態は二重化運用中、等価性保証処理中、図示してはいないがもう一つ等価性保証処理完了の３個の状態がある。二重化運用中の状態は書き込みはＸ系、Ｙ系に二重に行い、読み込みは片方の系のボリューム（たとえばＸ系）から行う運用中であることを示す。すなわち正常にシステムが稼働中にはアクセスメソッドはこの表を調べることにより上記のように両系に書き出す。ただしこれから説明するようにシステムが電源断などによって異常に停止した時には再開処理で順次ボリュームのアクセスが可能になっていく過程の状態が存在し、ここに表示されている二重化ボリューム状態とは異なる。このように再開処理中はアクセス禁止フラグを１として示す。図３（ａ）にはボリュームＡのみがアクセス禁止フラグが０で他は１、すなわち、システムが異常停止の後二重化ボリュームを順次等価性保証処理を行っていく過程でボリュームＡについては等価性保証処理が終了し、あらためて二重化運用中状態を表示してアクセス可能であるという意味をフラグが表示していることを示している。
【００２７】
ボリュームＢについては二重化ボリューム状態は等価性保証処理中すなわち全面複写中であるが、システムが稼働中においては二重化ボリュームＢは片系運転中でありアクセスは複写元ボリュームに示すＸ系にのみ書き込み、読み出しができる状態を示す。ただし、ボリュームＢのアクセス禁止フラグが１であるときはシステムが異常停止したときに上記片系運転中、並行して全面等価性保証処理中であったことを示すものである。
【００２８】
なお、二重化ボリューム状態のもうひとつに等価性保証処理完了がある。これは正常にシステムを停止するときには等価性保証の確認を行い、システムスタート時にはいつでも二重化運用ができるようにしておく状態である。
【００２９】
複写元ボリュームの表示は等価性保証処理中にどちらの系から複写を行っているのかを示すものである。ボリュームＡ、Ｃ、Ｄでは表示がない。ボリュームＢについてはＸ系にのみアクセスする片系運転であることを示す。
【００３０】
等価性保証処理タイプにはアプリ別と一般がある。すなわち本発明で等価性保証処理をアプリケーションプログラム別等価性保証処理プログラムで行う場合と従来通り全面等価性保証処理で行う場合を区別するものである。
【００３１】
上記した二重化対象ボリュームＡとＢの他、ボリュームＣはシステムが電源断により異常停止したとき二重化運用中であり等価性保証処理は全面等価性保証処理を用いること、またボリュームＤは同様に二重化運用中であったがアプリケーションプログラムが更新ログをとっており再起動のための等価性保証処理はアプリ別等価性保証処理プログラムを用いることを示している。
【００３２】
図３（ｂ）はアプリ別等価性保証処理対象領域管理表３２を示す。アプリケーションプログラムで本来のデータ更新の論理から複数のデータの状態のアトミシティ（原子性）を保証するものでは別途示す更新ログの情報により更新中のデータのアドレスが分かるのでこれを利用して両系のボリュームの等価性保証処理をボリュームのすべてのブロックを複写することなく、アプリケーション別に用意した等価性プログラムを起動することで達成できる。
【００３３】
アプリ別等価性保証処理対象領域管理表３２の中でアプリ別等価性保証処理プログラム対象ボリューム名は上記したようなアプリケーションプログラムが読み書きする二重化ボリュームを示す。図３（ａ）に示したように対象となるボリュームはＡとＤである。各ボリュームに対応するアプリケーションプログラム名はＡＰａとＡＰｄ、各アプリ別等価性保証処理プログラムのスタートアドレスがＴａ、Ｔｄであることを示している。
【００３４】
図４はシステム起動時の等価性保証処理に関する実施の形態の動作を説明するフローチャートである本発明の実施の形態の構成に対応して区分すると４１が等価性保証処理選択部であり、４２がアプリ別等価性保証処理部、４３が全面等価性保証処理部である。以下ステップを追って説明する。まず、図示していないが初期設定として図３（ａ）のボリューム状態管理表のすべてのボリュームに対してアクセス禁止フラグを１とする。これはシステム起動時に各二重化ボリュームの等価性保証処理を行う過程で順次ボリュームのアクセスを可能とするために行うものである。
【００３５】
ステップＳ４４では、図３（ｂ）のアプリ別等価性保証処理対象領域管理表３２にあるボリューム名の内図３（ａ）に示すボリューム状態管理表３１で二重化ボリューム状態が二重化運用中となっているものがあるか探す。すなわち、最初にアプリ別等価性保証処理対象領域管理表３２にあるボリュームＡについてボリューム状態管理表を調べると二重化ボリューム状態が二重化運用中となっているのでアプリ別等価性保証処理を行うためにステップＳ４５に制御を移す。なお、図３（ａ）ではアクセス禁止フラグが０となっているがこれはボリュームＡについての等価性保証処理が終了したあとの状態を例示しているのであるが処理開始時にはアクセス禁止フラグは１である。
【００３６】
ステップＳ４５では、図３（ｂ）のアプリ別等価性保証処理対象領域管理表３２に示されるボリュームＡを読み書きするアプリケーションプログラムＡＰａのアプリ別等価性保証処理プログラムのスタートアドレスに制御を移して等価性保証処理を起動する。処理完了時にステップＳ４６でボリュームＡの二重化ボリューム状態を二重化運用中とし、アクセス禁止フラグをリセットして両系のボリュームを二重化ボリュームとしてアクセスを可能とする。同様にステップＳ４４に戻り他に条件にあう次のボリュームＢについて処理する。ステップＳ４４の条件に合う二重化ボリュームがなくなるまでこれを繰り返す。アプリ別等価性保証処理の対象の二重化ボリュームの等価性保証処理をすべて終わってから、ステップＳ４７で残りの二重化ボリュームについて従来技術の全面等価性保証処理を実行する。全面等価性保証処理は大量のデータの複写を伴う場合も多いがこのようなときには複写元をどちらかの系のボリュームとし、また二重化ボリューム状態を等価性保証処理中であるとボリューム状態管理表３１に記録して複写元ボリュームのみの片系運転で読み書きを可能としてシステムに組み入れる。全面等価性保証処理が完了した時点でボリューム状態管理表二重化運用中と設定してはじめて二重化ボリュームの機能を発揮する。
【００３７】
図５、図６によりアプリケーションプログラムのデータ更新処理を説明する。図５（ａ）はアプリケーションプログラムがひとかたまりのデータを更新するとき、更新ログの記録と更新データの記録の完了の過程の確認を行うためのチェックポイントと、どのようなデータをどこに書き込むのかを示すデータ更新情報の格納アドレスを不揮発性媒体に記録する表の形式を示している。図５（ｂ）は上記したデータ更新情報の形式を示す表である。データ更新情報は一連の更新するデータのブロックアドレスと更新後設定すべき値を格納している不揮発媒体上の先頭ブロックアドレスと連続したブロック数を各アプリケーションプログラム毎に（ａ）に示す更新データ数だけ並べた形式としている。またこれらの情報は図２に示したように二重化ボリューム上に配置されているものとしている。
【００３８】
図６のアプリケーションプログラムのデータ更新処理のフローチャートにより動作を説明する。図５に示す一連のデータをひとかたまりにして、アトミシティを保証して更新するためにチェックポイントを用いて処理の進捗状態を確認できるようにする。ステップＳ６１では一連の更新処理に入る前であることをチェックポイントに０を設定することで記録する。
【００３９】
ステップＳ６２ではこれから書き込むデータの値と書き込み先のアドレスをデータ更新ログとして記録する。ステップＳ６３ではデータ更新情報の記録が完了したことを示すためにチェックポイント情報に１を設定する。
【００４０】
ステップＳ６４でデータ更新情報に設定された一連のデータの更新を行う。ステップＳ６５でデータ更新の完了を示すためにチェックポイント情報に２を設定する。
フローチャートの右側に（イ）、（ロ）、（ハ）でチェックポイント情報の値によりデータの更新がどこまで進んでいるかを判断できるかを矢印の範囲で示している。
【００４１】
すなわち、片系のチェックポイント情報が２であると（イ）の範囲つまり、前回分のデータ更新は完了し、データ、データ更新情報は共に等価性が保たれている状態である。ただし、チェックポイント情報についてはＸ系、Ｙ系によって０、１、２である可能性があり等価性が保たれているとは言えない。
【００４２】
片系のチェックポイント情報が０であると、（ロ）の範囲でデータ更新情報の設定中すなわち更新データは前回更新されたままであり等価性は保証されている状態である。しかし、データ更新情報とチェックポイント情報は等価性は保証されない状態である。
【００４３】
片系のチェックポイント情報が１であると、（ハ）の範囲でデータを更新中であるが完了は確認できず、データの等価性、チェックポイントデータの等価性は保証されず、データ更新情報の等価性だけが保証された状態であることを示している。
【００４４】
以上のようなデータの更新状態をチェックポイント情報から知ることによりアプリケーションプログラムによる等価性保証処理を行う方法について図７のフローチャートにより説明する。
【００４５】
ステップＳ７１においては前記（イ）、（ロ）、（ハ）のいずれにおいてもチェックポイントの等価性は保証されておらずここでＸ系からチェックポイント情報をＹ系に書き込みチェックポイント情報の等価性を保証する。ここで逆方向Ｙ系からＸ系に複写してもよい。
【００４６】
ステップＳ７２、ステップＳ７３ではチェックポイント情報の値を調べ、その値によって以下の処理を分ける。
前記したように、０の場合には、データは等価であり、データ更新情報の等価状態が不確定であり、ステップＳ７４に移る。ここでは複写方向の考え方は上記と同様にしてＸ系のデータ更新情報を読み込みＹ系に複写する、あるいは、等価でありさえすれば中身は問題としないので、中身を初期設定、例えばクリアする方法でもよい。
【００４７】
同様にチェックポイント情報が１の場合データ更新情報は等価であるが、データの等価性は疑わしいのでステップＳ７５においてデータ更新情報を読み込み、読み込んだ情報を基づき改めてデータをＸ系、Ｙ系両系に書き込む。
【００４８】
チェックポイント情報が２の場合にはデータおよびデータ更新情報はともに等価性が保証されているので何もせず等価性保証処理を終了する。
上記ではアプリケーションプログラムで更新するデータは１群のみであるとしたが複数のデータ群がある場合にもアプリ別の等価性保証処理プログラムをそれに対応するように作成することは容易である。
【００４９】
【発明の効果】
以上の説明から明らかなように本発明によれば、二重化ボリュームの領域の内アプリケーションプログラムの論理により等価性保証処理が可能なら、アプリケーションプログラムで等価性保証処理を行うことにより等価性保証処理が必要なボリューム領域を小さくし、全面等価性保証処理に必要な時間、資源（ＣＰＵ使用量、Ｉ／Ｏ回数）を小さくすることができ、特に規模の大きなシステムの連続運転化と効率化を実現するという工業的効果がある。
【図面の簡単な説明】
【図１】本発明の構成図
【図２】本発明の実施の形態の構成図
【図３】ボリューム状態管理とアプリ別等価性保証処理対象の関連説明図
【図４】実施の形態の動作を説明するフローチャート
【図５】アプリケーションプログラムによるデータ更新ログ
【図６】アプリケーションプログラムのデータ更新処理のフローチャート
【図７】アプリケーションプログラムによる等価性保証処理のフローチャート
【図８】従来技術のフローチャート（システム起動時の等価性保証処理）
【符号の説明】
１ボリューム状態管理表
２アプリ別等価性保証処理対象領域管理表
３等価性保証処理選択手段
４全面等価性保証処理手段
５アプリ別等価性保証処理手段

Claims

同一内容を別のボリュームに二重に書き込み、一方のボリュームに障害が発生しても他方のボリュームの読み書きを継続可能とする二重化ボリュームシステムにおいて、二つのボリュームの内容の等価性が疑われるとき、ボリュームの二重化運用の状態を示すボリューム状態管理表に基づき、一方から他方のボリュームへ内容を全面複写する全面等価性保証処理手段を有して二重化ボリュームの等価性を保証処理する二重化ボリュームの等価性保証処理装置であって、
アトミシティを保証するデータ更新を行うアプリケーションプログラム毎に該アプリケーションプログラムが更新対象とするボリューム領域内の等価性保証処理を行うアプリ別等価性保証処理手段と、
上記アプリケーションプログラム毎に該アプリケーションプログラムの等価性保証処理対象ボリューム領域と該アプリケーションプログラムのアプリ別等価性保証処理手段の所在を記憶するアプリ別等価性保証処理対象領域管理表と、
上記ボリューム状態管理表および上記アプリ別等価性保証処理対象領域管理表に基づき、ボリューム領域毎に等価性保証の手段として上記アプリ別等価性保証処理手段あるいは上記全面等価性保証処理手段のいずれかを選択する等価性保証処理選択手段と、
を備えることを特徴とする二重化ボリュームの等価性保証処理装置。
同一内容を別のボリュームに二重に書き込み、一方のボリュームに障害が発生しても他方のボリュームの読み書きを継続可能とする二重化ボリュームシステムにおいて、二つのボリュームの内容の等価性が疑われるとき、一方から他方のボリュームへ内容を複写して二重化ボリュームの等価性を保証処理する二重化ボリュームの等価性保証処理方法であって、
二重化ボリュームの対象領域の内、アプリケーションプログラムがアトミシティを保証してデータ更新を行う二重化ボリューム領域を区分し、該区分された二重化ボリューム領域毎に等価性保証処理するアプリケーションプログラムの所在を記憶するステップ、
上記区分された二重化ボリューム領域については該領域毎に所在を記憶された等価性保証処理するアプリケーションプログラムを実行して二重化ボリュームの等価性を保証処理するステップ、
を有することを特徴とする二重化ボリュームの等価性保証処理方法。