SAP Pacemaker クラスターを ENSA1 から ENSA2 にアップグレードする - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SAP Pacemaker クラスターを ENSA1 から ENSA2 にアップグレードする

作成者: Gergely Cserdi (AWS) と Balazs Sandor Skublics (AWS)

環境:本稼働

ソース: ENSA1 ベースの Pacemaker クラスター

ターゲット: ENSA2 ベースの Pacemaker クラスター

R タイプ: リアーキテクト

ワークロード: SAP

テクノロジー: インフラストラクチャ、モダナイゼーション

AWS サービス: Amazon EC2

[概要]

このパターンでは、スタンドアロンエンキューサーバー (SAPENSA1) に基づく Word Pacemaker クラスターを ENSA2 にアップグレードするための手順と考慮事項について説明します。このパターンの情報は、SUSE Linux Enterprise Server (SLES) と Red Hat Enterprise Linux (RHEL) の両方のオペレーティングシステムに適用されます。

SAP NetWeaver Word7.52 または S/4HANA 1709 以前のバージョンの Pacemaker クラスターは ENSA1 アーキテクチャで実行され、ENSA1 専用に設定されています。Amazon Web Services (AWS) で SAP ワークロードを実行し、ENSA2 への移行に関心がある場合は、SAP、SUSE、および RHEL ドキュメントでは包括的な情報が提供されていない場合があります。このパターンでは、SAP パラメータと Pacemaker クラスターを再設定して Word から ENSA1 にアップグレードするために必要な技術的な手順について説明しますENSA2。SUSE システムの例を示しますが、概念は RHEL クラスターでも同じです。

注: ENSA1 と ENSA2 は SAP アプリケーションのみに関連する概念であるため、このパターンの情報は HANA SAP やその他のタイプのクラスターには適用されません。

技術的には、ENSA2 はエンキューレプリケーター 2 の有無にかかわらず使用できます。ただし、高可用性 (HA) と (クラスターソリューションによる) フェイルオーバー自動化には エンキューレプリケーター 2 が必要です。このパターンでは、ENSA2 クラスターという用語を使用して、スタンドアロンエンキューサーバー 2 とエンキューレプリケーター 2 を持つクラスターを参照します。

前提条件と制限

前提条件

  • Word または ENSA1 で Pacemaker と Corosync を使用する動作中の SLES ベースのクラスターRHEL。

  • (Word) SAP Central Services (ABAPASCS/EC2) インスタンスとエンキューレプリケーションサーバー (SCS) インスタンスが実行されている Amazon Elastic Compute Cloud (Amazon ERS) インスタンスが少なくとも 2 つあります。

  • SAP アプリケーションとクラスターの管理に関する知識。

  • ルートユーザーとして Linux 環境にアクセスします。

機能制限

  • ENSA1ベースのクラスターは、2 ノードアーキテクチャのみをサポートします。

  • ENSA2.52 より前のバージョンの NetWeaver にはSAP ベースのクラスターをデプロイできません。

  • クラスター内のEC2インスタンスは、異なる AWS アベイラビリティーゾーンにある必要があります。

製品バージョン

  • NetWeaver SAP バージョン 7.52 以降

  • S/4HANA 2020 以降では、ENSA2 クラスターのみがサポートされています

  • ENSA2 および Enqueue Replicator 2 をサポートするカーネル 7.53 以降

  • SLES for SAP Applications バージョン 12 以降

  • RHEL for SAP with High Availability (HA) バージョン 7.9 以降

アーキテクチャ

ソーステクノロジースタック

  • SAP NetWeaver カーネル 7.53 以降の SAP7.52

  • SLES または RHEL オペレーティングシステム

ターゲットテクノロジースタック

  • SAP プラットフォームを搭載した S/4 NetWeaver 2020 を含む、SAP カーネル 7.53 以降の ABAPHANA7.52

  • SLES または RHEL オペレーティングシステム

