RHEL HA Add-On を使用した SAP HANA スケールアップシステムレプリケーションの自動化

RHEL 高可用性クラスターのサポートポリシー - クラスター内の SAP HANA の管理 を参照してください。

SAP Note3108302 - SAP HANA DB: Recommended OS Settings for RHEL 9 に記載されているように、SAP HANA を実行するすべての RHEL 9 システムには RHEL for SAP Solutions サブスクリプションが必要です。RHEL 9 で SAP HANA を実行するための標準リポジトリーに加えて、すべての HA クラスターノードで RHEL HA Add-On のリポジトリーも有効にする必要があります。有効なリポジトリーのリストは次のようになります。

[root]# dnf repolist
repo id                                 repo name                                                      status
rhel-9-for-x86_64-appstream-rpms        Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)       8,603
rhel-9-for-x86_64-baseos-rpms           Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)          3,690
rhel-9-for-x86_64-highavailability-rpms Red Hat Enterprise Linux 9 for x86_64 - High Availability (RPMs)   156
rhel-9-for-x86_64-sap-solutions-rpms    Red Hat Enterprise Linux 9 for x86_64 - SAP Solutions (RPMs)      10

各 HA クラスターノードで正しいサブスクリプションとリポジトリーが有効になっていることを確認する方法の詳細は、RHEL for SAP サブスクリプションおよびリポジトリー を参照してください。

両方のシステムが、問題なく両方のシステムの FQDN を解決できることを確認します。DNS がなくても FQDN を解決できるようにするには、以下の例のように FQDN を /etc/hosts に配置します。

[root]# cat /etc/hosts
...
192.168.0.11 node1.example.com node1
192.168.0.12 node2.example.com node2

システムレプリケーションを機能させるには、SAP HANA log_mode 変数を normal に設定する必要があります。これはデフォルト値でもあります。詳細は、SAP Note 3221437 - System replication is failed due to "Connection refused: Primary has to run in log mode normal for system replication!" を参照してください。これは、両方のノードで以下のコマンドを使用して、SAP HANA 管理ユーザーとして確認できます。

[rh1adm]$ hdbsql -u system -p <HANA_SYSTEM_PASSWORD> -i 02 "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"
VALUE "normal"
1 row selected

設定手順の多くは、インストール中に選択された SID の SAP HANA 管理ユーザーによって実行されます。このドキュメントで説明されているセットアップ例では、使用される SID が RH1 であるため、ユーザー ID rh1adm が SAP HANA 管理ユーザーとして使用されます。

root ユーザーから SAP HANA 管理ユーザーに切り替えるには、次のコマンドを使用できます。

[root]# sudo -i -u rh1adm
[rh1adm]$

SAP HANA システムレプリケーションは、SAP HANA システムレプリケーションセットアップのプライマリーインスタンスとなる HANA インスタンスで初期バックアップが実行された後にのみ機能します。

以下に、/tmp/foo ディレクトリーに初期バックアップを作成する例を示します。

バックアップのサイズはデータベースのサイズによって異なるため、完了までに時間がかかる場合があることに注意してください。バックアップが配置されるディレクトリーは、SAP HANA 管理ユーザーが書き込み可能である必要があります。

シングルテナントの SAP HANA セットアップでは、次のコマンドを使用して初期バックアップを作成できます。

[rh1adm]$ hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> "BACKUP DATA USING FILE ('/tmp/foo')"
0 rows affected (overall time xx.xxx sec; server time xx.xxx sec)

マルチテナントの SAP HANA セットアップでは、SYSTEMDB とすべてのテナントデータベースをバックアップする必要があります。次の例は、SYSTEMDB のバックアップ方法を示しています。

[rh1adm]$ hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> -d SYSTEMDB "BACKUP DATA USING FILE ('/tmp/foo')"
0 rows affected (overall time xx.xxx sec; server time xx.xxx sec)
[rh1adm]# hdbsql -i 02 -u system -p <HANA_SYSTEM_PASSWORD> -d SYSTEMDB "BACKUP DATA FOR RH1 USING FILE ('/tmp/foo-RH1')"
0 rows affected (overall time xx.xxx sec; server time xx.xxx sec)

テナントデータベースのバックアップ方法については、SAP HANA のドキュメントを確認してください。

