管理の手引き


クラスター構成

ホット・スタンドバイ 構成では、 引き受けノードではない AIX プロセッサー・ノードは他の作業負荷を一切実行していません相互引き受け 構成では、 引き受けノードである AIX プロセッサー・ノードは他の作業負荷を実行しています

一般に、DB2 ユニバーサル・データベース エンタープライズ拡張エディション (UDB EEE) は、 各ノード上の区画で相互引き受けモードで実行されます。 1 つの例外として、 カタログ・ノード部品がホット・スタンドバイ構成の一部となるシナリオがあります。

HACMP ES を使用する RS/6000 SP で大規模な DB2 インストールを計画する場合は、 RS/6000 SP フレームの内部またはフレーム間でクラスターのノードを分割する方法を考慮する必要があります。 異なる SP フレームにノードおよびそのバックアップを指定すると、 1 つのフレームがダウン (つまり、 フレームの電源 / スイッチ・ボードが故障) するという事象でも引き受けが可能です。 しかし、こうした故障は非常にまれだと考えられます。 各 SP フレームには N+1 の電源機構があり、 各 SP スイッチには N+1 のファンと電源を含む冗長パスがあるからです。 フレームが故障すると、手作業で介入して、 残りのフレームを回復しなければならない場合があります。 この回復手順については、SP 管理の手引きで説明されています。 HACMP ES では、SP ノード障害を回復できます。 その場合、フレーム障害の回復は、 1 つまたは複数の SP フレーム内のクラスターの適正なレイアウトに依存しています。

計画時に考慮すべき別の点として、 大きなクラスターの管理方法があります。 大きなクラスターよりも小さなクラスターのほうが管理は容易ですが、 多くの小さなクラスターよりも 1 つの大きなクラスターのほうが管理はやはり容易です。 計画時には、実際のアプリケーションがクラスター環境で使用される方法を考慮してください。 たとえば、16 ノードで単一の大きな同類のアプリケーションが実行されていれば、 構成を 8 個の 2 ノード・クラスターではなく、 単一のクラスターとして管理するほうが容易でしょう。 同じ 16 ノードでも、異なるネットワーク、ディスク、 およびノード関係を持つ多数の異なるアプリケーションが含まれているのであれば、 ノードを小さめのクラスターにグループ化したほうが得策と思われます。 各ノードは一度に 1 つずつ HACMP クラスターに統合される点に留意してください。 つまり、1 つの大きなクラスターよりも複数のクラスター構成のほうが始動速度は向上します。 HACMP ES は、ノードおよびそのバックアップが同じクラスターにある限り、 単一のクラスターも複数のクラスターもサポートします。

HACMP ES フェールオーバー回復では、 物理ノードにリソース・グループを事前定義 (カスケード ともいう) によって割り当てることができます。 フェールオーバーの回復手順では、 物理ノードにリソース・グループを浮動 (回転 ともいう) によって割り当てることもできます。 IP アドレス、外部ディスク・ボリューム・グループ、ファイル・システム、 NFS ファイル・システム、および各リソース・グループ内のアプリケーション・サーバーは、 アプリケーションまたはアプリケーション構成要素のいずれかを指定します。 これは、フェールオーバーまたは再統合によって、物理ノード間で HACMP ES が操作するものです。 フェールオーバーおよび再統合の操作は、作成されるリソース・グループのタイプ、 およびリソース・グループに配置されるノード数によって指定されます。

たとえば、DB2 データベース区画 (論理ノード) を考慮してみます。 そのログと表スペースのコンテナーが外部ディスクに置かれ、 他のノードがそのディスクにリンクされていた場合、 それら他のノードは外部ディスクにアクセスし、 (引き受けノード上にある) データベース区画を再始動することができます。 HACMP では、このような操作が自動化されます。 HACMP ES は、 DB2 インスタンスの主要なユーザー・ディレクトリーが使用する NFS ファイル・システムを回復する場合にも使用できます。

DB2 UDB EEE の回復を計画する場合には、 その一環として HACMP ES 資料を精読してください。 概念、計画、インストール、管理の手引きに目を通した後、 環境に合った回復アーキテクチャーを構築してください。 知られている障害点に基づいて識別した、回復を要する各サブシステムについては、 必要な HACMP クラスターと回復ノード (ホット・スタンドバイまたは相互引き受け) を識別してください。 これは、 資料にある HACMP ワークシートを完成させる上で開始点となります。

