RHEL での SAP HANA の HA スケールアップ クラスタ構成ガイド

このガイドでは、Google Cloud 上の SAP HANA 1.0 SPS 12 以降のスケールアップ システム用に Red Hat Enterprise Linux(RHEL)高可用性(HA)クラスタをデプロイして構成する方法を説明します。

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

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

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

SUSE Linux Enterprise Server(SLES)で SAP HANA の HA クラスタを構成するには、SLES での SAP HANA スケールアップの HA クラスタ構成ガイドをご覧ください。

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

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

このガイドに従って、2 つの SAP HANA インスタンスをデプロイし、RHEL に HA クラスタを設定します。各 SAP HANA インスタンスを、同じリージョン内の異なるゾーンにある Compute Engine VM にデプロイします。SAP NetWeaver の高可用性インストールについては、このガイドでは説明しません。

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

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

  • それぞれ SAP HANA のインスタンスを持つ 2 つのホスト VM。
  • 同期 SAP HANA システム レプリケーション。
  • Pacemaker 高可用性クラスタ リソース マネージャー。
  • STONITH フェンシング メカニズム。
  • 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動。

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

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

前提条件

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

ネットワークの作成

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

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

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

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

コンソール

  1. Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. [VPC ネットワークを作成] をクリックします。
  3. ネットワークの名前を入力します。

    命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。

  4. [サブネット作成モード] で [カスタム] をクリックします。
  5. [新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
    1. サブネットの名前を入力します。
    2. [リージョン] で、サブネットを作成する Compute Engine のリージョンを選択します。
    3. [IP スタックタイプ] で [IPv4(シングルスタック)] を選択し、CIDR 形式で IP アドレス範囲を入力します。(10.1.0.0/24 など)

      これはサブネットのプライマリ IPv4 範囲です。複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。

    4. [完了] をクリックします。
  6. さらにサブネットを追加するには、[サブネットを追加] をクリックして前の手順を繰り返します。ネットワークを作成した後で、ネットワークにさらにサブネットを追加できます。
  7. [作成] をクリックします。

gcloud

  1. Cloud Shell に移動します。

    Cloud Shell に移動

  2. カスタム サブネットワーク モードで新しいネットワークを作成するには、次のコマンドを実行します。
    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    NETWORK_NAME は、新しいネットワークの名前に置き換えます。命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。

    デフォルトの自動モードでは、各 Compute Engine リージョンにサブネットが自動的に作成されます。この自動モードを使用しないようにするには、--subnet-mode custom を指定します。詳しくは、サブネット作成モードをご覧ください。

  3. サブネットワークを作成し、リージョンと 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 範囲は、単一のリージョンにマッピングされることに注意してください。

  4. 必要に応じて前の手順を繰り返し、サブネットワークを追加します。

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 アドレスがわからない場合は、社内のネットワーク管理者に確認してください。
  • SAP HANA サブネットワークの VM 間の通信(SAP HANA スケールアウト システムのノード間の通信や、3 層アーキテクチャのデータベース サーバーとアプリケーション サーバー間の通信など)。VM 間の通信を有効にするには、サブネットワーク内から発信されるトラフィックを許可するファイアウォール ルールを作成する必要があります。

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

コンソール

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

    [ファイアウォール] に移動

  2. ページ上部の [ファイアウォール ルールを作成] をクリックします。

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

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 のデプロイ

HA クラスタの構成を開始する前に、HA クラスタのプライマリ ノードとセカンダリ ノードとして機能する VM インスタンスと SAP HANA システムを定義してデプロイします。

システムを定義してデプロイするには、SAP HANA デプロイガイドで SAP HANA システムのデプロイに使用するのと同じ Cloud Deployment Manager テンプレートを使用します。

ただし、1 つではなく 2 つのシステムをデプロイするには、最初のシステムの定義をコピーして貼り付け、2 つ目のシステムの定義を構成ファイルに追加する必要があります。2 番目の定義を作成したら、2 番目の定義のリソース名とインスタンス名を変更します。ゾーン障害から保護するには、同じリージョン内の別のゾーンを指定します。2 つの定義のその他のプロパティ値はすべて同じです。

SAP HANA システムが正常にデプロイされたら、HA クラスタを定義して構成します。

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

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

    [割り当て] ページに移動

  2. Cloud Shell を開くか、gcloud CLI をローカル ワークステーションにインストールしている場合はターミナルを開きます。

    Cloud Shell に移動

  3. Cloud Shell または gcloud CLI で次のコマンドを入力して、SAP HANA 高可用性クラスタの template.yaml 構成ファイル テンプレートを作業ディレクトリにダウンロードします。

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml
  4. 必要に応じて template.yaml のファイル名を変更し、このファイルで定義する構成がわかるようにします。

  5. Cloud Shell コードエディタで template.yaml ファイルを開きます。gcloud CLI を使用している場合は、任意のテキスト エディタで開きます。

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

  6. 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 数とメモリ量を変更してください。
    zone 文字列 定義している VM インスタンスをデプロイする Google Cloud ゾーン。プライマリとセカンダリの HANA 定義に同じリージョン内に異なるゾーンを指定します。このゾーンは、サブネットに選択したのと同じリージョンに存在する必要があります。
    subnetwork 文字列 前のステップで作成したサブネットワークの名前。共有 VPC にデプロイする場合は、この値を [SHAREDVPC_PROJECT]/[SUBNETWORK] の形式で指定します。例: myproject/network1
    linuxImage 文字列 SAP HANA で使用する Linux オペレーティング システム イメージまたはイメージ ファミリーの名前。イメージ ファミリーを指定するには、ファミリー名に接頭辞 family/ を追加します。例: family/rhel-7-6-sap-ha特定のイメージを指定するには、イメージ名のみを指定します。使用可能なイメージとファミリーのリストについては、Google Cloud コンソールの [イメージ] ページをご覧ください。
    linuxImageProject 文字列 使用するイメージを含む Google Cloud プロジェクト。このプロジェクトは独自のプロジェクトか、rhel-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 整数 0 を指定します。これらの手順はスケールアップ SAP HANA システム専用です。
    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 です。
    serviceAccount 文字列 省略可。ホスト VM と、ホスト VM で実行されるプログラムが使用するサービス アカウントを指定します。サービス アカウントのメールアドレスを指定します。たとえば、svc-acct-name@project-id.iam.gserviceaccount.comのようにします。デフォルトでは、Compute Engine のデフォルトのサービス アカウントが使用されます。詳細については、Google Cloud 上での SAP プログラムの Identity and Access Management をご覧ください。
  7. プライマリ SAP HANA システムの定義をコピーし、それをプライマリ SAP HANA システム定義の後に貼り付けて、セカンダリ SAP HANA システムの定義を作成します。次の手順の例を参照してください。

  8. セカンダリ SAP HANA システムの定義で、次のプロパティにプライマリ SAP HANA システム定義とは異なる値を指定します。

    • name
    • instanceName
    • zone

  9. 次のコマンドを実行して、インスタンスを作成します。

    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 つの VM インスタンスをデプロイする完全な template.yaml 構成ファイルを示しています。

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

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

プロパティ networkTagserviceAccountsap_hana_sidadm_uidsap_hana_sapsys_gid は、構成ファイル テンプレートの [詳細オプション] セクションにあります。プロパティ sap_hana_sidadm_uidsap_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/rhel-8-1-sap-ha
    linuxImageProject: rhel-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: 0
    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/rhel-8-1-sap-ha
    linuxImageProject: rhel-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: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    

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

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

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

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

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

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

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

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

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

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

    Cloud Logging に移動

  2. ログをフィルタします。

    ログ エクスプローラ

    1. [ログ エクスプローラ] ページで、[クエリ] ペインに移動します。

    2. [リソース] プルダウン メニューから [グローバル] を選択し、[追加] をクリックします。

      [グローバル] オプションが表示されない場合は、クエリエディタに次のクエリを入力します。

      resource.type="global"
      "Deployment"
      
    3. [クエリを実行] をクリックします。

    以前のログビューア

    • [以前のログビューア] ページの基本的なセレクタ メニューから、ロギング リソースとして [グローバル] を選択します。
  3. フィルタされたログを分析します。

    • "--- Finished" が表示されている場合、デプロイメントは完了しています。次の手順に進んでください。
    • 割り当てエラーが発生した場合:

      1. [IAM と管理] の [割り当て] ページで、SAP HANA プランニング ガイドに記載されている SAP HANA の要件を満たしていない割り当てを増やします。

      2. Deployment Manager の [デプロイ] ページでデプロイメントを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。

      3. デプロイを再実行します。

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

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

    Compute Engine VM インスタンス ページの SSH ボタン

  2. root ユーザーに変更します。

    $ sudo su -
  3. コマンド プロンプトで 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
  4. 次のコマンドの SID_LC を構成ファイルのテンプレートで指定したシステム ID で置き換え、SAP 管理ユーザーに変更します。すべて小文字を使用します。

    # su - SID_LCadm
  5. 次のコマンドを入力して、hdbnameserverhdbindexserver などの SAP HANA サービスがインスタンス上で実行されていることを確認します。

    > HDB info
  6. RHEL for SAP 9.0 以降を使用する場合は、パッケージ chkconfigcompat-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 用エージェントが実行されていることを確認する

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

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

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

    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 に正しく送信されていることを確認するには、次の操作を行います。

  1. SAP システムで、トランザクションとして「ST06」を入力します。
  2. 概要ウィンドウで可用性と以下のフィールドの内容を確認し、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 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*/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 を有効にするには、次の手順を行います。

  1. ホスト VM との SSH 接続を確立します。

  2. root に切り替えます。

    sudo su -

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

    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh
  4. ファイルを実行可能にします。

    chmod +x sap_lib_hdbfr.sh
  5. スクリプトにエラーがないことを確認します。

    vi sap_lib_hdbfr.sh
    ./sap_lib_hdbfr.sh -help

    コマンドからエラーが返された場合は、Cloud カスタマーケアにお問い合わせください。カスタマーケアへのお問い合わせ方法については、Google Cloud での SAP に関するサポートを受けるをご覧ください。

  6. スクリプトを実行する前に、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)

