管理の手引き


DB2 に関する考慮事項

このセクションでは、 以下のトピックについて説明します。

HA インスタンスに接続するアプリケーション

高可用性 DB2 インスタンスに依存するアプリケーションは、 フェールオーバー時に再接続が可能でなければなりません。 論理ホストのホスト名および IP アドレスは同じままなので、 別のホスト名に接続したり、 データベースを再カタログする必要はありません。

2 つのマシンと 1 つの DB2 ユニバーサル・データベース エンタープライズ・エディションのインスタンスを持つクラスターを考慮してみましょう。 EE インスタンスは通常、 クラスター内のマシンの 1 つに常駐します。 HA インスタンスのクライアントは、 HA インスタンスに関連した論理ホストの論理 IP アドレス (またはホスト名) に接続します。

HA クライアントによれば、 2 つのタイプのフェールオーバーがあります。 1 つのタイプは、 HA インスタンスをホストしているマシンがクラッシュしたときに起こります。 別のタイプは、 HA インスタンスを正常にシャットダウンする機会が与えられたときに起こります。

マシンがクラッシュして HA インスタンスをダウンした場合、 データベースへの既存の接続および新規の接続は両方ともハングします。 接続がハングするのは、 ネットワーク上に、 クライアントがデータベースに使用していた IP アドレスを持つマシンがないためです。 データベースが正常にシャットダウンされると、 db2stop force はデータベースへの既存の接続を中断し、 エラー・メッセージが戻されます。

フェールオーバー時に、 データベースに関連した論理 IP アドレスはオフラインになります。 これは、SC2.2 ソフトウェアによってオフラインにされたためか、 または論理ホストをホストしていたマシンがクラッシュしたためです。 このとき、 データベースへの新規の接続は、少しの間ハングします。

データベースに関連した論理 IP アドレスは、 最終的に、DB2 が開始される前に別のマシンに移動されます。 この段階では、データベースへの接続はハングしませんが、 通信エラーを受け取ります。 これは、DB2 がまだシステム上で開始されていないためです。 データベースに接続されていた DB2 クライアントも、 通信エラーを受け取り始めます。 クライアントはまだ接続状態にあると考えますが、 論理 IP アドレスをホストし始めたマシンは、 既存の接続を識別しません。 接続は単純にリセットされ、 DB2 クライアントは通信エラーを受け取ります。 少しした後、DB2 はマシン上で開始され、 DB2 への接続が正常に確立されます。 この時点で、データベースが不整合になり、 クライアントはそれが回復するのを待たなければならない場合があります。

HA 環境用のアプリケーションを設計する際、 データベース接続がハングする場合のために特別なコードを書く必要はありません。 接続は、 Sun Cluster ソフトウェアが論理 IP アドレスを移動させる少しの間だけハングします。 Sun Cluster 上で実行されるどのデータ・サービスにも、 この段階で同様のハング接続があります。 どのようにデータベースがダウンするかに関係なく、 クライアントはエラー・メッセージを受け取り、 正常に行われるまで再接続を試行しなければなりません。 クライアントから見ると、 HA インスタンスがダウンしてから同じマシンに戻されたように見えます。 制御されるフェールオーバーでは、 クライアントには、強制的に切断されて、 後に同じマシンでデータベースへの再接続が可能であるように見えます。 制御されないフェールオーバーでは、 クライアントには、データベース・サーバーがクラッシュしてから、 すぐに同じマシンに戻されたように見えます。

EE および EEE インスタンスのディスクのレイアウト

DB2 は、必要とするディスク装置またはファイル・システムが、 クラスター内の各マシン上で同じように見えることを予期します。 これを確実にするためには、 必要なディスクまたはファイル・システムを、 HA インスタンスに関連した論理ホストに従い、 クラスター内の各マシンで同じパス名になるように構成する必要があります。

DMS および SMS 表スペースの両方とも、 HA 環境でサポートされています。 DMS 表スペースの装置コンテナーでは、 ボリューム・マネージャーにより作成された生装置を使用する必要があります。 これらの装置は、ミラーリングされているか、 または RAID 構成になっています。 /dev/rdsk/c20t0d0s0 のような正規のディスク装置は、以下の理由から、 使用すべきではありません。

DB2 がこの状況でフェールオーバーされると、 必要なディスク装置は別のマシンの場合と同じように見えず、DB2 は始動しません。 DMS 表スペースのファイル・コンテナー、 および SMS 表スペースのファイル・コンテナーは、 マウントされたファイル・システムに常駐する必要があります。 論理ホストのファイル・システムは、 論理ホストの vfstab ファイルに組み込まれていると、 自動的にマウントされます。

論理ホストの vfstab ファイルは以下のパスにあります。

   /etc/opt/SUNWcluster/conf/hanfs/vfstab.<logical_host>

logical_host は、 vfstab ファイルに関連した論理ホストの名前です。

