シナリオ: Db2 pureScale 環境での HADR のデプロイ

背景

計画

優先再生メンバー

すべての 1 次側のメンバーで生成されたログの再生は、スタンバイ側の 1 つのメンバーだけが一貫して行います。 したがって、EFE の DBA は、1 次クラスターとスタンバイ・クラスターのどのメンバー・ホストが最大のメモリーおよび CPU リソースを持つかを判別し、それらのメンバーを優先再生メンバーとして指定します。 1 次側でもこの計画を行わなければならない理由は、1 次データベースで障害が発生して、そのデータベースがスタンバイとして再統合された場合、指定されたメンバーがすべての再生を実行することになるためです。 これに該当するのは、1 次側では p0、スタンバイ側では s0 です。いずれの場合も、メンバー 0 はホストの常駐メンバーです。

同期モード

EFE の DBA は、同期モードを ASYNC (デフォルト)、SYNC、NEARSYNC、および SUPERASYNC のどれにするかを選択する必要があります。 そのために、DBA は WAN を分析し、ネットワーク・スループットが 300 メガビット/秒であること、そして往復時間が 80 ミリ秒であることを判別します。次に、DBA はロギング・レートを測定します。クラスター・レベルでのロギング・レートは 20 MB/秒であると測定されました。 ネットワーク・スループットは、このロギング・レートをサポートするには十分であり、ピーク時のロギング・レートを 37 MB/秒に達するまで許容するため、ASYNC が適切なモードということになります。 スループットがロギング・レートに近い場合には、SUPERASYNC のほうが適切な選択になります。SUPERASYNC では、トランザクションのピーク期間中に、1 次がスタンバイのかなり先に進むことができるためです。

スケーリングに関する考慮事項

EFE は、一年のピーク期間中に一時メンバーを追加する傾向があります。メンバー・トポロジーは HADR ペアの間で共通していなければならないため、EFE はスタンバイをスケールアウトする方法を決定しなければなりません。 EFE が新しいホストで新規メンバーを追加することにより 1 次クラスターを大きくすることを決定した場合、EFE は既存のホストに新規メンバーを追加することによるスタンバイ・クラスターでの追加コストを回避できます。 この場合、スタンバイが新しい 1 次としてテークオーバーすると、データベースの処理能力が低下する結果となりますが、このコスト節約は、潜在的な不利に値するものです。

HADR の構成

HADR の開始

select LOG_STREAM_ID, PRIMARY_MEMBER, STANDBY_MEMBER, HADR_STATE
from table (mon_get_hadr(-2))

  LOG_STREAM_ID PRIMARY_MEMBER STANDBY_MEMBER HADR_STATE            
  ------------- -------------- -------------- -----------------------
  0             0              0              PEER
  1             1              0              PEER
  2             2              0              PEER
  3             3              0              PEER

役割の切り替え

DBA は、役割の切り替えを実行する必要があります。 つまり、現在のスタンバイ側が 1 次の役割をテークオーバーし、現在の 1 次側がスタンバイの役割をテークオーバーするということです。 これにより、サイト A でクラスターのシャットダウンを必要とする一部の保守が可能になります。 この手順は、データベースに現在接続されているアプリケーションへの影響を最小限に抑えるために、使用量が少ない時間に行われます。

1. DBA は、1 次側のいずれのメンバーも異常な状態でないことを確認します。

   SELECT ID,  
          varchar(STATE,21) AS STATE, 
          varchar(HOME_HOST,10) AS HOME_HOST, 
          varchar(CURRENT_HOST,10) AS CUR_HOST, 
          ALERT 
   FROM SYSIBMADM.DB2_MEMBER
   
   ID     STATE                 HOME_HOST  CUR_HOST   ALERT
   ------ --------------------- ---------- ---------- --------
   0      STARTED               p0         p0         NO
   1      STARTED               p1         p1         NO
   2      STARTED               p2         p2         NO
   3      STARTED               p3         p3         NO
   
     4 record(s) selected.

2. DBA は、すべてのログ・ストリームがピア状態であることを確認します。

   select LOG_STREAM_ID, PRIMARY_MEMBER, STANDBY_MEMBER, HADR_STATE
   from table (mon_get_hadr(-2))
   
     LOG_STREAM_ID PRIMARY_MEMBER STANDBY_MEMBER HADR_STATE            
     ------------- -------------- -------------- -----------------------
     0             0              0              PEER
     1             1              0              PEER
     2             2              0              PEER
     3             3              0              PEER

3. サイト B で、DBA がメンバー 0 に対して TAKEOVER HADR コマンドを実行します。

   TAKEOVER HADR ON DB hadr_db

   このコマンドが完了すると、新しいスタンバイ側のメンバー 0 (優先再生メンバー) が再生メンバーとして選択され、スタンバイ・クラスターの他のメンバーでは、データベースがシャットダウンします。 新しい 1 次側では、データベースはメンバー 0 でのみ活動化されます。 他のメンバーは、クライアント接続によって活動化されるか、DBA がそれぞれのメンバーに対して明示的に ACTIVATE DATABASE コマンドを実行した場合に活動化されます。 自動クライアント・リルートは、すべての新規クライアントをサイト B に送信します。
