SAP 用 IBM Db2 高可用性クラスタのデプロイガイド

注: このガイドは、11.5 より前のバージョンの Db2 システムのデプロイを対象としています。

Db2 バージョン 11.5.8 以降では、IBM が提供する Db2 用のクラスタリングソリューションを使用して、2 ホストの HADR Pacemaker クラスタを構成できます。Db2 統合 Pacemaker クラスタを設定するには、次の操作を行います。

SAP NetWeaver システムを分散システムとしてインストールします。詳細については、SAP のページ SAP Products Based on SAP NetWeaver 7.3 EHP1 to 7.52 Supported for Installation Using Software Provisioning Manager 1.0 をご覧ください。
IBM Db2 統合 Pacemaker ソフトウェアスタックをインストールします。詳細については、IBM の Pacemaker クラスター・ソフトウェア・スタックのインストールをご覧ください。
IBM Db2 HADR ペアを設定します。詳細については、SAP ページの Configuring the HADR Pair をご覧ください。
Pacemaker クラスタを作成します。詳細については、IBM の Pacemaker 管理の Linux クラスターでの HADR Db2 インスタンスの作成をご覧ください。

Db2 バージョン 11.5.8 以降では、Google Cloud でフェンシングと仮想 IP アドレス（VIP）を使用して 2 ホストの Db2 Pacemaker クラスタを設定できます。詳細については、Google Cloud で利用可能な代替構成または追加構成に関する IBM のページをご覧ください。仮想ホスト名と IP アドレスを使用して SAP システムを有効にする手順については、SAP のページで Virtual Host Name and IP Address をご覧ください。

このガイドでは、Linux オペレーティングシステムで SAP 用 IBM Db2（IBM Db2）高可用性（HA）クラスタ向けに Google Cloud リソースを設定する方法について説明します。

以下の内容は、SAP と IBM が IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms で説明している手順を補足するものです。Google Cloud で IBM Db2 HA クラスタのインストールと構成を行う場合は必ず、SAP と IBM が提供する最新のドキュメントをご覧ください。

以下では、IBM Tivoli System Automation for Multiplatforms（TSAMP）を使用する IBM Db2 HA クラスタでシステムをモニタリングし、システムが応答不能になった場合に適切な処置を行う方法について説明します。クラスタは IBM Db2 高可用性障害復旧（HADR）機能を使用して、ログに記録されたデータ変更をスタンバイデータベースに複製します。

クラスタは、Google Cloud 静的ルートまたはエイリアス IP アドレスを使用して Google Cloud が実装しているフローティング IP アドレスを使用します。このコンテキストで、「フローティング IP アドレス」という用語は、SAP のドキュメントで使用されている「仮想 IP アドレス」と同じ意味で使用されています。

1 台のプライマリ IBM Db2 サーバーと 1 台のセカンダリまたはスタンバイ IBM Db2 サーバーで構成される IBM Db2 HA クラスタを設定する方法を示します。これらのサーバーは、別々の Compute Engine 仮想マシン（VM）にデプロイされています。

このガイドは、高可用性クラスタに精通している経験豊富な SAP ユーザーと IBM Db2 ユーザーを対象としています。

Db2 HA クラスタの計画については、『IBM Db2 for SAP プランニングガイド』の高可用性 IBM Db2 クラスタを参照してください。

必要な SAP ドキュメント

SAP と IBM のコンポーネントをインストールして構成する手順については、SAP が提供する IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms をご覧ください。

これらの手順を開始する前に、SAP と Google Cloud の両方のドキュメントをご覧ください。デプロイのさまざまな段階で、SAP と Google Cloud の両方のドキュメントが必要になることがあります。

前提条件

IBM Db2 高可用性クラスタを作成する前に、次の前提条件を満たしていることを確認してください。

個人または組織の Google Cloud アカウントがあり、IBM Db2 HA クラスタをデプロイするプロジェクトを作成している。Google Cloud プロジェクトの作成方法については、『IBM Db2 for SAP デプロイガイド』で前提条件をご覧ください。
データ所在地、アクセス制御、サポート担当者、規制要件に準拠しながら SAP ワークロードを実行する必要がある場合は、必要な Assured Workloads フォルダを作成する必要があります。詳細については、Google Cloud 上の SAP のコンプライアンスと主権管理をご覧ください。
Google Cloud に Virtual Private Cloud ネットワークが構成されている。VPC ネットワークとファイアウォールルールを構成する方法と、IBM Db2 for SAP に NAT ゲートウェイまたは踏み台インスタンスを設定する方法については、IBM Db2 for SAP デプロイガイドをご覧ください。
プロジェクトメタデータで OS Login が有効になっている場合は、デプロイが完了するまで一時的に OS Login を無効にする必要があります。デプロイのために、次の手順によりインスタンスメタデータで SSH 認証鍵を構成します。OS Login が有効になっている場合、メタデータベースの SSH 認証鍵の構成は無効になります。デプロイが完了したら、再度 OS Login を有効にできます。

