SLES 上での SAP NetWeaver の HA クラスタ構成ガイド

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

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

  • 内部 TCP / UDP 負荷分散を構成して、障害発生時にトラフィックを再ルーティングする
  • SLES に Pacemaker クラスタを構成して、フェイルオーバー中に SAP システムやその他のリソースを管理する

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

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

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

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

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

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

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

  • 2 つのホスト VM(アクティブな SAP セントラル サービスを含む VM とアクティブなスタンドアロン エンキュー サーバーを含む VM)
  • Pacemaker 高可用性クラスタ リソース マネージャー。
  • STONITH フェンシング メカニズム。
  • 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動。

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

前提条件

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

  • 個人または組織で Google Cloud アカウントを所有していて、SAP NetWeaver をデプロイするプロジェクトを作成済みである。Google Cloud アカウントとプロジェクトの作成方法については、Linux 向け SAP NetWeaver デプロイガイドのプロジェクトの作成をご覧ください。
  • VPC 内部 DNS を使用している場合は、プロジェクト メタデータの VmDnsSetting 変数の値を GlobalOnly または ZonalPreferred にして、ゾーン間でノード名を解決できるようにする。VmDnsSetting のデフォルト設定は ZonalOnly です。詳細については、次のトピックをご覧ください。

  • プロジェクト メタデータで OS Login が有効になっている場合は、デプロイが完了するまで一時的に OS Login を無効にする必要があります。デプロイのために、次の手順によりインスタンス メタデータで SSH 認証鍵を構成します。OS Login が有効になっている場合、メタデータ ベースの SSH 認証鍵構成は無効になり、このデプロイは失敗します。デプロイが完了したら、再度 OS Login を有効にできます。

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

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

ネットワークの作成

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

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

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

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

  1. Cloud Shell に移動します。

    Cloud Shell に移動

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

    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    NETWORK_NAME は、新しいネットワークの名前に置き換えます。ネットワーク名に使えるのは、小文字、数字、ダッシュ(-)のみです。

    デフォルトの自動モードでは、各 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 アドレスなしでインターネットに安全にアクセスできるようになります。

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

デフォルトでは、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 ヘルスチェック。詳細については、ヘルスチェック用のファイアウォール ルールを作成するをご覧ください。

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

  1. Cloud Console で、[ファイアウォール ルール] ページに移動します。

    [ファイアウォール ルール] ページを開く

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

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

SAP NetWeaver 用の VM のデプロイ

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

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

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

VM が正常にデプロイされたら、SAP NetWeaver をインストールし、HA クラスタを定義して構成します。

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

  1. Cloud Shell を開きます。

    Cloud Shell に移動

  2. YAML 構成ファイルのテンプレート template.yaml を作業ディレクトリにダウンロードします。

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

  3. 必要に応じて template.yaml のファイル名を変更し、このファイルで定義する構成がわかるようにします。例: nw-ha-sles15sp1.yaml

  4. Cloud Shell ターミナル ウィンドウの右上にある鉛筆アイコン()をクリックし、エディタを起動することで、Cloud Shell コードエディタで YAML 構成ファイルを開きます。

  5. YAML 構成ファイルのテンプレートで、最初の VM インスタンスを定義します。次の表の後の次のステップで、2 番目の VM インスタンスを定義します。

    プロパティ値を指定するには、かっことその内容をご使用のインストール環境の値に置き換えます。プロパティについては、次の表をご覧ください。完全な構成ファイルの例については、完全な YAML 構成ファイルの例をご覧ください。

    プロパティ データ型 説明
    name 文字列 次のプロパティ セットで定義するデプロイ リソースを識別する任意の名前。
    type 文字列

    デプロイ中に使用する Deployment Manager テンプレートの場所、タイプ、バージョンを指定します。

    YAML ファイルには 2 つの type 仕様が含まれており、そのうちの 1 つがコメントアウトされています。デフォルトで有効な type 仕様では、テンプレート バージョンを latest として指定します。コメントアウトされている type 仕様では、タイムスタンプを使用して特定のテンプレート バージョンを指定します。

    すべてのデプロイで同じテンプレート バージョンを使用する必要がある場合は、タイムスタンプを含む type 仕様を使用します。

    instanceName 文字列 定義中の VM インスタンスの名前。プライマリ VM とセカンダリ VM の定義で異なる名前を指定します。インスタンスを同じ高可用性クラスタに属するものとして識別する名前を使用してください。

    インスタンス名は 13 文字以下で、小文字、数字、ハイフンで指定する必要があります。プロジェクト内で一意の名前を使用してください。

    instanceType 文字列 必要な Compute Engine VM のタイプ。プライマリ VM とセカンダリ VM に同じインスタンス タイプを指定します。

    カスタム VM タイプが必要な場合は、小さな事前定義 VM タイプを指定し、デプロイが完了した後に必要に応じて VM をカスタマイズします。

    zone 文字列 定義している VM インスタンスをデプロイする Google Cloud ゾーン。プライマリ VM 定義とセカンダリ VM 定義に同じリージョンの異なるゾーンを指定します。このゾーンは、サブネットに選択したのと同じリージョンに存在する必要があります。
    subnetwork 文字列 前のステップで作成したサブネットワークの名前。共有 VPC にデプロイする場合は、この値を [SHAREDVPC_PROJECT]/[SUBNETWORK] の形式で指定します。例: myproject/network1
    linuxImage 文字列 SAP NetWeaver で使用する Linux オペレーティング システムのイメージまたはイメージ ファミリーの名前。イメージ ファミリーを指定するには、ファミリー名に接頭辞 family/ を追加します。例: family/sles-15-sp1-sap利用可能なイメージ ファミリーの一覧については、Cloud Console の [イメージ] ページをご覧ください。
    linuxImageProject 文字列 使用するイメージを含む Google Cloud プロジェクト。このプロジェクトは独自のプロジェクトか、Google Cloud イメージ プロジェクト suse-sap-cloud です。Google Cloud イメージ プロジェクトの一覧については、Compute Engine ドキュメントのイメージのページをご覧ください。
    usrsapSize 整数 /usr/sap ディスクのサイズ。最小サイズは 8 GB です。
    sapmntSize 整数 /sapmnt ディスクのサイズ。最小サイズは 8 GB です。
    swapSize 整数 スワップ ボリュームのサイズ。最小サイズは 1 GB です。
    networkTag 文字列

    省略可。ファイアウォールまたはルーティングの目的で使用される、VM インスタンスを表すネットワーク タグ。カンマ区切りで複数指定できます。

    高可用性構成では、クラスタノード間の通信を許可するファイアウォール ルールに使用するネットワーク タグと、クラスタノードへのアクセスに対する Cloud Load Balancing ヘルスチェックを許可するファイアウォール ルールに使用するネットワーク タグを指定します。

    「publicIP: No」を指定していて、ネットワーク タグを指定しない場合は、インターネットへの別のアクセス手段を必ず指定してください。

    serviceAccount 文字列

    省略可。デプロイされた VM に使用するカスタム サービス アカウントを指定します。サービス アカウントには、SAP 用の VM を構成するためにデプロイ時に必要となる権限を含める必要があります。

    serviceAccount を指定しない場合は、デフォルトの Compute Engine サービス アカウントが使用されます。

    完全なサービス アカウント アドレスを指定します。例: sap-ha-example@example-project-123456.iam.gserviceaccount.com

    publicIP ブール値 省略可。パブリック IP アドレスを VM インスタンスに追加するかどうかを指定します。デフォルトは Yes です。
    sap_deployment_debug ブール値 省略可。この値が Yes に設定されている場合、デプロイの際に詳細なログが生成されます。Google のサポート エンジニアからデバッグを有効にするように求められない限り、この設定はオンにしないでください。
  6. YAML 構成ファイルで、1 番目の VM の定義をコピーし、それを 1 番目の定義の後に貼り付けて、2 番目の VM の定義を作成します。例については、完全な YAML 構成ファイルの例をご覧ください。

  7. 2 番目の VM の定義では、次のプロパティについて、最初の定義で指定したものとは異なる値を指定します。

    • name
    • instanceName
    • zone
  8. VM インスタンスを作成します。

    gcloud deployment-manager deployments create [DEPLOYMENT_NAME] --config [TEMPLATE_NAME].yaml

    ここで

    • [DEPLOYMENT_NAME] はデプロイメントの名前を表します。
    • [TEMPLATE_NAME] は YAML 構成ファイルの名前を表します。

    上のコマンドによって Deployment Manager が起動すると、YAML 構成ファイルの仕様に従って VM がデプロイされます。

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

