管理の手引き


DB2 高可用性エージェント

DB2 高可用性エージェントは、 DB2 と SC2.x の間の仲介者として機能します。 このエージェントにより、DB2 についての詳しい知識がなくても、 Sun Cluster 2.2 ソフトウェアはクラスター環境で DB2 を制御することができます。 EE および EEE 両インスタンスのための 1 つのエージェントがあります。 このエージェントは管理インスタンスとデータベース・インスタンスの両方をサポートします。

hadb2 サービスの登録

SC2.2 を使用して作業するには、 DB2 HA エージェントが登録されていなければなりません。 データ・サービスを登録すると、 使用可能な制御メソッドとそれらが常駐するディレクトリーが SC2.2 に知らされます。 HA エージェントに付属している特殊なスクリプト hadb2_reg は、 hadb2 サービスを EE および EEE インスタンスの両方に対して登録できます。 hadb2_reg スクリプトは、 クラスター全体に対して 1 度だけ実行する必要があります。

DB2 HA エージェントの制御メソッドのセットは 1 つだけですが、 それらが登録される方法は、 EEE インスタンスが相互引き受け構成で使用されるかどうかによって異なります。 ホット・スタンドバイ構成の EE インスタンスまたは EEE インスタンスの場合、 HA-NFS は使用されません。 したがって、 hadb2 サービスが HA-NFS に依存することを SC2.2 ソフトウェアに知らせる -d nfs スイッチは必要ありません。

DB2 V7.1 制御メソッドを EEE インスタンス用に登録するために hadb2_reg が使用する実際のコマンドは以下の通りです。

   hareg -r hadb2 -b /opt/IBMdb2/V7.1/ha -m
   START=hadb2_start,START_NET=hadb2_startnet,STOP_NET=hadb2_stopnet,
   FM_START=hadb2_fmstart,FM_STOP=hadb2_fmstop
   -t START_NET=$TIMEOUT,STOP_NET=$TIMEOUT -d nfs

-b スイッチは、 すべての制御メソッドを opt/IBMdb2/V7.1/ha ディレクトリーで探すように SC2.x に指示します。 -m スイッチは、 hadb2 サービス用の実際の制御メソッドを定義します。 -t スイッチは、 START_NET および STOP_NET 制御メソッドのタイムアウトを定義します。 各制御メソッドについての詳細は、 Sun Cluster の資料を参照してください。

hadb2_unreg スクリプトを使用すると、 hadb2 サービスを登録解除することができます。 これは、hadb2_reg と同様、クラスターで 1 度だけ実行する必要があります。

hadb2tab ファイル

hadb2tab ファイルは、 DB2 HA エージェント用の主な構成ファイルです。 各制御メソッドはこのファイルを調べて、 可用性の高いインスタンスを見つけ出します。 hadb2tab ファイルは、 DB2 UDB バージョン 7.1 の /var/db2/v71/ ディレクトリーの下にあります。 このファイルは複数インスタンスをサポートしており、 それぞれの非コメント行は、それぞれの HA インスタンスを表します。 以下は、hadb2tab ファイルの例です。

   <scadmin@thrash(203)# cat hadb2tab
   EEE DATA db2eee jolt ON /export/ha_home /log0/home #Added by DB2 HA software
   EE ADMIN db2ee log1 ON  -               -          #Added by DB2 HA software

最初のフィールドは、 インスタンスが EE インスタンスであるか、 または EEE インスタンスであるかを DB2 HA エージェントに示します。 2 番目のフィールドは、 インスタンスがデータ・インスタンスであるか、 または管理インスタンスであるかを示します。 3 番目のフィールドには、 HA インスタンスのユーザー名が含まれています。 4 番目のフィールドは、 インスタンスの論理ホストまたは HA-NFS ホストです。 これは、インスタンスが EE インスタンスと EEE インスタンスのいずれであるかに依存します。 5 番目のフィールドは、 インスタンスの障害モニターのオン / オフを示します。 最後の 2 つのフィールドは、 それぞれ、ローカル・マウント・ポイントとリモート HA-NFS ディレクトリーです。 これらのフィールドは、 使用されない場合は - (ハイフン) に設定され、 EEE 相互引き受け構成でのみ使用されます。 行で「#」マーカーより前にある情報が、長さ 0 であるか、 またはインスタンスの有効な定義であれば、 hadb2tab ファイルでコメントが使用できます。

制御メソッド

SC2.2 エージェントの制御メソッドは、 一連のスクリプトまたはプログラムです。 DB2 (Solaris 版) のエージェントは、 以下のメソッドを含む一連のプログラムです。