詳細については、以下をご覧ください。
- OS Login を有効または無効にする
- メタデータベースの SSH 認証鍵を使用する VM に SSH 認証鍵を追加する

Google Cloud に IBM Db2 高可用性クラスタをデプロイする

以下では、2 台の VM をデプロイしてフローティング IP アドレスを定義し、フローティング IP アドレスをサポートするエイリアス IP アドレスまたは Google Cloud ルートを構成します。IBM のコンポーネントをインストールする必要がある場合は、SAP のドキュメントをご覧ください。

IBM Db2 高可用性クラスタに設定する必要がある主な Google Cloud サービスは次のとおりです。

VPC ネットワークとサブネットワーク
ファイアウォールルール（他の形式のネットワークアクセス制御を使用していない場合）
Compute Engine VM と永続ディスクストレージ

ホスト間でのフローティング IP アドレスの切り替えを管理する際に TSAMP が使用するカスタムリソースを定義するときは、Google Cloud ヘルパースクリプトをダウンロードして使用します。TSAMP は、このスクリプトを使用して Google Cloud API を操作します。

Deployment Manager について

この手順では、Deployment Manager 構成ファイルテンプレートでインストール環境のリソースオプションを定義します。

Deployment Manager では、SAP システム用に作成されたすべてのリソースを「デプロイメント」という単一のエンティティとして扱います。Google Cloud コンソールの [デプロイ] ページで、プロジェクトのすべてのデプロイメントを表示して作業できます。

Deployment Manager を使用するときは、以下の動作に注意してください。

デプロイメントを削除すると、そのデプロイメントに関連付けられているすべてのリソース（VM、永続ディスク、VM にインストールされている SAP システムなど）が削除されます。
デフォルトでは、Deployment Manager は ACQUIRE リソース作成ポリシーを使用します。プロジェクト内の別の VM ですでに使用されている VM 名を指定した場合、新しい VM は作成されず、既存の VM が新しいデプロイメントに追加されます。元の VM が前回の Deployment Manager の実行で作成されたものである場合、VM は 2 つのデプロイメントに関連付けられます。

その後、新しいデプロイメントを削除すると、取得した VM は最初に作成したデプロイメントから削除されます。このような事態を避けるには、Deployment Manager リソースポリシーを CREATE に設定するか、新しいデプロイメントで一意のリソース名を使用してください。

Deployment Manager でリソースを作成する際に使用できるポリシーとその指定方法については、Deployment Manager のドキュメントをご覧ください。

Deployment Manager を使用して IBM Db2 HA クラスタの VM をデプロイする

Cloud Shell で、template_ha.yaml 構成ファイルのテンプレートを作業ディレクトリにダウンロードします。
```
wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/template_ha.yaml
```
Cloud Shell コードエディタを開くには、Cloud Shell ターミナルウィンドウの右上にある鉛筆（）アイコンをクリックします。
必要に応じて template_ha.yaml のファイル名を変更し、このファイルで定義する構成がわかるようにします。例: db2_ha_s123_dh1.yaml
コードエディタで template_ha.yaml を開くには、ファイル名をダブルクリックします。

template_ha.yaml ファイルに VM と通常ディスクを定義します。template_ha.yaml ファイルには、sap_db2_primary と sap_db2_secondary という 2 つのセクションがあります。各セクションには、一連のプロパティと値のペアが含まれています。セクションの最後にコメント部分があり、使用頻度の低いプロパティが記述されています。

instanceName、zone、otherHost プロパティ以外のセクションは、すべての VM で同一にする必要があります。

次の表に、各セクションに含まれるプロパティを示します。プロパティを使用するには、プレースホルダのテキストと括弧をご使用の環境の値に置き換えます。