初期バックアップが正常に完了したら、次のコマンドを使用して SAP HANA システムレプリケーションを初期化します。

[rh1adm]$ hdbnsutil -sr_enable --name=DC1
checking for active nameserver ...
nameserver is active, proceeding ...
successfully enabled system as system replication source site done.

初期化後、SAP HANA システムレプリケーションステータスに現在のノードが 'プライマリー' として表示されていることを確認します。

[rh1adm]#$ hdbnsutil -sr_state
checking for active or inactive nameserver ...
System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~
mode: primary
site id: 1
site name: DC1
Host Mappings:

SAP HANA プライマリーインスタンスと同じ SID とインスタンス番号を使用して、他の HA クラスターノードにセカンダリー SAP HANA インスタンスをインストールした後、すでに実行中の SAP HANA プライマリーインスタンスに登録する必要があります。

セカンダリーレプリケーションインスタンスとなる SAP HANA インスタンスは、プライマリーインスタンスに登録できるようになる前に、まず停止する必要があります。

[rh1adm]$ HDB stop

セカンダリー SAP HANA インスタンスが停止したら、SAP HANA システム PKI SSFS_RH1.KEY および SSFS_RH1.DAT ファイルをプライマリー SAP HANA インスタンスからセカンダリー SAP HANA インスタンスにコピーします。

[rh1adm]$ scp root@node1:/usr/sap/RH1/SYS/global/security/rsecssfs/key/SSFS_RH1.KEY /usr/sap/RH1/SYS/global/security/rsecssfs/key/SSFS_RH1.KEY
...
[rh1adm]$ scp root@node1:/usr/sap/RH1/SYS/global/security/rsecssfs/data/SSFS_RH1.DAT /usr/sap/RH1/SYS/global/security/rsecssfs/data/SSFS_RH1.DAT
...

詳細は、SAP Note 2369981 - Required configuration steps for authentication with HANA System Replication 参照してください。

これで、以下のコマンドを使用して、SAP HANA セカンダリーレプリケーションインスタンスを SAP HANA プライマリーレプリケーションインスタンスに登録できるようになります。

[rh1adm]$ hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --operationMode=logreplay --name=DC2
adding site ...
checking for inactive nameserver ...
nameserver node2:30201 not responding.
collecting information ...
updating local ini files ...
done.

HANA システムレプリケーションの要件に応じて、replicationMode と operationMode の値を選択してください。詳細は、Replication Modes for SAP HANA System Replication および Operation Modes for SAP HANA System Replication を参照してください。

登録が成功すると、SAP HANA セカンダリーレプリケーションインスタンスを再度起動できます。

[rh1adm]$ HDB start

セカンダリーノードが実行中であり、'mode' が hdbnsutil -sr_register コマンドの replicationMode パラメーターに使用される値と一致していることを確認します。登録が成功した場合、SAP HANA セカンダリーレプリケーションインスタンスの SAP HANA システムレプリケーションステータスは、以下のようになります。

[rh1adm]$ hdbnsutil -sr_state
checking for active or inactive nameserver ...
System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~
mode: syncmem
site id: 2
site name: DC2
active primary site: 1
Host Mappings:
~~~~~~~~~~~~~~
node2 -> [DC1] node1
node2 -> [DC2] node2

SAP HANA システムレプリケーションの現在の状態を確認するには、現在のプライマリー SAP HANA ノードで SAP HANA 管理ユーザーとして SAP HANA によって提供される systemReplicationStatus.py Python スクリプトを使用できます。

シングルテナントの SAP HANA セットアップでは、出力は次のようになります。

[rh1adm]$ python /usr/sap/RH1/HDB02/exe/python_support/systemReplicationStatus.py
| Host | Port | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary | Replication | Replication | Replication | | | | | | | | Host | Port | Site ID | Site Name | Active Status | Mode | Status | Status Details |
| ----- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- | | node1 | 30201 | nameserver | 1 | 1 | DC1 | node2 | 30201 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| node1 | 30207 | xsengine | 2 | 1 | DC1 | node2 | 30207 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| node1 | 30203 | indexserver | 3 | 1 | DC1 | node2 | 30203 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |


status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mode: PRIMARY
site id: 1
site name: DC1

マルチテナント SAP HANA セットアップでは、出力は次のようになります。

