高い可用性を持つ IBM Db2 データベースをAWS上に構築する

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。

従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。

注：このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。（訳注：こちらにエディションの違いの詳細があります）
この記事のステップを進めていくと、2つのアベイラビリティゾーン（AZ）にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。

事前準備のステップ

このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。

• 同一リージョンの２つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。
• VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。

最初にAmazon S3 バケットを作成し、IBM Db2インストールファイルを以下のようにしてアップロードします。このS3バケットは、この後の自動的なビルドサイクルの中でプライマリーとスタンバイの情報を交換するためにも使用されます。

1. Db2ソリューションをデプロイするのと同じAWSリージョンにS3バケットを作成します。バケットのコンフィグで追加の設定は不要です。
2. バケットの中にdb2というフォルダ（プレフィックス）を作成します。
3. IBM Db2 の90日間トライアルのLinux版(IBM Db2 – 90 Day Trial)をIBMウェブサイトからダウンロードします
4. ダウンロードしたgunzipファイルを、先ほど作成したS3バケットのdb2フォルダ以下にアップロードします。

高可用性のDb2ソリューションを構築する

ソリューションの構築はAWS CloudFormationテンプレートにより自動化されています。こちらのリンクでCloudFormationコンソールを開き、開始してください。（訳注：リンク先は自動的にアイルランドリージョンが指定されているため、必要であれば別のリージョンに切り替えてください）

本CloudFormationテンプレートはいくつかのパラメータ入力を必要とします:

• VpcId: ソリューションを構築するVPCのIDを入力します。
• Stack Name: スタックに分かりかすい名前を付けます。例：Db2-hadr
• KeyPairName: 登録済のAmazon EC2キーペア名を指定します。このキーペアでDb2のEC2インスタンスにアクセスします。
• LinuxInstanceType: ワークロードで必要とされるEC2インスタンスタイプを選択します。
• DB2VolumeSize: データベース用のAmazon EBSボリュームのサイズを指定します。
• S3Bucket: 事前に作成したS3バケット名を指定します。
• DB2Instance: デフォルトのまま利用するか、Db2インスタンス名を指定します。
• DB2Database: デフォルトのまま利用するか、Db2データベース名を指定します。
• SyncMode: 必要とするHADRの同期モードを選択します。
• SSHCidr: 適切なCIDRブロックを入力します。このCIDRブロック内にあるサーバからDb2のEC2インスタンスにSSH接続が許可されます。
• DB2ClientCidr: 適切なCIDRブロックを入力します。このCIDRブロック内にあるサーバからDb2データベースへの（Db2クライアントとしての）接続が許可されます。
• PrimaryEC2InstanceName: デフォルトのまま利用するか、プライマリEC2インスタンスの名前を入力します。
• PrimarySubnetId: プライマリEC2インスタンスが入るサブネットIDを入力します。
• SecondaryEC2InstanceName: デフォルトのまま利用するか、セカンダリEC2インスタンスの名前を入力します。
• SecondarySubnetId: セカンダリEC2インスタンスが入るサブネットIDを入力します。

パラメータを入力し終わったら、以下のように進めます:

1. Next（次へ）をクリック。
2. 次の画面で、タグ、IAMロール、もしくは追加のオプションを選択し、Next（次へ）をクリック。
3. 最終画面で内容を確認し、Create（作成）ボタンでソリューションの構築を開始します。

このソリューションではEC2インスタンスのブートストラップ（初期構築）にユーザデータを使用しています。より詳細な情報を得るには、CloudFormationテンプレートのuser dataセクションを確認してください。ビルドの進捗を確認するには、それぞれのEC2インスタンスにSSHでログインし、以下のコマンドを実行してください。:  tail –f /var/log/cloud-init-output.log

Db2クラスターの詳細を確認する
CloudFormationテンプレートに記載されたブートストラップシーケンスが完了すると、クラスターの詳細を３つのIBMのコマンドを利用することで確認できます: lssam, lsrpnodeおよび db2pdです。

HADRの設定は、プライマリー、スタンバイそれぞれのインスタンスでrootユーザにて以下のコマンドを実行することで確認できます（以下のtestdbの部分はご自身が指定された名前に変更して実行してください）。

su - db2inst1 -c "db2pd -hadr -db testdb"