省略可: プライマリ VM とセカンダリ VM で SSH 認証鍵を構成する

SAP HANA セキュアストア(SSFS)鍵は、HA クラスタ内のホスト間で同期する必要があります。同期を簡略化し、バックアップなどのファイルを HA クラスタ内のホスト間でコピーできるようにするため、これらの手順では 2 つのホスト間の直接 SSH 接続を承認します。

組織には、内部ネットワーク通信を管理するガイドラインがある場合があります。必要に応じて、デプロイの完了後に VM からメタデータを削除し、authorized_keys ディレクトリから鍵を削除します。

直接 SSH 接続の設定が組織のガイドラインに準拠していない場合は、次のような別の方法で SSFS 鍵を同期し、ファイルを転送できます。

  • Cloud Shell の [ファイルをアップロード] と [ファイルをダウンロード] のメニュー オプションを使用して、ローカル ワークステーションから小さいファイルを転送します。Cloud Shell を使用したファイルの管理をご覧ください。
  • Google Cloud Storage バケットを使用してファイルを交換します。Cloud Storage ドキュメントオブジェクトの処理をご覧ください。
  • Cloud Storage Backint agent for SAP HANA を使用して、HANA データベースのバックアップと復元を行います。Cloud Storage Backint agent for SAP HANA をご覧ください。
  • Filestore や NetApp Cloud Volumes Service などのファイル ストレージ ソリューションを使用して、共有フォルダを作成します。ファイル サーバーのオプションをご覧ください。

