Terraform: SAP NetWeaver の HA クラスタ構成ガイド(RHEL)

このガイドでは、SAP NetWeaver 用にパフォーマンスが最適化された Red Hat Enterprise Linux(RHEL)高可用性(HA)クラスタのデプロイを自動化する方法について説明します。

このガイドでは、Terraform を使用して、2 台の Compute Engine 仮想マシン(VM)、内部パススルー ネットワーク ロードバランサが実装された仮想 IP アドレス(VIP)、OS ベースの HA クラスタをデプロイします。これらはすべて、Google Cloud、SAP、OS ベンダーのベスト プラクティスに従います。

高可用性に固有ではない SAP NetWeaver 用の Compute Engine VM をデプロイする方法については、ご使用のオペレーティング システムに固有の SAP NetWeaver デプロイガイドをご覧ください。

SUSE Linux Enterprise Server(SLES)で SAP NetWeaver の HA クラスタを構成するには、SLES での SAP NetWeaver HA クラスタの手動構成ガイドをご覧ください。

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

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

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

単一ノード SAP NetWeaver システム用の高可用性 Linux クラスタの概要

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

  • 2 つのホスト VM。1 つは、アクティブな ASCS インスタンス用、もう一つは ENSA2 Enqueue Replicator または ENSA1 Enqueue Replication Server(ENSA1)用のアクティブ インスタンス用。ENSA2 インスタンスと ENSA1 インスタンスは、両方とも ERS と呼ばれます。
  • Pacemaker 高可用性クラスタ リソース マネージャー。
  • STONITH フェンシング メカニズム。
  • 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動。

前提条件

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

Google Cloud 環境で必要とされる場合を除き、このガイドの情報は Red Hat および SAP の以下の関連ガイドと同じです。

ネットワークの作成

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

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

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

プロジェクトの VPC ネットワークを作成するには、次の手順を行います。

  1. カスタムモードのネットワークを作成します。詳細については、カスタムモード ネットワークの作成をご覧ください。

  2. サブネットワークを作成し、リージョンと IP 範囲を指定します。詳細については、サブネットの追加をご覧ください。

NAT ゲートウェイの設定

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

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

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

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

デフォルトでは、Google Cloud ネットワークの外部からの受信接続はブロックされています。受信側の接続を許可するには、VM にファイアウォール ルールを設定します。ファイアウォール ルールは、VM への新しい受信接続のみを規制します。VM との接続が確立された後、トラフィックはその接続の両方向で許可されます。

指定したポートへのアクセスや、同じサブネットワーク上の VM 間のアクセスを許可するファイアウォール ルールを作成できます。

次のようなアクセスを許可するためのファイアウォール ルールを作成します。

  • TCP/IP Ports of All SAP Products に記述されている SAP NetWeaver によって使用されるデフォルトのポート。
  • 自分のパソコンまたは企業のネットワーク環境から Compute Engine VM インスタンスへの接続。使用すべき IP アドレスがわからない場合は、会社のネットワーク管理者に相談してください。
  • 3 層構成、スケールアウト構成、または高可用性構成の VM 間の通信。たとえば、3 層システムをデプロイしている場合、サブネットワークに少なくとも 2 つの VM(SAP NetWeaver 用の VM とデータベース サーバー用の VM)が存在することになります。2 つの VM 間の通信を有効にするには、サブネットワークから発信されるトラフィックを許可するファイアウォール ルールを作成する必要があります。
  • Cloud Load Balancing ヘルスチェック。

プロジェクトのファイアウォール ルールを作成するには、ファイアウォール ルールの作成をご覧ください。

SAP NetWeaver の高可用性 Linux クラスタを作成する

次の手順では、Terraform 構成ファイルを使用して、2 つの Compute Engine VM のある SAP NetWeaver 用 RHEL 高可用性クラスタを作成します。Compute Engine VM は、SAP セントラル サービスとエンキュー レプリケーション用に、自動フェイルオーバー構成で 2 つのターゲット ゾーンに作成されます。