[rh1adm]$ python /usr/sap/RH1/HDB02/exe/python_support/systemReplicationStatus.py
| Database | Host | Port | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary | Replication | Replication | Replication | | | | | | | | | Host | Port | Site ID | Site Name | Active Status | Mode | Status | Status Details |
| -------- | ----- | ----- | ------------ | --------- | ------- | --------- | ----------| --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
| SYSTEMDB | node1 | 30201 | nameserver | 1 | 1 | DC1 | node2 | 30201 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| RH1 | node1 | 30207 | xsengine | 2 | 1 | DC1 | node2 | 30207 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |
| RH1 | node1 | 30203 | indexserver | 3 | 1 | DC1 | node2 | 30203 | 2 | DC2 | YES | SYNCMEM | ACTIVE | |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mode: PRIMARY
site id: 1
site name: DC1

いずれの場合も、戻りコードも確認してください。

echo $?
15

戻りコード 15 (アクティブ) は問題ありません。14 は同期、13 は初期化を意味します。

テストフェーズは、KPI が満たされており、ランドスケープが設定どおりに機能するかどうかを検証する非常に重要なフェーズです。HA クラスターがないと SAP HANA システムレプリケーションのセットアップが期待どおりに動作しない場合、SAP HANA システムレプリケーションのセットアップを管理するために後で HA クラスターを設定するときに、予期しない動作が発生する可能性があります。

したがって、ガイドラインとして以下にいくつかのテストケースを提案しますが、特定の要件によって強化する必要があります。テストは、現実的なデータ負荷とサイズで実行する必要があります。

詳細は、How To Perform System Replication for SAP HANA の “9. Testing” を参照してください。

SAP HANA スケールアップシステムレプリケーションのセットアップを管理するための HA クラスターのセットアップに必要なリソースエージェントおよびその他の SAP HANA 固有のコンポーネントは、“RHEL for SAP Solutions” リポジトリーの resource-agents-sap-hana RPM パッケージで提供されます。

パッケージをインストールするには、次のコマンドを使用してください。

[root]# dnf install resource-agents-sap-hana

SAP の Implementing a HA/DR Provider に記載されているように、SAP HANA の最新バージョンでは、SAP HANA が特定のイベントの通知を送信できるようにするいわゆる "hooks" が提供されています。srConnectionChanged() フックを使用すると、HA クラスターのアクションを必要とする SAP HANA システムレプリケーションのステータスの変更が発生したことを検出する HA クラスターの機能を向上させ、偶発的なテイクオーバーが回避すべき状況でトリガーされないようにすることで、データ損失/データ破損を避けることができます。

リソースの不必要なフェイルオーバーを回避するには、resource-stickiness パラメーターと migration-threshold パラメーターの次のデフォルト値を設定する必要があります (これは 1 つのノードでのみ行う必要があります)。

[root]# pcs resource defaults update resource-stickiness=1000
[root]# pcs resource defaults update migration-threshold=5000

resource-stickiness=1000 は、リソースが現在の場所で実行し続けることを奨励しますが、migration-threshold=5000 は、5000 回の失敗後にのみ、リソースを新しいノードに移動させます。リソースが別のノードに早期にフェイルオーバーすることを防ぐには、通常は 5000 で十分です。これにより、リソースのフェイルオーバー時間が制御可能な制限内に収まるようになります。

SAPHanaTopology リソースエージェントは、各ノード上の SAP HANA システムレプリケーションのステータスと設定に関する情報を収集します。さらに、SAP HANA インスタンスの起動、停止、監視に必要なローカル SAP HostAgent を起動して監視します。

SAPHanaTopology リソースエージェントには次の属性があります。

以下は、SAPHanaTopology のクローン作成されたリソースを作成するコマンドの例です。

[root]# pcs resource create SAPHanaTopology_RH1_02 SAPHanaTopology SID=RH1 InstanceNumber=02 \
op start timeout=600 \
op stop timeout=300 \
op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

結果として得られるリソースは次のようになります。

