IBM Cloud Docs
SAP S/4HANA 高可用性構成での実行

SAP S/4HANA 高可用性構成での実行

IBM Cloud® アーキテクチャは、クラウドインフラストラクチャに不可欠なソフトウェア定義可能環境、プログラマブルインターフェース、何百ものハードウェアおよびネットワーク構成など、優れた技術的能力を提供する。 さまざまなワークロードに対応する仮想サーバーと専用サーバーの組み合わせ、インターフェースの自動化、ハイブリッド導入オプションなど、より高いレベルの柔軟性を実現するよう設計されている。 IBM Cloud SAP-Certified Infrastructure offering for SAP HANA and SAP NetWeaver は、 SAP ソフトウェア・スタックが実行されるベアメタル・サーバーと仮想化ベース・サーバーのベスト・フィット・セレクションを提供する。

SAP HANA SAP NetWeaver IBM Cloud® SAP HANA は、専用のデータベースサーバーにインストールされたインメモリデータベースである。 SAP HANA の主なアーキテクチャは、シングルホストまたはマルチホストシステムである。 IBM Cloud は、これらのアプリケーション・サーバー・スタックに基づく アプリケーション・サーバー ABAP、、および 製品を実行するために認定されています。 SAP NetWeaver Java SAP

SAP S/4 HA構成マルチゾーンでのHANA展開

図 1. SAP S/4 マルチゾーンのHA構成におけるHANAの展開
SAP S/4 マルチゾーンのHA構成におけるHANAの展開

高可用性における SAP システムの展開は、2つのペースメーカー・クラスタ構成に基づいている：

  • 1つのクラスタは、 SAP アプリケーションとセントラル・サービスの1つの単一障害点を保護します。
  • 番目のクラスタは、 SAP HANA データベースの可用性を保証する。

SAP テクニカル・コンポーネント

以下は、この構成で導入された SAP テクニカルコンポーネントである：

  • SAP HANA データベース - 2つのVSIに2つのインストールを行い、HAサポートのためにレプリケーション設定を行う。
  • SAP ノードの1つにインストールされたASCSインスタンス。 このインスタンスには、メッセージ・サーバーと Enqueue Server プロセスが含まれる。 これは、SAP システムでロックを管理し、メッセージを交換し、ワークロードのバランスを取るために使用されます。
  • SAP 反対側のノードにインストールされた ERS インスタンス。 このエンキュー・レプリケーション・サーバーは、HAシナリオでは必須のインスタンスで、エンキュー・テーブルのレプリカをローカル・メモリーに保存する役割を持つ。
  • SAP PAS、対話とバッチ処理を行うプライマリアプリケーションサーバー。
  • SAP AASは、PASに関連する反対側のノードにインストールされた追加アプリケーションサーバー。
  • SAP ルーター（オプション）は、VSIへの安全な接続と、 AGリモートサービスをサポートするためのリモート接続を提供します。 SAP

VPCサービスとコンポーネント

以下は、 SAP 高可用性構成をサポートする IBM Cloud VPC サービスとコンポーネントである：

  • ネットワーク・サービス（VPN、 Public Gateway ） - 顧客アクセスとインターネット接続を提供。
  • Jumphost - 同じ顧客ゾーンにある SAP 仮想サーバーインスタンスへのアクセス、管理、および管理を、顧客構内から直接行うために使用します。
  • アプリケーションロードバランサー - SAP およびHANAクラスタの一部である仮想インスタンスのトラフィックを分散する役割を持つ。
  • DNS Services
  • FileShares- SAP Netweaver ファイルシステム構成のニーズをサポートする共有ストレージとして使用される NFS ベースのファイルストレージを提供します。

CFN（Customer Facing Network）上のクライアントは、フローティングIPを使用して、 IBM Cloud 内の仮想サーバーインスタンスにアクセスします。 仮想サーバー・インスタンスは、地理的地域内のアベイラビリティー・ゾーン (データ・センター) でホストされます。

SAP 仮想サーバー・インスタンスは別のセキュリティ・ゾーンに置くことができますが、同じ IBM Cloud リージョンに置く必要があります。 jumphost へのお客様の接続は、お客様のオンプレミスから仮想サーバー・インスタンスの SAP インスタンスへの直接接続と同じルールに従います。 接続は、指定されたパブリックサブネットからのフローティングIPとセキュリティグループ1のファイアウォールルールを使用します。 このアーキテクチャーでは、2 つのセキュリティー・グループが定義されています。この配置は、パブリック・サブネットとプライベート・サブネットを分離する最も簡単な方法です。 さらに分離が必要な場合、セキュリティー・グループを追加できます。

