IBM Cloud Docs
概要 IBM 上の SAP アプリケーションの高可用性 Power Virtual Server

概要 IBM 上の SAP アプリケーションの高可用性 Power Virtual Server

IBM® Power® Virtual Server 上で SAP を実行することで、 SAP HANA と従来のアプリケーションに一貫したプラットフォームを提供し、ワールドクラスのパフォーマンス、クリティカルなワークロードに対する回復力、柔軟なインフラオプションを実現します。

以下の情報を使用して、 Power Virtual Server インスタンス上の SAP システムに高可用性ソリューションを実装する方法を学んでください。

SAP システムアーキテクチャ

SAP システムの主な構成要素は以下の通り。

SAP HANA システム

SAP HANA システムは、 SAP アプリケーションのデータを保存するテナントデータベースをホストする。

SAP アプリケーションサーバー

SAP アプリケーションサーバーは、 SAP S/4HANA またはその他の SAP アプリケーションソリューションの機能コンポーネントを提供する。 カスタマイズとアプリケーションのデータはすべて、 SAP HANA システムのテナント・データベースに保存されます。

SAP アプリケーション・システムは、1つのユニットとしてインストールされ、構成される。 以下のアプリケーション・インスタンスで構成されている。

  • ABAPシステム・セントラルサービス・インスタンス(ASCSインスタンス)1つ

    • 各 SAP アプリケーションシステムには、メッセージサーバーとエンキューサーバーを含むASCSインスタンスが1つ含まれる。
  • 1つ以上のアプリケーションサーバーインスタンス(ASインスタンス)

    • プライマリアプリケーションサーバー(PAS)は、ABAPシステムにインストールされる最初のASインスタンスです。
    • 追加のASインスタンスは、追加アプリケーションサーバー(AAS)と呼ばれる。

アプリケーションサーバーインスタンスとASCSインスタンスの両方が、共有ファイルシステムへの読み取りと書き込みアクセスを必要とする。

共有ファイル・ システム : 共有ファイルシステムは通常、ネットワーク・ファイル・システム( NFS )サーバーからエクスポートされ、すべてのASインスタンスにマウントされる。

図1は、 SAP システムの技術的構成要素を示している。

図 1. SAP システム用技術コンポーネント
SAP システム用技術コンポーネント

SAP 高可用性ソリューションの検討事項

高可用性を確保するには、アプリケーションサーバーを冗長化してインストールする。 少なくとも2つのアプリケーションサーバー(PASとAAS)を導入し、負荷分散のためにログオングループを構成する。 アプリケーション・サーバーに障害が発生すると、そのインスタンス上でアクティブなユーザー・セッションはすべて終了する。 ユーザーは再ログインする必要があり、ロードバランシングによって別の実行中のアプリケーションサーバーにリダイレクトされる。

SAP HANA データベース、ASCSインスタンス、共有ファイルシステムを含むその他の技術コンポーネントは単一障害点であり、保護が必要である。

SAP HANA システム保護

SAP HANA システムを保護するには、 SAP HANA インスタンスを別の仮想サーバーに配置し、 SAP HANA システムのレプリケーションを有効にし、高可用性(HA)クラスターソフトウェアを使用して自動フェイルオーバーを行います。 解決策は、復旧時間の目標(RTO)に依存する。

高可用性ソリューションのバリエーション SAP HANA
シナリオ 標準的なRTO Comment
パフォーマンス最適化 数分 このシナリオは、特別な要件がない限り、デフォルトで使用される。
アクティブ/アクティブ(読み取り可能) 数分 Active/Active(読み取り有効)構成では、 SAP HANA システム・レプリケーションにより、セカンダリ・システム上のデータベース・コンテンツへの読み取りアクセスが可能になります。
コスト最適化 数十分 コスト最適化構成では、通常運用時には、非本番環境の SAP HANA システムがセカンダリノード上で稼働します。 ハードウェア・リソースは、非本番システムとレプリケーション・セカンダリの間で共有される。 カラム・テーブル・データのプリロードを無効にすることで、メモリ消費量を削減。 フェイルオーバー・プロセス中、非本番インスタンスは、ノードが本番ワークロードを引き継ぐ前に停止します。 このアプローチでは、パフォーマンスを最適化したコンフィギュレーションに比べてテイクオーバー時間が長くなる。

