Google Cloud での SAP

Pacemaker を使用して Google Cloud 上で SAP の高可用性を実現 - パート 1

※この投稿は米国時間 2022 年 7 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

問題の説明

一般的に、ミッション クリティカルなシステムのビジネス継続性を維持するには、人手をかけることなくフェイルオーバーする高可用性(HA)ソリューションが必要です。SAP HANA や SAP NetWeaver(SAP NW)を Google Cloud 上で稼働させている場合、SAP システムのビジネス継続性を確保するために、基盤となる機能として Red Hat Enterprise Linux(RHEL)for SAP や SUSE Linux Enterprise Server(SLES)for SAP の提供する OS ネイティブの高可用性(HA)クラスタ機能が一般的に使用されます。このブログでは、SAP HANA および NetWeaver プラットフォーム向け Pacemaker クラスタ ソフトウェアの RedHat および SUSE HA 実装に関する基本用語とコンセプトをいくつかご紹介します。

Pacemaker の用語

リソース

Pacemaker におけるリソースとは、クラスタにより高可用性にされたサービスです。SAP HANA の場合、HANA と HANA トポロジという 2 つのリソースがあります。SAP NetWeaver Central Services の場合も 2 つのリソースがあります。1 つが Message Server および Enqueue Server(NW ABAP の ASCS または SCS NW Java)を実行する Central Services インスタンス用のリソースで、もう 1 つが Enqueue Replication Server(ERS)用のリソースです。Pacemaker クラスタでは、仮想 IP(VIP)や内部ロードバランサ (ILB)ヘルスチェック メカニズムなどの機能に対応するほかのリソースも構成します。

リソース エージェント

リソース エージェントは各リソースを管理します。Pacemaker クラスタによって呼び出されるリソース オペレーション(開始、停止、リソースの健全性のモニタリング)のロジックを定義します。これは通常は Linux bash または python スクリプトで、リソース エージェントのオペレーションのための関数を実装します。

SAP リソースを管理するリソース エージェントは、SAP と OS ベンダーによって共同開発されます。リソース エージェントは GitHub でオープンソース化され、OS ベンダーは Linux ディストリビューション用に SAP リソース エージェント パッケージにダウンストリームします。

HANA の管理にリソース エージェントが 2 つあるのはなぜでしょうか。

「SAPHanaTopology」は、すべてのクラスタノードでの HANA トポロジのステータスをモニタリングし、HANA 関連のクラスタ プロパティを更新します。属性は、「SAPHANA」が HANA モニタリング関数の一部として読み取ります。

リソース エージェントが通常インストールされるディレクトリは「/usr/lib/ocf/resource.d/」です。

リソース オペレーション

リソースは、リソース オペレーションと呼ばれるものを持つことができます。リソース オペレーションとは、モニタリング、開始、停止、昇格、降格といった主要なアクション タイプです。これらの機能は記述どおりです。たとえば、リソース オペレーションが「昇格」の場合、クラスタのリソースを昇格します。アクションはそれぞれのリソース エージェント スクリプトに埋め込まれます。

オペレーションのプロパティ:

  • interval(インターバル) - ゼロ以外の値に設定すると、最初のモニタリング アクション完了後のオペレーションの実行頻度が定義されます。

  • timeout(タイムアウト) - オペレーションが中止または失敗とみなされる前に、オペレーションが完了しなければならない時間の長さを定義します。

  • on-fail(失敗時)- オペレーション失敗時に実行されるアクションを定義します。「停止」オペレーションのデフォルトのアクションは「フェンス」で、その他のすべてのデフォルトは「再起動」です。

  • ロール - 指定されたロールであるとクラスタがみなすノードでのみオペレーションを実行します。ロールは、マスターまたはスレーブ、開始済みまたは停止済みの可能性があります。ロールにより、リソース ロケーションとオペレーションの決定のコンテキストを Pacemaker に提供します。

リソース グループ

リソース エージェントは、管理ユニットにグループ化できます。管理ユニットは互いに依存関係を持つもので、順番に開始され、その逆の順序で停止する必要があります。

技術的に各クラスタ リソースは順番にフェイルオーバーされますが、論理的には(クラスタ構成を単純化するため)リソース グループのフェイルオーバーが構成されます。たとえば SAP HANA の場合、VIP リソースと ILB ヘルスチェック リソースの両方を含む 1 つのリソース グループが一般的です。

リソースの制約

制約は、クラスタにおけるリソースの動作を決定します。制約のカテゴリはロケーション、オーダー、コロケーションです。以下のリストに SLES と RHEL の制約を記載しています。

  • ロケーションの制約 - リソースが動作可能なノードを決定します。たとえばホスト VM への各フェンス デバイスを固定します。

  • オーダーの制約 - リソースの動作順序を決定します。たとえば、最初に開始するのが SAPHANATopology リソースで次に SAPHANA リソースとするなどです。

  • コロケーションの制約 - 1 つのリソースのロケーションが別のリソースのロケーションに依存するようにします。たとえば、IP アドレスのリソース グループがプライマリ HANA インスタンスと同じホスト上になくてはならない、などです。

フェンシングとフェンス エージェント

フェンシングまたはフェンス エージェントは抽象化であり、これによって Pacemaker クラスタは、状態の特定できない問題のあるクラスタノードやクラスタ リソースを分離できます。フェンシングは、クラスタ ノード レベルでもクラスタ リソース / リソース グループ レベルでも実行できます。フェンシングは、問題のあるクラスタノードの電源をリモートでオフにして再度オンにしたり、ネットワークへのアクセスを無効にしたりするなど、クラスタ ノード レベルで最も一般的に実行されます。