各論理ホストには独自の vfstab ファイルがあり、 このファイルには、 論理ホストのディスク・グループが現行のマシンに移された後で、 HA サービスが開始される前にマウントされるファイル・システムが含まれます。 Sun Cluster ソフトウェアは、 ファイル・システムの正常性を保証するために、 fsck (ファイル・システム検査) を実行した後で適切に定義されたファイル・システムをマウントしようと試みます。 fsck が失敗すると、 ファイル・システムはマウントされず、 エラー・メッセージがログに記録されます。
注:プロセスにオープン・ファイルが含まれる場合、 または現行の作業ディレクトリーがマウント・ポイントの下にある場合、 マウントは失敗します。 これを防ぐには、 論理ホストの vfstab ファイルに含まれるマウント・ポイントの下に、 プロセスが残されていないことを確認してください。

SMS 表スペースを使用するときは、 任意の規則を EEE インスタンスのファイル・システムのレイアウトで使用することができます。 以下に示すのは、hadb2_setup ユーティリティーで使用される規則です。

   scadmin@crackle(190)# pwd
   /export/ha_home/db2eee/db2eee
   scadmin@crackle(191)# ls -l
   total 18
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0000 -> /log0/disks/db2eee/NODE0000
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0001 -> /log0/disks/db2eee/NODE0001
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0002 -> /log0/disks/db2eee/NODE0002
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0003 -> /log0/disks/db2eee/NODE0003
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0004 -> /log0/disks/db2eee/NODE0004
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0005 -> /log1/disks/db2eee/NODE0005
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0006 -> /log1/disks/db2eee/NODE0006
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0007 -> /log1/disks/db2eee/NODE0007
   lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0008 -> /log1/disks/db2eee/NODE0008
   scadmin@crackle(192)#

インスタンス所有者は db2eee で、 db2eee インスタンスのデフォルト・データベース・ディレクトリーは /export/ha_home/db2eee です。 論理ホスト log0 は、データベース区画 0、1、2、および 3 をホストしており、 論理ホスト log1 は、データベース区画 4、5、6、7、および 8 をホストしています。

各データベース区画ごとに、 対応する NODExxxx ディレクトリーがあります。 データベース区画のノード・ディレクトリーは、 関連する論理ホストのファイル・システムの下にあるディレクトリーを指しています。

パスの表記規則を選択するときは、 以下のことを確かめてください。

  1. ファイル・システムのディスクが、 それを必要とするデータベース区画を担当する論理ホストのディスク・グループにある。
  2. コンテナーを保持するファイル・システムが、 論理ホストの vfstab ファイルによってマウントされている。

EE および EEE インスタンスのホーム・ディレクトリーのレイアウト

EE インスタンスの場合、 ホーム・ディレクトリーは、 論理ホストの vfstab ファイルで定義されたファイル・システムである必要があります。 このディレクトリーは DB2 が開始される前に使用可能になり、 クラスター内で論理ホストが移動される場所に DB2 とともに移されます。 各マシンには vfstab ファイルの独自コピーがあるため、 各マシンで同じ内容になるように注意を払う必要があります。 以下に示すのは EE インスタンスのホーム・ディレクトリーの例です。

   /log0/home/db2ee

/log0 は論理ホスト log0 の論理ホスト・ファイル・システムで、 db2ee は DB2 インスタンスの名前です。 このホーム・ディレクトリーのパスは、 「db2ee」インスタンスをホストするクラスター内の各マシンにある /etc/passwd ファイルに含める必要があります。

EEE インスタンスの場合、 ホーム・ディレクトリーをセットアップする方法は 2 つあります。 ホット・スタンドバイ構成の場合、 ホーム・ディレクトリーは EE インスタンスと同じ方法でセットアップすることができます。 相互引き受け構成の場合は、 HA-NFS をホーム・ディレクトリーで使用し、 EEE インスタンスをセットアップする前に 適切に構成しなければなりません。

クラスター内のマシンのうちの 1 つは、 選択した論理ホストの dfstab ファイルを使用して、 EEE インスタンスのファイル・システムをエクスポートする必要があります。 dfstab ファイルには、 マシンが論理ホストをホストしているときに NFS を介してエクスポートされるファイル・システムが含まれています。 各マシンには dfstab ファイルの独自コピーがあるため、 各マシンで同じ内容になるように注意を払う必要があります。

HA-NFS ファイル・システムに関する情報は、 (hadb2_setup プログラムによって) hadb2tab ファイルに置かれています。 HA エージェントがインスタンスに関する情報を読み取ると、 インスタンスの HA-NFS ファイル・システムが自動的にマウントされます (hadb2tab ファイルを参照してください)。

