Deployment Manager: SAP HANA スケールアップ高可用性クラスタ構成ガイド

このガイドでは、内部パススルーネットワークロードバランサを使用する Red Hat Enterprise Linux（RHEL）または SUSE Linux Enterprise Server（SLES）の高可用性（HA）クラスタで SAP HANA のデプロイを自動化し、仮想 IP（VIP）アドレスを管理する方法について説明します。

このガイドでは、Cloud Deployment Manager を使用して、2 つの Compute Engine 仮想マシン（VM）、2 つの SAP HANA スケールアップシステム、内部パススルーネットワークロードバランサが実装された仮想 IP アドレス（VIP）、OS ベースの HA クラスタをデプロイします（すべて、Google Cloud、SAP、OS ベンダーのベストプラクティスに沿って行います）。

Terraform を使用して SAP HANA 用の高可用性クラスタのデプロイを自動化する場合は、Terraform: SAP HANA 高可用性クラスタの構成ガイドをご覧ください。

SAP HANA システムの 1 つがプライマリのアクティブシステムとして機能し、もう 1 つはセカンダリのスタンバイシステムとして機能します。両方の SAP HANA システムは同じリージョンにデプロイします（異なるゾーンにデプロイすることが理想的です）。

高可用性 Linux クラスタの単一ノード SAP HANA スケールアップシステムの概要

デプロイされたクラスタには、以下の機能が含まれます。

Pacemaker 高可用性クラスタリソースマネージャー。
Google Cloud フェンシングメカニズム。
レベル 4 の TCP 内部ロードバランサの実装を使用する仮想 IP（VIP）。以下を含みます。
- VIP 用に選択した IP アドレスの予約
- 2 つの Compute Engine インスタンスグループ
- TCP 内部ロードバランサ
- Compute Engine ヘルスチェック
RHEL HA クラスタの場合:
- Red Hat 高可用性パターン
- Red Hat リソースエージェントとフェンシングパッケージ
SLES HA クラスタの場合:
- SUSE 高可用性パターン。
- SUSE SAPHanaSR リソースエージェントパッケージ。
同期システムレプリケーション。
メモリプリロード。
障害が発生したインスタンスを新しいセカンダリインスタンスとして自動的に再起動。

Linux 高可用性クラスタまたはスタンバイホストなしで SAP HANA システムをデプロイする場合は、SAP HANA デプロイガイドをご覧ください。

このガイドは、SAP HANA 用の Linux 高可用性構成に精通している SAP HANA の上級ユーザーを対象としています。

前提条件

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

SAP HANA プランニングガイドと SAP HANA 高可用性プランニングガイドを読んでいる。
個人または組織で Google Cloud アカウントを所有していて、SAP HANA をデプロイするプロジェクトを作成済みである。Google Cloud アカウントとプロジェクトの作成方法については、SAP HANA デプロイガイドの Google アカウントの設定をご覧ください。
データ所在地、アクセス制御、サポート担当者、規制要件に準拠しながら SAP ワークロードを実行する必要がある場合は、必要な Assured Workloads フォルダを作成する必要があります。詳細については、Google Cloud 上の SAP のコンプライアンスと主権管理をご覧ください。
SAP HANA のインストールメディアが、ユーザーのデプロイプロジェクトおよびリージョンで利用可能な Cloud Storage バケットに格納されている。SAP HANA インストールメディアを Cloud Storage バケットにアップロードする方法については、SAP HANA デプロイガイドの SAP HANA のダウンロードをご覧ください
プロジェクトメタデータで OS Login が有効になっている場合は、デプロイが完了するまで一時的に OS Login を無効にする必要があります。デプロイのために、次の手順によりインスタンスメタデータで SSH 認証鍵を構成します。OS Login が有効になっている場合、メタデータベースの SSH 認証鍵構成は無効になり、このデプロイは失敗します。デプロイが完了したら、再度 OS Login を有効にできます。

詳細については、以下をご覧ください。
- OS Login を有効または無効にする
- メタデータベースの SSH 認証鍵を使用する VM に SSH 認証鍵を追加する
VPC 内部 DNS を使用している場合は、プロジェクトメタデータの vmDnsSetting 変数の値を GlobalOnly または ZonalPreferred にして、ゾーン間でノード名を解決できるようにする。vmDnsSetting のデフォルト設定は ZonalOnly です。詳細については、次のトピックをご覧ください。

VM インスタンスが意図せずインターネットに公開されるのを防ぐため、次の推奨事項に従ってください。

NAT ゲートウェイを使用する。
不要な外部アクセスをすべてブロックするファイアウォールルールを作成する。
VM の作成時に次のことを行う。
- 各 VM にルーティングルールとファイアウォールルールで使用するネットワークタグを指定する。Google Cloud が提供する Deployment Manager テンプレートを使用する場合は、networkTag: [TAG] を使用したタグを指定してください。
- 外部 IP を持たない VM を作成する。Google Cloud が提供する Deployment Manager テンプレートを使用する場合は、publicIP: No を指定してください。

ネットワークの作成

セキュリティ上の理由から、新しいネットワークを作成します。アクセスできるユーザーを制御するには、ファイアウォールルールを追加するか、別のアクセス制御方法を使用します。

プロジェクトにデフォルトの VPC ネットワークがある場合、デフォルトは使用せず、明示的に作成したファイアウォールルールが唯一の有効なルールとなるように、独自の VPC ネットワークを作成してください。

デプロイ中、VM インスタンスは通常、Google Cloud の SAP 用エージェントをダウンロードするためにインターネットにアクセスする必要があります。Google Cloud から入手できる SAP 認定の Linux イメージのいずれかを使用している場合も、ライセンスを登録して OS ベンダーのリポジトリにアクセスするために、VM インスタンスからインターネットにアクセスする必要があります。このアクセスをサポートするために、NAT ゲートウェイを配置し、VM ネットワークタグを使用して構成します。ターゲット VM に外部 IP がない場合でもこの構成が可能です。

ネットワークを設定するには:

コンソール

Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
ネットワークの名前を入力します。
命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。
[サブネット作成モード] で [カスタム] をクリックします。
[新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
1. サブネットの名前を入力します。
2. [リージョン] で、サブネットを作成する Compute Engine のリージョンを選択します。
3. [IP スタックタイプ] で [IPv4（シングルスタック）] を選択し、CIDR 形式で IP アドレス範囲を入力します。（10.1.0.0/24 など）
  これはサブネットのプライマリ IPv4 範囲です。複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。
4. [完了] をクリックします。
さらにサブネットを追加するには、[サブネットを追加] をクリックして前の手順を繰り返します。ネットワークを作成した後で、ネットワークにさらにサブネットを追加できます。
[作成] をクリックします。

gcloud

Cloud Shell に移動します。
Cloud Shell に移動
カスタムサブネットワークモードで新しいネットワークを作成するには、次のコマンドを実行します。
```
gcloud compute networks create NETWORK_NAME --subnet-mode custom
```
NETWORK_NAME は、新しいネットワークの名前に置き換えます。命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。

デフォルトの自動モードでは、各 Compute Engine リージョンにサブネットが自動的に作成されます。この自動モードを使用しないようにするには、--subnet-mode custom を指定します。詳しくは、サブネット作成モードをご覧ください。
サブネットワークを作成し、リージョンと IP 範囲を指定します。
```
gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE
```
次のように置き換えます。
- SUBNETWORK_NAME: 新しいサブネットワークの名前
- NETWORK_NAME: 前の手順で作成したサービスの名前
- REGION: サブネットワークを配置するリージョン
- RANGE: CIDR 形式で指定された IP アドレス範囲（例: 10.1.0.0/24）。
  複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。
必要に応じて前の手順を繰り返し、サブネットワークを追加します。

NAT ゲートウェイの設定

パブリック IP アドレスなしで 1 台以上の VM を作成する必要がある場合は、ネットワークアドレス変換（NAT）を使用して、VM がインターネットにアクセスできるようにする必要があります。Cloud NAT は Google Cloud の分散ソフトウェア定義マネージドサービスであり、VM からインターネットへのパケットの送信と、それに対応するパケットの受信を可能にします。また、別個の VM を NAT ゲートウェイとして設定することもできます。

プロジェクトに Cloud NAT インスタンスを作成する方法については、Cloud NAT の使用をご覧ください。

プロジェクトに Cloud NAT を構成すると、VM インスタンスはパブリック IP アドレスなしでインターネットに安全にアクセスできるようになります。

ファイアウォールルールの追加

デフォルトでは、暗黙のファイアウォールルールにより、Virtual Private Cloud（VPC）ネットワークの外部からの受信接続がブロックされます。受信側の接続を許可するには、VM にファイアウォールルールを設定します。VM との受信接続が確立されると、トラフィックはその接続を介して双方向に許可されます。

SAP HANA の HA クラスタには少なくとも 2 つのファイアウォールルールが必要です。1 つは Compute Engine ヘルスチェックでクラスタノードの正常性をチェックするルール、もう 1 つはクラスタノードが相互に通信できるようにするルールです。

共有 VPC ネットワークを使用していない場合は、ノード間の通信用のファイアウォールルールを作成する必要がありますが、ヘルスチェック用に作成する必要はありません。Deployment Manager テンプレートは、ヘルスチェック用のファイアウォールルールを作成します。このファイアウォールルールは、必要に応じてデプロイ完了後に変更できます。

共有 VPC ネットワークを使用している場合、ネットワーク管理者はホストプロジェクトで両方のファイアウォールルールを作成する必要があります。

特定のポートへの外部アクセスを許可するファイアウォールルールや、同じネットワーク上の VM 間のアクセスを制限するファイアウォールルールも作成できます。VPC ネットワークタイプとして default が使用されている場合は、default-allow-internal ルールなどの追加のデフォルトルールも適用されます。追加のデフォルトルールは、同じネットワークであれば、すべてのポートで VM 間の接続を許可します。

ご使用の環境に適用可能な IT ポリシーによっては、データベースホストへの接続を分離するか制限しなければならない場合があります。これを行うには、ファイアウォールルールを作成します。

目的のシナリオに応じて、次の対象にアクセスを許可するファイアウォールルールを作成できます。

すべての SAP プロダクトの TCP/IP にリストされているデフォルトの SAP ポート。
パソコンまたは企業のネットワーク環境から Compute Engine VM インスタンスへの接続。使用すべき IP アドレスがわからない場合は、社内のネットワーク管理者に確認してください。
VM インスタンスへの SSH 接続（ブラウザでの SSH を含む）。
Linux のサードパーティ製ツールを使用した VM への接続。ファイアウォールルールを作成して、ツールのアクセスを許可します。

ファイアウォールルールを作成するには:

コンソール

Google Cloud コンソールで、VPC ネットワークの [ファイアウォール] ページに移動します。

[ファイアウォール] に移動
ページ上部の [ファイアウォールルールを作成] をクリックします。
- [ネットワーク] フィールドで、VM が配置されているネットワークを選択します。
- [ターゲット] フィールドで、このルールが適用される Google Cloud 上のリソースを指定します。たとえば、[ネットワーク上のすべてのインスタンス] を指定します。Google Cloud 上の特定のインスタンスにルールを制限するには、[指定されたターゲットタグ] にタグを入力してください。
- [ソースフィルタ] フィールドで、次のいずれかを選択します。
  - 特定の IP アドレスからの受信トラフィックを許可する場合は、[IP 範囲] を選択します。[ソース IP の範囲] フィールドで IP アドレスの範囲を指定します。
  - サブネット: 特定のサブネットワークからの受信トラフィックを許可する場合に使用します。次の [サブネット] フィールドにサブネットワーク名を指定します。このオプションを使用すると、3 層構成またはスケールアウト構成で VM 間のアクセスを許可できます。
- [プロトコルとポート] セクションで、[指定したプロトコルとポート] を選択して tcp:PORT_NUMBER を指定します。
[作成] をクリックしてファイアウォールルールを作成します。

gcloud

次のコマンドを使用して、ファイアウォールルールを作成します。

$ gcloud compute firewall-rules create FIREWALL_NAME
--direction=INGRESS --priority=1000 \
--network=NETWORK_NAME --action=ALLOW --rules=PROTOCOL:PORT \
--source-ranges IP_RANGE --target-tags=NETWORK_TAGS

SAP HANA がインストールされている高可用性 Linux クラスタを作成する

次の手順では、Cloud Deployment Manager を使用して、2 つの SAP HANA システムを備えた 1 つの RHEL クラスタまたは SLES クラスタを作成します。1 つの VM インスタンスにプライマリ単一ホストの SAP HANA システムを作成し、同じ Compute Engine リージョン内の別の VM インスタンスにスタンバイ SAP HANA システムを作成します。SAP HANA システムは同期システムレプリケーションを使用し、スタンバイシステムは複製されたデータをプリロードします。

SAP HANA 高可用性クラスタの構成オプションは、Deployment Manager 構成ファイルのテンプレートで定義します。

次の手順では Cloud Shell を使用していますが、Google Cloud CLI の場合も同様です。

永続ディスクや CPU などリソースの現在の割り当てが、インストールしようとしている SAP HANA システムに対して十分であることを確認します。割り当てが不足しているとデプロイは失敗します。SAP HANA の割り当て要件については、SAP HANA の料金と割り当てに関する考慮事項をご覧ください。

[割り当て] ページに移動
Cloud Shell を開くか、Google Cloud CLI をローカルワークステーションにインストールしている場合はターミナルを開きます。

Cloud Shell に移動
Cloud Shell または gcloud CLI で次のコマンドを入力して、SAP HANA 高可用性クラスタの template.yaml 構成ファイルテンプレートを作業ディレクトリにダウンロードします。
```
$ wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana_ha_ilb/template.yaml
```
必要に応じて template.yaml のファイル名を変更し、このファイルで定義する構成がわかるようにします。
Cloud Shell コードエディタで template.yaml ファイルを開きます。gcloud CLI を使用している場合は、任意のテキストエディタで開きます。

Cloud Shell コードエディタを開くには、Cloud Shell ターミナルウィンドウの右上にある鉛筆アイコンをクリックします。

template.yaml ファイルでは、角かっこで囲まれた部分を各自のインストール環境に合わせた値に置き換えてプロパティ値を更新します。プロパティについては、次の表をご覧ください。

SAP HANA をインストールせずに VM インスタンスを作成するには、sap_hana_ で始まるすべての行を削除またはコメントアウトします。

特性	データ型	説明
`type`	文字列	デプロイ中に使用する Deployment Manager テンプレートの場所、タイプ、バージョンを指定します。 YAML ファイルには 2 つの `type` 仕様が含まれており、そのうちの 1 つがコメントアウトされています。デフォルトで有効な `type` 仕様では、テンプレートバージョンを `latest` として指定します。コメントアウトされている `type` 仕様では、タイムスタンプを使用して特定のテンプレートバージョンを指定します。すべてのデプロイで同じテンプレートバージョンを使用する必要がある場合は、タイムスタンプを含む `type` 仕様を使用します。
`primaryInstanceName`	文字列	プライマリ SAP HANA システムの VM インスタンスの名前。小文字、数字またはハイフンを使用して名前を指定します。
`secondaryInstanceName`	文字列	セカンダリ SAP HANA システムの VM インスタンスの名前。小文字、数字またはハイフンを使用して名前を指定します。
`primaryZone`	文字列	プライマリ SAP HANA システムがデプロイされているゾーン。プライマリゾーンとセカンダリゾーンは同じリージョンにする必要があります。
`secondaryZone`	文字列	セカンダリ SAP HANA システムがデプロイされるゾーン。プライマリゾーンとセカンダリゾーンは同じリージョンにする必要があります。
`instanceType`	文字列	SAP HANA を実行する Compute Engine 仮想マシンのタイプ。カスタム VM タイプが必要な場合は、必要な数に最も近く、かつ必要数以上の vCPU 数を持つ事前定義された VM タイプを指定します。デプロイが完了したら、vCPU 数とメモリ量を変更してください。
`network`	文字列	VIP を管理するロードバランサを作成するネットワークの名前。共有 VPC ネットワークを使用している場合は、ホストプロジェクトの ID をネットワーク名の親ディレクトリとして追加する必要があります。例: `host-project-id/network-name`
`subnetwork`	文字列	HA クラスタに使用するサブネットワークの名前。共有 VPC ネットワークを使用している場合は、ホストプロジェクトの ID をサブネットワーク名の親ディレクトリとして追加する必要があります。例: `host-project-id/subnetwork-name`
`linuxImage`	文字列	SAP HANA で使用する Linux オペレーティングシステムイメージまたはイメージファミリーの名前。イメージファミリーを指定するには、ファミリー名に接頭辞 `family/` を追加しますたとえば、`family/rhel-8-2-sap-ha` や `family/sles-15-sp2-sap` です。特定のイメージを指定するには、イメージ名のみを指定します。利用可能なイメージファミリーの一覧については、Cloud コンソールの [イメージ] ページをご覧ください。
`linuxImageProject`	文字列	使用するイメージを含む Google Cloud プロジェクト。このプロジェクトは独自のプロジェクトか、Google Cloud イメージプロジェクトです。RHEL の場合は、`rhel-sap-cloud` を指定します。SLES の場合は、`suse-sap-cloud` を指定します。Google Cloud イメージプロジェクトの一覧については、Compute Engine ドキュメントのイメージのページをご覧ください。
`sap_hana_deployment_bucket`	文字列	前のステップでアップロードした SAP HANA インストールファイルを含む、プロジェクト内の Cloud Storage バケットの名前。
`sap_hana_sid`	文字列	SAP HANA システム ID。ID は英数字 3 文字で、最初の文字はアルファベットにする必要があります。文字は大文字のみ使用できます。
`sap_hana_instance_number`	整数	SAP HANA システムのインスタンス番号（0～99）。デフォルトは 0 です。
`sap_hana_sidadm_password`	文字列	デプロイ時に使用されるオペレーティングシステム管理者向けの仮のパスワード。デプロイの完了後にはパスワードを変更します。パスワードは 8 文字以上で設定し、少なくとも英大文字、英小文字、数字をそれぞれ 1 文字以上含める必要があります。デプロイの完了後にパスワードを変更します。
`sap_hana_system_password`	文字列	データベースのスーパーユーザー向けの仮のパスワード。デプロイの完了後にはパスワードを変更します。パスワードは 8 文字以上で設定し、少なくとも英大文字、英小文字、数字をそれぞれ 1 文字以上含める必要があります。デプロイが完了したら、パスワードを変更します。
`sap_vip`	文字列	VIP に使用する IP アドレス。IP アドレスは、サブネットワークに割り当てられている IP アドレスの範囲内でなければなりません。この IP アドレスは、Deployment Manager テンプレートにより予約されます。アクティブな HA クラスタでは、この IP アドレスは常にアクティブな SAP HANA インスタンスに割り当てられます。
`primaryInstanceGroupName`	文字列	プライマリノードの非マネージドインスタンスグループの名前を定義します。このパラメータを省略した場合、デフォルト名は `ig-primaryInstanceName` になります。
`secondaryInstanceGroupName`	文字列	セカンダリノードの非マネージドインスタンスグループの名前を定義します。このパラメータを省略した場合、デフォルト名は `ig-secondaryInstanceName` になります。
`loadBalancerName`	文字列	TCP 内部ロードバランサの名前を定義します。
`nic_type`	文字列	省略可。ただし、ターゲットマシンと OS バージョンに適用可能な場合は推奨します。VM インスタンスで使用するネットワークインターフェースを指定します。値には `GVNIC` または `VIRTIO_NET` を指定できます。Google Virtual NIC（gVNIC）を使用するには、`linuxImage` プロパティの値として gVNIC をサポートする OS イメージを指定する必要があります。OS イメージの一覧については、オペレーティングシステムの詳細をご覧ください。このプロパティの値を指定しなかった場合は、`instanceType` プロパティに指定したマシンタイプに基づいて、ネットワークインターフェースが自動的に選択されます。この引数は、Deployment Manager テンプレートバージョン `202302060649` 以降で使用できます。

次の例では、SAP HANA 用の高可用性クラスタを定義する、完成した構成ファイルのテンプレートが示されています。このクラスタは、内部パススルーネットワークロードバランサを使用して VIP を管理します。

Deployment Manager が、構成ファイルで定義された Google Cloud リソースをデプロイします。その後、スクリプトが処理を引き継ぎ、オペレーティングシステムの構成、SAP HANA のインストール、レプリケーションの構成、Linux HA クラスタの構成を行います。

RHEL か SLES をクリックして、ご使用のオペレーティングシステムに固有の例をご覧ください。

RHEL

resources:
- name: sap_hana_ha
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana_ha_ilb/sap_hana_ha.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/yyyymmddhhmm/dm-templates/sap_hana_ha_ilb/sap_hana_ha.py
  #
  properties:
    primaryInstanceName: example-ha-vm1
    secondaryInstanceName: example-ha-vm2
    primaryZone: us-central1-a
    secondaryZone: us-central1-c
    instanceType: n2-highmem-32
    network: example-network
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    # SAP HANA parameters
    sap_hana_deployment_bucket: my-hana-bucket
    sap_hana_sid: HA1
    sap_hana_instance_number: 00
    sap_hana_sidadm_password: TempPa55word
    sap_hana_system_password: TempPa55word
    # VIP parameters
    sap_vip: 10.0.0.100
    primaryInstanceGroupName: ig-example-ha-vm1
    secondaryInstanceGroupName: ig-example-ha-vm2
    loadBalancerName: lb-ha1
    # Additional optional properties
    networkTag: hana-ha-ntwk-tag
    serviceAccount: sap-deploy-example@example-project-123456.iam.gserviceaccount.com

SLES

resources:
- name: sap_hana_ha
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana_ha_ilb/sap_hana_ha.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/yyyymmddhhmm/dm-templates/sap_hana_ha_ilb/sap_hana_ha.py
  #
  properties:
    primaryInstanceName: example-ha-vm1
    secondaryInstanceName: example-ha-vm2
    primaryZone: us-central1-a
    secondaryZone: us-central1-c
    instanceType: n2-highmem-32
    network: example-network
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    # SAP HANA parameters
    sap_hana_deployment_bucket: my-hana-bucket
    sap_hana_sid: HA1
    sap_hana_instance_number: 00
    sap_hana_sidadm_password: TempPa55word
    sap_hana_system_password: TempPa55word
    # VIP parameters
    sap_vip: 10.0.0.100
    primaryInstanceGroupName: ig-example-ha-vm1
    secondaryInstanceGroupName: ig-example-ha-vm2
    loadBalancerName: lb-ha1
    # Additional optional properties
    networkTag: hana-ha-ntwk-tag
    serviceAccount: sap-deploy-example@example-project-123456.iam.gserviceaccount.com

次のコマンドを実行して、インスタンスを作成します。
```
$ gcloud deployment-manager deployments create deployment-name --config template-name.yaml
```
上記のコマンドによって Deployment Manager が起動され、Google Cloud インフラストラクチャが設定され、SAP HANA と HA クラスタをインストールして構成するスクリプトに制御が渡されます。

Deployment Manager により制御が行われる間、ステータスメッセージは Cloud Shell に書き込まれます。スクリプトが呼び出されると、ログを確認するで説明されているように、ステータスメッセージが Logging に書き込まれ、Google Cloud コンソールで表示できるようになります。

完了までの時間は一定ではありませんが、通常 30 分未満でプロセス全体が完了します。

HANA HA システムのデプロイを確認する

SAP HANA HA クラスタの検証では、いくつかの手順を行う必要があります。

Logging を確認する
VM と SAP HANA の構成を確認する
クラスタの構成を確認する
ロードバランサとインスタンスグループの健全性を確認する
SAP HANA Studio を使用して SAP HANA システムを確認する
フェイルオーバーテストを実行する

ログを調べる

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

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

VM と SAP HANA の構成を確認する

SAP HANA システムが正常にデプロイされたら、SSH を使用して VM に接続します。Compute Engine の [VM インスタンス] ページで、VM インスタンスの SSH ボタンをクリックするか、お好みの SSH メソッドを使用します。
root ユーザーに変更します。
```
sudo su -
```

コマンドプロンプトで df -h を実行します。/hana/data などの /hana ディレクトリを含む出力が表示されていることを確認します。

RHEL

[root@example-ha-vm1 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          126G     0  126G   0% /dev
tmpfs                             126G   54M  126G   1% /dev/shm
tmpfs                             126G   25M  126G   1% /run
tmpfs                             126G     0  126G   0% /sys/fs/cgroup
/dev/sda2                          30G  5.4G   25G  18% /
/dev/sda1                         200M  6.9M  193M   4% /boot/efi
/dev/mapper/vg_hana-shared        251G   52G  200G  21% /hana/shared
/dev/mapper/vg_hana-sap            32G  477M   32G   2% /usr/sap
/dev/mapper/vg_hana-data          426G  9.8G  417G   3% /hana/data
/dev/mapper/vg_hana-log           125G  7.0G  118G   6% /hana/log
/dev/mapper/vg_hanabackup-backup  512G  9.3G  503G   2% /hanabackup
tmpfs                              26G     0   26G   0% /run/user/900
tmpfs                              26G     0   26G   0% /run/user/899
tmpfs                              26G     0   26G   0% /run/user/1003

SLES

example-ha-vm1:~ # df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          126G  8.0K  126G   1% /dev
tmpfs                             189G   54M  189G   1% /dev/shm
tmpfs                             126G   34M  126G   1% /run
tmpfs                             126G     0  126G   0% /sys/fs/cgroup
/dev/sda3                          30G  5.4G   25G  18% /
/dev/sda2                          20M  2.9M   18M  15% /boot/efi
/dev/mapper/vg_hana-shared        251G   50G  202G  20% /hana/shared
/dev/mapper/vg_hana-sap            32G  281M   32G   1% /usr/sap
/dev/mapper/vg_hana-data          426G  8.0G  418G   2% /hana/data
/dev/mapper/vg_hana-log           125G  4.3G  121G   4% /hana/log
/dev/mapper/vg_hanabackup-backup  512G  6.4G  506G   2% /hanabackup
tmpfs                              26G     0   26G   0% /run/user/473
tmpfs                              26G     0   26G   0% /run/user/900
tmpfs                              26G     0   26G   0% /run/user/0
tmpfs                              26G     0   26G   0% /run/user/1003

オペレーティングシステムに固有の status コマンドを入力し、新しいクラスタのステータスを確認します。

RHEL

pcs status

SLES

crm status

次のような結果が表示されます。この例では、両方の VM インスタンスが開始され、example-ha-vm1 がアクティブなプライマリインスタンスになります。

RHEL

[root@example-ha-vm1 ~]# pcs status
Cluster name: hacluster
Cluster Summary:
  * Stack: corosync
  * Current DC: example-ha-vm1 (version 2.0.3-5.el8_2.4-4b1f869f0f) - partition with quorum
  * Last updated: Wed Jul  7 23:05:11 2021
  * Last change:  Wed Jul  7 23:04:43 2021 by root via crm_attribute on example-ha-vm2
  * 2 nodes configured
  * 8 resource instances configured

Node List:
  * Online: [ example-ha-vm1 example-ha-vm2 ]

Full List of Resources:
  * STONITH-example-ha-vm1      (stonith:fence_gce):    Started example-ha-vm2
  * STONITH-example-ha-vm2      (stonith:fence_gce):    Started example-ha-vm1
  * Resource Group: g-primary:
    * rsc_healthcheck_HA1       (service:haproxy):      Started example-ha-vm2
    * rsc_vip_HA1_00    (ocf::heartbeat:IPaddr2):       Started example-ha-vm2
  * Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
    * Started: [ example-ha-vm1 example-ha-vm2 ]
  * Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00] (promotable):
    * Masters: [ example-ha-vm2 ]
    * Slaves: [ example-ha-vm1 ]

Failed Resource Actions:
  * rsc_healthcheck_HA1_start_0 on example-ha-vm1 'error' (1): call=29, status='complete', exitreason='', last-rc-change='2021-07-07 21:07:35Z', queued=0ms, exec=2097ms
  * SAPHana_HA1_00_monitor_61000 on example-ha-vm1 'not running' (7): call=44, status='complete', exitreason='', last-rc-change='2021-07-07 21:09:49Z', queued=0ms, exec=0ms

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

SLES

example-ha-vm1:~ # crm status
Cluster Summary:
  * Stack: corosync
  * Current DC: example-ha-vm1 (version 2.0.4+20200616.2deceaa3a-3.9.1-2.0.4+20200616.2deceaa3a) - partition with quorum
  * Last updated: Wed Jul  7 22:57:59 2021
  * Last change:  Wed Jul  7 22:57:03 2021 by root via crm_attribute on example-ha-vm1
  * 2 nodes configured
  * 8 resource instances configured

Node List:
  * Online: [ example-ha-vm1 example-ha-vm2 ]

Full List of Resources:
  * STONITH-example-ha-vm1      (stonith:external/gcpstonith):   Started example-ha-vm2
  * STONITH-example-ha-vm2      (stonith:external/gcpstonith):   Started example-ha-vm1
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started example-ha-vm1
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started example-ha-vm1
  * Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
    * Started: [ example-ha-vm1 example-ha-vm2 ]
  * Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
    * Masters: [ example-ha-vm1 ]
    * Slaves: [ example-ha-vm2 ]

次のコマンドの SID_LC を構成ファイルのテンプレートで指定した SID 値で置き換え、SAP 管理ユーザーに変更します。すべて小文字を使用します。
```
su - SID_LCadm
```
次のコマンドを入力して、hdbnameserver、hdbindexserver などの SAP HANA サービスがインスタンス上で実行されていることを確認します。
```
HDB info
```
RHEL for SAP 9.0 以降を使用する場合は、パッケージ chkconfig と compat-openssl11 が VM インスタンスにインストールされていることを確認してください。

SAP の詳細については、SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installation and Configuration をご覧ください。

クラスタの構成を確認する

クラスタのパラメータ設定を確認します。クラスタソフトウェアに表示される設定とクラスタ構成ファイルのパラメータ設定の両方を確認します。設定例を、以下の例で使用されている設定と比較してください。これらの設定は、このガイドで使用されている自動化スクリプトによって作成されたものです。

ご使用のオペレーティングシステムのタブをクリックしてください。

RHEL

クラスタリソース構成を表示します。

pcs config show

次の例は、RHEL 8.1 以降の自動化スクリプトによって作成されるリソース構成を示しています。

RHEL 7.7 以前を実行している場合、リソース定義 Clone: SAPHana_HA1_00-clone に Meta Attrs: promotable=true は含まれません。

 Cluster Name: hacluster
 Corosync Nodes:
  example-rha-vm1 example-rha-vm2
 Pacemaker Nodes:
  example-rha-vm1 example-rha-vm2

 Resources:
  Group: g-primary
   Resource: rsc_healthcheck_HA1 (class=service type=haproxy)
    Operations: monitor interval=10s timeout=20s (rsc_healthcheck_HA1-monitor-interval-10s)
                start interval=0s timeout=100 (rsc_healthcheck_HA1-start-interval-0s)
                stop interval=0s timeout=100 (rsc_healthcheck_HA1-stop-interval-0s)
   Resource: rsc_vip_HA1_00 (class=ocf provider=heartbeat type=IPaddr2)
    Attributes: cidr_netmask=32 ip=10.128.15.100 nic=eth0
    Operations: monitor interval=3600s timeout=60s (rsc_vip_HA1_00-monitor-interval-3600s)
                start interval=0s timeout=20s (rsc_vip_HA1_00-start-interval-0s)
                stop interval=0s timeout=20s (rsc_vip_HA1_00-stop-interval-0s)
  Clone: SAPHanaTopology_HA1_00-clone
   Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
   Resource: SAPHanaTopology_HA1_00 (class=ocf provider=heartbeat type=SAPHanaTopology)
    Attributes: InstanceNumber=00 SID=HA1
    Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_00-methods-interval-0s)
                monitor interval=10 timeout=600 (SAPHanaTopology_HA1_00-monitor-interval-10)
                reload interval=0s timeout=5 (SAPHanaTopology_HA1_00-reload-interval-0s)
                start interval=0s timeout=600 (SAPHanaTopology_HA1_00-start-interval-0s)
                stop interval=0s timeout=300 (SAPHanaTopology_HA1_00-stop-interval-0s)
  Clone: SAPHana_HA1_00-clone
   Meta Attrs: promotable=true
   Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHana)
    Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
    Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
    Operations: demote interval=0s timeout=3600 (SAPHana_HA1_00-demote-interval-0s)
                methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s)
                monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)
                monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59)
                promote interval=0s timeout=3600 (SAPHana_HA1_00-promote-interval-0s)
                reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s)
                start interval=0s timeout=3600 (SAPHana_HA1_00-start-interval-0s)
                stop interval=0s timeout=3600 (SAPHana_HA1_00-stop-interval-0s)

 Stonith Devices:
  Resource: STONITH-example-rha-vm1 (class=stonith type=fence_gce)
   Attributes: pcmk_delay_max=30 pcmk_monitor_retries=4 pcmk_reboot_timeout=300 port=example-rha-vm1 project=sap-certification-env zone=us-central1-a
   Operations: monitor interval=300s timeout=120s (STONITH-example-rha-vm1-monitor-interval-300s)
               start interval=0 timeout=60s (STONITH-example-rha-vm1-start-interval-0)
  Resource: STONITH-example-rha-vm2 (class=stonith type=fence_gce)
   Attributes: pcmk_monitor_retries=4 pcmk_reboot_timeout=300 port=example-rha-vm2 project=sap-certification-env zone=us-central1-c
   Operations: monitor interval=300s timeout=120s (STONITH-example-rha-vm2-monitor-interval-300s)
               start interval=0 timeout=60s (STONITH-example-rha-vm2-start-interval-0)
 Fencing Levels:

 Location Constraints:
   Resource: STONITH-example-rha-vm1
     Disabled on: example-rha-vm1 (score:-INFINITY) (id:location-STONITH-example-rha-vm1-example-rha-vm1--INFINITY)
   Resource: STONITH-example-rha-vm2
     Disabled on: example-rha-vm2 (score:-INFINITY) (id:location-STONITH-example-rha-vm2-example-rha-vm2--INFINITY)
 Ordering Constraints:
   start SAPHanaTopology_HA1_00-clone then start SAPHana_HA1_00-clone (kind:Mandatory) (non-symmetrical) (id:order-SAPHanaTopology_HA1_00-clone-SAPHana_HA1_00-clone-mandatory)
 Colocation Constraints:
   g-primary with SAPHana_HA1_00-clone (score:4000) (rsc-role:Started) (with-rsc-role:Master) (id:colocation-g-primary-SAPHana_HA1_00-clone-4000)
 Ticket Constraints:

 Alerts:
  No alerts defined

 Resources Defaults:
  migration-threshold=5000
  resource-stickiness=1000
 Operations Defaults:
  timeout=600s

 Cluster Properties:
  cluster-infrastructure: corosync
  cluster-name: hacluster
  dc-version: 2.0.2-3.el8_1.2-744a30d655
  have-watchdog: false
  stonith-enabled: true
  stonith-timeout: 300s

 Quorum:
   Options:

クラスタ構成ファイル corosync.conf を表示します。

cat /etc/corosync/corosync.conf

次の例に、RHEL 8.1 以降用に自動化スクリプトによって設定されたパラメータを示します。

RHEL 7.7 以前を使用している場合、transport: の値は knet ではなく udpu です。

 totem {
     version: 2
     cluster_name: hacluster
     transport: knet
     join: 60
     max_messages: 20
     token: 20000
     token_retransmits_before_loss_const: 10
     crypto_cipher: aes256
     crypto_hash: sha256
 }

 nodelist {
     node {
         ring0_addr: example-rha-vm1
         name: example-rha-vm1
         nodeid: 1
     }

     node {
         ring0_addr: example-rha-vm2
         name: example-rha-vm2
         nodeid: 2
     }
 }

 quorum {
     provider: corosync_votequorum
     two_node: 1
 }

 logging {
     to_logfile: yes
     logfile: /var/log/cluster/corosync.log
     to_syslog: yes
     timestamp: on
 }

SLES

クラスタリソース構成を表示します。

crm config show

このガイドで使用する自動化スクリプトでは、次の例に示すリソース構成を作成します。

 node 1: example-ha-vm1 \
         attributes hana_ha1_op_mode=logreplay lpa_ha1_lpt=1635380335 hana_ha1_srmode=syncmem hana_ha1_vhost=example-ha-vm1 hana_ha1_remoteHost=example-ha-vm2 hana_ha1_site=example-ha-vm1
 node 2: example-ha-vm2 \
         attributes lpa_ha1_lpt=30 hana_ha1_op_mode=logreplay hana_ha1_vhost=example-ha-vm2 hana_ha1_site=example-ha-vm2 hana_ha1_srmode=syncmem hana_ha1_remoteHost=example-ha-vm1
 primitive STONITH-example-ha-vm1 stonith:external/gcpstonith \
         op monitor interval=300s timeout=120s \
         op start interval=0 timeout=60s \
         params instance_name=example-ha-vm1 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
 primitive STONITH-example-ha-vm2 stonith:external/gcpstonith \
         op monitor interval=300s timeout=120s \
         op start interval=0 timeout=60s \
         params instance_name=example-ha-vm2 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4
 primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
         operations $id=rsc_sap2_HA1_HDB00-operations \
         op monitor interval=10 timeout=600 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=300 \
         params SID=HA1 InstanceNumber=00
 primitive rsc_SAPHana_HA1_HDB00 ocf:suse:SAPHana \
         operations $id=rsc_sap_HA1_HDB00-operations \
         op start interval=0 timeout=3600 \
         op stop interval=0 timeout=3600 \
         op promote interval=0 timeout=3600 \
         op demote interval=0 timeout=3600 \
         op monitor interval=60 role=Master timeout=700 \
         op monitor interval=61 role=Slave timeout=700 \
         params SID=HA1 InstanceNumber=00 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true
 primitive rsc_vip_hc-primary anything \
         params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:60000,backlog=10,fork,reuseaddr /dev/null" \
         op monitor timeout=20s interval=10s \
         op_params depth=0
 primitive rsc_vip_int-primary IPaddr2 \
         params ip=10.128.15.101 cidr_netmask=32 nic=eth0 \
         op monitor interval=3600s timeout=60s
 group g-primary rsc_vip_int-primary rsc_vip_hc-primary
 ms msl_SAPHana_HA1_HDB00 rsc_SAPHana_HA1_HDB00 \
         meta notify=true clone-max=2 clone-node-max=1 target-role=Started interleave=true
 clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
         meta clone-node-max=1 target-role=Started interleave=true
 location LOC_STONITH_example-ha-vm1 STONITH-example-ha-vm1 -inf: example-ha-vm1
 location LOC_STONITH_example-ha-vm2 STONITH-example-ha-vm2 -inf: example-ha-vm2
 colocation col_saphana_ip_HA1_HDB00 4000: g-primary:Started msl_SAPHana_HA1_HDB00:Master
 order ord_SAPHana_HA1_HDB00 Optional: cln_SAPHanaTopology_HA1_HDB00 msl_SAPHana_HA1_HDB00
 property cib-bootstrap-options: \
         have-watchdog=false \
         dc-version="1.1.24+20210811.f5abda0ee-3.18.1-1.1.24+20210811.f5abda0ee" \
         cluster-infrastructure=corosync \
         cluster-name=hacluster \
         maintenance-mode=false \
         stonith-timeout=300s \
         stonith-enabled=true
 rsc_defaults rsc-options: \
         resource-stickiness=1000 \
         migration-threshold=5000
 op_defaults op-options: \
         timeout=600

