管理の手引き


MSCS 環境で DB2 を管理する

MSCS クラスターを使用している場合、DB2 インスタンスには毎日の操作、データベースの展開、 およびデータベース構成に関係する付加的な計画を必要とします。 DB2 を MSCS ノードで透過的に実行するには、 付加的な管理用タスクを実行する必要があります。 すべての DB2 従属のオペレーティング・システム・リソースは、 すべての MSCS ノードで使用可能でなければなりません。 これらのオペレーティング・システムのいくつかは、MSCS の効力範囲外です。 つまり、MSCS リソースとして定義できません。 同じオペレーティング・システム・リソースがすべての MSCS ノードで使用可能であるように、 各システムを確実に構成することが必要です。 以下のセクションでは、行う必要がある付加的な作業を説明します。

DB2 リソースの開始および停止

DB2 リソースは、 Cluster Administrator ツールから開始したり停止したりするべきです。 いくつかのメカニズムは db2start コマンド、 および「コントロール パネル」からの 「サービス」オプションなどの DB2 インスタンスを開始するのに使用できます。 しかし、DB2 が Cluster Administrator から開始しない場合、 MSCS ソフトウェアは DB2 インスタンスの状態を感知しません。 DB2 インスタンスが Cluster Administrator を使用して開始され、 db2stop コマンドを使用して停止される場合、 MSCS ソフトウェアは db2stop コマンドをソフトウェア障害として解釈し、 DB2 を再始動しようとします。 (現在の MSCS インターフェースは、 リソース状態 の通知をサポートしません。)

同様に、db2start を使用して DB2 インスタンスを開始する場合、 MSCS はリソースがオンライン上にあるかどうか検出できません。 データベース・サーバーが失敗すると、 MSCS は DB2 リソースをクラスター中のフェールオーバー・マシン上でオンラインにすることはありません。

3 つの操作が DB2 インスタンスに適用します。

オンライン
この操作は、db2start コマンドの使用と同じです。 DB2 がすでに活動状態である場合、この操作を使用して、 MSCS に DB2 が活動状態であることを単に通知することができます。 この操作中にエラーが起きると、Windows NT 事象ログに書き込まれます。

オフライン
この操作は、db2stop コマンドの使用と同じです。 インスタンスに活動状態の接続がある場合、この操作は失敗します。 これは db2stop の動作と一貫します。

リソースの失敗
この操作は、force オプションを指定した db2stop コマンドの使用と同じです。 DB2 はすべてのアプリケーションを DB2 システムから切断し、 すべてのデータベース・サーバーを停止します。

スクリプトの実行

スクリプトは、DB2 リソースがオンラインになった前でも、後でも実行できます。 これらのスクリプトは、DB2INSTPROF 環境変数に指定される、 インスタンス・プロファイル・ディレクトリーの中になければなりません。 このディレクトリーは、 db2icrt コマンドの -p パラメーターによって指定されるディレクトリー・パスです。 次のコマンドを発行して、この値を得ることができます。

   db2set -i:instance_name DB2INSTPROF

このファイル・パスは、 インスタンス・ディレクトリーがすべてのクラスター・ノードで使用可能になるように、 クラスター化ディスク上になければなりません。

これらのスクリプト・ファイルは必須ではなく、 インスタンス・ディレクトリーで検出される場合にのみ実行されます。 これらはバックグラウンドで MSCS クラスター・サービスによって立ち上げられます。 スクリプト・ファイルは、 スクリプト・ファイル内のコマンドから戻される情報を取り込むために標準出力をリダイレクトする必要があります。 出力は画面には表示されません。

区分データベース環境では、デフォルトで、 インスタンス中のすべてのデータベース区画サーバーが同じスクリプトを使用します。 インスタンス中の異なるデータベース区画サーバーを見分ける必要がある場合、 DB2NODE 環境変数の異なる割り当てをターゲット・ノード番号に使用してください (たとえば、 db2cpre.bat および db2cpost.bat ファイルで IF ステートメントを使用する)。