プライマリ インスタンスとセカンダリ インスタンス間の SSH 接続を有効にする手順は次のとおりです。

  1. プライマリ ホスト VM で、次のようにします。

    1. VM に SSH 接続します。

    2. ホスト間の SSH 接続を必要とするユーザーの SSH 認証鍵を生成します。通常、ユーザーはご自身です。

      $ ssh-keygen
    3. プロンプトで、Enter キーを押してデフォルトを受け入れます。

    4. プライマリ VM のメタデータを、セカンダリ VM の SSH 認証鍵に関する情報で更新します。

      $ gcloud compute instances add-metadata secondary-host-name \
           --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
           --zone secondary-zone
    5. プライマリ VM をそれ自体に対して認可します。

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  2. セカンダリ ホスト VM で、次のようにします。

    1. VM に SSH 接続します。

    2. ホスト間の SSH 接続を必要とするユーザーの SSH 認証鍵を生成します。

      $ ssh-keygen
    3. セカンダリ VM のメタデータを、プライマリ VM の SSH 認証鍵に関する情報で更新します。

      $ gcloud compute instances add-metadata primary-host-name \
            --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
            --zone primary-zone
    4. セカンダリ VM をそれ自体に対して認可します。

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. セカンダリ システムからプライマリ システムへの SSH 接続を開き、SSH 認証鍵が正しく設定されていることを確認します。

      $ ssh primary-host-name
  3. プライマリ ホスト VM で、セカンダリ ホスト VM への SSH 接続を開いて接続を確認します。

    $ ssh secondary-host-name

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

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

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

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

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

  1. プライマリ ホストで、SID_LCadm に切り替えます。OS イメージによっては、コマンドが異なる場合があります。

    sudo -i -u SID_LCadm
  2. データベースのバックアップを作成します。

    • 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)
  3. ロギングモードが通常に設定されていることを確認します。

    > 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 つにすぎません。

  1. プライマリ ホストで、SID_LCadm としてシステム レプリケーションを有効にします。

    > hdbnsutil -sr_enable --name=primary-host-name
  2. セカンダリ ホストで、SID_LCadm として SAP HANA を停止します。

    > HDB stop
  3. プライマリ ホストで、ホスト VM 間の SSH の設定に使用したのと同じユーザー アカウントを使い、鍵ファイルをセカンダリ ホストにコピーします。便宜上、次のコマンドではユーザー アカウント ID の環境変数も定義しています。

    $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
    $ myid=$(whoami)
    $ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
    $ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
    $ rm -r /home/"${myid}"/rsecssfs
    
  4. セカンダリ ホストで、前の手順と同じユーザーとして次を行います。

    1. rsecssfs ディレクトリ内の既存の鍵ファイルをプライマリ ホストのファイルに置き換え、アクセスを制限するファイル権限を設定します。

      $ SAPSID=SID
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ myid=$(whoami)
      $ sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chmod 644 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chmod 640 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
    2. ホーム ディレクトリのファイルをクリーンアップします。

      $ rm -r /home/"${myid}"/rsecssfs
    3. SID_LCadm として、セカンダリ SAP HANA システムを SAP HANA システム レプリケーションに登録します。

      > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
      --replicationMode=syncmem --operationMode=logreplay --name=secondary-host-name
    4. SID_LCadm として SAP HANA を起動します。

      > HDB start

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

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

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

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

  • Secondary Active StatusYES
  • Replication StatusACTIVE

また、overall system replication statusACTIVE です。

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

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

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

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

  1. Cloud Shell を開きます。

    Cloud Shell に移動

  2. 仮想 IP の IP アドレスを予約します。これは、アプリケーションが SAP HANA へのアクセスに使用する IP アドレスです。--addresses フラグを省略すると、指定したサブネット内の IP アドレスが自動的に選択されます。

    $ gcloud compute addresses create VIP_NAME \
      --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
      --addresses VIP_ADDRESS

    静的 IP の予約の詳細については、静的内部 IP アドレスの予約をご覧ください。

  3. 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 のインスタンス グループを作成する

  1. 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
    
  2. インスタンス グループが作成されたことを確認します。

    $ 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 ヘルスチェックを作成する

  1. 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
  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/16130.211.0.0/22)からホスト VM へのアクセスを許可します。詳細については、ヘルスチェック用のファイアウォール ルールの作成をご覧ください。

  1. ホスト 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
    
  2. まだ作成していない場合は、ヘルスチェックを許可するファイアウォール ルールを作成します。

    $ 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

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

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

    $ 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
  2. プライマリ インスタンス グループをバックエンド サービスに追加します。

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --instance-group PRIMARY_IG_NAME \
      --instance-group-zone PRIMARY_ZONE \
      --region CLUSTER_REGION
  3. セカンダリのフェイルオーバー インスタンス グループをバックエンド サービスに追加します。

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --instance-group SECONDARY_IG_NAME \
      --instance-group-zone SECONDARY_ZONE \
      --failover \
      --region CLUSTER_REGION
  4. 転送ルールを作成します。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 ユーティリティを使用して、ヘルスチェック ポートを一時的にリッスンできます。

  1. 両方のホスト VM に socat ユーティリティをインストールします。

    $ sudo yum install -y socat

  2. socat プロセスを開始して、ヘルスチェック ポートで 60 秒間リッスンします。

    $ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

  3. 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 を一時的に使用するには、次の手順に従います。

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

    [ヘルスチェック] ページに移動

  2. [編集] をクリックします。

  3. [ポート] 項目で、ポート番号を 22 に変更します。

  4. [保存] をクリックし、1~2 分待ちます。

  5. 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
  6. 完了したら、ヘルスチェックのポート番号を元のポート番号に戻します。

Pacemaker を設定する

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

この手順は、以下を含む高可用性クラスタを構成するための Red Hat のドキュメントに基づいています(Red Hat サブスクリプションが必要です)。

両方のノードにクラスタ エージェントをインストールする

両方のノードで次の手順を行います。

  1. root として、Pacemaker コンポーネントをインストールします。

    # yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
    # yum update -y

    Google 提供の RHEL-for-SAP イメージを使用している場合、これらのパッケージはすでにインストールされていますが、一部更新が必要な場合があります。

  2. パッケージの一部としてインストールされる hacluster ユーザーのパスワードを設定します。

    # passwd hacluster
  3. プロンプトで、hacluster のパスワードを指定します。

  4. Google Cloud が提供する RHEL イメージでは、OS ファイアウォール サービスがデフォルトで有効になっています。高可用性トラフィックを許可するようにファイアウォール サービスを構成します。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
  5. pcs サービスを起動し、起動時に有効化するように構成します。

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  6. pcs サービスのステータスを確認します。

    # 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-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
    Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
  7. /etc/hosts ファイルに、クラスタ内の両方のホストの完全なホスト名と内部 IP アドレスを追加します。次に例を示します。

    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    10.0.0.40 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1  # Added by Google
    10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-ha-vm-2
    169.254.169.254 metadata.google.internal  # Added by Google

    RHEL クラスタノードでの /etc/hosts ファイルの設定に関する Red Hat からの詳細情報については、https://access.redhat.com/solutions/81123 をご覧ください。

クラスタを作成する

  1. いずれかのノードの root として、hacluster ユーザーを承認します。RHEL バージョンのタブをクリックすると、コマンドが表示されます。

    RHEL 8 以降

    # pcs host auth primary-host-name secondary-host-name

    RHEL 7

    # pcs cluster auth primary-host-name secondary-host-name
  2. プロンプトで、hacluster ユーザーに設定した hacluster ユーザー名とパスワードを入力します。

  3. クラスタを作成します。

    RHEL 8 以降

    # pcs cluster setup cluster-name primary-host-name secondary-host-name

    RHEL 7

    # pcs cluster setup --name cluster-name primary-host-name secondary-host-name

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