クラスタ構成ファイル corosync.conf を表示します。

cat /etc/corosync/corosync.conf

このガイドで使用する自動化スクリプトは、次の例のように corosync.conf ファイルでパラメータ設定を指定します。

 totem {
   version: 2
   secauth: off
   crypto_hash: sha1
   crypto_cipher: aes256
   cluster_name: hacluster
   clear_node_high_bit: yes
   token: 20000
   token_retransmits_before_loss_const: 10
   join: 60
   max_messages: 20
   transport: udpu
   interface {
     ringnumber: 0
     bindnetaddr: 10.128.1.63
     mcastport: 5405
     ttl: 1
   }
 }
 logging {
   fileline: off
   to_stderr: no
   to_logfile: no
   logfile: /var/log/cluster/corosync.log
   to_syslog: yes
   debug: off
   timestamp: on
   logger_subsys {
     subsys: QUORUM
     debug: off
   }
 }
 nodelist {
   node {
     ring0_addr: example-ha-vm1
     nodeid: 1
   }
   node {
     ring0_addr: example-ha-vm2
     nodeid: 2
   }
 }
 quorum {
   provider: corosync_votequorum
   expected_votes: 2
   two_node: 1
 }

ロードバランサとインスタンスグループの健全性を確認する

ロードバランサとヘルスチェックが正しくセットアップされていることを確認するには、Google Cloud コンソールでロードバランサとインスタンスグループを確認します。