プロパティ	データ型	説明
type	文字列	デプロイ中に使用する Deployment Manager テンプレートの場所、タイプ、バージョンを指定します。 YAML ファイルには 2 つの `type` 仕様が含まれており、そのうちの 1 つがコメントアウトされています。デフォルトで有効な `type` 仕様では、テンプレートバージョンを `latest` として指定します。コメントアウトされている `type` 仕様では、タイムスタンプを使用して特定のテンプレートバージョンを指定します。すべてのデプロイで同じテンプレートバージョンを使用する必要がある場合は、タイムスタンプを含む `type` 仕様を使用します。
`instanceName`	文字列	IBM Db2 をインストールする VM インスタンスの名前。名前は 13 文字以下にし、小文字、数字またはハイフンで指定する必要があります。
`instanceType`	文字列	IBM Db2 をインストールする Compute Engine 仮想マシンの種類。複数の vCPU を持つマシンタイプを指定します。例: `n1-standard-4`。
`zone`	文字列	IBM Db2 インスタンスをデプロイしているゾーン。このゾーンは、サブネットワークで選択したものと同じリージョンに存在する必要があります。
`subnetwork`	文字列	前のステップで作成したサブネットワークの名前。共有 VPC にデプロイする場合は、この値を `shared-vpc-project/SUBNETWORK` の形式で指定します。例: `myproject/network1`
`linuxImage`	文字列	IBM Db2 で使用する Linux オペレーティングシステムのイメージまたはイメージファミリーの名前。イメージファミリーを指定するには、ファミリー名に接頭辞 `family/` を追加します。たとえば、`family/rhel-7-sap-apps` や `family/sles-12-sp3-sap` です。イメージを指定する場合は、イメージ名のみを入力します。利用可能なイメージファミリーの一覧については、Google Cloud コンソールの [イメージ] ページをご覧ください。
`linuxImageProject`	文字列	使用するイメージを含む Google Cloud プロジェクト。このプロジェクトは独自のプロジェクトか、`rhel-sap-cloud` や `suse-sap-cloud` のような Google Cloud イメージプロジェクトです。Google Cloud イメージプロジェクトの一覧については、Compute Engine ドキュメントのイメージのページをご覧ください。
`db2SID`	文字列	データベースのインスタンス ID。
`db2sidSize`	整数	データベースインスタンスのルートディレクトリである /db2/`DBSID` のサイズ（GB 単位）。`db2sidSize` の最小値とデフォルト値はどちらも 8 GB です。
`db2homeSize`	整数	データベースインスタンスのホームディレクトリである /db2/db2`db2sid` のサイズ（GB 単位）。`db2homeSize` の最小値とデフォルト値はどちらも 8 GB です。
`db2dumpSize`	整数	問題の診断に使用される DB2 のダンプファイルを格納する /db2/`DBSID`/db2dump のサイズ（GB 単位）。`db2dumpSize` の最小値とデフォルト値はどちらも 8 GB です。
`db2saptmpSize`	整数	データベースの一時テーブルスペースを格納する /db2/`DBSID`/saptmp のサイズ（GB 単位）。`db2saptmpSize` の最小値とデフォルト値はどちらも 8 GB です。
`db2sapdataSize`	整数	データベースのデータファイルを格納する /sapdb/`DBSID`/sapdata のサイズ。`db2sapdataSize` の最小値とデフォルト値はどちらも 30 GB です。
`db2logSize`	整数	データベースのトランザクションログを格納する /db2/`DBSID`/logdir のサイズ。`db2logSize` の最小値とデフォルト値はどちらも 8 GB です。
`db2backupSize`	整数	/db2backup ボリュームのサイズ。このプロパティは省略可能です。`0` に設定するか省略した場合、ディスクは作成されません。
`db2sapdataSSD`	ブール値	データドライブが SSD 永続ディスクを使用する（`Yes`）か、HDD 永続ディスクを使用する（`No`）かを指定します。デフォルトは `Yes` です。
`db2logSSD`	ブール値	ログドライブが SSD 永続ディスクを使用する（`Yes`）か、HDD 永続ディスクを使用する（`No`）かを指定します。デフォルトは `Yes` です。ログドライブには SSD をおすすめします。
`usrsapSize`	整数	IBM Db2 をインストールして、同じ VM インスタンス上で SAP NetWeaver とともに実行させる場合にのみ必要です。
`sapmntSize`	整数	IBM Db2 をインストールして、同じ VM インスタンス上で SAP NetWeaver とともに実行させる場合にのみ必要です。
`swapSize`	整数	IBM Db2 をインストールして、同じ VM インスタンス上で SAP NetWeaver とともに実行させる場合にのみ必要です。
`otherHost`	文字列	IBM Db2 HA クラスタ内の他の VM インスタンスの名前。VM インスタンスは、同じ `template_ha.yaml` ファイルの他のプロパティセットで定義する必要があります。
`networkTag`	文字列	省略可。ファイアウォールまたはルーティングの目的で使用される、VM インスタンスを表すネットワークタグ。`publicIP: No` を指定して、ネットワークタグを使用しない場合は、インターネットへの別のアクセス手段を必ず指定してください。
`publicIP`	ブール値	省略可。パブリック IP アドレスを VM インスタンスに追加するかどうかを指定します。デフォルトは `Yes` です。注: NAT ゲートウェイを VM 用に定義されたネットワークタグで構成しているか、VM をインターネットに接続する他のルートを確保している場合を除いて、`No` と入力しないでください。インターネットへのルートがない場合、インストールは失敗します。
`serviceAccount`	文字列	省略可。ロックされたアクセス権限を持つ独自のサービスアカウントを作成する場合は、ここにアカウントの名前を入力します。デフォルトでは、VM はデフォルトのプロジェクトサービスアカウントを使用してデプロイされます。サービスアカウントを誤って定義すると、デプロイに失敗します。カスタムサービスアカウントの例: `myserviceuser@myproject.iam.gserviceaccount.com`
`sap_deployment_debug`	ブール値	省略可。この値が `Yes` に設定されている場合、デプロイの際に詳細なログが生成されます。Google のサポートエンジニアからデバッグを有効にするように求められない限り、この設定はオンにしないでください。
`post_deployment_script`	文字列	省略可。デプロイの完了後に実行するスクリプトの場所を指定します。スクリプトは、ウェブサーバーか Cloud Storage バケットでホストする必要があります。URL は `http://`、`https://`、または `gs://` で始める必要があります。このスクリプトは、テンプレートで作成されたすべての VM で実行されます。プライマリインスタンスでのみ実行するには、スクリプトの先頭にチェックを追加します。