DB2 リソースをオンラインにする前にスクリプトを実行する

DB2 リソースをオンラインにする前に スクリプトを実行したい場合、 スクリプトの名前を db2cpre.batしなければなりません。 DB2 は Windows NT コマンド行プロセッサー (CLP) からこのバッチ・ファイルを立ち上げる関数を呼び出し、 DB2 リソースがオンラインになる前に CLP が実行を完了するのを待機します。 このバッチ・ファイルは、 DB2 データベース・マネージャー構成の修正などのタスクをこのバッチ・ファイルに使用することができます。 フェールオーバー・システムが無理である場合、 データベース・マネージャーのパラメーター値をいくつか変更する必要があるかもしれませんし、 DB2 が使用するシステム・リソースを削減することが必要です。

db2cpre.bat スクリプトに配置されたコマンドは、 同期で実行されるべきです。 そうしないと、DB2 リソースは、スクリプト中のすべてのタスクが完了する前にオンラインになり、 その結果予期しない動作が起きる場合があります。 特に、db2cmddb2cpre.bat スクリプトで呼び出すべきではありません。 これは、 DB2 コマンドを非同期に db2cmd プログラムに対して実行する他のコマンド・プロセッサーを代わりに立ち上げてしまうからです。

db2cpre.bat スクリプトで DB2 CLP コマンドを使用したい場合、 コマンドはファイル中に配置し、 DB2 コマンド行プロセッサー用に DB2 環境を初期化するプログラム内から CLP バッチ・ファイルとして実行する必要があり、 次に DB2 コマンド行プロセッサーの完了を待機します。 次に例を示します。

#include <windows.h>
 
int WINAPI DB2SetCLPEnv_api(DWORD pid);
 
void main ( int argc, char *argv [ ] )
{
      STARTUPINFO         startInfo   = {0};
      PROCESS_INFORMATION pidInfo     = {0};
      char     title  [32]   = "Run Synchronously";
      char     runCmd [64]  =
                             "DB2 -z c:\\run.out -tvf c:\\run.clp";
 
/* Invoke API to set up a CLP Environment */
      if ( DB2SetCLPEnv_api (GetCurrentProcessId ()) == 0 ) (1)
      {
         startInfo.cb          = sizeof(STARTUPINFO);
         startInfo.lpReserved  = NULL;
         startInfo.lpTitle     = title;
         startInfo.lpDesktop   = NULL;
         startInfo.dwX         = 0;
         startInfo.dwY         = 0;
         startInfo.dwXSize     = 0;
         startInfo.dwYSize     = 0;
         startInfo.dwFlags     = 0L;
         startInfo.wShowWindow = SW_HIDE;
         startInfo.lpReserved2 = NULL;
         startInfo.cbReserved2 = 0;
               if ( CreateProcessA( NULL,
                              runCmd, (2)
                              NULL,
                              NULL,
                              FALSE,
                              NORMAL_PRIORITY_CLASS CREATE_NEW_CONSOLE,
                              NULL,
                              NULL,
                              &startInfo,
                              &pidInfo ) )
         {
            WaitForSingleObject (pidInfo.hProcess, INFINITE);
            CloseHandle (pidInfo.hProcess);
            CloseHandle (pidInfo.hThread);
         }
      }
      return;
}

(1)
API DB2SetCLPEnv_api はインポート・ライブラリー DB2API.LIB によって解決されます。 この API は、呼び出される CLP コマンドを許可する環境を設定します。 このプログラムが db2cpre.bat スクリプトから呼び出される場合、 コマンド・プロセッサーは CLP コマンドの完了を待機します。

(2)
runCmd は DB2 CLP コマンドを含むスクリプト・ファイルの名前です。