START_NET
hadb2_startnet が、DB2 を始動するのに使用されます。

STOP_NET
hadb2_stopnet が、DB2 を停止するのに使用されます。

FM_START
hadb2_fmstart が、 DB2 の障害モニターを始動するのに使用されます。

FM_STOP
hadb2_fmstop が、 DB2 障害モニターを停止するのに使用されます。

これらの制御メソッドについての詳細は、 Sun Cluster の資料を参照してください。

EE インスタンスの場合、 インスタンスに関連する論理ホストは、 hadb2tab ファイルで定義されます。 ただし、EEE インスタンスの場合、 制御メソッドは以下のファイルも参照しなければなりません。

   ~<instance>/sqllib/ha/hadb2-eee.cfg

~<instance> は、 インスタンス所有者のホーム・ディレクトリーです。 このファイルには各データベース区画ごとに 1 つの行が含まれ、 データベース区画と論理ホストを関連付けるために使用されます。 以下に示すのは、 有効な hadb2-eee.cfg ファイルの例です。

   crackle % cat hadb2-eee.cfg
   NODE:log0 0
   NODE:log0 1
   NODE:log1 2
   NODE:log1 3

インスタンスまたはデータベース区画は、 クラスター内で対応する論理ホストについていきます。 論理ホストは、 基礎となるハードウェアおよび SC2.2 によってサポートされるクラスター内のマシンならどれにでも移動できます。 構成が適切にセットアップされていれば、 DB2 は SC2.2 ソフトウェアによってサポートされるどのトポロジーもサポートします。

インスタンスの全情報を読み取った後、 制御メソッドは、 インスタンスと関連する論理ホストを認識しています。 コマンド行引き数を解析した後、 制御メソッドは、 現行のマシンによりホストされる論理ホストとホストされない論理ホストを認識しています。

以下の表は、 実行されている制御メソッドと、 データベース区画またはインスタンスと関連した論理ホストが現行のマシンでホストされているかどうかによって行われるアクションを示しています。
制御メソッド 関連した論理ホストがホストされている場合 関連した論理ホストがホストされていない場合
START_NET DB2 インスタンスまたはデータベース区画を開始する 処置なし
STOP_NET 処置なし DB2 インスタンスまたはデータベース区画を停止する
FM_START インスタンスの障害モニターを開始する 処置なし
FM_STOP 処置なし インスタンスの障害モニターを停止する

開始アクションを実行する制御メソッドは、 現在ホストされている論理ホストだけを処理し、 停止アクションを実行する制御メソッドは、 現在ホストされていない論理ホストだけを処理します。

HA-NFS が使用されている場合、制御メソッドは、 特別な方法で HA-NFS ディレクトリーをマウントする必要もあります。 HA-NFS のローカル・マウント・ポイントおよびディレクトリーが - (ハイフン) として定義されていない場合、 制御メソッドはローカル・マウント・ポイントで statvfs(2) を実行します。 ローカル・マウント・ポイントのファイル・システムのタイプが nfs でない場合、 エージェントは、 hadb2tab 行の情報を使用してファイル・システムのマウントを試みます。 HA-NFS のマウント・ポイントおよびディレクトリーが - (ハイフン) として定義されていない場合、 対応する論理ホストの vfstab ファイルが、 インスタンスのホーム・ディレクトリーを含むファイル・システムをマウントするために必要となります。 HA-NFS のローカル・マウント・ポイントおよびリモート・ディレクトリーは、 EE および EEE のホット・スタンドバイ構成の場合、 - (ハイフン) としてのみ定義できます。

ユーザー・スクリプト

このスクリプトは制御メソッドから実行され、機能を追加します。 このスクリプトには制御メソッドと同じコマンド行引き数が渡され、 システム管理者またはデータベース管理者によって書き込まれます。

バックグラウンドで実行されないスクリプト内からプログラムを実行しなければならない場合、 nohup(1) を使用してそのプログラムをバックグラウンドで実行することを考慮してください。 nohup プログラムは、 実行されているプログラムを、 SIGHUP (またはハングアップ) シグナルから保護します。 nohup を使用しないと、 バックグラウンドでスクリプトから実行されているプログラムは、 スクリプトの終了時に SIGHUP シグナルの結果として強制終了される場合があります。

制御メソッドは以下のスクリプトを実行します。

~instance は、 HA インスタンスのホーム・ディレクトリーです。