以下の template_ha.yaml 構成ファイルの VM 定義では、IBM Db2 HA クラスタに 2 つの VM が作成されます。この構成ファイルにより、それぞれの VM に対して、SLES 12 SP3 イメージファミリーのオペレーティングシステムを実行している n1-standard-4 VM をデプロイするように Deployment Manager に指示します。VM には、IBM Db2 HA クラスタの実行に必要なすべてのディレクトリが含まれています。ディレクトリサイズが 0 に設定されているため、Deployment Manager は SAP NetWeaver ディレクトリを作成しません。

resources:
- name: sap_db2_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s1
    instanceType: n1-standard-4
    zone: us-central1-c
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s2
#
# (Comment section omitted from example)
#
- name: sap_db2_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s2
    instanceType: n1-standard-4
    zone: us-central1-f
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s1

Deployment Manager を使用して VM インスタンスをデプロイします。
```
gcloud deployment-manager deployments create DEPLOYMENT-NAME --config TEMPLATE-NAME.yaml
```
ここで
- DEPLOYMENT-NAME は、現在のデプロイメントに選択した名前です。この名前は、Google Cloud コンソールの [デプロイ] ページでこのデプロイメントを識別するために使用されます。
- TEMPLATE-NAME は、構成ファイルで指定した名前です。デフォルトのファイル名を変更していない場合は template_ha.yaml です。
Deployment Manager が、template_ha.yaml ファイルの指定を読み取り、それに応じて VM と永続ディスクを構成します。処理には数分かかる場合があります。デプロイの進行状況を確認するには、次のセクションの手順を実施してください。

デプロイの確認

デプロイを確認するには、Cloud Logging でデプロイログを確認し、VM の設定を確認します。

ログを調べる

Google Cloud コンソールで Cloud Logging を開き、インストールの進行状況をモニタリングして、エラーを確認します。

注: Cloud Logging でこの手順を完了すると、費用が発生する場合があります。詳細については、Cloud Logging の料金をご覧ください。
Cloud Logging に移動
ログをフィルタします。
ログエクスプローラ
1. [ログエクスプローラ] ページで、[クエリ] ペインに移動します。
2. [リソース] プルダウンメニューから [グローバル] を選択し、[追加] をクリックします。
  
  [グローバル] オプションが表示されない場合は、クエリエディタに次のクエリを入力します。
```
resource.type="global"
"Deployment"
```
3. [クエリを実行] をクリックします。
以前のログビューア
- [以前のログビューア] ページの基本的なセレクタメニューから、ロギングリソースとして [グローバル] を選択します。
フィルタされたログを分析します。
- "--- Finished" が表示されている場合、デプロイメントは完了しています。次の手順に進んでください。
- 割り当てエラーが発生した場合:
  1. [IAM と管理] の [割り当て] ページで、IBM DB2 for SAP プランニングガイドに記載されている IBM DB2 の要件を満たしていない割り当てを増やします。
  2. Deployment Manager の [デプロイ] ページでデプロイメントを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。
  3. デプロイを再実行します。

VM の構成を確認する

VM のデプロイが完了したら、ssh を使用して各 VM に接続します。Compute Engine の [VM インスタンス] ページから、VM インスタンスの SSH ボタンをクリックするか、任意の SSH メソッドを使用します。
root ユーザーに変更します。
```
sudo su -
```

コマンドプロンプトで df -h を実行します。次のような出力が表示されます。

db2-ha-s1:~ # df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.4G     0  7.4G   0% /dev
tmpfs                           12G     0   12G   0% /dev/shm
tmpfs                          7.4G   18M  7.4G   1% /run
tmpfs                          7.4G     0  7.4G   0% /sys/fs/cgroup
/dev/sda1                       30G  2.2G   26G   8% /
/dev/mapper/vg_db2sid-vol       16G   33M   16G   1% /db2/DH1
/dev/mapper/vg_db2dump-vol      16G   33M   16G   1% /db2/DH1/db2dump
/dev/mapper/vg_db2sapdata-vol   50G   33M   50G   1% /db2/DH1/sapdata
/dev/mapper/vg_db2saptmp-vol    16G   33M   16G   1% /db2/DH1/saptmp
/dev/mapper/vg_db2log-vol       16G   33M   16G   1% /db2/DH1/log_dir
/dev/mapper/vg_db2home-vol      16G   33M   16G   1% /db2/db2dh1
/dev/mapper/vg_db2backup-vol    50G   33M   50G   1% /db2backup
tmpfs                          1.5G     0  1.5G   0% /run/user/1001