ディスクとアダプターはどちらも、 外部ディスク構成でミラーリングすることをぜひお勧めします。 HACMP 用に構成する DB2 物理ノードの場合、 ボリューム・グループ上のノードを共用外部ディスクから 構成変更できるように配慮する必要があります。 相互引き受け構成でこのような設定を行う場合、 対になったノードが競合することなく互いのボリューム・グループにアクセスできるよう、 いくらか余分の計画を立てることが必要です。 DB2 UDB EEE 内では、 すべてのデータベース間でコンテナー名をすべて固有のものにしておく必要があります。

固有のものにする 1 つの方法は、 名前の一部に区分番号を含めることです。 SMS または DMS コンテナーを作成するときに、 コンテナーのストリング構文にノード式を指定できます。 式を指定するときは、 ノード番号をコンテナー名の一部とすることができます。 また、追加の引き数を指定する場合は、 これらの引き数の結果をコンテナー名の一部とすることができます。 ノード式を指定するには、 引き数 「 $N」([ブランク]$N) を使用します。 引き数は必ずコンテナー・ストリングの最後に指定するようにし、 以下のいずれかの形式だけを使用できます。

表 56. コンテナーを作成するための引き数
ノード番号を 5 と仮定します。
構文
[ブランク]$N 「 $N」 5
[ブランク]$N+[番号] 「 $N+1011」 1016
[ブランク]$N%[番号] 「 $N%3」 2
[ブランク]$N+[番号]%[番号] 「 $N+12%13」 4
[ブランク]$N%[番号]+[番号] 「 $N%3+20」 22

注:

  1. % はモジュラスです。

  2. どの場合でも、演算子は左から右に向かって評価されます。

次に、この特殊な引き数を使用してコンテナーを作成する方法の例をいくつか示します。

図 104 および 図 105 は、 DB2 SSA I/O サブシステム構成の例を示しています。 また、高可用性外部ディスク構成、および競合を起こさずに すべてのボリューム・グループにアクセスする機能の両方を実現するために必要な計画の一部を示しています。

図 104. 単一の障害点がない

単一の障害点がない

図 105. ボリューム・グループおよび論理ボリュームのセットアップ

ボリューム・グループおよび論理ボリュームのセットアップ

DB2 データベース区画の構成

構成が済むと、 インスタンス中の各データベース区画は HACMP ES によって物理ノードごとに始動されます。 4 ノードよりも大きい並列 DB2 構成を始動する場合は、 複数のクラスターをお勧めします。 64 ノードの並列 DB2 構成では、 4 個の 16 ノード・クラスターよりも、 32 個の 2 ノード HACMP クラスターのほうが始動速度が向上することに注意してください。

スクリプト・ファイル rc.db2pe は、 ホット・スタンドバイまたは相互引き受けノードのいずれかで HACMP ES のフェールオーバーまたは回復を構成するための補助機構として、 DB2 UDB EEE にパッケージされています (/usr/bin の各ノードにインストールされます)。 また、rc.db2pe の内部から、 フェールオーバーまたは相互引き受け構成で DB2 バッファー・プールのサイズをカスタマイズできます。 (バッファー・プール・サイズは、 1 つの物理ノードで 2 つのデータベース区画を稼働する場合に 適切なパフォーマンスを確保できるように構成する必要があります。)

DB2 データベース区画の HACMP 構成でアプリケーション・サーバーを作成する場合、 次のようにして rc.db2pe を開始および停止スクリプトとして指定します。

   /usr/bin/rc.db2pe <instance> <dpn> <secondary dpn> start <use switch>
   /usr/bin/rc.db2pe <instance> <dpn> <secondary dpn> stop <use switch>
 
   ここで、各パラメーターは以下のとおりです。
 
   <instance> はインスタンス名。
   <dpn> はデータベース区画番号。
   <secondary dpn> は、相互引き受け構成のみにおける
      'コンパニオン' データベース区画番号。
      ホット・スタンバイ構成では、<dpn> と同じ。
   <use switch> は通常はブランク。ブランクの場合は、
      SP switch ネットワークが db2nodes.cfg ファイルのホスト名 フィールドに使用される。
      (DB2 のためのすべてのトラフィックが SP スイッチを介して経路指定される。)
      ブランクでない場合、ここで使用する名前は、使用される SP ノードのホスト名。