Terraform 構成ファイルで SAP NetWeaver 高可用性クラスタの構成オプションを定義します。

  1. Cloud Shell を開きます。

    Cloud Shell に移動

  2. SAP NetWeaver 高可用性クラスタの sap_nw_ha.tf 構成ファイルを作業ディレクトリにダウンロードします。

    $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/terraform/sap_nw_ha.tf
  3. sap_nw_ha.tf ファイルを Cloud Shell コードエディタで開きます。

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

  4. sap_nw_ha.tf ファイルで、二重引用符で囲まれた内容をご使用のインストール環境の値に置き換えて、引数値を更新します。引数については、次の表をご覧ください。

    引数 データ型 説明
    source 文字列

    デプロイ時に使用する Terraform モジュールの場所とバージョンを指定します。

    sap_nw_ha.tf 構成ファイルには、source 引数の 2 つのインスタンスがあります。1 つは有効で、もう 1 つはコメントとして追加されています。デフォルトで有効な source 引数に、モジュール バージョンとして latest を指定します。デフォルトでは、source 引数の 2 番目のインスタンスの先頭に # 文字があり、引数が無効になっています。この引数には、モジュール バージョンを識別するタイムスタンプを指定します。

    すべてのデプロイで同じモジュール バージョンを使用する必要がある場合は、バージョン タイムスタンプを指定する source 引数の先頭から # 文字を削除し、latest を指定する source 引数の先頭にコメント文字を追加します。

    project_id 文字列 このシステムをデプロイする Google Cloud プロジェクトの ID を指定します。例: my-project-x
    machine_type 文字列 SAP システムの実行に必要な Compute Engine 仮想マシン(VM)のタイプを指定します。カスタム VM タイプが必要な場合は、必要な数に最も近く、かつ必要数以上の vCPU 数を持つ事前定義された VM タイプを指定します。デプロイが完了したら、vCPU 数とメモリ量を変更してください。

    たとえば、n1-highmem-32 のようにします。

    network 文字列 VIP を管理するロードバランサを作成するネットワークの名前を指定します。

    共有 VPC ネットワークを使用している場合は、ホスト プロジェクトの ID をネットワーク名の親ディレクトリとして追加する必要があります。例: HOST_PROJECT_ID/NETWORK_NAME

    subnetwork 文字列 前の手順で作成したサブネットワークの名前を指定します。共有 VPC にデプロイする場合は、この値を SHARED_VPC_PROJECT_ID/SUBNETWORK として指定します。例: myproject/network1
    linux_image 文字列 SAP システムをデプロイする Linux オペレーティング システム イメージの名前を指定します。たとえば、rhel-9-2-sap-ha のようにします。使用可能なオペレーティング システム イメージのリストについては、Google Cloud コンソールの [イメージ] ページをご覧ください。
    linux_image_project 文字列 引数 linux_image に指定するイメージを含む Google Cloud プロジェクトを指定します。このプロジェクトは独自のプロジェクトか、Google Cloud イメージ プロジェクトです。Compute Engine イメージの場合は、rhel-sap-cloud を指定します。ご利用のオペレーティング システムのイメージ プロジェクトを確認するには、オペレーティング システムの詳細をご覧ください。
    sap_primary_instance 文字列 プライマリ SAP NetWeaver システムの VM インスタンスの名前を指定します。これは、最初の ASCS の場所です。名前には、英小文字、数字、ハイフンを使用できます。13 文字以下で指定してください。
    sap_primary_zone 文字列 プライマリ SAP NetWeaver システムがデプロイされているゾーンを指定します。プライマリ ゾーンとセカンダリ ゾーンは同じリージョンにする必要があります。例: us-east1-b
    sap_secondary_instance 文字列 セカンダリ SAP NetWeaver システムの VM インスタンスの名前を指定します。これは最初の ERS の場所です。名前には、英小文字、数字、ハイフンを使用できます。13 文字以下で指定してください。
    sap_secondary_zone 文字列 セカンダリ SAP NetWeaver システムがデプロイされているゾーンを指定します。プライマリ ゾーンとセカンダリ ゾーンは同じリージョンにする必要があります。例: us-east1-c
    nfs_path 文字列 共有ファイル システムの NFS マウント ポイントを指定します。例: 10.163.58.114:/ssd_nfs
    sap_sid 文字列 SAP システム ID を指定します。ID は英数字 3 文字で、最初の文字はアルファベットにする必要があります。文字は大文字のみ使用できます。例: ED1
    hc_firewall_rule_name 文字列 省略可。ヘルスチェック ファイアウォール ルールの名前を指定します。デフォルト値は SAP_SID-hc-allow です。
    hc_network_tag 文字列 省略可。ヘルスチェック ファイアウォール ルールで VM インスタンスに関連付けるネットワーク タグを、カンマ区切りで 1 つ以上指定します。デフォルト値は SAP_SID-hc-allow-tag です。
    scs_inst_group_name 文字列 省略可。ASCS インスタンス グループの名前を指定します。デフォルト値は SAP_SID-scs-ig です。
    scs_hc_name 文字列 省略可。ASCS ヘルスチェックの名前を指定します。デフォルト値は SAP_SID-scs-hc です。
    scs_hc_port 文字列 省略可。ASCS ヘルスチェックのポートを指定します。他のサービスと競合しないように、ASCS ヘルスチェックのポート番号をプライベート範囲 49152~65535 に指定します。デフォルト値は 60000 です。
    scs_vip_address 文字列 省略可。以前に subnetwork で指定したサブネットワーク内の未使用の IP アドレスを指定して、ASCS インスタンスの仮想 IP アドレスとして使用します。何も指定しないと、デプロイ スクリプトは、指定されたサブネットワークから未使用の IP アドレスを自動的に選択します。
    scs_vip_name 文字列 省略可。ASCS 仮想 IP の名前を指定します。デフォルト値は SAP_SID-scs-vip です。
    scs_backend_svc_name 文字列 省略可。ASCS バックエンド サービスの名前を指定します。デフォルト値は SAP_SID-scs-backend-svc です。
    scs_forw_rule_name 文字列 省略可。ASCS 転送ルールの名前を指定します。デフォルト値は SAP_SID-scs-fwd-rule です。
    ers_inst_group_name 文字列 省略可。ERS インスタンス グループの名前を指定します。デフォルト値は SAP_SID-ers-ig です。
    ers_hc_name 文字列 省略可。ERS ヘルスチェックの名前を指定します。デフォルト値は SAP_SID-ers-hc です。
    ers_hc_port 文字列 省略可。ERS ヘルスチェックのポートを指定します。他のサービスと競合しないように、プライベート範囲の ERS ヘルスチェックのポート番号 49152~65535 を指定します。デフォルト値は 60010 です。
    ers_vip_address 文字列 省略可。前に subnetwork で指定したサブネットワーク内の未使用の IP アドレスを指定して、ERS インスタンスの仮想 IP アドレスとして使用します。何も指定しないと、デプロイ スクリプトは、指定されたサブネットワークから未使用の IP アドレスを自動的に選択します。
    ers_vip_name 文字列 省略可。ERS 仮想 IP の名前を指定します。デフォルト値は SAP_SID-ers-vip です。
    ers_backend_svc_name 文字列 省略可。ERS バックエンド サービスの名前を指定します。デフォルト値は SAP_SID-ers-backend-svc です。
    ers_forw_rule_name 文字列 省略可。ERS 転送ルールの名前を指定します。デフォルト値は SAP_SID-ers-fwd-rule です。
    usr_sap_size 整数 省略可。/usr/sap ディスクのサイズを GB で指定します。 最小サイズは 8 GB です。デフォルト値は 8 です。
    sap_mnt_size 整数 省略可。/sapmnt ディスクのサイズを GB で指定します。 最小サイズは 8 GB です。デフォルト値は 8 です。
    swap_size 整数 省略可。スワップ ボリュームのサイズを GB で指定します。 最小サイズは 8 GB です。デフォルト値は 8 です。
    sap_scs_instance_number 文字列 省略可。ASCS インスタンス番号を指定します。sap_scs_instance_number は 2 桁の数字です。1 桁の番号を指定する必要がある場合は、番号の前に 0 を追加します。例: 07。デフォルト値は 00 です。
    sap_ers_instance_number 文字列 省略可。ERS インスタンス番号を指定します。sap_ers_instance_number は 2 桁の数字です。1 桁の番号を指定する必要がある場合は、番号の前に 0 を追加します。例: 07。デフォルト値は 10 です。
    sap_nw_abap ブール値 省略可。SAP NetWeaver の ABAP スタックと Java スタックのどちらをデプロイするかを指定します。SAP NetWeaver の Java スタックの場合は、false を指定します。デフォルト値は true です。
    pacemaker_cluster_name 文字列 省略可。Pacemaker クラスタの名前を指定します。デフォルト値は SAP_SID-cluster です。
    public_ip ブール値 省略可。VM インスタンスのエフェメラル パブリック IP アドレスを作成するには、public_iptrue に設定します。デフォルト値は false です。
    service_account 文字列 省略可。ホスト VM とホスト VM で実行されるプログラムで使用されるユーザー管理のサービス アカウントのメールアドレスを指定します。例: svc-acct-name@project-id.iam.gserviceaccount.com

    この引数に値を指定しない場合、または省略した場合、インストール スクリプトは、Compute Engine のデフォルトのサービス アカウントを使用します。詳細については、Google Cloud 上での SAP プログラム向け Identity and Access Management をご覧ください。

    network_tags 文字列 省略可。ファイアウォールまたはルーティングの目的で使用され、VM インスタンスに関連付けるネットワーク タグを 1 つ以上カンマ区切りで指定します。

    ILB コンポーネントのネットワーク タグは、VM のネットワーク タグに自動的に追加されます。

    public_ip = false の場合にネットワーク タグを指定しない場合は、インターネットへの別のアクセス手段を必ず指定してください。

    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 Broadwell
      • n1-highmem-64: Intel Broadwell
      • n1-highmem-96: Intel Skylake
      • m1-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 Broadwell
      • n1-highmem-64: Intel Broadwell
      • n1-highmem-96: Intel Skylake
      • m1-megamem-96: Intel Skylake
    • Google Cloud での使用が SAP に認定されている他のすべてのマシンタイプの最小 CPU プラットフォームは、SAP の最小 CPU 要件に準拠しています。
    can_ip_forward ブール値

    送信元 IP または宛先 IP が一致しないパケットの送受信を許可するかどうかを指定します。 許可すると、VM がルーターのように動作することが可能になります。 デフォルト値は true です。

    デプロイされた VM の仮想 IP を Google の内部ロードバランサのみを使用して 管理する場合は、値を false に設定します。内部ロードバランサは、高可用性テンプレートの一部として自動的にデプロイされます。

    以下は、SAP NetWeaver の高可用性クラスタを定義する完成した構成ファイルの例です。このクラスタは、内部パススルー ネットワーク ロードバランサを使用して VIP を管理します。

    Terraform は構成ファイルで定義されている Google Cloud リソースをデプロイします。その後、起動スクリプトが処理を引き継ぎ、オペレーティング システムと Linux HA クラスタの構成を行います。

    わかりやすくするために、この例では構成ファイルのコメントは省略しています。

       # ...
         module "sap_nw_ha" {
         source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/sap_nw_ha_module.zip"
       #
       # By default, this source file uses the latest release of the terraform module
       # for SAP on Google Cloud.  To fix your deployments to a specific release
       # of the module, comment out the source argument above and uncomment the source argument below.
       #
       # source = "https://storage.googleapis.com/cloudsapdeploy/terraform/202201240926/terraform/sap_nw_ha/sap_nw_ha_module.zip"
       #
       # ...
       #
       project_id = "example-project-123456"
       machine_type = "n2-highmem-32"
       network = "example-network"
       subnetwork = "example-subnet-us-central1"
       linux_image = "rhel-8-4-sap-ha"
       linux_image_project = "rhel-sap-cloud"
    
       sap_primary_instance = "nw-ha-vm-1"
       sap_primary_zone = "us-central1-a"
    
       sap_secondary_instance = "nw-ha-vm-2"
       sap_secondary_zone = "us-central1-c"
    
       nfs_path = "10.223.55.130:/pr1_nw"
    
       sap_sid = "PR1"
       # ...
    }
  5. 現在の作業ディレクトリを初期化し、Google Cloud 用の Terraform プロバイダのプラグインとモジュール ファイルをダウンロードするには、以下の操作を行います。

    terraform init

    terraform init コマンドで、他の Terraform コマンドの作業ディレクトリを準備します。

    作業ディレクトリのプロバイダ プラグインと構成ファイルを強制的に更新するには、--upgrade フラグを指定します。--upgrade フラグが省略されていて、作業ディレクトリに変更を加えていない場合、source URL で latest が指定されている場合でも、Terraform はローカル キャッシュに保存されたコピーを使用します。

    terraform init --upgrade 
  6. 必要に応じて、Terraform 実行プランを作成します。

    terraform plan

    terraform plan コマンドによって、現在の構成で必要な変更が表示されます。この手順をスキップすると、terraform apply コマンドは自動的に新しいプランを作成し、それを承認するように求めます。

  7. 実行計画を適用します。

    terraform apply

    アクションを承認するように求められたら、「yes」と入力します。

    terraform apply コマンドは、Google Cloud インフラストラクチャをセットアップした後、Terraform 構成ファイルで定義された引数に従って HA クラスタを構成するスクリプトに制御を渡します。

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

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

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

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

  • ログを調べる
  • VM の構成を確認する