確認ステップの途中でインストールに失敗したことが示された場合は、次の手順を行います。

エラーを修正します。
[デプロイ] ページでデプロイメントを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。
デプロイを再実行します。

フローティング IP アドレスを予約する

フローティング IP アドレスとして使用する IP アドレスを選択する必要があります。後でホスト VM インスタンスのメタデータを設定するときや、IBM db2 と HA クラスタをインストールして構成するときに、この IP アドレスが必要になります。

フローティング IP アドレスに対してルートまたはエイリアス IP の実装タイプのいずれを選択するかによって、フローティング IP アドレスの要件が異なります。

フローティング IP アドレスに静的ルートを使用する場合、サブネットワークの IP アドレス範囲に含まれない IP アドレスを設定する必要があります。この IP アドレスは、組織の拡張ネットワーク内で使用できません。適切な IP アドレスを決める場合は、ネットワーク管理者に相談してください。

フローティング IP アドレスにエイリアス IP アドレスを使用する場合、ホストが使用しているサブネットワークの IP アドレス範囲の中から IP アドレスを予約する必要があります。

エイリアス IP アドレスは、エイリアス IP アドレスを使用する場合のみ予約します。

ホスト VM でターミナルを開くか、Cloud Shell を開きます。

Cloud Shell に移動
IP アドレスを予約します。
```
gcloud compute addresses create vip-name --region region --subnet subnet-name \
  --addresses ip-addr-optional
```
addresses プロパティの指定は任意です。IP アドレスを入力しないと、Compute Engine はサブネットワークから IP アドレスを選択します。

予約済みの IP アドレスを表示してメモします。このアドレスは、データベースサーバーをインストールして HA クラスタを構成するときに使用します。

gcloud compute addresses describe vip-name --region=region

例:

db2-ha-s1:~ # gcloud compute addresses describe db2-ha-vip-dh1 --region=us-central1
address: 10.1.0.30
addressType: INTERNAL
creationTimestamp: '2018-11-28T11:34:14.478-08:00'
description: ''
id: '6558342813288977241'
kind: compute#address
name: db2-ha-vip-dh1
region: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/addresses/db2-ha-vip-dh1
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/subnetworks/example-sap-   subnetwork

各ホスト VM インスタンスのメタデータにフローティング IP アドレスを追加する

クラスタ内の VM インスタンスごとに、フローティング IP アドレスに関する情報（選択したルートやエイリアス IP の実装タイプなど）をカスタムメタデータとして指定します。フローティング IP アドレスの実装タイプの選択方法については、Google Cloud の IBM Db2 HA クラスタ用フローティング IP アドレスをご覧ください。

実装タイプに応じて、設定するメタデータパラメータが異なります。次の 2 つのセクションのうち、使用しているフローティング IP アドレスの実装に該当するセクションの指示に従ってください。

フローティング IP アドレスにルートを使用する場合のメタデータの設定

フローティング IP アドレスにルートを使用する場合は、次の表のパラメータと手順を使用して、インスタンスのメタデータを設定します。

パラメータ	値	目的
`sap_ibm_vip_solution`	`route`	Google Cloud 静的ルートを使用してホスト間でフローティング IP アドレスの切り替えを行うマルチゾーンデプロイメントであることを指定します。
`sap_ibm_db2_vip`	`ip-address`	前の手順で予約したフローティング IP アドレスを指定します。
`sap_ibm_db2_routename`	`route-name`	静的ルートに任意の名前を指定します。たとえば、`db2-dh1-vip-route` を使用できます。
`sap_ibm_db2_routenet`	`vpc-network-name`	IBM Db2 HA クラスタを含む VPC ネットワークを指定します。

フローティング IP アドレスの静的ルートにインスタンスメタデータを設定するには:

ホスト VM でターミナルを開くか、Cloud Shell を開きます。

Cloud Shell に移動

クラスタ内の各ホスト VM インスタンスで、フローティング IP アドレスのルート実装に同じメタデータを指定します。

gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=route,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_routename=route-name,sap_ibm_db2_routenet=vpc-network-name \
--zone instance-zone

フローティング IP アドレスにエイリアス IP アドレスを使用する場合のメタデータの設定

フローティング IP アドレスにエイリアス IP アドレスを使用する場合は、次の表のパラメータと手順を使用して、インスタンスのメタデータを設定します。

パラメータ	値	目的
`sap_ibm_vip_solution`	`alias`	Google Cloud エイリアス IP アドレスを使用して、ホスト間でフローティング IP アドレスの切り替えを行うシングルゾーンデプロイメントであることを示します。
`sap_ibm_db2_vip`	`ip-address`	前の手順で予約したフローティング IP アドレスを指定します。
`sap_ibm_db2_vip_range`	`alias-ip-range-name`	（省略可）エイリアス IP 範囲に任意の名前を指定します。たとえば、`db2-dh1-vip-alias` を使用できます。デフォルト値はサブネットワーク名です。