完全な YAML 構成ファイルの例

次の例は、最新バージョンの Deployment Manager テンプレートを使用して SAP NetWeaver の HA 構成用に 2 つの VM インスタンスをデプロイする、完全な YAML 構成ファイルを示しています。この例では、テンプレートを初めてダウンロードするときに、そのテンプレートに含まれるコメントが省略されます。

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

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

プロパティ networkTagserviceAccount は、構成ファイル テンプレートの [詳細オプション] セクションにあります。

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com

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

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

  • 構成が目的の場合は、ローカル ワークステーション、踏み台インスタンス、踏み台サーバー
  • クラスタノード間のアクセスの場合は、HA クラスタ内の他のホスト VM
  • 後のヘルスチェック用のファイアウォール ルールを作成するの手順で説明される、Cloud Load Balancing で使用するヘルスチェック

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

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

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

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

VM のデプロイを確認する

SAP NetWeaver をインストールするか、HA クラスタの構成を開始する前に、ログと OS ストレージ マッピングを確認して、VM が正しくデプロイされていることを確認します。

ログを確認する

次の手順では Cloud Logging を使用するため、料金が発生することがあります。詳細については、Cloud Logging の料金をご覧ください。

  1. Cloud Logging を開いてエラーをチェックし、インストールの進行状況をモニタリングします。

    Logging に移動

  2. [リソース] タブで、ロギング リソースとして [グローバル] を選択します。VM に「INSTANCE DEPLOYMENT COMPLETE」と表示されている場合、その VM に対する Deployment Manager の処理は完了しています。

    Logging の表示

VM の構成を確認する

  1. VM インスタンスがデプロイされたら、ssh を使用して VM に接続します。

    1. まだ作成していない場合は、ファイアウォール ルールを作成して、ポート 22 で SSH 接続が許可されるようにします。
    2. [VM インスタンス] ページに移動します。

      [VM インスタンス] ページに移動

    3. 各 VM インスタンスのエントリで [SSH] ボタンをクリックして各 VM インスタンスに接続するか、任意の SSH メソッドを使用します。

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

  2. ファイル システムを表示します。

    ~> df -h

    次のような出力が表示されます。

    Filesystem                 Size  Used Avail Use% Mounted on
    devtmpfs                    32G  8.0K   32G   1% /dev
    tmpfs                       48G     0   48G   0% /dev/shm
    tmpfs                       32G  402M   32G   2% /run
    tmpfs                       32G     0   32G   0% /sys/fs/cgroup
    /dev/sda3                   30G  3.4G   27G  12% /
    /dev/sda2                   20M  3.7M   17M  19% /boot/efi
    /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
    /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
    tmpfs                      6.3G     0  6.3G   0% /run/user/1002
    tmpfs                      6.3G     0  6.3G   0% /run/user/0
  3. スワップ領域が作成されたことを確認します。

    ~> cat /proc/meminfo | grep Swap

    次の例のような結果が表示されます。

    SwapCached:            0 kB
    SwapTotal:      25161724 kB
    SwapFree:       25161724 kB

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

  1. エラーを修正します。
  2. [デプロイ] ページでデプロイメントを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。
  3. デプロイを再実行します。

Cloud SDK を更新する