プライマリ ホストの /etc/corosync/corosync.conf ファイルを編集して、Google Cloud 上の HA クラスタのフォールト トレラントをテストするためのより適切な開始ポイントを設定します。

  1. どちらのホストでも、任意のテキスト エディタを使用して /etc/corosync/corosync.conf ファイルを編集用に開きます。

    # /etc/corosync/corosync.conf
  2. /etc/corosync/corosync.conf が新しいファイルまたは空の場合は、/etc/corosync/ ディレクトリでサンプル ファイルを確認し、corosync ファイルの基礎として使用できます。

  3. corosync.conf ファイルの totem セクションに、次のプロパティと RHEL のバージョンごとの推奨値を追加します。

    RHEL 8 以降

    • transport: knet
    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    次に例を示します。

    totem {
    version: 2
    cluster_name: hacluster
    secauth: off
    transport: knet
    token: 20000
    token_retransmits_before_loss_const: 10
    join: 60
    max_messages: 20
    }
    ...

    RHEL 7

    • transport: udpu
    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    次に例を示します。

    totem {
    version: 2
    cluster_name: hacluster
    secauth: off
    transport: udpu
    token: 20000
    token_retransmits_before_loss_const: 10
    join: 60
    max_messages: 20
    }
    ...
  4. 編集した corosync.conf ファイルを含むホストから、クラスタ全体に corosync 構成を同期します。

    RHEL 8 以降

    # pcs cluster sync corosync

    RHEL 7

    # pcs cluster sync
  5. 自動的に起動するようにクラスタを設定します。

    1. # pcs cluster enable --all
    2. # pcs cluster start --all
  6. corosync-cmapctl ユーティリティを使用して、クラスタで新しい corosync 設定が有効なことを確認します。

    # corosync-cmapctl

フェンスを設定する

Google Cloud が提供する RHEL イメージには、Google Cloud に固有の fence_gce フェンス エージェントが含まれています。fence_gce を使用して、各ホスト VM のフェンス デバイスを作成します。

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

fence_gce フェンス エージェントで利用可能なすべてのオプションを確認するには、fence_gce -h を発行します。

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

  1. プライマリ ホストで root として以下を行います。

    1. 各ホスト VM にフェンス デバイスを作成します。

      # pcs stonith create primary-fence-name fence_gce \
        port=primary-host-name \
        zone=primary-host-zone \
        project=project-id \
        pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
        op monitor interval="300s" timeout="120s" \
        op start interval="0" timeout="60s"
      # pcs stonith create secondary-fence-name fence_gce \
        port=secondary-host-name \
        zone=secondary-host-zone \
        project=project-id \
        pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
        op monitor interval="300s" timeout="120s" \
        op start interval="0" timeout="60s"
    2. 各フェンス デバイスを他のホスト VM に対して制限します。

      # pcs constraint location primary-fence-name avoids primary-host-name
      # pcs constraint location secondary-fence-name avoids secondary-host-name
  2. プライマリ ホストで root として、セカンダリ フェンス デバイスをテストします。

    1. セカンダリ ホスト VM をシャットダウンします。

      # fence_gce -o off -n secondary-host-name --zone=secondary-host-zone

      コマンドが成功すると、セカンダリ ホスト VM への接続が失われ、その VM は Google Cloud コンソールの [VM インスタンス] ページで停止したものとして表示されます。ページの更新が必要になる場合があります。

    2. セカンダリ ホスト VM を再起動します。

      # fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
  3. セカンダリ ホストで root として、コマンド内のプライマリ ホストの値を使用し、前述の手順を繰り返してプライマリ フェンス デバイスをテストします。

  4. いずれかのホストで root として、クラスタのステータスを確認します。

    # pcs status

    クラスタ ステータスのリソース セクションに、次の例のようにフェンス リソースが表示されます。

    [root@hana-ha-vm-2 ~]# pcs status
    Cluster name: hana-ha-cluster
    Stack: corosync
    Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Mon Jun 15 17:19:07 2020
    Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on hana-ha-vm-1
    
    2 nodes configured
    2 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    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
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

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

  1. 両方のホストで、root として Corosync の起動を遅延させる systemd ドロップイン ファイルを作成し、フェンス付き VM の再起動後に適切な一連のイベントが行われるようにします。

    systemctl edit corosync.service
  2. このファイルに次の行を追加します。

    [Service]
    ExecStartPre=/bin/sleep 60
  3. ファイルを保存し、エディタを終了します。

  4. systemd マネージャー構成を再読み込みします。

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

    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

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

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

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

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

    > HDB stop

  1. root または SID_LCadm として、global.ini ファイルを編集用に開きます。

    > vi /hana/shared/SID/global/hdb/custom/config/global.ini
  2. global.ini ファイルに次の定義を追加します。

    [ha_dr_provider_SAPHanaSR]
    provider = SAPHanaSR
    path = /usr/share/SAPHanaSR/srHook
    execution_order = 1
    
    [trace]
    ha_dr_saphanasr = info

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

    > sudo visudo -f /etc/sudoers.d/20-saphana
  4. /etc/sudoers.d/20-saphana ファイルに次のテキストを追加します。

    次のように置き換えます。

    • SITE_A: プライマリ SAP HANA サーバーのサイト名
    • SITE_B: セカンダリ SAP HANA サーバーのサイト名
    • SID_LC: SID は小文字で指定します
    サイト名を確認するには、SAP HANA プライマリ サーバーまたはセカンダリ サーバーで、root ユーザーとしてコマンド crm_mon -A1 | grep site を実行します。
    Cmnd_Alias SITEA_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
    Cmnd_Alias SITEA_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
    Cmnd_Alias SITEB_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
    Cmnd_Alias SITEB_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
    SID_LCadm ALL=(ALL) NOPASSWD: SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL
    Defaults!SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL !requiretty

  5. /etc/sudoers ファイルに次のテキストが含まれていることを確認します。

    #includedir /etc/sudoers.d

    このテキストの # は構文の一部であり、行がコメントであることを意味するわけではありません。

  6. SID_LCadm として SAP HANA を起動します。

    > HDB start

  7. フック スクリプトから報告されたステータスを、プライマリ ホスト上で SID_LCadm としてテストします。

    > cdtrace
    > awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

