SAP ERP 6.0のサポートが2027年に終了するというアナウンスが出てから、データベースを次世代のSAP HANAへの移行を検討するユーザーが増えています。
Contents
SAP HANA（インメモリデータベース）のメリット・デメリット
SAP ERP 6.0 では言及されませんでしたが、SAP HANAでは冗長構成が基本となります。理由はSAP HANAで採用されているインメモリーデータベースにあります。
SAP HANAではインメモリーデータベースを採用しています。インメモリーデータベースはデータの保持をメモリー上で行うため、処理が高速であるこというメリットがあります。しかしながらデメリットとして、メモリーを稼働するハードウェアが停止するとメモリー上のデータが消えてしまいます。次回の起動（リカバリー）時には取得しているスナップショットからデータからのリストアが必要となり、場合によっては復旧までに数時間を要します。基本的には24時間稼働するシステムですが、障害が発生すると停止せざるえない場合があります。
HANA System Replication（HSR）と連携してデメリットを補う方法！
このデメリットを補うため、SAP HANAには待機系サーバーにデータをミラーリングするHSR（HANA System Replication）というレプリケーション機能が備わっています。待機系サーバーで同じデータが稼働しているため、アクティブサーバーが停止してもスタンバイノードで即座にサービスを再開できます。
HSRはミラーリング機能がありますが、障害の検出や自動リカバリー（フェイルオーバー）機能といったHAクラスターの機能がありません。
障害の検出、自動リカバリー機能については、HAクラスターソフトウェアを導入することで補うことが出来ます。HAクラスターソフトウェアである LifeKeeper ではSAP HANA Recovery kitが提供されており、このSAP HANA Recovery Kitを使用してHSRと連携が可能であり、機能として不足する障害検出、オートリカバリー機能を補うことが出来ます。
SAP HANA Recovery Kit はクラウド環境を中心に既に多くの案件で導入されています。
LifeKeeper の特徴
LifeKeeper はHAクラスターソフトウェアとして長らく利用されており、国内で利用されるようになってから20年近くとなります。SAP HANA の他にも、Oracle やPostgreSQL、JP1、HULFT など多くのアプリケーションを保護することが可能であり、アプリケーションによっては障害の検出や自動リカバリーを行うスクリプトをサポートをつけて提供しています。
他の HAクラスターソフトウェアでは、各アプリケーションを保護するに際して専用のスクリプトを準備する必要があります。しかしながら LifeKeeper では特定のアプリケーションに対しては、Recovery Kitという開発済みのスクリプトをサポートを付与して提供しています。この Recovery Kit はこれまで多くのユーザーに利用いただいております。※LifeKeeperでも個別に開発したスクリプトを組み込むことができます。
スクリプト開発が不要な他にも、導入作業が容易となるGUIの提供や、マニュアルとは別にユーザーサイトやブログ（本ブログ）による情報公開、サポート窓口による支援などを行っております。ハードルが高いと思われがちなクラスターソフトウェアの導入作業がスムーズに進められます。
SAP HANAについても、HSRと連携する SAP HANA Recovery Kit の提供を行っております。そのためSAP HANAをHAクラスターで保護する事についても容易になっています。
LifeKeeper による障害検出/自動リカバリー
SAP HANA Recovery Kit は、SAP HANA を保護対象として取り込むことで、アクティブノードの障害やSAP HANAのプロセス障害、レプリケーション機能の障害など多くの障害の検出、自動復旧が可能です。
また障害の検出については以下の2種類があります。サーバーやVirtual Machineの障害を検出するノード障害と、SAP HANAなどアプリケーション障害（プロセス異常やサービス停止など）を検出する２つです。これらの障害は以下のように区別しています。
- ノード障害によるフェイルオーバー
- リソース障害によるフェイルオーバー
それぞれ、ケースを交えて紹介します。
ノード障害によるフェイルオーバー
ノード障害とは、クラスターノード（アクティブノード、スタンバイノード）間で接続するネットワーク（コミュニケーションパス）を使用して相互にハートビートを送信します。ハードビートへの応答の有無でノードが正常かどうか確認しています。
ハートビートへの応答が一定間隔ない場合、ハートビートを送ったノードは対象ノードで障害が発生したと判断します。OSによる正常なシャットダウンの場合は、フラグを立ててフェイルオーバーを抑制します。予期せぬ電源ダウンなどによるノードの停止の場合はフラグが無いためノード障害として処理されます。アクティブノードで障害が発生した場合は、スタンバイノードのハートビートへの応答がなくなります。そのためスタンバイノードはSAP HANAを起動してHSRのアクティブとなります。（フェイルオーバーが発生します）
以下がノード障害のフローです。
リソース障害によるフェイルオーバー
リソース障害とは、LifeKeeper で保護するアプリケーションを対象として、デフォルト設定で120秒間隔でアプリケーション専用の監視プログラムを稼働し、このプログラムによって障害と判断されることです。リソース障害が発生すると専用のリカバリー（ローカルリカバリー）スクリプトを実行してリカバリーを試みます。リカバリーに失敗した場合は待機ノードにフェイルオーバーを行うことでサービスの復旧を試みます。
以下がリソース監視の処理フローです。
SAP HANA Recovery Kit でも同様に監視するスクリプトを稼働して障害の有無を確認します。具体的には以下のような項目を監視します。なおHSRがある前提となるため、アクティブ/スタンバイそれぞれを監視します。
対象ノード | 確認項目 | 詳細 |
アクティブ/スタンバイ | Agentの確認 |
|
アクティブ/スタンバイ | sapstartsrv サービスの確認 |
|
アクティブ | レプリケーションモードの確認 |
|
スタンバイ | レプリケーションモードの確認 |
|
アクティブ/スタンバイ | DBインスタンスの確認 |
|
リソース障害を検出した場合、まずはローカル環境でのリカバリー（SAP HANAの再起動）処理を試みます。
再起動を行っても復旧しない場合は、ローカルノードでのリカバリーを諦めて、レプリケーションを行っていたスタンバイノードへフェイルオーバー（アクティブノードで停止後にスタンバイノードで起動）を行います。これらの詳細な内容は、後述のSAP HANA Recovery Kit 処理概要をご参照下さい。
まとめ
- SAP HANAではHSRの導入が推奨されているが、HSR単体ではHANA DBの障害を自動的に検知して復旧することはできない。
- HSR環境にLifeKeeper を導入することで障害の検出、HANAデータベースの自動的なリカバリーが可能となる。
- LifeKeeper は導入しやすい設計となっており、SAP HANAを保護するにあたっても実績のあるRecovery Kit（スクリプト）を提供している。
- LifeKeeperはノード監視とリソース監視を並行して行っており、SAP HANA Recovery Kitの処理概要も公開されている。
SAP HANAへのリプレイスや新規導入について検討する材料としてください。
<参考資料>
[Linux] SAP HANA Recovery Kit 処理概要