Deployment Manager テンプレートによって、デプロイ中に VM に Cloud SDK がインストールされました。Cloud SDK を更新し、最新の更新がすべて含まれていることを確認します。

  1. プライマリ VM に SSH 接続します。

  2. Cloud SDK を更新します。

    ~>  sudo gcloud components update
  3. 表示される手順に沿って操作します。

  4. セカンダリ VM で上述の手順を繰り返します。

VM 間でのロードバランサのバックエンド通信を有効にする

VM が正常にデプロイされたことを確認したら、HA クラスタ内のノードとして機能する VM 間のバックエンド通信を有効にします。

  1. HA クラスタ内の各 VM でローカル ルーティングを有効にします。

    1. 計画しているクラスタ内の各 VM に SSH 接続します。
    2. root ユーザーに切り替えます。
    3. 各マシンで、次のコマンドを発行してプライマリ インターフェースのローカル ルーティングを有効にします。eth0 とは異なるインターフェースを使用している場合は、コマンド内で eth0 の代わりにそのインターフェースを指定します。

      echo net.ipv4.conf.eth0.accept_local=1 >> /etc/sysctl.conf
      sysctl -p

      前述のコマンドは、設定を構成ファイルに書き込みます。

  2. 各 VM で、バックエンド間の通信を有効にする起動スクリプトを作成します。

    Cloud Console

    1. Cloud Console の [VM インスタンス] ページに移動します。

      [VM インスタンス] ページに移動

    2. プライマリ VM の名前をクリックします。

    3. [VM インスタンスの詳細] ページで、[編集] ボタンをクリックします。

    4. [カスタム メタデータ] セクションで [項目を追加] をクリックします。

    5. [キー] フィールドで、startup-script を指定します。

    6. [] フィールドに、次の bash スクリプトを貼り付けます。

      #! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule del from all lookup local
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi
    7. ページの下部にある [保存] をクリックします。

    8. 起動スクリプトを有効にするために、サーバーを再起動します。

      完了すると、カスタム メタデータは次の例のようになります。

      Cloud Console の [VM の詳細] ページの [カスタム メタデータ] セクションで、「startup-script」が他のエントリとともにスクリーン キャプチャに表示される

    9. セカンダリ サーバーに上述の手順を繰り返します。

    gcloud

    1. Cloud Shell や Cloud SDK がインストールされている場所で、付属の起動スクリプトとともに次の gcloud コマンドを使用して、各 VM のインスタンス メタデータに起動スクリプトを追加します。コマンドを入力する前に、変数を VM の名前とゾーンに置き換えます。

      gcloud compute instances add-metadata primary-vm-name \
      --zone=primary-vm-zone --metadata=startup-script='#! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip rule del from all lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi'
    2. 起動スクリプトを有効にするために、サーバーを再起動します。

    3. 起動スクリプトがインスタンス メタデータに保存されていることを確認するには、次のコマンドを発行します。

      gcloud compute instances describe primary-vm-name \
      --zone=primary-vm-zone

      次の省略例に示すように、起動スクリプトは出力の metadata の下に表示されます。

      metadata:
      fingerprint: Tbuij9k-knk=
      items:
      - key: post_deployment_script
      value: ''
      - key: sap_deployment_debug
      value: 'False'
      - key: status
      value: completed
      - key: startup-script
      value: |-
        #! /bin/bash
        # VM startup script
        ...
        [example truncated]
    4. セカンダリ VM の場合は、変数値をセカンダリ VM インスタンスの値に置き換えてから、上述の手順を繰り返します。

Compute Engine VM 用の起動スクリプトの作成方法については、起動スクリプトの実行をご覧ください。

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

HA クラスタ内のホスト間でファイルをコピーできるようにするために、このセクションの手順で、2 つのホスト間の root SSH 接続を作成します。

Google Cloud が提供する Deployment Manager テンプレートによりキーが生成されますが、自身でキーを生成してこれを置き換えることもできます。

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

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

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

プライマリ インスタンスとセカンダリ インスタンス間の SSH 接続を有効にする手順は次のとおりです。この手順では、SAP 用の Deployment Manager テンプレートによって生成された SSH 認証鍵を使用していることを前提としています。

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

    1. SSH 経由で VM に接続します。

    2. root に切り替えます。

      $ sudo su -
    3. SSH 認証鍵が存在していることを確認します。

      # ls -l /root/.ssh/

      id_rsa 鍵ファイルは次の例のようになります。

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. プライマリ VM のメタデータを、セカンダリ VM の SSH 認証鍵に関する情報で更新します。

      # gcloud compute instances add-metadata secondary-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-vm-zone
    5. プライマリ システムからセカンダリ システムへの SSH 接続を開き、SSH 認証鍵が正しく設定されていることを確認します。

      # ssh secondary-vm-name
  2. セカンダリ ホスト VM で、次のようにします。

    1. VM に SSH 接続します。

    2. root に切り替えます。

      $ sudo su -
    3. SSH 認証鍵が存在していることを確認します。

      # ls -l /root/.ssh/

      id_rsa 鍵ファイルは次の例のようになります。

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. セカンダリ VM のメタデータを、プライマリ VM の SSH 認証鍵に関する情報で更新します。

      # gcloud compute instances add-metadata primary-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone
      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. セカンダリ システムからプライマリ システムへの SSH 接続を開き、SSH 認証鍵が正しく設定されていることを確認します。

      # ssh primary-vm-name

共有ファイル ストレージを設定し、共有ディレクトリを構成する

HA クラスタの両方のノードがアクセスできる、可用性の高い共有ファイル ストレージを提供する NFS ファイル共有ソリューションを設定する必要があります。その後、共有ファイル ストレージにマッピングする両方のノードにディレクトリを作成します。クラスタ ソフトウェアにより、適切なインスタンスにのみ適切なディレクトリがマウントされます。

このガイドでは、ファイル共有ソリューションの設定方法については説明しません。ファイル共有システムの設定手順については、ソリューションのベンダーが提供する手順をご覧ください。