db2clpex.exe という名前のサンプル・プログラムが、 DB2 インストール・パスの MISC サブディレクトリーに見つかることがあります。 この実行可能ファイルは提供される例に類似していますが、 DB2 CLP コマンドをコマンド行引き数として受け入れます。 このサンプル・プログラムを使用したい場合、 BIN サブディレクトリーにコピーしてください。 この実行可能ファイルは、 db2cpre.bat スクリプトで次のように使用できます (INSTHOME はインスタンス・ディレクトリー)。

  db2clpex "DB2 -Z INSTHOME\pre.log -tvf INSTHOME\pre.clp"

すべての DB2 ATTACH コマンドまたは CONNECT ステートメントは、 明示的にユーザーを指定する必要があります。 そうしないと、クラスター・サービスと関連するユーザー・アカウントのもとで実行されます。 CLP スクリプトはまた TERMINATE コマンドで完了して、 CLP バックグラウンド・プロセスを終了する必要があります。

以下に、db2cpre.bat ファイルの例を示します。

   db2cpre.bat : (1)
   ------------------------
   db2clpex "db2 -z INSTHOME\pre-%DB2NODE%.log -tvf INSTHOME\pre.clp" (2) - (5)
   ------------------------
 
   PRE.CLP (6)
   ------------------------
   update dbm cfg using MAXAGENTS 200;
   get dbm cfg;
   terminate;
   ------------------------

(1)
db2cpre.bat スクリプトは、 クラスター・サービスと関連するユーザー・アカウントの下で実行します。 DB2 処置が必要な場合、クラスター・サービスと関連するユーザー・アカウントは、 DB2 で定義されているように有効な SQL 識別子でなければなりません。

(2)
INSTHOME はインスタンス・ディレクトリーです。

(3)
ログ・ファイルの名前は、 両方の論理ノードが同時にオンラインになったときにファイルの競合を避けるため、 各ノードごとに異なっていなければなりません。

(4)
db2clpex.exe は、 コマンド行引き数を使用して、 呼び出す CLP コマンドを指定するサンプル・プログラムです。

(5)
db2clpex.exe サンプル・プログラムは、 すべての MSCS クラスター・ノードで使用可能にされなければなりません。

(6)
この例の CLP コマンドは、エージェントの数に制限を設定します。

DB2 リソースをオンラインにした後にスクリプトを実行する

DB2 リソースをオンラインにした後に スクリプトを実行したい場合、 スクリプトの名前を db2cpost.batしなければなりません。 スクリプトは、DB2 リソースが正常にオンラインになってから、 MSCS から非同期で実行されます。 db2cmd コマンドをこのスクリプトで使用し、 DB2 CLP スクリプト・ファイルを実行できます。 db2cmd コマンドの -c パラメーターを使用して、 ユーティリティーがタスクの完了時にすべてのウィンドウをクローズするように指定します。 次に例を示します。

   db2cmd -c db2 -tvf mycmds.clp

-c パラメーターは、 db2cmd コマンドに対する最初の引き数でなければなりません。 これにより、バックグラウンドのコマンド・プロセッサーを孤立しないようにできます。

db2cpost.bat スクリプトは、 DB2 リソースがフェールオーバーし、 活動状態になった直後にデータベース活動を実行したい場合に役立ちます。 たとえば、ユーザー・アクセス用にプライム状態になるように、 インスタンス中のデータベースを再始動または活動化することができます。

以下に、db2cpost.bat スクリプトの例を示します。

   db2cpost.bat (1)
   ------------------------
   db2cmd -c db2 -z INSTHOME\post-%DB2NODE%.log -tvf INSTHOME\post.clp (2) - (4)
   ------------------------
 
   POST.CLP (5)
   ------------------------
   restart database SAMPLE;
   connect reset;
   activate database SAMPLE;
   terminate;
   ------------------------

(1)
db2cpost.bat スクリプトは、 クラスター・サービスと関連するユーザー・アカウントの下で実行します。 DB2 処置が必要な場合、クラスター・サービスと関連するユーザー・アカウントは、 DB2 で定義されているように有効な SQL 識別子でなければなりません。

