AWS 上で SAP HANA Fast Restart Option を利用する

はじめに

長年にわたり、企業はインメモリデータベースの SAP HANA のパワーを享受し、重要なビジネスプロセスのパフォーマンスを支援してきました。しかし、その使用量とデータのフットプリントの増加に伴い、運用上の課題として、アプリケーションの再起動後にデータをメモリにロードするために必要な起動時間が挙げられます。起動の所要時間により、一部のパッチ適用や SAP HANA による障害シナリオでは、システム停止時間が長くなってしまいます。例として、「特定の SAP HANA SP Stack のアップグレードを適用するには、どれくらいのダウンタイムが必要ですか。」と、SAP 管理者はビジネス側からよく聞かれます。ダウンタイムアクティビティの内訳では、SAP HANA の起動時間がダウンタイムウィンドウの大部分を占める可能性があり、データベースサイズに応じて 10 ～ 30 分以上の範囲になることがよくあります。SAP は SAP HANA 2.0 SPS04 以降で、Linux のネイティブな tmpfs 機能を活用した Fast Restart Option を導入し、起動時間を大幅に短縮することで企業のビジネスダウンタイムの短縮を支援します。この機能は迅速に実装でき、追加リソースも必要ないため、起動時間が重要な SAP HANA ベースのワークロードすべてで評価する必要があります。このブログでは、コンセプトの紹介、起動時間の違いのデモンストレーション、実装の詳細について説明します。SAP HANA Fast Restart 機能は、AWS の SAP 認定 Amazon Elastic Compute Cloud (EC2) インスタンス上で稼働する SAP HANA データベースに対して実装することが可能です。

ソリューションの概要

このソリューションを理解するために、まず SAP HANA のメモリ管理について見てみましょう。

SAP HANA データベースは、カラムストアとローストアの2種類のテーブル・ストレージをサポートしています。カラムストアを使用するように、SAP は HANA を最適化しており、カラムストアがデフォルトとなっています。

カラムストアは、MAIN と DELTA という 2 つのデータ構造で構成されています。MAIN ストレージは圧縮され、読み取り操作に最適化されています。一方、DELTA ストレージはすべての書き込み操作のターゲットとなります。データの変更は、デルタマージ操作によって、DELTA ストレージから MAIN ストレージに移動されます。詳細は SAP ドキュメント Memory Management in the Column Store をご参照ください。

SAP HANA Fast Restart オプションは、RAM 上に存在する揮発性の一時ファイルシステムである tmpfs ストレージを使用して、MAIN データフラグメントを保存し再利用します。これは、オペレーティングシステムが再起動しない場合のメモリロード時間を最小化するのに有効で、以下のシナリオに適用されます。

● SAP HANA の再起動

● インデックスサーバーのクラッシュを含む SAP HANA サービスの再起動

● SAP HANA のアップグレード・Service Pack の適用

図 1 は、メモリの使用例と、tmpfs がどのように動的に成長・縮小するかを示しています。設定に関して、以下の 3 つのパラメータが重要です。

1) basepath_persistent_memory_volumes: tmpfs ファイルシステムの場所です。

2) persistent_memory_global_allocation_limit: デフォルトでは制限は指定されていません。ホスト上の持続的メモリーの最大サイズを制限することが可能です。

3) table_default: デフォルトでは ON です。OFF に設定し、PERSISTENT MEMORY スイッチを使用して、テーブル、パーティション、カラムの 3 つのレベルで永続メモリの使用量を手動で制御することが可能です。

上記のパラメータとその使用方法に関する詳細情報は、SAP ドキュメント Persistent Memory をご参照ください。

図 1 SAP HANA Fast Restart

SAP HANA のオンラインパフォーマンスとサイジングの KPI に影響がないので、SAP HANA 2.0 SP4 以降をお使いのお客様は本機能の導入をご検討いただくことをお勧めします。また、ランドスケープ全体で一貫性を持たせるために、非本番環境と本番環境のシステム全体も SAP HANA Fast Restart を有効にしてください。

HANA FAST Restart を有効にした場合としない場合のテスト結果