ログを調べる

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

    Cloud Logging に移動

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

    ログ エクスプローラ

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

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

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

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

    以前のログビューア

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

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

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

      2. Cloud Shell を開く

        Cloud Shell に移動

      3. 作業ディレクトリに移動してデプロイを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。

        terraform destroy

        アクションの承認を求められたら、「yes」と入力します。

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

VM の構成を確認する

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

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

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

    nw-ha-vm-1:~ # df -h
    Filesystem                             Size  Used Avail Use% Mounted on
    ...
    /dev/mapper/vg_usrsap-vol              8.0G  242M  7.8G   3% /usr/sap
    /dev/mapper/vg_sapmnt-vol              8.0G   90M  7.9G   2% /sapmnt
    10.95.255.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
    10.95.255.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
    10.95.255.130:/pr1_nw/usrsapPR1ASCS00 1007G     0  956G   0% /usr/sap/PR1/ASCS00
    ...
      
    ファイル・ディレクトリが最初にアクセスされたときに共通の共有ファイル・ディレクトリをマウントするように、autofs がデプロイ時に自動的に構成されます。ASCSASCS_INSTANCE_NUMBER ディレクトリと ERSERS_INSTANCE_NUMBER ディレクトリのマウントは、クラスタ ソフトウェアによって管理されます。クラスタ ソフトウェアもデプロイ時に設定されます。

  4. pcs status コマンドを入力して、新しいクラスタのステータスを確認します。

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

    nw-ha-vm-1:~ # pcs status
    Cluster name: pr1-cluster
    Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
    * Last updated: Mon Aug 29 18:03:22 2022
    * Last change:  Mon Aug 29 17:58:21 2022 by root via cibadmin on nw-ha-vm-1
    * 2 nodes configured
    * 8 resource instances configured
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    Full List of Resources:
    * fence-PR1-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
    * fence-PR1-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
    * file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
    * file-system-PR1-ERS10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
    * health-check-PR1-ASCS00    (service:haproxy@PR1ASCS):     Started nw-ha-vm-1
    * health-check-PR1-ERS10    (service:haproxy@PR1ERS):     Started nw-ha-vm-2
    * vip-PR1-ASCS00    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-1
    * vip-PR1-ERS10    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-2
    Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

  5. socat ユーティリティを使用して、ASCS と ERS ロードバランサの設定をテストします。

    1. 各 VM インスタンスで、一時的に固有のホスト名を返す socat プロセスを開始します。

      socat TCP-LISTEN:80,bind=0.0.0.0,fork,reuseaddr,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\: text/plain; echo; echo $(hostname)" & 
    2. 各ノードで curl を使用して、次の IP アドレスとホスト名への到達を試行します。IP アドレスとホスト名は /etc/hosts で確認できます。

      • 127.0.0.1
      • localhost
      • ASCS_VIRTUAL_HOST_NAME
      • ASCS_IP_ADDRESS
      • ERS_VIRTUAL_HOST_NAME
      • ERS_IP_ADDRESS
      • SCS VIP 名(パラメータ scs_vip_name に指定)
      • SCS VIP IP アドレス(パラメータ scs_vip_address に指定)
      • ERS VIP 名(パラメータ ers_vip_name に指定)
      • ERS VIP IP アドレス(パラメータ ers_vip_address に指定)

    このようなテストの出力例を次に示します。

    example-nw1:~ # cat /etc/hosts
    ...
    10.128.1.182 example-nw1.c.myproject.internal example-nw1
    10.128.1.169 example-nw2.c.myproject.internal example-nw2
    10.128.1.46 pr1-scs-vip.c.myproject.internal pr1-scs-vip
    10.128.0.75 pr1-ers-vip.c.myproject.internal pr1-ers-vip
    example-nw1:~ # curl 127.0.0.1
    example-nw1
    example-nw1:~ # curl localhost
    example-nw1
    example-nw1:~ # curl example-nw1
    example-nw1
    example-nw1:~ # curl 10.128.1.182
    example-nw1
    example-nw1:~ # curl example-nw2
    example-nw2
    example-nw1:~ # curl 10.128.1.169
    example-nw2
    example-nw1:~ # curl pr1-scs-vip
    example-nw1
    example-nw1:~ # curl 10.128.1.46
    example-nw1
    example-nw1:~ # curl pr1-ers-vip
    example-nw2
    example-nw1:~ # curl 10.128.0.75
    example-nw2
  6. RHEL for SAP 9.0 以降を使用する場合は、パッケージ chkconfigcompat-openssl11 が VM インスタンスにインストールされていることを確認してください。

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

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

  1. エラーを解決します。

  2. Cloud Shell を開く

    Cloud Shell に移動

  3. Terraform 構成ファイルのあるディレクトリに移動します。

  4. デプロイを削除します。

    terraform destroy

    アクションの承認を求められたら、「yes」と入力します。

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

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