SAP ASCSインスタンス保護

ASCSインスタンスを保護するには、Enqueue Replication Server(ERS)インスタンスを別の仮想サーバー上に配置し、自動フェイルオーバーのためにHAクラスターソフトウェアを使用します。

ASCSとERSインスタンスを両方のサーバーに接続されている共有ディスク、または NFS ファイルシステムにインストールします。

ASCSインスタンスのenqueueサーバーがロックテーブルを管理し、ERSは複製されたコピーをメモリに保持する。 エンキューサーバーが再起動されると、ロックテーブルはERSのコピーから再構築され、すべてのロックが保持される。

データを保持する必要がないため、メッセージ・サーバーの再起動で十分である。

共有ファイルシステムの保護

共有ファイルシステムを保護するには、 VPC用にファイル・ストレージ共有を 作成します。 File Storage for IBM Cloud® File Storage for VPC は、高可用性のために設計されており、ゾーン展開や地域展開のためのプロファイルを提供しています。 VPC用ファイルストレージ共有へのアクセス 」の手順に従って、 Power Virtual Server インスタンスにファイルシステムをマウントします。

高可用性クラスタの概要

HAクラスタは、仮想サーバーインスタンスを使用して、 SAP システムの高可用性を提供します。 重要な SAP コンポーネントは、クラスタ内の複数のインスタンスで実行される。 HAクラスタソフトウェアはダウンタイムを完全に排除するものではないが、フェイルオーバープロセスを管理および自動化することで、サービスの継続性を維持し、フェイルオーバー発生時の混乱を最小限に抑えることができる。

クラスタ化されていない展開では、重要なコンポーネントまたはその基礎となる仮想サーバーインスタンスに障害が発生すると、 SAP システムが完全に停止します。 管理者は問題を診断し、修正し、故障したコンポーネントを再起動しなければならない。

HAクラスタでは、システムがハードウェアまたはソフトウェアの障害を自動的に検出する。 障害が発生すると、HAクラスタソフトウェアは、健全な仮想サーバインスタンス上で影響を受けたコンポーネントを再起動します。 フェイルオーバーと呼ばれるこのプロセスは、管理者が介入することなく自動的に行われるため、手作業による復旧手順に比べて復旧時間が短縮される。 この設定は、アプリケーション・コンポーネントや仮想サーバー・インスタンスに障害が発生した場合に、 SAP システムの高可用性を維持するのに役立つ。

HAクラスタの主要コンポーネント

クリティカルなアプリケーション・コンポーネントを複数のクラスタ・ノードで実行する場合、高可用性を実現するには通常、以下の要素が役割を果たします:

共有ストレージ
クラスターノードは同じストレージにアクセスする必要があります。 フェイルオーバー中、別のノードは必要なファイルやデータにアクセスできるため、障害が発生したコンポーネントを起動できる。
サービスIPアドレス
クライアントノードは、コンポーネントが実行されているノードに割り当てられる固定サービスIPアドレスを通じて、アプリケーションコンポーネントと通信する。
リソースエージェント
リソースエージェントは、アプリケーションコンポーネントのクラスタ管理を抽象化します。 コンポーネントの起動、停止、監視のロジックを定義する。

クラスタの監視と障害検出

HAクラスタは、ノードの健全性と状態を監視するためにハートビート機構を使用します。

クラスタソフトウェアは、スプリットブレインシナリオ(ノードがアクティブなまますべてのハートビート通信が失敗するシナリオ)を防止する必要があります。 このような状況では、複数のノードが誤って自分がアクティブであると思い込み、重複したリソースを開始し、データの破損を引き起こす可能性がある。

クォーラムとノードの分離

クォーラムは、ノードが安全に運用とリソース管理を継続できるかどうかを決定する。 クォーラムを持たないノードは、スプリットブレイン・シナリオを防ぐために、停止または隔離しなければならない。