クラスタのデフォルトを設定する

移行のしきい値と継続性を設定して、障害が発生する前に試行するフェイルオーバーの回数を決定し、最初に現在のホストで再起動を試みるようにシステムを設定します。この処理は、1 つのノードに設定するだけで、クラスタに適用されます。

  1. いずれかのホストで root として、クラスタを起動します。

    # pcs cluster start --all #start the cluster
  2. リソースのデフォルトを設定します。

    # pcs resource defaults resource-stickiness=1000
    # pcs resource defaults migration-threshold=5000

    プロパティ resource-stickiness は、サービスの運用が継続される可能性を制御します。値が大きいほど、サービスの継続性が高まります。1000 の値はサービスの継続性が高いことを意味します。

    プロパティ migration-threshold は、サービスが別のホストにフェイルオーバーするまでに発生する必要がある障害の数を指定します。5,000 という値は、存続期間が短いエラー状況でのフェイルオーバーを回避するのに十分に高い値です。

    リソースのデフォルトを確認するには、pcs resource defaults を入力します。

  3. リソースのオペレーション タイムアウトのデフォルトを設定します。

    # pcs resource op defaults timeout=600s

    リソースのオペレーションのデフォルトを確認するには、pcs resource op defaults を入力します。

  4. 以下のクラスタ プロパティを設定します。

    # pcs property set stonith-enabled="true"
    # pcs property set stonith-timeout="300s"
    

    プロパティの設定は、pcs property list で確認できます。

SAPHanaTopology リソースを作成する

SAPHanaTopology リソースは、ノード上の HANA システムレ プリケーションのステータスと構成を取得します。また、SAP ホスト エージェントも確認します。

  1. いずれかのホストの root として、SAPHanaTopology リソースを作成します。

    # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
       InstanceNumber=inst_num \
       op start timeout=600 \
       op stop timeout=300 \
       op monitor interval=10 timeout=600 \
       clone clone-max=2 clone-node-max=1 interleave=true
  2. リソースが作成されたら、構成を確認します。リソース名に -clone を追加して、レスポンスにクローンセット情報を含めます。

    RHEL 8 以降

    # pcs resource config topology_resource_name-clone

    RHEL 7

    # pcs resource show topology_resource_name-clone

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

    Clone: SAPHanaTopology_HA1_22-clone
    Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
    Resource: SAPHanaTopology_HA1_22 (class=ocf provider=heartbeat type=SAPHanaTopology)
     Attributes: InstanceNumber=22 SID=HA1
     Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_22-methods-interval-0s)
                 monitor interval=10 timeout=600 (SAPHanaTopology_HA1_22-monitor-interval-10)
                 reload interval=0s timeout=5 (SAPHanaTopology_HA1_22-reload-interval-0s)
                 start interval=0s timeout=600 (SAPHanaTopology_HA1_22-start-interval-0s)
                 stop interval=0s timeout=300 (SAPHanaTopology_HA1_22-stop-interval-0s)

crm_mon -A1 コマンドを使用してクラスタ属性を確認することもできます。

SAPHana リソースを作成する

SAPHana リソース エージェントは、SAP HANA システム レプリケーション用に構成されたデータベースを管理します。

SAPHana リソース定義の次のパラメータは省略可能です。

  • AUTOMATED_REGISTER: true に設定すると、テイクオーバー後に DUPLICATE_PRIMARY_TIMEOUT が期限切れになると、以前のプライマリが自動的にセカンダリとして登録されます。デフォルトは false です。

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

  • DUPLICATE_PRIMARY_TIMEOUT: デュアルプライマリの状況が発生した場合に、2 つのプライマリ タイムスタンプの時間差を秒で設定します。デフォルトは 7200 です。

  • PREFER_SITE_TAKEOVER: フェイルオーバーが開始される前にローカルでの再起動を試行するかどうかを決定します。デフォルトは false です。

これらのパラメータの詳細については、Google Cloud への Red Hat Enterprise Linux 7.6(以降)高可用性クラスタのインストールと構成をご覧ください。Red Hat サブスクリプションが必要です。

  1. いずれかのホストの root として、SAP HANA リソースを作成します。

    RHEL 8 以降

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
    InstanceNumber=inst_num \
    PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Slave" timeout=700 \
    op monitor interval=59 role="Master" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable meta notify=true clone-max=2 clone-node-max=1 interleave=true

    RHEL 7

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
    InstanceNumber=inst_num \
    PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Slave" timeout=700 \
    op monitor interval=59 role="Master" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    master meta notify=true clone-max=2 clone-node-max=1 interleave=true
  2. 結果のリソース属性を確認します。

    RHEL 8 以降

    # pcs resource config sap_hana_resource_name

    RHEL 7

    # pcs resource show sap_hana_resource_name

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

     Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
      Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1
      Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
      Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s)
                  methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
                  monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
                  monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
                  promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
                  reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
                  start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
                  stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)
  3. リソースが起動したら、ノード属性を確認して、ノード上の SAP HANA データベースの現在の状態を確認します。

    # crm_mon -A1

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

    Stack: corosync
    Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Tue Jun 16 20:07:51 2020
    Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1
    
    2 nodes configured
    6 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    Active 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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    
    Node Attributes:
    * Node hana-ha-vm-1:
       + hana_ha1_clone_state              : PROMOTED
       + hana_ha1_op_mode                  : logreplay
       + hana_ha1_remoteHost               : hana-ha-vm-2
       + hana_ha1_roles                    : 4:P:master1:master:worker:master
       + hana_ha1_site                     : hana-ha-vm-1
       + hana_ha1_srmode                   : syncmem
       + hana_ha1_sync_state               : PRIM
       + hana_ha1_version                  : 1.00.122.27.1568902538
       + hana_ha1_vhost                    : hana-ha-vm-1
       + lpa_ha1_lpt                       : 1592338046
       + master-SAPHana_HA1_22             : 150
    * Node hana-ha-vm-2:
       + hana_ha1_clone_state              : DEMOTED
       + hana_ha1_op_mode                  : logreplay
       + hana_ha1_remoteHost               : hana-ha-vm-1
       + hana_ha1_roles                    : 4:S:master1:master:worker:master
       + hana_ha1_site                     : hana-ha-vm-2
       + hana_ha1_srmode                   : syncmem
       + hana_ha1_sync_state               : SOK
       + hana_ha1_version                  : 1.00.122.27.1568902538
       + hana_ha1_vhost                    : hana-ha-vm-2
       + lpa_ha1_lpt                       : 30
       + master-SAPHana_HA1_22             : 100