fm_warning スクリプトを除き、 各ユーザー・スクリプトは、 そのスクリプトを呼び出した制御メソッドと同じ引き数を使用して実行されます。 EEE インスタンスを使用している場合、 データベース区画番号も (最後の引き数として) ユーザー・スクリプトに渡されます。

/var/db2/v71/failover スクリプトは、START_NET メソッドの最初に呼び出され、 バックグラウンドで実行されます。 このスクリプトを使用すると、 たとえばフェールオーバーが起きたときにサポート・スタッフに電子メールを出すことができます。 以下に、フェールオーバー・スクリプトの例を示します。

   #!/bin/ksh
 
   # E-mail or page support staff to notify them that a failover has occurred.
 
   echo "Failover occurred on machine `hostname`:Running $0!" |/bin/mail admin@sphere.torolab.ibm.com

スクリプトから正常に電子メールを出すためには、 sendmail(1m) が適切にシステムで構成されていなければなりません。

名前から分かるように、 pre_db2start スクリプトは、 db2start が呼び出される直前に実行されます。 このスクリプトは、 データベース・マネージャー構成パラメーターの変更などのタスクで使用することができます。 完了までに最大で 20 秒が与えられています。 EEE インスタンスの場合、 このスクリプトは db2start が各データベース区画で呼び出される前に実行されます。 このスクリプトは、データ・インスタンスにのみ適用でき、 管理インスタンスには適用できません。

同様に、post_db2start スクリプトは、 db2start が呼び出された直後に 実行されます。 このスクリプトは、 データベースの再始動のようなタスクで使用することができます。 これは、バックグラウンドで実行されるので、 その実行時間が他のインスタンスに支障をきたすことはありません。 このスクリプトは、データ・インスタンスにのみ適用でき、 管理インスタンスには適用できません。

インスタンス所有者のホーム・ディレクトリーの下にある post_failover スクリプトは、 インスタンスの処理の後で実行されます。 このスクリプトを使用すると、 DB2 が機能していることをクライアント・アプリケーションに知らせたり、 データベースを活動化したり、 状況ファイルを管理者に送信したりすることができます。 これは、バックグラウンドで実行されるので、 その実行時に別の HA インスタンスに対するアクションが遅れることはありません。 以下に、フェールオーバー後処理スクリプトの例を示します。

   #!/bin/ksh
   #
 
   # Send the status file to the administrato-r.
   mail admin@sphere.torolab.ibm.com </tmp/HA.info.db2eee

DB2 HA エージェントの START_NET および STOP_NET メソッドは両方とも、 各インスタンスの処理の後に状況ファイルを作成します。 状況ファイルの名前は以下の通りです。

   /tmp/HA.info.<instance>

instance は、 インスタンス所有者のユーザー名です。 状況ファイルには、インスタンスの開始および停止レポートと、 制御メソッドを実行するのにかかった時間が含まれます。 以下に、状況ファイルの例を示します。

   scadmin@crackle(173)# cat /tmp/HA.info.db2eee
   -----  Elapsed Time: 00:00:18           -----
   -----  Elapsed Time: 00:00:00  (HA-NFS) -----
 
   NODE     ACTION     RESULT     TRIES     RC
   ----     ------     ------     -----     --
      4     stop       success        3    1064
      5     stop       success        1    1064
      6     stop       success        2    1064
      7     stop       success        2    1064
      8     stop       success        1    1064
   ---------------------------------------------

pre_db2stop スクリプトは、 db2stop が呼び出される直前に実行されます。 このスクリプトを使用すると、 DB2 が停止しようとしていることをクライアント・アプリケーションに通知することができます。 完了までに最大で 20 秒が与えられます。 このスクリプトは、データ・インスタンスにのみ適用でき、 管理インスタンスには適用できません。

障害モニターも、 予期せぬシャットダウンのために DB2 が再始動されたときに、 ユーザー・スクリプトを実行します。 以下のスクリプトが呼び出されます。

   ~<instance>/sqllib/ha/fm_warning

fm_warning スクリプトを使用すると、 DB2 が障害モニターによって再始動されたことをシステム管理者に通知することができます。 システム管理者は、 DB2 が突然シャットダウンした理由を突き止め、 これが再び起きないように適切な処置を取る必要があります。 fm_warning スクリプトはバックグラウンドで実行されます。

他の考慮事項

HA データ・サービスがオフにされると、 フェールオーバーまたはクラスターの再構成時には停止メソッドだけが実行されます。 他のメソッドは、HA データ・サービスが適切に登録され、 オンにされた場合にのみ実行されます。

