SLES での SAP HANA の HA スケールアウトクラスタの構成ガイド

このガイドでは、Google Cloud 上の SAP HANA スケールアウトシステムに、パフォーマンスが最適化された SUSE Linux Enterprise Server（SLES）高可用性（HA）クラスタをデプロイして構成する方法について説明します。

このガイドでは、次の手順について説明します。

障害発生時にトラフィックを再ルーティングするように内部パススルーネットワークロードバランサを構成する
SLES に Pacemaker クラスタを構成して、フェイルオーバー中に SAP システムやその他のリソースを管理する

このガイドでは、SAP HANA システムレプリケーションを構成する手順についても説明します。具体的な手順については、SAP のドキュメントをご覧ください。

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

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

このガイドでデプロイするシステム

このガイドでは、マジョリティメーカーとして機能する追加のインスタンス（タイブレーカーノードとも呼ばれる）を備えた、完全なゾーン冗長性を実現するように構成されたマルチノード SAP HANA HA システムをデプロイします。これにより、1 つのゾーンが失われても、クラスタクォーラムが維持されるようになります。

最終的なデプロイは、次のリソースで構成されます。

プライマリインスタンスとセカンダリサイト。各インスタンスにゾーンがあります。
同期レプリケーション用に構成された 2 つのサイト。
マジョリティメーカーとして機能する 1 つのコンピューティングインスタンス。
フェンシングメカニズムを備えた Pacemaker 高可用性クラスタリソースマネージャー。
各 SAP HANA インスタンスにアタッチされた SAP HANA データおよびログボリューム用の永続ディスク。

マルチノード SAP HANA スケールアウトシステムの高可用性 Linux クラスタの概要

このガイドでは、Google Cloud が提供する Terraform テンプレートを使用して、Compute Engine 仮想マシン（VM）と SAP HANA インスタンスをデプロイすることで、VM とベースとなる SAP HANA システムが SAP のサポート要件を満たし、現在のベストプラクティスを遵守するようにします。

このガイドでは、SAP HANA Studio を使用して SAP HANA システムのレプリケーションをテストします。必要に応じて、SAP HANA Cockpit を代わりに使用することもできます。SAP HANA Studio のインストールについては、以下をご覧ください。

前提条件

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 です。詳細については、次のトピックをご覧ください。
スケールアウトした SAP HANA システムのホスト間で SAP HANA の /hana/shared ボリュームと /hanabackup ボリュームを共有するために、マネージド Filestore ソリューションなどの NFS ソリューションが用意されている。Filestore NFS サーバーをデプロイするには、インスタンスの作成をご覧ください。
- データの上書きを避けるため、プライマリサイトとセカンダリサイトはそれぞれ専用の NFS パスにアクセスできる必要があります。単一の Filestore インスタンスを使用するには、個別のサブディレクトリをマウントパスとして使用するように、デプロイを構成する必要があります。

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 との受信接続が確立されると、トラフィックはその接続を介して双方向に許可されます。

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

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

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

すべての SAP プロダクトの TCP/IP にリストされているデフォルトの SAP ポート。
パソコンまたは企業のネットワーク環境から Compute Engine VM インスタンスへの接続。使用すべき IP アドレスがわからない場合は、社内のネットワーク管理者に確認してください。

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

コンソール

Google Cloud コンソールで、Compute Engine の [ファイアウォール] ページに移動します。

[ファイアウォール] に移動
ページ上部の [ファイアウォールルールを作成] をクリックします。
- [ネットワーク] フィールドで、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

VM と SAP HANA のデプロイ

完全なゾーン冗長性を備えたマルチノードの SAP HANA HA システムをデプロイするには、構成のベースとして SAP HANA 用の Cloud Deployment Manager テンプレートを使用し、さらに、マジョリティメーカーインスタンスをデプロイするための追加のテンプレートを使用します。

デプロイメントは次のものから構成されます。

2 つの同じ SAP HANA システム（それぞれ複数のワーカーノードを持つ）。
タイブレーカーノードとも呼ばれる 1 つのマジョリティメーカーインスタンス。これにより、1 つのゾーンが失われても、クラスタクォーラムが維持されるようになります。

Deployment Manager によって 1 回のデプロイですべてのリソースがデプロイされるように、すべてのシステムの定義を同じ YAML ファイルに追加します。SAP HANA システムとマジョリティメーカーインスタンスが正常にデプロイされたら、HA クラスタを定義して構成します。

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

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

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

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

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

template.yaml ファイルで、プライマリ SAP HANA システムの定義を完了します。プロパティ値を指定するには、かっことその内容をご使用のインストール環境の値に置き換えます。プロパティについては、次のテーブルをご覧ください。

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