Google Cloud コンソールで [ロードバランシング] ページを開きます。

[Cloud Load Balancing] に移動
ロードバランサのリストで、HA クラスタ用のロードバランサが作成されたことを確認します。

注: 「1 個のバックエンドサービスが正常でありません」という警告は無視してかまいません。HA クラスタでは、ロードバランサはアクティブノードのみを正常として登録します。
[ロードバランサの詳細] ページの [バックエンド] セクションで、[インスタンスグループ] の [正常] 列の片方のインスタンスグループが「1/1」、もう片方が「0/1」と表示されていることを確認します。フェイルオーバー後、正常なインジケーター「1/1」が新しいアクティブなインスタンスグループに切り替わります。

SAP HANA Studio を使用して SAP HANA システムを確認する

SAP HANA Cockpit または SAP HANA Studio を使用すると、高可用性クラスタで SAP HANA システムをモニタリングし、管理できます。

SAP HANA Studio を使用して HANA システムに接続します。接続を定義するときに、次の値を指定します。
- [Specify System] パネルで、ホスト名としてフローティング IP アドレスを指定します。
- [Connection Properties] パネルのデータベースユーザー認証で、データベースのスーパーユーザー名と、template.yaml ファイルの sap_hana_system_password プロパティで指定したパスワードを入力します。
SAP から提供されている SAP HANA Studio のインストール情報については、SAP HANA Studio のインストールおよび更新ガイドをご覧ください。
SAP HANA Studio が HANA HA システムに接続したら、ウィンドウ左側のナビゲーションパネルでシステム名をダブルクリックして、システム概要を表示します。
[Overview] タブの [General Information] で次のことを確認します。
- [Operational Status] に「All services started」と表示されます。
- [System Replication Status] に「All services are active and in sync」と表示されます。
[General Information] の [System Replication Status] をクリックして、レプリケーションモードを確認します。同期レプリケーションの場合、[System Replication] タブの [REPLICATION_MODE] 列に SYNCMEM が表示されます。

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