テストのために、DBACOCKPIT スキーマにテストデータを含む複数のテーブルを作成しました。128 vCPU、メモリ 2048 (GiB) の x2idn.32xlarge EC2 インスタンスでデータベースサイズを 1062 GB とした場合の再起動時間を SAP HANA Fast Restart あり、なしで見てみます。

オペレーティングシステム：SUSE Linux Enterprise Server 12 SP4
SAP HANA バージョン：2.00.050.00.1592305219 (fa/hana2sp05)
HANA DB サイズ：1,062 GB
インスタンスタイプ：x2idn.32xlarge
ストレージタイプ：gp2/gp3（AWS storage configuration guide に従って、SAP HANA に設定）

ディスク上のデータサイズとメモリ上のデータサイズは、以下のようになります。

Fast Restart を使用しない場合の起動時のロード時間：

インデックスサーバーのトレース：

[57833]{-1}[12/-1] 2022-08-03 08:53:44.790361 i TableReload TRexApiSystem.cpp(00376) : Starting preload of table HDB::DBACOCKPIT:LOADGENen
[57831]{-1}[-1/-1] 2022-08-03 09:16:28.450727 i Service_Startup TREXIndexServer.cpp(02059) : Pre-/Re-Loading of column store tables finished.

カラムストアを完全にロードするには 23 分かかりました。

Fast Restart を使用した場合の起動時のロード時間：

インデックスサーバーのトレース：

[77218]{-1}[13/-1] 2022-08-03 09:25:26.339358 i TableReload TRexApiSystem.cpp(00376) : Starting preload of table HDB::DBACOCKPIT:LOADGENen
[79544]{-1}[-1/-1] 2022-08-03 09:26:28.037447 i Service_Startup TREXIndexServer.cpp(02059) : Pre-/Re-Loading of column store tables finished.

カラムストアを完全にロードするには 1 分かかりました。

結果として、Fast Restart Option を使用することで、HANA STARTUPのロード時間が大幅に短縮されました。このケースでは、Fast Restartを使用しない場合 23 分かかっていた起動時間が、Fast Restart を使用することで 1 分まで短縮されました。

導入ステップ

多くの場合、大きなメリットには高い複雑さとコストが伴いますが、SAP HANA Fast Restart の場合はそのようなことはありません。Fast Restart は簡単に導入でき、SAP HANA 2.0 SPS04 以降に追加費用なしで含まれています。

SAP HANA 認証 EC2 インスタンスに SAP HANA Fast Restart を実装するためのステップは下記となります。

ステップ 1：各CPUソケットのメモリ搭載量を決定します。

cat /sys/devices/system/node/node*/meminfo | grep MemTotal | awk 'BEGIN {printf "%10s | %20s\n", "NUMA NODE", "MEMORY GB"; while (i++ < 33) printf "-"; printf "\n"} {printf "%10d | %20.3f\n", $2, $4/1048576}'

アウトプットの例：

NUMA NODE | MEMORY GB
--------------------------------------------
0 | 1000.034
1 | 1000.067

ステップ 2：マウントポイントを作成します。NUMA ノードあたり 1 つの tmpfs を作成します。x2idn.32xlarge は 1000GB のメモリを搭載した NUMA ノードが 2 つあるので、マウントポイントは 2 つ作成します。

mkdir -p /hana/tmpfs0/<SID>
mkdir -p /hana/tmpfs1/<SID>
chown -R <sid>adm:sapsys /hana/tmpfs*/<SID>
chmod 777 -R /hana/tmpfs*/<SID>

ステップ 3：etc/fstab に以下の行を追加します。

tmpfs<SID>0 /hana/tmpfs0/<SID> tmpfs rw,relatime,mpol=prefer:0
tmpfs<SID>1 /hana/tmpfs1/<SID> tmpfs rw,relatime,mpol=prefer:1

ステップ 4（オプション）：TMPFS ファイルシステムに割り当てるメモリを制限するために、パラメータ「size」を入れることが可能です。以下の例では、メモリを 250G に制限しています。

tmpfs<SID>0 /hana/tmpfs0/<SID> tmpfs rw,relatime,mpol=prefer:0,size=250G
tmpfs<SID>1 /hana/tmpfs1/<SID> tmpfs rw,relatime,mpol=prefer:1,size=250G