高可用性の主な側面

重要なコンポーネントの冗長性、自動化されたフェイルオーバー・メカニズム、 Pacemaker や SAP HANA System Replication などのクラスタリングやシステム・レプリケーション・テクノロジーとの統合は、高可用性リファレンス・アーキテクチャの重要な側面である。

エンドユーザーへのアプリケーション処理へのアクセスと可用性を維持するため、 SAP アプリケーションサーバーは冗長的にインストールすることを推奨します。 これは、2つのVSIを使用して、プライマリアプリケーションサーバーと追加アプリケーションサーバーを使用することで得られる。

クラッシュが発生し、ノードの1つが故障した場合、ユーザーは故障したそれぞれのアプリケーション・サーバーへのアクセスを失う。 ロードバランシングにログオングループが使用されている場合、ユーザーが再度接続するときに、利用可能な残りのアプリケーションサーバーにリダイレクトされます。

その他の障害ポイントは、ASCSインスタンスと SAP HANA データベースである：

  • ASCS インスタンスは HighAvailability クラスタにデプロイする必要があります。 このようにして、エンキュー・サーバーが管理するエンキュー・テーブルのロックは保護される。 これを実現するために、ERSインスタンスは別のVSI上に配置され、そのインスタンスメモリにロックテーブルの複製コピーを作成する。 ASCSに障害が発生した場合、エンキューロックテーブルはERSインスタンスが保持する複製コピーから再構築することができる。 メッセージサーバーを再起動すると、通信は失われるが、データの完全性は保証される。

SAP S/4 HANAシステムは、デフォルトで ENSA2、ERSノード上でASCSを起動する必要がないというコンセプトで稼働しています。 それでも、2ノードクラスタ構成では、ASCSはERSが稼働している同じノードにフェイルオーバーします。

  • SAP HANA データベースシステムは、 High Availabilityクラスタにデータベースインスタンスをインストールすることでも保護されます。 Pacemaker この環境は、標準的な2ノードの高可用性クラスタとして構築されており、1つのノードがアクティブで、もう1つのノードは継続的なデータ同期でセカンダリとして動作する。 SAP HANA データベースは、ネイティブのHANAシステムレプリケーション（HSR）を同期モード（mode=sync、ログ再生を有効）で使用して構成され、コミットされたすべてのデータがプライマリノードからセカンダリノードへほぼリアルタイムでレプリケートされます。 レプリケーションは、同じサイズの2つの SAP HANA インスタンス間で確立される。 SAP HANA、大規模なワークロードを処理するためのスケールアップ（垂直スケーリング）とスケールアウト（水平スケーリング）の両方のアーキテクチャをサポートしているが、今回の導入はスケールアップモデルに焦点を当てている。

シンプルなマウント構造 (SUSE Linux )

従来のHAセットアップでは、フェイルオーバー操作中にクラスタが SAP ファイルシステムのマウントとアンマウントを管理します。 シンプルマウントアーキテクチャは、これらのファイルシステムをスイッチオーバーする必要も、ペースメーカークラスタによって制御する必要もないと仮定している。 この構造は、外部のネットワークファイル共有に基づいている。 SAP システムごとに必要なファイルシステム数と、 SAP インスタンスごとに必要なファイルシステム数の代わりに、シンプルマウントセットアップでは2つのシンプルなファイルシステムレイアウトだけで済む： 「[sapmnt] /SID」と「/usr [/] sap/SID」である。 インスタンス・ディレクトリを持つ NFS 共有は、systemd や fstab などの標準的な OS メカニズムを使用して、ブート時にすべてのノードに静的にマウントすることができます。 また、" /usr/sap/sapservices” ファイルは各クラスターノードにローカルに存在する。 以前のHAセットアップとのある種の互換性を保つため、このリファレンス・アーキテクチャではまだ「古い」ファイルシステム・レイアウトを使用しているが、シンプルなマウント・アプローチを実装するため、ほとんどのファイルシェアは両方のノードにマウントされている。