ターゲット アーキテクチャ

次の図は、ASCS クラスターに基づく ERS/SCS インスタンスと ENSA2 インスタンスの HA 設定を示しています。

ASCS クラスター上の ERS/SCS インスタンスと ENSA2 インスタンスの HA アーキテクチャ

ENSA1 クラスターと ENSA2 クラスターの比較

SAP は ENSA2 の後継として ENSA1 を導入しました。ENSA1 ベースのクラスターは、2 ノードアーキテクチャをサポートしています。このアーキテクチャでは、クラスター内にフェイルオーバーするノードがないため、ASCS/SCS instance fails over to ERS when an error occurs. This limitation stems from how the ASCS/SCS instance regains the lock table information from the shared memory of the ERS node after failover. ENSA2-based clusters with Enqueue Replicator 2 eliminate this limitation, because the ASCS/SCS instance can collect the lock information from the ERS instance over the network. ENSA2-based clusters can have more than two nodes, because the ASCS/SCS instance is no longer required to fail over to the ERS node. (However, in a two-node ENSA2 cluster environment, the ASCS/SCS インスタンスは引き続き ERS ノードにフェイルオーバーされます)。ENSA2 は、Word カーネル 7.50 SAP 以降でサポートされていますが、いくつかの制限があります。エンキューレプリケーター 2 をサポートする HA セットアップの場合、最小要件は NetWeaver 7.52 です (SAP OSS Note 2630416 を参照)。S/4HANA 1809 にはデフォルトで推奨される ENSA2 アーキテクチャが付属していますが、S/4HANA ではバージョン 2020 以降の ENSA2 のみがサポートされています。

自動化とスケール

ターゲットアーキテクチャの HA クラスターは、ASCS を自動的に他のノードにフェイルオーバーします。

ENSA2 ベースのクラスターへの移行シナリオ

ENSA2 ベースのクラスターにアップグレードするには、主に 2 つのシナリオがあります。 

  • シナリオ 1: Word リリースとカーネルバージョンが ENSA2 をサポートしていると仮定して、SAP のアップグレードや S/4SAP HANA変換を伴わずに ENSA2 にアップグレードすることを選択します。

  • シナリオ 2: ENSA2 を使用して、アップグレードまたは変換の一部として SUM に移行する (S/4HANA 1809 以降など)。

エピック」 セクションでは、2つのシナリオのステップについて説明します。最初のシナリオでは、SAP のクラスター設定を変更する前に、ENSA2 関連のパラメータを手動で設定する必要があります。2 番目のシナリオでは、バイナリと SAP 関連のパラメータが SUM によってデプロイされ、残りのタスクは HA のクラスター設定を更新するだけです。SAP を使用した後も、SUM パラメータを検証することをお勧めします。ほとんどの場合、S/4HANA 変換がクラスターのアップグレードの主な理由です。

ツール

  • OS パッケージマネージャーの場合は、Zypper (SLES 用) または YUM (RHEL 用) ツールをお勧めします。

  • クラスター管理には、crm (SLES の場合) または pcs (RHEL の場合) シェルをお勧めします。

  • SAP などの SAPControl インスタンス管理ツール。

  • (オプション) S/4SUM 変換アップグレード用の HANA ツール。

ベストプラクティス

  • SAP で AWS ワークロードを使用するためのベストプラクティスについては、SAP Well-Architected フレームワークの Word レンズを参照してください。 AWS

  • ENSA2 マルチノードアーキテクチャのクラスターノードの数 (奇数または偶数) を考慮してください。

  • ENSA2 S/4-HA-SLES 1.0 認定標準に従って、SAP 15 用の CLU クラスターを設定します。

  • ENSA2 にアップグレードする前に、必ず既存のクラスターとアプリケーションの状態を保存またはバックアップしてください。

エピック

タスク説明必要なスキル

デフォルトのプロファイルにパラメータを設定します。