フェンシング・メカニズム

フェンシングは、クォーラムがないノードや、リソースを正常に停止できないノードを隔離し、リソースが別のノードで安全に起動できるようにする。 一般的なフェンシングの方法は2つある:

パワーフェンス

fence_agentは、パワーデバイス、ハードウェア管理コンソール、またはハイパーバイザーAPIを制御して、強制的にノードの電源を切ったり再起動したりします。 ノードの電源を切ると、共有リソースにアクセスできなくなる。

パワーフェンシングは信頼性の高い絶縁を提供し、ノードの電源を確実にオフにする。 制御はハードウェアレベルで行われ、オペレーティングシステムやクラスタソフトウェアの状態とは無関係である。 しかし、電源サイクリングには時間がかかり、フェンスエージェントの設定にはより複雑なセットアップが必要となる。

SBD(ストニス・ブロック・デバイス)ポイズン・ピル・フェンス

共有ストレージ・デバイスは、すべてのノードがアクセスできる。 ノードはディスクに毒薬を書き込み、他のノードにシャットダウンの合図を送る。

ターゲット・ノードの sbd ・デーモンが毒薬を読み取り、再起動またはシャットダウンをトリガーする。 この方法にはウォッチドッグが必要である。 sbd 、デーモンがハングして毒薬の読み取りに失敗すると、ウォッチドッグ・タイマーのリセットにも失敗する。 タイマーが切れると、ウォッチドッグはノードを再起動する。

Linux の高可用性クラスタの概要 Power Virtual Server

Power Virtual Server のクラスタノードは、1つのゾーン内の1つのワークスペースで実行することも、異なるゾーン内の2つのワークスペースにまたがって実行することもできます。

ネットワーク・アーキテクチャは展開モデルによって異なる。 1つのワークスペースでは、1つのサブネットがすべてのクラスタノードにまたがることができます。 しかし、 Power Virtual Server、サブネットが複数のワークスペースにまたがることはできない。 その結果、従来の IPaddr2 リソースエージェントは、ワークスペース間で固定サービスIPを割り当てるために使用することはできない。

リソースエージェント powervs-move-ippowervs-subnet は、クラスタノードが複数のワークスペースに分散している場合に、追加のサブネットまたはネットワークルートを管理します。

表2は、単一ワークスペースとマルチゾーン・リージョンの展開における高可用性クラスタ構成の比較です。

単一ワークスペースとマルチゾーン・リージョンのHAクラスタ構成の比較
構成 単一ワークスペース マルチゾーン・リージョン
共有ブロック・ストレージ Power Virtual Server ボリューム 該当しない
共有ファイル・ストレージ VPC(ゾーン)用ファイルストレージ共有 VPC用ファイルストレージ共有(地域)
フェンシング・エージェント fence_ibm_powervs (代理店1社) fence_ibm_powervs (1ワークスペースにつき1エージェント)
SBDフェンシング用共有ストレージ Power Virtual Server ボリューム iSCSI VPC VSI上のボリューム
リソースエージェント ServiceIP ipaddr2 (推奨)、 powervs_move_ip powervs_move_ip (推奨)、 powervs_subnet

次の図は、可用性の高い SAP システムのアーキテクチャを示している。

SAP Web Dispatcherは、 SAP システムへの HTTP (S)リクエストのリバースプロキシとして機能する。 IBM Cloud® Load Balancer の背後で、2つの SAP Web Dispatcher が IBM Cloud® Virtual Private Cloud s で並列に実行される。 IBM Cloud® Transit Gateway は、 IBM Cloud VPC と Power Virtual Server ワークスペースのリソースを相互接続する。 ビジネス・ユーザーは、 Load Balancer および SAP Web Dispatchers を通して SAP システムにアクセスする。

図2は、単一の Power Virtual Server ワークスペースにインストールされた SAP システムによる高可用性セットアップを示している。

Power Virtual Server ワークスペース内の仮想サーバーインスタンス上で少なくとも2つのアプリケーションサーバーが実行される。 アプリケーション・サーバーのインスタンス・ディレクトリは、 Power Virtual Server ボリュームまたはゾーン・ファイル・ストレージ共有に保存されます。