Google Cloud で利用可能なファイル共有ソリューションについては、Google Cloud での HA SAP システムの共有ストレージ オプションをご覧ください。

共有ディレクトリを構成するには:

  1. 高可用性 NFS 共有ファイル ストレージ ソリューションをまだ設定していない場合は、ここで設定します。

  2. 初期構成のために、NFS 共有ストレージを両方のサーバーにマウントします。

    ~> sudo mkdir /mnt/nfs
    ~> sudo mount -t nfs nfs-path /mnt/nfs
  3. 両方のサーバーで、sapmnt のディレクトリ、セントラル トランスポート ディレクトリ、システム ディレクトリ、インスタンス固有のディレクトリを作成します。Java スタックを使用している場合、以下のコマンド、およびその他のコマンドの例を使用する前に、「ASCS」を「SCS」に置き換えてください。

    ~> sudo mkdir /mnt/nfs/sapmntSID
    ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDSYS,SIDASCSscs-instance-number,SIDERSers-instance-number}
  4. 両方のサーバーで、必要なマウント ポイントを作成します。

    ~> sudo mkdir -p /sapmnt/SID
    ~> sudo mkdir -p /usr/sap/trans
    ~> sudo mkdir -p /usr/sap/SID/SYS
    ~> sudo mkdir -p /usr/sap/SID/ASCSscs-instance-number
    ~> sudo mkdir -p /usr/sap/SID/ERSers-instance-number
  5. ファイル ディレクトリへの最初のアクセス時に、共通の共有ファイル ディレクトリをマウントするように autofs を構成します。ASCSscs-instance-number ディレクトリと ERSers-instance-number ディレクトリのマウントは、後の手順で構成するクラスタ ソフトウェアによって管理されます。

    必要に応じて、コマンドの NFS オプションをファイル共有ソリューションに合わせて調整します。

    両方のサーバーで、autofs を構成します。

    ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
    ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
    ~> echo "/sapmnt/SID ${NFS_OPTS} nfs-path/sapmntSID" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/trans ${NFS_OPTS} nfs-path/usrsaptrans" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/SID/SYS ${NFS_OPTS} nfs-path/usrsapSIDSYS" | sudo tee -a /etc/auto.sap

    autofs の詳細については、autofs - 仕組みをご覧ください。

  6. 両方のサーバーで autofs サービスを起動します。

    ~> sudo systemctl enable autofs
    ~> sudo systemctl restart autofs
    ~> sudo automount -v
  7. cd コマンドを使用して各ディレクトリにアクセスし、autofs をトリガーして共有ディレクトリをマウントします。次に例を示します。

    ~> cd /sapmnt/SID
    ~> cd /usr/sap/trans
    ~> cd /usr/sap/SID/SYS
    
  8. すべてのディレクトリにアクセスしたら、df -Th コマンドを実行して、ディレクトリがマウントされていることを確認します。

    ~> df -Th | grep file_share_name

    次のようなマウント ポイントとディレクトリが表示されます。

    10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
    10.49.153.26:/nfs_share_nw_ha/usrsapAHASYS nfs      1007G   76M  956G   1% /usr/sap/AHA/SYS
    10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
    10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA

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

フェイルオーバーをサポートする内部 TCP / UDP 負荷分散サービスは、SCS トラフィックと ERS トラフィックを SAP NetWeaver クラスタ内の各アクティブなインスタンスにルーティングします。内部 TCP / UDP 負荷分散では、仮想 IP(VIP)アドレス、バックエンド サービス、インスタンス グループ、ヘルスチェックを使用してトラフィックが適切にルーティングされます。

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

SAP NetWeaver の高可用性クラスタの場合は、2 つの VIP を作成します。これは、フローティング IP アドレスと呼ばれることもあります。1 つの VIP は、アクティブな SAP セントラル サービス(SCS)インスタンスをフォローし、もう 1 つの VIP はエンキュー レプリケーション サーバー(ERS)インスタンスをフォローします。ロードバランサは、各 VIP に送信されるトラフィックを、VIP の SCS または ERS コンポーネントのアクティブ インスタンスを現在ホストしている VM にルーティングします。

  1. Cloud Shell を開きます。

    Cloud Shell に移動

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

    ~ gcloud compute addresses create scs-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses scs-vip-address
    
    ~ gcloud compute addresses create ers-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses ers-vip-address

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

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

    ~ gcloud compute addresses describe vip-name \
      --region cluster-region

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

    address: 10.1.0.85
    addressType: INTERNAL
    creationTimestamp: '2021-05-12T13:30:29.991-07:00'
    description: ''
    id: '1740813556077659146'
    kind: compute#address
    name: scs-aha-vip-name
    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/scs-aha-vip-name
    status: RESERVED
    subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

/etc/hosts 内の VIP アドレスのホスト名を定義する

各 VIP アドレスのホスト名を定義し、VM と VIP の両方の IP アドレスとホスト名を各 VM の /etc/hosts ファイルに追加します。

VIP ホスト名は、DNS サービスに追加しない限り VM の外部では認識されません。これらのエントリをローカルの /etc/hosts ファイルに追加すると、クラスタが DNS サービスへの中断から保護されます。

/etc/hosts ファイルの更新は次の例のようになります。

#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
127.0.0.1       localhost
10.1.0.89       nw-ha-vm-1
10.1.0.88       nw-ha-vm-2
10.1.0.90       vh-scs-aha
10.1.0.91       vh-ers-aha

Cloud Load Balancing ヘルスチェックを作成する