エラーを解決します。
[Deployments] ページからデプロイを削除します。
前のセクションの最後の手順で説明したように、インスタンスを再作成します。

フェイルオーバーテストを行う

フェイルオーバーを行うには:

SSH を使用してプライマリ VM に接続します。各 VM インスタンスの SSH ボタンをクリックして、Compute Engine の [VM インスタンス] ページから接続するか、任意の SSH メソッドを使用できます。
コマンドプロンプトで、次のコマンドを入力します。
```
sudo ip link set eth0 down
```
ip link set eth0 down コマンドは、プライマリホストとの通信を切断し、フェイルオーバーをトリガーします。
SSH を使用していずれかのホストに再接続し、root ユーザーに変更します。

セカンダリホストの格納に使用していた VM でプライマリホストがアクティブになっていることを確認します。クラスタで自動再起動が有効になっているため、停止したホストが再起動し、セカンダリホストの役割を引き継ぎます。

RHEL

pcs status

SLES

crm status

次の例では、各ホストで役割が切り替わっています。

RHEL

[root@example-ha-vm1 ~]# pcs status
Cluster name: hacluster
Cluster Summary:
  * Stack: corosync
  * Current DC: example-ha-vm1 (version 2.0.3-5.el8_2.3-4b1f869f0f) - partition with quorum
  * Last updated: Fri Mar 19 21:22:07 2021
  * Last change:  Fri Mar 19 21:21:28 2021 by root via crm_attribute on example-ha-vm2
  * 2 nodes configured
  * 8 resource instances configured