2台の Power Virtual Server インスタンスがASCSとERSのクラスタを形成する。 ASCSとERSのインスタンスディレクトリはゾーンファイルストレージ共有に保存されます。 ipaddr2 リソースエージェントはASCSとERSの仮想IPアドレスを管理します。

もう2つの Power Virtual Server インスタンスが SAP HANA のクラスタを形成する。 SAP HANA は、システム・レプリケーションが設定された両方のインスタンス上で実行される。 SAP HANA ストレージは Power Virtual Server ボリュームに保存される。 ipaddr2 リソースエージェントは、 SAP HANA プライマリーの仮想IPを管理する。

図 2. SAP Power Virtual Server 宛 HAアーキテクチャの概要 宛 宛 HAアーキテクチャの概要 宛 宛 HAアーキテクチャの概要
SAP Power Virtual Server

図3は、マルチゾーン・リージョンの2つのゾーンにまたがる SAP ・システムによる高可用性セットアップを示している。

冗長化されたアプリケーション・サーバーは、 Power Virtual Server の両方のワークスペースの仮想サーバー・インスタンス上で実行される。 アプリケーション・サーバー・インスタンスのディレクトリは、 Power Virtual Server ボリュームまたは地域のファイル・ストレージ共有に保存される。

ワークスペース全体で2つの Power Virtual Server インスタンスがASCSとERSのクラスタを形成している。 インスタンス・ディレクトリは地域のファイル・ストレージ共有に保存される。 powervs-move-ip リソースエージェントはASCSとERSのスタティックルートとバーチャルIPアドレスを管理します。

もう2つの Power Virtual Server インスタンスが SAP HANA のクラスタを形成する。 SAP HANA は、システム・レプリケーションが設定された両方のインスタンス上で実行される。 SAP HANA は、 Power Virtual Server ボリュームをストレージに使用する。 powervs-move-ip リソースエージェントは、 SAP HANA プライマリのスタティックルートとバーチャルIPを管理します。

図 3. SAP Power Virtual Server 宛 HAアーキテクチャの概要 宛 宛 HAアーキテクチャの概要 宛 宛 HAアーキテクチャの概要
SAP Power Virtual Server

高可用性ネットワークに関する考察

IBM Power Virtual Server 上の SAP ソリューションの高可用性戦略は、シングルゾーンとマルチゾーンの実装で異なる。

シングルゾーンのセットアップでは、すべてのコンポーネントが同じゾーン内に配置されるため、通常、レイテンシーが改善され、フェイルオーバー時間が短縮される。 しかし、ゾーンレベルのインフラ障害に対してはより脆弱である。

対照的に、マルチゾーンのセットアップでは、リソースを別々のゾーンに分散することで、ゾーン固有の停電に対する耐性を強化し、全体的な耐障害性を向上させることができる。 マルチゾーンのデプロイメントでは、より多くのネットワークに関する考慮事項が発生する。

マルチゾーン環境に SAP アプリケーションサーバーを配置する場合、両方のゾーンでアプリケーションサーバーを実行すると、アプリケーションサーバーとアクティブなデータベースサーバーの間に待ち時間が発生する可能性があります。 この影響を最小限に抑えるには、アプリケーションサーバーをアクティブな SAP HANA データベースインスタンスとコロケートすることを推奨します。

マルチゾーン環境におけるIPフェイルオーバー

IBM Power Virtual Server では、サブネットは単一のワークスペースに関連付けられ、複数のワークスペースにまたがることはない。 Linux したがって ipaddr2 などの標準的なリソースエージェントは、ワークスペース間でのサービスIPフェイルオーバーを提供できません。

マルチゾーン・リージョンのセットアップで、 IBM Cloud VPC または別の Power Virtual Server ワークスペースからの接続を維持するには、カスタム処理が必要です。 IBM Cloud VPC、またはマルチゾーン・リージョン内の別の Power Virtual Server ワークスペース間の接続性を維持するには、特定の設定手順が必要です。 IBM これらのシナリオでIPフェイルオーバーを可能にするために、2つのカスタム・リソース・エージェントを提供する。