ASCS と ERS をインストールする

次のセクションでは、Google Cloud 上での SAP NetWeaver のインストールに固有の要件と推奨事項のみについて説明します。

インストール手順の詳細については、SAP NetWeaver のドキュメントをご覧ください。

インストールを準備する

クラスタ全体の整合性を確保し、インストールを簡素化するため、SAP NetWeaver ASCS と ERS コンポーネントをインストールする前に、ユーザー、グループ、権限を定義して、セカンダリ サーバーをスタンバイ モードにします。

  1. クラスタのメンテナンス モードを終了します。

    # sudo pcs property set maintenance-mode="false"

  2. 両方のサーバーで、root として次のコマンドを入力し、環境に適したユーザー ID とグループ ID を指定します。

    # groupadd -g GID_SAPINST sapinst
    # groupadd -g GID_SAPSYS sapsys
    # useradd -u UID_SIDADM SID_LCadm -g sapsys
    # usermod -a -G sapinst SID_LCadm
    # useradd -u UID_SAPADM sapadm -g sapinst
    
    # chown SID_LCadm:sapsys /usr/sap/SID/SYS
    # chown SID_LCadm:sapsys /sapmnt/SID -R
    # chown SID_LCadm:sapsys /usr/sap/trans -R
    # chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
    # chown SID_LCadm:sapsys /usr/sap/SID -R

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

    • GID_SAPINST: SAP プロビジョニング ツールの Linux グループ ID を指定します。
    • GID_SAPSYS: SAPSYS ユーザーの Linux グループ ID を指定します。
    • UID_SIDADM: SAP システム(SID)の管理者の Linux ユーザー ID を指定します。
    • SID_LC: システム ID(SID)を指定します。すべて小文字を使用します。
    • UID_SAPADM: SAP Host Agent のユーザー ID を指定します。
    • SID: システム ID(SID)を指定します。文字には大文字を使用します。

    実際の GID と UID の番号スキームの例を次に示します。

    Group sapinst      1001
    Group sapsys       1002
    Group dbhshm       1003
    
    User  en2adm       2001
    User  sapadm       2002
    User  dbhadm       2003

