前回はHANAのSAP S/4HANAへの移行時に考慮しておきたいHANAデータベース冗長構成の選定ポイントについて、デル・テクノロジーズ株式会社の山崎様にお話しを伺いましたが今回は1年が経ち、少し可用性の取り方について変化が生まれてきたということで、改めてお話しを伺ってきました。
お話を聞かせてくれた方
デル・テクノロジーズ株式会社
Data Centric Workload and Solutions部
SAP Specialist
山崎 良浩 氏
サイオステクノロジー株式会社
BC&CSサービスライン
プリセールス
西下 容史
—山崎様、前回はHANAデータベースの冗長構成の選定ポイントについてお話いただきありがとうございました。
HANAの導入においてはHAクラスター構成がデフォルトになっており、さらに周辺アプリケーションについてもHAクラスター構成をご検討される企業が増えているとのことですが、背景など山崎様が感じておられることをお伺いできますか？
山崎様：
はい。前回のユースケースでは当社としてSAP HANA案件でHAクラスターとHANA system replicationを使った構成が増えてきているという話をしましたが、1年たちこのHAクラスター構成がHANA導入においてはデフォルトになってきたと感じています。
またS/4HANAなどのアプリケーションサーバ（NetWeaverのインスタンス）も同様にしてHA構成にすることを検討されるお客様が増えてきています。
これは、HANA部分のHAクラスター化が進む中でデータベースだけ可用性を高めてもアプリケーションサーバが機能していなくては業務の継続ができないという事とSAPがNetWeaverインスタンスに対してもHAクラスター利用によって可用性を高められるメカニズムを用意しているという事の2点が理由だと思います。
簡単な図で説明しましょう。
HANAのみがHAクラスター化された状態は下記のようになります。
この図で描かれているようにS/4HANAアプリケーションサーバのインスタンスはASCS、PAS、AASの3種類に分かれています。
これらは全てNetWeaverのワークプロセスと呼ばれます。
ワークプロセスの役割は主にS/4HANAのコードを解釈・実行するものです。
このS/4HANAの処理を実行するメインのプロセスがPAS (プライマリ アプリケーション サーバ)なのですが、S/4HANAの処理はパラレルで行うことができ、その場合はAAS (アディショナル アプリケーション サーバ) を追加します。
これに対してテーブルのロック (SAPでは伝統的にデータベースのロック機構を直接使いません) を管理するなど、PASやAASをサポートするワークプロセスが存在しこれをASCS (ABAPセントラル サービス) といいます。
PASとAASはどちらかが落ちても残ったほうで処理を継続できるのですが、ASCSはパラレルで動かすことはできず、これが落ちてしまうとS/4HANAの処理は継続できなくなります。
この図の中のWeb Dispatcherもパラレルで動かせますので、ASCSだけが単一障害点となってしまうのです。
つまり、S/4HANAの環境の中でHANAのHAクラスター化に加え、ASCSもHAクラスターで保護してやればS/4HANA全体として高可用性が達成できるわけです。
–なるほど、そもそも業務を停止しないように HANAデータベースをHAクラスターで冗長化しているのに、単一障害点があるとそこが止まってしまった場合に業務全体が停止してしまうので、NetWeaverインスタンスもHAクラスター構成で冗長化しておこうという流れが強まっているということですね。ありがとうございます。
もしかするとHAクラスターになじみがない方もいらっしゃるかもしれませんので、簡単にご説明いただけますか？
山崎様：
それではまず、クラスタリングをベースにしたHA構成について概要を話してみたいと思います。
クラスタリングをネットで引くと「コンピューター（ノード）を結合したシステムを指し、1台のノードにトラブルが生じても残りのノードで処理を継続することで可用性を高めることができる。」というような説明が出てくると思いますが、今回は実際の導入例が多い2台のノードをプライマリ、セカンダリとして構成し通常プライマリ ノードで動いているアプリケーションサービスが障害時セカンダリ ノードに切り替わるケースで話をしていきます。
クラスタリングの目的は必要な機能を障害時に残りのノードで処理を継続するという事ですが、重要なのは単一障害点となる機能を保護することです。
HANAではScale-upとScale-outという構成が組めるのですが、S/4HANAの環境ではScale-outは制約が大きく通常はScale-upで導入されます。（S/4HANA環境でのScale-outでの制約とは搭載されるサーバ１ノードあたりCPUは最低８ソケット、メモリは最低6TBと非常に大規模でないと構成できないことなどです。）
Scale-upの場合HANAは論理的に単一のDBなのでこれが単一障害点となります。つまりHANA環境で可用性を担保するためにはHANA自身のHAクラスターを組むことになります。
このようにHAクラスターによって可用性を担保される対象をリソースと呼びます。
このリソースはクラスタリングソフトによってその状態が管理され、必要な時にノードの切り替えなどが行われます。
特定のリソースに特化しそのリソースの状態をクラスタリングソフトに通知するエージェントも必要になり、HANAではresource-agent-sap-hanaというパッケージで提供されています。
障害があった時にリソースをセカンダリ ノードに切り替えることをFailoverといいますが、これには主に2つの方法があります。
スタンバイシステムをセカンダリ ノードで起動、本番システムと同期させておき、障害時はスタンバイシステムを本番システムに昇格させる方法が一つ、もう一つは障害時にセカンダリ ノードで対象のアプリケーションインスタンスを起動し引き継がせる方法です。
どちらにしてもプライマリとセカンダリでこのリソースのデータをレプリケーションまたは共有するメカニズムが必要になります。
このリソース、リソースのデータを同期させるメカニズム、クラスタリングソフトというのが主な構成要素なのですが、もう一つ重要なものにフェンシングがあります。
これは障害を起こしたノードがリソースを利用できなくするもので、今回フォーカスするLinux環境では、STONITHというものが広く使われています。
このSTONITHはShoot The Other Node In The Headの頭の文字を取ったもので物騒な名前ですが、障害を起こしたノード上でリソースを使えなく（ノードをシャットダウンするなどして）します。
一般的にはSBD (STONITH Block Device) によるメッセージ交換を用いて実現されています。
SBDは外部ストレージを使った共有ブロックが一般的ですが、3ノード以上のHAクラスターではディスクレスモードもサポートされます。
クラスタリングソフトにはいろいろなものがありますが、現在デルではSAP環境のクラスタリング構成では、
- SIOS LifeKeeper
- Red Hat Enterprise Linux HA add-on
- SUSE Linux Enterprise Server High Availability Extension
を使っています。
実際クラスタリングソフトを使ってHA構成をどのように組むかHANAとS/4HANAワークプロセスの例を見ていきましょう。
保護対象がHANAの場合、HAクラスターによって管理されるリソースはHANA自身とHANAの仮想IPアドレスとなるのですが、HANAといっても複数のコンポーネントからなるので、SAPHanaとSAPHanaTopologyという2つのパッケージをリソースとして使います。
HANAはプライマリ ノード、セカンダリ ノードでともに起動されておりHANA system replicationによってセカンダリのデータはプライマリに同期されています。
HANA Hookを含むresource-agent-sap-hanaで提供されるエージェントによりプライマリの障害が検知されるとクラスタリングソフトに通知され、リソースのプロパティ（何回障害通知があれば切り替えるかなど）に応じてクラスタリングソフトによって切り替えが行われます。
切り替えでは仮想IPアドレスが旧セカンダリ ノードに移り、スタンバイのHANAが本番に昇格します。
ここでHANA system replicationについて補足します。
HANA system replicationはHANAに標準で付いているのですが、レプリケーションモードとオペレーションモードを設定することで動作を設定するようになっています。
レプリケーションモードには次の3つがあります。
- Synchronous in memory
- Synchronous on disk
- Asynchronous
1と2が同期モードで3が非同期モードです。
クラスターを使ったHAを構成するには同期モードを使用します。
同期モードではプライマリ側でトランザクションのsubmitが行われたとき、この情報がセカンダリに記録されるまで処理を止めて待ちます。
in memoryではセカンダリのメモリ上に書かれるまでですが、on diskではdiskに書き込まれるまで待つことになります。
on diskのほうが安全ではありますが、待ち時間が長くなるのと実質的にin memoryでも安全は問題ないので、一般的にクラスターを使ったHAを構成する場合に使われるのは1のSynchronous in memoryとなります。
次にオペレーションモードですがこちらも3つあります。
- Logreplay
- Logreplay-readaccess
- Delta-data-shipping
1と2ではログだけをプライマリからセカンダリに送り、セカンダリでは受け取ったログをすぐにリプレイしてDBの内容をプライマリと同じ状態に保ちます。
1と2の違いは1ではセカンダリのHANAはFailoverするまではアプリケーションなどから利用できない状態になっているのに対し、2ではFailoverしなくてもreadではアクセス出来てレポート作成などに利用できるという点です。
2は別途ライセンスが必要になります。
3ではログは1や2と同じようにセカンダリに送られるのですがすぐにはリプレイされずDBは更新されません。
定期的にDBの差分情報が送られてきてこれがセカンダリのDBに反映されます。
Failoverが起こるとセカンダリに反映されているDB差分情報以降に生成されたログがリプレイされてDBが更新されることになります。
3はセカンダリ ノードを通常は単純にスタンバイとしてではなく開発など他の用途で使いたいときのものです。
クラスターを使ったHAを構成する場合にはセカンダリは常にプライマリと同期されている必要があるので使用されるのは、1のLogreplayか2のLogreplay-readaccessとなります。
続いてS/4HANAワークプロセスですが1つのシステムの中で複数のワークプロセスを作ることができ、この中で必要な処理（ダイアログやバックグランド、スプールなど）を実行できます。
ほとんどのワークプロセスは冗長構成を組むことができるのですが、メッセージとエンキューといわれるテーブルのロックを管理するワークプロセスは１つしか動かすことができません。
このメッセージとエンキューはABAP Central Service Instance (ASCS)というワークプロセス上に配置されこれが HAクラスターで保護すべき単一障害点となります。
ASCSは小さなインスタンスなので障害が起こった際には短時間で他のノードで再起動することができます。従って、切り替えの基本は実行モジュール、設定ファイルなどを共有ファイルシステム上に配置し、障害時はセカンダリ ノードに共有ファイルシステムへのアクセス権を与えセカンダリ ノードで再起動し直してやればいいことになります。
このただ１つ問題があってテーブルのロック情報はメモリ上で管理され共有ファイルシステムには存在しないことです。
このメモリ上のロック情報を新しく起動されたASCSインスタンスに引き継ぐ手段がEnqueue Replication Server (ERS) です。ERSインスタンスをセカンダリノードで動かし、ASCSのロック情報を同期させることができます。
障害発生時このERSインスタンスが動いているセカンダリノードでASCSインスタンスを再起動させることでロック情報を新しいASCSに引き継がせます。
HAクラスターが保護する対象はASCSインスタンス、そのためにクラスターが管理するリソースは、
- ASCSとERSの2つのインスタンス
- ASCSとERSの2つがそれぞれ使用する仮想IPアドレス
- ASCSやERSの実行モジュールや設定ファイルが収まっている共有ファイルシステム（NASストレージ上の構築されるのが一般的です。）
S/4HANAの環境ではHANAとASCSこの2つが単一障害点なのでHAクラスターによってこれらの高可用性を担保すれば、S/4HANA全体の高可用性は実現できるという事です。
デル・テクノロジーズさまのソリューションページはこちらです。
–では、ここからはHAクラスターの選択肢として山崎様にも紹介いただいたLifeKeeperについて改めてサイオステクノロジー西下から紹介します。
西下さん、LifeKeeperの概要や他のHAクラスターとの違いを簡単に教えてください。
西下：
サイオステクノロジーが開発・販売するHAクラスター製品「LifeKeeper」は、グローバルで25年以上、8万ライセンス以上導入されている実績豊富な製品です。
オンプレミスおよびクラウド環境上で基幹系システムを構成するソフトウェアを冗長化し、基幹系にふさわしい高可用性を実現します。
LifeKeeperは一般的なHAクラスター製品と同様に、制御スクリプトを作成してソフトウェアを監視したり切り替えたりすることも可能ですが、よく使われているソフトウェア向けにメーカー製の制御スクリプトがオプションリカバリキット（ARK：Application Recovery Kit）として提供されています。
ARKを使うことで、直感的なGUIの画面上でスクリプトを書かずに容易にHAクラスターを構築できます。
ARKには製品サポートが提供されます。
SAP向けには、HANA用のARKおよびNetWeaver用のARKのラインナップがLinux版のLifeKeeperに用意されています。
–SAP向けに用意されているHANAやNetWeaver用のARKについてもう少し詳しく紹介してください。
西下：
HANA用のARK（SAP HANA Recovery Kit）は、HANAのデータベースとHSR（HANA System Replication）を保護・制御します。
監視対象のHANAのデータベースおよび必要なプロセスがActiveでないと判断された場合は、まず対象のデータベースおよびプロセスの再起動による復旧を試みます。
再起動で復旧しない場合は、待機系ノードへの切り替え（フェイルオーバー）が行われます。
インメモリ型データベースのHANAは、シングル構成で運用している時に障害が起きてしまうと、復旧時の再ロードに数時間単位の大きな時間がかかる可能性がありますので、HSRを導入されるケースが多くありますが、HSRだけでは障害の自動検知や自動復旧までは行われません。
そこでLifeKeeper for LinuxおよびSAP HANA Recovery Kitをお使いいただくことで、HANAのデータベースを冗長化して基幹系システムの運用に耐えうる高い可用性で運用することが可能となります。
SAP HANA Recovery Kitの処理概要は下記をご覧ください。
→[Linux] SAP HANA Recovery Kit 処理概要
NetWeaver用のARK（SAP Recovery Kit）では、ASCS/SCSとERSを冗長化します。
ASCSのロック情報はERSに複製されるため、ASCS/SCSとERSは対向ノードでそれぞれが相互にActiveになる必要があります。
SAP Recovery Kitは、この要件を満たせるようにASCSとERSを保護し、障害検出時には自動的にフェイルオーバー（切り替え）が行われ、待機系のERSが複製したエンキュー（ロックテーブル）の情報をASCS/SCSに複製することで、排他制御は待機系に引き継がれます。
クラスターノード間のデータの共有は、上記のように共有ストレージを使うこともできますが、共有ストレージが使えない場合は下記のようにDataKeeperを使うこともできます。
DataKeeperは稼働系ノードと待機系ノードのローカルディスクをブロックレベルでリアルタイムに同期することで論理的な共有ストレージとしてLifeKeeperに認識されます。
これにより、共有ストレージとほとんど同じ手順でHAクラスターを構築することが可能になります。
SAP Recovery Kitの処理概要は下記をご覧ください。
→[Linux] SAP Recovery Kit 処理概要
—なるほど、お二人ともありがとうございました。
今回は業務が停止しないよう単一障害点をなくすことが重要であり、S/4HANAの環境ではHANAとASCSこの2つが単一障害点となるのでHAクラスター化が必要だということがよくわかりました。
そしてHAクラスター化するには、手前味噌ですがLifeKeeperならSAP Recovery Kitがあるので比較的簡単にHAクラスターを構築できるんですね。
LifeKeeperには評価版がありますので、導入をご検討の場合は是非ご利用いただければと思います。
また、構築に関しては多数の導入実績のあるデル・テクノロジー様にいつでもご相談いただければと思います。