フローティング IP アドレスのエイリアス IP にインスタンスメタデータを設定するには:

ホスト VM でターミナルを開くか、Cloud Shell を開きます。

Cloud Shell に移動

クラスタ内の各ホスト VM インスタンスで、フローティング IP アドレスのエイリアス IP アドレスの実装に同じメタデータを指定します。

gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=alias,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_vip_range=alias-ip-range-name --zone instance-zone

インスタンスメタデータの確認または変更

設定したインスタンスメタデータを確認するには:

gcloud compute instances describe instance-name --zone instance-zone

カスタムメタデータの変更が必要な場合は、次のコマンドを実行します。

gcloud compute instances add-metadata instance-name --metadata  parm-name=parm-value

ホスト名と IP アドレスを `/etc/hosts` に追加する

クラスタの設定中に、SAP クラスタ設定ツールは、各ホスト VM のホスト名と内部 IP アドレス、フローティング IP アドレスを検証します。検証が成功したことを確認するには、任意のエディタを使用して、各ホスト VM の IP アドレスとホスト名、VPC の内部 DNS 名、さらにフローティング IP アドレスを各ホスト VM の /etc/hosts ファイルに追加します。

たとえば、root として次の例を実行すると、/etc/hosts が更新されます。

echo "#Db2 HA floating IP additions" >> /etc/hosts
echo 10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal >> /etc/hosts
echo 10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal >> /etc/hosts
echo 10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal >> /etc/hosts

上記の例では、各行のホスト名と >> 間の文字列は VPC の内部 DNS 名です。これは、VPC の内部 DNS サービスによって使用されます。

ホスト VM は、ゾーンのフィールドを含むゾーン内部 DNS 名を使用します。フローティング IP アドレスは、ゾーンフィールドを含まないグローバル内部 DNS 名を使用します。

VM ホストの場合、ホスト VM のターミナルから次のコマンドを入力すると内部 DNS 名を取得できます。

curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
-H "Metadata-Flavor: Google"

フローティング IP アドレスの場合は、次の形式で入力します。

vip-host-name.c.project-name.internal

/etc/hosts ファイルを更新すると、/etc/hosts ファイルの関連情報は次のようになります。

#Db2 HA floating IP additions
10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal
10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal
10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal

オペレーティングシステムの準備

VM を作成したら、IBM Db2 HA クラスタ用にオペレーティングシステムを準備します。

要件は SAP と IBM によって定義されています。SAP のドキュメントには Perl や Korn Shell などのソフトウェアをインストールするように記載されていますが、これらのソフトウェアは Compute Engine のホスト VM にプリインストールされていないことがあります。

最新の要件については、次のドキュメントをご覧ください。

IBM Db2 high availability solution: IBM Tivoli System Automation for Multiplatforms
1984787 - SUSE LINUX Enterprise Server 12: Installation notes

注: SLES 12 SP2 では、OS パッケージの更新に zypper update を使用する必要があります。更新しなかった場合、JDBC など、Java 上で実行されるソフトウェアによってはコアダンプが発生することがあります。
2002167 - Red Hat Enterprise Linux 7.x: Installation and Upgrade

データベースサーバーをインストールして IBM Db2 HA クラスタを作成する

IBM Db2 High availability solution: IBM Tivoli System Automation for Multiplatforms に記載されている手順に沿って IBM Db2 および HA クラスタのインストールと構成を行う前に、以下の手順の概要を確認してください。注記の部分は特に注意して確認する必要があります。

SAP NetWeaver とプライマリアプリケーションサーバーをインストールするには、Google Cloud で SAP NetWeaver のドキュメントをご覧ください。また、SAP ヘルプポータルで該当する SAP インストールガイドもご覧ください。

以下では、インストール手順の概要を説明します。詳しくは、SAP のドキュメントをご覧ください。

SAP のドキュメントの説明に従って、プライマリインスタンスとセカンダリインスタンスの間でキーベースの SSH 接続を確立します。また、各インスタンス間も同じ SSH 接続を確立します。SSH は、SAP クラスタ設定ツールで使用されます。各ホストですべての接続をテストします。たとえば、db2-ha-s1 で次の両方をテストします。
- ```
ssh db2-ha-s1
```
- ```
ssh db2-ha-s2
```
  注: 各 Compute Engine VM には、生成された独自の id_rsa ファイルと id_rsa.pub ファイルが付属しています。Db2 HA クラスタの場合、各ホスト VM の id_rsa.pub ファイルにある RSA 鍵が、クラスタ内の他のすべてのホスト VM の authorized_keys ファイルに追加されます。
SAP サポートポータルから Db2 用の完全な SAP メディアセットを VM にダウンロードするか、コピーします。
プライマリホスト VM で、SAP Software Provisioning Manager（SWPM）を使用して IBM Db2 データベースサーバーをインストールします。