リソース エージェントと同様に、これらのエージェントも bash や python スクリプトを使用するのが一般的です。GCP 内でよく使用される 2 つのフェンス エージェントは「gcpstonith」と「fence_gce」です。「fence_gce」の方が「gcpstonith」のより強固な後継です。フェンス エージェントは Compute Engine Reset API を使用して問題のあるノードを囲います。

通常、フェンシング リソース「gcpstonith」は「/usr/lib64/stonith/plugins/external」ディレクトリにダウンロードおよび保存されます。リソース「fence_gce」には HA 拡張機能とともに RHEL イメージと SLES イメージが含まれます。

Corosync

Corosync は Pacemaker クラスタの重要な部分ですが、クラスタへの影響が低く評価されることがよくあります。Corosync によりサーバーはクラスタとして操作を行える一方で、Pacemaker によりクラスタの動作の制御が可能になります。Corosync は、メッセージ機能とメンバーシップ機能に加え、次のような機能も提供します。

  • クォーラム情報の維持。

  • クラスタのタスクを通信、連携するためにすべてのクラスタノードが使用。

  • Corosync 構成のデフォルトの場所(/etc/corosync/corosync.conf)の保存。

Corosync 内で通信障害やタイムアウトが発生した場合は、メンバーシップの変更やフェンシング アクションが実行されます。

クローンとクローンセット

クローンとは、独自のリソース定義を作成しなくても複数のホストでアクティブになれるリソースを表します。

リソースが複数のホストにまたがってグループ化されたものをクローンセットと呼びます。クローン化されたリソースには、いくつかの異なるタイプがあります。SAP 構成に関連する主なクローンセットは、ステートフル クローンのセットで、特定のロールを持つリソースを表します。SAP HANA データベースの場合、プライマリ データベース インスタンスとセカンダリ データベース インスタンスは、SAPHana クローンセット内に含まれます。

結論

用語を一通り読んだので、次に SAP Pacemaker クラスタが各 OS でどのようになるかを見てみましょう。

SLES:

1 pacemaker.jpg
  • クラスタには 2 つのノードがあり、両方がオンラインです

    • * Online: [ node-x node-y ]

  • STONITH リソースが各ノードで開始され、「gcpstonith」フェンス エージェントが使用されています

    •   * STONITH-node-x      (stonith:external/gcpstonith):   Started node-y

    •   * STONITH-node-y      (stonith:external/gcpstonith):   Started node-x

  • g-primary と呼ばれるリソース グループがあり、IPAddr2 リソース エージェント(ILB 転送ルール IP アドレスをアクティブ ノードの NIC に追加)と anything リソース エージェント(プログラム「socat」を開始して ILB ヘルスチェック プローブに対応)の両方が含まれます。

    •     * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started node-y

    •     * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started node-y

  • SAPHANATopology リソース エージェント用のクローンセットがあり、2 つのノードが含まれます。

    • cln_SAPHanaTopology_TST_HDB00 [rsc_SAPHanaTopology_TST_HDB00] 

  • SAPHANA リソース エージェント用のクローンセットがあり、マスターノードとスレーブノードが含まれます。

    •   * Clone Set: msl_SAPHana_TST_HDB00 [rsc_SAPHana_TST_HDB00] (promotable)

注: クローンセットの 1 つに「promotable」とマークされているのがわかります。クローンが promotable(昇格可能)の場合、そのインスタンスは特殊なロールを実行できます。このロールは、Pacemaker によってリソース エージェントの昇格オペレーションと降格オペレーションで管理されます。

RHEL:

2 pacemaker.jpg
  • クラスタには 2 つのノードがあり、両方がオンラインです。

    • * Online: [ rhel182ilb01 rhel182ilb02 ]

  • STONITH リソースが反対のノードで開始され、より強固な「fence_gce」フェンス エージェントが使用されています。

    • STONITH-rhel182ilb01 (stonith:fence_gce): Started rhel182ilb02

    • STONITH-rhel182ilb02 (stonith:fence_gce): Started rhel182ilb01

  • g-primary と呼ばれるリソース グループがあり、IPAddr2 リソース エージェント(ILB 転送ルール IP アドレスをアクティブ ノードの NIC に追加)と haproxy リソース エージェント(プログラム「haproxy」を開始して ILB ヘルスチェック プローブに対応)の両方が含まれます。

    • * rsc_healthcheck_R82        (service:haproxy):       Started rhel182ilb02

    • * rsc_vip_R82_00       (ocf::heartbeat:IPaddr2):        Started rhel182ilb02

  • SAPHanaTopology リソース エージェント用のクローンセットがあり、2 つのノードが含まれます。

    • * Clone Set: SAPHanaTopology_R82_00-clone [SAPHanaTopology_R82_00] 

  • SAPHana リソース エージェント用のクローンセットがあり、マスターノードとスレーブノードが含まれます。

    •   * Clone Set: SAPHana_R82_00-clone [SAPHana_TST_HDB00] (promotable)

上記の SLES クラスタと RHEL クラスタを比較すると、両方とも完全に別のクラスタではありますが、類似点やクラスタ オペレーションの実行に使用されるテクノロジーを確認できます。

お疲れさまでした。ここまでで、Google Cloud Platform で実行する SAP クラスタの主要エリアと用語について概要を学習しました。

次のステップ他のブログを再度読んで、クラスタとその動作について理解を深めましょう。

- テクニカル ソリューション エンジニア Billy Martin

- シニア テクニカル ソリューション エンジニア Cherry Legler