特性	データ型	説明
type	文字列	デプロイ中に使用する Deployment Manager テンプレートの場所、タイプ、バージョンを指定します。 YAML ファイルには 2 つの `type` 仕様が含まれており、そのうちの 1 つがコメントアウトされています。デフォルトで有効な `type` 仕様では、テンプレートバージョンを `latest` として指定します。コメントアウトされている `type` 仕様では、タイムスタンプを使用して特定のテンプレートバージョンを指定します。すべてのデプロイで同じテンプレートバージョンを使用する必要がある場合は、タイムスタンプを含む `type` 仕様を使用します。
`instanceName`	文字列	現在定義されている VM インスタンスの名前。プライマリ VM とセカンダリ VM の定義で異なる名前を指定します。名前は小文字、数字、ハイフンで指定する必要があります。
`instanceType`	文字列	SAP HANA を実行する Compute Engine 仮想マシンのタイプ。カスタム VM タイプが必要な場合は、必要な数に最も近く、かつ必要数以上の vCPU 数を持つ事前定義された VM タイプを指定します。デプロイが完了したら、vCPU の数とメモリ量を変更します。マジョリティメーカーインスタンスに推奨される最小の `instanceType` は `n1-standard-2` か、2 基以上の CPU コアと 2 GB のメモリを備えたタイプになります。
`zone`	文字列	定義している VM インスタンスをデプロイする Google Cloud ゾーン。プライマリ HANA、セカンダリ HANA、マジョリティメーカーインスタンスの定義に同じリージョンの異なるゾーンを指定します。このゾーンは、サブネットに選択したのと同じリージョンに存在する必要があります。
`subnetwork`	文字列	前のステップで作成したサブネットワークの名前。共有 VPC にデプロイする場合は、この値を `[SHAREDVPC_PROJECT]/[SUBNETWORK]` の形式で指定します。例: `myproject/network1`
`linuxImage`	文字列	SAP HANA で使用する Linux オペレーティングシステムイメージまたはイメージファミリーの名前。イメージファミリーを指定するには、ファミリー名に接頭辞 `family/` を追加します。例: `family/sles-15-sp1-sap`特定のイメージを指定するには、イメージ名のみを指定します。使用可能なイメージとファミリーのリストについては、Google Cloud コンソールの [イメージ] ページをご覧ください。
`linuxImageProject`	文字列	使用するイメージを含む Google Cloud プロジェクト。このプロジェクトは独自のプロジェクトか、`suse-sap-cloud` のような Google Cloud イメージプロジェクトです。Google Cloud イメージプロジェクトの詳細については、Compute Engine ドキュメントのイメージのページをご覧ください。
`sap_hana_deployment_bucket`	文字列	前のステップでアップロードした SAP HANA インストールファイルとリビジョンファイルを含む、プロジェクト内の Google Cloud Storage バケットの名前。バケット内のすべてのアップグレードリビジョンファイルは、デプロイプロセス中に SAP HANA に適用されます。
`sap_hana_sid`	文字列	SAP HANA システム ID（SID）。ID は英数字 3 文字で、最初の文字はアルファベットにする必要があります。文字は大文字のみ使用できます。
`sap_hana_instance_number`	整数	SAP HANA システムのインスタンス番号（0～99）。デフォルトは 0 です。
`sap_hana_sidadm_password`	文字列	オペレーティングシステム（OS）管理者のパスワード。パスワードは 8 文字以上で設定し、少なくとも英大文字、英小文字、数字をそれぞれ 1 文字以上含める必要があります。注意: インストールの完了後にパスワードを変更してください。
`sap_hana_system_password`	文字列	データベースのスーパーユーザー用パスワード。パスワードは 8 文字以上で設定し、少なくとも英大文字、英小文字、数字をそれぞれ 1 文字以上含める必要があります。注意: インストールの完了後にパスワードを変更してください。
`sap_hana_sidadm_uid`	整数	ユーザーが作成したグループが SAP HANA と競合するのを防ぐため、`SID_LCadm` ユーザー ID のデフォルト値は `900` になっています。必要に応じて、この値を別の値に変更できます。
`sap_hana_sapsys_gid`	整数	sapsys のデフォルトのグループ ID は `79` です。上記の値を指定することにより、この値を要件に合わせてオーバーライドできます。
`sap_hana_scaleout_nodes`	整数	`1` 以上を指定してください。
`sap_hana_shared_nfs`	文字列	`/hana/shared` ボリュームの NFS マウントポイント。例: `10.151.91.122:/hana_shared_nfs`。注: `/hana/shared` ボリュームの NFS マウントポイントは、Deployment Manager の実行前に空にして、他のデプロイで使用しないようにする必要があります。
`sap_hana_backup_nfs`	文字列	`/hanabackup` ボリュームの NFS マウントポイント。例: `10.216.41.122:/hana_backup_nfs`
`networkTag`	文字列	ファイアウォールまたはルーティングの目的で使用される、VM インスタンスを表すネットワークタグ。`publicIP: No` を指定していて、ネットワークタグを指定しない場合は、インターネットへの別のアクセス手段を必ず指定してください。
`nic_type`	文字列	省略可。ただし、ターゲットマシンと OS バージョンに適用可能な場合は推奨します。VM インスタンスで使用するネットワークインターフェースを指定します。値には `GVNIC` または `VIRTIO_NET` を指定できます。Google Virtual NIC（gVNIC）を使用するには、`linuxImage` プロパティの値として gVNIC をサポートする OS イメージを指定する必要があります。OS イメージの一覧については、オペレーティングシステムの詳細をご覧ください。このプロパティの値を指定しなかった場合は、`instanceType` プロパティに指定したマシンタイプに基づいて、ネットワークインターフェースが自動的に選択されます。この引数は、Deployment Manager テンプレートバージョン `202302060649` 以降で使用できます。
`publicIP`	ブール値	省略可。パブリック IP アドレスを VM インスタンスに追加するかどうかを指定します。デフォルトは `Yes` です。注: NAT ゲートウェイを VM 用に定義されたネットワークタグで構成しているか、VM をインターネットに接続する他のルートを確保している場合を除いて、`No` は指定しないでください。インターネットへのルートがない場合、インストールは失敗します。
`serviceAccount`	文字列	省略可。ホスト VM と、ホスト VM で実行されるプログラムが使用するサービスアカウントを指定します。サービスアカウントのメールアドレスを指定します。たとえば、`svc-acct-name`@`project-id`.iam.gserviceaccount.comのようにします。デフォルトでは、Compute Engine のデフォルトのサービスアカウントが使用されます。詳細については、Google Cloud 上での SAP プログラムの Identity and Access Management をご覧ください。

プライマリ SAP HANA システムの定義をコピーし、それをプライマリ SAP HANA システム定義の後に貼り付けて、セカンダリ SAP HANA システムの定義を作成します。次の手順の例を参照してください。
セカンダリ SAP HANA システムの定義で、次のプロパティにプライマリ SAP HANA システム定義とは異なる値を指定します。
- name
- instanceName
- zone

sap_majoritymaker.yaml マジョリティメーカーインスタンス構成ファイルをダウンロードします。

wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/template.yaml -O sap_majoritymaker.yaml

sap_majoritymaker.yaml ファイルの 6 行目から始まる YAML 仕様をコピーして、SAP HANA の template.yaml ファイルの一番下に貼り付けます。
マジョリティメーカーインスタンスの定義を完了します。
- 2 つの SAP HANA システムとは異なる zone を指定します。
- 推奨される最小の instanceType は n1-standard-2 か、2 基以上の CPU コアと 2 GB のメモリを備えたタイプになります。
これで、YAML ファイルに 3 つのリソース、2 つの SAP HANA クラスタ、1 つのマジョリティメーカーインスタンスが、構成可能なプロパティとともにリストされたことになります。
次のコマンドを実行して、インスタンスを作成します。
```
gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml
```
上記のコマンドによって Deployment Manager が起動すると、template.yaml ファイルの仕様に従って VM がデプロイされ、SAP HANA ソフトウェアがストレージバケットからダウンロードされて SAP HANA がインストールされます。

デプロイ処理は 2 つのステージで構成されています。最初の段階では、Deployment Manager がコンソールにステータスを書き込みます。第 2 段階では、デプロイスクリプトが Cloud Logging にステータスを書き込みます。

完全な `template.yaml` 構成ファイルの例

次の例は、SAP HANA システムがインストールされた 2 つのスケールアウトクラスタと、マジョリティメーカーとして機能する 1 つの VM インスタンスをデプロイする完全な template.yaml 構成ファイルを示しています。

このファイルには、デプロイする 2 つのリソース（sap_hana_primary と sap_hana_secondary）の定義が含まれています。各リソース定義には、VM と SAP HANA インスタンスの定義が含まれています。

sap_hana_secondary リソース定義は、最初の定義をコピーして貼り付け、name、instanceName、zone の各プロパティの値を変更することによって作成されました。2 つのリソース定義のその他のプロパティ値はすべて同じです。

プロパティ networkTag、serviceAccount、sap_hana_sidadm_uid、sap_hana_sapsys_gid は、構成ファイルテンプレートの [詳細オプション] セクションにあります。プロパティ sap_hana_sidadm_uid と sap_hana_sapsys_gid はデフォルト値を示すために含まれており、プロパティがコメントアウトされているため使用されています。

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.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/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 2
    sap_hana_shared_nfs: 10.151.91.123:/hana_shared_nfs
    sap_hana_backup_nfs: 10.216.41.123:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.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/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 2
    sap_hana_shared_nfs: 10.141.91.124:/hana_shared_nfs
    sap_hana_backup_nfs: 10.106.41.124:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    
