このガイドでは、SAP NetWeaver システム用にパフォーマンスが最適化された Red Hat Enterprise Linux（RHEL）高可用性（HA）クラスタをデプロイして構成する方法について説明します。
このガイドでは、次の手順について説明します。- 障害発生時にトラフィックを再ルーティングするように内部パススルー ネットワーク ロードバランサを構成する。
- RHEL に Pacemaker クラスタを構成して、フェイルオーバー中に SAP システムやその他のリソースを管理する。
このガイドでは、SAP NetWeaver システムを HA 用に構成する手順についても説明します。具体的な手順については、SAP のドキュメントをご覧ください。
高可用性に固有ではない 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 にデプロイします。このガイドでは、基盤となるデータベースの高可用性インストールについては説明しません。
デプロイされたクラスタには、以下の機能が含まれます。
- 2 つのホスト VM。1 つは、アクティブな ASCS インスタンス用、もう一つは ENSA2 Enqueue Replicator または ENSA1 Enqueue Replication Server（ENSA1）用のアクティブ インスタンス用。ENSA2 インスタンスと ENSA1 インスタンスは、両方とも ERS と呼ばれます。
- Pacemaker 高可用性クラスタ リソース マネージャー。
- STONITH フェンシング メカニズム。
- 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動。
Terraform を使用して SAP NetWeaver HA システムのデプロイを自動化するには、Terraform: RHEL での SAP NetWeaver HA クラスタ構成ガイドをご覧ください。
前提条件
SAP NetWeaver 高可用性クラスタを作成する前に、次の前提条件を満たしていることを確認してください。
- SAP NetWeaver プランニング ガイドと Google Cloud での SAP NetWeaver 用高可用性のプランニング ガイドを読んでいる。
- 個人または組織で Google Cloud アカウントを所有していて、SAP NetWeaver をデプロイするプロジェクトを作成済みである。Google Cloud アカウントとプロジェクトの作成方法については、Linux 向け SAP NetWeaver デプロイガイドのプロジェクトの作成をご覧ください。
- データ所在地、アクセス制御、サポート担当者、規制要件に準拠しながら SAP ワークロードを実行する必要がある場合は、必要な Assured Workloads フォルダを作成する必要があります。詳細については、Google Cloud 上の SAP のコンプライアンスと主権管理をご覧ください。
VPC 内部 DNS を使用している場合は、プロジェクト メタデータの
vmDnsSetting変数の値をGlobalOnlyまたはZonalPreferredにして、ゾーン間でノード名を解決できるようにする。vmDnsSettingのデフォルト設定はZonalOnlyです。詳細については、次のトピックをご覧ください。NFS 共有ファイル ストレージ ソリューション（Filestore Enterprise など）を使用してファイル共有を設定している。
プロジェクト メタデータで OS Login が有効になっている場合は、デプロイが完了するまで一時的に OS Login を無効にする必要があります。デプロイのために、次の手順によりインスタンス メタデータで SSH 認証鍵を構成します。OS Login が有効になっている場合、メタデータ ベースの SSH 認証鍵構成は無効になり、このデプロイは失敗します。デプロイが完了したら、再度 OS Login を有効にできます。
詳細については、以下をご覧ください。
RHEL に関する関連情報
Google Cloud 環境で必要とされる場合を除き、このガイドの情報は Red Hat および SAP の以下の関連ガイドと同じです。
- Configure SAP NetWeaver ASCS/ERS ENSA1 with Standalone Resources in RHEL 7.5+ and RHEL 8
- Configure SAP S/4HANA ASCS/ERS with Standalone Enqueue Server 2 (ENSA2) in Pacemaker
- SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installation and Upgrade
- SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration
- SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installation and Configuration
- SAP Note 2641322 - Installation of ENSA2 and update from ENSA1 to ENSA2 when using the Red Hat HA solutions for SAP
ネットワークの作成
セキュリティ上の理由から、新しいネットワークを作成します。アクセスできるユーザーを制御するには、ファイアウォール ルールを追加するか、別のアクセス制御方法を使用します。
プロジェクトにデフォルトの VPC ネットワークがある場合、デフォルトは使用せず、明示的に作成したファイアウォール ルールが唯一の有効なルールとなるように、独自の VPC ネットワークを作成してください。
デプロイ中、VM インスタンスは通常、Google Cloud の SAP 用エージェントをダウンロードするためにインターネットにアクセスする必要があります。Google Cloud から入手できる SAP 認定の Linux イメージのいずれかを使用している場合も、ライセンスを登録して OS ベンダーのリポジトリにアクセスするために、VM インスタンスからインターネットにアクセスする必要があります。このアクセスをサポートするために、NAT ゲートウェイを配置し、VM ネットワーク タグを使用して構成します。ターゲット VM に外部 IP がない場合でもこの構成が可能です。
ネットワークを設定するには:
コンソール
- Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
- [VPC ネットワークを作成] をクリックします。
- ネットワークの名前を入力します。
命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。
- [サブネット作成モード] で [カスタム] をクリックします。
- [新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
- サブネットの名前を入力します。
- [リージョン] で、サブネットを作成する Compute Engine のリージョンを選択します。
- [IP スタックタイプ] で [IPv4（シングルスタック）] を選択し、CIDR 形式で IP アドレス範囲を入力します。（
10.1.0.0/24など）これはサブネットのプライマリ IPv4 範囲です。複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。
- [完了] をクリックします。
- さらにサブネットを追加するには、[サブネットを追加] をクリックして前の手順を繰り返します。ネットワークを作成した後で、ネットワークにさらにサブネットを追加できます。
- [作成] をクリックします。
gcloud
- Cloud Shell に移動します。
- カスタム サブネットワーク モードで新しいネットワークを作成するには、次のコマンドを実行します。
gcloud compute networks create NETWORK_NAME --subnet-mode custom
NETWORK_NAMEは、新しいネットワークの名前に置き換えます。命名規則に従って名前を付けてください。VPC ネットワークは、Compute Engine の命名規則を使用します。デフォルトの自動モードでは、各 Compute Engine リージョンにサブネットが自動的に作成されます。この自動モードを使用しないようにするには、
--subnet-mode customを指定します。詳しくは、サブネット作成モードをご覧ください。 - サブネットワークを作成し、リージョンと IP 範囲を指定します。
gcloud compute networks subnets create SUBNETWORK_NAME \ --network NETWORK_NAME --region REGION --range RANGE次のように置き換えます。
SUBNETWORK_NAME: 新しいサブネットワークの名前NETWORK_NAME: 前の手順で作成したサービスの名前REGION: サブネットワークを配置するリージョンRANGE: CIDR 形式で指定された IP アドレス範囲（例:10.1.0.0/24）。複数のサブネットワークを追加する場合は、ネットワーク内の各サブネットワークに重複しない CIDR IP 範囲を割り当ててください。各サブネットワークとその内部 IP 範囲は、単一のリージョンにマッピングされることに注意してください。
- 必要に応じて前の手順を繰り返し、サブネットワークを追加します。
NAT ゲートウェイの設定
パブリック IP アドレスなしで 1 台以上の VM を作成する必要がある場合は、ネットワーク アドレス変換（NAT）を使用して、VM がインターネットにアクセスできるようにする必要があります。Cloud NAT は Google Cloud の分散ソフトウェア定義マネージド サービスであり、VM からインターネットへのパケットの送信と、それに対応するパケットの受信を可能にします。また、別個の VM を NAT ゲートウェイとして設定することもできます。
プロジェクトに Cloud NAT インスタンスを作成する方法については、Cloud NAT の使用をご覧ください。
プロジェクトに Cloud NAT を構成すると、VM インスタンスはパブリック IP アドレスなしでインターネットに安全にアクセスできるようになります。
ファイアウォール ルールの追加
デフォルトでは、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 ヘルスチェック。詳細については、ヘルスチェック用のファイアウォール ルールを作成するをご覧ください。
ファイアウォール ルールを作成するには:
Google Cloud コンソールで、VPC ネットワークの [ファイアウォール] ページに移動します。
ページ上部の [ファイアウォール ルールを作成] をクリックします。
- [ネットワーク] フィールドで、VM が配置されているネットワークを選択します。
- [ターゲット] フィールドで、[ネットワーク上のすべてのインスタンス] を選択します。
- [ソースフィルタ] フィールドで、次のいずれかを選択します。
- 特定の IP アドレスからのトラフィックを許可する場合は、[IP 範囲] を選択します。[ソース IP の範囲] フィールドで IP アドレスの範囲を指定します。
- サブネット: 特定のサブネットワークからの受信トラフィックを許可する場合に使用します。次の [サブネット] フィールドにサブネットワーク名を指定します。このオプションを使用すると、3 層構成またはスケールアウト構成で VM 間のアクセスを許可できます。
- [プロトコルとポート] セクションで、[指定したプロトコルとポート] を選択して
tcp:PORT_NUMBER;を指定します。
[作成] をクリックしてファイアウォール ルールを作成します。
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 を使用していますが、Google Cloud CLI の場合も同様です。
Cloud Shell を開きます。
YAML 構成ファイルのテンプレート
template.yamlを作業ディレクトリにダウンロードします。wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml
必要に応じて
template.yamlのファイル名を変更し、このファイルで定義する構成がわかるようにします。例:nw-ha-rhel-8-4.yamlCloud Shell ターミナル ウィンドウの右上にある鉛筆アイコン（edit）をクリックし、エディタを起動することで、Cloud Shell コードエディタで YAML 構成ファイルを開きます。
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/network1linuxImage文字列 SAP NetWeaver で使用する Linux オペレーティング システムのイメージまたはイメージ ファミリーの名前。イメージ ファミリーを指定するには、ファミリー名に接頭辞 family/を追加します。例:family/rhel-8-4-sap-ha利用可能なイメージ ファミリーの一覧については、Google Cloud コンソールの [イメージ] ページをご覧ください。linuxImageProject文字列 使用するイメージを含む Google Cloud プロジェクト。このプロジェクトは独自のプロジェクトか、Google Cloud イメージ プロジェクト rhel-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.compublicIPブール値 省略可。パブリック IP アドレスを VM インスタンスに追加するかどうかを指定します。デフォルトは Yesです。sap_deployment_debugブール値 省略可。この値が Yesに設定されている場合、デプロイの際に詳細なログが生成されます。Google のサポート エンジニアからデバッグを有効にするように求められない限り、この設定はオンにしないでください。YAML 構成ファイルで、1 番目の VM の定義をコピーし、それを 1 番目の定義の後に貼り付けて、2 番目の VM の定義を作成します。例については、完全な YAML 構成ファイルの例をご覧ください。
2 番目の VM の定義では、次のプロパティについて、最初の定義で指定したものとは異なる値を指定します。
nameinstanceNamezone
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_1 と sap_nw_node_2）の定義が含まれています。各リソース定義には VM の定義が含まれています。
sap_nw_node_2 リソース定義は、最初の定義をコピーして貼り付け、name、instanceName、zone の各プロパティの値を変更することによって作成されました。2 つのリソース定義のその他のプロパティ値はすべて同じです。
プロパティ networkTag と serviceAccount は、構成ファイル テンプレートの [詳細オプション] セクションにあります。
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/rhel-8-4-sap-ha
linuxImageProject: rhel-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/rhel-8-4-sap-ha
linuxImageProject: rhel-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 が正しくデプロイされていることを確認します。
ログを調べる
Google Cloud コンソールで Cloud Logging を開き、インストールの進行状況をモニタリングして、エラーを確認します。
ログをフィルタします。
ログ エクスプローラ
[ログ エクスプローラ] ページで、[クエリ] ペインに移動します。
[リソース] プルダウン メニューから [グローバル] を選択し、[追加] をクリックします。
[グローバル] オプションが表示されない場合は、クエリエディタに次のクエリを入力します。
resource.type="global" "Deployment"[クエリを実行] をクリックします。
以前のログビューア
- [以前のログビューア] ページの基本的なセレクタ メニューから、ロギング リソースとして [グローバル] を選択します。
フィルタされたログを分析します。
"--- Finished"が表示されている場合、デプロイメントは完了しています。次の手順に進んでください。割り当てエラーが発生した場合:
[IAM と管理] の [割り当て] ページで、SAP NetWeaver プランニング ガイドに記載されている SAP NetWeaver の要件を満たしていない割り当てを増やします。
Deployment Manager の [デプロイ] ページでデプロイメントを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。
デプロイを再実行します。
VM の構成を確認する
VM インスタンスがデプロイされたら、
sshを使用して VM に接続します。- まだ作成していない場合は、ファイアウォール ルールを作成して、ポート
22で SSH 接続が許可されるようにします。 [VM インスタンス] ページに移動します。
各 VM インスタンスのエントリで [SSH] ボタンをクリックして各 VM インスタンスに接続するか、任意の SSH メソッドを使用します。
- まだ作成していない場合は、ファイアウォール ルールを作成して、ポート
ファイル システムを表示します。
~>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スワップ領域が作成されたことを確認します。
~>cat /proc/meminfo | grep Swap次の例のような結果が表示されます。
SwapCached: 0 kB SwapTotal: 25161724 kB SwapFree: 25161724 kB
確認ステップの途中でインストールに失敗したことが示された場合、次の手順を行います。
- エラーを修正します。
- [デプロイ] ページでデプロイメントを削除し、失敗したインストールから VM と永続ディスクをクリーンアップします。
- デプロイを再実行します。
VM 間でのロードバランサのバックエンド通信を有効にする
VM が正常にデプロイされたことを確認したら、HA クラスタ内のノードとして機能する VM 間のバックエンド通信を有効にします。
VM 間のバックエンド通信を有効にするには、Google Cloud で提供されているすべての Linux 公開イメージの Linux ゲスト環境に含まれる google-guest-agent の構成を変更します。
ロードバランサのバックエンド通信を有効にするには、クラスタの一部である各 VM で次の手順を行います。
エージェントを停止します。
sudo service google-guest-agent stop
編集用に
/etc/default/instance_configs.cfgファイルを開くか、作成します。次に例を示します。sudo vi /etc/default/instance_configs.cfg
以下のように、
/etc/default/instance_configs.cfgファイルで次の構成プロパティを指定します。セクションが存在しない場合は作成します。特に、target_instance_ipsとip_forwardingの両方のプロパティがfalseに設定されていることを確認します。[IpForwarding] ethernet_proto_id = 66 ip_aliases = true target_instance_ips = false [NetworkInterfaces] dhclient_script = /sbin/google-dhclient-script dhcp_command = ip_forwarding = false setup = true
ゲスト エージェント サービスを開始します。
sudo service google-guest-agent start
ロードバランサのヘルスチェック構成では、ヘルスチェック用のリスニング ターゲット ポートとインターフェースへの仮想 IP の割り振りの両方が必要です。詳細については、ロードバランサの構成をテストするをご覧ください。
プライマリ VM とセカンダリ VM で SSH 認証鍵を構成する
HA クラスタ内のホスト間でファイルをコピーできるようにするために、このセクションの手順で、2 つのホスト間の root SSH 接続を作成します。
Google Cloud が提供する Deployment Manager テンプレートによりキーが生成されますが、自身でキーを生成してこれを置き換えることもできます。
組織には、内部ネットワーク通信を管理するガイドラインがある場合があります。必要に応じて、デプロイの完了後に VM からメタデータを削除し、authorized_keys ディレクトリから鍵を削除します。
直接 SSH 接続の設定が組織のガイドラインを遵守していない場合は、次のような別の方法でファイルを転送できます。
- Cloud Shell の [ファイルをアップロード] と [ファイルをダウンロード] のメニュー オプションを使用して、ローカル ワークステーションから小さいファイルを転送します。Cloud Shell を使用したファイルの管理をご覧ください。
- Cloud Storage バケットを使用してファイルを交換します。アップロードとダウンロードをご覧ください。
- Filestore や NetApp Cloud Volumes Service などのファイル ストレージ ソリューションを使用して、共有フォルダを作成します。ファイル共有ソリューションをご覧ください。
プライマリ インスタンスとセカンダリ インスタンス間の SSH 接続を有効にする手順は次のとおりです。この手順では、SAP 用の Deployment Manager テンプレートによって生成された SSH 認証鍵を使用していることを前提としています。
プライマリ ホスト VM で、次のようにします。
SSH 経由で VM に接続します。
root に切り替えます。
$sudo su -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
プライマリ VM のメタデータを、セカンダリ VM の SSH 認証鍵に関する情報で更新します。
#gcloud compute instances add-metadata SECONDARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone SECONDARY_VM_ZONEプライマリ システムからセカンダリ システムへの SSH 接続を開き、SSH 認証鍵が正しく設定されていることを確認します。
#ssh SECONDARY_VM_NAME
セカンダリ ホスト VM で、次のようにします。
VM に SSH 接続します。
root に切り替えます。
$sudo su -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
セカンダリ VM のメタデータを、プライマリ VM の SSH 認証鍵に関する情報で更新します。
#gcloud compute instances add-metadata PRIMARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone PRIMARY_VM_ZONE#cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keysセカンダリ システムからプライマリ システムへの SSH 接続を開き、SSH 認証鍵が正しく設定されていることを確認します。
#ssh PRIMARY_VM_NAME
共有ファイル ストレージを設定し、共有ディレクトリを構成する
HA クラスタの両方のノードがアクセスできる、可用性の高い共有ファイル ストレージを提供する NFS ファイル共有ソリューションを設定する必要があります。その後、共有ファイル ストレージにマッピングする両方のノードにディレクトリを作成します。クラスタ ソフトウェアにより、適切なインスタンスにのみ適切なディレクトリがマウントされます。
このガイドでは、ファイル共有ソリューションの設定方法については説明しません。ファイル共有システムの設定手順については、ソリューションのベンダーが提供する手順をご覧ください。ファイル共有ソリューションに Filestore を使用する場合は、Filestore の Enterprise ティアを使用することをおすすめします。Filestore インスタンスの作成方法については、インスタンスの作成をご覧ください。
Google Cloud で利用可能なファイル共有ソリューションについては、Google Cloud での HA SAP システムの共有ストレージ オプションをご覧ください。
共有ディレクトリを構成するには:
高可用性 NFS 共有ファイル ストレージ ソリューションをまだ設定していない場合は、ここで設定します。
初期構成のために、NFS 共有ストレージを両方のサーバーにマウントします。
~>sudo mkdir /mnt/nfs~>sudo mount -t nfs NFS_PATH /mnt/nfsNFS_PATHは、NFS ファイル共有ソリューションのパスに置き換えます。例:10.49.153.26:/nfs_share_nw_haどちらかのサーバーから
sapmntのディレクトリ、セントラル トランスポート ディレクトリ、システム ディレクトリ、インスタンス固有のディレクトリを作成します。Java スタックを使用している場合、以下のコマンド、およびその他のコマンドの例を使用する前に、「ASCS」を「SCS」に置き換えてください。~>sudo mkdir /mnt/nfs/sapmntSID~>sudo mkdir /mnt/nfs/usrsap{trans,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}Simple Mount 設定を使用している場合は、代わりに次のコマンドを実行します。
~>sudo mkdir /mnt/nfs/sapmntSID~>sudo mkdir /mnt/nfs/usrsap{trans,SID}次のように置き換えます。
SID: SAP システム ID（SID）。文字には大文字を使用します。例:AHAASCS_INSTANCE_NUMBER: ASCS システムのインスタンス番号。例:00ERS_INSTANCE_NUMBER: ERS システムのインスタンス番号。例:10
両方のサーバーで、必要なマウント ポイントを作成します。
~>sudo mkdir -p /sapmnt/SID~>sudo mkdir -p /usr/sap/trans~>sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER~>sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBERSimple Mount 設定を使用している場合は、代わりに次のコマンドを実行します。
~>sudo mkdir -p /sapmnt/SID~>sudo mkdir -p /usr/sap/trans~>sudo mkdir -p /usr/sap/SIDファイル ディレクトリへの最初のアクセス時に、共通の共有ファイル ディレクトリをマウントするように
autofsを構成します。ASCSASCS_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.sapautofsの詳細については、autofs - 仕組みをご覧ください。Simple Mount 設定を使用している場合は、代わりに次のコマンドを実行します。
~>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}/sapmnt" | sudo tee -a /etc/auto.sap~>echo "/usr/sap/trans ${NFS_OPTS}/usrsaptrans" | sudo tee -a /etc/auto.sap~>echo "/usr/sap/SID ${NFS_OPTS}/usrsapSID" | sudo tee -a /etc/auto.sap両方のサーバーで
autofsサービスを起動します。~>sudo systemctl enable autofs~>sudo systemctl restart autofs~>sudo automount -vcdコマンドを使用して各ディレクトリにアクセスし、autofsをトリガーして共有ディレクトリをマウントします。例:~>cd /sapmnt/SID~>cd /usr/sap/transSimple Mount 設定を使用している場合は、代わりに次のコマンドを実行します。
~>cd /sapmnt/SID~>cd /usr/sap/trans~>cd /usr/sap/SIDすべてのディレクトリにアクセスしたら、
df -Thコマンドを実行して、ディレクトリがマウントされていることを確認します。~>df -Th | grep FILE_SHARE_NAMEFILE_SHARE_NAMEは、NFS ファイル共有ソリューションの名前に置き換えます。例:nfs_share_nw_ha次のようなマウント ポイントとディレクトリが表示されます。
10.49.153.26:/nfs_share_nw_ha nfs 1007G 76M 956G 1% /mnt/nfs 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
Simple Mount 設定を使用している場合、次のようなマウント ポイントとディレクトリが表示されます。
10.49.153.26:/nfs_share_nw_ha nfs 1007G 76M 956G 1% /mnt/nfs 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 10.49.153.26:/nfs_share_nw_ha/usrsapAHA nfs 1007G 76M 956G 1% /usr/sap/AHA
Cloud Load Balancing のフェイルオーバー サポートを構成する
フェイルオーバーをサポートする内部パススルー ネットワーク ロードバランサ サービスは、ASCS トラフィックと ERS トラフィックを各 SAP NetWeaver クラスタ内のアクティブなインスタンスに転送します。内部パススルー ネットワーク ロードバランサは、仮想 IP（VIP）アドレス、バックエンド サービス、インスタンス グループ、ヘルスチェックを使用してトラフィックを適切にルーティングします。
仮想 IP の IP アドレスを予約する
SAP NetWeaver の高可用性クラスタの場合は、2 つの VIP を作成します。これは、フローティング IP アドレスと呼ばれることもあります。1 つの VIP は、アクティブな SAP セントラル サービス（SCS）インスタンスをフォローし、もう 1 つの VIP はエンキュー レプリケーション サーバー（ERS）インスタンスをフォローします。ロードバランサは、各 VIP に送信されるトラフィックを、VIP の ASCS または ERS コンポーネントのアクティブ インスタンスを現在ホストしている VM にルーティングします。
Cloud Shell を開きます。
ASCS の仮想 IP と ERS の VIP 用に IP アドレスを予約します。ASCS の場合、この IP アドレスはアプリケーションが SAP NetWeaver へのアクセスに使用する IP アドレスです。ERS の場合、この IP アドレスはエンキュー サーバー レプリケーションに使用される IP アドレスです。
--addressesフラグを省略すると、指定したサブネット内の IP アドレスが自動的に選択されます。~gcloud compute addresses create ASCS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ASCS_VIP_ADDRESS~gcloud compute addresses create ERS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ERS_VIP_ADDRESS次のように置き換えます。
ASCS_VIP_NAME: ASCS インスタンスの仮想 IP アドレスの名前を指定します。例:ascs-aha-vipCLUSTER_REGION: クラスタが配置されている Google Cloud リージョンを指定します。例:us-central1CLUSTER_SUBNET: クラスタで使用するサブネットワークを指定します。例:example-sub-network-sapASCS_VIP_ADDRESS: 必要に応じて、ASCS 仮想 IP の IP アドレスを CIDR 表記で指定します。例:10.1.0.2ERS_VIP_NAME: ERS インスタンスの仮想 IP アドレスの名前を指定します。例:ers-aha-vipERS_VIP_ADDRESS: 必要に応じて、ERS 仮想 IP の IP アドレスを CIDR 表記で指定します。例:10.1.0.4
静的 IP の予約の詳細については、静的内部 IP アドレスの予約をご覧ください。
IP アドレスの予約を確認します。
~gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGION出力は次の例のようになります。
address: 10.1.0.2 addressType: INTERNAL creationTimestamp: '2022-04-04T15:04:25.872-07:00' description: '' id: '555067171183973766' kind: compute#address name: ascs-aha-vip 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/ascs-aha-vip 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 ファイルの更新は次の例のようになります。
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2 10.1.0.2 ascs-aha-vip 10.1.0.4 ers-aha-vip 10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1 # Added by Google 169.254.169.254 metadata.google.internal # Added by Google
Cloud Load Balancing ヘルスチェックを作成する
ヘルスチェックを作成します。1 つはアクティブな ASCS インスタンス用で、もう 1 つはアクティブな ERS 用です。
Cloud Shell で、ヘルスチェックを作成します。他のサービスと競合しないようにするには、プライベート範囲の ASCS インスタンスと ERS インスタンスのポート番号 49152～65535 を指定します。次のコマンド内のチェック間隔とタイムアウトの値は、Compute Engine のライブ マイグレーション イベント中のフェイルオーバーの許容範囲を広げるために、デフォルトよりも少し長くなっています。必要に応じて値を調整できます。
~gcloud compute health-checks create tcp ASCS_HEALTH_CHECK_NAME \ --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \ --unhealthy-threshold=2 --healthy-threshold=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
各ヘルスチェックが作成されたことを確認します。
~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: ascs-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/16 と 130.211.0.0/22）からホスト VM へのアクセスを許可します。ロードバランサのファイアウォール ルールの詳細については、ヘルスチェック用のファイアウォール ルールの作成をご覧ください。
ホスト VM にネットワーク タグを追加します（まだ設定されていない場合）。このタグは、ファイアウォール ルールのヘルスチェックで使用されます。
~gcloud compute instances add-tags PRIMARY_VM_NAME \ --zone=PRIMARY_ZONE \ --tags NETWORK_TAGS~gcloud compute instances add-tags SECONDARY_VM_NAME \ --zone=SECONDARY_ZONE \ --tags NETWORK_TAGS
ネットワーク タグを使用してヘルスチェックを許可するファイアウォール ルールを作成します。
~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:ASCS_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 をインスタンス グループに追加する必要があります。
Cloud Shell で、プライマリ インスタンス グループを作成し、そこにプライマリ VM を追加します。
~gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE~gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE \ --instances=PRIMARY_VM_NAME
Cloud Shell で、セカンダリ インスタンス グループを作成し、そこにセカンダリ VM を追加します。
~gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE~gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE \ --instances=SECONDARY_VM_NAME
インスタンス グループが作成されたことを確認します。
~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
バックエンド サービスを構成する
ASCS 用と ERS 用の 2 つのバックエンド サービスを作成します。両方のインスタンス グループを各バックエンド サービスに追加し、対になるインスタンス グループをそれぞれのバックエンド サービスのフェイルオーバー インスタンス グループとして指定します。最後に、VIP からバックエンド サービスへの転送ルールを作成します。
Cloud Shell で、ASCS のバックエンド サービスとフェイルオーバー グループを作成します。
ASCS のバックエンド サービスを作成します。
~gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks ASCS_HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksプライマリ インスタンス グループを ASCS バックエンド サービスに追加します。
~gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --region CLUSTER_REGIONセカンダリ インスタンス グループを ASCS バックエンド サービスのフェイルオーバー インスタンス グループとして追加します。
~gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --failover \ --region CLUSTER_REGION
Cloud Shell で、ERS のバックエンド サービスとフェイルオーバー グループを作成します。
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セカンダリ インスタンス グループを ERS バックエンド サービスに追加します。
~gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --region CLUSTER_REGIONプライマリ インスタンス グループを ERS バックエンド サービスのフェイルオーバー インスタンス グループとして追加します。
~gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --failover \ --region CLUSTER_REGION
必要に応じて、バックエンド サービスに想定通りにインスタンス グループが含まれていることを確認します。
~gcloud compute backend-services describe BACKEND_SERVICE_NAME \ --region=CLUSTER_REGIONASCS バックエンド サービスの場合、次の例のような出力が表示されます。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: '2022-04-06T10:58:37.744-07:00' description: '' failoverPolicy: disableConnectionDrainOnFailover: true dropTrafficIfUnhealthy: true failoverRatio: 1.0 fingerprint: s4qMEAyhrV0= healthChecks: - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name id: '6695034709671438882' kind: compute#backendService loadBalancingScheme: INTERNAL name: ascs-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/ascs-aha-backend-service-name sessionAffinity: NONE timeoutSec: 30
Cloud Shell で、ASCS および ERS バックエンド サービスの転送ルールを作成します。
ASCS VIP から ASCS バックエンド サービスへの転送ルールを作成します。
~gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \ --load-balancing-scheme internal \ --address ASCS_VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service ASCS_BACKEND_SERVICE_NAME \ --ports ALLERS 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 ユーティリティを使用して、ヘルスチェック ポートを一時的にリッスンできます。
両方のホスト VM に
socatユーティリティをインストールします。$sudo yum install socatプライマリ VM で、一時的に eth0 ネットワーク カードに VIP を割り振ります。
ip addr add VIP_ADDRESS dev eth0
プライマリ VM で、
socatプロセスを開始して、ASCS ヘルスチェック ポートで 60 秒間リッスンします。$timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,forkCloud Shell で、ヘルスチェックがリスナーを検出するまで数秒待ってから、ASCS バックエンド インスタンス グループのヘルスチェックを行います。
~gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONASCS の場合、次のような出力が表示されます。
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#backendServiceGroupHealtheth0 インターフェースから VIP を削除します。
ip addr del VIP_ADDRESS dev eth0
ASCS の変数値を ERS の値に置き換えて、ERS の手順を繰り返します。
ポート 22 を使用してロードバランサをテストする
ホスト VM で SSH 接続用にポート 22 が開いている場合、ヘルス チェッカーに応答できるリスナーを備えたポート 22 を使用するように、ヘルス チェッカーを一時的に編集できます。
ポート 22 を一時的に使用するには、次の手順を行います。
Google Cloud コンソールで、Compute Engine の [ヘルスチェック] ページに移動します。
ヘルスチェックの名前をクリックします。
[編集] をクリックします。
[ポート] 項目で、ポート番号を 22 に変更します。
[保存] をクリックし、1～2 分待ちます。
Cloud Shell で、ヘルスチェックがリスナーを検出するまで数秒待ってから、バックエンド インスタンス グループのヘルスチェックを行います。
~gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGION出力は次のようになります。
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-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完了したら、ヘルスチェックのポート番号を元のポート番号に戻します。
ヘルスチェック用のリスナーをインストールする
ヘルスチェック リソースを構成するには、まずリスナーをインストールする必要があります。
ロードバランサは、各ホストのヘルスチェック ポートでリスナーを使用して、SAP HANA クラスタのプライマリ インスタンスが実行されている場所を判断します。
次の手順で、クラスタ内の各ホストにリスナーをインストールします。
root として、シンプルな TCP リスナーをインストールします。以下の手順では、HAProxy をインストールしてリスナーとして使用します。
#yum install haproxyデフォルトの
haproxy.cfg構成ファイルをコピーして名前を変更し、複数の haproxy インスタンスのテンプレート ファイルとして使用します。#cp /usr/lib/systemd/system/haproxy.service \ /etc/systemd/system/haproxy@.service次の例に示すように、
haproxy@.serviceファイルの[Unit]セクションと[Service]セクションを編集して、%iインスタンス パラメータを含めます。[Unit] Description=HAProxy Load Balancer %i After=network-online.target Wants=network-online.target [Service] Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid" ...
Red Hat の
systemdユニット テンプレートの詳細については、インスタンス化されたユニットの操作をご覧ください。ASCS インスタンスの
haproxy.cfg構成ファイルを作成します。次に例を示します。#vi /etc/haproxy/haproxy-SIDscs.cfgSIDは、SAP システム ID（SID）に置き換えます。文字には大文字を使用します。例:AHAhaproxy-SIDscs.cfgASCS 構成ファイルで次の構成を挿入します。ASCS_HEALTHCHECK_PORT_NUMは、以前に ASCS の Compute Engine ヘルスチェックの作成時に指定したポート番号に置き換えます。global chroot /var/lib/haproxy pidfile /var/run/haproxy-%i.pid user haproxy group haproxy daemon defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 3000 # Listener for SAP healthcheck listen healthcheck bind *:ASCS_HEALTHCHECK_PORT_NUMERS インスタンスの
haproxy.cfg構成ファイルを作成します。次に例を示します。#vi /etc/haproxy/haproxy-SIDers.cfghaproxy-SIDers.cfgERS 構成ファイルで、次の構成を挿入します。ERS_HEALTHCHECK_PORT_NUMは、以前に ERS の Compute Engine ヘルスチェックを作成したときに指定したポート番号に置き換えます。global chroot /var/lib/haproxy pidfile /var/run/haproxy-%i.pid user haproxy group haproxy daemon defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 3000 # Listener for SAP healthcheck listen healthcheck bind *:ERS_HEALTHCHECK_PORT_NUMsystemdサービスを再読み込みします。#systemctl daemon-reloadhaproxy サービスが正しく設定されていることを確認します。
#systemctl start haproxy#systemctl status haproxy#systemctl | grep haproxy返されたステータスには、
haproxy.serviceがactive (running)と表示されます。● haproxy.service - HAProxy Load Balancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago Main PID: 1079 (haproxy) Tasks: 2 (limit: 100996) Memory: 5.1M CGroup: /system.slice/haproxy.service ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer... Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.クラスタ内の各ホストで上記の手順を繰り返します。
Pacemaker を設定する
次の手順では、SAP NetWeaver の Compute Engine VM に Pacemaker クラスタの RHEL 実装を構成します。
この手順は、次のパブリケーションを含む高可用性クラスタを構成するための Red Hat のドキュメントに基づいています（Red Hat サブスクリプションが必要です）。
- Configuring SAP NetWeaver ASCS/ERS ENSA1 with Standalone Resources in RHEL 7.5+ and RHEL 8
- Configuring SAP S/4HANA ASCS/ERS with Standalone Enqueue Server 2 (ENSA2) in Pacemaker
RHEL のインストールと構成に関する SAP の詳細情報については、以下をご覧ください。
- SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installation and Configuration
- SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration
- SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installation and Upgrade
両方のクラスタに必要なクラスタ パッケージと OS ファイアウォールを構成する
プライマリ ホストとセカンダリ ホストの両方で、root として、必要なクラスタ パッケージをインストールして更新します。さらに、hacluster を構成して、OS ファイアウォール サービスを構成します。
必要な次のクラスタ パッケージをインストールします。
#yum install pcs pacemaker#yum install fence-agents-gce#yum install resource-agents-gcp#yum install resource-agents-sap#yum install sap-cluster-connectorインストール済みのパッケージを更新します。
#yum update -yクラスタ パッケージの一部としてインストールされる
haclusterユーザーのパスワードを設定します。#passwd haclusterプロンプトで、
haclusterのパスワードを指定します。Google Cloud が提供する RHEL イメージでは、OS ファイアウォール サービスがデフォルトで有効になっています。高可用性トラフィックを許可するようにファイアウォール サービスを構成します。
#firewall-cmd --permanent --add-service=high-availability#firewall-cmd --reloadpcs サービスを起動し、起動時に有効化するように構成します。
#systemctl start pcsd.service#systemctl enable pcsd.servicepcs サービスのステータスを確認します。
#systemctl status pcsd.service出力は次のようになります。
● pcsd.service - PCS GUI and remote configuration interface Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago Docs: man:pcsd(8) man:pcs(8) Main PID: 31627 (pcsd) CGroup: /system.slice/pcsd.service └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface... Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
クラスタを作成する
いずれかのノードの root として、
haclusterユーザーを承認します。RHEL バージョンのタブをクリックすると、コマンドが表示されます。RHEL 8 以降
#pcs host auth PRIMARY_VM_NAME SECONDARY_VM_NAMERHEL 7
#pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAMEプロンプトで、
haclusterユーザーに設定したhaclusterユーザー名とパスワードを入力します。クラスタを作成します。
RHEL 8 以降
#pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAMERHEL 7
#pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME
Corosync 構成ファイルを更新する
次の手順では、Corosync に推奨されるクラスタ値を設定します。Corosync 構成ファイル /etc/corosync/corosync.conf がまだ存在しないか、空の場合は、構成のベースとして /etc/corosync/ ディレクトリにあるサンプル ファイルを使用できます。
編集する
corosync.confファイルを開きます。#vi /etc/corosync/corosync.confcorosync.confファイルのtotemセクションで、次の例に示すパラメータを、表示される値に設定します。一部のパラメータには、すでに正しい値が設定されている場合があります。RHEL 8
totem { ... transport: knet token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 ... }RHEL 7
totem { ... transport: udpu token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 ... }構成を 2 つ目のサーバーに同期します。
RHEL 8 以降
#pcs cluster sync corosyncRHEL 7
#pcs cluster syncプライマリ VM でクラスタを有効にして起動する
#pcs cluster enable --all#pcs cluster start --allcorosync-cmapctl ユーティリティを使用して、クラスタで新しい corosync 設定が有効なことを確認します。
#corosync-cmapctlクラスタのステータスを確認します。
#pcs status出力は次の例のようになります。
Cluster name: nwha WARNINGS: No stonith devices and stonith-enabled is not false Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 0 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * No resources Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
インフラストラクチャのクラスタ リソースを構成する
次のクラスタ インフラストラクチャに Pacemaker リソースを定義する必要があります。
- フェンシング デバイス（スプリット ブレイン シナリオを回避する）
- 共有ファイル システム内の ASCS ディレクトリと ERS ディレクトリ
- ヘルスチェック
- VIP
- ASCS コンポーネントと ERS コンポーネント
まず、フェンシング デバイス、共有ファイル システム、ヘルスチェック、VIP のリソースを定義します。次に、SAP NetWeaver をインストールします。SAP NetWeaver をインストールしたら、最後に ASCS コンポーネントと ERS コンポーネントのクラスタ リソースを定義します。
フェンスを設定する
フェンスを設定するには、各ホスト VM で fence_gce エージェントを使用してクラスタ リソースを定義します。
フェンシング アクションの後に適切なイベントのシーケンスを保証するには、VM のフェンス後に Corosync が再起動するようにオペレーティング システムも構成します。また、遅延を考慮して、再起動の Pacemaker タイムアウトも調整します。
フェンシング デバイス リソースを作成する
クラスタ内の VM ごとに、クラスタが VM を再起動できるように、フェンシング デバイスのクラスタ リソースを作成します。VM のフェンシング デバイスは別の VM で実行する必要があるため、再起動可能な VM 以外の VM で実行されるようにクラスタ リソースのロケーションを構成します。
プライマリ ホストで、root としてプライマリ VM のフェンシング デバイス用のクラスタ リソースを作成します。
#pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \ port="PRIMARY_VM_NAME" \ zone="PRIMARY_ZONE" \ project="CLUSTER_PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"セカンダリ VM でのみアクティブになるように、プライマリ VM のフェンシング デバイスの場所を構成します。
#pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAMEセカンダリ ホストで、root としてセカンダリ VM のフェンシング デバイス用のクラスタ リソースを作成します。
#pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \ port="SECONDARY_VM_NAME" \ zone="SECONDARY_ZONE" \ project="CLUSTER_PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"プライマリ VM でのみアクティブになるように、セカンダリ VM のフェンシング デバイスの場所を構成します。
#pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME
Corosync の再起動の遅延を設定する
両方のホストで、root として Corosync の起動を遅延させる
systemdドロップイン ファイルを作成し、フェンス付き VM の再起動後に適切な一連のイベントが行われるようにします。systemctl edit corosync.service
このファイルに次の行を追加します。
[Service] ExecStartPre=/bin/sleep 60
ファイルを保存し、エディタを終了します。
systemd マネージャー構成を再読み込みします。
systemctl daemon-reload
ドロップイン ファイルが作成されていることを確認します。
service corosync status
次の例に示すように、ドロップイン ファイルの行が表示されます。
● corosync.service - Corosync Cluster Engine Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/corosync.service.d └─override.conf Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago
ファイル システム リソースを作成する
共有ファイル システムで ASCS ディレクトリと ERS ディレクトリのクラスタ リソースを定義します。
ASCS ディレクトリのファイル システム リソースを構成します。
#pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \ fstype=nfs force_unmount=safe \ --group ASCS_RESOURCE_GROUP \ op start interval=0 timeout=60 \ op stop interval=0 timeout=120 \ op monitor interval=200 timeout=40次のように置き換えます。
ASCS_FILE_SYSTEM_RESOURCE: ASCS ファイル システムのクラスタ リソースの名前を指定します。NFS_PATH: NFS ファイル システムのディレクトリ パスを指定します。SID: システム ID（SID）を指定します。文字には大文字を使用します。ASCS_INSTANCE_NUMBER: ASCS インスタンス番号を指定します。ASCS_RESOURCE_GROUP: ASCS クラスタ リソースの一意のグループ名を指定します。「SID_ASCSinstance_number_group」のような規則を使用することで、一意性を確保できます。例:nw8_ASCS00_groupグループがまだ存在しないため、Pacemaker がグループを作成します。他の ASCS リソースを作成する場合は、このグループに追加します。
ERS ディレクトリのファイル システム リソースを構成します。
#pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \ fstype=nfs force_unmount=safe \ --group ERS_RESOURCE_GROUP \ op start interval=0 timeout=60 \ op stop interval=0 timeout=120 \ op monitor interval=200 timeout=40次のように置き換えます。
ERS_FILE_SYSTEM_RESOURCE: ファイル システム リソースの名前を指定します。NFS_PATH: NFS ファイル システムのディレクトリ パスを指定します。SID: システム ID（SID）を指定します。文字には大文字を使用します。ERS_INSTANCE_NUMBER: ERS インスタンス番号を指定します。ERS_RESOURCE_GROUP: ERS クラスタ リソースの一意のグループ名を指定します。「SID_ERSinstance_number_group」のような規則を使用することで、一意性を確保できます。例:nw8_ERS10_groupグループがまだ存在しないため、Pacemaker がグループを作成します。他の ERS リソースを作成する場合は、このグループに追加します。
仮想 IP アドレス リソースを作成する
VIP アドレスのクラスタ リソースを定義します。
VIP アドレスを検索する必要がある場合は、以下のコードを使用します。
gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
ASCS VIP と ERS VIP のクラスタ リソースを作成します。
#pcs resource create ASCS_VIP_RESOURCE IPaddr2 \ ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600 timeout=60 \ --group ASCS_RESOURCE_GROUP#pcs resource create ERS_VIP_RESOURCE IPaddr2 \ ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600 timeout=60 \ --group ERS_RESOURCE_GROUP
ヘルスチェック リソースを作成する
ASCS ヘルスチェックのクラスタ リソースを構成します。
#pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \ op monitor interval=10s timeout=20s \ --group ASCS_RESOURCE_GROUPERS ヘルスチェックのクラスタ リソースを構成します。
#pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \ op monitor interval=10s timeout=20s \ --group ERS_RESOURCE_GROUP
追加クラスタのデフォルトを設定する
追加のクラスタ プロパティを設定します。
#pcs resource defaults resource-stickiness=1#pcs resource defaults migration-threshold=3
定義済みのリソースを表示する
これまでに定義したクラスタ リソースを表示して、リソースが正しいことを確認します。
クラスタのステータスを表示します。
#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): Started nw-ha-vm-2 * 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-2 * nw8_healthcheck_ers (service:haproxy@nw8ers): Started nw-ha-vm-2 * nw8_fs_ers10 (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
ASCS と ERS をインストールする
次のセクションでは、Google Cloud 上での SAP NetWeaver のインストールに固有の要件と推奨事項のみについて説明します。
インストール手順の詳細については、SAP NetWeaver のドキュメントをご覧ください。
インストールを準備する
クラスタ全体の整合性を確保し、インストールを簡素化するため、SAP NetWeaver ASCS と ERS コンポーネントをインストールする前に、ユーザー、グループ、権限を定義して、セカンダリ サーバーをスタンバイ モードにします。
クラスタのメンテナンス モードを終了します。
#sudo pcs property set maintenance-mode="false"両方のサーバーで、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 -RSimple Mount 設定を使用している場合は、代わりに、両方のサーバーで 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#chown SID_LCadm:sapsys /sapmnt/SID -R#chown SID_LCadm:sapsys /usr/sap/trans -R#chown SID_LCadm:sapsys /usr/sap/SID -R#chown SID_LCadm:sapsys /usr/sap/SID/SYS次のように置き換えます。
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 コンポーネントをインストールする
セカンダリ サーバーで次のコマンドを入力して、セカンダリ サーバーをスタンバイ モードにします。
#pcs node standbyセカンダリ サーバーをスタンバイ モードにすると、すべてのクラスタ リソースがプライマリ サーバーに統合されるため、インストールが簡単になります。
セカンダリ サーバーがスタンバイ モードになっていることを確認します。
#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プライマリ サーバーで、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 確認ページで、仮想ホスト名が正しいことを確認します。
構成が完了したら、セカンダリ VM をスタンバイ モードから解除します。
#pcs node unstandby
ERS コンポーネントをインストールする
プライマリ サーバーで、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"プライマリ サーバーで次のコマンドを入力して、プライマリ サーバーをスタンバイ モードにします。
#pcs node standbyプライマリ サーバーをスタンバイ モードにすると、すべてのクラスタ リソースがセカンダリ サーバーに統合されるため、インストールが簡単になります。
プライマリ サーバーがスタンバイ モードになっていることを確認します。
#pcs statusセカンダリ サーバーで、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 確認ページで、仮想ホスト名が正しいことを確認します。
プライマリ VM をスタンバイ状態から解除して、両方ともアクティブにします。
#pcs node unstandby
SAP サービスを構成する
サービスが正しく構成されていることを確認する必要があります。ASCS プロファイルと ERS プロファイルで設定を確認し、SID_LCadm ユーザーを haclient ユーザー グループに追加します。
SAP サービスのエントリを確認する
両方のサーバーで、
/usr/sap/sapservicesファイルに ASCS サービスと ERS サービスの両方のエントリが含まれていることを確認します。これを行うには、systemVまたはsystemdインテグレーションを使用します。sapstartsrvコマンドをpf=PROFILE_OF_THE_SAP_INSTANCEオプションと-regオプションで使用すると、不足しているエントリを追加できます。これらのインテグレーションの詳細については、次の SAP Note をご覧ください。
systemVsystemVのインテグレーションを使用している場合の/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_LCadmsystemd/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
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.servicesystemdインテグレーションが無効になっていることを確認します。#systemctl list-unit-files | grep sap次の例のような出力は、
systemdインテグレーションが無効になっていることを意味します。なお、saphostagentやsaptuneなどの一部のサービスが有効になり、無効のサービスもあります。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 サービスを停止する
セカンダリ サーバーで、ERS サービスを停止します。
#su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"#su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"各サーバーで、すべてのサービスが停止していることを確認します。
#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 ソフトウェアによるサービスの自動再起動機能を無効にします。
両方のノードで
/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 プロファイルを編集する
いずれかのサーバーで、次のコマンドのどちらかを使用してプロファイル ディレクトリに切り替えます。
#cd /usr/sap/SID/SYS/profile#cd /sapmnt/SID/profile必要に応じて、プロファイル ディレクトリでファイルを一覧表示して、ASCS プロファイルと ERS プロファイルのファイル名を確認できます。また、次の形式を使用することもできます。
SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
ENSA1 を使用している場合は、ASCS プロファイルで次の設定を行い、キープアライブ機能を有効にします。
enque/encni/set_so_keepalive = true
詳細については、SAP Note 1410736 - TCP/IP: setting keepalive interval をご覧ください。
必要に応じて、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 のクラスタ リソースを構成する
いずれかのサーバーからの root として、クラスタをメンテナンス モードにします。
#pcs property set maintenance-mode="true"クラスタがメンテナンス モードになっていることを確認します。
#pcs statusASCS サービスと 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=3000ERS インスタンスのクラスタ リソースを作成します。
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=3000ERS インスタンスのクラスタ リソースを作成します。
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 セントラル サービス インスタンスと同じホスト上に存在する必要があります。
- 開始順序の制約を定義します。
ENSA1
ASCS リソースが ERS リソースと同じサーバーで実行されないようにするコロケーション制約を作成します。
#pcs constraint colocation add ERS_RESOURCE_GROUP with \ ASCS_RESOURCE_GROUP -5000フラグ
runsersSIDが1と等しい場合に、ERS が実行されているサーバーにフェイルオーバーするように ASCS を構成します。#pcs constraint location ASCS_INSTANCE_RESOURCE \ rule score=2000 runs_ers_SID eq 1ERS がフェイルオーバー後に他方のサーバーに移行する前に ASCS が起動するように構成します。
#pcs constraint order start ASCS_RESOURCE_GROUP then \ stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
ENSA2
ASCS リソースが ERS リソースと同じサーバーで実行されないようにするコロケーション制約を作成します。
#pcs constraint colocation add ERS_RESOURCE_GROUP with \ ASCS_RESOURCE_GROUP -5000ERS がフェイルオーバー後に他方のサーバーに移行する前に ASCS が起動するように構成します。
#pcs constraint order start ASCS_RESOURCE_GROUP then \ stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
制約を確認します。
#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:いずれかのサーバーからルートとして、クラスタのメンテナンス モードを無効にします。
#pcs property set maintenance-mode="false"
SAP 用の Red Hat クラスタ コネクタを構成する
クラスタ内の各ホストで、HA インターフェースを介して Pacemaker クラスタ ソフトウェアと通信するように SAP Start Service sapstartsrv を構成します。
SAP 管理ユーザーを
haclientグループに追加します。usermod -a -G haclient SID_LCadm
各プロファイルの末尾に次の行を追加して、SAP インスタンス プロファイルを編集します。プロファイルは
/sapmnt/SID/profilesディレクトリにあります。service/halib = $(DIR_CT_RUN)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_cluster_connector
ASCS インスタンス リソースと ERS インスタンス リソースが現在クラスタで実行されている場合は、無効にします。
pcs resource disable ERS_INSTANCE_RESOURCE pcs resource disable ASCS_INSTANCE_RESOURCE
ASCS ホストでサービスを停止します。
sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService
ERS ホストでサービスを停止します。
sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService
リソースを有効にします。
pcs resource enable ERS_INSTANCE_RESOURCE pcs resource enable ASCS_INSTANCE_RESOURCE
クラスタ内の各ホストで上記の手順を繰り返します。
Red Hat からの詳細情報については、RHEL 7 および 8 の SAPInstance リソースに SAP halib を構成する方法をご覧ください。
データベース サーバーとアプリケーション サーバーをクラスタ外部のホストにインストールする
高可用性構成では、クラスタ内の ASCS ホストおよび ERS ホストとは異なるホストに、データベース サーバーとアプリケーション サーバーをインストールすることをおすすめします。
サーバーごとに別々のホストを使用することで、複雑さを軽減し、複数のサーバーに影響を与える障害のリスクを軽減できます。また、各 Compute Engine のサイズをサーバーの種類ごとに調整できます。
これにより、認定された最適なマシンサイズを選択し、障害を回避して複雑さを軽減できます。
データベースとアプリケーション サーバーのインストールについては、このガイドでは説明しません。
データベース サーバーのインストールについては、以下をご覧ください。
- Google Cloud 上の SAP HANA
- Google Cloud 上の SAP ASE
- Google Cloud 上の SAP MaxDB
- Google Cloud 上での SAP 向け IBM Db2
クラスタの検証とテスト
このセクションでは、次のテストを実行する方法について説明します。
- 構成エラーを確認する
- フェイルオーバー中に ASCS リソースと ERS リソースでサーバーを正しく切り替えることを確認する
- ロックが保持されていることを確認する
- Compute Engine のメンテナンス イベントをシミュレートして、ライブ マイグレーションによってフェイルオーバーがトリガーされないようにする。
クラスタの構成を確認する
いずれかのサーバーの 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:SID_LCadmユーザーに切り替えます。#su - SID_LCadmクラスタの構成を確認します。
INSTANCE_NUMBERには、コマンドを入力するサーバーでアクティブな ASCS インスタンスまたは ERS インスタンスのインスタンス番号を指定します。>sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig次の例に示すように、
HAActiveはTRUEにする必要があります。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:
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
ASCS がアクティブなサーバーで、
SID_LCadmとしてフェイルオーバーをシミュレートします。>sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""root として、
crm_monを使用してフェイルオーバーを行うと、ASCS はもう一方のサーバーに移動し、ERS はそのサーバー上で停止した後、ASCS が実行されていたサーバーに移動することが表示されます。
フェイルオーバーをシミュレートする
プライマリ ホストで障害をシミュレートして、クラスタをテストします。テストシステムを使用するか、システムをリリースする前に本番環境システムでテストを実施します。
次のようなさまざまな方法で障害をシミュレートできます。
shutdown -r（アクティブ ノード）ip link set eth0 downecho c > /proc/sysrq-trigger
以下の手順では、ip link set eth0 down を使用してネットワーク インターフェースをオフラインにします。これは、フェイルオーバーとフェンシングの両方を検証するためです。
システムをバックアップします。
アクティブな SCS インスタンスを持つホストの root として、ネットワーク インターフェースをオフラインにします。
$ip link set eth0 downSSH を使用していずれかのホストに再接続し、root ユーザーに変更します。
「
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
SID_LCadmとして、ERS がアクティブなサーバーで、enqtプログラムを使用してロックエントリを生成します。>enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKSSID_LCadmとして、ASCS がアクティブなサーバーで、ロックエントリが登録されていることを確認します。>sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now10 個のロックを作成した場合、次の例のような出力が表示されます。
locks_now: 10
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 9999ASCS がアクティブな場合は、サーバーを再起動します。
モニタリング サーバーで 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
enqtモニターが停止したら、「Ctrl + c」と入力してモニターを終了します。必要に応じて、いずれかのサーバーの root として、クラスタ フェイルオーバーをモニタリングします。
#crm_monSID_LCadmとして、ロックが保持されていることを確認したら、ロックを解除します。>enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKSSID_LCadmとして、ASCS がアクティブなサーバーで、ロックエントリが削除されていることを確認します。>sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now
ENSA2
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_NAMESID_LCadmとして、ASCS がアクティブなサーバーで、ロックエントリが登録されていることを確認します。>sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now10 個のロックを作成した場合、次の例のような出力が表示されます。
locks_now: 10
ERS がアクティブな場合、ロックエントリが複製されたことを確認します。
>sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now返されるロックの数は、ASCS インスタンスと同じになるはずです。
ASCS がアクティブな場合は、サーバーを再起動します。
必要に応じて、いずれかのサーバーの root として、クラスタ フェイルオーバーをモニタリングします。
#crm_monSID_LCadmとして、ASCS が再起動されたサーバーで、ロックエントリが保持されていることを確認します。>sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowSID_LCadmとして、ERS がアクティブなサーバーで、ロックが保持されていることを確認した後、ロックを解放します。>enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAMESID_LCadmとして、ASCS がアクティブなサーバーで、ロックエントリが削除されていることを確認します。>sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now出力は次の例のようになります。
locks_now: 0
Compute Engine のメンテナンス イベントをシミュレートする
Compute Engine のメンテナンス イベントをシミュレートして、ライブ マイグレーションによってフェイルオーバーがトリガーされないようにします。
この手順で使用されるタイムアウトと間隔の値では、ライブ マイグレーションの期間が考慮されます。クラスタ構成で値を小さくすると、ライブ マイグレーションによってフェイルオーバーがトリガーされるリスクが高くなります。
ライブ マイグレーション用のクラスタの許容値をテストするには:
プライマリ ノードで、次の gcloud CLI コマンドを使用してシミュレート メンテナンス イベントをトリガーします。
$gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAMEプライマリ ノードが変更されていないことを確認します。
$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 に関する最小限のサポート要件について詳しくは、以下をご覧ください。
- Google Cloud での SAP に関するサポートを受ける
- SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites（SAP ユーザー アカウントが必要です）
デプロイ後のタスクの実行
SAP NetWeaver システムを使用する前に、新しい SAP NetWeaver HA システムをバックアップすることをおすすめします。
詳細については、SAP NetWeaver 運用ガイドをご覧ください。
次のステップ
高可用性、SAP NetWeaver、Google Cloud の詳細については、次のリソースをご覧ください。
SAP NetWeaver 運用ガイド（VM の管理とモニタリングの詳細）