このデータベース区画用に構成したすべてのデータベースを検索するには、 rc.db2pe 内から DB2 コマンド LIST DATABASE DIRECTORY を使用します。 すると、スクリプト・ファイルは、 /usr/bin/reg.parms.DATABASE ファイル、 および /usr/bin/failover.parms.DATABASE ファイルを探します。 ただし、DATABASE はこのデータベース区画用に構成された個々のデータベースを表します。 相互引き受け構成では、 パラメーター・ファイル reg.parms.xxx および failover.parms.xxx を作成することをお勧めします。 failover.parms.xxx ファイルでは、 複数のバッファー・プールがある可能性を考慮して、 BUFFPAGE、DBHEAP、 およびバッファー・プールに影響を与える他のパラメーターの設定を調整します。 サンプル・ファイル reg.parms.SAMPLE および failover.parms.SAMPLE は、 ユーザーが使用するために用意されました。

この環境で重要なパラメーターの 1 つは、 start_stop_time データベース・マネージャー構成パラメーターです。 このパラメーターの省略時値は 10 分です。 ただし、rc.db2pe を指定すると、 このパラメーターは 2 分に設定されます。 このパラメーターは rc.db2pe で調整して、 10 分か、もう少し大きめの値に設定するとよいでしょう。 このコンテキストでは、指定した時間は、 区画の障害発生からその区画の回復までの時間間隔です。 区画上で実行されているアプリケーションが頻繁に COMMIT を出す場合、 データベース区画上の障害後、10 分もあれば、 コミットされていないトランザクションをロールバックし、 その区画上のデータベースの一貫性ポイントに到達することが可能です。 作業負荷が重いか、または多くの区画がある場合、 ロールバック操作が完了する前にタイムアウトになってしまう可能性を少なくするために、 時間を増やす必要があるかもしれません。

以下は、ホット・スタンドバイ構成および相互引き受け構成の例です。 どちらの例でも、 リソース・グループにはサービス IP スイッチ別名アドレスが入っています。 このスイッチ別名アドレスは、以下の目的で使用されます。

実際の設定でこれらの別名が必要でなければ、削除しても構いません。 削除した場合は、 rc.db2pe スクリプト・ファイルで MOUNT_NFS パラメーターを NO に設定してください。

ホット・スタンドバイ構成の例

この例では、 ホット・スタンバイ構成がノード 1 とノード 2 の間にあり、 DB2 インスタンス名が POWERTP であると仮定します。 データベース区画は 1 で、 データベースはファイル・システム /database 上の TESTDATA です。

   Resource group name: db2_dp_1
   Node Relationship: cascading
   Participating nodenames: node1_eth, node2_eth
   Service_IP_label: nfs_switch_1     (<<< this is the switch alias address)
   Filesystems: /database/powertp/NODE0001
   Volume Groups: DB2vg1
   Application Servers: db2_dp1_app
   Application Server Start Script: /usr/bin/rc.db2pe powertp 1 1 start
   Application Server Stop Script: /usr/bin/rc.db2pe powertp 1 1 stop

相互引き受け構成の例

この例では、 相互引き受け構成がノード 1 とノード 2 の間にあり、 DB2 インスタンス名が POWERTP であると仮定します。 データベース区画は 1 および 2 で、 データベースはファイル・システム /database 上の TESTDATA です。

   Resource group name: db2_dp_1
   Node Relationship: cascading
   Participating nodenames: node1_eth, node2_eth
   Service_IP_label: nfs_switch_1     (<<< this is the switch alias address)
   Filesystems: /database/powertp/NODE0001
   Volume Groups: DB2vg1
   Application Servers: db2_dp1_app
   Application Server Start Script: /usr/bin/rc.db2pe powertp 1 2 start
   Application Server Stop Script: /usr/bin/rc.db2pe powertp 1 2 stop
 
   Resource group name: db2_pd_2
   Node Relationship: cascading
   Participating nodenames: node2_eth, node1_eth
   Service_IP_label: nfs_switch_2     (<<< this is the switch alias address)
   Filesystems: /database/powertp/NODE0002
   Volume Groups: DB2vg2
   Application Servers: db2_dp2_app
   Application Server Start Script: /usr/bin/rc.db2pe powertp 2 1 start
   Application Server Stop Script: /usr/bin/rc.db2pe powertp 2 1 stop

NFS サーバー・ノードの構成