- name: sap_majoritymaker
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/sap_majoritymaker.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/202208181245/dm-templates/sap_majoritymaker/sap_majoritymaker.py
  properties:
    instanceName: sap-majoritymaker
    instanceType: n1-standard-2
    zone: us-central1-b
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    publicIP: No

ホスト VM へのアクセスを許可するファイアウォールルールを作成する

まだ行っていない場合は、以下のソースから各ホスト VM へのアクセスを許可するファイアウォールルールを作成します。

構成が目的の場合は、ローカルワークステーション、踏み台インスタンス、踏み台サーバー
クラスタノード間のアクセスの場合は、HA クラスタ内の他のホスト VM

VPC ファイアウォールルールを作成するときは、template.yaml 構成ファイルで定義したネットワークタグを指定して、ホスト VM をルールのターゲットとして指定します。

デプロイを確認するには、踏み台インスタンスまたはローカルワークステーションからのポート 22 での SSH 接続を許可するルールを定義します。

クラスタノード間のアクセスの場合は、同じサブネットワーク内の他の VM からの任意のポートですべての接続タイプを許可するファイアウォールルールを追加します。

次のセクションに進む前に、デプロイの確認とクラスタ内通信用のファイアウォールルールが作成されていることを確認します。手順については、ファイアウォールルールの追加をご覧ください。

VM と SAP HANA のデプロイを確認する

デプロイを確認するには、Cloud Logging でデプロイログを調べ、プライマリホストとセカンダリホストの VM 上のディスクとサービスを調べます。

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. デプロイを再実行します。

マジョリティメーカーのデプロイステータスを確認する

マジョリティメーカーのデプロイステータスは、次のコマンドを使用して確認できます。

gcloud compute instances describe MAJORITY_MAKER_HOSTNAME --zone MAJORITY_MAKER_ZONE --format="table[box,title='Deployment Status'](name:label=Instance_Name,metadata.items.status:label=Status)"

Complete ステータスが表示されている場合、マジョリティメーカーインスタンスのデプロイ処理は成功しています。デプロイが進行中の場合は、<blank> ステータスが表示されます。

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

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

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

Filesystem                        Size  Used Avail Use% Mounted on
/dev/sda2                          30G  4.0G   26G  14% /
devtmpfs                          126G     0  126G   0% /dev
tmpfs                             126G     0  126G   0% /dev/shm
tmpfs                             126G   17M  126G   1% /run
tmpfs                             126G     0  126G   0% /sys/fs/cgroup
/dev/sda1                         200M  9.7M  191M   5% /boot/efi
/dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
/dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
/dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
/dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
/dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
tmpfs                              26G     0   26G   0% /run/user/900
tmpfs                              26G     0   26G   0% /run/user/899
tmpfs                              26G     0   26G   0% /run/user/1000

次のコマンドの SID_LC を構成ファイルのテンプレートで指定したシステム ID で置き換え、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 をご覧ください。

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 用エージェントを使用している SAP HANA モニタリング指標の収集の詳細については、SAP HANA モニタリング指標の収集をご覧ください。

（省略可）スクリプト自動化用インスタンスのリストを作成する

SAP HANA システムと Pacemaker クラスタの構成中に、繰り返し作業の一部を自動化する場合は、bash スクリプトを使用します。このガイドでは、SAP HANA システムと Pacemaker クラスタの構成を高速化するために、このような bash スクリプトを使用します。これらのスクリプトでは、デプロイされているすべての VM インスタンスとそれに対応するゾーンのリストを入力として使用します。

この自動化を有効にするには、nodes.txt という名前のファイルを作成し、デプロイされたすべての VM インスタンスの詳細をゾーン名、空白文字、VM インスタンス名の形式で指定します。このガイドでは、次のサンプルファイルを使用します。

# cat nodes.txt
  us-west1-a hana-ha-vm-1
  us-west1-a hana-ha-vm-1w1
  us-west1-a hana-ha-vm-1w2
  us-west1-b hana-majoritymaker
  us-west1-c hana-ha-vm-2
  us-west1-c hana-ha-vm-2w1
  us-west1-c hana-ha-vm-2w2

パスワード不要の SSH アクセスを設定する

Pacemaker クラスタを構成して SAP HANA セキュアストア（SSFS）鍵を同期するには、マジョリティメーカーインスタンスを含むすべてのノード間でパスワード不要の SSH アクセスが必要です。パスワード不要の SSH アクセスの場合、デプロイされたすべてのインスタンスのインスタンスメタデータに SSH 公開鍵を追加する必要があります。

メタデータの形式は USERNAME: PUBLIC-KEY-VALUE です。

VM に SSH 認証鍵を追加する方法については、メタデータベースの SSH 認証鍵を使用する VM に SSH 認証鍵を追加するをご覧ください。

手動で行う場合の手順

プライマリシステム、セカンダリシステムの各インスタンス、マジョリティメーカーインスタンスのそれぞれについて、root ユーザーの公開鍵を収集します。
```
gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub
```
公開鍵の先頭に文字列 root: を付加し、その鍵を public-ssh-keys.txt というファイルに書き込みます。鍵は 1 行に 1 つずつ入力します。例:
```
root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME
```
すべての SSH 公開鍵を収集したら、鍵をメタデータとしてすべてのインスタンスにアップロードします。
```
gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME
```

自動で行う場合の手順

nodes.txt に含まれているすべてのインスタンスに対して、パスワード不要の SSH アクセスを設定するプロセスを自動化する場合は、Google Cloud コンソールで次の操作を行います。

デプロイされたすべてのインスタンスから公開鍵のリストを作成します。

while read -u10 ZONE HOST ;  do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt

SSH 公開鍵をメタデータエントリとしてすべてのインスタンスに割り当てます。

while read -u10 ZONE HOST ;  do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt

SAP HANA 自動起動を無効にする

手動で行う場合の手順

クラスタ内の SAP HANA インスタンスごとに、SAP HANA 自動起動が無効になっていることを確認します。フェイルオーバーの場合、Pacemaker がクラスタ内の SAP HANA インスタンスの起動と停止を管理します。

各ホストで、SID_LCadm として SAP HANA を停止します。
```
> HDB stop
```
各ホストで、vi などのエディタを使用して SAP HANA プロファイルを開きます。
```
vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME
```
Autostart プロパティを 0 に設定します。
```
Autostart=0
```
プロファイルを保存します。
各ホストで、SID_LCadm として SAP HANA を起動します。
```
> HDB start
```

自動で行う場合の手順

nodes.txt に含まれているすべてのインスタンスに対して SAP HANA 自動起動を無効にする場合は、Google Cloud コンソールから次のスクリプトを実行します。

while read -u10 ZONE HOST ;
 do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME;
 sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME";
 done 10< nodes.txt

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)

SUSE パッケージをダウンロードする

スケールアップデプロイに使用するリソースエージェントをアンインストールして、スケールアウトに使用するリソースエージェントに置き換えます。

手動で行う場合の手順

マジョリティメーカーインスタンスを含むすべてのホストで、次の操作を行います。