図 2. SUSE のシンプルマウントアーキテクチャ Linux
SUSE のシンプルマウントアーキテクチャ Linux

SAP スタンドアロン・エンキュー・サーバー1 ( ) およびスタンドアロン・エンキュー・サーバー2 ( ) ENSA1ENSA2 SAP システムの重要なコンポーネントの1つで、単一障害点であるエンキュー・テーブルを保護するために、エンキュー・テーブルのコピーを保持するエンキュー・レプリケーション・サーバー・インスタンス（ERS）を別途インストールする必要があります。

ENSA1 のインストールでは、ASCSは自身のENQロックテーブルを再構築するために、ERSが稼働しているノードにフェイルオーバーする必要がある。 これはインスタンスの共有メモリセグメントを同期させることで実現されるため、ASCSはERSが稼働しているノードで起動することが必須となる。

SAP NW 7.52 / SAP S4 HANAから、Standalone Enqueue Server 2がデフォルトでインストールされます。 この新しいメカニズムは、 ENSA1 に代わるもので、HAインストレーションにおけるいくつかの改善された動作と、フェイルオーバー操作における柔軟性を導入している。 ENQテーブルのレプリケーション/コピーがネットワーク接続を介して実行されるようになった。 つまり、フェイルオーバーが発生した場合、ERS側でASCSを再起動する必要はなく、元のノードを含むクラスタの他のノードでASCSを再起動する必要があります。 もちろん、2ノードクラスタのセットアップでも、ASCSは反対側のノード（ERSが稼働しているのと同じノード）にフェイルオーバーします。

SAP HANA システムレプリケーションのスケールアップ（高可用性シナリオ）

SAP HANA スケールアップ高可用性構成のシステムレプリケーションは、パフォーマンスの最適化、コスト管理、サービス継続性（RTO）など、ビジネスや運用上の要件に合わせて複数の導入構成をサポートします。

  • HANA Performance Optimized：1番目のノードにインストールされた SAP HANA、2番目のノードにインストールされた SAP HANA データベースと同期（操作モードのログ再生で同期）している。 2番目のノードのデータベースはメモリ内のテーブルをプリロードするように設定されているため、テイクオーバーにかかる時間は非常に短い。
  • HANAパフォーマンス最適化、セカンダリサイト読み取り可能：パフォーマンス最適化シナリオですが、セカンダリデータベースサイトの読み取りアクセスを許可する可能性があります。 これはアクティブ-アクティブ構成とも呼ばれる。
  • HANAコストの最適化：このシナリオでは、スタンバイまたはセカンダリのHANAデータベースは、非生産的なデータベースシステム（テストまたは開発システムなど）とコロケーションされます。 テイクオーバーが発生するたびに、非生産的なシステムは、昇格したHANAの生産的インスタンスを実行するために必要なハードウェアリソースを解放するために停止する必要があります。 このシナリオでは、テーブルのプリロードがオフになり、テイクオーバーの時間が長くなる。

MultiZone (MZ) および SingleZone (SZ) 環境での高い可用性

リージョン内の複数のゾーンにリソースを配置することで、1つのゾーンに障害が発生してもワークロードは稼働し続けることができるため、高可用性と障害分離が可能になります。 詳しくは、 IBM Cloud リージョンとデータセンターのリソースの配置場所を 参照してください。

しかし、リージョン内のシングルゾーンを使用することで、HA構成でリソースを配置することも可能である。

図 3. SAP S/4 HA構成でのHANA展開 シングルゾーン
SAP S/4 HA構成でのHANA展開 シングルゾーン

  • プライベート・サブネットは1つしか配備されていない。
  • SAP HANA は同じネットワークセグメント内の2つのノードクラスタである。
  • SAP サービスインスタンスASCS/ERSは同じネットワークセグメントに属し、2つのノードVSI上の アプリケーションサーバーとコロケートされています。 SAP
  • 仮想ホスト名は、DNSサービスの助けを借りて、アプリケーション・ロード・バランサーを介してクライアントやアプリケーションからもアドレス指定される。

電源配置グループと配置ストラテジーは、単一ゾーン内のVMに補足的な保護を提供し、各インスタンスが別々の電源とネットワークデバイスを持つコンピュータホスト上に配置されることを保証します。 配置グループについては IBM Cloud をご覧ください。