仮想 IP アドレス リソースを作成する

VIP のクラスタ リソースを作成する必要があります。VIP リソースはプライマリ オペレーティング システムにローカライズされ、他のホストからはルーティングできません。ロードバランサは、ヘルスチェックに基づいて VIP に送信されたトラフィックをバックエンド ホストにルーティングします。

いずれかのホストの root として:

# pcs resource create resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

vip-address 値は、以前に予約して、ロードバランサのフロントエンドの転送ルールで指定した IP アドレスと同じです。構成に応じて、ネットワーク インターフェースを変更します。

制約を作成する

最初に開始する必要があるサービスと、同じホストで一緒に実行する必要があるサービスを定義する制約を作成します。たとえば、IP アドレスはプライマリ HANA インスタンスと同じホスト上にある必要があります。

  1. 開始順序の制約を定義します。

    RHEL 8 以降

    # pcs constraint order topology_resource_name-clone \
    then sap_hana_resource_name-clone symmetrical=false

    RHEL 7

    # pcs constraint order topology_resource_name-clone \
    then sap_hana_resource_name-master symmetrical=false

    symmetrical=false を指定すると、制約は起動のみに適用され、シャットダウンには適用されません。

    ただし、前のステップで interleave=true をこれらのリソースに設定したため、プロセスは並行して開始できます。つまり、SAPHanaTopology が実行されるとすぐに、任意のノードで SAPHana を起動できます。

  2. 制約を確認します。

    # pcs constraint

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

    Location Constraints:
     Resource: STONITH-hana-ha-vm-1
       Disabled on:
         Node: hana-ha-vm-1 (score:-INFINITY)
     Resource: STONITH-hana-ha-vm-2
       Disabled on:
         Node: hana-ha-vm-2 (score:-INFINITY)
    Ordering Constraints:
     start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
    Ticket Constraints:

リスナーをインストールし、ヘルスチェック リソースを作成する

ヘルスチェック リソースを構成するには、まずリスナーをインストールする必要があります。

リスナーをインストールする

ロードバランサは、各ホストのヘルスチェック ポートでリスナーを使用して、SAP HANA クラスタのプライマリ インスタンスが実行されている場所を判断します。1. プライマリ システムとセカンダリ システムのマスター インスタンスの root として、TCP リスナーをインストールします。以下の手順では、HAProxy をインストールしてリスナーとして使用します。

# yum install haproxy

  1. 構成ファイル haproxy.cfg を編集用に開きます。

    # vi /etc/haproxy/haproxy.cfg
    1. haproxy.cfgデフォルト セクションで、modetcp に変更します。

    2. デフォルト セクションの後に、以下を追加して新しいセクションを作成します。

      #---------------------------------------------------------------------
      # 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
  2. 各ホストで root として、サービスを開始し、正しく構成されていることを確認します。

    # systemctl start haproxy.service
  3. Google Cloud コンソールの [ロードバランサ] ページで、ロードバランサのエントリをクリックします。

    [ロード バランシング] ページ

    [ロードバランサの詳細] ページの [バックエンド] セクションで、両方のホストで HAProxy サービスがアクティブな場合、各インスタンス グループ エントリの [正常] の列に 1/1 が表示されます。

    画面キャプチャは、両方のインスタンス グループの [正常] の列に「1/1」が表示され、両方とも正常であることを示しています。

  4. 各ホストで、HAProxy サービスを停止します。

    # systemctl stop haproxy.service

    各ホストで HAProxy サービスを停止すると、各インスタンス グループの [正常] の列に 0/1 が表示されます。

    画面キャプチャは、各インスタンス グループの [正常] の列に「0/1」が表示され、アクティブなリスナーがないことが示しています。

    後でヘルスチェックが構成されると、クラスタはマスターノードのリスナーを再起動します。

ヘルスチェック リソースを作成する

  1. HAProxy サービスのヘルスチェック リソースを、いずれかのホスト上で root として作成します。

    # pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s
  2. ヘルスチェック サービスがマスター SAP HANA インスタンスおよび VIP リソースと同じホスト上でアクティブであることを確認します。

    # pcs status

    ヘルスチェック リソースがプライマリ ホスト上にない場合は、次のコマンドを使用して移動します。

    # pcs resource move healthcheck_resource_name target_host_name
    # pcs resource clear healthcheck_resource_name

    コマンド pcs resource clear は、リソースを新しいロケーションに残し、pcs resource move コマンドによって作成された不要なロケーション制約を削除します。

    ステータスのリソース セクションは次の例のようになります。

    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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
    rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2
  3. VIP とヘルスチェックのリソースをグループ化します。

    # pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_name

    クラスタ ステータスのリソース セクションは、次の例のようになります。

    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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    Resource Group: g-primary
        rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
        rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
  4. マスター SAP HANA インスタンスと同じノードに新しいグループを配置する制約を作成します。

    RHEL 8 以降

    # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-clone 4000

    RHEL 7

    # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000

    最終的な制約は、次の例のようになります。

    # pcs constraint
    Location Constraints:
     Resource: STONITH-hana-ha-vm-1
       Disabled on:
         Node: hana-ha-vm-1 (score:-INFINITY)
     Resource: STONITH-hana-ha-vm-2
       Disabled on:
         Node: hana-ha-vm-2 (score:-INFINITY)
    Ordering Constraints:
     start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
     g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
    Ticket Constraints:

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

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

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

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

  • 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 に基づいて受信トラフィックと送信トラフィックをドロップし、プライマリへのネットワーク接続の損失をシミュレートします。

  1. アクティブ ホストで、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
  2. SSH を使用していずれかのホストに再接続し、root ユーザーに変更します。

  3. 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 ]
    
    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
    
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2  ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-2 ]
        Slaves: [ hana-ha-vm-1  ]
    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

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

SAP HANA 2.0 SPS1 以降では、Pacemaker クラスタで HANA アクティブ / アクティブ(読み取り可能)を構成できます。これは省略可能です。

Pacemaker クラスタで HANA アクティブ / アクティブ(読み取り可能)を構成するには、次の手順を完了します。

セカンダリ ホストの Cloud Load Balancing のフェイルオーバー サポートを構成する

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