HANA スケールアップリソースエージェントをアンインストールします。
```
zypper remove SAPHanaSR SAPHanaSR-doc
```
HANA スケールアウトリソースエージェントをインストールします。
```
zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc
```
socat をインストールします。
```
zypper install socat
```
最新のオペレーティングシステムのパッチを適用します。
```
zypper patch
```

自動で行う場合の手順

nodes.txt に含まれているすべてのインスタンスに対してこのプロセスを自動化するには、Google Cloud コンソールから次のスクリプトを実行します。

while read -u10 HOST ;  do gcloud compute ssh --zone $HOST -- "sudo zypper remove -y SAPHanaSR SAPHanaSR-doc; sudo zypper in -y SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc socat; sudo zypper patch -y"; done 10< nodes.txt

データベースをバックアップする

データベースのバックアップを作成して、SAP HANA システムレプリケーションのデータベースロギングを開始し、復旧時点を作成します。

MDC 構成に複数のテナントデータベースがある場合は、各テナントデータベースをバックアップします。

Deployment Manager テンプレートでは、デフォルトのバックアップディレクトリとして /hanabackup/data/SID が使用されます。

新しい SAP HANA データベースのバックアップを作成するには:

プライマリホストで、SID_LCadm に切り替えます。OS イメージによっては、コマンドが異なる場合があります。
```
sudo -i -u SID_LCadm
```
データベースのバックアップを作成します。
- SAP HANA 単一データベースコンテナシステムの場合は、次のようにします。
```
> hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"
```
  次の例は、新しい SAP HANA システムからの正常なレスポンスを示しています。
```
0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)
```
- SAP HANA マルチデータベースコンテナシステム（MDC）の場合は、システムデータベースとテナントデータベースのバックアップを作成します。
```
> hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"
```
```
> hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"
```
次の例は、新しい SAP HANA システムからの正常なレスポンスを示しています。
```
0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)
```

ロギングモードが通常に設定されていることを確認します。

> hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

以下のように表示されます。

VALUE
"normal"

SAP HANA システムレプリケーションを有効にする

SAP HANA システムレプリケーションの有効化の一環として、ファイルシステム（SSFS）上の SAP HANA セキュアストアのデータと鍵ファイルをプライマリホストからセカンダリホストにコピーする必要があります。この手順で使用するファイルのコピー方法は、使用できる方法の 1 つにすぎません。

プライマリホストで、SID_LCadm としてシステムレプリケーションを有効にします。
```
> hdbnsutil -sr_enable --name=PRIMARY_HOST_NAME
```

セカンダリホストで、次のようにします。

SID_LCadm として SAP HANA を停止します。

> sapcontrol -nr INST_NUM -function StopSystem

root として、既存の SSFS データと鍵ファイルをアーカイブします。

# cd /usr/sap/SID/SYS/global/security/rsecssfs/
# mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
# mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

プライマリホストからデータファイルをコピーします。

# scp -o StrictHostKeyChecking=no \
PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

プライマリホストから鍵ファイルをコピーします。

# scp -o StrictHostKeyChecking=no \
PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

ファイルのオーナー権限を更新します。

# chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
# chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

ファイルの権限を更新します。

# chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
# chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

SID_LCadm として、セカンダリ SAP HANA システムを SAP HANA システムレプリケーションに登録します。

> hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \
--replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAME

SID_LCadm として、SAP HANA を起動します。
```
> sapcontrol -nr INST_NUM -function StartSystem
```

システムレプリケーションを検証する

プライマリホストで、SID_LCadm として次の Python スクリプトを実行し、SAP HANA システムレプリケーションがアクティブであることを確認します。

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

レプリケーションが適切に設定されている場合は、他のインジケーターとともに、xsengine、nameserver、indexserver の各サービスに対して以下の値が表示されます。

Secondary Active Status は YES
Replication Status は ACTIVE

また、overall system replication status は ACTIVE です。

SAP HANA HA / DR プロバイダフックを有効にする

SUSE では、SAP HANA HA / DR プロバイダフックを有効にすることをおすすめします。これにより、SAP HANA で特定のイベントに関する通知を送信でき、障害検出が改善されます。SAP HANA HA/DR プロバイダフックには、SAP HANA 2.0 SPS 03 以降のバージョンが必要です。

プライマリサイトとセカンダリサイトの両方で、次の操作を行います。

SID_LCadm として SAP HANA を停止します。
```
> sapcontrol -nr 00 -function StopSystem
```

root または SID_LCadm として、global.ini ファイルを編集用に開きます。
```
> vi /hana/shared/SID/global/hdb/custom/config/global.ini
```

global.ini ファイルに次の定義を追加します。

