このガイドでは、仮想 IP（VIP）アドレスを管理するために、内部パススルー ネットワーク ロードバランサを使用する Google Cloud 上の SAP HANA スケールアウト システム用に Red Hat Enterprise Linux（RHEL）高可用性（HA）クラスタをデプロイして手動で構成する方法を説明します。
このガイドでは、次の手順について説明します。
- 障害発生時にトラフィックを再ルーティングするように内部パススルー ネットワーク ロードバランサを構成する
- RHEL に 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 データおよびログボリューム用の永続ディスク。
このガイドでは、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 を有効にできます。
詳細については、以下をご覧ください。
VPC 内部 DNS を使用している場合は、プロジェクト メタデータの
vmDnsSetting変数の値をGlobalOnlyまたはZonalPreferredにして、ゾーン間でノード名を解決できるようにする。vmDnsSettingのデフォルト設定はZonalOnlyです。詳細については、次のトピックをご覧ください。スケールアウトした SAP HANA システムのホスト間で SAP HANA の
/hana/sharedボリュームと/hanabackupボリュームを共有するために、マネージド Filestore ソリューションなどの NFS ソリューションが用意されている。Filestore NFS サーバーをデプロイするには、インスタンスの作成をご覧ください。- データの上書きを避けるため、プライマリ サイトとセカンダリ サイトはそれぞれ専用の NFS パスにアクセスできる必要があります。単一の Filestore インスタンスを使用するには、個別のサブディレクトリをマウントパスとして使用するように、デプロイを構成する必要があります。
ネットワークの作成
セキュリティ上の理由から、新しいネットワークを作成します。アクセスできるユーザーを制御するには、ファイアウォール ルールを追加するか、別のアクセス制御方法を使用します。
プロジェクトにデフォルトの VPC ネットワークがある場合、デフォルトは使用せず、明示的に作成したファイアウォール ルールが唯一の有効なルールとなるように、独自の VPC ネットワークを作成してください。
デプロイ中、VM インスタンスは通常、Google Cloud の SAP 用エージェントをダウンロードするためにインターネットにアクセスする必要があります。Google Cloud から入手できる SAP 認定の Linux イメージのいずれかを使用している場合も、ライセンスを登録して OS ベンダーのリポジトリにアクセスするために、VM インスタンスからインターネットにアクセスする必要があります。このアクセスをサポートするために、NAT ゲートウェイを配置し、VM ネットワーク タグを使用して構成します。ターゲット VM に外部 IP がない場合でもこの構成が可能です。
プロジェクトの VPC ネットワークを作成するには、次の手順を行います。
-
カスタムモードのネットワークを作成します。詳細については、カスタムモード ネットワークの作成をご覧ください。
-
サブネットワークを作成し、リージョンと 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 アドレスがわからない場合は、社内のネットワーク管理者に確認してください。
プロジェクトのファイアウォール ルールを作成するには、ファイアウォール ルールの作成をご覧ください。
VM と SAP HANA のデプロイ
このガイドでは、Google Cloud が提供する Terraform 構成ファイルを使用して、次のものをデプロイします。
- 2 つの同じ SAP HANA システム（それぞれ 2 つ以上の VM インスタンスを持つ）
- タイブレーカー ノードとも呼ばれる 1 つのマジョリティ メーカー インスタンス。これにより、1 つのゾーンが失われても、クラスタ クォーラムが維持されるようになります。
SAP HANA システムは非同期システム レプリケーションを使用します。つまり、SAP HANA システムの 1 つがプライマリのアクティブ システムとして機能し、もう 1 つがセカンダリのスタンバイ システムとして機能します。両方の SAP HANA システムは同じリージョンにデプロイします（異なるゾーンにデプロイすることが理想的です）。
SAP HANA 自動ホスト フェイルオーバー用のスタンバイ ホストを備えたスケールアウト システムが必要な場合は、代わりに Terraform: ホストの自動フェイルオーバーを備える SAP HANA スケールアウト システムのデプロイガイドをご覧ください。
Terraform 構成ファイルで SAP HANA 高可用性クラスタの構成オプションを定義します。
次の手順では Cloud Shell を使用していますが、通常は、Terraform がインストールされ、Google プロバイダが構成されているローカル ターミナルに適用できます。
永続ディスクや CPU などリソースの現在の割り当てが、インストールしようとしている SAP HANA システムに対して十分であることを確認します。割り当てが不足していると、デプロイは失敗します。
SAP HANA の割り当て要件については、SAP HANA の料金と割り当てに関する考慮事項をご覧ください。
Cloud Shell またはローカル ターミナルを開きます。
Cloud Shell またはターミナルで次のコマンドを実行して、
manual_sap_hana_scaleout_ha.tf構成ファイルを作業ディレクトリにダウンロードします。$wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana_ha/terraform/manual_sap_hana_scaleout_ha.tfmanual_sap_hana_scaleout_ha.tfファイルを Cloud Shell コードエディタで開きます。または、ターミナルを使用している場合は、任意のテキスト エディタで開きます。Cloud Shell コードエディタを開くには、Cloud Shell ターミナル ウィンドウの右上にある鉛筆アイコンをクリックします。
manual_sap_hana_scaleout_ha.tfファイル内のsap_hana_primaryとsap_hana_secondaryの両方で、二重引用符で囲まれた部分をご使用のインストール環境の値に置き換えて、引数の値を更新します。引数については、次の表をご覧ください。引数 データ型 説明 source文字列 デプロイ時に使用する Terraform モジュールの場所とバージョンを指定します。
manual_sap_hana_scaleout_ha.tf構成ファイルには、source引数の 2 つのインスタンスがあります。1 つは有効で、もう 1 つはコメントとして追加されています。デフォルトで有効なsource引数に、モジュール バージョンとしてlatestを指定します。デフォルトでは、source引数の 2 番目のインスタンスの先頭に#文字があり、引数が無効になっています。この引数には、モジュール バージョンを識別するタイムスタンプを指定します。すべてのデプロイで同じモジュール バージョンを使用する必要がある場合は、バージョン タイムスタンプを指定する
source引数の先頭から#文字を削除し、latestを指定するsource引数の先頭にコメント文字を追加します。project_id文字列 このシステムをデプロイする Google Cloud プロジェクトの ID を指定します。例: my-project-xmachine_type文字列 SAP システムの実行に必要な Compute Engine 仮想マシン（VM）のタイプを指定します。カスタム VM タイプが必要な場合は、必要な数に最も近く、かつ必要数以上の vCPU 数を持つ事前定義された VM タイプを指定します。デプロイが完了したら、vCPU 数とメモリ量を変更してください。 例:
n1-highmem-32network文字列 VIP を管理するロードバランサを作成するネットワークの名前を指定します。 共有 VPC ネットワークを使用している場合は、ホスト プロジェクトの ID をネットワーク名の親ディレクトリとして追加する必要があります。例:
HOST_PROJECT_ID/NETWORK_NAMEsubnetwork文字列 前の手順で作成したサブネットワークの名前を指定します。共有 VPC にデプロイする場合は、この値を SHARED_VPC_PROJECT_ID/SUBNETWORKとして指定します。例:myproject/network1linux_image文字列 SAP システムをデプロイする Linux オペレーティング システム イメージの名前を指定します。 たとえば、 rhel-9-2-sap-haやsles-15-sp5-sapです。使用可能なオペレーティング システム イメージのリストについては、Google Cloud コンソールの [イメージ] ページをご覧ください。linux_image_project文字列 引数 linux_imageに指定するイメージを含む Google Cloud プロジェクトを指定します。このプロジェクトは独自のプロジェクトか、Google Cloud イメージ プロジェクトです。 Compute Engine イメージの場合は、rhel-sap-cloudかsuse-sap-cloudを指定します。 ご利用のオペレーティング システムのイメージ プロジェクトを確認するには、オペレーティング システムの詳細をご覧ください。primary_instance_name文字列 プライマリ SAP HANA システムの VM インスタンスの名前を指定します。名前には、小文字、数字、ハイフンを使用できます。 primary_zone文字列 プライマリ SAP HANA システムがデプロイされているゾーンを指定します。プライマリ ゾーンとセカンダリ ゾーンは同じリージョンにする必要があります。例: us-east1-csecondary_instance_name文字列 セカンダリ SAP HANA システムの VM インスタンスの名前を指定します。名前には、小文字、数字、ハイフンを使用できます。 secondary_zone文字列 セカンダリ SAP HANA システムがデプロイされているゾーンを指定します。プライマリ ゾーンとセカンダリ ゾーンは同じリージョンにする必要があります。例: us-east1-bsap_hana_deployment_bucket文字列 デプロイした VM に SAP HANA を自動的にインストールするには、SAP HANA インストール ファイルを含む Cloud Storage バケットのパスを指定します。パスには gs://を含めないでください。バケット名とフォルダ名のみを含めます。例:my-bucket-name/my-folderCloud Storage バケットは、
project_id引数に指定した Google Cloud プロジェクト内に存在する必要があります。sap_hana_scaleout_nodes整数 スケールアウト システムで必要なワーカーホストの数を指定します。スケールアウト システムをデプロイするには、少なくとも 1 つのワーカーホストが必要です。 Terraform は、プライマリ SAP HANA インスタンスに加えてワーカーホストも作成します。たとえば、
3を指定した場合、4 つの SAP HANA インスタンスがスケールアウト システムにデプロイされます。sap_hana_sid文字列 デプロイされた VM に SAP HANA を自動的にインストールするには、SAP HANA システム ID を指定します。ID は英数字 3 文字で、最初の文字はアルファベットにする必要があります。文字は大文字のみ使用できます。例: ED1sap_hana_instance_number整数 省略可。SAP HANA システムのインスタンス番号（0～99）を指定します。デフォルトは 0です。sap_hana_sidadm_password文字列 デプロイした VM に SAP HANA を自動的にインストールするには、デプロイ時に使用するインストール スクリプトで SIDadmの一時パスワードを指定します。パスワードは 8 文字以上で設定し、少なくとも英大文字、英小文字、数字をそれぞれ 1 文字以上含める必要があります。パスワードを書式なしテキストとして指定する代わりに、シークレットを使用することをおすすめします。詳細については、パスワード管理をご覧ください。
sap_hana_sidadm_password_secret文字列 省略可。Secret Manager を使用して SIDadmパスワードを保存している場合は、このパスワードに対応するシークレットの名前を指定します。Secret Manager では、Secret 値（パスワード）は 8 文字以上で、英大文字、英小文字、数字をそれぞれ 1 文字以上使用します。
詳細については、パスワード管理をご覧ください。
sap_hana_system_password文字列 デプロイした VM に SAP HANA を自動的にインストールするには、デプロイ時に使用するインストール スクリプトで一時的なデータベース スーパーユーザーのパスワードを指定します。パスワードは 8 文字以上で設定し、少なくとも英大文字、英小文字、数字をそれぞれ 1 文字以上含める必要があります。 パスワードを書式なしテキストとして指定する代わりに、シークレットを使用することをおすすめします。詳細については、パスワード管理をご覧ください。
sap_hana_system_password_secret文字列 省略可。Secret Manager を使用してデータベースのスーパーユーザーのパスワードを保存している場合は、このパスワードに対応するシークレットの名前を指定します。 Secret Manager では、Secret 値（パスワード）は 8 文字以上で、英大文字、英小文字、数字をそれぞれ 1 文字以上使用します。
詳細については、パスワード管理をご覧ください。
sap_hana_double_volume_sizeブール値 省略可。HANA のボリューム サイズを 2 倍にするには、 trueを指定します。この引数は、複数の SAP HANA インスタンスまたは障害復旧 SAP HANA インスタンスを同じ VM にデプロイしたい場合に便利です。デフォルトでは、SAP の認証とサポート要件を満たしつつ、ボリューム サイズが VM のサイズに必要な最小サイズとして自動的に計算されます。デフォルト値はfalseです。sap_hana_backup_size整数 省略可。 /hanabackupボリュームのサイズを GB 単位で指定します。この引数を指定しない場合、または0に設定した場合、インストール スクリプトは、合計メモリの 2 倍の HANA バックアップ ボリュームを持つ Compute Engine インスタンスをプロビジョニングします。sap_hana_sidadm_uid整数 省略可。SID_LC adm ユーザー ID のデフォルト値をオーバーライドする値を指定します。デフォルト値は 900です。SAP ランドスケープ内での整合性を保つために、別の値に変更できます。sap_hana_sapsys_gid整数 省略可。 sapsysのデフォルトのグループ ID をオーバーライドします。デフォルト値は79です。sap_vip文字列 VIP に使用する IP アドレスを指定します。IP アドレスは、サブネットワークに割り当てられている IP アドレスの範囲内でなければなりません。この IP アドレスは、Terraform 構成ファイルで予約されます。 primary_instance_group_name文字列 省略可。プライマリ ノードの非マネージド インスタンス グループの名前を指定します。デフォルト名は ig-PRIMARY_INSTANCE_NAMEです。secondary_instance_group_name文字列 省略可。セカンダリ ノードの非マネージド インスタンス グループの名前を指定します。デフォルト名は ig-SECONDARY_INSTANCE_NAMEです。loadbalancer_name文字列 省略可。内部パススルー ネットワーク ロードバランサの名前を指定します。デフォルト名は lb-SAP_HANA_SID-ilbです。network_tags文字列 省略可。ファイアウォールまたはルーティングの目的で使用され、VM インスタンスに関連付けるネットワーク タグを 1 つ以上カンマ区切りで指定します。 public_ip = falseを指定していて、ネットワーク タグを指定しない場合は、インターネットへの別のアクセス手段を必ず指定してください。nic_type文字列 省略可。VM インスタンスで使用するネットワーク インターフェースを指定します。値には GVNICまたはVIRTIO_NETを指定できます。Google Virtual NIC（gVNIC）を使用するには、linux_image引数の値として gVNIC をサポートする OS イメージを指定する必要があります。OS イメージの一覧については、オペレーティング システムの詳細をご覧ください。この引数の値を指定しなかった場合は、
この引数はmachine_type引数に指定したマシンタイプに基づいて、ネットワーク インターフェースが自動的に選択されます。sap_hanaモジュール バージョン202302060649以降で使用できます。disk_type文字列 省略可。デプロイの SAP データとログボリュームにデプロイする Persistent Disk または Hyperdisk ボリュームのデフォルト タイプを指定します。Google Cloud が提供する Terraform 構成によって実行されるデフォルトのディスク デプロイについては、Terraform によるディスク デプロイをご覧ください。 この引数の有効な値は
pd-ssd、pd-balanced、hyperdisk-extreme、hyperdisk-balanced、pd-extremeです。SAP HANA スケールアップ デプロイでは、/hana/sharedディレクトリに個別のバランス永続ディスクもデプロイされます。いくつかの高度な引数を使用して、このデフォルトのディスクタイプと関連するデフォルトのディスクサイズとデフォルトの IOPS をオーバーライドできます。詳細については、作業ディレクトリに移動してから、
terraform initコマンドを実行して、/.terraform/modules/manual_sap_hana_scaleout_ha/variables.tfファイルを確認してください。これらの引数を本番環境で使用する前に、非本番環境でテストしてください。use_single_shared_data_log_diskブール値 省略可。デフォルト値は falseです。これは、SAP ボリューム（/hana/data、/hana/log、/hana/shared、/usr/sap）ごとに、個別の永続ディスクまたは Hyperdisk をデプロイするように Terraform に指示します。これらの SAP ボリュームを同じ永続ディスクまたは Hyperdisk にマウントするには、trueを指定します。include_backup_diskブール値 省略可。この引数は、SAP HANA スケールアップ デプロイに適用されます。デフォルト値は trueです。これは、/hanabackupディレクトリをホストする別のディスクをデプロイするように Terraform に指示します。ディスクタイプは、
backup_disk_type引数によって決まります。このディスクのサイズは、sap_hana_backup_size引数によって決まります。include_backup_diskの値をfalseに設定すると、/hanabackupディレクトリ用のディスクはデプロイされません。public_ipブール値 省略可。パブリック IP アドレスを VM インスタンスに追加するかどうかを指定します。デフォルト値は trueです。service_account文字列 省略可。ホスト VM とホスト VM で実行されるプログラムで使用されるユーザー管理のサービス アカウントのメールアドレスを指定します。例: svc-acct-name@project-id.iam.gserviceaccount.comこの引数に値を指定しない場合、または省略した場合、インストール スクリプトは、Compute Engine のデフォルトのサービス アカウントを使用します。詳細については、Google Cloud 上での SAP プログラム向け Identity and Access Management をご覧ください。
sap_deployment_debugブール値 省略可。Cloud カスタマーケアでデプロイのデバッグを有効にするよう求められた場合にのみ、 trueを指定します。これにより、デプロイの際に詳細なログが生成されます。デフォルト値はfalseです。primary_reservation_name文字列 省略可。HA クラスタのプライマリ SAP HANA インスタンスをホストする VM インスタンスをプロビジョニングするために、特定の Compute Engine VM 予約を使用するには、予約の名前を指定します。 デフォルトでは、インストール スクリプトは、次の条件に基づいて使用可能な Compute Engine 予約を選択します。 予約を使用するときに名前を指定するのか、インストール スクリプトで自動的に選択するかに関係なく、予約は次のように設定する必要があります。
-
specificReservationRequiredオプションはtrueに設定されます。または、Google Cloud コンソールで [特定の予約を選択] オプションが選択されています。 -
Compute Engine のマシンタイプによっては、マシンタイプの SAP 認定に含まれていない CPU プラットフォームに対応しているものもあります。対象となる予約が次のいずれかのマシンタイプの場合、予約には指示された最小の CPU プラットフォームを指定する必要があります。
n1-highmem-32: Intel Broadwelln1-highmem-64: Intel Broadwelln1-highmem-96: Intel Skylakem1-megamem-96: Intel Skylake
Google Cloud での使用が SAP に認定されている他のすべてのマシンタイプの最小 CPU プラットフォームは、SAP の最小 CPU 要件に準拠しています。
secondary_reservation_name文字列 省略可。HA クラスタのセカンダリ SAP HANA インスタンスをホストする VM インスタンスをプロビジョニングするために、特定の Compute Engine VM 予約を使用するには、予約の名前を指定します。 デフォルトでは、インストール スクリプトは、次の条件に基づいて使用可能な Compute Engine 予約を選択します。 予約を使用するときに名前を指定するのか、インストール スクリプトで自動的に選択するかに関係なく、予約は次のように設定する必要があります。
-
specificReservationRequiredオプションはtrueに設定されます。または、Google Cloud コンソールで [特定の予約を選択] オプションが選択されています。 -
Compute Engine のマシンタイプによっては、マシンタイプの SAP 認定に含まれていない CPU プラットフォームに対応しているものもあります。対象となる予約が次のいずれかのマシンタイプの場合、予約には指示された最小の CPU プラットフォームを指定する必要があります。
n1-highmem-32: Intel Broadwelln1-highmem-64: Intel Broadwelln1-highmem-96: Intel Skylakem1-megamem-96: Intel Skylake
Google Cloud での使用が SAP に認定されている他のすべてのマシンタイプの最小 CPU プラットフォームは、SAP の最小 CPU 要件に準拠しています。
primary_static_ip文字列 省略可。高可用性クラスタ内のプライマリ VM インスタンスに有効な静的 IP アドレスを指定します。IP アドレスを指定しない場合は、VM インスタンスに対して IP アドレスが自動的に生成されます。例: 128.10.10.10この引数は
sap_hana_haモジュール バージョン202306120959以降で使用できます。secondary_static_ip文字列 省略可。高可用性クラスタ内のセカンダリ VM インスタンスに有効な静的 IP アドレスを指定します。IP アドレスを指定しない場合は、VM インスタンスに対して IP アドレスが自動的に生成されます。例: 128.11.11.11この引数は
sap_hana_haモジュール バージョン202306120959以降で使用できます。primary_worker_static_ipsリスト（文字列） 省略可。SAP HANA スケールアウト HA システムのプライマリ インスタンス内のワーカー インスタンスに対して、有効な静的 IP アドレスの配列を指定します。この引数の値を指定しない場合、ワーカー VM インスタンスごとに IP アドレスが自動的に生成されます。例: [ "1.0.0.1", "2.3.3.4" ]静的 IP アドレスは、インスタンスの作成順に割り当てられます。たとえば、3 つのワーカー インスタンスをデプロイするものの、引数
primary_worker_static_ipsに 2 つの IP アドレスのみを指定する場合、これらの IP アドレスは、Terraform の構成がデプロイされる最初の 2 つの VM インスタンスに割り当てられます。3 つ目のワーカー VM インスタンスでは、IP アドレスが自動的に生成されます。この引数は
sap_hana_haモジュール バージョン202307270727以降で使用できます。secondary_worker_static_ipsリスト（文字列） 省略可。SAP HANA スケールアウト HA システムのセカンダリ インスタンス内のワーカー インスタンスに対して、有効な静的 IP アドレスの配列を指定します。この引数の値を指定しない場合、ワーカー VM インスタンスごとに IP アドレスが自動的に生成されます。例: [ "1.0.0.2", "2.3.3.5" ]静的 IP アドレスは、インスタンスの作成順に割り当てられます。たとえば、3 つのワーカー インスタンスをデプロイするものの、引数
secondary_worker_static_ipsに 2 つの IP アドレスのみを指定する場合、これらの IP アドレスは、Terraform の構成がデプロイされる最初の 2 つの VM インスタンスに割り当てられます。3 つ目のワーカー VM インスタンスでは、IP アドレスが自動的に生成されます。この引数は
sap_hana_haモジュール バージョン202307270727以降で使用できます。次の例は、SAP HANA スケールアウト システムの高可用性クラスタを定義する完全な構成ファイルを示しています。このクラスタは、内部パススルー ネットワーク ロードバランサを使用して VIP を管理します。
Terraform は構成ファイルで定義されている Google Cloud リソースをデプロイします。その後、スクリプトが処理を引き継ぎ、オペレーティング システムの構成と SAP HANA のインストールを行います。
-
同じ
manual_sap_hana_scaleout_ha.tfファイルで、majority_makerの引数の値を更新します。引数については、次の表をご覧ください。引数 データ型 説明 project文字列 このシステムをデプロイする Google Cloud プロジェクトの ID を指定します。 majority_maker_instance_name文字列 マジョリティ メーカーとして機能する Compute Engine VM インスタンスの名前を指定します。
この引数は
sap_hana_haモジュール バージョン202307270727以降で使用できます。majority_maker_instance_type文字列 マジョリティ メーカー インスタンスに使用する Compute Engine 仮想マシン（VM）のタイプを指定します。例: n1-highmem-32カスタム VM タイプを使用する場合は、必要な数に最も近く、かつ必要数以上の vCPU 数を持つ事前定義された VM タイプを指定します。デプロイが完了したら、vCPU 数とメモリ量を変更してください。
この引数は
sap_hana_haモジュール バージョン202307270727以降で使用できます。majority_maker_zone文字列 マジョリティ メーカー VM インスタンスがデプロイされているゾーンを指定します。このゾーンは、プライマリ ゾーンおよびセカンダリ ゾーンと同じリージョンに存在する必要があります。例: us-east1-dマジョリティ メーカー VM インスタンスは、プライマリおよびセカンダリ SAP HANA システムとは異なるゾーンにデプロイすることをおすすめします。
この引数は
sap_hana_haモジュール バージョン202307270727以降で使用できます。majority_maker_linux_image文字列 前の手順と同じ値を使用して、イメージの完全なパスを "linux_image_project/linux_image"として指定します。例:"rhel-sap-cloud/rhel-9-0-sap-v20230708"。subnetwork文字列 前の手順で作成したサブネットワークの名前を指定します。共有 VPC にデプロイする場合は、この値を SHARED_VPC_PROJECT_ID/SUBNETWORKとして指定します。例:myproject/network1service_account文字列 省略可。ホスト VM とホスト VM で実行されるプログラムで使用されるユーザー管理のサービス アカウントのメールアドレスを指定します。例: svc-acct-name@project-id.iam.gserviceaccount.comこの引数に値を指定しない場合、または省略した場合、インストール スクリプトは、Compute Engine のデフォルトのサービス アカウントを使用します。詳細については、Google Cloud 上での SAP プログラム向け Identity and Access Management をご覧ください。
metadata_startup_script文字列 この引数は編集しないでください。デフォルトでは、マジョリティ メーカーは最新の起動スクリプトをダウンロードして、Pacemaker クラスタリング用にインスタンスを準備します。 わかりやすくするために、次の構成例ではコメントを省略しています。
module "sap_hana_primary" {
source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"
project_id = "example-project-123456"
zone = "us-west1-a"
machine_type = "n1-highmem-32"
subnetwork = "default"
linux_image = "rhel-9-0-sap-v20230711"
linux_image_project = "rhel-sap-cloud"
instance_name = "hana-ha-1"
sap_hana_sid = "HA1"
sap_hana_deployment_bucket = "my-hana-bucket"
sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
sap_hana_system_password_secret = "hana_sys_pwd"
sap_hana_scaleout_nodes = 1
sap_hana_shared_nfs = "10.10.10.1:/hana_scaleout/hana_a/shared"
sap_hana_backup_nfs = "10.10.10.1:/hana_scaleout/hana_a/backup"
}
module "sap_hana_secondary" {
source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"
project_id = "example-project-123456"
zone = "us-west1-b"
machine_type = "n1-highmem-32"
subnetwork = "default"
linux_image = "rhel-9-0-sap-v20230711"
linux_image_project = "rhel-sap-cloud"
instance_name = "hana-ha-2"
sap_hana_sid = "HA1"
sap_hana_deployment_bucket = "my-hana-bucket"
sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
sap_hana_system_password_secret = "hana_sys_pwd"
sap_hana_scaleout_nodes = 1
sap_hana_shared_nfs = "10.10.10.2:/hana_scaleout/hana_b/shared"
sap_hana_backup_nfs = "10.10.10.2:/hana_scaleout/hana_b/backup"
}
resource "google_compute_instance" "majority_maker" {
project = "example-project-123456"
# majority_maker_instance_name
name = "majority-maker"
# majority_maker_instance_type
machine_type = "n1-standard-8"
# majority_maker_zone
zone = "us-west1-c"
boot_disk {
initialize_params {
# majority_maker_linux_image
image = "rhel-sap-cloud/rhel-9-0-sap-v20230711"
}
}
network_interface {
# network or subnetwork
network = "default"
}
service_account {
# service_account (Optional)
# email = svc-acct-name@project-id.iam.gserviceaccount.com.
scopes = ["cloud-platform"]
}
# Do not edit
metadata_startup_script = "curl -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh | bash -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh"
}
現在の作業ディレクトリを初期化し、Google Cloud 用の Terraform プロバイダのプラグインとモジュール ファイルをダウンロードするには、以下の操作を行います。
terraform init
terraform initコマンドで、他の Terraform コマンドの作業ディレクトリを準備します。作業ディレクトリのプロバイダ プラグインと構成ファイルを強制的に更新するには、
--upgradeフラグを指定します。--upgradeフラグが省略されていて、作業ディレクトリに変更を加えていない場合、sourceURL でlatestが指定されている場合でも、Terraform はローカル キャッシュに保存されたコピーを使用します。terraform init --upgrade
必要に応じて、Terraform 実行プランを作成します。
terraform plan
terraform planコマンドによって、現在の構成で必要な変更が表示されます。この手順をスキップすると、terraform applyコマンドは自動的に新しいプランを作成し、それを承認するように求めます。実行計画を適用します。
terraform apply
アクションを承認するように求められたら、
yesを入力します。terraform applyコマンドは、Google Cloud インフラストラクチャをセットアップした後、HA クラスタを構成し、terraform 構成ファイルで定義された引数に従って SAP HANA をインストールするスクリプトに制御を渡します。Terraform によって制御が行われる間、Cloud Shell にステータス メッセージが書き込まれます。スクリプトが呼び出されると、ログの確認で説明されているように、ステータス メッセージが Logging に書き込まれ、Google Cloud コンソールで表示できるようになります。
HANA HA システムのデプロイの確認
ログを調べる
Google Cloud コンソールで Cloud Logging を開き、インストールの進行状況をモニタリングして、エラーを確認します。
ログをフィルタします。
ログ エクスプローラ
[ログ エクスプローラ] ページで、[クエリ] ペインに移動します。
[リソース] プルダウン メニューから [グローバル] を選択し、[追加] をクリックします。
[グローバル] オプションが表示されない場合は、クエリエディタに次のクエリを入力します。
resource.type="global" "Deployment"[クエリを実行] をクリックします。
以前のログビューア
- [以前のログビューア] ページの基本的なセレクタ メニューから、ロギング リソースとして [グローバル] を選択します。
フィルタされたログを分析します。
"--- Finished"が表示されている場合、デプロイメントは完了しています。次の手順に進んでください。割り当てエラーが発生した場合:
[IAM と管理] の [割り当て] ページで、SAP HANA プランニング ガイドに記載されている SAP HANA の要件を満たしていない割り当てを増やします。
Cloud Shell を開きます。
作業ディレクトリに移動してデプロイを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。
terraform destroy
アクションの承認を求められたら、「
yes」と入力します。デプロイを再実行します。
VM と SAP HANA の構成を確認する
SAP HANA システムが正常にデプロイされたら、SSH を使用して VM に接続します。Compute Engine の [VM インスタンス] ページで、VM インスタンスの SSH ボタンをクリックするか、お好みの SSH メソッドを使用します。
root ユーザーに変更します。
sudo su -
コマンド プロンプトで
df -hを実行します。/hana/dataなどの/hanaディレクトリを含む出力が表示されていることを確認します。[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
クリーンアップしてデプロイを再試行する
前のセクションのデプロイ検証ステップのいずれかでインストールが正常に完了しなかった場合は、デプロイを元に戻し、次の手順を行ってデプロイを再試行する必要があります。
エラーが発生した場合は、同じ理由でデプロイが再び失敗することがないようにエラーを解決してください。ログの確認または割り当て関連のエラーの解決について詳しくは、ログを調べるをご覧ください。
Cloud Shell を開くか、Google Cloud CLI をローカル ワークステーションにインストールしている場合はターミナルを開きます。
このデプロイに使用した Terraform 構成ファイルがあるディレクトリに移動します。
次のコマンドを実行して、デプロイメントに含まれるすべてのリソースを削除します。
terraform destroy
アクションの承認を求められたら、「
yes」と入力します。このガイドの前半で説明したように、デプロイを再試行します。
Google Cloud の SAP 用エージェントのインストールを検証する
すべてのインスタンスをデプロイして 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.txtSSH 公開鍵をメタデータ エントリとしてすべてのインスタンスに割り当てます。
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 オプションのドキュメントをご覧ください。
手動で行う場合の手順
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*/SIDNUMA ノード ディレクトリを 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 を大文字で指定します。例:AHASECRET_NAME: SAP HANA データベースの SYSTEM ユーザーのパスワードに対応するシークレットの名前を指定します。このシークレットは、ホスト VM インスタンスを含む Google Cloud プロジェクトに存在している必要があります。
書式なしテキストのパスワードを使用してスクリプトを実行することもできます。SAP HANA Fast Restart を有効にした後、パスワードを変更します。パスワードは VM のコマンドライン履歴に記録されるため、書式なしテキストのパスワードの使用はおすすめしません。
sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'
次のように置き換えます。
SID: SID を大文字で指定します。例:AHAPASSWORD: 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)
自動で行う場合の手順
このプロセスを自動化するには、nodes.txt と、Google Cloud コンソールの次のスクリプトを使用します。
IP アドレスとホスト名のリストを含む
hosts.txtファイルを生成します。while read -u10 ZONE HOST ; do gcloud compute instances list --filter="name=( 'NAME' $HOST )" --format="csv[separator=' ',no-heading](networkInterfaces[0].networkIP,name)" >> hosts.txt; done 10< nodes.txt
hosts.txtファイルが次の例のようになっていることを確認します。10.138.0.1 rhel-hana-primary 10.138.0.2 rhel-hana-primaryw1 10.138.0.3 rhel-hana-secondary 10.138.0.4 rhel-hana-secondaryw1 10.138.0.5 rhel-sap-mm
クラスタ内のすべてのホスト（マジョリティ メーカーを含む）で、
/etc/hostsファイルを更新して、Pacemaker クラスタ内のすべてのインスタンスのホスト名と内部 IP アドレスを含めます。while read -u10 ZONE HOST ; do gcloud compute ssh --tunnel-through-iap --quiet $HOST --zone $ZONE -- "sudo tee -a /etc/hosts" < hosts.txt; 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 StopSystemroot として、既存の 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.KEYSID_LCadm として、セカンダリ SAP HANA システムを SAP HANA システム レプリケーションに登録します。
>hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \ --replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAMESID_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はYESReplication StatusはACTIVE
また、overall system replication status は ACTIVE です。
SAP HANA HA / DR プロバイダ フックを有効にする
Red Hat では、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.iniglobal.iniファイルに次の定義を追加します。[ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /usr/share/SAPHanaSR-ScaleOut/ execution_order = 1 [trace] ha_dr_saphanasr = info
root として次のコマンドを実行して、
/etc/sudoers.dディレクトリにカスタム構成ファイルを作成します。この新しい構成ファイルを使用すると、srConnectionChanged()フックメソッドの呼び出し時にSID_LCadmユーザーがクラスタノード属性にアクセスできるようになります。>sudo visudo -f /etc/sudoers.d/20-saphana/etc/sudoers.d/20-saphanaファイルに次のテキストを追加します。SID_LCは小文字の SID に置き換えます。Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR SID_LCadm ALL=(ALL) NOPASSWD: SOK, SFAIL Defaults!SOK, SFAIL !requiretty
/etc/sudoersファイルに次のテキストが含まれていることを確認します。#includedir /etc/sudoers.d
このテキストの
#は構文の一部であり、行がコメントであることを意味するわけではありません。SID_LCadmとして SAP HANA を起動します。>sapcontrol -nr 00 -function StartSystemフック スクリプトから報告されたステータスを、プライマリ ホスト上で
SID_LCadmとしてテストします。>cdtrace>awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
Cloud Load Balancing のフェイルオーバー サポートを構成する
フェイルオーバーをサポートする内部パススルー ネットワーク ロードバランサ サービスは、ヘルスチェック サービスに基づいて、SAP HANA クラスタ内のアクティブ ホストにトラフィックをルーティングします。
仮想 IP の IP アドレスを予約する
仮想 IP（VIP）アドレスはフローティング IP アドレスとも呼ばれ、アクティブな SAP HANA システムに従います。ロードバランサは、VIP に送信されるトラフィックを、現在アクティブな SAP HANA システムをホストしている VM にルーティングします。
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 ALLSAP HANA 高可用性システムへのリージョン間アクセスの詳細については、内部 TCP / UDP ロード バランシングをご覧ください。
ロードバランサの構成をテストする
バックエンド インスタンス グループはすぐには正常として登録されませんが、ヘルスチェックに応答するようにリスナーを設定することで、ロードバランサの構成をテストできます。リスナーを設定した後、ロードバランサが正しく構成されていれば、バックエンド インスタンス グループのステータスは正常に変わります。
以降のセクションでは、構成のテストに使用できるさまざまな方法について説明します。
socat ユーティリティでロードバランサをテストする
socat ユーティリティを使用して、ヘルスチェック ポートを一時的にリッスンできます。
プライマリ マスターホスト VM とセカンダリ マスターホスト VM の両方に、
socatユーティリティをインストールします。$sudo yum install -y socatsocatプロセスを開始して、ヘルスチェック ポートで 60 秒間リッスンします。$sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkCloud 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 クラスタの Red Hat 実装を構成します。
この手順は、以下を含む高可用性クラスタを構成するための Red Hat のドキュメントに基づいています（Red Hat サブスクリプションが必要です）。
- Google Cloud への Red Hat Enterprise Linux 7.6（以降）高可用性クラスタのインストールと構成
- Pacemaker クラスタでのスケールアウトにおける SAP HANA システム レプリケーションの自動化
手動で行う場合の手順
すべてのホストで次の手順を完了します。Google 提供の RHEL-for-SAP イメージでは、一部のパッケージはすでにインストールされていますが、追加の変更が必要です。
root として、イメージにプリインストールされている SAP HANA スケールアップ リソース エージェントを削除します。
#yum -y remove resource-agents-sap-hanaPacemaker と不足しているリソース エージェントをインストールします。
#yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana-scaleoutUpdate packages to latest version:
#yum update -yパッケージの一部として作成された
haclusterユーザーのパスワードを設定します。#passwd haclusterプロンプトで、
haclusterのパスワードを指定します。Google Cloud が提供する RHEL-for-SAP イメージでは、OS ファイアウォール サービスがデフォルトで有効になっています。高可用性トラフィックを許可するようにファイアウォール サービスを構成します。
#firewall-cmd --permanent --add-service=high-availability#firewall-cmd --reloadpcs サービスを起動し、起動時に有効化するように構成します。
#systemctl start pcsd.service#systemctl enable pcsd.servicepcs サービスのステータスを確認します。
#systemctl status pcsd.service出力は次のようになります。
● pcsd.service - PCS GUI and remote configuration interface Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago Docs: man:pcsd(8) man:pcs(8) Main PID: 31627 (pcsd) CGroup: /system.slice/pcsd.service └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd Jun 13 21:17:03 hana-ha-1 systemd[1]: Starting PCS GUI and remote configuration interface... Jun 13 21:17:05 hana-ha-1 systemd[1]: Started PCS GUI and remote configuration interface.
自動で行う場合の手順
このプロセスを自動化するには、nodes.txt と Google Cloud コンソールの次のスクリプトを使用します。
プロンプトが表示されたら、Pacemaker リソース エージェントのインストール時に作成した hacluster ユーザーのパスワードを入力します。
echo "Set password for hacluster user:"; read -r HA_PASSWD; while read -u10 HOST ; do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo yum -y remove resource-agents-sap-hana; sudo yum -y install pcs pacemaker fence-agents-gce resource-agents-sap-hana-scaleout resource-agents-gcp; sudo yum update -y; sudo firewall-cmd --permanent --add-service=high-availability; sudo firewall-cmd --reload; sudo systemctl start pcsd.service; sudo systemctl enable pcsd.service; yes $HA_PASSWD | sudo passwd hacluster"; done 10< nodes.txt
/etc/hosts ファイルを更新する
クラスタ内のすべてのホスト（マジョリティ メーカーを含む）で、/etc/hosts ファイルを更新して、Pacemaker クラスタ内のすべてのインスタンスのホスト名と内部 IP アドレスを含めます。
/etc/hosts ファイルの出力は次の例のようになります。
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.138.0.1 rhel-hana-primary.us-west1-a.c.project-name.internal rhel-hana-primary # Added by Google 169.254.169.254 metadata.google.internal # Added by Google 10.138.0.1 rhel-hana-primary 10.138.0.2 rhel-hana-primaryw1 10.138.0.3 rhel-hana-secondary 10.138.0.4 rhel-hana-secondaryw1 10.138.0.5 rhel-sap-mm
RHEL クラスタノードでの /etc/hosts ファイルの設定に関する Red Hat からの詳細情報については、https://access.redhat.com/solutions/81123 をご覧ください。
クラスタを作成する
プライマリ マスター ホストの root として、
haclusterユーザーを承認します。このコマンドには、クラスタの一部になるホストをすべて含める必要があります。RHEL 8.0 以降
pcs host auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
RHEL 7.6 以降
pcs cluster auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
プロンプトが表示されたら、前のセクションで
haclusterユーザーに設定したhaclusterユーザー名とパスワードを入力します。クラスタをメンテナンス モードに設定します。
pcs property set maintenance-mode=true
corosync 構成を生成して同期します。
RHEL 8.0 以降
pcs cluster setup scale_out_hsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
RHEL 7.6 以降
pcs cluster setup --start --name hanascaleoutsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
corosync.conf のデフォルト設定を編集する
任意のエディタで
/etc/corosync/corosync.confファイルを開きます。consensusパラメータを削除します。Google Cloud の推奨事項に従って残りのパラメータを変更します。
次の表に、Google Cloud が推奨するtotemパラメータと、値の変更による影響を示します。パラメータのデフォルト値は Linux ディストリビューションごとに異なります。詳細は、Linux ディストリビューションのドキュメントをご覧ください。パラメータ 推奨値 値の変更による影響 secauthoffすべての totemメッセージの認証と暗号化を無効にします。join60（ミリ秒） メンバーシップ プロトコルの joinメッセージに対するノードの待機時間を増やします。max_messages20 トークンの受信後にノードから送信される可能性があるメッセージの最大数を増やします。 token20000（ミリ秒） ノードがトークンの損失を宣言してノード障害を想定したアクションを開始する前に、
totemプロトコル トークンの待機時間を増やします。tokenパラメータの値を増やすと、クラスタの一時的なインフラストラクチャ イベント（ライブ マイグレーションなど）に対する耐性が高くなります。ただし、クラスタがノードの障害を検出して復旧するまでに時間がかかることがあります。また、
tokenパラメータの値によってconsensusパラメータのデフォルト値が決まり、この値により、構成メンバーシップの再確立を試行する前にノードの合意を待機する時間が制御されます。consensusなし 新しいメンバーシップ構成を開始する前に合意を得るまでの待機時間をミリ秒単位で指定します。
このパラメータは省略することをおすすめします。
consensusパラメータを指定しないと、Corosync はその値をtokenパラメータ値の 1.2 倍に設定します。tokenパラメータの推奨値である20000を使用すると、consesusパラメータの値は24000に設定されます。consensusの値を明示的に指定する場合は、値が24000または1.2*tokenのいずれか大きい方を指定してください。token_retransmits_before_loss_const10 受信ノードが失敗したと判断してアクションを実行する前に、ノードが再試行するトークンの再送回数を増やします。 transport- SLES の場合:
udpu - RHEL 8 以降の場合:
knet - RHEL 7 の場合:
udpu
corosync で使用されるトランスポート メカニズムを指定します。 - SLES の場合:
編集した
corosync.confファイルを含むホストから、クラスタ全体に corosync 構成を同期します。RHEL 8 以降
#pcs cluster sync corosyncRHEL 7
#pcs cluster sync自動的に起動するようにクラスタを設定します。
#pcs cluster enable --all#pcs cluster start --allcorosync-cmapctl ユーティリティを使用して、クラスタで新しい corosync 設定が有効なことを確認します。
#corosync-cmapctl
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
フェンスを設定する
Google Cloud が提供する RHEL イメージには、Google Cloud 固有の fence_gce という名前のフェンシング エージェントが含まれています。fence_gce を使用して、各ホスト VM のフェンス デバイスを作成します。
フェンシング アクションの後に適切なイベント シーケンスが行われるようにするには、VM のフェンス後に Corosync の再起動が遅延するようにオペレーティング システムを構成する必要があります。また、遅延を考慮して、再起動の Pacemaker タイムアウトも調整する必要があります。
fence_gce フェンシング エージェントで利用可能なすべてのオプションを確認するには、fence_gce -h を実行します。
手動で行う場合の手順
プライマリ ホストで、root ユーザーとして、マジョリティ メーカーを含むすべてのホストのフェンシング デバイスを作成します。
pcs stonith create STONITH-host-name fence_gce \ port=host-name \ zone=host-zone \ project=project-id \ pcmk_host_list=host-name pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"
フェンシング デバイスのロケーション制約を設定します。
pcs constraint location STONITH-host-name avoids host-name
変数 host-name と host-zone に適切な値を入力します。プライマリ クラスタとセカンダリ クラスタの他のすべてのホスト、マジョリティ メーカー ホストに対して、前の 2 つの手順を繰り返します。
自動で行う場合の手順
このプロセスを自動化するには、nodes.txt ファイルと Google Cloud コンソールの次のスクリプトを使用する必要があります。
while read -u10 ZONE HOST; do gcloud compute ssh $HOST --tunnel-through-iap --quiet --zone $ZONE -- "sudo pcs stonith create STONITH-$HOST fence_gce project=project-id port=$HOST zone=$ZONE pcmk_host_list=$HOST pcmk_reboot_timeout=300 pcmk_monitor_retries=4 op monitor interval=300s timeout=120s op start interval=0 timeout=60s && sudo pcs constraint location STONITH-$HOST avoids $HOST"; done 10< nodes.txt
クラスタのデフォルトを設定する
移行のしきい値と継続性を設定して、障害が発生する前に試行するフェイルオーバーの回数を決定し、最初に現在のホストで再起動を試みるようにシステムを設定します。この処理は、1 つのノードに設定するだけで、クラスタに適用されます。
任意のホストから root として、リソースのデフォルトを設定します。
RHEL 8.0 以降
#pcs resource defaults update resource-stickiness=1000#pcs resource defaults update migration-threshold=5000RHEL 7.6 以降
#pcs resource defaults resource-stickiness=1000#pcs resource defaults migration-threshold=5000プロパティ
resource-stickinessは、サービスの運用が継続される可能性を制御します。値が大きいほど、サービスの継続性が高まります。1000の値はサービスの継続性が高いことを意味します。プロパティ
migration-thresholdは、サービスが別のホストにフェイルオーバーするまでに発生する必要がある障害の数を指定します。5,000 という値は、存続期間が短いエラー状況でのフェイルオーバーを回避するのに十分に高い値です。リソースのデフォルトを確認するには、
pcs resource defaultsを入力します。リソースのオペレーション タイムアウトのデフォルトを設定します。
RHEL 8.0 以降
#pcs resource op defaults update timeout=600sRHEL 7.6 以降
#pcs resource op defaults timeout=600sリソースのオペレーションのデフォルトを確認するには、
pcs resource op defaultsを入力します。以下のクラスタ プロパティを設定します。
#pcs property set stonith-enabled="true"#pcs property set stonith-timeout="300s"プロパティの設定は、
pcs property listで確認できます。
SAPHanaTopology リソースを作成する
SAPHanaTopology リソースは、ノード上の HANA システムレ プリケーションのステータスと構成を取得します。また、SAP ホスト エージェントも確認します。
いずれかのホストの root として、
SAPHanaTopologyリソースを作成します。RHEL 8.0 以降
#pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopology SID=SID \ InstanceNumber=inst_num \ op methods interval=0s timeout=5 \ op monitor interval=10 timeout=600 \ clone meta clone-node-max=1 interleave=trueRHEL 7.6 以降
#pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopologyScaleOut SID=SID \ InstanceNumber=inst_num \ op start timeout=600 \ op stop timeout=300 \ op monitor interval=10 timeout=600#pcs resource clone rsc_SAPHanaTopology_SID_HDBinstNr meta clone-node-max=1 interleave=trueリソースが作成されたら、構成を確認します。リソース名に
-cloneを追加して、レスポンスにクローンセット情報を含めます。RHEL 8.0 以降
#pcs resource config rsc_SAPHanaTopology_SID_HDBinstNr-clone出力は次のようになります。
Clone: SAPHanaTopology_HA1_00-clone Meta Attrs: 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) start interval=0s timeout=600 (SAPHanaTopology_HA1_00-start-interval-0s) stop interval=0s timeout=300 (SAPHanaTopology_HA1_00-stop-interval-0s)RHEL 7.6 以降
#pcs resource show rsc_SAPHanaTopology_SID_HDBinstNr-clone出力は次のようになります。
Clone: rsc_SAPHanaTopology_HA1_HDB00-clone Meta Attrs: clone-node-max=1 interleave=true Resource: rsc_SAPHanaTopology_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaTopologyScaleOut) Attributes: InstanceNumber=00 SID=HA1 Meta Attrs: clone-node-max=1 interleave=true Operations: methods interval=0s timeout=5 (rsc_SAPHanaTopology_HA1_HDB00-methods-interval-0s) monitor interval=10 timeout=600 (rsc_SAPHanaTopology_HA1_HDB00-monitor-interval-10) start interval=0s timeout=600 (rsc_SAPHanaTopology_HA1_HDB00-start-interval-0s) stop interval=0s timeout=300 (rsc_SAPHanaTopology_HA1_HDB00-stop-interval-0s)
crm_mon -A1 コマンドを使用してクラスタ属性を確認することもできます。
SAPHanaController リソースを作成する
SAPHanaController リソース エージェントは、SAP HANA システム レプリケーション用に構成されたデータベースを管理します。
SAPHana リソース定義の次のパラメータは省略可能です。
AUTOMATED_REGISTER:trueに設定すると、テイクオーバー後に DUPLICATE_PRIMARY_TIMEOUT が期限切れになると、以前のプライマリが自動的にセカンダリとして登録されます。デフォルトはfalseです。マルチ階層の SAP HANA HA クラスタで、SAP HANA 2.0 SP03 より前のバージョンを使用している場合は、
AUTOMATED_REGISTERをfalseに設定します。これにより、復元されたインスタンスが、レプリケーション ターゲットが構成済みの HANA システムへのレプリケーションを自己登録しようとすることが防止されます。SAP HANA 2.0 SP03 以降の場合は、マルチ階層システム レプリケーションを使用する SAP HANA 構成のAUTOMATED_REGISTERをtrueに設定できます。DUPLICATE_PRIMARY_TIMEOUT: デュアルプライマリの状況が発生した場合に、2 つのプライマリ タイムスタンプの時間差を秒で設定します。デフォルトは7200です。PREFER_SITE_TAKEOVER: フェイルオーバーが開始される前にローカルでの再起動を試行するかどうかを決定します。デフォルトはfalseです。
これらのパラメータの詳細については、Google Cloud への Red Hat Enterprise Linux 7.6（以降）高可用性クラスタのインストールと構成をご覧ください。Red Hat サブスクリプションが必要です。
いずれかのホストの root として、SAPHanaController リソースを作成します。
RHEL 8.0 以降
#pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \ InstanceNumber=inst_num \ PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \ op demote interval=0s timeout=320 \ op methods interval=0s timeout=5 \ op monitor interval=59 \ role="Master" timeout=700 \ op monitor interval=61 \ role="Slave" timeout=700 \ op promote interval=0 timeout=3600 \ op start interval=0 timeout=3600 \ op stop interval=0 timeout=3600e#pcs resource promotable rsc_SAPHana_SID_HDBinstNr meta master-max="1" clone-node-max=1 interleave=trueRHEL 7.6 以降
#pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \ InstanceNumber=inst_num \ PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \ op start interval=0 timeout=3600 \ op stop interval=0 timeout=3600 \ op promote interval=0 timeout=3600 \ op monitor interval=60 \ role="Master" timeout=700 \ op monitor interval=61 \ role="Slave" timeout=700#pcs resource master msl_rsc_SAPHana_SID_HDBinstNr rsc_SAPHana_SID_HDBinstNr master-max="1" clone-node-max=1 interleave=true結果のリソース属性を確認します。
RHEL 8.0 以降
#pcs resource config rsc_SAPHana_SID_HDBinstNr-clone出力は次の例のようになります。
Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHanaController) Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1 Operations: demote interval=0s timeout=320 (SAPHana_HA1_00-demote-interval-0s) methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s) monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59) promote interval=0 timeout=3600 (SAPHana_HA1_00-promote-interval-0) reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s) start interval=0 timeout=3600 (SAPHana_HA1_00-start-interval-0) stop interval=0 timeout=3600 (SAPHana_HA1_00-stop-interval-0) monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)RHEL 7.6 以降
#pcs resource show msl_rsc_SAPHana_SID_HDBinstNr出力は次の例のようになります。
Master: msl_rsc_SAPHana_HA1_HDB00 Meta Attrs: clone-node-max=1 interleave=true master-max=1 Resource: rsc_SAPHana_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaController) Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1 Operations: demote interval=0s timeout=320 (rsc_SAPHana_HA1_HDB00-demote-interval-0s) methods interval=0s timeout=5 (rsc_SAPHana_HA1_HDB00-methods-interval-0s) monitor interval=60 role=Master timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-60) monitor interval=61 role=Slave timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-61) promote interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-promote-interval-0) start interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-start-interval-0) stop interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-stop-interval-0)
仮想 IP アドレス リソースを作成する
VIP のクラスタ リソースを作成する必要があります。VIP リソースはプライマリ オペレーティング システムにローカライズされ、他のホストからはルーティングできません。ロードバランサは、ヘルスチェックに基づいて VIP に送信されたトラフィックをバックエンド ホストにルーティングします。
いずれかのホストの root として:
# pcs resource create rsc_ip_SAPHANA_SID_HDBinstNr \
IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
op monitor interval=3600s timeout=60svip-address 値は、以前に予約して、ロードバランサのフロントエンドの転送ルールで指定した IP アドレスと同じです。構成に応じて、ネットワーク インターフェースを変更します。
制約を作成する
最初に開始する必要があるサービスと、同じホストで一緒に実行する必要があるサービスを定義する制約を作成します。
開始順序の制約を定義します。
RHEL 8.0 以降
#pcs constraint order start rsc_SAPHanaTopology_SID_HDBinstNr-clone then start rsc_SAPHana_SID_HDBinstNr-cloneRHEL 7.6
#pcs constraint order rsc_SAPHanaTopology_SID_HDBinstNr-clone then rsc_SAPHana_SID_HDBinstNr-masterConfigure the majority maker to avoid taking an an active role in the cluster environment:
RHEL 8.0 and later
#pcs constraint location rsc_SAPHana_SID_HDBinstNr-clone avoids majority-maker-name#pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymakerRHEL 7.6
#pcs constraint location msl_rsc_SAPHana_SID_HDBinstNr avoids majoritymaker#pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker制約を確認します。
#pcs constraint出力は次のようになります。
Location Constraints: Resource: STONITH-hana-ha-1 Disabled on: hana-ha-1 (score:-INFINITY) Resource: STONITH-hana-ha-1w1 Disabled on: hana-ha-1w1 (score:-INFINITY) Resource: STONITH-hana-ha-2 Disabled on: hana-ha-2 (score:-INFINITY) Resource: STONITH-hana-ha-2w1 Disabled on: hana-ha-2w1 (score:-INFINITY) Resource: STONITH-majority-maker Disabled on: majority-maker (score:-INFINITY) Resource: rsc_SAPHanaTopology_HA1_HDB00-clone Disabled on: majority-maker (score:-INFINITY) Resource: rsc_SAPHana_HA1_HDB00-master Disabled on: majority-maker (score:-INFINITY) Ordering Constraints: start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)
リスナーをインストールし、ヘルスチェック リソースを作成する
ヘルスチェック リソースを構成するには、まずリスナーをインストールする必要があります。
リスナーをインストールする
ロードバランサは、各ホストのヘルスチェック ポートでリスナーを使用して、SAP HANA クラスタのプライマリ インスタンスが実行されている場所を判断します。1. プライマリ システムとセカンダリ システムのマスター インスタンスの root として、TCP リスナーをインストールします。以下の手順では、HAProxy をインストールしてリスナーとして使用します。
# yum install haproxy構成ファイル
haproxy.cfgを編集用に開きます。#vi /etc/haproxy/haproxy.cfghaproxy.cfgのデフォルト セクションで、modeをtcpに変更します。デフォルト セクションの後に、以下を追加して新しいセクションを作成します。
#--------------------------------------------------------------------- # Health check listener port for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:healthcheck-port-num
バインドポートは、ヘルスチェックの作成時に使用したポートと同じです。
完了したら、次の例のように更新されます。
#--------------------------------------------------------------------- # common defaults that all the 'listen' and 'backend' sections will # use if not designated in their block #--------------------------------------------------------------------- defaults mode tcp log global option tcplog option dontlognull option http-server-close # option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 #--------------------------------------------------------------------- # Set up health check listener for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:60000
各ホストで root として、サービスを開始し、正しく構成されていることを確認します。
#systemctl start haproxy.serviceGoogle Cloud コンソールの [ロードバランサ] ページで、ロードバランサのエントリをクリックします。
[ロードバランサの詳細] ページの [バックエンド] セクションで、両方のホストで HAProxy サービスがアクティブな場合、各インスタンス グループ エントリの [正常] の列に
1/1が表示されます。![画面キャプチャは、両方のインスタンス グループの [正常] の列に「1/1」が表示され、両方とも正常であることを示しています。](https://cloud.google.com/static/solutions/sap/docs/images/hana-ha-ilb-backend-both-healthy.png?hl=ja)
各ホストで、HAProxy サービスを停止します。
#systemctl stop haproxy.service各ホストで HAProxy サービスを停止すると、各インスタンス グループの [正常] の列に
0/1が表示されます。![画面キャプチャは、各インスタンス グループの [正常] の列に「0/1」が表示され、アクティブなリスナーがないことが示しています。](https://cloud.google.com/static/solutions/sap/docs/images/hana-ha-ilb-backend-both-unhealthy.png?hl=ja)
後でヘルスチェックが構成されると、クラスタはマスターノードのリスナーを再起動します。
ヘルスチェック リソースを作成する
任意のホストから root として、HAProxy サービスのヘルスチェック リソースを作成します。
#pcs resource create hc_SID_HDBinstNr service:haproxy op monitor interval=10s timeout=20sVIP とヘルスチェックのリソースをグループ化します。
#pcs resource group add rsc-group-name hc_SID_HDBinstNr rsc_ip_SAPHANA_SID_HDBinstNrグループをマスター SAP HANA インスタンスと同じノードに配置するための制約を作成します。
RHEL 8.0 以降
#pcs constraint colocation add rsc-group-name with master rsc_SAPHana_SID_HDBinstNr-cloneRHEL 7.6 以降
#pcs constraint colocation add rsc-group-name with master msl_rsc_SAPHana_SID_HDBinstNrHANA の昇格後にのみグループを開始する順序の制約を作成します。
#pcs constraint order promote rsc_SAPHana_SID_HDBinstNr-clone then start rsc-group-name最終的な制約は、次の例のようになります。
# pcs constraint Location Constraints: Resource: STONITH-hana-ha-1 Disabled on: hana-ha-1 (score:-INFINITY) Resource: STONITH-hana-ha-1w1 Disabled on: hana-ha-1w1 (score:-INFINITY) Resource: STONITH-hana-ha-2 Disabled on: hana-ha-2 (score:-INFINITY) Resource: STONITH-hana-ha-2w1 Disabled on: hana-ha-2w1 (score:-INFINITY) Resource: STONITH-majority-maker Disabled on: majority-maker (score:-INFINITY) Resource: rsc_SAPHanaTopology_HA1_HDB00-clone Disabled on: majority-maker (score:-INFINITY) Resource: rsc_SAPHana_HA1_HDB00-master Disabled on: majority-maker (score:-INFINITY) Ordering Constraints: start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory) promote rsc_SAPHana_HA1_HDB00-clone then start g-primary (kind:Mandatory) (id:order-rsc_SAPHana_HA1_HDB00-clone-g-primary-mandatory) Colocation Constraints: g-primary with rsc_SAPHana_HA1_HDB00-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master) Ticket Constraints:
設定を完了する
クラスタのメンテナンス モードを終了します。
pcs property set maintenance-mode=false
リソースが起動したら、ノード属性を確認して、ノード上の SAP HANA データベースの現在の状態を確認します。
#crm_mon -A1出力は次のようになります。
RHEL 8.0 以降
Cluster Summary: Stack: corosync Current DC: hana-ha-2w1 (version 2.0.5-9.el8_4.7-ba59be7122) - partition with quorum Last updated: Wed Oct 11 17:59:51 2023 Last change: Wed Oct 11 17:59:48 2023 by hacluster via crmd on hana-ha-2 5 nodes configured 17 resource instances configured Node List: Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 dru-somm ] Active Resources: STONITH-hana-ha-1 (stonith:fence_gce): Started hana-ha-2 STONITH-hana-ha-1w1 (stonith:fence_gce): Started hana-ha-1 STONITH-hana-ha-2 (stonith:fence_gce): Started hana-ha-2w1 STONITH-hana-ha-2w1 (stonith:fence_gce): Started dru-somm STONITH-dru-somm (stonith:fence_gce): Started hana-ha-1 Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]: Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ] Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00]-(promotable): Slaves: [ hana-ha-1w1 hana-ha-2w1 ] Resource Group: g-primary: healthcheck_HA1 (service:haproxy): Started hana-ha-1 ip_SAPHANA_HA1_00 (ocf::heartbeat:IPaddr2): Started hana-ha-1 Node Attributes: Node: hana-ha-1: hana_ha1_clone_state : PROMOTED hana_ha1_gra : 2.0 hana_ha1_remoteHost : hana-ha-2w1 hana_ha1_roles : master1:master:worker:master hana_ha1_site : hana-ha-1 hana_ha1_sra : - hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-1 master-SAPHana_HA1_00 : 5 Node: hana-ha-1w1: hana_ha1_clone_state : DEMOTED hana_ha1_gra : 2.0 hana_ha1_remoteHost : hana-ha-2w1 hana_ha1_roles : slave:slave:worker:slave hana_ha1_site : hana-ha-1 hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-1w1 master-SAPHana_HA1_00 : -INFINITY Node: hana-ha-2: hana_ha1_clone_state : DEMOTED hana_ha1_gra : 2.0 hana_ha1_remoteHost : hana-ha-1w1 hana_ha1_roles : master1:master:worker:master hana_ha1_site : hana-ha-2 hana_ha1_sra : - hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-2 master-SAPHana_HA1_00 : 100 Node: hana-ha-2w1: hana_ha1_clone_state : DEMOTED hana_ha1_gra : 2.0 hana_ha1_remoteHost : hana-ha-1w1 hana_ha1_roles : slave:slave:worker:slave hana_ha1_site : hana-ha-2 hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-2w1 master-SAPHana_HA1_00 : -12200 Node: dru-somm: hana_ha1_remoteHost : hana-ha-2w1 hana_ha1_srmode : syncmem
RHEL 7.6 以降
Stack: corosync Current DC: majority-maker (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum Last updated: Wed Oct 11 17:58:07 2023 Last change: Wed Oct 11 17:57:57 2023 by hacluster via crmd on hana-ha-2w1 5 nodes configured 17 resource instances configured Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 majority-maker ] Active resources: STONITH-hana-ha-1 (stonith:fence_gce): Started hana-ha-1w1 STONITH-hana-ha-1w1 (stonith:fence_gce): Started hana-ha-2 STONITH-hana-ha-2 (stonith:fence_gce): Started hana-ha-1 STONITH-hana-ha-2w1 (stonith:fence_gce): Started majority-maker STONITH-majority-maker (stonith:fence_gce): Started hana-ha-1w1 Master/Slave Set: msl_rsc_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] rsc_SAPHana_HA1_HDB00 (ocf::heartbeat:SAPHanaController): Master hana-ha-1 (Monitoring) Slaves: [ hana-ha-1w1 hana-ha-2 hana-ha-2w1 ] Clone Set: rsc_SAPHanaTopology_HA1_HDB00-clone [rsc_SAPHanaTopology_HA1_HDB00] Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ] Resource Group: g-primary hc_HA1_HDB00 (service:haproxy): Started hana-ha-1 rsc_ip_SAPHANA_HA1_HDB00 (ocf::heartbeat:IPaddr2): Started hana-ha-1 Node Attributes: Node hana-ha-1: hana_ha1_clone_state : PROMOTED hana_ha1_remoteHost : hana-ha-2 hana_ha1_roles : master1:master:worker:master hana_ha1_site : hana-ha-1 hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-1 master-rsc_SAPHana_HA1_HDB00 : 150 Node hana-ha-1w1: hana_ha1_clone_state : DEMOTED hana_ha1_remoteHost : hana-ha-2w1 hana_ha1_roles : slave:slave:worker:slave hana_ha1_site : hana-ha-1 hana_ha1_srmode : syncmem hana_ha1_version : 2.00.052.00.1599235305 hana_ha1_vhost : hana-ha-1w1 master-rsc_SAPHana_HA1_HDB00 : -10000 Node hana-ha-2: hana_ha1_clone_state : DEMOTED hana_ha1_remoteHost : hana-ha-2w1 hana_ha1_roles : master1:master:worker:master hana_ha1_site : hana-ha-2 hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-2 master-rsc_SAPHana_HA1_HDB00 : 100 Node hana-ha-2w1: hana_ha1_clone_state : DEMOTED hana_ha1_remoteHost : hana-ha-1 hana_ha1_roles : slave:slave:worker:slave hana_ha1_site : hana-ha-2 hana_ha1_srmode : syncmem hana_ha1_vhost : hana-ha-2w1 master-rsc_SAPHana_HA1_HDB00 : -12200 Node majority-maker: hana_ha1_srmode : syncmem
障害が発生したクラスタ リソースがある場合は、次のコマンドの実行が必要になることがあります。
pcs resource cleanup
フェイルオーバーをテストする
プライマリ ホストで障害をシミュレートして、クラスタをテストします。テストシステムを使用するか、システムをリリースする前に本番環境システムでテストを実施します。
テストの前にシステムをバックアップします。
次のようなさまざまな方法で障害をシミュレートできます。
HDB stopHDB killreboot（アクティブ ノード）- 単一のネットワーク インターフェースを持つインスタンスの場合は
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 DROPSSH を使用していずれかのホストに再接続し、root ユーザーに変更します。
「
pcs status」と入力して、セカンダリ ホストの格納に使用していた VM でプライマリ ホストがアクティブになっていることを確認します。次の例に示すように、クラスタで自動再起動が有効になっているため、停止したホストが再起動し、セカンダリ ホストの役割を引き継ぎます。Cluster name: hana-ha-cluster Stack: corosync Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum Last updated: Wed Jun 17 01:04:36 2020 Last change: Wed Jun 17 01:03:58 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: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1 Stopped: [ hana-ha-vm-mm ] ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-2 ] Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1 Stopped: [ hana-ha-vm-mm ] ] Resource Group: g-primary rsc_healthcheck_HA1 (service:haproxy): Started hana-ha-vm-2 rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
トラブルシューティング
RHEL 上での SAP HANA 用の高可用性構成に関する問題のトラブルシューティングについては、SAP 高可用性構成のトラブルシューティングをご覧ください。
RHEL 上での SAP HANA のサポートを受ける
RHEL 上での SAP HANA 用の高可用性クラスタの問題を解決するには、必要な診断情報を収集し、Cloud カスタマーケアまでお問い合わせください。詳細については、RHEL の診断情報での高可用性クラスタをご覧ください。
サポート
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 ネットワーク インターフェースの全体的なネットワーク スループットを改善できます。
詳細については、以下をご覧ください。
次のステップ
詳細については、以下のリソースをご覧ください。
- Google Compute Cloud への Red Hat Enterprise Linux 7.6（以降）高可用性クラスタのインストールと構成
- Pacemaker クラスタでのスケールアップにおける SAP HANA システム レプリケーションの自動化
- RHEL 高可用性クラスタのサポート ポリシー - フェンシング/STONITH の一般的な要件
- SAP HANA 高可用性プランニング ガイド
- SAP HANA 障害復旧プランニング ガイド
- VM の管理とモニタリングの詳細については、SAP HANA 運用ガイドをご覧ください。