ASCS コンポーネントをインストールする

  1. セカンダリ サーバーで次のコマンドを入力して、セカンダリ サーバーをスタンバイ モードにします。

    # pcs node standby

    セカンダリ サーバーをスタンバイ モードにすると、すべてのクラスタ リソースがプライマリ サーバーに統合されるため、インストールが簡単になります。

  2. セカンダリ サーバーがスタンバイ モードになっていることを確認します。

    # pcs status

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

    Cluster name: nwha
       Cluster Summary:
         * Stack: corosync
         * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
         * 2 nodes configured
         * 8 resource instances configured
    
       Node List:
         * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
       Full List of Resources:
         * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
         * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
         * Resource Group: nw8_ascs00_group:
           * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
           * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
           * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
         * Resource Group: nw8_ers10_group:
           * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
           * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
           * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
    
       Daemon Status:
         corosync: active/enabled
    
  3. プライマリ サーバーで、root ユーザーとしてディレクトリを /tmp などの一時インストール ディレクトリに変更し、SAP Software Provisioning Manager(SWPM)を実行して ASCS インスタンスをインストールします。

    • SWPM のウェブ インターフェースにアクセスするには、root ユーザーのパスワードが必要です。SAP 管理者が root パスワードにアクセスすることが IT ポリシーで許可されていない場合、SAPINST_REMOTE_ACCESS_USER を使用できます。

    • SWPM を起動するときに、SAPINST_USE_HOSTNAME パラメータを使用して、/etc/hosts ファイルで ASCS VIP アドレス用に定義した仮想ホスト名を指定します。

      次に例を示します。

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
    • 最終的な SWPM 確認ページで、仮想ホスト名が正しいことを確認します。

  4. 構成が完了したら、セカンダリ VM をスタンバイ モードから解除します。

    # pcs node unstandby

ERS コンポーネントをインストールする

  1. プライマリ サーバーで、root または SID_LCadm として ASCS サービスを停止します。

    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"
  2. プライマリ サーバーで次のコマンドを入力して、プライマリ サーバーをスタンバイ モードにします。

    # pcs node standby

    プライマリ サーバーをスタンバイ モードにすると、すべてのクラスタ リソースがセカンダリ サーバーに統合されるため、インストールが簡単になります。

  3. プライマリ サーバーがスタンバイ モードになっていることを確認します。

    # pcs status

  4. セカンダリ サーバーで、root ユーザーとしてディレクトリを /tmp などの一時インストール ディレクトリに変更し、SAP Software Provisioning Manager(SWPM)を実行して ERS インスタンスをインストールします。

    • ASCS コンポーネントをインストールしたときに使用したのと同じユーザー名とパスワードを使用して SWPM にアクセスします。

    • SWPM を起動するときに、SAPINST_USE_HOSTNAME パラメータを使用して、/etc/hosts ファイルで ERS VIP アドレス用に定義した仮想ホスト名を指定します。

      次に例を示します。

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
    • 最終的な SWPM 確認ページで、仮想ホスト名が正しいことを確認します。

  5. プライマリ VM をスタンバイ状態から解除して、両方ともアクティブにします。

    # pcs node unstandby

SAP サービスを構成する

サービスが正しく構成されていることを確認する必要があります。ASCS プロファイルと ERS プロファイルで設定を確認し、SID_LCadm ユーザーを haclient ユーザー グループに追加します。