Node List:
  * Online: [ example-ha-vm1 example-ha-vm2 ]

Full List of Resources:
  * STONITH-example-ha-vm1  (stonith:fence_gce):    Started example-ha-vm2
  * STONITH-example-ha-vm2  (stonith:fence_gce):    Started example-ha-vm1
  * Resource Group: g-primary:
    * rsc_healthcheck_HA1   (service:haproxy):  Started example-ha-vm2
    * rsc_vip_HA1_00    (ocf::heartbeat:IPaddr2):   Started example-ha-vm2
  * Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
    * Started: [ example-ha-vm1 example-ha-vm2 ]
  * Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00] (promotable):
    * Masters: [ example-ha-vm2 ]
    * Slaves: [ example-ha-vm1 ]

SLES

example-ha-vm2:~ #
Cluster Summary:
  * Stack: corosync
  * Current DC: example-ha-vm2 (version 2.0.4+20200616.2deceaa3a-3.9.1-2.0.4+20200616.2deceaa3a) - partition with quorum
  * Last updated: Thu Jul  8 17:33:44 2021
  * Last change:  Thu Jul  8 17:33:07 2021 by root via crm_attribute on example-ha-vm2
  * 2 nodes configured
  * 8 resource instances configured

Node List:
  * Online: [ example-ha-vm1 example-ha-vm2 ]

Full List of Resources:
  * STONITH-example-ha-vm1      (stonith:external/gcpstonith):   Started example-ha-vm2
  * STONITH-example-ha-vm2      (stonith:external/gcpstonith):   Started example-ha-vm1
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started example-ha-vm2
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started example-ha-vm2
  * Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
    * Started: [ example-ha-vm1 example-ha-vm2 ]
  * Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
    * Masters: [ example-ha-vm2 ]
    * Slaves: [ example-ha-vm1 ]

コンソールの [ロードバランサの詳細] ページで、[正常] 列に新しいアクティブなプライマリインスタンスのステータスが「1/1」と表示されていることを確認します。必要に応じてページを更新します。

[Cloud Load Balancing] に移動

例:
SAP HANA Studio で、ナビゲーションパネルのシステムエントリをダブルクリックしてシステム情報を更新し、システムに接続していることを確認します。
[System Replication Status] リンクをクリックして、プライマリホストとセカンダリホストでホストが切り替わり、アクティブになっていることを確認します。

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

SAP HANA のモニタリングを設定する

必要に応じて、Google Cloud の SAP 用エージェントを使用して SAP HANA インスタンスをモニタリングできます。バージョン 2.0 以降では、SAP HANA モニタリング指標を収集して Cloud Monitoring に送信するようにエージェントを構成できます。Cloud Monitoring を使用すると、これらの指標を可視化するダッシュボードを作成し、指標のしきい値などに基づくアラートを設定できます。

Google Cloud の SAP 用エージェントを使用して HA クラスタをモニタリングするには、エージェントの高可用性構成のガイダンスに従ってください。

Google Cloud の SAP 用エージェントを使用している SAP HANA モニタリング指標の収集の詳細については、SAP HANA モニタリング指標の収集をご覧ください。

SAP HANA Fast Restart を有効にする

Google Cloud では、SAP HANA の各インスタンス（特に大規模なインスタンス）で SAP HANA Fast Restart を有効にすることを強くおすすめします。SAP HANA Fast Restart により、SAP HANA の終了後もオペレーティングシステムが稼働し続けている場合の再起動時間が短縮されます。

Google Cloud が提供する自動化スクリプトによって構成されるように、オペレーティングシステムとカーネルの設定は、すでに SAP HANA 高速再起動をサポートしています。tmpfs ファイルシステムを定義し、SAP HANA を構成する必要があります。

tmpfs ファイルシステムを定義して SAP HANA を構成するには、手動の手順を行うか、Google Cloud が提供する自動化スクリプトを使用して SAP HANA Fast Restart を有効にします。詳細については、次の情報をご覧ください。

手動で行う場合の手順: SAP HANA Fast Restart を有効にする
自動で行う場合の手順: SAP HANA Fast Restart を有効にする

SAP HANA Fast Restart の詳しい手順については、SAP HANA Fast Restart オプションのドキュメントをご覧ください。

手動で行う場合の手順

`tmpfs` ファイルシステムを構成する

ホスト VM とベースとなる SAP HANA システムが正常にデプロイされたら、tmpfs ファイルシステムで NUMA ノードのディレクトリを作成してマウントする必要があります。

VM の NUMA トポロジを表示する

必要な tmpfs ファイルシステムをマッピングする前に、VM に含まれる NUMA ノードの数を確認する必要があります。Compute Engine VM で利用可能な NUMA ノードを表示するには、次のコマンドを入力します。

lscpu | grep NUMA

たとえば、m2-ultramem-208 VM タイプには、次の例に示すように、0～3 の番号が付いた 4 つの NUMA ノードがあります。

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207

NUMA ノードディレクトリを作成する

VM に NUMA ノードごとにディレクトリを作成し、権限を設定します。

たとえば、0～3 の番号が付いた 4 つの NUMA ノードの場合、次のようになります。

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID

NUMA ノードディレクトリを `tmpfs` にマウントする

tmpfs ファイルシステムディレクトリをマウントし、mpol=prefer を使用してそれぞれの NUMA ノードの優先順位を指定します。

SID: SID を大文字で指定します。

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID

`/etc/fstab` を更新する

オペレーティングシステムの再起動後にマウントポイントを使用できるようにするには、次のように、ファイルシステムテーブル /etc/fstab にエントリを追加します。

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

省略可: メモリ使用量の上限を設定する

tmpfs ファイルシステムは動的に拡張および縮小できます。

tmpfs ファイルシステムで使用されるメモリを制限するには、size オプションを使用して NUMA ノードボリュームのサイズ制限を設定します。次に例を示します。

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

また、global.ini ファイルの [memorymanager] セクションで persistent_memory_global_allocation_limit パラメータを設定して、特定の SAP HANA インスタンスと特定のサーバーノードにおけるすべての NUMA ノードについて、全体的な tmpfs メモリ使用量を制限できます。

Fast Restart 用の SAP HANA の構成

Fast Restart 用に SAP HANA を構成するには、global.ini ファイルを更新し、永続メモリに保存するテーブルを指定します。

`global.ini` ファイルの `[persistence]` セクションを更新する

tmpfs の場所を参照するように、SAP HANA の global.ini ファイルの [persistence] セクションを構成します。各 tmpfs の場所をセミコロンで区切ります。

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

上記の例では、4 つの NUMA ノードに 4 つのメモリボリュームを指定しています。これは、m2-ultramem-208 に対応しています。m2-ultramem-416 で実行している場合は、8 つのメモリボリューム（0～7）を構成する必要があります。

global.ini ファイルを変更したら、SAP HANA を再起動します。

SAP HANA では、tmpfs の場所を永続メモリ領域として使用できるようになりました。

永続メモリに保存するテーブルを指定する

永続メモリに保存する特定の列テーブルまたはパーティションを指定します。

たとえば、既存のテーブルの永続メモリを有効にするには、SQL クエリを実行します。

ALTER TABLE exampletable persistent memory ON immediate CASCADE

新しいテーブルのデフォルトを変更するには、indexserver.ini ファイルにパラメータ table_default を追加します。次に例を示します。

[persistent_memory]
table_default = ON

列、テーブルのコントロール方法の詳細や、どのモニタリングビューが詳細情報を提供するかは、SAP HANA 永続メモリをご確認ください。