(2)
INSTHOME はインスタンス・ディレクトリーです。

(3)
ログ・ファイルの名前は、 両方の論理ノードが同時にオンラインになったときにファイルの競合を避けるため、 各ノードごとに異なっていなければなりません。

(4)
db2cmd コマンドを使用できます。 db2cpost.bat スクリプトが非同期に実行できるためです。 -c パラメーターを使用して、 コマンド・プロセッサーを終了する必要があります。

(5)
この例の CLP スクリプトには、 データベースを再始動および活動化させるコマンドが含まれています。 このスクリプトは、データベース・マネージャーの起動直後、 データベースを活動状態に戻します。 区分データベース・システムでは、 複数の DB2 リソースが同時にオンラインになるので、 ACTIVATE DATABASE コマンドを除去する必要があります。 RESTART DATABASE コマンドは、 別のノードがデータベースを活動化するために失敗することがあります。 これが起きた場合、スクリプトを再実行してデータベースが確実に、 正しく再始動するようにしてください。

データベースの考慮事項

データベースの作成時、 データベース・パスが共用ディスクを必ず参照するようにしてください。 これによって、データベースがすべての MSCS ノードで参照可能になります。 すべてのログと他のデータベース・ファイルも、DB2 が正常にフェールオーバーするように、 クラスター・ディスクを参照することが必要です。 これらのステップを実行しないと、ファイルが削除されたまたは使用不可能になった DB2 を参照するので、 DB2 システム障害が発生します。

また、データベース・マネージャーおよびデータベース構成パラメーターの設定が、 必ず DB2 の使用するシステム・リソース量がどの MSCS ノードでもサポートされるようにしてください。 autorestart データベース構成パラメーターは、 フェールオーバー上の最初のデータベース接続がデータベースを一貫した状態にするように、 ON に設定するべきです。 (autorestart の省略時設定は ON です。) また、 db2cpost.bat スクリプトを使用してデータベースを再始動および活動化することによっても、 データベースを作動可能状態にすることができます。 この方法をお勧めします。autorestart には従属関係がなく、 データベースはユーザー接続要求とは関係なく作動可能状態になるためです。

ユーザーおよびグループ・サポート

DB2 はユーザー認証およびグループ・サポートに関して、 Windows NT に依存しています。 DB2 インスタンスをシームレス (直接) に 1 つの MSCS ノードから別のノードにフェールオーバーするには、 各 MSCS ノードを同じ Windows NT セキュリティー・データベースにアクセスさせる必要があります。 これは、Windows NT ドメイン・セキュリティーを使用して達成できます。

すべての DB2 ユーザーとグループをドメイン・セキュリティー・データベースで定義してください。 MSCS ノードは、このドメインのメンバーでなければならないか、 またはドメインがトラステッド・ドメインであることが必要です。 その場合、DB2 はドメイン・セキュリティー・データベースを、 DB2 を実行しているノードに関係なく認証およびグループ・サポートに使用します。

ローカル・アカウントを使用している場合、 アカウントは各 MSCS ノードで複製される必要があります。 このアプローチは、エラーを起こしやすく、 二重のメンテナンスが必要なので、あまりお勧めできません。

すべての MSCS ノードが同じ DCE セルのクライアントである場合、 DCE セキュリティーもサポートされる認証モードです。

MSCS サービスを、DB2 命名規則に従うユーザー・アカウントと関連付ける必要があります。 これによって MSCS サービスは、DB2 に対して処置をとることができます。 このことは db2cpre.bat および db2cpost.bat スクリプトで必要になることがあります。

Windows NT ユーザーおよびグループ・サポートについての詳細は、 DB2 (Windows NT 版) での DB2 ユーザー認証 を参照してください。

通信に関する考慮事項

DB2 は、MSCS 環境で 2 つの LAN プロトコルをサポートします。