また、rc.db2pe スクリプトを使用して、 DB2 並列インスタンス・ユーザー・ディレクトリーの NFS マウント・ディレクトリーが使用可能になります。 これは、 rc.db2pe スクリプト・ファイルで MOUNT_NFS パラメーターを YES に設定し、 NFS フェールオーバー・サーバーのペアを以下のように構成することによって実行できます。

NFS サーバー引き受け構成の例

この例では、 IP アドレス「nfs_server」を介してボリューム・グループ nfsvg に NFS サーバー・ファイル・システム /nfshome があることを想定しています。 DB2 インスタンス名は POWERTP で、 ホーム・ディレクトリーは /dbhome/powertp です。

   Resource group name: nfs_server
   Node Relationship: cascading
   Participating nodenames: node1_eth, node2_eth
   Service_IP_label: nfs_server     (<<< this is the switch alias address)
   Filesystems: /nfshome
   Volume Groups: nfsvg
   Application Servers: nfs_server_app
   Application Server Start Script: /usr/bin/rc.db2pe powertp NFS SERVER start
  Application Server Stop Script: /usr/bin/rc.db2pe powertp NFS SERVER stop

この例では、以下のようになります。

SP スイッチ構成時の考慮事項

HACMP ES に SP スイッチを実装する場合は、以下の事柄を考慮します。

DB2 HACMP 構成の例

次の例では、異なるフェールオーバー・サポート構成と、 障害発生時に生じる事柄を示します。

DB2 HACMP 相互引き受け構成 (図 106図 107、 および 図 108) については次のとおりです。

図 106. NFS フェールオーバーを使用した相互引き受け - 正常

NFS フェールオーバーを使用した相互引き受け - 正常

図 107. NFS フェールオーバーを使用した相互引き受け - NFS フェールオーバー

NFS フェールオーバーを使用した相互引き受け - NFS フェールオーバー

図 108. NFS フェールオーバーを使用した相互引き受け - DB2 フェールオーバー

NFS フェールオーバーを使用した相互引き受け - DB2 フェールオーバー

DB2 HACMP ホット・スタンバイ構成 (図 109および 図 110) については次のとおりです。

図 109. NFS フェールオーバーを使用したホット・スタンドバイ - 正常

NFS フェールオーバーを使用したホット・スタンドバイ - 正常

図 110. NFS フェールオーバーを使用したホット・スタンドバイ - DB2 フェールオーバー

NFS フェールオーバーを使用したホット・スタンドバイ - DB2 フェールオーバー

NFS フェールオーバー構成を使用しない DB2 HACMP 相互引き受け (図 111 および 図 112) については次のとおりです。

図 111. NFS フェールオーバーを使用しない相互引き受け - 正常

NFS フェールオーバーを使用しない相互引き受け - 正常

図 112. NFS フェールオーバーを使用しない相互引き受け - DB2 フェールオーバー

NFS フェールオーバーを使用しない相互引き受け - DB2 フェールオーバー

DB2 HACMP 始動に関する推奨事項

/etc/inittab でブート時での HACMP の始動を指定しないことをお勧めします。 HACMP は、ノードのブート後に手作業で始動してください。 この方法により、障害ノードの破壊的な保守を避けることができます。

「破壊的な保守」の例として、 ハードウェアの障害と破損が生じたノードについて考慮してみます。 フェールオーバーは HACMP により自動的に開始され、 回復は正常に完了します。 しかし、障害ノードは、修復する必要があります。 HACMP がリブート時に始動するように /etc/inittab で構成された場合、 このノードはブート完了後に再統合を試みますが、 それはこのような状況では望ましいことではありません。

「非破壊的な保守」として、 各ノードで HACMP を手作業で始動する場合を考慮してみましょう。 手作業での始動により、 他のノードに影響を与えないで障害ノードを修正し、 再統合することができます。 コントロール・ワークステーションから HACMP の始動および停止コマンドを制御するには、 ha_cmd スクリプトを使用できます。
注:はじめて DB2 インスタンスを作成するときは、 次の項目が /etc/inittab ファイルに付加されます。

   rcdb2:2:once:/etc/rc.db2 > /dev/console 2>&1 # Autostart DB2 Services
HACMP または HACMP ES が使用可能になっている場合、 HACMP 項目の前に上記の行を置き、 /etc/inittab ファイルを更新してください。 以下は、/etc/inittab ファイル内のサンプル HACMP 項目です。

   clinit:a:wait:touch /usr/sbin/cluster/.telinit # HACMP for AIX
この項目は、 /etc/inittab ファイル内の最後の項目でなければなりません。


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