HA-NFS ファイル・システムのマウント・ポイントは、通常、 /export/ha_home です。 クラスター内の各マシンで、 このマウント・ポイントは HA-NFS ディレクトリーをエクスポートする論理ホストから NFS マウントされます。 EEE インスタンス所有者のホーム・ディレクトリーは、 以下のディレクトリーに置かれており、呼び出されます。

   /export/ha_home/<instance>

instance は、 インスタンス所有者の名前です。

ホーム・ディレクトリーをマウントしたりアンマウントしないですむように、 各マシン上のインスタンスごとにホーム・ディレクトリーを持つこともできます。 これを行うには、 確実にホーム・ディレクトリーが各マシン上で同一になるように、 追加の管理オーバーヘッドが必要になります。 これが失敗すると、DB2 は正常に始動しないか、 また別の構成で DB2 が始動されることになります。 これは、サポートされている構成ではありません

論理ホストと DB2 UDB EEE

論理ホストは通常、1 つまたは複数のデータベース区画をホストしたり、 HA-NFS ファイル・システムをエクスポートしたりするために選択されます。 たとえば、クラスター内に 4 つのデータベース区画と 2 つのマシンがある場合、 各マシンごとに 1 つの論理ホストが存在しなければなりません (図 119)。 一方の論理ホストで 2 つのデータベース区画のホストと HA-NFS ファイル・システムのエクスポートを行い、 他方の論理ホストで残りの 2 つのデータベース区画のホストを行うことができます。

デフォルトでは、 DB2 UDB EEE インスタンスは、 そのインスタンス用に活動状態にあるデータベース区画がすでに 1 つ以上存在しているマシンに、 最大で 2 つのデータベース区画を正常に追加するのに十分のリソースを割り当てます。 たとえば、 クラスター上の単一インスタンス用に 4 つのデータベース区画がある場合は、 論理ホストごとに 1 つのデータベース区画があるか、 または 1 つの論理ホストが 3 つのデータベース区画をホストしている場合にのみ、 このことが問題となります。 どちらの場合も、 同じインスタンスのデータベース区画をすでにホストしているマシンに対して、 3 つのデータベース区画をフェールオーバーすることが可能です。

DB2_NUM_FAILOVER_NODES レジストリー変数を使用すれば、 フェールオーバーされるデータベース区画のために予約されたリソースの量を増やすことができます。

図 119. 各マシンごとに 1 つの論理ホストがある

各マシンごとに 1 つの論理ホストがある

DB2 のインストール場所およびオプション

DB2 がインストールされるファイル・システムは、ミラーリングされているか、 または少なくとも RAID 構成にある必要があります。 DB2 が通常のディスクにインストールされていると、 ディスク障害は起こりやすくなります。 その結果起こるフェールオーバーは防止可能なものとみなされるため、 クラスターの安定度は減少します。

DB2 は、論理ホストのディスク・グループにあるディスクにはインストールできません。 これは、HA エージェントが常に、DB2 ライブラリーへのアクセスを必要とするからです。 DB2 ライブラリーにアクセスできないと、HA エージェントには障害が起こります。 DB2 は通常、クラスター内の各マシンでインストールしなければなりません。

データベースおよびデータベース・マネージャー構成パラメーター

データベース・マネージャー構成パラメーターは、フェールオーバーの後、 DB2 が始動される前に、 pre_db2start スクリプトを使用して変更することができます (ユーザー・スクリプトを参照)。 この実行可能スクリプトは、 (存在する場合に) インスタンス所有者のホーム・ディレクトリーの sqllib/ha ディレクトリーの下で実行されます。 名前から分かるように、 これは db2start の直前に実行されます。 インスタンスが EEE インスタンスでない限り、 pre_db2start スクリプトには、 制御メソッドに渡されたのと同じ引き数が渡されます。 EEE インスタンスの場合は、 pre_db2start スクリプトにも、 db2start コマンドのノード番号が渡されます。

破損回復

HA 環境での破損回復は、 通常の環境での破損回復と同じです。 HA インスタンスが、クラッシュしたマシンとは別のマシンで再開されたとしても、 インスタンスのファイルおよびディスク装置は同じように見え、 データベースを回復するのに必要なアクションも異なりません。 破損回復や他の形式のデータベース回復についての詳細は、 第 19 章, データベースの回復 を参照してください。

データベースは手作業で (または、ユーザー・スクリプトの 1 つによって) 再始動できますが、 特に EEE インスタンスの場合には、 autorestart データベース構成パラメーターを ON に設定するようお勧めします。 これにより、 データベースが不整合の状態になる時間を最小限にとどめることができます。

データ複製による高可用性

データの可用性は、複製によっても強化することができます。 2 つのサーバー間でデータを複写することにより、 1 つの形式の高可用性が実現します。 サーバーの 1 つがダウンすると、 別のサーバーがそれを引き継ぎ、データ・サービスを提供し続けることができます。

ただし、 複製は非同期に行われるので、 サーバーがダウンしたときに一部の変更内容が別のサーバーに伝えられない場合もあります。


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