[root]# pcs resource config SAPHanaTopology_RH1_02-clone
Clone: SAPHanaTopology_RH1_02-clone
Meta Attrs: clone-max=2 clone-node-max=1 interleave=true Resource: SAPHanaTopology_RH1_02 (class=ocf provider=heartbeat type=SAPHanaTopology)
  Attributes: SID=RH1 InstanceNumber=02
  Operations: start interval=0s timeout=600 (SAPHanaTopology_RH1_02-start-interval-0s)
              stop interval=0s timeout=300 (SAPHanaTopology_RH1_02-stop-interval-0s)
              monitor interval=10 timeout=600 (SAPHanaTopology_RH1_02-monitor-interval-10s)

リソースが開始されると、ノード属性の形式で保存された収集された情報が表示されます。この情報は pcs status --full コマンドで表示できます。以下は、SAPHanaTopology のみが開始された場合、属性がどのようになるかを示した例です。

[root]# pcs status --full
...
Node Attributes:
* Node node1:
    + hana_rh1_remoteHost               : node2
    + hana_rh1_roles                    : 1:P:master1::worker:
    + hana_rh1_site                     : DC1
    + hana_rh1_srmode                   : syncmem
    + hana_rh1_vhost                    : node1
* Node node2:
    + hana_rh1_remoteHost               : node1
    + hana_rh1_roles                    : 1:S:master1::worker:
    + hana_rh1_site                     : DC2
    + hana_rh1_srmode                   : syncmem
    + hana_rh1_vhost                    : node2
...

SAPHana リソースエージェントは、SAP HANA スケールアップシステムレプリケーションの一部である SAP HANA インスタンスを管理し、SAP HANA システムレプリケーションのステータスも監視します。SAP HANA プライマリーレプリケーションインスタンスに障害が発生した場合、SAPHana リソースエージェントは、リソースエージェントパラメーターの設定方法に基づいて、SAP HANA システムレプリケーションのテイクオーバーをトリガーできます。

SAPHana リソースエージェントには、以下の属性があります。

PREFER_SITE_TAKEOVER、AUTOMATED_REGISTER、および DUPLICATE_PIMARY_TIMEOUT パラメーターは、HA クラスターによって管理される SAP HANA システムレプリケーションの可用性とデータ保護の要件に従って設定する必要があります。

通常、新しい SAP HANA プライマリーインスタンスが完全にアクティブになるまでの時間は、元の SAP HANA プライマリーインスタンスが再起動して、すべてのデータをディスクからメモリーに再ロードする際にかかる時間よりも短いため、一般に、PREFER_SITE_TAKEOVER は true に設定し、プライマリー SAP HANA インスタンスの障害が検出された場合に HA クラスターがテイクオーバーをトリガーできるようにします。

HA クラスターによってトリガーされたテイクオーバーが発生した後に、新しいプライマリー SAP HANA インスタンス上のすべてのデータが正しいことを検証できるようにするには、AUTOMATED_REGISTER を false に設定する必要があります。これにより、オペレーターは、テイクオーバーが偶然発生した場合に古いプライマリー SAP HANA インスタンスに戻すか、テイクオーバーが正しかった場合は、古いプライマリー SAP HANA インスタンスを新しいセカンダリー SAP HANA インスタンスとして登録し、SAP HANA システムレプリケーションが再び動作するようにするかのいずれかの可能性を提供します。

AUTOMATED_REGISTER が true に設定されている場合、HA クラスターによるテイクオーバーが発生した後、古いプライマリー SAP HANA インスタンスが SAPHana リソースエージェントによって新しいセカンダリー SAP HANA インスタンスとして自動的に登録されます。これにより、SAP HANA システムレプリケーションセットアップの可用性が向上し、SAP HANA システムレプリケーション環境におけるいわゆる “dual-primary” 状況が阻止されます。ただし、セカンダリー SAP HANA インスタンス上のデータが完全に同期していないにもかかわらず、HA クラスターによってテイクオーバーがトリガーされた場合、古いプライマリー SAP HANA インスタンスを新しいセカンダリー SAP HANA インスタンスとして自動登録すると、このインスタンス上のすべてのデータが削除されるため、テイクオーバーが発生する前に同期されていなかったデータは利用できなくなることから、データ損失やデータ破損のリスクが高まる可能性があります。

SAP HANA インスタンスと SAP HANA システムレプリケーションを管理するための昇格可能な SAPHana クラスターリソースは、次の例のように作成できます。