注: SWPM の [Cluster Configuration - Network] パネルで、予約済みのフローティング IP アドレスを指定して、タイブレーカーの IP アドレスを指定します。タイブレーカーとして使用できる対象については、ネットワークタイブレーカーをご覧ください。
セカンダリホスト VM で、SAP Homogeneous System Copy などの方法を使用してスタンバイデータベースを設定します。
両方のホスト VM に、IBM Db2 と IBM TSAMP のライセンスファイルをインストールします。SAP から取得した IBM ライセンスをインストールする方法については、SAP Note 816773 - DB6: Installing an SAP OEM license をご覧ください。
両方のホスト VM に、データベースのバージョンとオペレーティングシステムのバージョンでサポートされている TSAMP の最新バージョンをインストールします。
プライマリホスト VM で、最新バージョンの SAP クラスタ設定ツール sapdb2cluster.sh を使用して、IBM Db2 HA クラスタの構成と作成を行います。

注: Db2 HA クラスタを作成する前に、sapdb2cluster.sh 設定ダイアログで DB2_NO_SERVICE_IP=true を指定して、標準の IBM.ServiceIP リソースの作成を回避するように SAP クラスタ設定ツールを構成する必要があります。クラスタは IBM.Application リソースを使用します。
詳しくは、フローティング IP アドレスのおすすめの方法をご覧ください。
クラスタの作成後、プライマリホストで DB2 高可用性インスタンス構成ユーティリティ（db2haicu）を使用して、クラスタがフェイルオーバーできることを確認します。
1. SAP クラスタ設定ツールと Korn シェルを終了します。
2. プライマリインスタンスで、プライマリデータベースサーバーがオンラインになっていることを確認します。
```
lssam
```
  次の例は、lssam 出力の一部です。ここでは、プライマリデータベースインスタンスがオンラインになっています。
```
Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
```
3. データベースインスタンスユーザーに切り替えます。
```
sudo su - db2sid
```
4. db2haicu ユーティリティを開始します。
```
db2haicusid
```
5. db2haicu インターフェースで、オプション 5 を選択し、プロンプトに従います。
6. db2haicu ユーティリティを終了します。
7. プライマリホストで、セカンダリホストがオンラインになったことを確認します。
```
lssam
```
  次の例は、lssam 出力の一部です。ここでは、セカンダリデータベースインスタンスがオンラインになっています。
```
Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
```

クラスタの構成を完了するため、次のセクションの指示に従ってフローティング IP アドレスにカスタム TSAMP リソースを作成し、TSAMP 内でそのリソースを IBM Db2 インスタンスリソースに関連付けます。

フローティング IP アドレスに TSAMP カスタムリソースを作成する

TSAMP がフローティング IP アドレスを管理できるようにするには、TSAMP カスタムリソースを作成する必要があります。TSAMP がフローティング IP アドレスのリソースを管理しながら Google Cloud を操作できるようにするには、Google Cloud からヘルパースクリプトをダウンロードして構成する必要があります。

Google Cloud ヘルパースクリプトをダウンロードする

クラスタ内の各ホストで、Google Cloud ヘルパースクリプトをダウンロードしてアクセス権を設定します。

プライマリホストとスタンバイホストの両方で、root ユーザーとしてプライマリ VM の /root ディレクトリからスクリプトをダウンロードします。

共有 VPC 構成を使用していないインスタンスの場合:
```
wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip.sh -O gcp_floating_ip.sh
```
共有 VPC 構成を使用しているインスタンスの場合:
```
wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip_svpc.sh -O gcp_floating_ip.sh
```
両方のホストで、スクリプトに権限を設定します。
```
chmod 744 gcp_floating_ip.sh
```

フローティング IP アドレスに TSAMP カスタムリソースを作成して構成する

クラスタ内の 1 つのホストで、フローティング IP アドレス用の TSAMP カスタムリソースを作成して構成します。

任意の 1 つのホストで cluster_res.conf という構成ファイルを作成します。NodeNameList パラメータをホスト名で更新した後に、次のテキストをファイルに貼り付けます。

PersistentResourceAttributes::
  Name="gcp_floating_ip-rs"
  ResourceType=1
  StartCommand="/root/gcp_floating_ip.sh start"
  StopCommand="/root/gcp_floating_ip.sh stop"
  MonitorCommand="/root/gcp_floating_ip.sh status"
  MonitorCommandPeriod=30
  MonitorCommandTimeout=30
  StartCommandTimeout=600
  StopCommandTimeout=600
  UserName="root"
  RunCommandsSync=1
  ProtectionMode=0
  NodeNameList={"host-1","host-2"}

プライマリホストで、root ユーザーとして次のコマンドを実行し、TSAMP カスタムリソースを作成します。

export CT_MANAGEMENT_SCOPE=2
mkrsrc -f cluster_res.conf IBM.Application
mkrg -l None gcp_floating_ip-rg
chrg -o Online gcp_floating_ip-rg
addrgmbr -g gcp_floating_ip-rg -m F IBM.Application:gcp_floating_ip-rs
rgreq -o start gcp_floating_ip-rg