同じ ENSA2 リリースを維持したまま SAP にアップグレードする場合、またはターゲットリリースのデフォルトが ENSA1 である場合は、デフォルトプロファイル (DEFAULT.PFL ファイル) のパラメータを次の値に設定します。

enq/enable=TRUE enq/serverhost=sapascsvirt enq/serverinst=10 (instance number of ASCS/SCS instance) enque/process_location=REMOTESA enq/replicatorhost=sapersvirt enq/replicatorinst=11 (instance number of ERS instance)

ここで、 sapascsvirtは ASCS インスタンスの仮想ホスト名、 sapersvirtは ERS インスタンスの仮想ホスト名です。これらはターゲット環境に合わせて変更できます。

注: このアップグレードオプションを使用するには、SAP リリースとカーネルバージョンが ENSA2 およびエンキューレプリケーター 2 をサポートしている必要があります。

SAP

ASCS/SCS インスタンスプロファイルを設定します。

同じ ENSA2 リリースを維持したまま SAP にアップグレードする場合、またはターゲットリリースのデフォルトが ENSA1 である場合は、ASCS/SCS インスタンスプロファイルで次のパラメータを設定します。 

ENSA1 が定義されているプロファイルの セクションは次のようになります。

#-------------------------------------------------------------- Start SAP enqueue server #-------------------------------------------------------------- _EN = en.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) Execute_04 = local rm -f $(_EN) Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enserver$(FT_EXE) $(_EN) Start_Program_01 = local $(_EN) pf=$(_PF)

このセクションを ENSA2 用に再設定するには:

  1. SAP からの最新情報 (OSS Note 2501860、SAP ONE Support Launchpad ユーザーアカウントが必要) _ENQに基づいて、_ENプログラムのプレフィックスを に変更します。

  2. エンキューサーバーのバイナリを enserver から enq_server に変更します。

  3. 新パラメータ enq/server/replication/enableTRUE に設定します。

  4. Autostart = 0 を確保します。

変更後、このプロファイルセクションは以下のように見えるでしょう。

#-------------------------------------------------------------- Start SAP enqueue server #-------------------------------------------------------------- _ENQ = enq.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) Execute_04 = local rm -f $(_ENQ) Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enq_server$(FT_EXE) $(_ENQ) Start_Program_01 = local $(_ENQ) pf=$(_PF) ... enq/server/replication/enable = TRUE Autostart = 0

重要: _ENQ は、再起動オプションを有効にしてはなりません。RestartProgram_01_ENQ に設定されている場合、StartProgram_01に変更します。これにより、SAP がサービスを再起動したり、クラスターマネージドリソースに干渉したりすることを防ぎます。

SAP

ERS プロファイルを設定します。

同じ ENSA2 リリースを維持したまま SAP にアップグレードする場合、またはターゲットリリースのデフォルトが ENSA1 である場合は、ERS インスタンスプロファイルで次のパラメータを設定します。

エンキューレプリケーターが定義されているセクションを見つけます。以下に似ているものになります。

#------------------------------------------------------ Start enqueue replication server #------------------------------------------------------ _ER = er.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) Execute_03 = local rm -f $(_ER) Execute_04 = local ln -s -f $(DIR_EXECUTABLE)/enrepserver$(FT_EXE) $(_ER) Start_Program_00 = local $(_ER) pf=$(_PF) NR=$(SCSID)

このセクションをエンキューレプリケーター 2 に再設定する場合:

  1. SAP の最新メモ (OSS Note 2501860、SAP ONE Support Launchpad ユーザーアカウントが必要) _ENQRに基づいて、_ERプログラムのプレフィックスを に変更します。

  2. エンキューレプリケータのバイナリを enrepserver の代わりに enq_replicator に変更します。

  3. Autostart = 0 を確保します。

変更後、このプロファイルセクションは以下のように表示されます。