[root]# pcs resource create SAPHana_RH1_02 SAPHana SID=RH1 InstanceNumber=02 \ PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
op start timeout=3600 \
op stop timeout=3600 \
op monitor interval=61 role="Slave" timeout=700 \
op monitor interval=59 role="Master" timeout=700 \
op promote timeout=3600 \
op demote timeout=3600 \
promotable notify=true clone-max=2 clone-node-max=1 interleave=true

結果の HA クラスターリソースは以下のようになります。

[root]# pcs resource config SAPHana_RH1_02-clone
Clone: SAPHana_RH1_02-clone
Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true promotable=true
Resource: SAPHana_RH1_02 (class=ocf provider=heartbeat type=SAPHana)
  Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=180 InstanceNumber=02 PREFER_SITE_TAKEOVER=true SID=RH1
  Operations: methods interval=0s timeout=5 (SAPHana_RH1_02-methods-interval-0s)
              monitor interval=61 role=Slave timeout=700 (SAPHana_RH1_02-monitor-interval-61)
              monitor interval=59 role=Master timeout=700 (SAPHana_RH1_02-monitor-interval-59)
              promote interval=0s timeout=3600 (SAPHana_RH1_02-promote-interval-0s)
              demote interval=0s timeout=3600 (SAPHana_RH1_02-demote-interval-0s)
              start interval=0s timeout=3600 (SAPHana_RH1_02-start-interval-0s)
              stop interval=0s timeout=3600 (SAPHana_RH1_02-stop-interval-0s)

リソースが開始され、HA クラスターが最初の監視操作を実行すると、以下に示すように、ノード上の SAP HANA データベースの現状を記述する追加のノード属性が追加されます。

[root]# pcs status --full
...
Node Attributes:
* Node node1:
    + hana_rh1_clone_state              : PROMOTED
    + hana_rh1_op_mode                  : delta_datashipping
    + hana_rh1_remoteHost               : node2
    + hana_rh1_roles                    : 4:P:master1:master:worker:master
    + hana_rh1_site                     : DC1
    + hana_rh1_sync_state               : PRIM
    + hana_rh1_srmode                   : syncmem
    + hana_rh1_version                	: 2.00.064.00.1660047502
    + hana_rh1_vhost                    : node1
    + lpa_rh1_lpt                       : 1495204085
    + master-SAPHana_RH1_02             : 150
* Node node2:
    + hana_r12_clone_state              : DEMOTED
    + hana_rh1_op_mode                  : delta_datashipping
    + hana_rh1_remoteHost               : node1
    + hana_rh1_roles                    : 4:S:master1:master:worker:master
    + hana_rh1_site                     : DC2
    + hana_rh1_srmode                   : syncmem
    + hana_rh1_sync_state               : SOK
    + hana_rh1_version                	: 2.00.064.00.1660047502
    + hana_rh1_vhost                    : node2
    + lpa_rh1_lpt                       : 30
    + master-SAPHana_RH1_02             : -INFINITY
...

クライアントが、現在実行されている HA クラスターノードから独立してプライマリー SAP HANA インスタンスにアクセスできるようにするには、仮想 IP アドレスが必要です。HA クラスターは、プライマリー SAP HANA インスタンスが実行されているノードでこのアドレスを有効にします。

HA クラスターが VIP を管理できるようにするには、IP 192.168.0.15 を使用して IPaddr2 リソースを作成します。

[root]# pcs resource create vip_RH1_02 IPaddr2 ip="192.168.0.15"

HA クラスターが実行されているプラットフォームに基づいて、仮想 IP アドレスを管理するための適切なリソースエージェントを使用してください。

結果の HA クラスターリソースは次のようになります。

[root]# pcs resource show vip_RH1_02
Resource: vip_RH1_02 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=192.168.0.15
Operations: start interval=0s timeout=20s (vip_RH1_02-start-interval-0s)
            stop interval=0s timeout=20s (vip_RH1_02-stop-interval-0s)
            monitor interval=10s timeout=20s (vip_RH1_02-monitor-interval-10s)

正しく動作させるには、SAPHana リソースを開始する前に SAPHanaTopology リソースが開始されていることと、プライマリー SAP HANA インスタンスが実行されているノードに仮想 IP アドレスが存在することを確認する必要があります。

これを達成するには、次の制約が必要です。