リソースエージェント: powervs-move-ip

このリソースエージェントは、仮想サーバーインスタンス(VSI)にエイリアスとしてオーバーレイIPアドレスを割り当て、テイクオーバー中にスタティックルートを更新することで、フェイルオーバーを管理します。

テイクオーバーイベント中、 powervs-move-ip リソースエージェントは、 IBM Power Virtual Server、事前に定義されたスタティックルートを更新し、仮想サーバーインスタンスにIPエイリアスとしてオーバーレイIPアドレスを割り当てます。

次の図は、 SAP HANA System Replicationクラスタにおけるこのシナリオを示しています。

  • 2つの仮想サーバーインスタンス(VSI)が別々のワークスペースに配置されている。
  • 各ワークスペースにプライベートサブネットが作成される。
  • インスタンスは2ノードのRHEL High Availability Add-Onクラスタを形成する。
  • SAP HANA が両方のインスタンスにインストールされ、 SAP HANA システム・レプリケーションが設定されている。
  • オーバーレイIPアドレスのクラスタリソースは、 powervs-move-ip リソースエージェントで構成されます。

オーバーレイIP特性

  • オーバーレイIPは、環境内のすべてのCIDRサブネット範囲の外側にある。
  • 配備時にネットワークインターフェースに割り当てられることはない。
  • 実行時に、リソースエージェントはオーバーレイIPアドレスをVSIネットワークアダプタのIPエイリアスとして設定します。
  • 各ワークスペースにはスタティックルートが設定されている:
    • 各スタティックルートの宛先はオーバーレイIPアドレスである。
    • 各ルートのネクストホップは、それぞれのVSIのプライマリIPアドレスである。
    • リソースエージェントは、 SAP HANA プライマリをホストするVSIへのルートを有効にし、 SAP HANA セカンダリをホストするVSIへのルートを無効にする。

オーバーレイIP正常動作

  • オーバーレイIPアドレスは、ワークスペース1の VSI-1、エイリアスとして設定されている。
  • ワークスペース1では、オーバーレイIPアドレスを宛先とし、ネクストホップを VSI-1 のプライマリIPアドレスに設定したスタティックルートが有効になっている。
  • ワークスペース2では、同じ宛先とネクストホップを VSI-2 'のプライマリIPアドレスに設定したスタティックルートが無効になっている。
  • SAP HANA のプライマリ・インスタンスは VSI-1 で実行される。
  • SAP HANA のセカンダリー・インスタンスは VSI-2 で実行される。

図 4. SAP HANA on Power Virtual Server in マルチゾーン地域 HA overview
SAP HANA on Power Virtual Server in マルチゾーン地域 HA overview

買収後のオーバーレイIP

  • オーバーレイIPアドレスは、ワークスペース2の VSI-2、エイリアスとして設定されている。
  • ワークスペース2では、オーバーレイIPアドレスを宛先とし、ネクストホップを VSI-2 のプライマリIPアドレスに設定したスタティックルートが有効になっている。
  • ワークスペース1では、同じ宛先とネクストホップが VSI-1 'のプライマリIPアドレスに設定されたスタティックルートが無効になっている。
  • SAP HANA のプライマリ・インスタンスは VSI-2 で実行される。
  • SAP HANA のセカンダリー・インスタンスは VSI-1 で実行される。

図 5. SAP HANA on Power Virtual Server in マルチゾーン地域 HA takeover
SAP HANA on Power Virtual Server in マルチゾーン地域 HA takeover

リソースエージェント: powervs-subnet

テイクオーバーイベント中、 powervs-subnet リソースエージェントは、仮想IPアドレスを含むサブネット全体を、あるワークスペースから別のワークスペースに移動します。

次の図は、 SAP HANA System Replicationクラスタにおけるこのシナリオを示しています。