#------------------------------------------------------ Start enqueue replication server #------------------------------------------------------ _ENQR = enqr.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) Execute_01 = local rm -f $(_ENQR) Execute_02 = local ln -s -f $(DIR_EXECUTABLE)/enq_replicator$(FT_EXE) $(_ENQR) Start_Program_00 = local $(_ENQR) pf=$(_PF) NR=$(SCSID) … Autostart = 0

重要: _ENQR は、再起動オプションを有効にしてはなりません。RestartProgram_01_ENQR に設定されている場合、StartProgram_01に変更します。これにより、SAP がサービスを再起動したり、クラスターマネージドサービスに干渉したりすることを防ぎます。

SAP

SAP Start Services を再起動します。

このエピックで前述したプロファイルを変更したら、WordASCS/SAP SCSと Word の両方で ERS Start Services を再起動します。

sapcontrol -nr 10 -function RestartService SCT

sapcontrol -nr 11 -function RestartService SCT

ここで、 は SAP システム ID SCTを参照し、10 と 11 がそれぞれ ASCS/SCS インスタンスと ERS インスタンスのインスタンス番号であると仮定します。

SAP
タスク説明必要なスキル

SAP リソースエージェントのバージョン番号を確認します。

SUM を使用して SAP を S/4HANA 1809 以降にアップグレードすると、SUM は SAP プロファイルのパラメータの変更を処理します。クラスターのみが手動調整が必要です。ただし、クラスターを変更する前に、パラメータ設定を確認することを推奨します。

注: このエピックの例では、SUSE オペレーティングシステムを使用していることを前提としています。RHEL を使用している場合は、Zypper や crm の代わりに YUM や pcs シェルなどのツールを使用する必要があります。

アーキテクチャ内の両方のノードをチェックして、resource-agentsパッケージが SAP が推奨する最小バージョンと一致していることを確認します。SLES の場合は、SAP OSS Note 2641019 を確認してください。RHEL の場合は、SAP OSS Note 2641322 を確認してください。(SAP Notes には SAP ONE Support Launchpad ユーザーアカウントが必要です)。

sapers:sctadm 23> zypper search -s -i resource-agents Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+-----------------+---------+------------------------------------+--------+----------------------------- i | resource-agents | package | 4.8.0+git30.d0077df0-150300.8.28.1 | x86_64 | SLE-Product-HA15-SP3-Updates

必要に応じて、resource-agents バージョンを更新します。

AWS システム管理者

クラスター設定をバックアップします。

CRM クラスター設定を次のようにバックアップします。

crm configure show > /tmp/cluster_config_backup.txt

AWS システム管理者

メンテナンスモードを設します。。

クラスターをメンテナンスモードに設定します。

crm configure property maintenance-mode="true"

AWS システム管理者

クラスター設定を確認します

現在のクラスター設定をチェックします。

crm configure show

以下は、完全な出力からの抜粋です:

node 1: sapascs node 2: sapers ... primitive rsc_sap_SCT_ASCS10 SAPInstance \ operations $id=rsc_sap_SCT_ASCS10-operations \ op monitor interval=120 timeout=60 on-fail=restart \ params InstanceName=SCT_ASCS10_sapascsvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ASCS10_sapascsvirt" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10 primitive rsc_sap_SCT_ERS11 SAPInstance \ operations $id=rsc_sap_SCT_ERS11-operations \ op monitor interval=120 timeout=60 on-fail=restart \ params InstanceName=SCT_ERS11_sapersvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ERS11_sapersvirt" \ AUTOMATIC_RECOVER=false IS_ERS=true \ meta priority=1000 ... colocation col_sap_SCT_no_both -5000: grp_SCT_ERS11 grp_SCT_ASCS10 location loc_sap_SCT_failover_to_ers rsc_sap_SCT_ASCS10 \ rule 2000: runs_ers_SCT eq 1 order ord_sap_SCT_first_start_ascs Optional: rsc_sap_SCT_ASCS10:start rsc_sap_SCT_ERS11:stop symmetrical=false ...