ヘルスチェックを作成します。1 つはアクティブな SCS インスタンス用で、もう 1 つはアクティブな ERS 用です。

  1. Cloud Shell で、ヘルスチェックを作成します。他のサービスと競合しないようにするには、プライベート範囲の SCS インスタンスと ERS インスタンスのポート番号 49152~65535 を指定します。次のコマンド内のチェック間隔とタイムアウトの値は、Compute Engine のライブ マイグレーション イベント中のフェイルオーバーの許容範囲を広げるために、デフォルトよりも少し長くなっています。必要に応じて値を調整できます。

    1. ~ gcloud compute health-checks create tcp scs-health-check-name \
      --port=scs-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
    2. ~ gcloud compute health-checks create tcp ers-health-check-name \
      --port=ers-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: '2021-05-12T15:12:21.892-07:00'
    healthyThreshold: 2
    id: '1981070199800065066'
    kind: compute#healthCheck
    name: scs-aha-health-check-name
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    tcpHealthCheck:
      port: 60000
      portSpecification: USE_FIXED_PORT
      proxyHeader: NONE
    timeoutSec: 10
    type: TCP
    unhealthyThreshold: 2

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

まだ行っていない場合は、プライベート範囲のポートのファイアウォール ルールを定義して、Cloud Load Balancing のヘルスチェックで使用される IP 範囲(35.191.0.0/16130.211.0.0/22)からホスト VM へのアクセスを許可します。ロードバランサのファイアウォール ルールの詳細については、ヘルスチェック用のファイアウォール ルールの作成をご覧ください。

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

  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:scs-healthcheck-port-num,tcp:ers-healthcheck-port-num

    次に例を示します。

    gcloud compute firewall-rules create  nw-ha-cluster-health-checks \
    --network=example-network \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-health-check \
    --rules=tcp:60000,tcp:60010

Compute Engine インスタンス グループを作成する

クラスタノード VM を含む各ゾーンにインスタンス グループを作成し、そのゾーンの VM をインスタンス グループに追加する必要があります。

  1. Cloud Shell で、プライマリ インスタンス グループを作成し、そこにプライマリ VM を追加します。

    1. ~ gcloud compute instance-groups unmanaged create primary-ig-name \
      --zone=primary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances primary-ig-name \
      --zone=primary-vm-zone \
      --instances=primary-vm-name
  2. Cloud Shell で、セカンダリ インスタンス グループを作成し、そこにセカンダリ VM を追加します。

    1. ~ gcloud compute instance-groups unmanaged create secondary-ig-name \
      --zone=secondary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances secondary-ig-name \
      --zone=secondary-vm-zone \
      --instances=secondary-vm-name
  3. インスタンス グループが作成されたことを確認します。

    ~ gcloud compute instance-groups unmanaged list

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

    NAME                              ZONE           NETWORK              NETWORK_PROJECT        MANAGED  INSTANCES
    sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
    sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
    

バックエンド サービスを構成する

SCS 用と ERS 用の 2 つのバックエンド サービスを作成します。両方のインスタンス グループを各バックエンド サービスに追加し、対になるインスタンス グループをそれぞれのバックエンド サービスのフェイルオーバー インスタンス グループとして指定します。最後に、VIP からバックエンド サービスへの転送ルールを作成します。

  1. Cloud Shell で、SCS のバックエンド サービスとフェイルオーバー グループを作成します。

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

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

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

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --failover \
        --region cluster-region
  2. Cloud Shell で、ERS のバックエンド サービスとフェイルオーバー グループを作成します。

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

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

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --region cluster-region
    3. プライマリ インスタンス グループを ERS バックエンド サービスのフェイルオーバー インスタンス グループとして追加します。

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --failover \
        --region cluster-region
  3. 必要に応じて、バックエンド サービスに想定通りにインスタンス グループが含まれていることを確認します。

    ~ gcloud compute backend-services describe backend-service-name \
     --region=cluster-region

    SCS バックエンド サービスの場合、次の例のような出力が表示されます。ERS の場合、failover: true はプライマリ インスタンス グループに表示されます。

    backends:
    - balancingMode: CONNECTION
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    - balancingMode: CONNECTION
      failover: true
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    connectionDraining:
      drainingTimeoutSec: 0
    creationTimestamp: '2021-05-25T08:30:58.424-07:00'
    description: ''
    failoverPolicy:
      disableConnectionDrainOnFailover: true
      dropTrafficIfUnhealthy: true
      failoverRatio: 1.0
    fingerprint: n44gVc1VVQE=
    healthChecks:
    - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    id: '4940777952116778717'
    kind: compute#backendService
    loadBalancingScheme: INTERNAL
    name: scs-aha-backend-service-name
    protocol: TCP
    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/backendServices/scs-aha-backend-service-name
    sessionAffinity: NONE
    timeoutSec: 30
  4. Cloud Shell で、SCS および ERS バックエンド サービスの転送ルールを作成します。

    1. SCS VIP から SCS バックエンド サービスへの転送ルールを作成します。

      ~ gcloud compute forwarding-rules create scs-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address scs-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service scs-backend-service-name \
      --ports ALL
    2. ERS VIP から ERS バックエンド サービスへの転送ルールを作成します。

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

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

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

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

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

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

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

    # zypper install -y socat

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

    # timeout 60s socat - TCP-LISTEN:scs-healthcheck-port-num,fork

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

    ~ gcloud compute backend-services get-health scs-backend-service-name \
      --region cluster-region
  4. SCS の変数値を ERS の値に置き換えて、ERS の手順を繰り返します。

    SCS の場合、次のような出力が表示されます。

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.89
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: UNHEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.88
        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-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.79
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.78
        port: 80
      kind: compute#backendServiceGroupHealth
  6. 完了したら、ヘルスチェックのポート番号を元のポート番号に戻します。

Pacemaker を設定する

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

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

必要なクラスタ パッケージをインストールする

  1. プライマリ ホストとセカンダリ ホストの両方で、root として、次の必要なクラスタ パッケージをダウンロードします。

    • ha_sles パターン:

      # zypper install -t pattern ha_sles
    • sap-suse-cluster-connector パッケージ:

      # zypper install -y sap-suse-cluster-connector
    • まだインストールしていない場合、socat ユーティリティ:

      # zypper install -y socat

  2. 最新の高可用性エージェントが読み込まれていることを確認します。

    # zypper se -t patch SUSE-SLE-HA