TCP/IP は、 クラスター・リソース・タイプであるためサポートされます。 DB2 が区分データベース・システムの通信プロトコルとして TCP/IP を使用できるようにするには、 IP アドレス・リソースを作成して、 リモート・アプリケーションに調整ノードとして使用したいデータベース区画サーバーを表す DB2 リソースとして同じグループに配置してください。 次に Cluster Administrator ツールを使用して従属関係を作成し、 DB2 リソースが開始される前に確実に IP リソースがオンラインになるようにします。 これで DB2 クライアントは TCP/IP ノード・ディレクトリー・エントリーをカタログ化し、 この TCP/IP アドレスを使用できます。

svcename データベース・マネージャー構成パラメーターと関連する TCP/IP ポートは、 インスタンスに参加するすべてのマシン上で DB2 インスタンスが使用するために予約しておく必要があります。 ポート番号と関連したサービス名も、 すべてのマシン上の services ファイルで同じでなければなりません。

NetBIOS はクラスター・リソースによってサポートされませんが、 NetBIOS を LAN プロトコルとして使用できます。 これはプロトコルが LAN 上で NetBIOS 名を確実に固有のものにするからです。 DB2 が NetBIOS 名を登録すると、NetBIOS は名前が LAN で使用されていないことを確かめます。 フェールオーバーのシナリオでは、DB2 がシステムからシステムへと移動されると、 DB2 が使用する nname は、 MSCS クラスターで 1 つのパートナー・マシンから登録解除され、別のマシンに登録されます。

DB2 NetBIOS サポートは NetBIOS Frames (NBF) を使用します。 このプロトコル・スタックは、 異なる論理アダプター番号 (LANA) と関連付けることができます。 サーバーに一貫した NetBIOS アクセスを保証するために、 NBF プロトコル・スタックと関連した LANA はすべてのクラスター・ノードで同じでなければなりません。 これは、「コントロール パネル」の 「ネットワーク」オプションを使用して構成できます。 NBF を LANA 0 と関連付けることは DB2 の省略時設定で予期されているので、 そうする必要があります。

システム時刻の考慮事項

DB2 はシステム時刻を使用して特定の操作にタイム・スタンプを付けます。 DB2 フェールオーバーに参加するすべての MSCS ノードには、システム時刻ゾーン、 および DB2 がすべてのマシンで一貫した動作をするように同期化されたシステム時刻が必要です。

「コントロール パネル」ダイアログの 「日付と時刻」オプションを使用してシステム時刻を設定します。 MSCS には、 MSCS ノードがクラスターを形式化するために結合する時に日時を同期化するタイム・サービスがあります。 しかし、タイム・サービスは単に 12 時間ごとに時刻を同期化するだけなので、 時刻が 1 つのシステム上で変更され、 時刻が同期化される前に DB2 がフェールオーバーする場合に問題が起きることがあります。

MSCS クラスター・ノードの 1 つで時刻が変更される場合、 次のコマンドを使用して他のクラスター・ノードで手作業で同期化されなければなりません。

   net time /set /y \\remote_node

remote_node には、クラスター・ノードのマシン名が入ります。

区分データベース環境の管理サーバーとコントロール・センターに関する考慮事項

DB2 管理サーバーは、 DB2 ユニバーサル・データベースのインストール中に (任意選択で) 作成されます。 これは区分データベース・システムではありません。 コントロール・センターは、管理サーバーが提供するサービスを使用して、 DB2 インスタンスおよびデータベースを管理します。

区分データベース・システムでは、 1 つの DB2 インスタンスが複数の MSCS ノードに常駐できます。 これは、どの MSCS ノードで DB2 インスタンスが活動状態になっているかに関係なく、 インスタンスがずっとアクセス可能になっているように、 コントロール・センターの下の複数のシステム上で DB2 インスタンスがカタログ化されなければならないということを暗示しています。

