Microsoft Cluster Server IBM DB2 Universal Database V8.1

Microsoft Cluster Serverを使用した
IBM DB2 Universal Database V8.1
Enterprise Server Editionの実装
2003 年 1 月
Aslam Nomani
DB2 UDB System Verification Test
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
1
© Copyright IBM Corp. 2003. All rights reserved.
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
2
商標
IBM、DB2、DB2 Universal Database は、IBM Corp.の米国またはその他の国 (あるいはそ
の両方) における商標または登録商標です。
Windows および Windows ベースの商標は、Microsoft Corp.の商標または登録商標です。
その他の会社名、製品名、またはサービス名は、それぞれ各社の商標またはサービス・マーク
です。
本書は IBM が所有する特許に対する使用許諾を意味するものではありません。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
3
目次
商標............................................................................................................................................... 3
概要............................................................................................................................................... 6
著者について ................................................................................................................................ 7
はじめに ....................................................................................................................................... 8
DB2 UDB ESE の概要................................................................................................................. 9
概念的な概要 .............................................................................................................................. 12
フェイルオーバーとフェイルバック.......................................................................................... 15
DB2MSCS ユーティリティー.................................................................................................... 17
ドライブ・マッピング................................................................................................................ 20
計画と準備.................................................................................................................................. 21
ホット・スタンバイの単一パーティション構成 ....................................................................... 22
相互テイクオーバーの単一パーティション構成 ....................................................................... 28
相互テイクオーバーの複数パーティション構成 ....................................................................... 33
DB2 管理サーバーの構成........................................................................................................... 36
リモート・クライアント接続..................................................................................................... 38
ユーザー・スクリプト................................................................................................................ 40
構成のテスト .............................................................................................................................. 41
ローリング・アップグレード..................................................................................................... 42
マシンの壊滅的破損後のクラスターの修復............................................................................... 43
セキュリティーの管理................................................................................................................ 45
DB2 の認証 ............................................................................................................................. 45
その他のサンプル構成................................................................................................................ 47
相互テイクオーバーのロード・バランシング構成 ................................................................ 47
複数のクラスター構成............................................................................................................ 50
付録 A – 制限および制約事項 ................................................................................................... 54
付録 B – よくある質問 .............................................................................................................. 55
付録 C – インスタンスのデクラスタリング.............................................................................. 58
DB2MSCS を使用してインスタンスをデクラスターする .................................................... 58
手動でインスタンスをデクラスタリングする ....................................................................... 58
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
4
付録 D – DB2MSCS ユーティリティーで実施されるステップを手動で実行する ................... 60
付録 E – サンプル・アプリケーション・プログラム ............................................................... 63
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
5
概要
IBM® DB2® Universal Database™ (UDB)は、業界初のマルチメディア対応かつ Web 対応のリ
レーショナル・データベース管理システムで、大企業の要望を十分に満たせるパワーと、小規
模から中規模の e-business にも対応できる柔軟性を兼ね備えています。DB2 UDB はビジネ
ス・インテリジェンス、コンテンツ管理、および e-business の統合パワーを、業界でも群を抜
くパフォーマンスと信頼性とともに提供します。この DB2 UDB を Microsoft® Cluster Server
(MSCS) と併用すると、高可用なコンピューティング環境が実現され、ソリューションが一段
と強化されます。
MSCS では、ハードウェアまたはソフトウェアの障害発生後、クラスター内の 1 つのシステム
から別のシステムへアプリケーションとデータをフェイルオーバーする作業を容易に自動化で
きます。
完全な高可用 (HA) セットアップは多くのパーツから成りますが、その 1 つが MSCS ソフト
ウェアです。優れた HA ソリューションには、プランニング、設計、カスタマイゼーション、
および変更管理が含まれます。HA ソリューションは障害発生ポイント (Single Point of
Failure: システム全体が停止する事態を招きかねない障害が発生し得る箇所) を排除すること
により、アプリケーションが使えない時間を短縮します。
この文書では、Microsoft Windows 2000® Advanced Server を用いた DB2 UDB Enterprise
Server Edition (ESE) V8.1 のサンプル構成を解説します。
本書は、MSCS や DB2 UDB の詳しい理解を図るために書かれたものではありません。DB2
UDB ESE を MSCS 環境へ統合する方法と、その環境における DB2 の構成方法について、理
解を促進することを意図したものです。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
6
著者について
Aslam Nomani 氏 IBM トロント研究所の IBM データベース技術チームの一員となって 6 年に
なります。その前の 5 年間は、DB2 UDB システム検証テスト部門に所属していました。現在
は高可用性ソリューションに重点的に取り組んでいます。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
7
はじめに
DB2 では、データベース・アプリケーションの正常な実行をコア・リソース・グループに依存
しています。これらのリソースの 1 つでも利用できなくなると、DB2 は完全には機能しなくな
ってしまいます。高可用 (HA) 環境では、必要なリソースを理解することと、リソースが継続
的にアプリケーションで利用できる状態にあることを保証するストラテジーの計画が重要です。
HA 環境ではクラスタリング・ソフトウェアが非常に有用です。クラスタリング・ソフトウェ
アは、全リソースが継続的にアプリケーションで利用できる状態であることを保証するメカニ
ズムを提供します。また、さらに一歩進めて、アプリケーションが連続可用状態であることも
保証します。
フェイルオバー機能を使用すると、ハードウェアに障害が発生した場合に、1 台のマシンから
別のマシンへワークロードを自動的に転送できます。Microsoft Cluster Server (MSCS) は、
複数マシン間のリソース・フェイルオーバー機能を備えています。対象となるリソースには、
ディスク、IP アドレス、ファイル共用、およびネットワーク名などがあります。DB2 はリソ
ース・タイプを追加作成する MSCS の機能を使用して、DB2 という名前のリソース・タイプ
を作成します。MSCS のグループ機能を使用してさまざまなリソースをまとめてグループ化す
ることにより、クラスター内のすべてのノード間を浮動できる仮想マシンが作成されます。し
たがって、グループ内のリソースのどれかに障害が発生すると、グループ (または仮想マシン)
全体がフェイルオーバーして別マシン上で再始動します。
図 1. マシン間を浮動する DB2 グループ
ヒント: HA 環境内では、どのシステムの信頼性も再弱リンク (ソフトウェア・アプリケーショ
ン、ディスク、ネットワーク、プロセッサーなど) と同程度であるため、管理者が障害発生ポ
イントを少しでも排除するよう努めることが重要です。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
8
DB2 UDB ESE の概要
DB2 UDB ESE は DB2 UDB のエディションで、これを用いると、ユーザーは単一パーティ
ションまたは複数パーティションのデータベース環境を構築できます。DB2 UDB ESE で使用
される極めてスケーラブルなシェアード・ナッシング・アーキテクチャーでは、ユーザーは複
数のデータベース・パーティション (物理的には異なるマシン上に存在できます) にわたって
データを分散させることができます。各パーティション上のデータは、複数のパーティション
にわたって、さらにはそれぞれのパーティション内でも、並列に処理されます。1 つのパーテ
ィションに障害が発生し、そのパーティションからデータを必要とする照会がある場合、その
照会は失敗します。DB2 では照会をパーティションのサブセットに対して発行できますが、そ
の照会はデータセット全体の結果を反映しないため、多くの環境に適した照会ではありません。
したがって、障害の起きたパーティションは、ユーザーがそのパーティション上のデータをア
クセスできるように、再始動の必要があります。
図 2. 複数パーティションと MSCS を用いた DB2 UDB ESE の典型的トポロジー
注意：
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
9
•
単一パーティション環境では、
「データベース・パーティション 1」は図 2 に存在しません。
•
両方のデータベース・パーティションが同じディスク・サブシステムに接続されていたと
しても、各パーティションはそれ自体が所有するデータをアクセスするだけです。
•
DB2 UDB では MSCS を使用して、障害発生時にデータベース・パーティションをフェイ
ルオーバーできます。これにより、すべてのパーティションは高可用になり、全データが
使えるようになります。
MSCS 環境において DB2 UDB ESE が機能する様子を示すために、図 2 の構成によく似た 2
つのパーティションで構成される DB2 インスタンスの簡単な例を挙げて説明します。単一パー
ティションの ESE インスタンスでは、パーティション 1 だけが db2nodes.cfg ファイルに存
在します。
•
マシン A では、まずパーティション 0 がアクティブです。パーティション 0 用のデータが
ディスク E 上の共用ディスク・サブシステムに保管されるとします。
•
マシン B では、まずパーティション 1 がアクティブです。パーティション 1 用のデータが
ディスク F 上の共用ディスク・サブシステムに保管されるとします。
最初は db2nodes.cfg
は次のとおりです。
0 macha macha 0 10.1.1.5
1 machb machb 0 10.1.1.6
注 意 ： db2nodes.cfg フ ァ イ ル に は DB2 パ ー テ ィ シ ョ ン 情 報 を 保 管 し ま す 。
db2nodes.cfg ファイルの詳細については、DB2 のマニュアルを参照してください。単
一パーティション・インスタンスについては、db2nodes.cfg の 4 番目のフィールドの
IP アドレスは不要です。
•
マシン B に障害が発生すると、パーティション 1、ディスク F、および TCP/IP アドレス
10.1.1.6 はマシン A にフェイルオーバーし、パーティション 0 と 1 がマシン A 上でアクテ
ィブになります。パーティション 0 は依然としてディスク E 上のデータをアクセスし、同
様にパーティション 1 はディスク F 上のデータをアクセスします。DB2 はパーティション
情報を保管する構成ファイル [db2nodes.cfg] で、パーティション 1 に関連付けられた
ホスト名とコンピューター名を自動的に更新します。db2nodes.cfg ファイルは次のよう
になります。
0 macha macha 0 10.1.1.5
1 macha macha 1 10.1.1.6
注意： パーティション 1 のホスト名とコンピューター名は DB2 によって自動的に macha
に変更されています。また、DB2 は競合を避けるために、パーティション 1 に関連付けら
れるポート番号も変更しました。TCP/IP アドレスは、DB2 パーティションと一緒に移動
する高可用アドレスであるため、変更しません。
•
db2nodes.cfg ファイルなどのインスタンス情報は、高可用のネットワーク名、ファイル
共用、およびディスクに保管されます。これらリソースを持つマシンに障害が発生すると、
リソースは別のマシンにフェイルオーバーして、引き続き DB2 に対して利用可能になりま
す。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
10
•
リモート・クライアントがパーティション 0 に接続されていた場合、障害発生時に未コミ
ット状態のトランザクションがあれば、再発行する必要があります。障害のあったパーテ
ィションからの情報を未コミット・トランザクションが必要としなかった場合、トランザ
クションの再発行は必要ありません。
•
リモート・クライアントがパーティション 1 に接続されていた場合、再びデータベースに
接続されない限り、照会を実行できません。リモート・クライアントは障害発生前と同じ
高可用 TCP/IP アドレスに再接続するので、パーティション 1 が別マシンへ移動したこと
には気付きません。
注意： DB2 クライアントのデフォルト動作では、ポート 0 を持つパーティションへ接続
します。したがって、パーティション 1 への接続は、実際には前のフェイルオーバーが発
生した後のパーティション 0 への接続です。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
11
概念的な概要
MSCS 環境では複数のマシンが同一ディスク・リソースの所有権を持つことができるので、こ
のディスクには、クラスター内の全マシンから共用直接アクセスできなければなりません。ク
ラスターは、クラスター内のどのノードが利用可能であるか判別するために、ノード間のハー
トビートも維持します。ハートビート通信は通常は内部プライベート・ネットワークを介して
流れます。一方、リモート・クライアントはパブリック・ネットワーク経由でクラスターをア
クセスします。したがって、典型的なクラスター・トポロジーは、次のようになります。
図 3. 典型的なクラスター構成
MSCS を正常にインストールすると、Cluster Administrator (MSCS に含まれるグラフィカル
管理ツール) は、クラスター内のマシン、リソース、リソース・タイプ、グループ、およびク
ラスターで使用可能なネットワークを表示します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
12
図 4. MSCS の初期導入後の Cluster Administrator
図 4 の画面ショットは、2 ノードの MSCS 構成に MSCS がインストールされた直後の、クラ
スターの初期スナップショットです。Windows Datacenter はクラスター内の 4 ノードをサポ
ートする一方、Windows NT Enterprise Edition および Windows 2000 Advanced Server はク
ラスター内の最大で 2 ノードしかサポートしないことに注意してください。Windows .NET は
最大 8 ノードまでサポートします。1 つの DB2 UDB ESE インスタンスが 1 つのクラスターで
利用可能な数を超えるノードに広がる場合、複数のクラスターを使用できます。図 4 に示すク
ラスターは、本書を通して使用する例題の出発点として使用します。このクラスターについて
の特記すべき情報のいくつかを次に示します。
•
クラスターの名前は MYCLUSTER。
•
クラスター内の 2 台のマシンは、WA9 と WA10。
•
クラスター・グループ 1 つと、Disk Group1∼5 とラベル付けされた他の 5 つのグループが
存在する。
•
各ディスク・グループは 1 つの物理ディスク・リソースを含む。
•
2 つのネットワークが存在し、それぞれ「Private Network」および「Public Network」と
いう名前が付いている。
•
現在、マシン WA10 上では、全ディスク・グループとともにクラスター・グループがアク
ティブである。
ヒント: MSCS 環境における DB2 の構成を進める前に、MSCS 構成内の全グループがクラスタ
ー内の全マシン間で正常にフェイルオーバーできることを確認します。
クラスターで利用可能な、デフォルトで提供されるリソース・タイプの中には、DB2 パーティ
ションに対応するリソース・タイプがありません。そこで、DB2 UDB は DB2 というリソース・
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
13
タイプを作成します。DB2 タイプのリソースは、それぞれ 1 つの DB2 パーティションに対応
します。これで DB2 は MSCS でモニター可能なリソース・タイプを持って MSCS 環境に統合
されるので、MSCS は、DB2 が DB2 で必要とするすべてのリソースと共にオンライン状態で
あることを確証できます。
DB2 リソース・タイプは、DB2MSCS ユーティリティーの実行時に自動的に作成されます。
DB2MSCS ユーティリティーについては、後述のセクションで説明します。
各 DB2 パーティションには、内部通信用の IP アドレス(複数パーティションのインスタンス使
用時)、およびリモート接続を許容する IP アドレス (オプション) といった情報を保管するディ
スクが必要なので、DB2 は MSCS 内のグループ機能を使用して、複数のリソースを 2 つの論
理エンティティーにグループ化します。DB2 リソース、ディスク、および TCP/IP アドレスの
組み合わせは、DB2 ESE インスタンスの正常実行に必要なほぼすべてのリソースです。DB2
ESE インスタンスはまた、高可用ネットワーク名およびファイル共用を使用して、全パーティ
ションで利用可能なインスタンス情報を保管します。必要とされるその他のリソースは、プロ
セッサーとメモリーです。この最後の 2 つのリソースは、グループが現在アクティブなマシン
から取得され、マシン間でのフェイルオーバーはありません。
単一パーティションまたはパーティション・グループは、単一の MSCS グループの中に含める
ことができます。パーティションが同一グループにある場合、それらは常に同時に同一マシン
上に存在します。同時に異なるマシン上に異なるパーティションを持つことが望まれる場合、
パーティションは異なる MSCS グループの中に配置される必要があります。
すでに述べたとおり、DB2 パーティションを持つ各 MSCS グループは、1 つ以上の DB2 リソ
ース、ディスク、および IP アドレスを含みます。インスタンス所有パーティションを含むグル
ープは、ESE インスタンス全体の構成情報を保管するために、ネットワーク名とファイル共用
も含みます。インスタンス所有パーティションは、常にパーティション 0 です。これらリソー
スがオンラインになる順序は、グループがオンラインにされるときは重要です。DB2 リソース
が最初に始動すると、たとえば、まだオンラインになっていないディスク上のファイルへのア
クセスをパーティションが必要とするため、障害が発生することもあります。したがって、
MSCS の従属性機能が利用されます。従属性機能を使用すると、あるリソースの始動に先立っ
て完全に始動しておくべき他のリソースを定義できます。DB2 リソースは、ディスクと同時に、
IP アドレスにも (さらには DB2 リソースがインスタンス所有パーティションに対応する場合
には、ネットワーク名およびファイル共用にも) 従属するように自動的に構成されます。この
従属性は、プロセスの停止にも適用されます。MSCS は、ディスクや IP アドレス (および、
DB2 リソースがインスタンス所有パーティションに対応する場合にはネットワーク名および
ファイル共用) がオフラインにされる前に、DB2 リソースが完全に停止されることを保証しま
す。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
14
フェイルオーバーとフェイルバック
MSCS は、リソースとグループが現在のマシン上で再始動されるのか、あるいはクラスター内
の別マシンへフェイルオーバーすべきなのかを決定します。どのリソースが始動済みであるか
をクラスターが認識することは、オンライン状態を保つべきリソースを知るためにも、非常に
重要です。Cluster Administrator を使用してリソースまたはグループをオンラインにする場合、
MSCS はそれらリソースが始動済みであると認識し、障害が発生した場合に利用可能状態にあ
ることを確認しようとします。DB2 が非クラスター・インターフェース (DB2START、NET
START、あるいは Service Manager からの自動スタート) を使用して始動された場合、MSCS
は DB2 パーティションが始動済みであることを認識せず、DB2 パーティションの稼動状態を
保つ試みは一切しません。
MSCS は、Cluster Administrator を使用してオンラインにされたすべてのリソースおよびグ
ループをモニターします。クラスター内のマシンに障害が発生すると、MSCS は全リソースお
よびグループを別のクラスター・マシンへ移動し、オンラインであったリソースがすべて再び
オンラインに戻されることを保証します。リソースに障害が起きると、MSCS はそのリソース
を、まず現在のマシン上でオンラインに戻そうと試みます。しかし、これにも失敗すると、そ
のリソースに関連付けられたグループ全体を別のクラスター・マシンに移動し、そこでオンラ
インに戻そうとします。リソースをオンラインに戻すための MSCS の再試行回数は、Cluster
Administrator 内で構成できます。グループのフェイルオーバー先に関するマシン・プリファ
レンスも、Cluster Administrator 内で構成できます。DB2 リソースの障害は、DB2 内の例外
のため、あるいはオペレーティング・システム・リソースが不足したために発生します。DB2
の障害検知機能は DB2 プロセスの終了によってトリガーされるため、ハングしたことで DB2
リソースの再始動が自動的にトリガーされることはありません。
マシンの障害またはその他の原因でフェイルオーバーが発生した場合、データベース・パーテ
ィションはトランザクション的に一貫性のない状態に陥ることがあります。そのため、無事だ
ったマシンでデータベース・パーティションを始動する際に、クラッシュ・リカバリー・フェ
ーズを実行する必要があります。このフェーズでは、他のパーティションへの迂回的なリカバ
リーを起動して、データベースをトランザクション的に一貫した状態に戻します。データ保全
性とトランザクションの一貫性を維持するために、データベースはクラッシュ・リカバリーが
完了するまでは完全には利用可能にはなりません。
相互テイクオーバー環境では、ある一時点で 1 台のマシン上ですべての MSCS グループがオン
ラインになる場合に、潜在的なマシン要件が最高になるように計画することが非常に重要です。
マシンがその負荷を処理できなければ、パフォーマンス低下から異常終了まで、予期せぬ結果
を招くことになります。
フェイルバックとは、クラスター内でマシンがオンラインに戻った場合に、MSCS グループが
優先マシンへ戻る機能です。「フォールバック」という用語も、フェイルバックを指して一般
的に使用されます。フェイルバックには、現在のマシンでグループをオフラインにし、グルー
プをその優先マシンへ移動して、そこでグループをオンラインに戻すという作業が含まれます。
自動フェイルバックの欠点の 1 つは、DB2 パーティションを含むグループがオフラインにされ
るたびに、データベース接続のいくつかが強制的にデータベースから解除されることです。
MSCS は Cluster Administrator 内の構成に基づいて、フェイルバックを進めます (デフォル
トではフェイルバックしなません)。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
15
DB2 バージョン 8 のデフォルト動作では、フェイルバックを許容します。自動フェイルバック
が望ましい場合、デフォルトの動作がフェイルバックを許容するようにクラスターを構成しま
す。DB2 のデフォルト動作を変更して、フェイルバックを許容しないようにするには、
DB2_FALLBACK DB2 プロファイル変数を調整します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
16
DB2MSCS ユーティリティー
DB2MSCS ユーティリティーはスタンドアロンのコマンド行ユーティリティーで、非 HA イン
スタンスを HA インスタンスに変換するために使用されます。このユーティリティーは、すべ
ての MSCS グループ、リソース、およびリソース従属関係を作成します。また、Windows レ
ジストリーに保管されたすべての DB2 情報をレジストリーのクラスター部分にコピーすると
同時に、インスタンス・ディレクトリーを共用クラスター・ディスクに移動します。DB2MSCS
ユーティリティーは、ユーザーがクラスターのセットアップ方法を指定した構成ファイルを入
力としてとります。DB2MSCS ユーティリティーはインスタンス所有パーティションから実行
する必要があります。DB2 ESE 用に使用される構成ファイル中のフィールドは、次のとおり
です。
DB2_INSTANCE：DB2 インスタンスの名前。インスタンス名の指定がない場合、デフォルト・
インスタンス (DB2INSTANCE 環境変数で指定された値) が使用されます。このパラメーター
はグローバル・スコープを持ち、DB2MSCS.CFG ファイル中で 1 回だけ指定される必要があり
ます。
DAS_INSTANCE：DB2 管理サーバー・インスタンスの名前。このパラメーターはグローバル・
スコープを持ち、DB2MSCS.CFG ファイルで 1 回だけ指定される必要があります。このパラメ
ーターは、DB2_INSTANCE と一緒には使用できません。
CLUSTER_NAME：MSCS クラスターの名前。この行の後に指定されるすべての行は、別の
CLUSTER_NAME パラメーターが指定されるまで、このクラスター内で使用されます。
DB2_LOGON_USERNAME ： DB2 サ ー ビ ス の ド メ イ ン ・ ア カ ウ ン ト の ユ ー ザ ー 名
(domain¥user など)。このパラメーターはグローバル・スコープを持ち、DB2MSCS.CFG ファ
イル中で 1 回だけ指定される必要があります。
DB2_LOGON_PASSWORD：DB2 サービスのドメイン・アカウントのパスワード。このパラ
メーターはグローバル・スコープを持ち、DB2MSCS.CFG ファイル中で 1 回だけ指定される必
要があります。
GROUP_NAME：MSCS グループの名前。このパラメーターが指定された場合、MSCS グル
ープが存在しなければ新たに作成されます。グループがすでに存在する場合、それがターゲッ
ト・グループとして使用されます。このパラメーターの後に指定される MSCS リソースは、別
の GROUP_NAME パラメーターが指定されるまでは、このグループ内に作成されるか、この
グループに移動されます。このパラメーターは、グループごとに 1 回指定します。
DB2_NODE：現在の MSCS グループに含められるデータベース・パーティション・サーバー
(またはノード) のノード数。同一マシン上に複数の論理ノードが存在する場合、各ノードに
別々の DB2_NODE パラメーターが必要です。DB2 リソースが正しい MSCS グループに作成
されるように、GROUP_NAME パラメーターの後にこのパラメーターを指定します。
このキーワードの値は、パーティション間通信に DB2 で使うネットワーク名 (または IP アド
レス) をオプションで含むことができます。MSCS 環境で稼動する場合、通常はプライベート・
ネットワークとパブリック・ネットワークという 2 つのネットワークがあります。プライベー
ト・ネットワークは、DB2 インスタンスの複数のパーティション間でのデータ転送に使用でき、
一方パブリック・ネットワークはリモート・クライアント接続に使用されます。DB2 がパーテ
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
17
ィション間通信に常にプライベート・ネットワークを使うことを保証するために、プライベー
ト・ネットワークに関連付けられた高可用ネットワーク名 (または IP アドレス) を、次のよう
に明示的に指定できます。
DB2_NODE = <node_number> <network_name>
IP_NAME：IP アドレス・リソースの名前。IP_NAME の値は任意ですが、クラスター内で固
有でなければなりません。このパラメーターが指定された場合、タイプが IP アドレスの MSCS
リソースが作成されます。リモート TCP/IP 接続には、このパラメーターが必要です。単一パ
ーティション環境では、このパラメーターはオプションです。当該 IP アドレスに対応するホス
ト名が推奨されます。
IP_ADDRESS：先行する IP_NAME パラメーターで指定された IP リソースの TCP/IP アドレ
ス。IP_NAME パラメーターが指定される場合は、このパラメーターも必要です。このアドレ
スは、ネットワーク内のどのマシンでも使われていない新規 IP アドレスです。
IP_SUBNET：先行する IP_NAME パラメーターで指定された IP リソースの TCP/IP サブネ
ット・マスク。IP_NAME パラメーターが指定された場合、このパラメーターは必須です。
IP_NETWORK：先行する IP アドレス・リソースが属す MSCS ネットワークの名前。このパ
ラメーターはオプションです。指定のない場合、システムで最初に検知された MSCS ネットワ
ークが使用されます。MSCS ネットワークの名前は、Cluster Administrator の「Networks」
の枝の下に表示されているとおりに正確に入力する必要があります。
注意：以上の 4 つの IP キーワードは、IP アドレス・リソースの作成に使用されます。
NETNAME_NAME：ネットワーク名リソースの名前。ネットワーク名リソースを作成するに
は、このパラメーターを指定します。インスタンスを所有するマシンには、このパラメーター
の指定が必須です。
NETNAME_VALUE：ネットワーク名リソースの値。NETNAME_NAME パラメーターが指
定される場合には、このパラメーターの指定も必須です。
NETNAME_DEPENDENCY：ネットワーク名リソースが従属する IP リソースの名前。各ネ
ットワーク名リソースは、IP アドレス・リソースに従属する必要があります。このパラメータ
ーはオプションです。指定されない場合、ネットワーク名リソースは、グループ内の最初の IP
リソースに従属します。
DISK_NAME：現在のグループに移される物理ディスク・リソースの名前。ディスク・リソー
スを必要なだけ指定します。ディスク・リソースは既存のものでなければなりません。
DB2MSCS ユーティリティーが DB2 インスタンスをフェイルオーバー・サポート用に構成す
る場合、インスタンス・ディレクトリーはグループ内の最初の MSCS ディスクにコピーされま
す 。 イ ン ス タ ン ス ・ デ ィ レ ク ト リ ー 用 に 異 な る MSCS デ ィ ス ク を 指 定 す る に は 、
INSTPROF_DISK パ ラ メ ー タ ー を 使 用 し ま す 。 使 用 さ れ る デ ィ ス ク 名 は 、 Cluster
Administrator に表示されているとおりに正確に入力する必要があります。
INSTPROF_DISK：DB2 インスタンス・ディレクトリーを含む MSCS ディスクを指定するオ
プション・パラメーター。このパラメーターが指定されない場合、DB2MSCS ユーティリティ
ーは同じグループに属する最初のディスクを使用します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
18
INSTPROF_PATH：DB2 インスタンス・ディレクトリーを含む MSCS ディスクのパスを指定
する代替方法。DB2MSCS ユーティリティーがディスク・リソースのドライブ文字を取得でき
ない場合に、このパラメーターを使用します。
TARGET_DRVMAP_DISK：データベース・ドライブ・マッピングのターゲット MSCS ディ
スクを指定するオプション・パラメーター。このパラメーターは、create database コマンドで
指定するドライブからのマッピングによって、データベースが作成される先のディスクを指定
します。このパラメーターの指定がない場合、データベース・ドライブ・マッピングは、
DB2DRVMP ユーティリティーを使用して手作業で登録される必要があります。
DB2_FALLBACK：DB2 リソースがオフラインにされるときに、アプリケーションも強制的に
オフにすべきかどうかを制御するオプション・パラメーター。アプリケーションを強制的にオ
フにしたくない場合、DB2_FALLBACK=NO に設定します。DB2_FALLBACK のデフォルト
値は YES です。
SERVICE_DISPLAY_NAME：汎用サービス・リソースの表示名。このパラメーターは汎用サ
ービス・リソースを作成するために指定します。
SERVICE_NAME：汎用サービス・リソースのサービス名。SERVICE_DISPLAY_NAME パ
ラメーターが指定される場合は、このパラメーターの指定は必須です。
SERVICE_STARTUP：汎用サービス・リソースの始動パラメーター (オプション)。
本書で使用する例題の構成ファイルを、後続のセクションで示します。
ヒント：IP_ADDRESS に使われる IP アドレスが、ネットワーク上のどのマシンでもまだ使用
されていない新しい IP アドレスであることを確認してください。また、DISK_NAME および
IP_NETWORK に使われるすべての値が、Cluster Administrator で表示されているとおりに
正確に入力されることを確認してください。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
19
ドライブ・マッピング
ドライブ・マッピングは、DB2 データベースを複数パーティション・インスタンスにわたって
実装するにあたり、パーティションが複数の MSCS グループに位置する場合に、必須ステップ
です。DB2 の create database コマンドには、データベースを作成する先のドライブ指定
が必要で、指定されない場合はデフォルト値が使用されます。ディスク E にデータベースを作
成する場合、そのディスク・ドライブは全パーティションで使用できなければなりません。パ
ーティションが複数グループにわたって広がる場合、同じドライブ文字を持つ共用ディスク・
ドライブが複数グループ内に存在することは不可能です。
図 5 の例に基づき、パーティション 0 を持つグループがディスク E を所有し、パーティション
1 を持つグループがディスク F を所有する場合、ドライブ文字が同じで両パーティションで使
用できる共用ドライブはありません。この問題を緩和するために、DB2 は create database
コマンドに使用されるドライブ・マッピング方式を実装しました。この例では、ディスク E を
パーティション 1 上のディスク F にマッピングできます。次に、ディスク E で create
database コマンドを発行すると、パーティション 0 のデータはディスク E 上に作成され、パ
ーティション 1 のデータはディスク F 上に作成されます。代替方法として、ディスク F にデー
タベースを作成して、パーティション 0 でディスク F をディスク E にマッピングすることもで
きます。ドライブ・マッピングは、DB2MSCS 入力ファイルで TARGET_DRVMAP_DISK キ
ーワードが指定されている場合に、自動的に実行されます。また、db2drvmp コマンドを使用
して手動で実行することもできます。
図 5. DB2 ドライブ・マッピング
注意：図 5 では、create database コマンドはパーティション 0 とパーティション 1 のどち
らからでも発行できます。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
20
計画と準備
ESE 高可用環境の計画の最初のステップは、ホスト・スタンバイ構成が必要なのか、相互テイ
クオーバーが必要なのか、それともその両方の組み合わせなのかを決めることです。次に、ESE
インスタンスの要件に基づいて、
MSCS クラスター構成を定義する必要があります。たとえば、
本書で説明するホット・スタンバイ構成では、ホット・スペアーとして使用される 1 台のマシ
ンで 2 ノードの MSCS クラスターが使用されました。
次のステップは、複数のパーティションが常に一緒にフェイルオーバーするかどうかを決めま
す。複数パーティションが一緒にフェイルオーバーする場合、それらパーティションは同一
MSCS グループに配置される必要があります。本書の目的に則して、1 つ以上のパーティショ
ンを含む MSCS グループを、どれも DB2 グループと呼ぶことにします。同じ DB2 グループに
位置するパーティションは、ディスク・リソースも TCP/IP リソースも共用できます。各 DB2
グループの優先マシン所有者は、DB2 グループのフェイルオーバー・プリファレンスと一緒に
決定される必要があります。次に、使用する環境において、自動フェイルバックが必要かどう
かを決定します。
各 DB2 グループには、同じ DB2 グループ内のパーティション用に情報を保管するために、1
つ以上の MSCS ディスク・リソースが必要です。データベース要件を満たすために必要とされ
る十分なディスク・リソースを割り振ります。
複数グループに存在する複数パーティション・インスタンスについては、各 DB2 グループはプ
ライベート・ネットワーク上に MSCS TCP/IP リソースを 1 つ持つ必要があります。この
TCP/IP リソースは、内部通信に使用すべきネットワークを DB2 に知らせるために使用されま
す。
オプションで、パブリック・ネットワークで定義された MSCS TCP/IP リソースを 1 つ以上の
DB2 グループが必要とする場合もあります。この TCP/IP リソースは、リモート・クライアン
トが同一 DB2 グループ内のパーティションに直接接続する場合に使用されます。着信クライア
ント要求を受け入れるために使用されるパーティションだけが、この TCP/IP リソースを必要
とします。複数のパーティションに着信要求を受け入れさせることの利点の 1 つは、複数のパ
ーティションにわたるワークロードの平衡化に役立つことです。
注意：MSCS 環境において DB2 で使用するために定義されたすべての TCP/IP リソースにつ
いては、静的 IP アドレスであることが重要です。すべての TCP/IP リソースは、使用するドメ
イン・ネーム・サーバーに登録されるか、クラスター内の各マシン上のホスト・ファイル中に
存在する必要があります。
各 DB2 インスタンスについて、一時点に任意の 1 台のマシンに存在できる DB2 パーティショ
ンの最大数を決定します。DB2 環境変数 DB2_NUM_FAILOVER_NODES を、1 台のマシン
上に存在できる最大パーティション数よりも 1 だけ少ない数に設定します。デフォルト値は 2
で、必ずしもこの値をデフォルトよりも小さく設定する必要はありません。たとえば、1 台の
マシン上に 4 つのパーティションが存在する可能性がある場合、次のようなコマンドを発行し
ます。
db2set DB2_NUM_FAILOVER_NODES=3
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
21
ホット・スタンバイの単一パーティション構成
ホット・スタンバイ構成では、
MSCS クラスター内の 1 台以上のマシンがアイドル状態であり、
障害発生時のバックアップとして待機します。スタンバイ・マシンは、構成によって、1 つ以
上のデータベース・パーティションのバックアップとして動作できます。図 6 では、パーティ
ション 0 は 1 台のマシン上でアクティブであり、そのマシンには、障害が起きた場合に使用で
きる 1 台のホット・スペアーが用意されています。
図 6. ホット・スタンバイ構成
次の例で、DB2 単一パーティション・インスタンスを使用したホット・スタンバイ構成のセッ
トアップに必要なステップを詳しく説明します。DB2MSCS ユーティリティーは、クラスター
内の各マシンに対してローカルな管理者権限を持つドメイン・ユーザーから実行される必要が
あります。
クラスター内の各マシンに DB2 UDB がインストールされた後、
各マシンをリブートしてから、
DB2MSCS 構成に進みます。
1.
MSCS クラスターを構成し、それが正常であることを確認します。
2.
DB2 UDB ESE をクラスター内のそれぞれのマシンにインストールし、そこで単一パーテ
ィション・インスタンスを構成できるようにします。DB2 はローカル・ディスクにインス
トールする必要があります。(ステップ 1 と 2 は、必要であれば逆順に実施することもでき
ます。) インストールによって、各マシン上に DB2 というインスタンスが作成されます。
2 台目のマシン (WA10) はホット・スタンバイ・マシンなので、このノード上の DB2 イ
ンスタンスは、次の db2idrop コマンドを使用して除去される必要があります。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
22
C:¥>db2idrop db2
sqllib ディレクトリーは各マシンにローカルに存在するので、ストアード・プロシージャ
ーやスクリプトなどのプログラムはすべて、適切なパスにある各クラスター・マシンに存
在することを確認してください。パス名を指定できるすべてのプログラムについては、そ
のプログラムをインスタンス・ディレクトリーに配置して、プログラム・コピーが 1 つだ
け必要になるようにします。
注意：インストールで作成されたインスタンス DB2 には、パーティション間通信用に 4
つのポートがサービス・ファイル中で予約されます。これらポートがクラスター内の全マ
シンで利用できることを確認します。また、DB2 インスタンスはドメイン・アカウントの
下で稼動することが推奨されます。
DB2STOP コマンドを使用して、インスタンスを 1 次マシン (WA9) で確実に停止します。
インスタンス DB2 は HA インスタンスの構成に使われます。入力構成ファイルは、
DB2MSCS ユーティリティーで使用するように構成される必要があります。インスタンス
をトランスフォームして HA インスタンスにする前に、DB2 がインストールされたローカ
ル・ドライブ上に現在インスタンス・ディレクトリーが保管されていることに注意してく
ださい。
C:>db2set db2instprof
C:¥SQLLIB
DB2MSCS ユーティリティーの入力構成ファイルは、次のようになります。
DB2_INSTANCE=DB2
CLUSTER_NAME=MYCLUSTER
DB2_LOGON_USERNAME=mydom¥db2admin
DB2_LOGON_PASSWORD=xxx
GROUP_NAME=DB2 Group 0
DB2_NODE=0
IP_NAME=mscs11
IP_ADDRESS= 9.26.75.25
IP_SUBNET=255.255.255.0
IP_NETWORK=Public Network
IP_NAME=ether0
IP_ADDRESS=10.1.1.1
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
NETNAME_NAME=mynetname
NETNAME_VALUE=mynetname
NETNAME_DEPENDENCY=ether0
DISK_NAME=Disk F:
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
23
DB2MSCS ユーティリティーを実行するには、ファイル名に-f オプションを指定し、コマ
ンドが正常終了することを確認します。
C:¥>db2mscs -f:db2mscs.cfg.db2
DB21500I The DB2MSCS command completed successfully.
注意：DB2MSCS 入力ファイル内の NETNAME_DEPENDENCY は、プライベート・ネ
ットワークで定義された TCP/IP アドレスを使用するように構成されます。
ヒント：高可用 (HA) クラスター・インスタンスにトランスフォームする前に、インスタ
ンス内の既存の全データベースをバックアップしてください。
DB2MSCS ユーティリティーを実行すると、インスタンス DB2 を MYCLUSTER 内に常
駐するクラスター・インスタンスにトランスフォームします。「DB2 Group 0」が作成さ
れ、これにはパーティションが 1 つと、新規 IP アドレス 2 つ、そしてディスク・リソー
スが 1 つ含まれます。インスタンス所有パーティションも含むので、「DB2 Group 0」に
はネットワーク名とファイル共用も含みます。インスタンス・ディレクトリーは「DB2
Group 0」内の新しいファイル共用に移動されます。ここで db2ilist コマンドを実行す
ると、インスタンス名の後に C:<cluster name>が表示され、インスタンスがクラスタ
リングされていることを示します。
C:>db2set db2instprof
¥¥mynetname¥DB2MSCS-DB2
C:¥>db2ilist
DB2 C : MYCLUSTER
図 7. Cluster Administrator - インスタンス DB2 を表示した画面
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
24
Cluster Administrator の新しい画面は次のようになります。
3.
•
「DB2 Group 0」というグループが作成された
•
「DB2 Group 0」にはディスク・リソースを 1 つ含む
•
「DB2 Group 0」には 2 つ IP アドレスを含む
•
リソース・タイプ DB2 が DB2 パーティション用に作成された
•
インスタンス・ディレクトリーを保持するために、「DB2 Group 0」にネットワーク
名とファイル共用が作成された。このネットワーク名は「Private Network」上に作成
された。
次のステップは、1 次マシンとスタンバイ・マシン用に使用するマシンをそれぞれ決定し
ます。この例では、WA9 を「DB2 Group 0」の優先所有者に、WA10 をホット・スペア
ーに決めます。「DB2 Group 0」のプロパティーは、最初は優先所有者なしに構成されて
います。Cluster Administrator から、この「DB2 Group 0」用の構成を変更して、優先
所有者を指定します。
図 8. Cluster Administrator の「DB2 Group 0」用プロパティー・ボックス
4.
優先所有者を指定した次は、優先マシンが障害から回復した後、DB2 グループを優先マシ
ンに自動的にフェイルバックさせたいかどうかを決定します。自動フェイルバックをさせ
たくない場合、デフォルト動作ではフェイルバックをしないので、その他のアクションは
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
25
不要です。自動フェイルバックをさせたい場合、各 DB2 グループのプロパティー・ボック
スを変更する必要があります。
「Failback▼フェイルバック▲」タブで、「Allow failback▼フェイルバック有効▲」を
選択します。優先マシンがオンラインに戻る際のフェイルバックを有効にしたい場合、
「Allow failback▼フェイルバック有効▲」を「Immediately▼即時▲」に設定します。特
定 の 時間 帯 (1:00A.M. ∼ 8:00A.M.な ど) だ けフ ェ イル バ ック を 有効 に し たい 場 合、
「Failback between▼フェイルバック対象期間▲」オプションで時間帯を構成します。優
先マシンがこの時間帯にオンラインに戻った場合、フェイルバックは発生します。オンラ
インに戻ったのが 12:59A.M.だった場合、1:00A.M.に自動フェイルバックは発生しません。
図 9. 「DB2 Group 0」のフェイルバック設定
•
インスタンス DB2 の構成が終わりました。次は、インスタンス DB2 と同じグループ
内に存在するディスク・ドライブ上に、インスタンス内にある全データベースを配置
する必要があります。インスタンス DB2 については、すべてのデータはディスク F に
あります。既存データベースが使用されていて、現在ディスク F 上に存在しない場合、
リダイレクト・リストアを使用して、データを共用ドライブへ移動します。リダイレ
クト・リストアの実施方法については、DB2 Universal Database のマニュアルを参照
してください。新しいデータベースを作成する場合、ディスク F 上にデータベースと
その表スペースを必ず作成してください。DB2 インスタンスが別のマシンにフェイル
オーバーして、すべてのデータ・ファイルへアクセスできなくなった場合、データベ
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
26
ース・エラーが発生します。
C:¥>db2 create db sample on f:
DB20000I The CREATE DATABASE command completed
successfully.
C:¥>db2 create tablespace ts in nodegroup
ibmdefaultgroup managed by database using (file
‘f:¥container' 10000) on node (0)
DB20000I The SQL command completed successfully.
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
27
相互テイクオーバーの単一パーティション構成
相互テイクオーバーの単一パーティション構成では、クラスター内の各マシン上で DB2 インス
タンスが稼動します。クラスター内のマシンに障害が起きると、同一マシン上で複数の DB2
インスタンスが稼動することになります。このシナリオでは、同一クラスター内に 2 つの単一
パーティション・インスタンス (異なるインスタンス名が必要です) が構成されます。クラス
ター内で障害が起きなかった方のマシンが、これから課せられるワークロードを処理する能力
があることを保証できるように、慎重に計画を進める必要があります。
図 10. 相互テイクオーバーの単一パーティション構成
相互テイクオーバー環境の構成は、2 番目のインスタンスが構成されることを除いて、ホット・
スタンバイ環境の構成と非常によく似ています。次の例で、相互テイクオーバー構成のセット
アップに必要なステップを詳述します。
1.
ホット・スタンバイの単一パーティション構成に関する前セクションのすべてのステップ
を実施します。これにより、マシン WA9 が推奨所有者の DB2 というインスタンスが作成
されます。
2.
DB3 という DB2 UDB ESE インスタンスをマシン WA10 上に作成します。DB2 パーティ
ション間通信に予約されたポートがクラスター内の全マシンで利用できることを確認しま
す。
c:¥>db2icrt db3 -s ese -p n:¥sqllib -u
mydom¥db2admin,xxx -r 60004,60007
c:¥>db2ilist
DB3
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
28
DB2 C : MYCLUSTER
db2ilist の出力は、DB3 と DB2 という 2 つのインスタンスがあることを示しています。
DB2 の後ろに続く情報は、これがクラスタリングされたインスタンス (クラスター・イン
スタンス) であり、MYCLUSTER というクラスター内にあることを示しています。現在、
DB3 はクラスタリングされておらず、マシン WA9 上に存在しません。
3.
DB3 をクラスター・インスタンスにトランスフォームできるように、DB2MSCS ユーティ
リティー用の入力ファイルを作成します。インスタンス DB2 とインスタンス DB3 は必ず
しも同一マシン上に存在する必要はないため、このグループに使用されるリソースは、イ
ンスタンス DB2 に使用されるリソースとは異なるものでなければなりません。DB2MSCS
ユーティリティーの入力構成ファイルは、次のようになります。
DB2_INSTANCE=DB3
CLUSTER_NAME=MYCLUSTER
DB2_LOGON_USERNAME=mydom¥db2admin
DB2_LOGON_PASSWORD=xxx
GROUP_NAME=DB2 Group 1
DB2_NODE=0
IP_NAME=mscs12
IP_ADDRESS=9.26.75.26
IP_SUBNET=255.255.255.0
IP_NETWORK=Public Network
IP_NAME=ether1
IP_ADDRESS=10.1.1.2
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
NETNAME_NAME=mynetname1
NETNAME_VALUE=mynetname1
NETNAME_DEPENDENCY=ether1
DISK_NAME=Disk G:
DISK_NAME=Disk H:
DB2MSCS ユーティリティーを実行するには、入力ファイル名に-f オプションを指定し、
コマンドが正常に実行されることを確認します。インスタンスが現在存在するのはマシン
WA10 なので、WA10 上で DB2MSCS ユーティリティーを実行します。
c:¥>db2mscs –f:db2mscs.cfg.db3
DB21500I The DB2MSCS command completed successfully.
インスタンス DB3 を構成すると、「DB2 Group 1」というグループが作成されます。こ
のグループは、インスタンス DB2 用に作成されたものとは異なる IP アドレスを持ち、イ
ンスタンス DB2 では使用されていないディスク G およびディスク H を持ちます。
INSTPROF_DISK フィールドは、インスタンス DB2 に使用されましたが、DB3 の構成に
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
29
は使用されませんでした。したがって、DB3 については、INSTPROF_DISK は最初に識
別されたディスクがデフォルトになり、この場合はディスク G になります。db2ilist の出
力では、両方のインスタンスがクラスタリングされていることがわかります。
c:¥>set db2instance=DB3
c:¥>db2set db2instprof
¥¥mynetname1¥DB2MSCS-DB3
c:¥>db2ilist
DB3 C : MYCLUSTER
DB2 C : MYCLUSTER
図 11. Cluster Administrator -「DB2 Group 1」にインスタンス DB3 が入った画面
図 11 は、初期ホット・スタンバイ設定に加えて、次のことを示しています。
4.
•
「DB2 Group 1」というグループが作成された。
•
ディスク G および H が「DB2 Group 1」に移された。
•
IP アドレス「mscs12」と「ether1」が作成され、
「DB2 Group 1」に存在する。
•
タイプ DB2 の「DB3-0」というリソースが作成され、「DB2 Group 1」に存在する。
•
「DB2 Group 1」は現在マシン WA10 上に存在する。
この構成は相互テイクオーバー構成であって、インスタンス DB2 は WA9 を 1 次マシンと
して使用するように構成されているため、インスタンス DB3 は 1 次マシンとして WA10
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
30
を使用するように構成される必要があります。DB2 Group のプロパティーは、1 次マシン
として WA10、2 次マシンとして WA9 を表すように変更される必要があります。
図 12. 「DB2 Group 1」のプロパティー・ボックス
5. 優先所有者が「DB2 Group 1」に対して構成された後、自動フェイルバックを設定するか
どうかを決めます。自動フェイルバックを実施したい場合、「Failback▼フェイルバック
▲」タブにあるフェイルバック・オプションを「DB2 Group 1」に設定します。
6.
最後のステップでは、DB3 に関連付けられたすべてのデータベースおよび対応する表スペ
ースがディスク G かディスク H のいずれかに存在することを確認します。古いデータベ
ースが使用されていて、ディスク G またはディスク H にまだ存在しない場合、リダイレ
クト・リストアが必要になります。リダイレクト・リストアの詳細については、DB2 UDB
のマニュアルを参照してください。新しいデータベースが作成される場合、データベース
とその表スペースが、ディスク G かディスク H のいずれかに作成されることを確認して
ください。
c:¥>db2 create db sampleb on G:
DB20000I The CREATE DATABASE command completed
successfully.
c:¥>db2 create tablespace tsb in nodegroup
ibmdefaultgroup managed by database using(file
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
31
‘h:¥container1' 50000) on node(0)
DB20000I The SQL command completed successfully.
ステップ 3 でコマンドが WA10 上で実行され、DB2INSTANCE は DB3 を指すように設定さ
れました。DB3 は現在 WA9 にはないため、WA9 上の DB3 に対して DB2 コマンドを実行し
ようとすると、エラーになります。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
32
相互テイクオーバーの複数パーティション構成
相互テイクオーバーの複数パーティション構成では、クラスター内の各マシン上で DB2 パーテ
ィションが稼動します。クラスター内のマシンの 1 台に障害が発生すると、同一マシン上で複
数の DB2 パーティションが稼動することになります。クラスター内の各マシンが、これから課
せられるワークロードを処理する能力があることを保証できるように、慎重に計画を進める必
要があります。
図 13. 相互テイクオーバーの複数パーティション構成
この例では、2 ノード・クラスターにおける 2 パーティションの相互テイクオーバー構成の構
成方法を示します。最初は各マシン上には DB2 パーティションが 1 つあります。相互テイク
オーバー環境の構成は、アイドル状態のマシンがないことを除き、ホット・スタンバイ環境の
構成と非常によく似ています。
1.
最初に、MSCS をインストールして構成し、2 パーティションの DB2 インスタンスを停止
します。
C:¥>db2nlist /s
List of nodes for instance "DB2MPP" is as follows:
Node: "0" Host: "wa9" Machine: "wa9" Port: "0" - "stopped"
Node: "1" Host: "wa10" Machine: "wa10" Port: "0" "stopped"
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
33
DB2MSCS 入力ファイルを作成し、この入力ファイルを使用して DB2MSCS ユーティリ
ティーを実行します。この構成では、着信するリモート・クライアント要求をパーティシ
ョン 0 だけが受信し、パブリック・ネットワーク上で MSCS TCP/IP リソースが定義され
ると仮定します。
DB2_INSTANCE=DB2MPP
CLUSTER_NAME=MYCLUSTER
DB2_LOGON_USERNAME=mydom¥db2admin
DB2_LOGON_PASSWORD=xxx
GROUP_NAME=DB2 Group 0
DB2_NODE=0 10.1.1.1
IP_NAME=mscs11
IP_ADDRESS=9.26.75.25
IP_SUBNET=255.255.255.0
IP_NETWORK=Public Network
IP_NAME=ether0
IP_ADDRESS=10.1.1.1
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
NETNAME_NAME=mynetname
NETNAME_VALUE=mynetname
NETNAME_DEPENDENCY=ether0
DISK_NAME=Disk F:
TARGET_DRVMAP_DISK=Disk F:
GROUP_NAME=DB2 Group 1
DB2_NODE=1 10.1.1.2
IP_NAME=ether1
IP_ADDRESS=10.1.1.2
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk G:
TARGET_DRVMAP_DISK=Disk G:
上 記 構 成 フ ァ イ ル を 使 用 し て db2mscs ユ ー テ ィ リ テ ィ ー を 実 行 す る と 、 Cluster
Administrator は次のようなクラスター・ビューが表示されます。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
34
図 14. Cluster Administrator -クラスター・インスタンス DB2MPP の表示
2.
DB2 グループのそれぞれについて、1 次マシンとして予定されているマシンを決めます。
この例の場合、「DB2 Group 0」の 1 次マシンを WA9、「DB2 Group 1」の 1 次マシン
を WA10 として設定します。また、必要であれば DB2 グループ用に自動フェイルバック
を構成します。
3.
高可用 (HA) ディスク上に全データベースを作成またはリストアします。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
35
DB2 管理サーバーの構成
DB2 管理サーバーは、DB2 インスタンスおよびデータベースを管理するために、DB2 コント
ロール・センターで使用されます。管理サーバーの高可用性が必要な場合、クラスタリングも
必要です。管理サーバーをクラスタリングするステップは、他の通常のインスタンスをトラン
スフォームするステップとよく似ています。次に示す例では、管理サーバーを使用して、「相
互テイクオーバーの複数パーティション構成」で作成された DB2MPP インスタンスを管理し
ます。また、この例では、パーティション 0 用に構成された共用ディスクと IP アドレスを再
利用するため、パーティション 0 と管理サーバーはこれらリソースを共用することになります。
同じリソースを共用するので、管理サーバーをパーティション 0 と同じグループに配置する必
要があります。以下に、DB2 管理サーバーを DB2MPP 用に構成するための手順を示します。
1.
すべてのマシンで管理サーバーを停止します。
C:¥>db2admin stop
SQL4407W The DB2 Administration Server was stopped successfully.
WA9 に管理サーバーが存在しない場合、db2admin create コマンドを使用して、WA9
上にこのインスタンスを作成します。
2.
各マシン上で次のコマンドを実行することにより、最初のノードを除くすべてのノードで
管理サーバーをドロップします。
C:¥>db2admin drop
SQL4402W The DB2ADMIN command was successful.
3.
管理サーバーが存在する最初のノード (WA9) で、「Windows Services▼Windows サー
ビス▲」ダイアログ・ボックスを表示して、管理サーバー・インスタンスを、手動で開始
するように変更します。管理サーバーの名前は DB2DAS00 なので、「Services▼サービ
ス▲」ダイアログ・ボックスに DB2DAS-DB2DAS00 と表示されます。
管理サーバーをクラスタリングするために、DB2MSCS ユーティリティーで使用される構
成入力ファイルを作成します。
DAS_INSTANCE=DB2DAS00
CLUSTER_NAME=MYCLUSTER
DB2_LOGON_USERNAME=mydom¥db2admin
DB2_LOGON_PASSWORD=xxx
GROUP_NAME=DB2 Group 0
DISK_NAME=Disk F:
INSTPROF_DISK=Disk F:
グループ名「DB2 Group 0」は、パーティション 0 の構成に使用したのと同じグループで
あり、すべてのリソースがパーティション 0 と同じグループに作成されます。また、すで
にパーティション 0 用に構成された IP アドレスは再利用可能であるため、ディスク F を
再利用し、IP アドレスは構成しません。ディスク F は「DB2 Group 0」用に構成済みであ
ったとしても、管理サーバーに関連した全情報が配置されるのがディスク F であるため、
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
36
再び指定される必要があります。汎用サービスが作成され、それにより、MSCS は DB2
管理サーバーをモニターできるようになります。
図 15. Cluster Administrator の画面(DB2 Group 0 に DB2DAS00 を追加)
4.
WA9 から DB2MSCS ユーティリティーを実行します。
c:¥>db2mscs -f:db2mscs.cfg.admin
DB21500I The DB2MSCS command completed successfully.
5.
DB2 管理に使用されるすべてのクライアントで、DB2 コントロール・センターを使用し
た管理サーバーへの参照があれば削除します。次に、DB2 コントロール・センターを使用
し、パブリック・ネットワークで定義された高可用 (HA) クラスターIP アドレスを使用す
る管理サーバーへの参照を再びカタログします。
これで管理サーバーは、クラスター内で統合されました。どのようなリモート・クライアント
接続も高可用 IP アドレスを経由することと、管理サーバーで必要とされるどのようなスクリプ
トやデータも、DB2DAS00 インスタンスに関連付けられた高可用ディスク上に配置されること
を、注意して確認してください。Cluster Administrator には、クラスター内に構成されたイン
スタンス DB2MPP が表示され、パーティション 0 を含むグループには管理サーバーも含まれ
ます。上記ステップは、単一パーティション構成例のインスタンス DB2 用に、管理サーバーを
クラスタリングするためにも利用できます。
注意：一時点で 1 台のマシン上で稼動できる DB2 管理サーバーは 1 つだけなので、相互テイ
クオーバーの単一パーティション構成では、各インスタンス用に DB2 管理サーバーをクラスタ
リングすることはできません。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
37
リモート・クライアント接続
MSCS は高可用 TCP/IP リソースを作成する機能を備えています。リモート・クライアントは、
サーバーへ接続する際に、パブリック・ネットワークで定義された高可用 IP アドレスを使用す
る必要があります。
クライアントから DB2 サーバーへの TCP/IP 接続をカタログする場合、接続先のパーティショ
ンと同じグループに位置するクラスター用に構成された IP アドレスを使用する必要がありま
す。したがって、特定のデータベース・パーティションへのクライアント接続を構成する場合、
その DB2 パーティションと同じグループにある高可用 TCP/IP アドレスを使用する必要があり
ます。複数パーティションへのデータベース接続をカタログすることにより、DB2 のコーディ
ネーター機能は複数のパーティションにわたって分散されます。物理マシンか、パーティショ
ンとは異なるグループにある IP アドレスのいずれかと関連付けられた IP アドレスが使われる
場合、データベース・パーティションが実際に存在するマシンを IP アドレスが指すかどうかは、
保証の限りではありません。
考慮されるべきもう 1 つの要因は、クライアントは指定されたポートを使用してサーバーに接
続するということです。同じポートがクラスター内のすべてのマシン上のインスタンスで利用
可能でなければならず、クラスター内の各マシン上のサービス・ファイルで定義される必要が
あります。次の例は、「ホット・スタンバイの単一パーティション構成」のセクションで作成
したインスタンス DB2 用に、リモート・クライアントからデータベース sample への接続をカ
タログする方法をを示しています。
1.
クラスター内の全マシン用のサービス・ファイルに次のエントリーを追加して、未使用ポ
ートを DB2 用に予約します。
db2cDB2 50000/tcp #connection port for the DB2 instance DB2
db2iDB2 50001/tcp #interrupt port for the DB2 instance DB2
2.
各パーティションについて、DB2COMM が TCPIP に設定されていることを確認します。
C:¥>set DB2INSTANCE=DB2
C:¥> db2set DB2COMM=TCPIP
3.
インスタンス DB2 について、データベース・マネージャー構成を更新し、着信する TCP/IP
クライアントを listen するポートをインスタンスが認識できるようにします。
C:¥>db2 update dbm cfg using svcename db2cdb2
4.
ステップ 2 と 3 の変更を有効にするには、パーティションをいったんオフラインにしてか
らオンラインに戻す必要があります。Cluster Administrator から、DB2 パーティション
を表すリソースの上で右クリックし、「Take Offline▼オフラインにする▲」を選択しま
す。すべての DB2 リソースをオフライン状態にしてから、同じリソースを右クリックして
「Bring Online▼オンラインにする▲」を選択します。
5.
すべてのパーティションで着信リモート要求の受信準備が整ったところで、データベー
ス・パーティションはリモート・マシンからカタログされる必要があります。リモート・
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
38
クライアント上のサービス・ファイルは、サーバー・マシンでの更新と同様のエントリー
で更新される必要があります。
インスタンス DB2 用に SAMPLE データベースをカタログするには、次のようにします。
C:¥>db2
C:¥>db2
C:¥>db2
C:¥>db2
catalog tcpip node nodea remote mscs11 server db2cdb2
catalog db sample at node nodea
terminate
connect to sample user db2admin using xxx
tcpip ノードをカタログするために、mscs11 をクラスター内の対応する IP アドレスと置
き換えることができます。
オプションで、DB2 クライアント構成アシスタントを用いて、グラフィカル・インターフ
ェースを使用して手作業でデータベースへの接続をカタログすることもできます。この方
式を使用する場合、データベース接続のカタログに高可用 IP アドレスが使われることを確
認します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
39
ユーザー・スクリプト
DB2 は、各 DB2 リソースがオンラインになる前後と、各リソースがオフラインになる前後に、
バッチ・スクリプトを実行する機能を備えています。このバッチ・スクリプトは各インスタン
スのインスタンス・ディレクトリーに位置し、各インスタンスはこれらスクリプト・ファイル
のコピーを別個に持ちます。インスタンス・ディレクトリーを特定するには、次のように db2set
コマンドを発行し、インスタンス名を結果に付加します。
c:>set DB2INSTANCE=DB2MPP
c:¥>db2set db2instprof
¥¥mynetname¥DB2MSCS-DB2MPP
この特定のケースでは、インスタンス DB2MPP のインスタンス・ディレクトリーは、
¥¥mynetname¥DB2MSCS-DB2MPP¥DB2MPP の下に位置します。各 DB2 パーティションがオ
ン ラ イ ン に さ れ る 前 後 に 実 行 す る ス ク リ プ ト は 、 そ れ ぞ れ db2cpre.bat お よ び
db2cpost.bat と呼ばれます。これらのスクリプトは、オフライン前スクリプトおよびオフラ
イン後スクリプトとも呼ばれます。これらのバッチ・ファイルはオプションであって、デフォ
ルトでは存在せず、存在する場合だけ実行されます。このバッチ・ファイルは MSCS クラスタ
ー・サービスによって起動され、バックグラウンドで実行されます。スクリプト・ファイルは
標準出力にリダイレクトし、スクリプト・ファイル中から実行されるコマンドの実行結果の出
力があれば、記録する必要があります。
オンライン前スクリプトは、DB2 リソースをオンラインにする試みが行われる前に、実行して
完了します。したがって、オンライン前スクリプト中のコマンドは、MSCS が DB2 リソース
をオンラインに戻そうとしてタイムアウトしないように、妥当な時間で実行することが重要で
す。オフライン前スクリプトも、DB2 がオフラインにされる前に同時に実行するので、フェイ
ルバック時間に大きな影響を与えないように、効率的に実行することを確認する必要がありま
す。
注意：ユーザー・スクリプトは、DB2INSTANCE および DB2NODE 環境変数が、スクリプト
を実行するリソースに対応する値に設定された状態で実行されます。DB2NODE の値は、パー
ティション番号に対応します。オフライン前およびオフライン後スクリプトは、DB2 プロセス
が異常終了した場合には実行されません。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
40
構成のテスト
高可用構成をテストする場合、障害発生の可能性のあるすべてのポイントをテストして、予備
のパスが用意されていることを確認するのが理想です。たとえば、ディスクやネットワーク、
マシン、およびソフトウェアの障害などは、テストが必要です。
このセクションの目標は、システム全体のテスト方法を詳述することではなく、システムの
DB2 部分のテスト方法を読者に示すことです。
1.
リモート・クライアントから、高可用データベースに接続して照会を発行します。照会は
全パーティションにわたって分散された表に対して発行される必要があります。
2.
パーティションを含むグループを別のマシンへ移動します。
3.
リモート・クライアントから、ステップ 1 の照会を再発行してみます。照会に失敗した場
合、同じ高可用データベースに再接続してから、照会を再発行します。こうすれば成功す
るはずです。
注意：マシンの故障など、ハード・クラッシュのためにパーティションに障害が発生した
場合、DB2 はどのデータベース・アプリケーションも強制的にオフにしようとはしません。
障害の起きたパーティションを使用した未コミット・トランザクションがあればロールバ
ックして、データベースをトランザクション的に一貫した状態にします。
4.
そのパーティションを含むグループを 1 次マシンへ戻します。
5.
リモート・クライアントから、ステップ 1 の照会を再発行してみます。照会に失敗した場
合、同じ高可用データベースに再接続してから、照会を再発行します。こうすれば成功す
るはずです。
6.
ハードウェアおよびソフトウェアのさまざまな障害をシミュレートし、本番環境で予想さ
れる実際のワークロードをより厳密にシミュレートしたクライアント・ワークロードを使
用して、ステップ 1∼5 を再び実施します。
注意：複数のマシンにまたがるクラスターを使用して、複数のマシンの障害をテストする必要
があります。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
41
ローリング・アップグレード
ローリング・アップグレードとは、アプリケーションをオンラインに保ちながら、クラスター
上のソフトウェアをアップグレードする機能です。MSCS 環境では、1 台のマシンがアップグ
レード中にも別のマシンではパーティションはオンライン状態でいられるので、DB2 のローリ
ング・バックアップの実施には理想的です。ローリング・アップグレードは、データベースや
インスタンスの移行を必要としない DB2 インストール用にサポートされています。
注意：複数パーティション構成をアップグレードする場合、複数のデータベース・パーティシ
ョンは、異なるコード・レベルで同時にアクティブに稼動していないことを確認してください。
次の例は、前述した「相互テイクオーバーの複数パーティション構成」のローリング・アップ
グレードを実施する方法を示しています。同じインスタンスの異なるパーティションは異なる
DB2 レベルで同時に稼動できたいため、アップグレード中には注意が必要です。ここで用いる
方針では、複数台のマシンを 2 つに分けて、まず後半のマシンに全パーティションを移動して
前半のマシンをアップグレードします。そして全パーティションをオフラインにしてから前半
のマシンに戻し、オンラインにします。最後に、後半のマシンをアップグレードして、パーテ
ィションを適切な位置へ戻します。
1.
最初にパーティション 0 と 1 は、それぞれマシン WA9 と WA10 に位置します。WA9 が
アイドル状態になるように、パーティション 0 を WA10 に移動します。
2.
WA9 のクラスター・サービスを停止します (net stop clussvc)。
3.
WA9 に DB2 FixPak を適用します。
4.
すべての DB2 リソースをオフラインにして、次に WA9 でクラスター・サービスを始動し
ます (net start clussvc)。すべての DB2 グループを WA9 に移動し、それらをオンライン
に戻すと、WA10 がアイドル状態になります。
5.
WA10 でクラスター・サービスを停止します。
6.
WA10 に DB2 FixPak を適用します。
7.
WA10 でクラスター・サービスを始動します。
8.
次に、都合のいいタイミングで、パーティション 1 を WA10 に戻します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
42
マシンの壊滅的破損後のクラスターの修復
マシンに修復不可能な故障が起きた場合、オペレーティング・システムを再ロードするか、マ
シンのリプレースが必要です。マシン WA10 が壊滅的に破損して、オペレーティング・システ
ムを再インストールしなければならないと仮定します。次の例では、相互テイクオーバーの複
数パーティション構成において、インスタンス DB2MPP と管理サーバーを修復するステップ
を示しています。現在、DB2MPP および管理サーバーは WA9 上でアクティブであり、クライ
アントはまだ完全にデータベースにアクセスできています。
1.
WA9 上の Cluster Administrator から、WA10 を右クリックして「Evict Node▼ノード除
去▲」を選択し、WA10 をクラスターから除去します。
2.
DB2 は DB2CLUSTERLIST という DB2 プロファイル変数を使用します (この変数は、ク
ラスターにあるマシンを見極めるために DB2 で使用する変数です)。DB2MPP を使用した
次の例で示すように、DB2CLUSTERLIST は最初はクラスター内の 2 つのマシンを表示
します。
C:¥>db2set DB2CLUSTERLIST
WA9 WA10
マシン WA9 で、インスタンス DB2MPP のクラスター・リストから WA10 を除去します。
set DB2INSTANCE=DB2MPP
db2set DB2CLUSTERLIST= “WA9”
3.
マシン WA10 上にオペレーティング・システムを再インストールします。
4.
マシン WA10 上に MSCS を再インストールして、初期クラスターに戻し、全グループを
WA9 に残します。
5.
マシン WA10 で、DB2 UDB を再インストールして、インストールで作成されたインスタ
ンスがあればドロップします。別ノードを既存インスタンスに追加する DB2 インストー
ル・オプションを選ばないようにしてください。
6.
まだ存在しない場合は WA10 に管理サーバーを作成し、それがアクティブでないことを確
認します。
db2admin create
注意：このステップは、FixPak を一切適用せずに DB2 UDB V8.1 を使用している場合だ
け、必要になります。
7.
WA9 から、管理サーバーのクラスター・リストから WA10 を削除します。これにより、
前のステップで作成された管理サーバーも削除し、最初に構成された高可用の管理サーバ
ーだけが残ります。
db2iclus drop /m:wa10 /DAS:db2das00 /c:mycluster
/u:mydom¥db2admin,xxx
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
43
8.
マシン WA9 で、インスタンス DB2MPP および管理サーバーのクラスター・リストにマ
シン WA10 を追加して戻します。このステップはまた、必要な DB2 サービスを WA10 に
作成します。
db2iclus add /m:wa10 /u:mydom¥db2admin,xxx /i:db2mpp
/c:mycluster
db2iclus add /m:wa10 /u:mydom¥db2admin,xxx /DAS:db2das00
/c:mycluster
9.
DB2MPP パーティションと管理サーバーを含むグループは、これでマシン WA10 へフェ
イルオーバーする準備が整いました。
10. 適切なタイミングで、Cluster Administrator の「Move Group▼グループの移動▲」オプ
ションを使用して、DB2MPP パーティションと管理サーバーを含むグループが WA10 で
正常に始動できることを確認します。
マシン WA10 を新しいマシンでアップグレードする場合、最初に WA10 上にある全グループ
を WA9 へ移動し、それからステップ 1∼10 を実施します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
44
セキュリティーの管理
DB2 が MSCS 環境下で適切に機能すると、今度はクラスターを管理できるユーザーを指定し
たい場合があります。クラスターを管理するには、ユーザーは両ノードに対する管理許可か、
あるいはそのクラスターを管理するための特定の許可を持つ必要があります。デフォルトでは、
すべてのノードのローカル管理者グループは、クラスターを管理する許可を持っています。全
ノードに対する管理許可を付与せずに、クラスターを管理する許可をユーザーに付与するには、
次のようにします。
1.
Cluster Administrator を起動します。
2.
クラスター名を右クリックし、次に「Properties▼プロパティー▲」をクリックします。
3.
「Security▼セキュリティー▲)または「Permissions▼許可▲」をクリックします。
4.
クラスターの管理を許可するユーザーおよびグループを指定します。
ユーザーは、HKEY_LOCAL_MACHINE¥Cluster¥IBM¥DB2¥PROFILES というレジストリー・
キーの下のクラスター・レジストリーに保管された DB2 レジストリー変数へのアクセス権限も、
持つ必要があります。デフォルトでは、全ノード上のローカル管理者グループは、クラスター・
レジストリーを完全に制御できます。DB2 レジストリー変数のアクセス許可をユーザーに付与
するには、次のようにします。
1.
regedt32.exe を実行します。
2.
HKEY_LOCAL_MACHINE¥Cluster¥IBM¥DB2¥PROFILES キーが表示されるまで、クラス
ター・キーを拡張します。
3.
キーを選択し、「Security▼セキュリティー▲)をクリックします。
4.
「Permissions▼許可▲」をクリックします。
5.
DB2 を稼動させる必要のあるユーザーおよびグループを指定します。
DB2 の認証
DB2 が別のマシンへフェイルオーバーするときに、同じ (ドメイン) ユーザーが同じ権限でデ
ータベースに接続できるように、ドメイン・セキュリティー (ドメイン・ユーザーおよびドメ
イン・グループ) の使用を推奨します。
デフォルトでは、ドメイン管理者は、データベースを完全にアクセスできます。ドメイン・ユ
ーザーおよびドメイン・グループに対する SYSADM 権限を制約するには、次のステップを実
施します。
1.
ドメイン・グループを作成します。グループ名は、8 文字以下を使用するという DB2 命名
規則に準拠する必要があります。
2.
このドメイン・グループに対する DB2 SYSADM 権限を持つドメイン・ユーザーがいれば、
追加します。
3.
DB2 が 稼 動 す る マ シ ン か ら 、 デ ー タ ベ ー ス ・ マ ネ ー ジ ャ ー 構 成 パ ラ メ ー タ ー
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
45
SYSADM_GROUP の値を、ドメイン・グループの名前に変更します。
4.
DB2 インスタンスを再始動します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
46
その他のサンプル構成
MSCS クラスター内では、多くの異なる方法で DB2 を構成できます。以下に、その他のサン
プル構成をいくつか紹介します。
相互テイクオーバーのロード・バランシング構成
この構成の目的は、1 台のマシンが故障した場合、ワークロードが残りの全マシンに均等に分
散されることを保証することです。クラスター内の各マシンが、故障したマシンから引き継ぐ
可能性のあるリソース要件に対応できる処理能力を備えていることに、注意を払う必要があり
ます。すべてのマシンが同じ構成で、各 DB2 パーティションが均等に使用されている場合、パ
ーティションをすべてのアクティブなマシンに均等に分散することが望まれます。本書の例で
は、6 つの DB2 パーティションを、マシンを 3 台しか含まないクラスター全体に等しく分散す
ることから始めます。
クラスター内のマシン 1 台が故障した場合、障害の起きた 2 つのパーティションを同じマシン
にフェイルオーバーするのは避けたいものです。同じマシンにフェイルオーバーすると、1 台
のマシンには 4 つの DB2 パーティション、もう 1 台のマシンには 2 つの DB2 パーティション
が配置されることになります。したがって、図 16 に示すとおり、各マシン上の 2 つのパーテ
ィションは、別々のマシンにフェイルオーバーするように構成する必要があります。
図 16. 相互テイクオーバーのロード・バランシング例
この構成では、3 台目のマシンが故障した場合、パーティション 4 とパーティション 5 はそれ
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
47
ぞれマシン 1 とマシン 2 に移ります。これにより、システム全体に均等に分散されたワークロ
ードが維持されます。
ロード・バランシングのこの特定の例については、各 MSCS グループは異なるマシンにフェイ
ルオーバーするように構成できるので、各 DB2 パーティションは異なる MSCS グループ内に
位置する必要があります。
1.
最初に、MSCS がインストールされ、6 つのパーティションで成る DB2 インスタンスが 1
つ構成されて停止されます。
C:¥>db2nlist /s
List of nodes for instance
Node: "0" Host: "stress01"
Node: "1" Host: "stress01"
Node: "2" Host: "stress02"
Node: "3" Host: "stress02"
Node: "4" Host: "stress03"
Node: "5" Host: "stress03"
2.
"DB2MPP"
Machine:
Machine:
Machine:
Machine:
Machine:
Machine:
is as follows:
"stress01" Port:
"stress01" Port:
"stress02" Port:
"stress02" Port:
"stress03" Port:
"stress03" Port:
"0"
"1"
"0"
"1"
"0"
"1"
-
"stopped"
"stopped"
"stopped"
"stopped"
"stopped"
"stopped"
DB2MSCS 入力ファイルを作成し、この入力ファイルを使用して DB2MSCS ユーティリ
ティーを実行します。この構成は、パーティション 0 だけが着信リモート・クライアント
要求を受け取り、よって、パブリック・ネットワークで定義された MSCS TCP/IP リソー
スを持つ唯一のパーティションになると想定しています。
DB2_INSTANCE=DB2MPP
CLUSTER_NAME=CLUSTERX
DB2_LOGON_USERNAME=mydom¥db2admin
DB2_LOGON_PASSWORD=xxx
GROUP_NAME=DB2 Group 0
DB2_NODE=0 10.1.1.5
IP_NAME=mscs3
IP_ADDRESS=9.26.97.16
IP_SUBNET=255.255.254.0
IP_NETWORK=Public Network
IP_NAME=ether0
IP_ADDRESS=10.1.1.5
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
NETNAME_NAME=mynetname
NETNAME_VALUE=mynetname
NETNAME_DEPENDENCY=ether0
DISK_NAME=Disk N:
TARGET_DRVMAP_DISK=Disk N:
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
48
GROUP_NAME=DB2 Group 1
DB2_NODE=1 10.1.1.6
IP_NAME=ether1
IP_ADDRESS=10.1.1.6
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk O:
TARGET_DRVMAP_DISK=Disk O:
GROUP_NAME=DB2 Group 2
DB2_NODE=2 10.1.1.7
IP_NAME=ether2
IP_ADDRESS=10.1.1.7
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk P:
TARGET_DRVMAP_DISK=Disk P:
GROUP_NAME=DB2 Group 3
DB2_NODE=3 10.1.1.8
IP_NAME=ether3
IP_ADDRESS=10.1.1.8
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk Q:
TARGET_DRVMAP_DISK=Disk Q:
GROUP_NAME=DB2 Group 4
DB2_NODE=4 10.1.1.9
IP_NAME=ether4
IP_ADDRESS=10.1.1.9
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk R:
TARGET_DRVMAP_DISK=Disk R:
GROUP_NAME=DB2 Group 5
DB2_NODE=5 10.1.1.10
IP_NAME=ether5
IP_ADDRESS=10.1.1.10
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk S:
TARGET_DRVMAP_DISK=Disk S:
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
49
3.
各 DB2 グループのフェイルオーバー・プリファレンスを決め、必要であれば自動フェイル
バックを有効にします。表 1 に、1 台のマシンが故障した場合に障害の起きたパーティシ
ョンが別のマシンへフェイルオーバーするという、フェイルオーバー・プリファレンスを
示しています。
第 1 プリファレンス
第 2 プリファレンス
DB2MPP パーティション 0
STRESS01
STRESS02
DB2MPP パーティション 1
STRESS01
STRESS03
DB2MPP パーティション 2
STRESS02
STRESS01
DB2MPP パーティション 3
STRESS02
STRESS03
DB2MPP パーティション 4
STRESS03
STRESS01
DB2MPP パーティション 5
STRESS03
STRESS02
表 1. 相互テイクオーバーのロード・バランシング構成の優先所有者
4.
Cluster Administrator から全 DB2 リソースを開始し、高可用ディスク上に全データベー
スを作成またはリストアします。
複数のクラスター構成
MSCS クラスターは、現在は最大 4 マシンまで、Windows .NET では最大 8 マシンまで拡がる
ことができます。しかし、使用される ESE インスタンスがクラスター内で利用可能なマシンよ
りも多くのマシンに広がる場合、複数のクラスターを使用できます。各 DB2 パーティションは
同一クラスター内のマシンにしかフェイルオーバーできません。特定のクラスター内の全マシ
ンが故障状態になると、そのクラスター内に存在する全パーティションは使えなくなります。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
50
図 17. 複数クラスターに拡がる DB2 インスタンス
図 17 は、4 パーティション ESE インスタンスが、それぞれマシン 2 台で構成された 2 つのク
ラスターに拡がる様子を示しています。クラスター内の各ノードで DB2 パーティションが 1
つ稼動しているので、各クラスターの初期構成は相互テイクオーバー構成です。
注意：複数のクラスターを使用でき、各クラスターは必ずしも同じタイプの構成である必要は
ありません。
次に、図 17 に示した例を構成する方法を示します。パーティション 0 がディスク N、パーテ
ィション 1 がディスク O、パーティション 2 がディスク P、パーティション 3 がディスク Q を
所有するとします。
1.
最初に、MSCS をインストールして、4 つのパーティションから成る DB2 インスタンスを
構成して停止します。CLUSTERX はマシン STRESS01 と STRESS02、CLUSTERY は
マシン STRESS03 と STRESS04 で構成されます。
C:¥>db2nlist /s
List of nodes for instance
Node: "0" Host: "stress01"
Node: "1" Host: "stress02"
Node: "2" Host: "stress03"
Node: "3" Host: "stress04"
"DB2MPP"
Machine:
Machine:
Machine:
Machine:
is as follows:
"stress01" Port:
"stress02" Port:
"stress03" Port:
"stress04" Port:
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
"0"
"0"
"0"
"0"
-
"stopped"
"stopped"
"stopped"
"stopped"
51
2.
DB2MSCS 入力ファイルを作成し、このファイルを使用して DB2MSCS ユーティリティ
ーを実行します。この構成では、パーティション 0 だけが着信リモート・クライアント要
求を受け取り、パブリック・ネットワークで定義された MSCS TCP/IP リソースを持つ唯
一のパーティションであると想定します。
DB2_INSTANCE=DB2MPP
CLUSTER_NAME=CLUSTERX
DB2_LOGON_USERNAME=mydom¥db2admin
DB2_LOGON_PASSWORD=xxx
GROUP_NAME=DB2 Group 0
DB2_NODE=0 10.1.1.5
IP_NAME=mscs3
IP_ADDRESS=9.26.97.16
IP_SUBNET=255.255.254.0
IP_NETWORK=Public Network
IP_NAME=ether0
IP_ADDRESS=10.1.1.5
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
NETNAME_NAME=mynetname
NETNAME_VALUE=mynetname
NETNAME_DEPENDENCY=ether0
DISK_NAME=Disk N:
TARGET_DRVMAP_DISK=Disk N:
GROUP_NAME=DB2 Group 1
DB2_NODE=1 10.1.1.6
IP_NAME=ether1
IP_ADDRESS=10.1.1.6
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk O:
TARGET_DRVMAP_DISK=Disk O:
CLUSTER_NAME=CLUSTERY
GROUP_NAME=DB2 Group 2
DB2_NODE=2 10.1.1.7
IP_NAME=ether2
IP_ADDRESS=10.1.1.7
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk P:
TARGET_DRVMAP_DISK=Disk P:
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
52
GROUP_NAME=DB2 Group 3
DB2_NODE=3 10.1.1.8
IP_NAME=ether3
IP_ADDRESS=10.1.1.8
IP_SUBNET=255.0.0.0
IP_NETWORK=Private Network
DISK_NAME=Disk Q:
TARGET_DRVMAP_DISK=Disk Q:
3.
各 DB2 グループのフェイルオーバー・プリファレンスを決定し、必要であれば自動フェイ
ルバックを有効にします。
4.
高可用ディスクにすべてのデータベースを作成またはリストアします。
注意：複数クラスター環境で db2set コマンドを発行する場合、クラスターごとにコマンドが
実行されることを確認します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
53
付録 A – 制限および制約事項
MSCS 環境で DB2 を実行する場合、次のような制限および制約が適用されます。
•
MSCS は物理ディスク・リソースを指すときにドライブ文字を使用するので、DB2 データ
ベースおよび表スペース・コンテナーのパスを決める際に、ドライブ文字を使用すること
をお勧めします。
•
MSCS はロー・ディスク・デバイスを管理できないため、DB2 はロー・ディスク・デバイ
スを使用するように構成すべきではありません。
•
DB2 パーティションは、Cluster Administrator などの MSCS インターフェースから管理
される必要があります。MSCS は MSCS の制御外から起動されたリソースを認識しないた
め、モニターもしません。また、MSCS の制御外からの DB2 パーティションの停止の試み
は、そのリソースが Cluster Administrator によって最初にオンラインにされたものである
場合、MSCS はリソース障害として扱います。したがって、この環境では、DB2 インスタ
ンスの始動と停止に、DB2STOP、DB2START、および DB2 コントロール・センターなど
の方式を使用しないようにしてください。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
54
付録 B – よくある質問
1.
Q. ESE インスタンスがクラスター内の他のマシンで始動しません。
A. DB2 ESE インスタンスは、始動中に使用されるサービス・ファイルでポートを予約し
ます。サービス・ファイルでポートが割り振られていない場合、DB2 は自動的にそのエン
トリーをサービス・ファイルに追加します。これらのポートがクラスター内の全マシンで
利用できることを確認してください。以下に、インスタンス DB2MPP に付随するサービ
ス・ファイルのサンプル・エントリーを示します。
DB2_DB2MPP 60000/tcp
DB2_DB2MPP_1 60001/tcp
DB2_DB2MPP_2 60002/tcp
DB2_DB2MPP_END 60003/tcp
2.
Q. DB2MSCS ユーティリティーを実行すると、次のようなエラーになりました。
c:¥>db2mscs -f:db2mscs.cfg.db2
Warning: The message file is missing
DB2MSCS processing complete, rc = 126
A. DB2 がインストールされた後、DB2MSCS ユーティリティーの実行に進む前に、クラ
スター内の各マシンをリブートする必要があります。
3.
Q. DB2MSCS ユーティリティーを実行すると、次のようなエラーになりました。
c:¥>db2mscs -f:db2mscs.cfg.badip
DB21524E Failed to create the resource "mscs5". Win32 error: ""
A. リソース mscs5 に対応する IP アドレスは、ネットワークですでに使用されています。
指定された IP アドレスが未使用かどうかを確認してください。
4.
Q. DB2MSCS ユーティリティーを実行すると、次のようなエラーになりました。
c:¥>db2mscs -f:db2mscs.cfg.baddisk
DB21526E Failed to move resource “O:". Win32 error: "The
cluster resource could not be found.”
A. 指定された物理ディスク・リソースはクラスター内に存在しません。入力構成ファイル
中のディスク名が、Cluster Administrator で指定された名前と正確に一致する (たとえば
「Disk O」) ことを確認してください。
5.
Q. DB2MSCS ユーティリティーを実行しましたが、正常に実行されません。
A. メッセージ・リファレンスを参照し、DB2MSCS ユーティリティからの戻りコードに
基づいて、解決策を判断してください。
6.
Q. db2nlist or db2nchg コマンドを実行すると、数分後に通信エラーで失敗します。
A. 使用したすべての TCP/IP アドレスが、ドメイン・ネーム・サーバーに対応するエント
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
55
リーを持っているか、各マシン上のホスト・ファイルにエントリーされているかを確認し
てください。
7.
Q. 使用しているパーティションはフェイルオーバーしません。
A. パーティションは Cluster Administrator などのクラスター・インターフェースを通し
て始動される必要があります。そうしないと、クラスターは、この DB2 パーティションを
オンライン状態に維持すべきであることを認識しません。
8.
Q. db2stop を実行すると、パーティションは自動的に再始動します。
A. DB2 パーティションが Cluster Administrator から始動された場合、クラスター・イン
ターフェースを通して停止される必要があります。MSCS は db2stop をリソース障害と
して扱い、その DB2 リソースをオンラインに戻そうとします。
9.
Q. DB2 パーティションを含むグループをオフラインにしようとしますが、DB2 リソース
はうまくオフラインになりません。
A. そのパーティションについて、DB2_FALLBACK が ON または YES に設定されている
ことを確認します (db2set DB2_FALLBACK=ON)。DB2 パーティションを含むグループ
を、ある時点でオフラインにするには、DB2 パーティションをオフラインにしようとして
いるマシン上のクラスター・サービスを停止します。
10. Q. 複数パーティション構成で create database コマンドの実行に失敗します。
A. ドライブ・マッピングが正常に実施されていることを確認します。手動のドライブ・マ
ッピングを有効にするには、すべての DB2 リソースをいったんオフラインにしてから、オ
ンラインに戻す必要があります。
11. Q. リモート・クライアントはデータベース・パーティションに正常に接続できますが、パ
ーティションをフェイルオーバーすると、正常に再接続できません。
A. データベース・パーティションと同じグループに構成された高可用 IP アドレス・リソ
ースに接続するように、クライアントがカタログされていることを確認します。また、デ
ータベース・マネージャー構成の SVCENAME パラメーターで定義されたポートが、まだ
使用中ではないことを確認します。
12. Q. DB2 コマンド行プロセッサーからローカルに DB2 コマンドを発行すると、次のエラー
のいずれかを受け取ります。
C:¥>db2 connect to sample
SQL1039C An I/O error occurred while accessing the database
directory. SQLSTATE=58031
C:¥>db2 connect to test
SQL6048N A communication error occurred during START or STOP
DATABASE MANAGER processing.
A. データベース・パーティションは現在のマシン上にありません。パーティションが存在
するマシンで、コマンドを発行してください。
13. Q. フェイルオーバー後、トランザクションのいくつかがロック待機中のようです。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
56
A. データベース内に未確定トランザクションがある可能性があります。次のコマンドを使
用して、手作業で未確定トランザクションを解決してください。
db2 list indoubt transactions with prompting
未確定トランザクションの詳細については、DB2 UDB のマニュアルを参照してください。
14. Q. インスタンスをデクラスターするために、-u オプションを付けて DB2MSCS ユーティ
リティーを実行しましたが、失敗しました。
A. インスタンスをデクラスターする場合、そのインスタンス所有パーティションから
DB2MSCS ユーティリティーを実行するようにしてください。インスタンスが部分デクラ
スターされるだけならば、本書の付録 C に解説した手動ステップを使用して、処理を続け
てください。
15. Q. オンライン前、オンライン後、オフライン前、オフライン後のスクリプト内のコマンド
が、認証エラーで失敗します。
A. これらのスクリプトは、Cluster Server サービスの所有者の下で実行されます。Cluster
Server の所有者がそのコマンドの実行に十分な特権を持っていることを確認してくださ
い。
注意：DB2MSCS ユーティリティーの実行トレースは、次のコマンドを実行することによって
起動できます。
db2mscs -f:db2mscs.cfg.ese -d:trace.out
問題判別の支援を IBM サポートから受ける場合、このトレースが役に立ちます。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
57
付録 C – インスタンスのデクラスタリング
管理サーバーまたはインスタンスをクラスタリングする必要がなくなった場合、DB2MSCS ユ
ーティリティーを使用するか手作業で、デクラスタリングできます。次に示す例で、相互テイ
クオーバー複数パーティション構成のデクラスタリング方法を説明します。
DB2MSCS を使用してインスタンスをデクラスターする
1.
インスタンス DB2MPP 内に存在するデータベースをバックアップします。DB2 ドライ
ブ・マッピングが使用された場合や、異なるドライブにデータベースを配置する必要のあ
る場合、データベースをドロップします。
2.
DB2MSCS ユーティリティーが実行された後、すべての DB2 グループを、それらが元々
あったマシン上に配置します。
3.
インスタンス所有パーティションから、DB2MSCS ユーティリティーを–u オプションを
付けて実行します。管理サーバーは ESE インスタンスよりも前にデクラスタリングされる
必要があります。
db2mscs –u:db2das00
db2mscs –u:db2mpp
4.
バックアップされたデータベースをリストアします。
手動でインスタンスをデクラスタリングする
1.
インスタンス DB2MPP 内に存在するデータベースをバックアップし、データベースをド
ロップします。
2.
Cluster Administrator で、DB2 リソースだけをオフラインにし、
ディスクや IP アドレス、
ネットワーク名、ファイル共用はオンラインのままにしておきます。
3.
クラスター内の 1 台のマシンから、管理サーバーと DB2MPP インスタンスをドロップし
ます。こうすると、これらは全マシンからドロップされます。
db2admin drop
db2idrop db2mpp
ヒント：インスタンスをドロップすると、すべてのインスタンス情報が失われます。将来
必要となるかもしれないインスタンス情報があれば (データベース・マネージャー構成パ
ラメーターや DB2 プロファイル変数設定値など)、保存しておくようにしてください。
db2 get admin cfg>admincfg.out
db2 get dbm cfg > db2cfg.out
db2set -all > db2set.out
4.
Cluster Administrator から、各 DB2 パーティションおよび管理サーバーに対応する DB2
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
58
リソース、さらには対応する IP アドレスやネットワーク名、ファイル共用もドロップしま
す。すべての物理ディスク・リソースをそれらの初期グループに戻します。各パーティシ
ョンに関連付けられたグループ内にはリソースは存在しないので、それらグループをドロ
ップします。
5.
MSCS クラスター用に構成されている DB2 インスタンスが他にない場合、DB2 リソース・
タイプをドロップできます。次のコマンドは、クラスター内の 1 台のマシンから実行する
だけで構いません。
db2wolfi u
6.
管理サーバーと DB2MPP インスタンスを再作成します。
7.
新規インスタンスにデータベースをリストアし、構成パラメーターを必要に応じて再構成
します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
59
付録 D – DB2MSCS ユーティリティーで実施されるステップを手動で
実行する
以下の例では、DB2MPP インスタンスを、本書の「相互テイクオーバーの複数パーティション
構成」のセクションで構成したのとまったく同じに、手動で構成する方法を示します。
DB2MSCS ユーティリティーの使用を推奨しますが、手順を 1 つ 1 つ押さえておくと、
DB2MSCS ユーティリティー実行中にエラーが発生した場合に問題判別に役立ちます。
1.
まず最初に、MSCS および DB2 UDB ESE が全マシン上にインストールされます。
2.
DB2MPP というインスタンスが存在しない場合、新たに作成します。
db2icrt DB2MPP -s ese -P ¥¥wa9¥c$¥sqllib -u mydom¥db2admin,xxx -h wa9 r 60000,60003
db2ncrt /n:1 /u:mydom¥db2admin,xxx /i:db2mpp /h:wa10 /m:wa10 /p:0 /o:wa9
C:¥>db2nlist /s
List of nodes for instance "DB2MPP" is as follows:
Node: "0" Host: "wa9" Machine: "wa9" Port: "0" - "stopped"
Node: "1" Host: "wa10" Machine: "wa10" Port: "0" - "stopped"
3.
インスタンスが稼動中であれば、DB2STOP コマンドでインスタンス DB2MPP を停止し
ます。
4.
DB2 リソース・タイプを WA9 からインストールします。
c:>db2wolfi i
ok
db2wolfi コマンドの実行結果が「Error : 183」になった場合、すでにインストールされ
ていることを意味します。リソース・タイプをドロップしてから再び追加すると、確認で
きます。また、リソース・タイプは、存在しない場合は Cluster Administrator には表示
されません。
c:>db2wolfi u
ok
c:>db2wolfi i
ok
5.
Cluster Administrator から、「DB2 Group 0」および「DB2 Group 1」という新規グル
ープを 2 つ作成し、これらグループをそれぞれ WA9 および WA10 へ移動します。優先所
有者は、グループが現時点で存在するマシンに設定する必要があります。
6.
Cluster Administrator から「Change Group」を実行して、ディスク F と G をそれぞれ
「DB2 Group 0」と「DB2 Group 1」に移動します。
注意： Change Group コマンドが機能するには、2 つのグループが同一マシン上になけれ
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
60
ばなりません。
7.
「DB2 Group 0」については、Cluster Administrator からパブリック・ネットワーク上
に存在する IP アドレス・タイプのリソース・タイプを新たに作成します。これは高可用
IP アドレスで、ネットワーク上に対応するマシンがあってはいけません。この例では、
「相
互テイクオーバーの複数パーティション構成」のセクションで定義したとおり、mscs11
を使用します。IP アドレス・リソースをオンラインにして、そのアドレスをリモート・マ
シンから ping できることを確認します。
8.
Cluster Administrator から、各 DB2 グループ用にプライベート・ネットワーク上に高可
用 TCP/IP アドレスを作成します。作成するアドレスを、ether0 および ether1 と呼ぶこ
とにします。
9.
ステップ 8 で作成された新しい TCP/IP アドレスを、対応するパーティションに割り当て
ます。
C:¥>db2nchg /n:0 /g:10.1.1.1
C:¥>db2nchg /n:1 /g:10.1.1.2
10. Cluster Administrator から、「DB2 Group 0」にネットワーク名を作成します。IP アド
レス ether0 に従属するネットワーク名 mynetname を作成し、このリソースをオンライン
にします。
11. 次のステップでは、ファイル共用を作成します。まず、ディスク F に db2profs というサ
ブディレクトリーを作成します。Cluser Administrator から、mynetname とディスク F
に従属する DB2MSCS-DB2MPP というファイル共用を作成します。ファイル共用のパス
の入力を求める応答に対して、f:¥db2profs を指定します。Cluster Administrator から
ファイル共用をオンラインにします。
12. ファイル共用がアクセス可能かどうか確かめます。
dir ¥¥mynetname¥db2mscs-db2mpp
13. タイプ DB2 の各 DB2 パーティションに対応する DB2 リソースを作成します。使用され
るインスタンスは DB2MPP なので、リソースは各 DB2 パーティションに対応して、それ
ぞれ DB2MPP-0 および DB2MPP-1 という名前にする必要があります。これら DB2 リソ
ースをそれぞれ「DB2 Group 0」と「DB2 Group 1」に作成します。作成した各 DB2 リ
ソースは、同一グループ内の他のすべてのリソースに従属する必要があります。まだ新し
い DB2 リソースをオンラインにしないでください。
14. WA9 から、db2iclus コマンドを使用して、DB2 インスタンスをクラスター・インスタ
ンスへトランスフォームします。これにより、新たに作成されたファイル共用にインスタ
ンス・ディレクトリーが配置されます。
C:¥>db2iclus migrate /i:db2mpp /c:mycluster /m:wa9
/p:¥¥mynetname¥db2mscs-db2mpp
15. WA9 から、db2iclus コマンドを使用して、残りのクラスター・マシンを DB2 クラスタ
ー・リストへ追加します。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
61
C:¥> db2iclus add /i:db2mpp /c:mycluster /m:wa10
/u:mydom¥db2admin,xxx
16. 「f」ドライブにデータベースを作成できるように、DB2 ドライブ・マッピングを実施し
ます。
C:¥>db2drvmp add 1 f g
17. 必要であれば、Cluster Administrator を介して DB2 グループをフェイルバック用に構成
し、次のコマンドを発行します。
C:¥>db2set DB2_FALLBACK=YES
18. Cluster Administrator 経由で、すべての DB2 リソースをオンラインにします。
19. すべてのデータベースを作成またはリストアし、全データを共用ドライブに置きます。
20. フェイルオーバー構成をテストします。
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
62
付録 E – サンプル・アプリケーション・プログラム
サンプル・プログラムから抜粋した次のコードは、接続失敗時にデータベースへの接続をアプ
リケーションに再試行させる方法、および特定のエラー・コードに基づいて SQL ステートメン
トを再試行させる方法を示しています。
int CSampleODBCObj::ExecuteSQLWithRetry(char * stmt)
{
int rc = 0;
int retry = 0;
do {
retry = 0;
rc = ExecuteSQL( stmt );
if (rc != 0)
{
if((strcmp( (char *)&(m_sqlstate[0]),"40003" ) == 0) ||
(strcmp( (char *)&(m_sqlstate[0]),"08003" ) == 0) ||
(strcmp( (char *)&(m_sqlstate[0]),"08007" ) == 0) ||
(strcmp( (char *)&(m_sqlstate[0]),"08S01" ) == 0))
{
Disconnect();
while (bContinue && (Connect() != 0))
Sleep(1000);
retry = 1;
}
else if (strcmp( (char *)&(m_sqlstate[0]),"40504" ) == 0)
{
// Just retry the transaction without reconnect
retry = 1;
}
}
} while ( bContinue && retry ); /* enddo */
return rc;
}
Microsoft Cluster Server を使用した IBM DB2 UDB ESE V8.1 の実装
63