クラスター内の各マシンに、 そのマシンが担当できるすべてのデータ・サービスを実行するのに十分なリソースがあることを確認してください。 CPU のロード、メモリー、スワップ、およびカーネル・パラメーターなどのリソースは、 クラスターが実働する前に考慮しなければなりません。 たとえば、 クラスター内のマシンが 2 つの DB2 インスタンスを実行する必要がある場合、 そのマシンのカーネル・パラメーターは、 各インスタンスで必要とされるものの合計でなければなりません。

障害モニター

障害モニターがオンにされると、 障害モニターはクラスターの再構成時またはフェールオーバー時に始動されます。 DB2 が START_NET スクリプトによって始動されていない場合、 障害モニター自身が DB2 を始動します。 障害モニターは、 DB2 が始動しなかったかどうか、 または不明な理由でシャットダウンされたかどうかを検出できます。 このため、 障害モニターがオンになっているときは、DB2 を手作業でシャットダウンしないことが重要です。 障害モニターはこれを予期しないシャットダウンと見なし、 DB2 を再始動します。 これがあまりにも多く起きる場合、 適切な論理ホストがフェールオーバーされます。

障害モニターがインスタンスで使用可能になっているとき、 インスタンスを手作業で開始または停止する正しい方法は、 最初に障害モニターまたは hadb2 サービスをオフにすることです。 これらのアクションの両方とも、 -f および -s スイッチを使用した hadb2_setup コマンドによって開始できます (hadb2_setup コマンドを参照)。
注:同じ論理ホストについて複数のインスタンスを使用しないでください。 複数のインスタンスが 1 つの論理ホストと関連付けられていると、 良好な状態にあるインスタンスが、 不良の状態にあるインスタンスとともにフェールオーバーされる可能性があります。

EEE に関する考慮事項

論理ホストと関連させるデータベース区画を決定するときは、 それらのデータベース区画がどのようにフェールオーバーするかを考慮することが重要です。 2 つのマシン間にある 4 つのデータベース区画で使用される 2 マシン・クラスターを考慮してみましょう。 これは、図 120 に示されています。

図 120. 4 つのデータベース区画を持つ 2 マシン・クラスター

4 つのデータベース区画を持つ 2 マシン・クラスター

一方の論理ホストを各データベース区画と関連付け、 他方を HA-NFS に関連付けます。 この場合、 すべての論理ホストが 1 つのシステムによってホストされていると、 問題が生じる可能性があります。 システムに障害が起きる場合、 すべての論理ホストを同時にシステムから移動しなければなりません。 不運にも、 Sun Cluster は予測可能な順序で論理ホストを移動しないので、 データベース区画が関連付けられている論理ホストが HA-NFS の論理ホストの前に移動する可能性があります。 単一のシステムでホストされるものごとにデータベース区画をグループ分けするのは良いアイデアです。 このとき、 通常 1 つのマシンでホストされる 2 つのデータベース区画が、 単一の論理ホストと関連付けられています。

EEE インスタンスによって使用される db2nodes.cfg ファイルは、 データベース区画が常駐するマシンを示すように更新されます。 たとえば、すべてのデータベース区画が「crackle」というマシンにある場合、 db2nodes.cfg ファイルは以下のようになります。

   scadmin@crackle(193)# cat db2nodes.cfg
   0 crackle 0 204.152.65.33
   1 crackle 1 204.152.65.33
   2 crackle 2 204.152.65.33
   3 crackle 3 204.152.65.33
   4 crackle 4 204.152.65.33
   5 crackle 5 204.152.65.33
   6 crackle 6 204.152.65.33
   7 crackle 7 204.152.65.33
   8 crackle 8 204.152.65.33

これらのデータベース区画の一部が「thrash」というマシンに移動すると、 db2nodes.cfg ファイルは以下のように更新されます。

   scadmin@crackle(193)# cat db2nodes.cfg
   0 crackle 0 204.152.65.33
   1 crackle 1 204.152.65.33
   2 crackle 2 204.152.65.33
   3 crackle 3 204.152.65.33
   4 thrash 0 204.152.65.34
   5 thrash 1 204.152.65.34
   6 thrash 2 204.152.65.34
   7 thrash 3 204.152.65.34
   8 thrash 4 204.152.65.34

マシン名「thrash」を反映するようにホスト名とスイッチ名の両方が変更されることと、 ポート番号も異なることに注意してください。

HA.config ファイル