[root]# pcs constraint order SAPHanaTopology_RH1_02-clone then SAPHana_RH1_02-clone symmetrical=false

[root]# pcs constraint
...
Ordering Constraints:
  start SAPHanaTopology_RH1_02-clone then start SAPHana_RH1_02-clone (kind:Mandatory) (non-symmetrical)
...

[root]# pcs constraint colocation add vip_RH1_02 with master SAPHana_RH1_02-clone 2000

[root]# pcs constraint
...
Colocation Constraints:
  vip_RH1_02 with SAPHana_RH1_02-clone (score:2000) (rsc-role:Started) (with-rsc-role:Master)
...

SAP HANA 2.0 SPS1 以降、SAP HANA は SAP HANA システムレプリケーションの Active/Active (Read-Enabled) セットアップをサポートしており、SAP HANA システムレプリケーションセットアップのセカンダリーインスタンスを読み取り専用アクセスに使用できます。

このようなセットアップをサポートするには、クライアントがセカンダリー SAP HANA インスタンスにアクセスできるようにする 2 番目の仮想 IP アドレスが必要です。テイクオーバーが発生した後もセカンダリーレプリケーションサイトに確実にアクセスできるようにするために、HA クラスターは、昇格可能な SAPHana リソースのスレーブで仮想 IP アドレスを移動する必要があります。

SAP HANA で Active/Active (Read-Enabled) モードを有効にするには、セカンダリー SAP HANA インスタンスを登録するときに、operationMode を logreplay_readaccess に設定する必要があります。

[root]# pcs resource create vip2_RH1_02 IPaddr2 ip="192.168.1.11"

[root]# pcs constraint location vip2_RH1_02 rule score=INFINITY hana_rh1_sync_state eq SOK and hana_rh1_roles eq 4:S:master1:master:worker:master
[root]# pcs constraint location vip2_RH1_02 rule score=2000 hana_rh1_sync_state eq PRIM and hana_rh1_roles eq 4:P:master1:master:worker:master

HANA は、indexserver プロセスの問題を検出すると、SAP HANA に組み込まれている機能を使用して、indexserver プロセスを自動的に停止および再起動することで問題を回復します。

ただし、場合によっては、サービスの "停止" フェーズに非常に長い時間がかかることがあります。その間、システムレプリケーションは同期されなくなる可能性がありますが、HANA は引き続き動作し、新しい接続を受け入れます。最終的に、サービスは停止と再起動のプロセスを完了し、回復します。

データの一貫性にリスクをもたらすこの長時間実行される再起動を待つ代わりに、その間にインスタンスで何か他の障害が発生した場合、ChkSrv.py フックスクリプトが状況に反応し、HANA インスタンスを停止して、より迅速な回復を行うことができます。自動フェイルオーバーが有効になっているセットアップでは、セカンダリーノードが正常な状態であれば、インスタンスが停止するとテイクオーバーが開始します。それ以外の場合、リカバリーはローカルで続行しますが、強制インスタンスの再起動によってリカバリーが高速化されます。

global.ini 設定ファイルで設定していると、SAP HANA はインスタンス内のすべてのイベントに対して ChkSrv.py フックスクリプトを呼び出します。スクリプトはイベントを処理し、イベントの詳細に適用したフィルターの結果に基づいてアクションを実行します。これにより、障害後に HANA によって停止および再起動する HANA indexserver プロセスと、インスタンスのシャットダウンの一環として停止する同じプロセスを区別できます。

実行可能なさまざまなアクションを以下に示します。

停止アクションと強制終了アクションの両方で HANA インスタンスが停止しますが、最終的には強制終了の方が少し速くなることに注意してください。

この時点で、クラスターは HANA リソースの障害を認識し、設定された方法で対応します。通常はインスタンスを再起動し、有効になっている場合はテイクオーバーも行います。

このドキュメントで説明されている HA クラスター設定を使用して SAP HANA システムレプリケーションのセットアップが管理されている場合、更新の前後に SAP HANA インスタンスを更新する実際のプロセスに加えて、追加の手順がいくつか必要になります。次の手順を実行します。

SAP HANA システムレプリケーションの手動テイクオーバーは、昇格可能なクローンリソースを移動することでトリガーできます。

[root]# pcs resource move SAPHana_RH1_02-clone <other-node>