SAP サービスのエントリを確認する

  1. 両方のサーバーで、/usr/sap/sapservices ファイルに ASCS サービスと ERS サービスの両方のエントリが含まれていることを確認します。これを行うには、systemV または systemd インテグレーションを使用します。

    sapstartsrv コマンドを pf=PROFILE_OF_THE_SAP_INSTANCE オプションと -reg オプションで使用すると、不足しているエントリを追加できます。

    これらのインテグレーションの詳細については、次の SAP Note をご覧ください。

    systemV

    systemV のインテグレーションを使用している場合の /usr/sap/sapservices ファイル内の ASCS サービスと ERS サービスのエントリの例を次に示します。

    # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
    /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    -D -u SID_LCadm
    /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    -D -u SID_LCadm

    systemd

    1. /usr/sap/sapservices ファイルに ASCS サービスと ERS サービスのエントリが含まれていることを確認します。次の例は、systemd インテグレーションを使用している場合に、これらのエントリが /usr/sap/sapservices ファイルにどのように表示されるかを示しています。

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers
    2. ASCS インスタンスと ERS インスタンスで systemd インテグレーションを無効にします。

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service
      
    3. systemd インテグレーションが無効になっていることを確認します。

      # systemctl list-unit-files | grep sap

      次の例のような出力は、systemd インテグレーションが無効になっていることを意味します。なお、saphostagentsaptune などの一部のサービスが有効になり、無効のサービスもあります。

      SAPSID_ASCS_INSTANCE_NUMBER.service disabled
      SAPSID_ERS_INSTANCE_NUMBER.service disabled
      saphostagent.service enabled
      sapinit.service generated
      saprouter.service disabled
      saptune.service enabled

SAP サービスを停止する

  1. セカンダリ サーバーで、ERS サービスを停止します。

    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"
  2. 各サーバーで、すべてのサービスが停止していることを確認します。

    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"
    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"

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

    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

SAP でサービスの自動再起動を無効にする

フェイルオーバー時にクラスタ ソフトウェアが SAP サービスの再起動を管理するため、競合を回避するために、SAP ソフトウェアによるサービスの自動再起動機能を無効にします。

  1. 両方のノードで /usr/sap/sapservices ファイルを編集して、ASCS と ERS の両方のコンポーネントに対して sapstartsrv コマンドの先頭にコメント文字 # を追加し、SAP ソフトウェアでの自動再起動を無効にします。

    次に例を示します。

    #!/bin/sh
    
     #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm
     #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
     

ASCS プロファイルと ERS プロファイルを編集する

  1. いずれかのサーバーで、次のコマンドのどちらかを使用してプロファイル ディレクトリに切り替えます。

    # cd /usr/sap/SID/SYS/profile
    # cd /sapmnt/SID/profile
  2. 必要に応じて、プロファイル ディレクトリでファイルを一覧表示して、ASCS プロファイルと ERS プロファイルのファイル名を確認できます。また、次の形式を使用することもできます。

    SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
    SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
  3. ENSA1 を使用している場合は、ASCS プロファイルで次の設定を行い、キープアライブ機能を有効にします。

    enque/encni/set_so_keepalive = true

    詳細については、SAP Note 1410736 - TCP/IP: setting keepalive interval をご覧ください。

  4. 必要に応じて、ASCS プロファイルと ERS プロファイルを編集して、エンキュー サーバーとエンキュー レプリケーション サーバーの起動時の動作を変更します。

    ENSA1

    ASCS プロファイルの [Start SAP enqueue server] セクションで、Restart_Program_NN が表示されている場合は、次の例に示すように「Restart」を「Start」に変更します。

    Start_Program_01 = local $(_EN) pf=$(_PF)

    ERS プロファイルの [Start enqueue server] セクションで、Restart_Program_NN が表示されている場合は、次の例に示すように「Restart」を「Start」に変更します。

    Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

    ENSA2

    ASCS プロファイルの [Start SAP enqueue server] セクションで、Restart_Program_NN が表示されている場合は、次の例に示すように「Restart」を「Start」に変更します。

    Start_Program_01 = local $(_ENQ) pf=$(_PF)

    ERS プロファイルの [Start enqueue replicator] セクションで、Restart_Program_NN が表示されている場合は、次の例に示すように「Restart」を「Start」に変更します。

    Start_Program_00 = local $(_ENQR) pf=$(_PF) ...

ASCS と ERS のクラスタ リソースを構成する

  1. いずれかのサーバーからの root として、クラスタをメンテナンス モードにします。

    # pcs property set maintenance-mode="true"
  2. クラスタがメンテナンス モードになっていることを確認します。

    # pcs status
  3. ASCS サービスと ERS サービスのクラスタ リソースを作成します。

    ENSA1

    • ASCS インスタンスのクラスタ リソースを作成します。InstanceName の値は、ASCS をインストールしたときに SWPM によって生成されるインスタンス プロファイルの名前です。

      # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
          failure-timeout=60  --group ASCS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      
      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
      
    • ERS インスタンスのクラスタ リソースを作成します。InstanceName の値は、ERS をインストールしたときに SWPM によって生成されるインスタンス プロファイルの名前です。パラメータ IS_ERS=true は、ERS がアクティブなノードで runsersSID フラグを 1 に設定するよう Pacemaker に指示します。

      # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      

    ENSA2

    • ASCS インスタンスのクラスタ リソースを作成します。InstanceName の値は、ASCS をインストールしたときに SWPM によって生成されるインスタンス プロファイルの名前です。

      # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
          --group ASCS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      
      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
      
    • ERS インスタンスのクラスタ リソースを作成します。InstanceName の値は、ERS をインストールしたときに SWPM によって生成されるインスタンス プロファイルの名前です。

      # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      

ロケーションと順序の制約を構成する

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

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