存在する場合、 /etc/HA.config ファイルには、 いくつかの構成オプションが含まれます。 これには、以下のものが含まれます。

   scadmin@thrash(204)# cat /etc/HA.config
   SYSLOG_FACILITY=LOG_LOCAL3
   SYSLOG_LPRIORITY=LOG_INFO
   SYSLOG_EPRIORITY=LOG_ERR
   USE_INTERCONNECT=auto
   SWITCH_NAME=204.152.65.18
   DEBUG_LEVEL=2
   FAILS_PER_HOUR=2
   FAILS_PER_DAY=4
   FAILS_PER_WEEK=10
   FM_FAIL_SEV=soft
   DB2START_TIMEOUT=60
   DB2STOP_TIMEOUT=500
   SCRIPT_USER=bin
注:HA.config ファイルが存在しない場合、 デフォルト値が使用されます。

SYSLOG_FACILITY 変数は、 メッセージおよびエラーの両方をログに記録するための SYSLOG 機能を設定します。 SYSLOG_LPRIORITY および SYSLOG_EPRIORITY 変数は、 情報メッセージおよびエラー・メッセージのそれぞれをログに記録するための SYSLOG 優先順位を設定します。

SYSLOG デーモンが DB2 HA エージェントからの情報をログに記録できるようにするために、 いくらかの変更が必要となる場合もあります。 たとえば、 /etc/syslog.conf ファイルに追加された以下の 2 行のうちの 1 つは、 SYSLOG デーモンに、情報をログ・ファイルに書き込むよう指示します。

   *.notice                                        /var/adm/SC.x
   local3.info                                     /var/adm/SC.LOG_LOCAL3

Sun Cluster は通常、 高速内部接続を行います。 DB2 との間で高速内部接続を使用するには、 USE_INTERCONNECT を auto または override に設定します。 auto 設定 (デフォルト) では、 Sun 内部論理ネットワーク・インターフェースを使用します。 最初のインターフェースに障害が起きると、 このインターフェースは別の物理インターフェースに移されます。 USE_INTERCONNECT が override に設定されている場合、 スイッチ名は SWITCH_NAME 変数からとられます。 あるいは、 USE_INTERCONNECT を no に設定することができます。 これは高速内部接続を使用しないことを指定します。

DEBUG_LEVEL は、 フェールオーバー時にログに記録される情報の量を指定します。 これは 0 〜 10 の数字であり、10 が最高のデバッグ・レベルです。 情報は、指定した SYSLOG 優先順位および機能でログに記録されます。 問題が生じた場合は、 デバッグ・レベルを最大レベルに設定し、 SYSLOG が HA エージェントからの出力をログを記録するように構成してから、 SYSLOG 出力を IBM サービスに送ってください。

変数 FAILS_PER_HOUR、FAILS_PER_DAY、および FAILS_PER_WEEK は、 DB2 障害モニターが論理ホストをフェールオーバーするときを決定するのに役立ちます。 各 HA 環境は異なっています。 許容できる DB2 障害の数を決めなければなりません。 「許容できる」障害が起きるたびに、 DB2 は同じマシン上で再始動されます。 これら 3 つの障害しきい値のうちの 1 つを超えると、 インスタンスまたはデータベース区画に関連した論理ホストがフェールオーバーされます。

FM_FAIL_SEV 変数は、 フェールオーバーが「ソフト」であるか「ハード」であるかを指定します。 詳細については、 Sun Cluster の資料で hactl(1m) を参照してください。

DB2START_TIMEOUT および DB2STOP_TIMEOUT 変数は、 db2start および db2stop が実行可能な最大秒数を指定します。 指定した間隔が過ぎると、 HA エージェントは操作が失敗したとみなし、 インスタンスの再始動を試みます。

特定のインスタンスと関連していないユーザー・スクリプトがあります。 通常、これらのスクリプトはルートとして実行されますが、 これは、SCRIPT_USER 変数によりオーバーライド可能です。 SCRIPT_USER 変数を設定すれば、これらのスクリプトを実行できるユーザー ID を指定できます。

制御メソッドが DB2 コマンドを実行する方法

DB2 HA エージェントは、 su コマンドを使用して、 インスタンス所有者としてコマンドを実行します。 実際のコマンドは以下のようなものです。

   su - <instance> -c "db2stop"

instance は、 インスタンスのユーザー名です。

インスタンス所有者の .profile ファイルが su に適したものであるようにすることは重要です。 そうでないと、 su コマンドは正常に機能しない可能性があります。 su コマンドを手作業で、 またはスクリプトから呼び出して、 コマンドを正常に実行できることを確認してください。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]