ここで、 sapascsvirt は ASCS インスタンスの仮想ホスト名、 sapersvirtは ERS インスタンスの仮想ホスト名、 は SAP システム ID SCTを指します。

AWS システム管理者

フェイルオーバーコロケーションの制約を削除します。

前の例では、場所の制約により、ASCS の ENSA1 機能がフェイルオーバー時に常に ERS インスタンスに従うようにloc_sap_SCT_failover_to_ers指定しています。ENSA2 を使用すると、ASCS は参加しているノードに自由にフェイルオーバーできるため、この制約を削除できます。

crm configure delete loc_sap_SCT_failover_to_ers

AWS システム管理者

プリミティブを調整します。

また、ASCS と ERSSAPInstance のプリミティブを少し変更する必要があります。

ASCS 用に設定された SAPInstance プリミティブの例を次に示しますENSA1。

primitive rsc_sap_SCT_ASCS10 SAPInstance \ operations $id=rsc_sap_SCT_ASCS10-operations \ op monitor interval=120 timeout=60 on-fail=restart \ params InstanceName=SCT_ASCS10_sapascsvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ASCS10_sapascsvirt" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

ENSA2 にアップグレードするには、この設定を次のように変更します。

primitive rsc_sap_SCT_ASCS10 SAPInstance \ operations $id=rsc_sap_SCT_ASCS10-operations \ op monitor interval=120 timeout=60 on-fail=restart \ params InstanceName=SCT_ASCS10_sapascsvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ASCS10_sapascsvirt" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=3000

これは、ERS 用に設定された SAPInstance プリミティブの例ですENSA1。

primitive rsc_sap_SCT_ERS11 SAPInstance \ operations $id=rsc_sap_SCT_ERS11-operations \ op monitor interval=120 timeout=60 on-fail=restart \ params InstanceName=SCT_ERS11_sapersvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ERS11_sapersvirt" \ AUTOMATIC_RECOVER=false IS_ERS=true \ meta priority=1000

ENSA2 にアップグレードするには、この設定を次のように変更します。

primitive rsc_sap_SCT_ERS11 SAPInstance \ operations $id=rsc_sap_SCT_ERS11-operations \ op monitor interval=120 timeout=60 on-fail=restart \ params InstanceName=SCT_ERS11_sapersvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ERS11_sapersvirt" \ AUTOMATIC_RECOVER=false IS_ERS=true

プリミティブは、さまざまな方法で変更できます。例えば、次の例のように、vi などのエディタで修正できます。

crm configure edit rsc_sap_SCT_ERS11

AWS システム管理者

メンテナンスモードを無効にします。

クラスターのメンテナンスモードを無効にします。

crm configure property maintenance-mode="false"

クラスターがメンテナンスモードから外れている場合、新しい ASCS 設定で ERS インスタンスと ENSA2 インスタンスをオンラインにしようとします。

AWS システム管理者
タスク説明必要なスキル

ベストプラクティスをレビューします。

より多くのノードを追加する前に、使うノードの数が奇数か、偶数かなどのベストプラクティスを必ず理解するようにしてください。

AWS システム管理者

ノードを追加します。

もっと多くのノードを追加するには、オペレーティングシステムの更新、既存のノードと一致するソフトウェアパッケージのインストール、マウントを使用可能にするなど、一連のタスクが必要です。SAP Software Provisioning Manager (SWPM) の「追加のホストの準備」オプションを使用して、ホストの SAP 固有のベースラインを作成できます。詳細については、次のセクションに記載されている SAP ガイドを参照してください。

AWS システム管理者

関連リソース

SAPとSUSEのリファレンス

SAP Notes にアクセスするには、SAP ONE Support Launchpad ユーザーアカウントが必要です。詳細については、SAP Support ウェブサイトを参照してください。

AWSリファレンス