MSCS クラスターを使用している場合、DB2 インスタンスには毎日の操作、データベースの展開、 およびデータベース構成に関係する付加的な計画を必要とします。 DB2 を MSCS ノードで透過的に実行するには、 付加的な管理用タスクを実行する必要があります。 すべての DB2 従属のオペレーティング・システム・リソースは、 すべての MSCS ノードで使用可能でなければなりません。 これらのオペレーティング・システムのいくつかは、MSCS の効力範囲外です。 つまり、MSCS リソースとして定義できません。 同じオペレーティング・システム・リソースがすべての MSCS ノードで使用可能であるように、 各システムを確実に構成することが必要です。 以下のセクションでは、行う必要がある付加的な作業を説明します。
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 インスタンスに適用します。
スクリプトは、DB2 リソースがオンラインになった前でも、後でも実行できます。 これらのスクリプトは、DB2INSTPROF 環境変数に指定される、 インスタンス・プロファイル・ディレクトリーの中になければなりません。 このディレクトリーは、 db2icrt コマンドの -p パラメーターによって指定されるディレクトリー・パスです。 次のコマンドを発行して、この値を得ることができます。
db2set -i:instance_name DB2INSTPROF
このファイル・パスは、 インスタンス・ディレクトリーがすべてのクラスター・ノードで使用可能になるように、 クラスター化ディスク上になければなりません。
これらのスクリプト・ファイルは必須ではなく、 インスタンス・ディレクトリーで検出される場合にのみ実行されます。 これらはバックグラウンドで MSCS クラスター・サービスによって立ち上げられます。 スクリプト・ファイルは、 スクリプト・ファイル内のコマンドから戻される情報を取り込むために標準出力をリダイレクトする必要があります。 出力は画面には表示されません。
区分データベース環境では、デフォルトで、 インスタンス中のすべてのデータベース区画サーバーが同じスクリプトを使用します。 インスタンス中の異なるデータベース区画サーバーを見分ける必要がある場合、 DB2NODE 環境変数の異なる割り当てをターゲット・ノード番号に使用してください (たとえば、 db2cpre.bat および db2cpost.bat ファイルで IF ステートメントを使用する)。
DB2 リソースをオンラインにする前に スクリプトを実行したい場合、 スクリプトの名前を db2cpre.bat にしなければなりません。 DB2 は Windows NT コマンド行プロセッサー (CLP) からこのバッチ・ファイルを立ち上げる関数を呼び出し、 DB2 リソースがオンラインになる前に CLP が実行を完了するのを待機します。 このバッチ・ファイルは、 DB2 データベース・マネージャー構成の修正などのタスクをこのバッチ・ファイルに使用することができます。 フェールオーバー・システムが無理である場合、 データベース・マネージャーのパラメーター値をいくつか変更する必要があるかもしれませんし、 DB2 が使用するシステム・リソースを削減することが必要です。
db2cpre.bat スクリプトに配置されたコマンドは、 同期で実行されるべきです。 そうしないと、DB2 リソースは、スクリプト中のすべてのタスクが完了する前にオンラインになり、 その結果予期しない動作が起きる場合があります。 特に、db2cmd を db2cpre.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; }
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; ------------------------
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; ------------------------
データベースの作成時、 データベース・パスが共用ディスクを必ず参照するようにしてください。 これによって、データベースがすべての 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 両方に管理サーバーがあるとします。 以下のステップを実行して、管理サーバーを高度に使用可能にします。
# # 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
db2set -g db2adminserver=DB2DAS00
管理サーバーがフェールオーバー用に使用可能になると、 すべてのリモート・アクセスは管理サーバーとの通信に MSCS IP リソースを使用しなければなりません。 管理サーバーは、これで次の特性を持つことになります。
MSCS 環境で DB2 を実行するには、次の制限があります。