自動で行う場合の手順

Google Cloud が提供する自動化スクリプトは、SAP HANA Fast Restart を有効にするためにディレクトリ /hana/tmpfs*、ファイル /etc/fstab、SAP HANA の構成を変更します。スクリプトを実行する際に、これが SAP HANA システムの初期デプロイか、マシンを別の NUMA サイズに変更するかによって、追加の手順が必要になる場合があります。

SAP HANA システムの初期デプロイや、NUMA ノードの数を増やすためにマシンのサイズを変更する場合は、Google Cloud 提供の自動化スクリプトで SAP HANA Fast Restart を有効にするときに、SAP HANA が稼働している必要があります。

NUMA ノードの数を減らすためにマシンサイズを変更する場合は、Google Cloud 提供の自動化スクリプトで SAP HANA Fast Restart を有効にするときに、SAP HANA が停止している必要があります。スクリプトの実行後、SAP HANA の構成を手動で更新し、SAP HANA Fast Restart の設定を完了する必要があります。詳細については、Fast Restart 用の SAP HANA の構成をご覧ください。

SAP HANA Fast Restart を有効にするには、次の手順を行います。

ホスト VM との SSH 接続を確立します。
root に切り替えます。
```
sudo su -
```

sap_lib_hdbfr.sh スクリプトをダウンロードします。

wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

ファイルを実行可能にします。
```
chmod +x sap_lib_hdbfr.sh
```
スクリプトにエラーがないことを確認します。
```
vi sap_lib_hdbfr.sh
./sap_lib_hdbfr.sh -help
```
コマンドからエラーが返された場合は、Cloud カスタマーケアにお問い合わせください。カスタマーケアへのお問い合わせ方法については、Google Cloud での SAP に関するサポートを受けるをご覧ください。
スクリプトを実行する前に、SAP HANA のシステム ID（SID）とパスワードを SAP HANA データベースの SYSTEM ユーザーのものと置き換えてください。パスワードを安全に提供するには、Secret Manager でシークレットを使用することをおすすめします。

Secret Manager で、シークレットの名前を使用してスクリプトを実行します。このシークレットは、ホスト VM インスタンスを含む Google Cloud プロジェクトに存在している必要があります。
```
sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME 
```
次のように置き換えます。
- SID: SID を大文字で指定します。例: AHA
- SECRET_NAME: SAP HANA データベースの SYSTEM ユーザーのパスワードに対応するシークレットの名前を指定します。このシークレットは、ホスト VM インスタンスを含む Google Cloud プロジェクトに存在している必要があります。
書式なしテキストのパスワードを使用してスクリプトを実行することもできます。SAP HANA Fast Restart を有効にした後、パスワードを変更します。パスワードは VM のコマンドライン履歴に記録されるため、書式なしテキストのパスワードの使用はおすすめしません。
```
sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'
```
次のように置き換えます。
- SID: SID を大文字で指定します。例: AHA
- PASSWORD: SAP HANA データベースの SYSTEM ユーザーのパスワードを指定します。

初期実行に成功すると、次のような出力が表示されます。

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

SAP HANA 用の Google モニタリングエージェントを設定する

必要に応じて、SAP HANA 用に Google のモニタリングエージェントを設定できます。これは、SAP HANA から指標を収集して、Monitoring に送信するものです。Monitoring を使用すると、指標に関するダッシュボードの作成や、指標のしきい値に基づいたカスタムアラートの設定が可能になります。

HA クラスタをモニタリングするには、クラスタの外部の VM インスタンスにモニタリングエージェントをインストールします。モニタリングするホストインスタンスの IP アドレスとして、クラスタのフローティング IP アドレスを指定します。

SAP HANA 用の Google モニタリングエージェントの設定と構成の詳細については、SAP HANA モニタリングエージェントユーザーガイドをご覧ください。

SAP HANA に接続する

この手順では SAP HANA に外部 IP を使用しないため、SAP HANA インスタンスに接続できるのは、SSH を使用して踏み台インスタンスを経由するか、SAP HANA Studio を使用して Windows サーバーを経由する場合だけになるのでご注意ください。

踏み台インスタンスを介して SAP HANA に接続するには、踏み台インスタンスに接続してから、任意の SSH クライアントを使用して SAP HANA インスタンスに接続します。
SAP HANA Studio を経由して SAP HANA データベースに接続するには、リモートデスクトップクライアントを使用して、Windows Server インスタンスに接続します。接続後、手動で SAP HANA Studio をインストールし、SAP HANA データベースにアクセスします。

HANA アクティブ / アクティブ構成（読み取り可能）を構成する

SAP HANA 2.0 SPS1 以降では、Pacemaker クラスタで HANA アクティブ / アクティブ（読み取り可能）を構成できます。手順については、以下をご覧ください。

デプロイ後の作業を実行する

SAP HANA インスタンスを使用する前に、次のデプロイ後の手順を実行することをおすすめします。詳細については、SAP HANA のインストールおよび更新ガイドをご覧ください。

SAP HANA システム管理者とデータベースのスーパーユーザーの仮のパスワードを変更します。
SAP HANA ソフトウェアを、最新のパッチで更新します。
アプリケーション機能ライブラリ（AFL）またはスマートデータアクセス（SDA）などの、追加コンポーネントがあればインストールします。
新しい SAP HANA データベースを、構成してバックアップをとります。詳細については、SAP HANA オペレーションガイドをご覧ください。

次のステップ

VM の管理とモニタリングの詳細については、SAP HANA 運用ガイドをご覧ください。

Deployment Manager: SAP HANA スケールアップ高可用性クラスタ構成ガイド

前提条件

ネットワークの作成

コンソール

gcloud

NAT ゲートウェイの設定

ファイアウォール ルールの追加

コンソール

gcloud

SAP HANA がインストールされている高可用性 Linux クラスタを作成する

RHEL

SLES

HANA HA システムのデプロイを確認する

ログを調べる

ログ エクスプローラ

以前のログビューア

VM と SAP HANA の構成を確認する

RHEL

SLES

RHEL

SLES

RHEL

SLES

クラスタの構成を確認する

RHEL

SLES

ロードバランサとインスタンス グループの健全性を確認する

SAP HANA Studio を使用して SAP HANA システムを確認する

フェイルオーバー テストを行う

RHEL

SLES

RHEL

SLES

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

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

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

SAP HANA のモニタリングを設定する

SAP HANA Fast Restart を有効にする

手動で行う場合の手順

tmpfs ファイル システムを構成する

VM の NUMA トポロジを表示する

NUMA ノード ディレクトリを作成する

NUMA ノード ディレクトリを tmpfs にマウントする

/etc/fstab を更新する

省略可: メモリ使用量の上限を設定する

Fast Restart 用の SAP HANA の構成

global.ini ファイルの [persistence] セクションを更新する

永続メモリに保存するテーブルを指定する

自動で行う場合の手順

SAP HANA 用の Google モニタリング エージェントを設定する

SAP HANA に接続する

HANA アクティブ / アクティブ構成（読み取り可能）を構成する

デプロイ後の作業を実行する

次のステップ

ファイアウォールルールの追加

ログエクスプローラ

ロードバランサとインスタンスグループの健全性を確認する

フェイルオーバーテストを行う

`tmpfs` ファイルシステムを構成する

NUMA ノードディレクトリを作成する

NUMA ノードディレクトリを `tmpfs` にマウントする

`/etc/fstab` を更新する

`global.ini` ファイルの `[persistence]` セクションを更新する

SAP HANA 用の Google モニタリングエージェントを設定する