プライマリ VM 上のクラスタを初期化、構成、起動する

クラスタを初期化するには、ha-cluster-init SUSE スクリプトを使用します。その後、Corosync 構成ファイルを編集し、セカンダリ ノードと同期する必要があります。クラスタを起動したら、crm コマンドを使用して、追加のクラスタ プロパティとデフォルトを設定します。

クラスタを初期化する

クラスタを初期化するには:

  1. プライマリ ホストで、root として SUSE ha-cluster-init スクリプトを使用してクラスタを初期化します。次のコマンドではクラスタに名前を付けて構成ファイル corosync.conf を作成し、クラスタノード間の同期を設定します。

    # ha-cluster-init --name cluster-name --yes --interface eth0 csync2
    # ha-cluster-init --name cluster-name --yes --interface eth0 corosync

Corosync 構成ファイルを更新する

  1. 編集する corosync.conf ファイルを開きます。

    # vi /etc/corosync/corosync.conf
  2. corosync.conf ファイルの totem セクションで、次の例に示すパラメータを、表示される値に設定します。一部のパラメータには、すでに正しい値が設定されている場合があります。

    totem {
            ...
            token: 20000
            token_retransmits_before_loss_const: 10
            join: 60
            consensus: 24000
            max_messages: 20
            ...
    }
  3. クラスタを起動します。

    # ha-cluster-init --name cluster-name cluster

追加のクラスタ プロパティを設定する

  1. 一般的なクラスタのプロパティを設定します。

    # crm configure property no-quorum-policy="stop"
    # crm configure property startup-fencing="true"
    # crm configure property stonith-timeout="300s"
    # crm configure property stonith-enabled="true"
    # crm configure rsc_defaults resource-stickiness="1"
    # crm configure rsc_defaults migration-threshold="3"
    # crm configure op_defaults timeout="600"

    個々のクラスタ リソースを定義すると、resource-stickinessmigration-threshold に設定した値がここで設定したデフォルト値よりも優先されます。

    crm config show」と入力すると、リソースのデフォルトおよび定義済みのリソースの値が表示できます。

  2. プライマリ ホストで Pacemaker を起動します。

    # systemctl enable pacemaker
    # systemctl start pacemaker

セカンダリ VM をクラスタに参加させる

プライマリ VM の開いているターミナルから、SSH を経由してセカンダリ VM のクラスタに参加し、起動します。

  1. プライマリ VM から、SSH 経由でセカンダリ VM で次の ha-cluster-join スクリプト オプションを実行します。上述の手順で HA クラスタを構成した場合は、ウォッチドッグ デバイスに関する警告を無視できます。

    1. --interface eth0 csync2 オプションを実行します。

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes --interface eth0 csync2'
    2. ssh_merge オプションを実行します。

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes ssh_merge'
    3. cluster オプションを実行します。

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes cluster'
  2. セカンダリ ホストで Pacemaker を起動します。

    1. Pacemaker を有効にします。

      # ssh secondary-vm-name systemctl enable pacemaker
    2. Pacemaker を起動します。

      # ssh secondary-vm-name systemctl start pacemaker
  3. いずれかのホストで、root としてクラスタに両方のノードが表示されていることを確認します。

    # crm_mon -s

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

    CLUSTER OK: 2 nodes online, 0 resource instances configured

インフラストラクチャのクラスタ リソースを構成する

Pacemaker が高可用性クラスタで管理するリソースを定義します。次のクラスタ コンポーネントのリソースを定義する必要があります。

  • フェンシング デバイス(スプリット ブレイン シナリオを回避する)
  • 共有ファイル システム内の SCS ディレクトリと ERS ディレクトリ
  • ヘルスチェック
  • VIP
  • SCS コンポーネントと ERS コンポーネント

最初に SAP NetWeaver をインストールする必要があるため、SCS および ERS コンポーネントのリソースは他のリソースよりも後で定義します。

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

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

    # crm configure property maintenance-mode="true"
  2. メンテナンス モードを確認します。

    # crm status

    次の例に示すように、リソース管理が無効になっていることが出力に示されるはずです。

    Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
    * Last updated: Fri May 14 15:26:08 2021
    * Last change:  Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1
    * 2 nodes configured
    * 0 resource instances configured
    
                *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
    
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of Resources:
    * No resources

フェンスを設定する

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

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

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

クラスタ内の VM ごとに、その VM を再起動できるフェンシング デバイス用のクラスタ リソースを作成します。VM のフェンシング デバイスは別の VM で実行する必要があるため、再起動可能な VM 以外の VM で実行されるようにクラスタ リソースのロケーションを構成します。

  1. プライマリ ホストで、root としてプライマリ VM のフェンシング デバイス用のクラスタ リソースを作成します。

    # crm configure primitive fencing-rsc-name-primary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="primary-vm-name" zone="primary-vm-zone" \
      project="cluster-project-id"
  2. セカンダリ VM でのみアクティブになるように、プライマリ VM のフェンシング デバイスの場所を構成します。

    # crm configure location fencing-location-name-primary-vm \
      fencing-rsc-name-primary-vm -inf: "primary-vm-name"
  3. プライマリ ホストで、root としてセカンダリ VM のフェンシング デバイス用のクラスタ リソースを作成します。

    # crm configure primitive fencing-rsc-name-secondary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="secondary-vm-name" zone="secondary-vm-zone" \
      project="cluster-project-id"
  4. プライマリ VM でのみアクティブになるように、セカンダリ VM のフェンシング デバイスの場所を構成します。

    # crm configure location fencing-location-name-secondary-vm \
      fencing-rsc-name-secondary-vm -inf: "secondary-vm-name"

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