プライマリホストで、オンラインになっている Db2 インスタンスリソースがオンラインのフローティング IP リソースと同じホストにあることを確認します。この操作は root ユーザーとして実行します。

lssam

出力では、オンラインリソースがすべて同じホスト VM 上に存在するはずです。

Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
Online IBM.ResourceGroup:gcp_floating_ip.sh_rg Nominal=Online
        '- Online IBM.Application:gcp_floating_ip.sh_rs
                |- Online IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s1
                '- Offline IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s2

フローティング IP アドレスのリソースがデータベースインスタンスと同じホスト上でオンラインになっていない場合は、フローティング IP アドレスのリソースを移動します。

rgreq -o move -n host-to-move-from gcp_floating_ip-rg

プライマリホストで root ユーザーとして、TSAMP でデータベースインスタンスリソースとフローティング IP アドレスリソースの関係を確立します。
```
rgreq -o lock gcp_floating_ip-rg
rgreq -o lock db2_db2sid_db2sid_SID-rg
mkrel -o NoCondition -p Collocated \
  -S IBM.Application:gcp_floating_ip-rs -G IBM.Application:db2_db2sid_db2sid_SID-rs \
  db2hadr_colo_gcp_floating_ip
rgreq -o unlock db2_db2sid_db2sid_SID-rg
rgreq -o unlock gcp_floating_ip-rg
```
データベースインスタンスリソースとフローティング IP アドレスリソースの間の関係を確立したら、次のセクションで説明するように、フェイルオーバーを再度テストできます。

Google Cloud で SAP 用の Db2 HA クラスタのデプロイを確認する

IBM Db2 HA クラスタが正しく構成されていることを確認するには、フェイルオーバーをトリガーし、すべてのオンラインリソースがホスト VM 間で移動しているかどうか確認します。

フェイルオーバーのテストを行うには:

root ユーザーとしてプライマリホストで、現在オンラインリソースに存在するホスト VM を確認します。
```
lssam
```
プライマリホストで、db2 インスタンスのユーザーに変更します。
```
sudo su - db2sid
```
db2haicu ユーティリティを開始します。
```
db2haicu
```
db2haicu ユーティリティインターフェースで、オプション 5 を選択し、プロンプトに従ってフェイルオーバーをトリガーします。
db2haicu ユーティリティの処理が終了したら、ユーティリティを終了します。
root ユーザーに切り替えます。
```
sudo su -
```
オンラインリソースが他のホスト VM に移動したことを確認します。

Google Cloud の SAP 用エージェントのインストールを検証する

VM をデプロイして SAP システムをインストールしたら、Google Cloud の SAP 用エージェントが正常に機能していることを確認します。

Google Cloud の SAP 用エージェントが実行されていることを確認する

エージェントの動作確認の手順は次のとおりです。

ホスト VM インスタンスと SSH 接続を確立します。

次のコマンドを実行します。

systemctl status google-cloud-sap-agent

エージェントが正常に機能している場合、出力には active (running) が含まれます。例:

google-cloud-sap-agent.service - Google Cloud Agent for SAP
Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
Main PID: 1337673 (google-cloud-sa)
Tasks: 9 (limit: 100427)
Memory: 22.4 M (max: 1.0G limit: 1.0G)
CGroup: /system.slice/google-cloud-sap-agent.service
       └─1337673 /usr/bin/google-cloud-sap-agent

エージェントが実行されていない場合は、エージェントを再起動します。

SAP Host Agent が指標を受信していることを確認する

Google Cloud の SAP 用エージェントによってインフラストラクチャの指標が収集され、SAP Host Agent に正しく送信されていることを確認するには、次の操作を行います。

SAP システムで、トランザクションとして「ST06」を入力します。
概要ウィンドウで可用性と以下のフィールドの内容を確認し、SAP と Google モニタリングインフラストラクチャのエンドツーエンドの設定が正しいか調べます。
- クラウドプロバイダ: Google Cloud Platform
- Enhanced Monitoring Access: TRUE
- Enhanced Monitoring Details: ACTIVE

デプロイ後のタスクの実行

Google Cloud で IBM Db2 高可用性システムを使用する前に、IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms に記載されているインストール後の作業をすべて完了しておくことをおすすめします。たとえば、次のような作業を行います。

データベースクラスタを検証する。
TSAMP コアポリシーをバックアップする
データベース修正パックを更新する。
フローティング IP アドレスのホスト名と IP アドレスを使用するように Db2 クライアント接続を更新する。たとえば、SAP ABAP アプリケーションサーバーの db2cli.ini ファイルを更新します。

DB2 HA クラスタで NAT ゲートウェイを使用している場合は、IBM Db2 for SAP デプロイガイドの NAT ゲートウェイのインストールの完了の説明に沿って、NAT ゲートウェイの設定を完了します。