それぞれのインスタンスでこのような結果が得られるはずです。

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS = TCP_PROTOCOL
                  PRIMARY_MEMBER_HOST = ip-10-240-16-50
                     PRIMARY_INSTANCE = Db2inst1
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = ip-10-240-17-180
                     STANDBY_INSTANCE = Db2inst1
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/06/2017 15:31:15.222197 (1512574275)
          HEARTBEAT_INTERVAL(seconds) = 15
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 26
                HADR_TIMEOUT(seconds) = 60
        TIME_SINCE_LAST_RECV(seconds) = 3
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000460
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.056
                  LOG_HADR_WAIT_COUNT = 121
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 332800
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 236184
            PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 64, 45099263
            STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 64, 45099263
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 64, 45099263
       STANDBY_RECV_REPLAY_GAP(bytes) = 1220384
                     PRIMARY_LOG_TIME = 12/06/2017 15:34:17.000000 (1512574457)
                     STANDBY_LOG_TIME = 12/06/2017 15:34:17.000000 (1512574457)
              STANDBY_REPLAY_LOG_TIME = 12/06/2017 15:34:17.000000 (1512574457)
         STANDBY_RECV_BUF_SIZE(pages) = 4300
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 25600
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 120
                      PEER_WINDOW_END = 12/06/2017 15:39:47.000000 (1512574787)
             READS_ON_STANDBY_ENABLED = N

この出力結果のうち以下に注目してください:

• HADR_ROLE: このパラメータはインスタンスがプライマリノードかスタンバイ（セカンダリ）かを表示します。
• HADR_STATE: このパラメータは PEER と表示されるはずです。
• HADR_CONNECT_STATUS: このパラメータは CONNECTEDと表示されるはずです。

プライマリ、もしくはスタンバイインスタンスでrootユーザで lsrpnode コマンドを使用することでTSAクラスターの状態を得ることができます。以下のような結果が得られるはずです。これはそれぞれのノードでのRSCT(IBM Reliable Scalable Cluster Technorogy) のバージョンを示しています。

Name             OpState RSCTVersion 
ip-10-240-17-180 Online  3.2.1.2     
ip-10-240-16-50  Online  3.2.1.2 

lssam コマンドをプライマリーインスタンスでrootで実行することでTSAクラスターリソースの確認が可能です。以下のような表示が得られるはずです。

Online IBM.ResourceGroup:Db2_Db2inst1_Db2inst1_TESTDB-rg Nominal=Online
        '- Online IBM.Application:Db2_Db2inst1_Db2inst1_TESTDB-rs |- Online IBM.Application:Db2_Db2inst1_Db2inst1_TESTDB-rs:ip-10-240-16-50 '- Offline IBM.Application:Db2_Db2inst1_Db2inst1_TESTDB-rs:ip-10-240-17-180
Online IBM.ResourceGroup:Db2_Db2inst1_ip-10-240-16-50_0-rg Nominal=Online
        '- Online IBM.Application:Db2_Db2inst1_ip-10-240-16-50_0-rs '- Online IBM.Application:Db2_Db2inst1_ip-10-240-16-50_0-rs:ip-10-240-16-50
Online IBM.ResourceGroup:Db2_Db2inst1_ip-10-240-17-180_0-rg Nominal=Online
        '- Online IBM.Application:Db2_Db2inst1_ip-10-240-17-180_0-rs '- Online IBM.Application:Db2_Db2inst1_ip-10-240-17-180_0-rs:ip-10-240-17-180
Online IBM.Equivalency:Db2_Db2inst1_Db2inst1_TESTDB-rg_group-equ
        |- Online IBM.PeerNode:ip-10-240-16-50:ip-10-240-16-50
        '- Online IBM.PeerNode:ip-10-240-17-180:ip-10-240-17-180 Online IBM.Equivalency:Db2_Db2inst1_ip-10-240-16-50_0-rg_group-equ '- Online IBM.PeerNode:ip-10-240-16-50:ip-10-240-16-50
Online IBM.Equivalency:Db2_Db2inst1_ip-10-240-17-180_0-rg_group-equ
        '- Online IBM.PeerNode:ip-10-240-17-180:ip-10-240-17-180

lssam コマンドは、TSAクラスター内のリソースとリソースグループを表示します。上記でオフライン(Offline)となっているリソースは、データベースがスタンバイノードでアクティブになっていない事を示しています。

クラスターをテストする
以下のコマンドを利用して手動でのフェイルオーバーを実行しクラスターをテストすることが可能です。