再起動時の Pacemaker のタイムアウト値を増やす

  1. 各ホストで root として、起動の遅れを考慮して、再起動の Pacemaker のタイムアウト値を増やします。

    crm_resource --resource STONITH-host-name --set-parameter=pcmk_reboot_timeout --parameter-value=300

    pcmk_reboot_timeout の値は、以下の合計値よりも大きくする必要があります。

    • Corosync token のタイムアウト
    • Corosync consensus のタイムアウト
    • 遅延属性を含め、再起動が完了するまでの時間の長さ。

    Google Cloud の場合、ほとんどのクラスタで 300 秒あれば十分です。

  2. 新しい pcmk_reboot_timeout 値を確認します。

    crm_resource --resource STONITH-host-name --get-parameter=pcmk_reboot_timeout

ファイル システム リソースを作成する

共有ファイル システム ディレクトリを作成したら、クラスタ リソースを定義できます。

  1. インスタンスに固有のディレクトリ用のファイル システム リソースを構成します。

    # crm configure primitive scs-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDASCSscs-instance-number" \
    directory="/usr/sap/SID/ASCSscs-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s
    # crm configure primitive ers-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDERSers-instance-number" \
    directory="/usr/sap/SID/ERSers-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

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

  1. SCS ヘルスチェックと ERS ヘルスチェックのクラスタ リソースを構成します。
# crm configure primitive scs-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:scs-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0
# crm configure primitive ers-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ers-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0

VIP リソースを作成する

VIP アドレスのクラスタ リソースを定義します。

  1. VIP 数値アドレスを検索する必要がある場合は、次を使用します。

    • gcloud compute addresses describe scs-vip-name
      --region=cluster-region --format="value(address)"
    • gcloud compute addresses describe ers-vip-name
      --region=cluster-region --format="value(address)"
  2. SCS VIP と ERS VIP のクラスタ リソースを作成します。

    # crm configure primitive scs-vip-rsc-name IPaddr2 \
     params ip=scs-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s
    # crm configure primitive ers-vip-rsc-name IPaddr2 \
     params ip=ers-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s

定義済みのリソースを表示する

  1. これまでに定義したすべてのリソースを表示するには、次のコマンドを入力します。

    # crm status

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

    Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Wed May 26 19:10:10 2021
    Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1
    
    2 nodes configured
    8 resource instances configured
    
                  *** Resource management is DISABLED ***
      The cluster will not attempt to start, stop or recover services
    
    Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped (unmanaged)
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Stopped (unmanaged)
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Stopped (unmanaged)
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)

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

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

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

インストールを準備する

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

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

    # crm configure property maintenance-mode="false"
  2. 両方のサーバーで、root として次のコマンドを入力し、環境に適したユーザー ID とグループ ID を指定します。

    # groupadd -g gid-sapinst sapinst
    # groupadd -g gid-sapsys sapsys
    # useradd -u uid-sidadm sid-loweradm -g sapsys
    # usermod -a -G sapinst sid-loweradm
    # useradd -u uid-sapadm sapadm -g sapinst
    
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS
    # chown sid-loweradm:sapsys /sapmnt/SID -R
    # chown sid-loweradm:sapsys /usr/sap/trans -R
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS -R
    # chown sid-loweradm:sapsys /usr/sap/SID -R

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

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

    # crm_standby -v on -N ${HOSTNAME};

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

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

    # crm status

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

    Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
    
    2 nodes configured
    8 resource instances configured
    
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
  3. プライマリ サーバーで、root ユーザーとしてディレクトリを /tmp などの一時インストール ディレクトリに変更し、SAP Software Provisioning Manager(SWPM)を実行して SCS インスタンスをインストールします。

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

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

      次に例を示します。

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

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

    # crm_standby -v off -N ${HOSTNAME}; # On SECONDARY

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

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

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

    # crm_standby -v on -N ${HOSTNAME};

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

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

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

    • SCS コンポーネントをインストールしたときに使用したのと同じユーザー名とパスワードを使用して 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 をスタンバイ状態から解除して、両方ともアクティブにします。

    # crm_standby -v off -N ${HOSTNAME};

SAP サービスを構成する

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

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

  1. 両方のサーバーで、/usr/sap/sapservices に SCS サービスと ERS サービスの両方のエントリが含まれていることを確認します。sapstartsrv commandpf=profile-of-the-sap-instance および -reg オプションで使用すると、不足しているエントリを追加できます。次に例を示します。

    # 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 \
     -reg
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ASCSscs-instance-number_scs-virtual-host-name \
     -reg

SAP サービスを停止する

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

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

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function GetSystemInstanceList"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function GetSystemInstanceList"

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

    18.05.2021 17:39:18
    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

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

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

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

    SID_ASCSscs-instance-number_scs-virtual-host-name
    SID_ERSers-instance-number_ers-virtual-host-name
  3. プロファイル ASCS と ERS インスタンス プロファイルに次の行を追加して、パッケージ sap-suse-cluster-connector を有効にします。

    #-----------------------------------------------------------------------
    # SUSE HA library
    #-----------------------------------------------------------------------
    service/halib = $(DIR_CT_RUN)/saphascriptco.so
    service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
  4. ENSA1 を使用している場合は、ASCS プロファイルで次の設定を行い、キープアライブ機能を有効にします。

    enque/encni/set_so_keepalive = true

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

  5. 必要に応じて、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) ...

sidadm ユーザーを haclient ユーザー グループに追加する

sap-suse-cluster-connector をインストールすると、haclient ユーザー グループが作成されました。sidadm ユーザーがクラスタで動作するようにするには、haclient ユーザー グループに追加します。

  1. 両方のサーバーで、次のように sidadm ユーザーを haclient ユーザー グループに追加します。

    # usermod -aG haclient sid-loweradm

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

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

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

    # crm status

    クラスタがメンテナンス モードの場合、ステータスには次の行が含まれます。

                  *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
  3. SCS サービスと ERS サービスのクラスタ リソースを作成します。

    ENSA1

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

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10
    • ERS インスタンスのクラスタ リソースを作成します。InstanceName の値は、ERS をインストールしたときに SWPM によって生成されるインスタンス プロファイルの名前です。パラメータ IS_ERS=true は、ERS がアクティブなノードで runsersSID フラグを 1 に設定するよう Pacemaker に指示します。

      # crm configure primitive ers-instance-rsc-name SAPInstance \
        operations \$id=ers-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSers-instance-number_ers-virtual-host-name  \
           START_PROFILE="/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name" \
           AUTOMATIC_RECOVER=false IS_ERS=true \
        meta priority=1000

    ENSA2

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

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60
    • ERS インスタンスのクラスタ リソースを作成します。InstanceName の値は、ERS をインストールしたときに SWPM によって生成されるインスタンス プロファイルの名前です。

      # crm configure primitive ers-instance-rsc-name SAPInstance \
        operations \$id=ers-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSers-instance-number_ers-virtual-host-name  \
           START_PROFILE="/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name" \
           AUTOMATIC_RECOVER=false IS_ERS=true