ステップ 5：/etc/fstab に追加したファイルシステムをマウントします。

mount -a

ステップ 6：HANA Studio、または hdbsql（ユーザー <dbsid>adm として実行）を使用して、以下のパラメータを変更します。

hdbsql -u system -p <password> "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') set ('persistence','basepath_persistent_memory_volumes') = '/hana/tmpfs0/<SID>;/hana/tmpfs1/<SID>' with reconfigure;"

hdbsql -u system -p <password> "ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'on' WITH RECONFIGURE;"

ステップ 7（オプション）：persistent_memory_global_allocation_limit と table_default に関連するパラメータを変更します（またはデフォルトを使用します）。今回は両方のパラメータもデフォルト値を使用しています。

persistent_memory_global_allocation_limit = Max Size (no limit is specified – default)
table_default = ON (default)

ステップ 8：変更を有効にするために、SAP HANA を再起動します。

HDB start

ステップ 9：tmpfs の消費量をチェックします。

注意：ステップ 1〜6 を実施した後の最初の再起動は、tmpfs を使用しない場合と同じ時間がかかります。その後の再起動はより高速になります。

df -h | head -1; df -h| grep tmpfs<SID>

ステップ 10（オプション）：テーブルの整合性をチェックします。

CALL CHECK_TABLE_CONSISTENCY('CHECK_PERSISTENT_MEMORY_CHECKSUM', NULL, NULL);

追加情報

SAP HANA FSO のセットアップは、SAP HANA システムの tmpfs 構成と EC2 インスタンスの CPU とメモリの仕様の間に関連付けを作成します。インスタンスサイズを変更する柔軟性を維持したい場合は、tmpfs のサイズを変更するために、systemd サービスを設定することをご検討ください。次の手順は、これを行うためのサンプルガイダンスを提供します。

ステップ 1：/etc/systemd/system に移動します。

ステップ 2：サービスを作成します。例：sap-hana-tmpfs.service. サービスを作成する例として、このスクリプトを使用することができます。

https://github.com/aws-quickstart/quickstart-sap-hana/blob/main/scripts/sap-hana-tmpfs.service

ステップ 3：ステップ 2 で作成したサービスから呼び出されるスクリプトを作成します。例：sap-hana-tmpfs.sh スクリプトを /etc/rc.d/sap-hana-tmpfs.sh に作成します。このスクリプトを例として使用することができます。

https://github.com/aws-quickstart/quickstart-sap-hana/blob/main/scripts/sap-hana-tmpfs.sh

ステップ 4：新しいサービスを含めるために、サービスファイルをリロードします。

sudo systemctl daemon-reload

ステップ 5：サービスを開始します。

sudo systemctl start <your_service_name>

ステップ 6：サービスの状況を確認します。

sudo systemctl status <your_service_name>

注：インスタンスタイプを変更した後、HANA パラメータを手動で確認し、インスタンスタイプ変更後の構成がお客様の要件に合っていることをご確認ください。

まとめ

SAP HANA データベース上でミッションクリティカルなアプリケーションを実行している企業にとって、ダウンタイムを最小限に抑えることは重要であり、SAP HANA Fast Restart Option を活用することで、基盤となるインフラを変更することなく、ビジネスのダウンタイムを短縮することができます。

SAP on AWS に関するディスカッションにご参加ください

お客様のアカウントチームと AWS サポートチャンネルに加えて、私たちは最近 re:Post – A Reimagined Q&A Experience for the AWS Community を開設しました。SAP on AWS ソリューションアーキテクチャチームは、定期的に SAP on AWS トピックをチェックし、お客様とパートナー様を支援するためにディスカッシや Q&Aをしています。もしご質問がサポートに関係しないものであれば、re:Post でのディスカッシにご参加頂き、コミュニティのナレッジベースに追加することをご検討ください。

AWS が 5000 を超える SAP のお客様に選ばれ、革新的なプラットフォームである理由については、SAP on AWS のページをご参照ください。

翻訳は Specialist SA アッシュが担当しました。原文はこちらです。

Amazon Web Services ブログ