2つの仮想サーバー・インスタンスが別々のワークスペースに配置され、それぞれが独自のサブネットを持つ:

  • SAP HANA が両方のVSIにインストールされ、 SAP HANA システム・レプリケーションが構成されている。
  • 2つの仮想サーバーインスタンスは2ノードの高可用性クラスターを形成し、それぞれが独自のサブネットを使用します。
  • powervs-subnet リソースエージェントを使用するクラスタリソースは、 Subnet 3IP address 3 用に構成されています。 小さなCIDR範囲を使用する。 Subnet 3 には、 IP address 3 とゲートウェイIPのみが割り当てられる。
  • SAP HANA データベースクライアントは IP address 3 を使ってデータベースに接続する。

サブネットの特性を移動する

  • CIDRの範囲は、環境内の他のサブネットと重複しない。
  • どちらのワークスペースでも、サブネットは事前に設定されていない。
  • リソースエージェントは、 SAP HANA プライマリインスタンスをホストするワークスペースにサブネットを作成します。

サブネットの移動

  • ワークスペース1にサブネット3が作成される。
  • サブネット3は VSI-1 に接続されている。
  • IP アドレス 3 は VSI-1 に設定されている。
  • SAP HANA のプライマリ・インスタンスは VSI-1 でアクティブになっている。
  • SAP HANA のセカンダリー・インスタンスは VSI-2 でアクティブになっている。

図 6. SAP HANA on Power Virtual Server in マルチゾーン地域 HA overview
SAP HANA on Power Virtual Server in マルチゾーン地域 HA overview

買収後のサブネットの移動

  • ワークスペース2にサブネット3が作成される。
  • サブネット3は VSI-2 に接続されている。
  • IP アドレス 3 は VSI-2 に設定されている。
  • SAP HANA のプライマリ・インスタンスは VSI-2 でアクティブになっている。
  • SAP HANA のセカンダリー・インスタンスは VSI-1 でアクティブになっている。

図 7. SAP HANA on Power Virtual Server in マルチゾーン地域 HA takeover
SAP HANA on Power Virtual Server in マルチゾーン地域 HA takeover

SAP マルチゾーン地域におけるアプリケーションサーバーの考慮事項

アクティブ-アクティブ展開
SAP アプリケーションサーバーは、異なるゾーンの2つのワークスペースに分散されている。 少なくとも2つのアプリケーションサーバーが別々のワークスペースで実行される。 SAP Central Services(CS)と SAP HANA データベースシステム用の冗長化された仮想サーバーインスタンスが、両方のワークスペースに配置されている。 一度にアクティブになるのは、1 つの CS インスタンスと 1 つのプライマリ・ノード( SAP HANA )のみである。 この配置は、アプリケーション層での冗長性を提供する。
アクティブ-パッシブ展開
SAP アプリケーションサーバーは、一度に2つのワークスペースのうち1つだけがアクティブになる。 パッシブ・ワークスペースのアプリケーション・サーバーは事前にプロビジョニングされているが、フェイルオーバーするまで電源が切られたままである。 アクティブ・アクティブ・アーキテクチャと同様に、CSと SAP HANA は両方のワークスペースに配備されるが、一度にアクティブになるのは1つのCSインスタンスと1つのプライマリ・ノードのみである。 この配備はパフォーマンスが向上しますが、フェイルオーバー中にアプリケーションサーバーを起動する必要があるため、目標復旧時間が長くなります。

SAP HANA 災害復旧シナリオ

データベースの保護を強化するには、 SAP HANA システム・レプリケーションを使用して、 SAP HANA システムを別の地域にある第三のシステムにレプリケートする。 要件に応じて、以下のトポロジーのいずれかを選択します。

  • SAP HANA 多階層システムレプリケーション

    多階層システムのレプリケーションは、複数のシステムをチェーン接続して、より高いレベルの可用性を提供する。

  • SAP HANA マルチターゲットシステムレプリケーション

    マルチターゲット・レプリケーションは、プライマリ・システムとセカンダリ・システムが複数のターゲットに変更をレプリケートすることを可能にする。

高可用性クラスタ設定リファレンス

次の表は、高可用性クラスタを構成するためのドキュメントへのリンクです。