[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut/
execution_order = 1

[ha_dr_provider_sustkover]
provider = susTkOver
path = /usr/share/SAPHanaSR-ScaleOut/
execution_order = 2
sustkover_timeout = 30

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut/
execution_order = 3
action_on_lost = stop

[trace]
ha_dr_saphanasrmultitarget = info
ha_dr_sustkover = info

root として次のコマンドを実行して、/etc/sudoers.d ディレクトリにカスタム構成ファイルを作成します。この新しい構成ファイルを使用すると、srConnectionChanged() フックメソッドの呼び出し時に SID_LCadm ユーザーがクラスタノード属性にアクセスできるようになります。
```
> sudo visudo -f /etc/sudoers.d/SAPHanaSR
```

/etc/sudoers.d/SAPHanaSR ファイルに次のテキストを追加します。

SID_LC は小文字の SID に置き換えます。

SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_*
SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_gsh *
SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=SID_LC *

/etc/sudoers ファイルに次のテキストが含まれていることを確認します。
- SLES for SAP 15 SP3 以降の場合:
```
@includedir /etc/sudoers.d
```
- SLES for SAP 15 SP2 より前のバージョンの場合:
```
#includedir /etc/sudoers.d
```
  このテキストの # は構文の一部であり、行がコメントであることを意味するわけではありません。
注: このセクションの手順は SUSE で推奨されていますが、別の方法を使用することもできます。ドロップイン構成ファイルを作成する代わりに、必要なアクセス権を /etc/sudoers ファイルに直接追加できます。
SID_LCadm として SAP HANA を起動します。
```
> sapcontrol -nr 00 -function StartSystem
```
SAP HANA のクラスタ構成が完了したら、SAPHanaSR Python フックのトラブルシューティングと HANA インデックスサーバーの障害発生時に HA クラスタの引き継ぎに時間がかかりすぎるの説明に従って、フェイルオーバーテストでフックが正しく機能することを確認できます。

Cloud Load Balancing のフェイルオーバーサポートを構成する

フェイルオーバーをサポートする内部パススルーネットワークロードバランササービスは、ヘルスチェックサービスに基づいて、SAP HANA クラスタ内のアクティブホストにトラフィックをルーティングします。

仮想 IP の IP アドレスを予約する

仮想 IP（VIP）アドレスはフローティング IP アドレスとも呼ばれ、アクティブな SAP HANA システムに従います。ロードバランサは、VIP に送信されるトラフィックを、現在アクティブな SAP HANA システムをホストしている VM にルーティングします。

Cloud Shell を開きます。

Cloud Shell に移動
仮想 IP の IP アドレスを予約します。これは、アプリケーションが SAP HANA へのアクセスに使用する IP アドレスです。--addresses フラグを省略すると、指定したサブネット内の IP アドレスが自動的に選択されます。
```
$ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS
```
静的 IP の予約の詳細については、静的内部 IP アドレスの予約をご覧ください。

IP アドレスの予約を確認します。

$ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

出力は次の例のようになります。

address: 10.0.0.19
addressType: INTERNAL
creationTimestamp: '2020-05-20T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-hana-ha
networkTier: PREMIUM
purpose: GCE_ENDPOINT
region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

ホスト VM のインスタンスグループを作成する

Cloud Shell で 2 つの非マネージドインスタンスグループを作成し、プライマリマスターホスト VM を 1 つのグループに、セカンダリマスターホスト VM をもう一方のグループに割り当てます。

$ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE \
  --instances=PRIMARY_HOST_NAME
$ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE \
  --instances=SECONDARY_HOST_NAME

インスタンスグループが作成されたことを確認します。

$ gcloud compute instance-groups unmanaged list

出力は次の例のようになります。

NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Compute Engine ヘルスチェックを作成する

Cloud Shell で、ヘルスチェックを作成します。ヘルスチェックで使用するポートには、他のサービスと競合しないようにプライベート範囲の 49152～65535 を選択します。チェック間隔とタイムアウトの値は、Compute Engine のライブマイグレーションイベント中のフェイルオーバーの許容範囲を広げるために、デフォルトよりも少し長くなっています。必要に応じて値を調整できます。
```
$ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2
```

ヘルスチェックが作成されたことを確認します。

$ gcloud compute health-checks describe HEALTH_CHECK_NAME

出力は次の例のようになります。

checkIntervalSec: 10
creationTimestamp: '2020-05-20T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: hana-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
tcpHealthCheck:
 port: 60000
 portSpecification: USE_FIXED_PORT
 proxyHeader: NONE
timeoutSec: 10
type: TCP
unhealthyThreshold: 2

ヘルスチェック用のファイアウォールルールを作成する

プライベート範囲のポートのファイアウォールルールを定義して、Compute Engine のヘルスチェックで使用される IP 範囲（35.191.0.0/16 と 130.211.0.0/22）からホスト VM へのアクセスを許可します。詳細については、ヘルスチェック用のファイアウォールルールの作成をご覧ください。

ホスト VM にネットワークタグを追加します（まだ設定されていない場合）。このタグは、ファイアウォールルールのヘルスチェックで使用されます。

$ gcloud compute instances add-tags PRIMARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

まだ作成していない場合は、ヘルスチェックを許可するファイアウォールルールを作成します。

$ gcloud compute firewall-rules create RULE_NAME \
  --network NETWORK_NAME \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --target-tags NETWORK_TAGS \
  --rules tcp:HLTH_CHK_PORT_NUM

次に例を示します。

gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

ロードバランサとフェイルオーバーグループを構成する

ロードバランサのバックエンドサービスを作成します。

$ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks HEALTH_CHECK_NAME \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region CLUSTER_REGION \
  --global-health-checks

プライマリインスタンスグループをバックエンドサービスに追加します。

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

セカンダリのフェイルオーバーインスタンスグループをバックエンドサービスに追加します。

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

転送ルールを作成します。IP アドレスには、VIP 用に予約した IP アドレスを指定します。以下で指定されているリージョンの外部から SAP HANA システムにアクセスする必要がある場合は、定義に --allow-global-access フラグを含めます。
```
$ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL
```
SAP HANA 高可用性システムへのリージョン間アクセスの詳細については、内部 TCP / UDP ロードバランシングをご覧ください。

ロードバランサの構成をテストする

バックエンドインスタンスグループはすぐには正常として登録されませんが、ヘルスチェックに応答するようにリスナーを設定することで、ロードバランサの構成をテストできます。リスナーを設定した後、ロードバランサが正しく構成されていれば、バックエンドインスタンスグループのステータスは正常に変わります。

以降のセクションでは、構成のテストに使用できるさまざまな方法について説明します。

`socat` ユーティリティでロードバランサをテストする

socat ユーティリティを使用して、ヘルスチェックポートを一時的にリッスンできます。socat ユーティリティは、後でクラスタリソースを構成するときに使用するため、インストールしておく必要があります。

プライマリとセカンダリの両方のマスターホスト VM に、root ユーザーとして socat ユーティリティをインストールします。
```
# zypper install -y socat
```
socat プロセスを開始して、ヘルスチェックポートで 60 秒間リッスンします。
```
# timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

Cloud Shell で、ヘルスチェックがリスナーを検出するまで数秒待ってから、バックエンドインスタンスグループのヘルスチェックを行います。

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

出力は次のようになります。

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

ポート 22 を使用してロードバランサをテストする

ホスト VM で SSH 接続用にポート 22 が開いている場合、ヘルスチェッカーに応答できるリスナーを備えたポート 22 を使用するように、ヘルスチェッカーを一時的に編集できます。

ポート 22 を一時的に使用するには、次の手順に従います。

コンソールでヘルスチェックをクリックします。

[ヘルスチェック] ページに移動
[編集] をクリックします。
[ポート] 項目で、ポート番号を 22 に変更します。
[保存] をクリックし、1～2 分待ちます。

Cloud Shell で、バックエンドインスタンスグループのヘルスチェックを行います。

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

出力は次のようになります。

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

完了したら、ヘルスチェックのポート番号を元のポート番号に戻します。

Pacemaker を設定する

次の手順では、SAP HANA の Compute Engine VM に Pacemaker クラスタの SUSE 実装を構成します。

SLES で高可用性クラスタを構成する方法の詳細については、ご使用の SLES バージョンの SUSE Linux Enterprise 高可用性拡張機能のドキュメントをご覧ください。

クラスタを初期化する

プライマリホストで、root ユーザーとしてクラスタを初期化します。

SLES 15

crm cluster init -y

SLES 12

ha-cluster-init -y

SBD とデフォルトのパスワードに関する警告は無視してください。このデプロイでは SBD とデフォルトのパスワードは使用しません。

クラスタを構成する

プライマリホストで root ユーザーとして次の操作を行います。

メンテナンスモードを有効にする

Pacemaker クラスタをメンテナンスモードにします。

crm configure property maintenance-mode="true"

一般的なクラスタプロパティを構成する

次の一般的なクラスタプロパティを構成します。

crm configure property stonith-timeout="300s"
crm configure property stonith-action="reboot"
crm configure property stonith-enabled="true"
crm configure property cluster-infrastructure="corosync"
crm configure property cluster-name="hacluster"
crm configure property placement-strategy="balanced"
crm configure property no-quorum-policy="freeze"
crm configure property concurrent-fencing="true"

crm configure rsc_defaults migration-threshold="50"
crm configure rsc_defaults resource-stickiness="1000"

crm configure op_defaults timeout="600"

corosync.conf のデフォルト設定を編集する

任意のエディタで /etc/corosync/corosync.conf ファイルを開きます。
consensus パラメータを削除します。

Google Cloud の推奨事項に従って残りのパラメータを変更します。

次の表に、Google Cloud が推奨する totem パラメータと、値の変更による影響を示します。パラメータのデフォルト値は Linux ディストリビューションごとに異なります。詳細は、Linux ディストリビューションのドキュメントをご覧ください。

パラメータ	推奨値	値の変更による影響
`secauth`	`off`	すべての `totem` メッセージの認証と暗号化を無効にします。
`join`	60（ミリ秒）	メンバーシッププロトコルの `join` メッセージに対するノードの待機時間を増やします。
`max_messages`	20	トークンの受信後にノードから送信される可能性があるメッセージの最大数を増やします。
`token`	20000（ミリ秒）	ノードがトークンの損失を宣言してノード障害を想定したアクションを開始する前に、`totem` プロトコルトークンの待機時間を増やします。 `token` パラメータの値を増やすと、クラスタの一時的なインフラストラクチャイベント（ライブマイグレーションなど）に対する耐性が高くなります。ただし、クラスタがノードの障害を検出して復旧するまでに時間がかかることがあります。また、`token` パラメータの値によって `consensus` パラメータのデフォルト値が決まり、この値により、構成メンバーシップの再確立を試行する前にノードの合意を待機する時間が制御されます。
`consensus`	なし	新しいメンバーシップ構成を開始する前に合意を得るまでの待機時間をミリ秒単位で指定します。このパラメータは省略することをおすすめします。`consensus` パラメータを指定しないと、Corosync はその値を `token` パラメータ値の 1.2 倍に設定します。`token` パラメータの推奨値である `20000` を使用すると、`consesus` パラメータの値は `24000` に設定されます。 `consensus` の値を明示的に指定する場合は、値が `24000` または `1.2*token` のいずれか大きい方を指定してください。
`token_retransmits_before_loss_const`	10	受信ノードが失敗したと判断してアクションを実行する前に、ノードが再試行するトークンの再送回数を増やします。
`transport`	SLES の場合: `udpu` RHEL 8 以降の場合: `knet` RHEL 7 の場合: `udpu`	corosync で使用されるトランスポートメカニズムを指定します。

すべてのホストを Pacemaker クラスタに参加させる

プライマリホストの Pacemaker クラスタに、マジョリティメーカーを含む他のすべてのホストを参加させます。

手動で行う場合の手順

SLES 15

crm cluster join -y -c PRIMARY_HOST_NAME

SLES 12

ha-cluster-join -y -c PRIMARY_HOST_NAME

自動で行う場合の手順

nodes.txt に含まれているすべてのインスタンスに対してこのプロセスを自動化するには、Google Cloud コンソールから次のスクリプトを実行します。

while read -u10 HOST ;  do echo "Joining $HOST to Pacemaker cluster";
gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- sudo ha-cluster-join -y -c PRIMARY_HOST_NAME;
done 10< nodes.txt

プライマリノードをそれ自体に参加させるときに発生するエラーメッセージ ERROR: cluster.join: Abort: Cluster is currently active は無視してください。

任意のホストから root ユーザーとして、クラスタにすべてのノードが表示されていることを確認します。

# crm_mon -s

出力は次のようになります。

CLUSTER OK: 5 nodes online, 0 resources configured

フェンスを設定する

フェンスを設定するには、各ホスト VM でフェンスエージェントを使用してクラスタリソースを定義します。

フェンシングアクションの後に適切なイベントのシーケンスを保証するには、VM のフェンス後に Corosync が再起動するようにオペレーティングシステムも構成します。また、遅延を考慮して、再起動の Pacemaker タイムアウトも調整します。

フェンシングデバイスリソースを作成する

手動で行う場合の手順

プライマリホストで、root ユーザーとして、プライマリクラスタとセカンダリクラスタ内のすべてのノードのフェンシングリソースを作成します。

PRIMARY_HOST_NAME をプライマリクラスタ内のノードのホスト名に置き換えてから、次のコマンドを実行します。

# crm configure primitive STONITH-"PRIMARY_HOST_NAME" stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="PRIMARY_HOST_NAME" zone="PRIMARY_ZONE" project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

プライマリクラスタ内の他のすべてのノードに対して、前の手順を繰り返します。

SECONDARY_HOST_NAME をセカンダリクラスタ内のノードのホスト名に置き換えてから、次のコマンドを実行します。

# crm configure primitive STONITH-"SECONDARY_HOST_NAME" stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="SECONDARY_HOST_NAME" zone="SECONDARY_ZONE" project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4

セカンダリクラスタ内の他のすべてのノードに対して、前の手順を繰り返します。

MAJORITY_MAKER_HOSTNAME をマジョリティメーカーインスタンスのホスト名に置き換えてから、次のコマンドを実行します。

# crm configure primitive STONITH-"MAJORITY_MAKER_HOSTNAME" stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="MAJORITY_MAKER_HOSTNAME" zone="MAJORITY_MAKER_ZONE" project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4

各フェンシングデバイスのロケーションを設定します。

# crm configure location LOC_STONITH_"PRIMARY_HOST_NAME" \
    STONITH-"PRIMARY_HOST_NAME" -inf: "PRIMARY_HOST_NAME"

マジョリティメーカーホストを含む、プライマリクラスタとセカンダリクラスタの他のすべてのホストに対して、前の手順を繰り返します。

Corosync の再起動の遅延を設定する

手動で行う場合の手順

両方のホストで、root として Corosync の起動を遅延させる systemd ドロップインファイルを作成し、フェンス付き VM の再起動後に適切な一連のイベントが行われるようにします。
```
systemctl edit corosync.service
```
このファイルに次の行を追加します。
```
[Service]
ExecStartPre=/bin/sleep 60
```
ファイルを保存し、エディタを終了します。
systemd マネージャー構成を再読み込みします。
```
systemctl daemon-reload
```

ドロップインファイルが作成されていることを確認します。

service corosync status

次の例に示すように、ドロップインファイルの行が表示されます。

● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/corosync.service.d
           └─override.conf
   Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

自動で行う場合の手順

nodes.txt に含まれているすべてのインスタンスに対してこのプロセスを自動化するには、Google Cloud コンソールから次のスクリプトを実行します。

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   --  "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt

VIP アドレス用のローカルクラスタ IP リソースを作成する

オペレーティングシステムで VIP アドレスを構成するには、前の手順で予約した VIP アドレスにローカルクラスタ IP リソースを作成します。

# crm configure primitive rsc_vip_int-primary IPaddr2 \
     params ip=VIP_ADDRESS cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s

ヘルパーヘルスチェックサービスを設定する

ロードバランサは、各ホストのヘルスチェックポートでリスナーを使用して、SAP HANA クラスタのプライマリインスタンスが実行されている場所を判断します。

クラスタ内のリスナーを管理するには、リスナー用にリソースを作成します。

以下の手順では、socat ユーティリティをリスナーとして使用します。

両方のホストで、root として socat utility をインストールします。
```
# zypper in -y socat
```

プライマリホストで、ヘルパーヘルスチェックサービス用のリソースを作成します。

crm configure primitive rsc_healthcheck-primary anything \
params binfile="/usr/bin/socat" \
cmdline_options="-U TCP-LISTEN:HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
op monitor timeout=20s interval=10s \
op_params depth=0

VIP とヘルパーヘルスチェックサービスのリソースをグループ化します。

# crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary meta resource-stickiness="0"

SAPHanaTopology の基本リソースを作成する

SAPHanaTopology の基本リソースを一時構成ファイルで定義し、それを Corosync にアップロードします。

プライマリホストで、root として次のようにします。

SAPHanaTopology 構成パラメータの一時構成ファイルを作成します。
```
# vi /tmp/cluster.tmp
```

SAPHanaTopology のリソース定義をコピーして /tmp/cluster.tmp ファイルに貼り付けます。

primitive rsc_SAPHanaTopology_SID_HDBINST_NUM ocf:suse:SAPHanaTopology \
 operations \$id="rsc_sap2_SID_HDBINST_NUM-operations" \
 op monitor interval="10" timeout="600" \
 op start interval="0" timeout="600" \
 op stop interval="0" timeout="300" \
 params SID="SID" InstanceNumber="INST_NUM"

clone cln_SAPHanaTopology_SID_HDBINST_NUM rsc_SAPHanaTopology_SID_HDBINST_NUM \
 meta clone-node-max="1" target-role="Started" interleave="true"
location SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

/tmp/cluster.tmp ファイルを編集して、変数テキストを SAP HANA システムの SID とインスタンス番号に置き換えます。
プライマリで、root として /tmp/cluster.tmp ファイルの内容を Corosync に読み込みます。
```
crm configure load update /tmp/cluster.tmp
```

SAPHana の基本リソースを作成する

SAPHana の基本リソースを定義するには、SAPHanaTopology のリソースに使用したのと同じ方法（一時構成ファイル）を使用します。このファイルを Corosync にアップロードします。

一時構成ファイルを置き換えます。
```
# rm /tmp/cluster.tmp
# vi /tmp/cluster.tmp
```

SAPHana のリソース定義をコピーして /tmp/cluster.tmp ファイルに貼り付けます。

primitive rsc_SAPHana_SID_HDBINST_NUM ocf:suse:SAPHanaController \
 operations \$id="rsc_sap_SID_HDBINST_NUM-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="SID" InstanceNumber="INST_NUM" PREFER_SITE_TAKEOVER="true" \
 DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"

ms msl_SAPHana_SID_HDBINST_NUM rsc_SAPHana_SID_HDBINST_NUM \
 meta master-node-max="1" master-max="1" clone-node-max="1" \
 target-role="Started" interleave="true"

colocation col_saphana_ip_SID_HDBINST_NUM 4000: g-primary:Started \
 msl_SAPHana_SID_HDBINST_NUM:Master
order ord_SAPHana_SID_HDBINST_NUM Optional: cln_SAPHanaTopology_SID_HDBINST_NUM \
 msl_SAPHana_SID_HDBINST_NUM
location SAPHanaCon_not_on_majority_maker  msl_SAPHana_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

マルチ階層の SAP HANA HA クラスタで、SAP HANA 2.0 SP03 より前のバージョンを使用している場合は、AUTOMATED_REGISTER を false に設定します。これにより、復元されたインスタンスが、レプリケーションターゲットが構成済みの HANA システムへのレプリケーションを自己登録しようとすることが防止されます。SAP HANA 2.0 SP03 以降の場合は、マルチ階層システムレプリケーションを使用する SAP HANA 構成の AUTOMATED_REGISTER を true に設定できます。詳しくは以下をご覧ください。

プライマリで、root として /tmp/cluster.tmp ファイルの内容を Corosync に読み込みます。
```
crm configure load update /tmp/cluster.tmp
```

SAP HANA システムレプリケーションがアクティブであることを確認する

プライマリホストで、SID_LCadm としてレプリケーションステータスを確認します。

# python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

クラスタをアクティブにする

プライマリホストで、root としてクラスタのメンテナンスモードを解除します。
```
# crm configure property maintenance-mode="false"
```
「メンテナンス」を解除するかどうかを確認するメッセージが表示された場合は、「y」と入力します。
15 秒待ってから、プライマリホストで、root としてクラスタのステータスを確認します。
```
# crm status
```
次の例は、適切に構成されたアクティブなクラスタのステータスを示しています。

7 nodes configured
21 resources configured
Online: [   hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 sap-majoritymaker ]


Full list of resources:


 STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-1w1 (stonith:fence_gce):  Started hana-ha-vm-1
 STONITH-hana-ha-vm-1w2 (stonith:fence_gce):  Started hana-ha-vm-2
 STONITH-sap-majoritymaker      (stonith:fence_gce):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-2w1
 STONITH-hana-ha-vm-2w1 (stonith:fence_gce):  Started hana-ha-vm-2w2
 STONITH-hana-ha-vm-2w2 (stonith:fence_gce):  Started sap-majoritymaker
 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
     Started: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]
 Resource Group: g-primary
     rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
     rsc_healthcheck-primary    (ocf::heartbeat:anything):      Started hana-ha-vm-1
 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
     Masters: [ hana-ha-vm-1 ]
     Slaves: [ hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]

フェイルオーバーをテストする

プライマリホストで障害をシミュレートして、クラスタをテストします。テストシステムを使用するか、システムをリリースする前に本番環境システムでテストを実施します。

テストの前にシステムをバックアップします。

次のようなさまざまな方法で障害をシミュレートできます。

HDB stop
HDB kill
reboot（アクティブノード）
単一のネットワークインターフェースを持つインスタンスの場合は ip link set eth0 down
複数のネットワークインターフェースを持つインスタンスの場合は iptables ... DROP
echo c > /proc/sysrq-trigger

次の手順では、ip link set eth0 down または iptables を使用して、クラスタ内の 2 つのホスト間のネットワークの中断をシミュレートします。単一のネットワークインターフェースを持つインスタンスの場合は ip link コマンドを使用し、複数のネットワークインターフェースを持つインスタンスの場合は iptables コマンドを使用します。このテストでは、フェイルオーバーとフェンシングの両方を検証します。インスタンスに複数のネットワークインターフェースが定義されている場合は、セカンダリホストで iptables コマンドを使用します。プライマリホストがクラスタ通信に使用している IP に基づいて受信トラフィックと送信トラフィックをドロップし、プライマリへのネットワーク接続の損失をシミュレートします。

アクティブホストで、root としてネットワークインターフェースをオフラインにします。
```
# ip link set eth0 down
```
複数のネットワークインターフェースがアクティブな場合は、セカンダリホストで iptables を使用します。
```
# iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP
```
SSH を使用していずれかのホストに再接続し、root ユーザーに変更します。

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

Stack: corosync
Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
Last updated: Fri Jun 12 16:46:07 2020
Last change: Fri Jun 12 16:46:07 2020 by root via crm_attribute on hana-ha-vm-2

2 nodes configured
8 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1]

Full list of resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1
STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-2w1
STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-mm
STONITH-hana-ha-vm-mm   (stonith:fence_gce):    Started hana-ha-vm-1w1
Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
    Stopped: [ hana-ha-vm-mm ]]
Resource Group: g-primary
    rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
    rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-2
Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
    Masters: [ hana-ha-vm-2 ]
    Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
    Stopped: [ hana-ha-vm-mm ]]

SAP HANA ワークロードを評価する

Google Cloud 上で実行される SAP HANA 高可用性ワークロードの継続的な検証チェックを自動化するには、Workload Manager を使用します。

Workload Manager を使用すると、SAP HANA 高可用性ワークロードを自動的にスキャンし、SAP、Google Cloud、OS ベンダーのベストプラクティスに対して評価できます。これにより、ワークロードの品質、パフォーマンス、信頼性が向上します。

Google Cloud で実行されている SAP HANA 高可用性ワークロードの評価で Workload Manager がサポートするベストプラクティスについては、SAP 向けの Workload Manager のベストプラクティスをご覧ください。Workload Manager を使用して評価を作成および実行する方法については、評価を作成して実行するをご覧ください。

トラブルシューティング

SLES 上での SAP HANA 用の高可用性構成に関する問題のトラブルシューティングについては、SAP 高可用性構成のトラブルシューティングをご覧ください。

SLES 上での SAP HANA のサポートを受ける

SLES 上での SAP HANA 用の高可用性クラスタの問題を解決するには、必要な診断情報を収集し、Cloud カスタマーケアまでお問い合わせください。詳細については、SLES の診断情報での高可用性クラスタをご覧ください。

サポート

Google Cloud のインフラストラクチャやサービスに関する問題については、カスタマーケアにお問い合わせください。連絡先は、Google Cloud コンソールのサポートの概要ページで確認できます。カスタマーケアが SAP システムに問題があると判断した場合は、SAP サポートをご案内します。

SAP プロダクト関連の問題については、SAP サポートでサポートリクエストを送信してください。SAP はサポートチケットを評価し、Google Cloud インフラストラクチャの問題と判断した場合は、そのチケットをシステム内の適切な Google Cloud コンポーネント（BC-OP-LNX-GOOGLE または BC-OP-NT-GOOGLE）に転送します。

サポート要件

SAP システムと、そのシステムが使用する Google Cloud のインフラストラクチャおよびサービスに対するサポートを受けるには、サポートプランの最小限の要件を満たす必要があります。

Google Cloud での SAP に関する最小限のサポート要件について詳しくは、以下をご覧ください。

Google Cloud での SAP に関するサポートを受ける
SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites（SAP ユーザーアカウントが必要です）

SAP HANA に接続する

ホスト VM に SAP HANA の外部 IP アドレスがない場合は、SSH を使用して踏み台インスタンスを介して SAP HANA インスタンスに接続するか、SAP HANA Studio を経由して Windows Server を介して SAP HANA インスタンスに接続します。

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

デプロイ後のタスク

デプロイが完了したら、次の手順を行います。

SAP HANA システム管理者とデータベースのスーパーユーザーの仮のパスワードを変更します。次に例を示します。
```
sudo passwd SID_LCadm
```
パスワードの変更に関する SAP の情報については、システムデータベースの SYSTEM ユーザーパスワードを再設定するをご覧ください。
SAP HANA インスタンスを使用する前に、新しい SAP HANA データベースを構成してバックアップします。
SAP HANA システムが VirtIO ネットワークインターフェースにデプロイされている場合は、TCP パラメータ /proc/sys/net/ipv4/tcp_limit_output_bytes の値を 1048576 に設定することをおすすめします。この変更により、ネットワークレイテンシに影響を与えることなく、VirtIO ネットワークインターフェースの全体的なネットワークスループットを改善できます。

詳細については、以下をご覧ください。

次のステップ

詳細については、以下のリソースをご覧ください。

Pcemaker クラスタでのスケールアップにおける SAP HANA システムレプリケーションの自動化

SAP HANA 高可用性プランニングガイド

SAP HANA 障害復旧プランニングガイド

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

SLES での SAP HANA の HA スケールアウト クラスタの構成ガイド

このガイドでデプロイするシステム

前提条件

ネットワークの作成

コンソール

gcloud

NAT ゲートウェイの設定

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

コンソール

gcloud

VM と SAP HANA のデプロイ

完全な template.yaml 構成ファイルの例

ホスト VM へのアクセスを許可するファイアウォール ルールを作成する

VM と SAP HANA のデプロイを確認する

ログ エクスプローラ

以前のログビューア

マジョリティ メーカーのデプロイ ステータスを確認する

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

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

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

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

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

（省略可）スクリプト自動化用インスタンスのリストを作成する

パスワード不要の SSH アクセスを設定する

手動で行う場合の手順

自動で行う場合の手順

SAP HANA 自動起動を無効にする

手動で行う場合の手順

自動で行う場合の手順

SAP HANA Fast Restart を有効にする

手動で行う場合の手順

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

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

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

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

/etc/fstab の更新

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

Fast Restart 用の SAP HANA の構成

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

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

自動で行う場合の手順

SUSE パッケージをダウンロードする

手動で行う場合の手順

自動で行う場合の手順

データベースをバックアップする

SAP HANA システム レプリケーションを有効にする

システム レプリケーションを検証する

SAP HANA HA / DR プロバイダ フックを有効にする

Cloud Load Balancing のフェイルオーバー サポートを構成する

仮想 IP の IP アドレスを予約する

ホスト VM のインスタンス グループを作成する

Compute Engine ヘルスチェックを作成する

ヘルスチェック用のファイアウォール ルールを作成する

ロードバランサとフェイルオーバー グループを構成する

ロードバランサの構成をテストする

socat ユーティリティでロードバランサをテストする

ポート 22 を使用してロードバランサをテストする

Pacemaker を設定する

クラスタを初期化する

SLES 15

SLES 12

クラスタを構成する

メンテナンス モードを有効にする

一般的なクラスタ プロパティを構成する

corosync.conf のデフォルト設定を編集する

すべてのホストを Pacemaker クラスタに参加させる

手動で行う場合の手順

SLES 15

SLES 12

自動で行う場合の手順

フェンスを設定する

フェンシング デバイス リソースを作成する

手動で行う場合の手順

Corosync の再起動の遅延を設定する

手動で行う場合の手順

自動で行う場合の手順

VIP アドレス用のローカル クラスタ IP リソースを作成する

ヘルパー ヘルスチェック サービスを設定する

SAPHanaTopology の基本リソースを作成する

SAPHana の基本リソースを作成する

SLES での SAP HANA の HA スケールアウトクラスタの構成ガイド

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

完全な `template.yaml` 構成ファイルの例

ホスト VM へのアクセスを許可するファイアウォールルールを作成する

ログエクスプローラ

マジョリティメーカーのデプロイステータスを確認する

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

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

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

`/etc/fstab` の更新

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

SAP HANA システムレプリケーションを有効にする

システムレプリケーションを検証する

SAP HANA HA / DR プロバイダフックを有効にする

Cloud Load Balancing のフェイルオーバーサポートを構成する

ホスト VM のインスタンスグループを作成する

ヘルスチェック用のファイアウォールルールを作成する

ロードバランサとフェイルオーバーグループを構成する

`socat` ユーティリティでロードバランサをテストする

メンテナンスモードを有効にする

一般的なクラスタプロパティを構成する

フェンシングデバイスリソースを作成する

VIP アドレス用のローカルクラスタ IP リソースを作成する

ヘルパーヘルスチェックサービスを設定する

SAP HANA システムレプリケーションがアクティブであることを確認する