管理サーバーのインスタンス・ディレクトリーは共用ではありません。 管理サーバーのディレクトリーのすべてのユーザー定義のファイルを、 すべての MSCS ノードに対して二重化して、 すべての MSCS ノードに同じレベルの管理を提供しなければなりません。 特に、ユーザー・スクリプトおよびスケジュールされた実行可能ファイルを、 すべてのノードで使用可能にしなければなりません。 また、スケジュールされた活動を MSCS クラスターのすべてのマシン上でもスケジュールしなければなりません。

別の方法として、すべてのマシン上で管理サーバーを重複する代わりに、 管理サーバーをフェールオーバーさせることも可能です。 次の例の目的では、クラスター中に 2 つの MSCS ノードがあり、 MACH0 および MACH1 という名前だと仮定します。 MACH0 は、管理サーバーが使用するクラスター・ディスクにアクセスできます。 さらに、MACH0 および MACH1 両方に管理サーバーがあるとします。 以下のステップを実行して、管理サーバーを高度に使用可能にします。

  1. 各マシンで db2admin stop コマンドを呼び出し、 両方のマシンで管理サーバーを停止します。
  2. すべての管理クライアント・マシンで、 UNCATALOG NODE コマンドを使用し、 MACH0 および MACH1 で管理サーバーへのすべての参照のカタログ化を解除します。 (LIST NODE DIRECTORY コマンドをクライアント・マシン上で使用して、 管理サーバーへの参照が残っていないか判別できます。)
  3. MACH1 から db2admin drop コマンドを呼び出し、 MACH1 から管理サーバーを除去します。 (このステップは、両方のマシン上に管理サーバーがある場合にのみ実行します。)
  4. MACH0 から db2admin コマンドを発行し、 管理サーバーの名前を決定します。 (省略時の名前は DB2DAS00 です。)
  5. DB2MSCS ユーティリティーを使用して管理サーバーにフェールオーバー・サポートをセットアップします。 これには、IP およびディスク・リソースで従属関係を持つ DB2DAS00 という名前の MSCS で DB2 リソースを作成することが必要です。 (相互引き受け構成がある場合、 NODE0 のための DB2 リソースを保持するグループにリソースを入れます。) このリソースは、管理サーバーをサポートする MSCS リソースとして使用されます。 DB2MSCS.ADMIN ファイルは次のとおりです。

       #
       # db2mscs.admin for Administration Server
       # run db2mscs -f:db2mscs.admin
       #
       DB2_INSTANCE=DB2DAS00
       CLUSTER_NAME=CLUSTERA
       DB2_LOGON_USERNAME=db2admin
       DB2_LOGON_PASSWORD=db2admin
       # put Administration server in the same group as DB2 Node 0
       GROUP_NAME=DB2NODE0 (1)
       DISK_NAME=DISK E:
       INSTPROF_DISK=DISK E:
       IP_NAME= IP Address for Administration Server
       IP_ADDRESS=9.9.9.8
       IP_SUBNET=255.255.255.0
       IP_NETWORK=Ethernet
    

    (1)
    このグループは、既存のグループと同じものかもしれません。 このように、 インスタンス・プロファイル・ディレクトリーには付加的なディスクは必要ありません。
  6. MACH1 で、次のコマンドを呼び出し、DB2DAS00 を管理サーバーとして設定します。

       db2set -g db2adminserver=DB2DAS00
    
  7. MACH0 で、サービス・プログラムを介して DB2DAS00 の開始プロパティーを変更し、 自動でなく手作業で立ち上げることができるようにします。 これは、DB2DAS00 がこの時点で MSCS に制御されているためです。

管理サーバーがフェールオーバー用に使用可能になると、 すべてのリモート・アクセスは管理サーバーとの通信に MSCS IP リソースを使用しなければなりません。 管理サーバーは、これで次の特性を持つことになります。

制限と制約事項

MSCS 環境で DB2 を実行するには、次の制限があります。


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