セカンダリ ホストのフェイルオーバー サポートを構成するには、次の操作を行います。

  1. Cloud Shell を開きます。

    Cloud Shell に移動

  2. 次のコマンドを実行して、仮想 IP の IP アドレスを予約します。

    仮想 IP(VIP)アドレスはセカンダリ SAP HANA システムに従います。これは、アプリケーションがセカンダリ SAP HANA システムへのアクセスに使用する IP アドレスです。ロードバランサは、VIP に送信されるトラフィックを、現在セカンダリ システムをホストしている VM インスタンスに転送します。

    次のコマンドで --addresses フラグを省略すると、指定したサブネット内の IP アドレスが自動的に選択されます。静的 IP の予約の詳細については、静的内部 IP アドレスの予約をご覧ください。

    $ gcloud compute addresses create secondary-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses secondary-vip-address
  3. 次のコマンドを実行して、Compute Engine ヘルスチェックを作成します。

    ヘルスチェックで使用するポートには、他のサービスと競合しないように、プライベート範囲である 49152~65535 のポート番号を選択します。ポートは、HANA プライマリ システム アクセスのヘルスチェック用に構成されたポートとは異なるものにする必要があります。チェック間隔(check-interval)とタイムアウト(timeout)の値は、Compute Engine のライブ マイグレーション イベント時におけるフェイルオーバーの許容範囲を広げるために、デフォルトよりも少し長くなっています。必要に応じて値を調整できます。

    $ gcloud compute health-checks create tcp secondary-health-check-name \
      --port=secondary-healthcheck-port-num \
      --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
      --healthy-threshold=2
  4. 次のコマンドを実行して、ロードバランサとフェイルオーバー グループを構成します。

    ここでは、追加のバックエンド サービスを作成し、SAP HANA プライマリ システムの内部 TCP / UDP ロードバランサの背後にあるバックエンド サービス用に事前に作成したインスタンス グループを使用します。

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

      $ gcloud compute backend-services create secondary-backend-service-name \
        --load-balancing-scheme internal \
        --health-checks secondary-health-check-name \
        --no-connection-drain-on-failover \
        --drop-traffic-if-unhealthy \
        --failover-ratio 1.0 \
        --region cluster-region \
        --global-health-checks
    2. プライマリ インスタンス グループをバックエンド サービスに追加します。

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-zone \
        --region cluster-region
    3. セカンダリのフェイルオーバー インスタンス グループをバックエンド サービスに追加します。

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-zone \
        --failover \
        --region cluster-region
    4. 転送ルールを作成します。

      IP アドレスフラグには、VIP 用に予約した IP アドレスを指定します。次のコマンドで指定したリージョンの外部から HANA セカンダリ システムにアクセスする必要がある場合は、転送ルールの定義に --allow-global-access フラグを含めます。

      $ gcloud compute forwarding-rules create secondary-rule-name \
        --load-balancing-scheme internal \
        --address secondary-vip-name \
        --subnet cluster-subnet \
        --region cluster-region \
        --backend-service secondary-backend-service-name \
        --ports ALL

      SAP HANA 高可用性システムへのリージョン間アクセスの詳細については、内部 TCP / UDP ロード バランシングをご覧ください。

HANA アクティブ / アクティブ(読み取り可能)を有効にする

セカンダリ ホストで、次の手順に沿って、SAP HANA システム レプリケーションのアクティブ / アクティブ(読み取り可能)を有効にします。

  1. root として、クラスタをメンテナンス モードにします。

    $ pcs property set maintenance-mode=true

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

    > HDB stop
  3. SID_LCadm として、オペレーション モード logreplay_readaccess を使用して HANA セカンダリ システムを SAP HANA システム レプリケーションに再登録します。

    > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
     --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-name
  4. SID_LCadm として SAP HANA を起動します。

    > HDB start
  5. SID_LCadm として、HANA の同期ステータスが ACTIVE であることを確認します。

    > cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_status

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

    overall_replication_status=ACTIVE

Pacemaker を構成する