ENSA1

  1. ASCS リソースが ERS リソースと同じサーバーで実行されないようにするコロケーション制約を作成します。

    # pcs constraint colocation add ERS_RESOURCE_GROUP with \
        ASCS_RESOURCE_GROUP -5000
    
  2. フラグ runsersSID1 と等しい場合に、ERS が実行されているサーバーにフェイルオーバーするように ASCS を構成します。

    # pcs constraint location ASCS_INSTANCE \
        rule score=2000 runs_ers_SID eq 1
  3. ERS がフェイルオーバー後に他方のサーバーに移行する前に ASCS が起動するように構成します。

    # pcs constraint order start ASCS_RESOURCE_GROUP then \
        stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
    

ENSA2

  1. ASCS リソースが ERS リソースと同じサーバーで実行されないようにするコロケーション制約を作成します。

    # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
        ASCS_RESOURCE_GROUP -5000
    
  2. ERS がフェイルオーバー後に他方のサーバーに移行する前に ASCS が起動するように構成します。

    # pcs constraint order start ASCS_RESOURCE_GROUP then \
        stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
    
  1. 制約を確認します。

    # pcs constraint

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

    Location Constraints:
      Resource: ascs-aha-instance
        Constraint: location-ascs-instance
          Rule: score=2000
            Expression: runs_ers_HKN eq 1
      Resource: fence-nw-ha-vm-1
        Disabled on: nw-ha-vm-1 (score:-INFINITY)
      Resource: fence-nw-ha-vm-2
        Disabled on: nw-ha-vm-2 (score:-INFINITY)
    Ordering Constraints:
      start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
    Colocation Constraints:
      ascs-group with ers-group (score:-5000)
    Ticket Constraints:
  2. いずれかのサーバーからルートとして、クラスタのメンテナンス モードを無効にします。

    # pcs property set maintenance-mode="false"

SAP 用の Red Hat クラスタ コネクタを構成する

クラスタ内の各ホストで、HA インターフェースを介して Pacemaker クラスタ ソフトウェアと通信するように SAP Start Service sapstartsrv を構成します。

  1. SAP 管理ユーザーを haclient グループに追加します。

    usermod -a -G haclient SID_LCadm
  2. 各プロファイルの末尾に次の行を追加して、SAP インスタンス プロファイルを編集します。プロファイルは /sapmnt/SID/profiles ディレクトリにあります。

    service/halib = $(DIR_CT_RUN)/saphascriptco.so
    service/halib_cluster_connector = /usr/bin/sap_cluster_connector
  3. ASCS インスタンス リソースと ERS インスタンス リソースが現在クラスタで実行されている場合は、無効にします。

    pcs resource disable ERS_INSTANCE_RESOURCE
    pcs resource disable ASCS_INSTANCE_RESOURCE
  4. ASCS ホストでサービスを停止します。

    sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService
  5. ERS ホストでサービスを停止します。

    sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService
  6. リソースを有効にします。

    pcs resource enable ERS_INSTANCE_RESOURCE
    pcs resource enable ASCS_INSTANCE_RESOURCE
  7. クラスタ内の各ホストで上記の手順を繰り返します。

Red Hat からの詳細情報については、RHEL 7 および 8 の SAPInstance リソースに SAP halib を構成する方法をご覧ください。

データベース サーバーとアプリケーション サーバーをクラスタ外部のホストにインストールする

高可用性構成では、クラスタ内の ASCS ホストおよび ERS ホストとは異なるホストに、データベース サーバーとアプリケーション サーバーをインストールすることをおすすめします。

サーバーごとに別々のホストを使用することで、複雑さを軽減し、複数のサーバーに影響を与える障害のリスクを軽減できます。また、各 Compute Engine のサイズをサーバーの種類ごとに調整できます。

これにより、認定された最適なマシンサイズを選択し、障害を回避して複雑さを軽減できます。

データベースとアプリケーション サーバーのインストールについては、このガイドでは説明しません。

データベース サーバーのインストールについては、以下をご覧ください。

クラスタの検証とテスト

このセクションでは、次のテストを実行する方法について説明します。

  • 構成エラーを確認する
  • フェイルオーバー中に ASCS リソースと ERS リソースでサーバーを正しく切り替えることを確認する
  • ロックが保持されていることを確認する
  • Compute Engine のメンテナンス イベントをシミュレートして、ライブ マイグレーションによってフェイルオーバーがトリガーされないようにする。

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

  1. いずれかのサーバーの root として、リソースが実行されているノードを確認します。

    # pcs status

    次の例では、ASCS リソースは nw-ha-vm-2 サーバーで実行され、ERS リソースは nw-ha-vm-1 サーバーで実行されます。

    Stack: corosync
      Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
      Last updated: Wed Apr 13 05:21:21 2022
      Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
    
      2 nodes configured
      10 resource instances configured
    
      Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
      Full list of resources:
    
      fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
      fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
       Resource Group: ascs-group
           ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
           ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
           ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
           ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
       Resource Group: ers-group
           ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
           ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
           ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
           ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
    
      Migration Summary:
      * Node nw-ha-vm-1:
      * Node nw-ha-vm-2:
  2. SID_LCadm ユーザーに切り替えます。

    # su - SID_LCadm
  3. クラスタの構成を確認します。INSTANCE_NUMBER には、コマンドを入力するサーバーでアクティブな ASCS インスタンスまたは ERS インスタンスのインスタンス番号を指定します。

    > sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

    次の例に示すように、HAActiveTRUE にする必要があります。

    HAGetFailoverConfig
    
    14.04.2022 17:25:45
    HAGetFailoverConfig
    OK
    HAActive: TRUE
    HAProductVersion: Pacemaker
    HASAPInterfaceVersion: sap_cluster_connector
    HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector
    HAActiveNode:
    HANodes:

  4. SID_LCadm として、構成のエラーを確認します。

    > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

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

    14.04.2022 21:43:39
    HACheckConfig
    OK
    state, category, description, comment
    SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
    SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
    SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
    SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
    SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
    SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

  5. ASCS がアクティブなサーバーで、SID_LCadm としてフェイルオーバーをシミュレートします。

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""
  6. root として、crm_mon を使用してフェイルオーバーを行うと、ASCS はもう一方のサーバーに移動し、ERS はそのサーバー上で停止した後、ASCS が実行されていたサーバーに移動することが表示されます。

