Pacemaker を使用して Google Cloud 上で SAP の高可用性を実現 - パート 1
Google Cloud Japan Team
※この投稿は米国時間 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 スケールアップの場合はリソース エージェントは「SAPHANA」と「SAPHANATopology」
HANA スケールアウトの場合はリソース エージェントは「SAPHANAController」と「SAPHANATopology」
NetWeaver Central Services の場合はリソース エージェントは「SAPInstance」
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:
クラスタには 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 つのノードがあり、両方がオンラインです。
* 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
