JP2000099359A5

JP2000099359A5 -

Info

Publication number: JP2000099359A5
Application number: JP1999253858A
Authority: JP
Filing date: 1999-09-08
Publication date: 2005-07-14
Anticipated expiration: 2019-09-08

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、マルチコンピュータ・システムで復元を行うための技術に関する。
【０００２】
【従来の技術】
上記マルチコンピュータ・システムは、多数のユーザをサポートし、非常に大型のデータベースを記憶するのによく使用される。例えば、通常のシステムは、５０、０００人のユーザをサポートする８つのサーバ・コンピュータから構成することができ、１つまたはそれ以上の３００ギガバイトのデータベースを記憶することができる。
【０００３】
例えば、マイクロソフト社製のオペレーションシステムであるウィンドウズＮＴの制御の下で動作するマイクロソフト・エクスチェンジのような標準サーバ・ソフトウェアに基づく上記システムを提供することができれば便利である。しかし、その場合１つの問題がある。それはコンピュータの中のどれかが故障した場合に、システムを復元できるようにするということである。この規模のあるシステムにクラスタ(cluster)技術を使用すると、あまりにコストが高くなり過ぎる。また、マイクロソフト・エクスチェンジは、クラスタを意識したアプリケーションではないし、また（ノードが２つだけのクラスタであっても）同じサーバ上に２つの段階(instance)のエクスチェンジを持つことはできない。
【０００４】
【発明が解決しようとする課題】
本発明は、複数のコンピュータと、上記各コンピュータに対して１つずつ使用される複数のシステム・ディスク・ユニットと、上記各コンピュータに対して１つずつ使用される複数の追加ディスク・ユニットとを備えるコンピュータ・システムを動作する方法を提供し、従来技術における上述の問題を解消するものである。
【０００５】
【課題を解決するための手段】
従来技術における上述の問題を解消する上記方法は、
(a)上記複数のコンピュータを稼動コンピュータとして指定し、上記コンピュータの他のものを待機コンピュータとして指定するステップと、
(b)システム・ディスク・ユニット上に保持されているデータの同期回復コピーを行うために、上記の別のデータ・ユニットを使用するステップと、
(c)上記稼動コンピュータのどれかが故障した場合、待機コンピュータに、故障したコンピュータに対応する追加ディスク・ユニットを使用させることにより、システムを再構成するステップとを含むことを特徴とする。
【０００６】
【発明の実施の形態】
添付の図面を参照しながら、本発明のコンピュータ・システムを以下に説明するが、これは単に例示としてのものに過ぎない。
【０００７】
本願明細書の場合、下記の用語は特定の意味で使用されている。
【０００８】
「ノード」という用語は、個々のコンピュータ・ハードウェア・コンフィギュレーションを意味する。本実施形態の場合には、各ノードはＩＣＬ（インターナショナル・コンピューターズ・リミテッド）のエキストラサーバ・コンピュータを備える。各ノードは一意の識別番号を持つ。
【０００９】
「サーバ」という用語は、インストールされた特定のサーバ・ソフトウェアを意味する。本実施形態の場合には、各サーバは、インストールされた特定のマイクロソフトＮＴを備える。各サーバは、一意のサーバ名を持ち、任意のノード上で動作（すなわち、作動）することができる。必要な場合には、サーバの動作を中止し、他のノードに再配置することができる。
【００１０】
「システム」という用語は、共通の記憶ユニットにアクセスしている多数のサーバを意味する。
【００１１】
図１について説明すると、この図は、Ｎ＋１のノード１０を備えるシステムを示す。通常の動作中、ノードの中のＮ個が稼動状態にあり、残りの１つのノードが待機状態にある。本実施形態の場合には、Ｎは４つである。（すなわち、ノードは全部で５つある。）各ノード１０は、サーバ１１のホスト役を勤める。
【００１２】
上記システムは、またそれにより、（人間の）オペレータまたはシステム管理装置がシステムを監視し、制御することができるシステム管理ワークステーションを含む。各サーバは、その名前及び現在の動作状態をワークステーション１２上に表示する。１つまたはそれ以上の他のシステム（図示せず）も、同じワークステーションから制御し、監視することができる。
【００１３】
すべてのノード１０は、共有ディスク・アレイ１３に接続している。本実施形態の場合、ディスク・アレイ１３は、ＥＭＣシンメトリクス・ディスク・アレイである。上記ディスク・アレイは、多数の磁気ディスク・ユニットからなり、それらすべては復元動作にとって鏡像になっている（二重になっている）。さらに、ディスク・アレイは、ビジネス継続ボリューム（ＢＣＶ）を提供する多数の追加ディスクを含む。ＢＣＶは、ワークステーション１２上で動作するＥＭＣタイムファインダ・ソフトウェアの制御の下で、１次網に接続することができ、１次網から切り離すことができる有効な第３の網である。ＢＣＶデータは、バックアップを行うために、１次網と同期させることができ、所与の時点で主なデータのスナップショトをとるために、１次網から切り離すことができる。ＢＣＶをこのように分割すると、任意の時点で再接続することができ、両者を再度同期させるために、データを１次網からＢＣＶへ、またＢＣＶから１次網にコピーすることができる。
【００１４】
システムは、またディスク・アレイ１３及び多数の自動磁気テープ・ドライブ１５に接続しているアーカイブ・サーバ１４を含む。動作中、アーカイブ・サーバは、周期的にＢＣＶ内に保持しているデータベースのコピーをテープにコピーすることにより、各データベースのデータをオフラインで保管する。保管が確実に行われると、ＢＣＶは、ＥＭＣタイムファインダ・ソフトウェアにより、回復ＢＣＶを形成するために、再び切り離される前に、主データベースと同期状態に戻る。
【００１５】
図１に示すように、ディスク・アレイ１３は、多数のシステム・ディスク１６を含むが、その中の１つがサーバ１１である。各システム・ディスクは、関連サーバのためのＮＴオペレーティング・システム・ファイル及びコンフィギュレーション・ファイルを含む。すなわち、システム・ディスクは、インストールされたサーバの「性格」を定義するすべての情報を保持する。各システム・ディスクは、関連システム・ディスクのバックアップ・コピーを含む、それに関連するＢＣＶディスク１７を持つ。通常、各ＢＣＶディスク１７は、その対応するシステム・ディスクから切り離されている。上記ＢＣＶディスクは、システム・ディスクが変わった場合だけ、２つのコピーを同期させるために、その対応するシステム・ディスクに接続される。
【００１６】
Ｎ個の稼動ノード１０のどれかが故障した場合には、システム管理ワークステーション１２上で、回復プロセスが開始する。本実施形態の場合、回復プロセスは、タイムファインダ・ソフトウェアに関連するスクリプティング言語で書かれたスクリプトを含む。このプロセスにより、待機ノードに、故障したノードのシステム・ディスクＢＣＶを使用させ、それにより、故障したノード上のサーバを待機ノードに再配置したり、またはその逆を行わせるために、システム管理装置はシステムを再構成する回復手順を使用する。
【００１７】
回復プロセスは、ノード及びサーバの可能な各組合せに対して１つずつ、予め定めた組のデバイスファイルを使用する。この例の場合には、サーバは５つ（待機中のものも含めて）であり、ノードも５つであるので、可能な組合せは２５組あり、上記デバイスファイルも２５供給される。これら各ファイルは、という形により識別される。この場合、Ｎはノード識別名であり、Ｓはサーバ名の最後の３つの数字である。（もちろん、ファイルの命名には、他の慣例的方法も使用することができる。各デバイスファイルは、特定のノード上に特定のサーバをインストールするために必要なすべての情報を含む。
【００１８】
図２に示すように、回復プロセスは下記のステップを含む。
【００１９】
（ステップ２０１）回復プロセスは、最初、システム管理装置により故障したシステムの識別を行う。このステップは、１つ以上のシステムが、同じシステム管理ワークステーションにより管理されている場合だけに必要なものである。
【００２０】
（ステップ２０２）その後、回復プロセスは、故障したノード及び待機ノードの識別番号を入手するように要求する。システム管理装置は、システム管理ワークステーション１２上に表示された情報により、これらノード番号を決定することができる。
【００２１】
（ステップ２０３）次に、回復プロセスは、故障したサーバ（すなわち、故障したノード上で、現在動作しているサーバ）の名前を入手するように要求する。回復プロセスは、また各システムに対して所定の待機サーバの名前を自動的に決定する。
【００２２】
（ステップ２０４）回復プロセスは、また各サーバ名を特定の装置識別子に関連づける参照用テーブルを使用して、故障したサーバ及び待機サーバに関連する、ＢＣＶの装置識別子を自動的に決定する。
【００２３】
（ステップ２０５）その後、回復プロセスは、これら２つのＢＣＶの現在の状態を決定するために、タイムファインダ・ソフトウェアのＢＣＶ問い合わせコマンドを呼び出す。上記２つのＢＣＶは切り離された状態でなければならない。
【００２４】
情報２つのＢＣＶの１つまたは両方が、切り離された状態でない場合には、回復プロセスは打ち切られ、システム管理装置は、適当な技術的サポート・サービスを呼び出すようにプロンプトされる。
【００２５】
（ステップ２０６）両方のＢＣＶが切り離されている場合には、回復プロセスは、故障したサーバ及び待機サーバの両方の動作を確実に停止するように、システム管理装置にプロンプトすることにより、その動作を継続する。回復プロセスは、上記動作の停止が行われたことの確認を待つ。
【００２６】
（ステップ２０７）故障したサーバ及び待機サーバの両方が、その動作を停止した場合には、回復プロセスは、下記のように２つのデバイスファイル名を作成する。
【００２７】
第１のファイル名は、n(W)_is_(X)である。ここで、Ｗは待機ノードのノード番号であり、Ｘは故障したサーバ名の最後の３つの数字である。
【００２８】
第２のファイル名は、n(Y)_is_(Z)である。ここで、Ｙは故障したノードのノード番号であり、Ｚは待機サーバ名の最後の３つの数字である。
【００２９】
（ステップ２０８）その後、回復プロセスは、タイムファインダＢＣＶ復元コマンドを呼び出し、それをパラメータとして第１のデバイスファイル名に渡す。そうすることにより、故障したノードのＢＣＶが、待機サーバのシステム・ディスクにリンクされ、ＢＣＶからシステム・ディスクへのデータのコピーが開始する。これにより、故障したノード上で動作していたサーバが、待機ノード上に再配置されるのを理解することができるだろう。
【００３０】
回復プロセスは、またＢＣＶ復元コマンドを呼出、それをパラメータとして第２のデバイスファイル名に渡す。そうすることにより、待機ノードのＢＣＶが、故障したサーバのシステム・ディスクにリンクされ、このＢＣＶからシステム・ディスクへのデータのコピーが開始する。それ故、これにより、待機ノード上で動作していたサーバが、故障したノード上に再配置される。
【００３１】
一例を挙げると、図３は、ノード１が故障した場合を示す。この場合、ノード４は待機ノードである。この図に示すように、待機ノードのＢＣＶディスクは、故障したノードのシステム・ディスクにリンクされ、故障したノードのＢＣＶは、待機ノードのシステム・ディスクにリンクされる。
【００３２】
復元コマンドが動作している間に、回復プロセスは、エラー応答をチェックし、上記応答すべてをシステム管理装置に報告する。回復プロセスは、またすべての処置を、処置直前にログ・ファイルに書き込む。
【００３３】
（ステップ２０９）復元コマンドを発行した後で、回復プロセスは、それが作動させる新しいノード名を知らせて、回復したサーバ（すなわち、故障したノードから待機ノードに移動したサーバ）を再始動するように、システム管理装置にプロンプトする。
【００３４】
復元コマンドは、背景で動作していて、通常、完了するのに約１時間掛かることに留意されたい。しかし、回復したサーバは直ちに再始動することができ、そのデータには、復元コマンドの実行の終了を待たないでアクセスすることができる。
【００３５】
（ステップ２１０）回復手順は、タイムファインダＢＣＶ問い合わせコマンドにより、ＢＣＶ復元動作の完了を監視する。
【００３６】
（ステップ２１１）復元動作が完了すると、回復手順は、タイムファインダＢＣＶ分割コマンドを発行する。上記コマンドはＢＣＶをシステム・ディスクから切り離す。回復はこれで完了し、回復プロセスは終了する。
【００３７】
故障したノードの修理が完了すると、必要に応じて、このノードをリブートすることができ、このノードは待機サーバになる。その後、稼動ノードのどれかが故障した場合には、回復手順を反復して行うことができる。
【００３８】
本発明の範囲から逸脱することなしに、上記システムを種々に修正することができることを理解されたい。例えば、異なる数のディスク及びコンピュータを使用することができる。また、他のオペレーティング・システムで、他のハードウェア・コンフィギュレーションにより本発明を実行することもできる。さらに、スクリプトにより回復手順を実行する代わりに、例えば、本発明をオペレーティング・システムに内蔵させることもできる。 Description: TECHNICAL FIELD [Detailed description of the invention]
[0001]
[Industrial application field]
The present invention relates to a technique for performing restoration in a multi-computer system.
0002.
[Conventional technology]
The multi-computer system supports a large number of users and is often used to store very large databases. For example, a typical system can consist of eight server computers that support 50,000 users and can store one or more 300 gigabyte databases.
0003
For example, it would be convenient to be able to provide the above system based on standard server software such as Microsoft Exchange, which operates under the control of Windows NT, an operating system manufactured by Microsoft. However, there is one problem in that case. That is to allow the system to be restored in the event of any failure in the computer. Using cluster technology on a system of this size would be too costly. Also, Microsoft Exchange is not a cluster-aware application, nor can it have a two-instance exchange on the same server (even in a cluster with only two nodes).
0004
[Problems to be Solved by the Invention]
The present invention includes a plurality of computers, a plurality of system disk units used one by one for each of the above computers, and a plurality of additional disk units used one by one for each of the above computers. It provides a method of operating a computer system provided and solves the above-mentioned problems in the prior art.
0005
[Means for solving problems]
The above-mentioned method for solving the above-mentioned problem in the prior art is
(a) The steps of designating the multiple computers as active computers and the other computers as standby computers.
(b) The step of using another data unit above to make a synchronous recovery copy of the data held on the system disk unit, and
(c) In the event of any of the above operating computers failing, it comprises the step of reconfiguring the system by having the standby computer use an additional disk unit corresponding to the failed computer.
0006
BEST MODE FOR CARRYING OUT THE INVENTION
The computer system of the present invention is described below with reference to the accompanying drawings, but this is merely an example.
0007
In the case of the present specification, the following terms are used with specific meanings.
0008
The term "node" means an individual computer hardware configuration. In the case of this embodiment, each node includes an ICL (International Computers Limited) extra server computer. Each node has a unique identification number.
0009
The term "server" means specific server software installed. In the case of this embodiment, each server includes a specific installed Microsoft NT. Each server has a unique server name and can operate (ie, operate) on any node. If necessary, the server can be stopped and relocated to another node.
0010
The term "system" means a large number of servers accessing a common storage unit.
0011
With reference to FIG. 1, this figure shows a system with N + 1 node 10. During normal operation, N of the nodes are in the active state and the remaining one node is in the standby state. In the case of this embodiment, N is four. (That is, there are five nodes in total.) Each node 10 serves as a host for the server 11.
0012
The system also includes a system management workstation that allows a (human) operator or system management device to monitor and control the system. Each server displays its name and current operating status on workstation 12. One or more other systems (not shown) can also be controlled and monitored from the same workstation.
0013
All nodes 10 are connected to the shared disk array 13. In the case of this embodiment, the disk array 13 is an EMC symmetry disk array. The disk array consists of a number of magnetic disk units, all of which are mirror images (duplex) of the restore operation. In addition, the disk array includes a number of additional disks that provide a business continuity volume (BCV). The BCV is an effective third network that can be connected to and disconnected from the primary network under the control of the EMC Timefinder software running on workstation 12. BCV data can be synchronized with the primary network for backup and detached from the primary network to snap the main data at a given point in time. When the BCV is divided in this way, it can be reconnected at any time, and data can be copied from the primary network to the BCV and from the BCV to the primary network in order to resynchronize the two.
0014.
The system also includes an archive server 14 connected to a disk array 13 and a number of automatic tape drives 15. During operation, the archive server stores the data of each database offline by periodically copying the copy of the database held in the BCV to tape. When the storage is ensured, the BCV is returned to sync with the main database by the EMC Timefinder software before being detached again to form a recovery BCV.
0015.
As shown in FIG. 1, the disk array 13 includes a large number of system disks 16, one of which is the server 11. Each system disk contains NT operating system files and configuration files for the associated server. That is, the system disk holds all the information that defines the "character" of the installed server. Each system disk has a BCV disk 17 associated with it, including a backup copy of the associated system disk. Typically, each BCV disk 17 is detached from its corresponding system disk. The BCV disk is connected to its corresponding system disk to synchronize the two copies only if the system disk changes.
0016.
If any of the N working nodes 10 fails, a recovery process begins on the system management workstation 12. In the case of this embodiment, the recovery process includes a script written in a scripting language associated with the timefinder software. This process causes the standby node to use the system disk BCV of the failed node, thereby relocating the server on the failed node to the standby node and vice versa. Uses a recovery procedure that reconfigures the system.
[0017]
The recovery process uses a predetermined set of device files, one for each possible combination of nodes and servers. In the case of this example, since there are 5 servers (including those in standby) and 5 nodes, there are 25 possible combinations, and 25 of the above device files are also supplied. Each of these files is identified by: In this case, N is the node identification name and S is the last three numbers of the server name. (Of course, other conventional methods can be used to name the files. Each device file contains all the information needed to install a particular server on a particular node.
0018
As shown in FIG. 2, the recovery process involves the following steps:
0019
(Step 201) The recovery process first identifies the failed system by the system management device. This step is necessary only if one or more systems are managed by the same systems management workstation.
0020
(Step 202) The recovery process then requests to obtain identification numbers for the failed and standby nodes. The system management device can determine these node numbers from the information displayed on the system management workstation 12.
0021.
(Step 203) The recovery process then requests to obtain the name of the failed server (ie, the server currently running on the failed node). The recovery process also automatically determines the name of a given standby server for each system.
0022.
(Step 204) The recovery process also uses a reference table that associates each server name with a particular device identifier to automatically determine the BCV device identifier associated with the failed and standby servers.
[0023]
(Step 205) The recovery process then calls the BCV query command of the timefinder software to determine the current state of these two BCVs. The above two BCVs must be separated.
0024
Information If one or both of the two BCVs are not in a detached state, the recovery process is terminated and the system management unit is prompted to call the appropriate technical support service.
0025
(Step 206) If both BCVs are disconnected, the recovery process performs its operation by prompting the system management unit to ensure that both the failed server and the standby server stop operating. continue. The recovery process waits for confirmation that the above operation has been stopped.
0026
(Step 207) If both the failed server and the standby server stop their operation, the recovery process creates two device file names as described below.
[0027]
The first file name is n (W) _is_ (X). Here, W is the node number of the standby node, and X is the last three numbers of the failed server name.
[0028]
The second file name is n (Y) _is_ (Z). Here, Y is the node number of the failed node, and Z is the last three numbers of the standby server name.
[0029]
(Step 208) The recovery process then calls the TimeFinder BCV restore command and passes it as a parameter to the first device file name. By doing so, the BCV of the failed node is linked to the system disk of the standby server, and copying of data from the BCV to the system disk begins. This will allow you to understand that the server that was running on the failed node will be relocated on the standby node.
[0030]
The recovery process also calls the BCV restore command , passing it as a parameter to the second device file name. By doing so, the BCV of the standby node is linked to the system disk of the failed server, and copying of data from this BCV to the system disk is started. Therefore, this causes the server running on the standby node to be relocated on the failed node.
0031
As an example, FIG. 3 shows a case where node 1 fails. In this case, node 4 is a standby node. As shown in this figure, the BCV disk of the standby node is linked to the system disk of the failed node, and the BCV of the failed node is linked to the system disk of the standby node.
[0032]
While the restore command is running, the recovery process checks for error responses and reports all of the above responses to the system management unit. The recovery process also writes all actions to the log file just prior to the action.
0033
(Step 209) After issuing the restore command, the recovery process will inform you of the new node name it will operate on and restart the recovered server (ie, the server that moved from the failed node to the standby node). , Prompt the system management device.
0034
Note that the restore command is running in the background and usually takes about an hour to complete. However, the recovered server can be restarted immediately and its data can be accessed without waiting for the restore command to finish executing.
0035.
(Step 210) In the recovery procedure, the completion of the BCV restoration operation is monitored by the time finder BCV inquiry command.
0036
(Step 211) When the restoration operation is completed, the recovery procedure issues a time finder BCV division command. The above command disconnects the BCV from the system disk. The recovery is now complete and the recovery process is complete.
0037
Once the failed node has been repaired, it can be rebooted if necessary and it becomes a standby server. After that, if any of the active nodes fails, the recovery procedure can be repeated.
[0038]
It should be understood that the system can be modified in various ways without departing from the scope of the present invention. For example, different numbers of discs and computers can be used. It is also possible to run the invention on other operating systems with other hardware configurations. Further, instead of scripting the recovery procedure, the invention can be incorporated into the operating system, for example.

Claims

Operation of a computer system comprising a plurality of computers, a plurality of system disk units used one for each computer, and a plurality of additional disk units used one for each computer A method,
(a) designating a plurality of the computers as active computers and designating other ones of the computers as standby computers;
(b) a step of using additional disk unit in order to perform a synchronized recovery copy of data held in the system disk units on,
and (c) reconfiguring the system by causing the standby computer to use the additional disk unit corresponding to the failed computer if any of the operating computers fails.

The method of claim 1, wherein reconfiguring the system comprises connecting the additional disk unit associated with the failed computer to a system disk of the standby computer from the additional disk to the system disk. Initiating the copying of data to.

3. The method of claim 2, further comprising the step of restarting the standby computer while data is being copied in the background.

A method according to any one of claims 1 to 3, the particular operating system installed, one for each possible combination of a particular computer hardware configuration, a set device files comprising the step of maintaining the step of reconfiguring the system, and selecting two device files corresponding to the new configuration of the failed computer and the standby computer, the said device file system Using to control reconfiguration of the.