rgreq -o move <name of TSAMP resource group>

以下は実行例です。

rgreq -o move Db2_Db2inst1_Db2inst1_TESTDB-rg

コマンド実行後に lssam コマンドを数回実行して、スタンバイノードにデータベースがフェイルオーバーされることを確認してください。

自動クライアントリルート（Automatic Client Reroute: ACR）をテストする

次にACRをテストします。簡単に実行するため、Db2クライアントインスタンスからDBA（DB管理者）ユーザを利用してデータベースに接続します。接続できるようにするには、DBAユーザがプライマリ、スタンバイ両方のインスタンスでパスワード設定されている必要があります。DBAユーザにパスワードを設定するために、以下のコマンドを両方のDb2インスタンスで実行してください。

echo "<DBA user name>:<Password>" | chpasswd

以下は実行例です。（この例ではDBAユーザ名はデフォルトのdb2inst1を使用しています）

echo "db2inst1:Pass.123" | chpasswd

続いて、Db2クライアントとなるサーバに（ローカルPCから）SSHで接続し、以下のステップを実行します。以下のステップではプライマリーインスタンスへ接続し、データベース設定の詳細を取得します。プライマリーインスタンスは”Alternate server host name”(代替サーバホスト名)を返します。ACRに対応したDb2クライアントはこの代替ホスト名を記憶しておき、プライマリーインスタンスが利用できない場合は自動的に代替ホストに接続します。

以下のコマンドをDBAユーザで、Db2クライアントから実行します:

1. Db2サーバのエリアス（接続情報）を以下のコマンドで作成します。
   Bash

   db2 catalog tcpip node HAPNODE remote <NAME-OF-PRIMARY-INSTANCE> server <DB Listener Port>

   以下が例です。

   Bash

   db2 catalog tcpip node HAPNODE remote ip-1-1-1-1 server 60000

2. 作成した接続情報の上に以下のコマンドでデータベース名をカタログします。
   Bash

   db2 catalog db <DB-Name> at node HAPNODE

   以下が例です。

   Bash

   db2 catalog db TESTDB at node HAPNODE

3. 以下のコマンドでデータベースに接続します。
   Bash

   db2 connect to <DB-Name> user <Db2InstanceName> using <Password>

   以下が例です。

   Bash

   db2 connect to TESTDB user db2inst1 using Pass.123

4. 以下のコマンドでスタンバイインスタンスの情報を表示させます。この情報はAlternate server hostnameのところに表示されます。
   Bash

   db2 list db directory

   実行結果の例は以下の通りです。

   Bash

   Alternate server hostname            = ip-10-240-17-180
   Alternate server port number         = 60000

サマリー
これでAWS上で高可用性のDb2データベースを稼働することが出来ました。プライマリーインスタンスに書き込まれた全てのトランザクションは、設定した同期モード（ASYNC-同期、NEARSYNC-近同期、SYNC-同期）にしたがってスタンバイインスタンスに反映されます。

プライマリーインスタンスに障害が発生したり、利用できなくなると、TSAMPはそれを検知し自動的にスタンバイインスタンスへフェイルオーバーさせます。フェイルオーバーが発生するとDb2クライアントはプライマリーインスタンスが利用不可になった事を検知し、自動的に（以前の）スタンバイインスタンスに接続します。

Before considering this solution for production use, you might need to make a few changes. For example, you might want to place the Db2 servers in private subnets. Other potential changes to consider are customizing options in the response file, or automatically configuring Db2 software licenses.プロダクション（本番）用途でこのソリューションを利用する際にはいくつかの変更をする必要があるでしょう。例えば、Db2サーバをプライベートサブネットに配置するように変更する必要があるかもしれません。もしくは、レスポンスファイル（インストールの設定情報）をカスタマイズしたり、Db2のライセンス設定部分を自動化する等も検討することも考えられます。

さあ、準備は整いました！ミッションクリティカルのDB2ベースのアプリケーションをAWS上にマイグレーションしましょう！

著者について

Nicholas AnsellはAWSプロフェッショナルサービスのシニアコンサルタントです。彼はお客様のゴールをAWSサービスを活用して実現できるよう、お客様をご支援しています。 

翻訳：下佐粉 昭 (@simosako)

原文：https://aws.amazon.com/jp/blogs/database/creating-highly-available-ibm-db2-databases-in-aws/