次のコマンドを root として実行し、Pacemaker HA クラスタをアクティブ / アクティブ(読み取り可能)で構成します。

  1. ヘルスチェック用のリスナーを設定します。

    1. デフォルトの haproxy.service 構成ファイルをコピーして名前を変更し、複数の haproxy インスタンスのテンプレート ファイルとして使用します。

      # cp /usr/lib/systemd/system/haproxy.service \
           /etc/systemd/system/haproxy@.service
    2. 次の例に示すように、haproxy@.service ファイルの [Unit] と [Service] セクションを編集し、%i インスタンス パラメータを含めます。

      RHEL 7

      [Unit]
      Description=HAProxy Load Balancer %i
      After=network-online.target

      [Service] EnvironmentFile=/etc/sysconfig/haproxy ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-%i.cfg -p /run/haproxy-%i.pid $OPTIONS ...

      RHEL 8

      [Unit]
      Description=HAProxy Load Balancer %i
      After=network-online.target
      Wants=network-online.target

      [Service] Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid" ...

      Red Hat の systemd ユニット テンプレートの詳細については、インスタンス化されたユニットの操作をご覧ください。

    3. SAP HANA プライマリ システムの haproxy.cfg 構成ファイルを作成します。次に例を示します。

      # vi /etc/haproxy/haproxy-primary.cfg
    4. SAP HANA プライマリ システムの haproxy-primary.cfg 構成ファイルに次の構成を挿入します。healthcheck-port-num は、HANA プライマリ システムの Compute Engine のヘルスチェックを作成したときに指定したポート番号に置き換えます。

      global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
      defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
      
      # Listener for SAP healthcheck
      listen healthcheck
        bind *:healthcheck-port-num
    5. SAP HANA セカンダリ システム用の haproxy.cfg 構成ファイルを作成します。次に例を示します。

      # vi /etc/haproxy/haproxy-secondary.cfg
    6. SAP HANA セカンダリ システムの haproxy-secondary.cfg 構成ファイルに次の構成を挿入します。secondary-healthcheck-port-num は、HANA セカンダリ システムの Compute Engine ヘルスチェックを作成したときに指定したポート番号に置き換えます。

      global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
      defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
      
      # Listener for SAP healthcheck
      listen healthcheck
        bind *:secondary-healthcheck-port-num
    7. /etc/haproxy/haproxy.cfg から既存のリスナー構成を削除します。

      #---------------------------------------------------------------------
      # Health check listener port for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
        bind *:healthcheck-port-num
    8. systemd サービスを再読み込みして、変更を読み込みます。

      # systemctl daemon-reload
    9. 2 つの haproxy サービスが正しく設定されていることを確認します。

      # systemctl start haproxy@primary
      # systemctl start haproxy@secondary
      
      # systemctl status haproxy@primary
      # systemctl status haproxy@secondary

      返されたステータスで、haproxy@primary.servicehaproxy@secondary.serviceactive (running) として表示されます。haproxy@primary.service の出力例を次に示します。

      ● haproxy@primary.service - Cluster Controlled haproxy@primary
        Loaded: loaded (/etc/systemd/system/haproxy@.service; disabled; vendor preset: disabled)
        Drop-In: /run/systemd/system/haproxy@primary.service.d
                 └─50-pacemaker.conf
        Active: active (running) since Fri 2022-10-07 23:36:09 UTC; 1h 13min ago
      Main PID: 21064 (haproxy-systemd)
        CGroup: /system.slice/system-haproxy.slice/haproxy@primary.service
                ├─21064 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-primary.cfg -p /run/hapro...
                ├─21066 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
                └─21067 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
      
      Oct 07 23:36:09 hana-ha-vm-1 systemd[1]: Started Cluster Controlled haproxy@primary.
    10. Cloud Shell で、ヘルスチェックがリスナーを検出するまで数秒待ってから、プライマリ バックエンド サービスとセカンダリ バックエンド サービスの両方でバックエンド インスタンス グループのヘルスチェックを行います。

      $ gcloud compute backend-services get-health backend-service-name \
        --region cluster-region
      $ gcloud compute backend-services get-health secondary-backend-service-name \
        --region cluster-region

      次のような出力が表示されるはずです。ここでは、現在作業している VM と healthStateHEALTHY になっていることを確認できます。

      ---
      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
      
    11. Pacemaker でサービスを管理できるようにするには、両方のサービスを停止します。

      # systemctl stop haproxy@primary
      # systemctl stop haproxy@secondary
    12. クラスタ内の各ホストで上記の手順を繰り返します。

  2. セカンダリ システム用に予約した VIP アドレスのローカル クラスタ IP リソースを作成します。

    # pcs resource create secondary_vip_resource_name \
      IPaddr2 ip="secondary-vip-address" nic=eth0 cidr_netmask=32 \
      op monitor interval=3600s timeout=60s
  3. 次のコマンドを実行して、ヘルパー ヘルスチェック サービスを設定します。

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

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

      1. HANA プライマリ システムのヘルスチェック サービスのリソースを削除します。

        # pcs resource delete healthcheck_resource_name --force
      2. HANA プライマリ システムのヘルスチェック サービス用に新しいリソースを追加します。

        # pcs resource create primary_healthcheck_resource_name \
         service:haproxy@primary op monitor interval=10s timeout=20s
      3. HANA セカンダリ システムのヘルスチェック サービス用に新しいリソースを追加します。

        # pcs resource create secondary_healthcheck_resource_name \
         service:haproxy@secondary op monitor interval=10s timeout=20s
    2. VIP とヘルパー ヘルスチェック サービスのリソースをグループ化します。

      1. プライマリ VIP リソースの既存のリソース グループに新しいヘルスチェック リソースを追加します。

        # pcs resource group add rsc-group-name primary_healthcheck_resource_name \
         --before vip_resource_name
      2. 新しいリソース グループを追加して、HANA セカンダリ システムの VIP とヘルパー ヘルスチェックのサービス リソースをグループ化します。

        # pcs resource group add secondary-rsc-group-name \
         secondary_healthcheck_resource_name secondary_vip_resource_name
  4. 次のコマンドを実行して、2 つのロケーションの制約を作成します。

    こうした制約によって、セカンダリ VIP リソース グループが正しいクラスタノードに配置されます。

    # pcs constraint location secondary-rsc-group-name rule score=INFINITY \
      hana_sid_sync_state eq SOK and hana_sid_roles eq 4:S:master1:master:worker:master
    # pcs constraint location secondary-rsc-group-name rule score=2000 \
      hana_sid_sync_state eq PRIM and hana_sid_roles eq 4:P:master1:master:worker:master
  5. クラスタのメンテナンス モードを終了します。

    # pcs property set maintenance-mode=false
  6. クラスタのステータスを確認します。

    # pcs status

    次の例は、アクティブ / アクティブ(読み取り可能)の SAP HANA システム レプリケーションに適切に構成されたアクティブ クラスタのステータスを示しています。セカンダリ システムの VIP リソース用に追加されたリソース グループが表示されます。次の例で、リソース グループの名前は g-secondary です。

    Cluster name: hacluster
      Stack: corosync
      Current DC: hana-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
      Last updated: Sat Oct  8 00:37:08 2022
      Last change: Sat Oct  8 00:36:57 2022 by root via crm_attribute on hana-test-2
    
      2 nodes configured
      10 resource instances configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    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
      Resource Group: g-primary
        rsc_healthcheck_HA1-primary        (service:haproxy@primary):      Started hana-ha-vm-1
        rsc_vip_HA1_00     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
      Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
      Master/Slave Set: SAPHana_HA1_00-master [SAPHana_HA1_00]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
      Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
      Resource Group: g-secondary
        rsc_healthcheck_HA1-secondary        (service:haproxy@secondary):      Started hana-ha-vm-2
        rsc_vip_HA1_00-secondary     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
    

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 を使用して評価を作成および実行する方法については、評価を作成して実行するをご覧ください。

トラブルシューティング

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 に関する最小限のサポート要件について詳しくは、以下をご覧ください。

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 データベースにアクセスします。

デプロイ後のタスク

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

  1. SAP HANA システム管理者とデータベースのスーパーユーザーの仮のパスワードを変更します。次に例を示します。

    sudo passwd SID_LCadm

    パスワードの変更に関する SAP の情報については、システム データベースの SYSTEM ユーザー パスワードを再設定するをご覧ください。

  2. SAP HANA インスタンスを使用する前に、新しい SAP HANA データベースを構成してバックアップします。

  3. SAP HANA システムが VirtIO ネットワーク インターフェースにデプロイされている場合は、TCP パラメータ /proc/sys/net/ipv4/tcp_limit_output_bytes の値を 1048576 に設定することをおすすめします。この変更により、ネットワーク レイテンシに影響を与えることなく、VirtIO ネットワーク インターフェースの全体的なネットワーク スループットを改善できます。

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

次のステップ

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