フェイルオーバーをシミュレートする

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

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

  • shutdown -r(アクティブ ノード)
  • ip link set eth0 down
  • echo c > /proc/sysrq-trigger

以下の手順では、ip link set eth0 down を使用してネットワーク インターフェースをオフラインにします。これは、フェイルオーバーとフェンシングの両方を検証するためです。

  1. システムをバックアップします。

  2. アクティブな SCS インスタンスを持つホストの root として、ネットワーク インターフェースをオフラインにします。

    $ ip link set eth0 down
  3. SSH を使用していずれかのホストに再接続し、root ユーザーに変更します。

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

     Stack: corosync
      Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
      Last updated: Wed Apr 13 05:21:21 2022
      Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
    
      2 nodes configured
      10 resource instances configured
    
      Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
      Full list of resources:
    
      fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
      fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
       Resource Group: ascs-group
           ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
           ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
           ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
           ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
       Resource Group: ers-group
           ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
           ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
           ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
           ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
    
      Migration Summary:
      * Node nw-ha-vm-1:
      * Node nw-ha-vm-2:

ロックのエントリが保持されていることを確認する

フェイルオーバー全体にロックエントリが保持されていることを確認するには、まず、エンキュー サーバーのバージョンのタブを選択します。手順に沿ってロックエントリを生成し、フェイルオーバーをシミュレートして、ASCS を有効化された後にロックエントリが保持されることを確認します。

ENSA1

  1. SID_LCadm として、ERS がアクティブなサーバーで、enqt プログラムを使用してロックエントリを生成します。

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS
  2. SID_LCadm として、ASCS がアクティブなサーバーで、ロックエントリが登録されていることを確認します。

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    10 個のロックを作成した場合、次の例のような出力が表示されます。

    locks_now: 10
  3. SID_LCadm として、ERS がアクティブなサーバーで、enqt プログラムのモニタリング機能 OpCode=20 を起動します。

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999

    次に例を示します。

    > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999
  4. ASCS がアクティブな場合は、サーバーを再起動します。

    モニタリング サーバーで Pacemaker が ERS を停止してもう一方のサーバーに移動するまで、次のような出力が表示されます。

    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
  5. enqt モニターが停止したら、「Ctrl + c」と入力してモニターを終了します。

  6. 必要に応じて、いずれかのサーバーの root として、クラスタ フェイルオーバーをモニタリングします。

    # crm_mon
  7. SID_LCadm として、ロックが保持されていることを確認したら、ロックを解除します。

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS
  8. SID_LCadm として、ASCS がアクティブなサーバーで、ロックエントリが削除されていることを確認します。

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

  1. SID_LCadm として、ASCS がアクティブなサーバーで、enq_adm プログラムを使用してロックエントリを生成します。

    > enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
  2. SID_LCadm として、ASCS がアクティブなサーバーで、ロックエントリが登録されていることを確認します。

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    10 個のロックを作成した場合、次の例のような出力が表示されます。

    locks_now: 10
  3. ERS がアクティブな場合、ロックエントリが複製されたことを確認します。

    > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    返されるロックの数は、ASCS インスタンスと同じになるはずです。

  4. ASCS がアクティブな場合は、サーバーを再起動します。

  5. 必要に応じて、いずれかのサーバーの root として、クラスタ フェイルオーバーをモニタリングします。

    # crm_mon
  6. SID_LCadm として、ASCS が再起動されたサーバーで、ロックエントリが保持されていることを確認します。

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now
  7. SID_LCadm として、ERS がアクティブなサーバーで、ロックが保持されていることを確認した後、ロックを解放します。

    > enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
  8. SID_LCadm として、ASCS がアクティブなサーバーで、ロックエントリが削除されていることを確認します。

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

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

    locks_now: 0

Compute Engine のメンテナンス イベントをシミュレートする

Compute Engine のメンテナンス イベントをシミュレートして、ライブ マイグレーションによってフェイルオーバーがトリガーされないようにします。

この手順で使用されるタイムアウトと間隔の値では、ライブ マイグレーションの期間が考慮されます。クラスタ構成で値を小さくすると、ライブ マイグレーションによってフェイルオーバーがトリガーされるリスクが高くなります。

ライブ マイグレーション用のクラスタの許容値をテストするには:

  1. プライマリ ノードで、次の gcloud CLI コマンドを使用してシミュレート メンテナンス イベントをトリガーします。

    $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME
  2. プライマリ ノードが変更されていないことを確認します。

    $ pcs status

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

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

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

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

トラブルシューティング

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

SAP NetWeaver 高可用性クラスタの診断情報を収集する

SAP NetWeaver 用の高可用性クラスタの問題を解決するには、必要な診断情報を収集し、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 NetWeaver システムを使用する前に、新しい SAP NetWeaver HA システムをバックアップすることをおすすめします。

詳細については、SAP NetWeaver 運用ガイドをご覧ください。

次のステップ

高可用性、SAP NetWeaver、Google Cloud の詳細については、次のリソースをご覧ください。