4. サイト A で、DBA はスタンバイ側のデータベースを非活動化します (これにより、このデータベースは HADR スタンバイとしての役割を保持します)。

   DEACTIVATE DATABASE hadr_db

5. サイト A で、DBA がスタンバイ側の Db2 を停止します。

   db2stop

6. サイト A で、DBA が必要な保守を行います。
7. サイト A で、DBA がスタンバイ側で Db2 を開始します。

   db2start

8. サイト A で、DBA がスタンバイ側のデータベースを活動化します。

   ACTIVATE DATABASE hadr_db

   データベースは、再生メンバーを 1 つ持つ HADR 1 次データベースとして活動化されます。
9. 元のセットアップに戻すには、DBA はサイト A のメンバー 0 に対して TAKEOVER HADR コマンドを発行します。

   TAKEOVER HADR ON DB hadr_db

フェイルオーバー

DBA は、フェイルオーバーを実行する必要があります。 つまり、サイト A で予期しない障害が発生した場合は、サイト B のスタンバイ・データベースが、1 次データベースの役割をテークオーバーしなければなりません。 Db2 pureScale 環境での HADR の重要な違いは、フェイルオーバーを自動化するための IBM® Tivoli® System Automation for Multiplatforms (SA MP) の使用がサポートされていないことです ( Db2 pureScale クラスターでの高可用性を確保するために既に使用されています)。 いずれにしても、このシナリオでは、DBA は、障害に対するこの種の応答についての手動制御を必要とします。

1. DBA は、サイト B のスタンバイ・データベースから強制テークオーバーを実行します。

   TAKEOVER HADR ON DB hadr_db BY FORCE

   スタンバイ・データベースは、無効化メッセージを送信して 1 次データベースをシャットダウンします。 ログ・シッピングおよびログ取り出しを停止した後、スタンバイ・データベースはそのログ・パスにあるすべてのログの再生を実行します。 最後に、スタンバイ・データベースが新しい 1 次データベースになります。
2. DBA は、新しい 1 次データベースに対して db2pd コマンドを実行して、このデータベースが 1 次の役割をテークオーバーしたことを確認します。

   db2pd -hadr -db hadr_db

3. DBA は、障害の原因に対処してサイト A を稼働中にした後に、古い 1 次データベースをスタンバイとして再統合しようと試みます。

   START HADR ON DB hadr_db AS STANDBY

4. DBA は、HADR_CONNECT_STATUS フィールドおよび HADR_STATE フィールドをチェックして、データベースが接続されていること、およびデータベースがピア状態またはリモート・キャッチアップ状態になっていることを確認することにより、サイト A がスタンバイになったことを検証します。

   db2pd -hadr -db hadr_db

   2 つのサイトでのデータベースのログ・ストリームは分岐しているため、データベースは切断済みとして示されます。 DBA が、古い 1 次のいずれかのメンバーの diag.log ファイルを調べると、そこに、サイト A のデータベースを新しい 1 次データベースと整合させることができないというメッセージが示されています。
5. DBA は、データベースをドロップし、それをサイト A の HADR スタンバイ・データベースとして再初期化する必要があります。
   1. データベースをドロップします。

      DROP DATABASE DB hadr_db

   2. サイト B でデータベースのバックアップを取ります。

      BACKUP DATABASE DB hadr_db ONLINE TO backup_dir

   3. バックアップ・イメージをサイト A にリストアします。

      db2 RESTORE DB hadr_db FROM backup_dir

   4. サイト A のデータベースに、クラスター・レベルとメンバー・レベルの構成パラメーターを設定します。

      db2 "UPDATE DB CFG FOR hadr_db USING
           HADR_TARGET_LIST  {s0:4000|s1:4000|s2:4000|s3:4000}
           HADR_REMOTE_HOST  {s0:4000|s1:4000|s2:4000|s3:4000}
           HADR_REMOTE_INST  db2inst
           HADR_SYNCMODE     async"

      • メンバー 0 の場合:

        db2 "UPDATE DB CFG FOR hadr_db MEMBER 0 USING
             HADR_LOCAL_HOST   p0
             HADR_LOCAL_SVC    4000"

      • メンバー 1 の場合:

        db2 "UPDATE DB CFG FOR hadr_db MEMBER 1 USING
             HADR_LOCAL_HOST   p1
             HADR_LOCAL_SVC    4000"

      • メンバー 2 の場合:

        db2 "UPDATE DB CFG FOR hadr_db MEMBER 2 USING
             HADR_LOCAL_HOST   p2
             HADR_LOCAL_SVC    4000"

      • メンバー 3 の場合:

        db2 "UPDATE DB CFG FOR hadr_db MEMBER 3 USING
             HADR_LOCAL_HOST   p3
             HADR_LOCAL_SVC    4000"

6. DBA は、メンバー 0 を優先再生メンバーとして指定することを決定し、サイト A のメンバー 0 から START HADR コマンドを実行します。

   db2 START HADR ON DB hadr_db AS STANDBY

7. DBA は、サイト A がスタンバイになったことを検証するために、HADR_CONNECT_STATUS および HADR_STATE フィールドをチェックして、データベースが接続されていること、および 1 次にキャッチアップしていることを確認します。

   db2pd -hadr -db hadr_db

8. DBA は、前のセクションで説明した役割の切り替えを実行することで、元のセットアップに戻すことができます。