リソース グループとロケーションの制約を構成する

  1. SCS リソースと ERS リソースをグループ化します。以前に定義したすべてのリソースの名前を表示するには、crm resource status コマンドを入力します。

    # crm configure group scs-rsc-group-name scs-file-system-rsc-name \
      scs-health-check-rsc-name scs-vip-rsc-name \
      scs-instance-rsc-name \
      meta resource-stickiness=3000
    # crm configure group ers-rsc-group-name ers-file-system-rsc-name \
      ers-health-check-rsc-name ers-vip-rsc-name \
      ers-instance-rsc-name
  2. コロケーションの制約を作成します。

    ENSA1

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

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. フラグ runsersSID1 と等しい場合に、ERS が実行されているサーバーにフェイルオーバーするように SCS を構成します。

      # crm configure location loc-scs-SID-failover-to-ers scs-instance-rsc-name \
      rule 2000: runs_ers_SID eq 1
    3. ERS がフェイルオーバー後に他方のサーバーに移行する前に SCS が起動するように構成します。

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false

    ENSA2

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

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. ERS がフェイルオーバー後に他方のサーバーに移行する前に SCS が起動するように構成します。

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false
  3. メンテナンス モードを無効にします。

    # crm configure property maintenance-mode="false"
  4. グループの構成、コロケーションの制約、順序を確認します。

    # crm config show

    出力には、次の例のような行が含まれます。

    ENSA1

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name
    location fencing-rsc-nw-aha-vm-1-loc fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-rsc-nw-aha-vm-2-loc fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    location loc-sap-AHA-failover-to-ers scs-aha-instance-rsc-name \
            rule 2000: runs_ers_AHA eq 1

    ENSA2

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    location fencing-location-nw-aha-vm-1 fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-location-nw-aha-vm-2 fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    order ord-sap-AHA-first-start-ascs Optional: scs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name

クラスタをテストする

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

  • 構成エラーを確認する
  • フェイルオーバー中に SCS リソースと ERS リソースでサーバーを正しく切り替えることを確認する
  • ロックが保持されていることを確認する
  • メンテナンス イベントでフェイルオーバーがトリガーされないことを Compute Engine で確認する

SAP からクラスタ構成を確認する

  1. いずれかのサーバーの root として、サーバー上でアクティブになっているインスタンスを確認します。

    # crm status
  2. sidadm ユーザーに切り替えます。

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

    > sapcontrol -nr instance-number -function HAGetFailoverConfig

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

    20.05.2021 01:33:25
    HAGetFailoverConfig
    OK
    HAActive: TRUE
    HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2
    HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2)
    HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
    HAActiveNode: nw-ha-vm-1
    HANodes: nw-ha-vm-1, nw-ha-vm-2
  4. sidadm として、構成のエラーを確認します。

    > sapcontrol -nr instance-number -function HACheckConfig

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

    20.05.2021 01:37:19
    HACheckConfig
    OK
    state, category, description, comment
    SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
    SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java 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 (vh-scs-aha_AHA_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-scs-aha_AHA_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vh-scs-aha_AHA_00), Enqueue replication active
  5. いずれかのサーバーの root として、リソースが実行されているノードを確認します。

    # crm status

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

    # Cluster Summary:
      * Stack: corosync
      * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Thu May 20 16:58:46 2021
      * Last change:  Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2
      * 2 nodes configured
      * 10 resource instances configured
    
    Node List:
      * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Active Resources:
      * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
      * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
      * Resource Group: scs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
      * Resource Group: ers-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
        * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
        * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
        * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
  6. SCS がアクティブなサーバーで、sidadm としてフェイルオーバーをシミュレートします。

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

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

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

ENSA1

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

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 11 number-of-locks
  2. sidadm として、SCS がアクティブなサーバーで、ロックエントリが登録されていることを確認します。

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

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

    locks_now: 10
  3. sidadm として、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. SCS がアクティブな場合は、サーバーを再起動します。

    モニタリング サーバーで 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. sidadm として、ロックが保持されていることを確認したら、ロックを解除します。

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 12 number-of-locks
  8. sidadm として、SCS がアクティブなサーバーで、ロックエントリが削除されていることを確認します。

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

ENSA2

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

    > enq_admin --set_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  2. sidadm として、SCS がアクティブなサーバーで、ロックエントリが登録されていることを確認します。

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

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

    locks_now: 10
  3. SCS がアクティブな場合は、サーバーを再起動します。

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

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

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

    > enq_admin --release_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  7. sidadm として、SCS がアクティブなサーバーで、ロックエントリが削除されていることを確認します。

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

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

    locks_now: 0

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

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

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

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

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

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

    # crm status

トラブルシューティング

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

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

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

サポート

Google Cloud のインフラストラクチャやサービスに関する問題については、カスタマーケアにお問い合わせください。連絡先は、Google Cloud Console のサポートの概要ページで確認できます。カスタマーケアが 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 システムをバックアップすることをおすすめします。

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

次のステップ

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

+ Google Cloud 上での SAP NetWeaver 向け高可用性のプランニング ガイド + Google Cloud での SAP: 高可用性のホワイト ペーパー + VM の管理とモニタリングについては、SAP NetWeaver 運用ガイドをご覧ください。