高速再起動: SAP HANA の稼働時間を向上させる強力な新ツール
Google Cloud Japan Team
※この投稿は米国時間 2020 年 8 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
日常の中には、「これで十分」という達成目標がたくさんあります。しかし、SAP 管理者であれば、ビジネス クリティカルな SAP HANA の環境でシステムのダウンタイムや再起動時間を短縮するとなると、「これで十分」ということはないとおわかりでしょう。
もちろん、完璧さを追求し、特に厳しい予算や業務に忙殺される IT スタッフに対処する場合には、優れた戦術があります。そのため、Google Cloud では、既存の SAP HANA の機能を利用してデータベースの再起動時間を短縮する強力な手法に注目しています。これは、ほとんどの SAP 管理者が数分で実装できるアプローチであり、SAP システムの可用性を最大化するための Google Cloud の既存のツールや戦術を補完します。
永続メモリを使用して HANA の再起動時間を短縮
SAP HANA では、インメモリ データベースのように、常駐データを永続ストレージからメモリに読み込むのに長い時間がかかることがあるため、再起動時間が常に懸念されてきました。プロセスの再起動、システムのクラッシュ、計画的なメンテナンスなど、いずれの場合にも HANA の再起動には 1 時間以上かかるのが一般的です。ディスクのデータをメモリに読み込むプロセスは、このダウンタイムのほとんどすべてを占めています。
SAP HANA 2 SPS3 以降の SAP では、再起動時間を短縮するために永続メモリ（PRAM）の使用をサポートしています。このアプローチでは、Intel Optane DC Persistent Memory などの永続メモリを利用し、列ストアのフラグメントをファイルシステムに保存する方法を採用しています。これは、SAP HANA がビジネスで重要な役割を果たしていて、HANA へのアクセスが 1 時間以上停止することが管理者の頭痛の種になっている組織にとって魅力的な選択肢です。
HANA の稼働時間を最大化することには多くの価値があります。しかし、柔軟性とスケーラビリティを備え、イノベーションをサポートするように設計されたテクノロジーを採用することにも価値があります。HANA システムの可用性を最大化し、これらの目標を達成するために組織が採用できる別の選択肢を見てみましょう。
高速再起動: HANA のダウンタイムの対処に役立つ新しい方法
HANA 2.0 SPS4 以降の SAP は高速再起動と呼ばれるメソッドをサポートしていて、PRAM と同様のメリットを多く提供しています。高速再起動は、永続メモリを使用するものよりも限定的なソリューションですが、大きな利点もあります。お客様は、パフォーマンスや柔軟性を犠牲にすることなく、ほとんどすべての現在のホストシステムに実装できます。
簡単に言えば、高速再起動は、仮想ファイルシステムを作成するための伝統的な UNIX 機能である TMPFS を使用して、HANA データベースの列を DRAM に保存します。つまり、高速再起動は VM の完全な再起動を継続できませんが、プロセスの再起動や計画的なメンテナンスによって HANA インスタンスが停止した場合に、データベースはそのままインメモリに保持されます。それでも高速再起動は多くの状況に適していて、1 時間も待たされていた再起動を、ユーザーが気付かないような一時的な中断に変えることができます。
高速再起動を使用する必要があるのは誰でしょうか？答えは簡単です。オンプレミスでもクラウドでも、SAP HANA 2 SPS4 以降を運用するほとんどすべての人が、真剣に使用を検討する必要があります。ほとんどの場合、高速再起動の採用は簡単で、実装プロセスは比較的単純で低リスクです。
ほとんどの SAP 管理者にとって、高速再起動の実装プロセスはわずか 3 ステップです。
ホスト環境の不均一メモリアクセス（NUMA）トポロジを計画して理解します。HANA はシステムの NUMA トポロジの独自の読み取りに基づいてメモリアクセスとプロセスの割り振りを自己最適化するように設計されているため、これは重要な準備ステップです。HANA 用の TMPFS を設定するには、HANA がシステムメモリを認識して使用する方法について同様の理解が必要です。
TMPFS ファイルシステムを作成してマウントします。これには、必要な数のディレクトリの作成と命名、マウント オプションの設定、fstab の更新、結果のファイルシステムをチェックして正しく機能するかどうか確認することが含まれます。
高速再起動を使用するように HANA を構成します。これには、HANA のグローバル INI パラメータを非常にシンプルに変更してから、特定の列テーブルやパーティションを永続メモリの領域に保存するか、すべての新しいテーブルのデフォルトを変更するかを決定することが含まれます。
独自の HANA システムに高速再起動を実装する準備ができたら、高速再起動の SAP ドキュメントを参照して、設定プロセスを深く掘り下げ、高速再起動を使用するための要件を確認してください。
数字で見る高速再起動: 昼夜の違い
HANA プロセスの再起動などのイベント中に、高速再起動がどの程度の違いをもたらすのか疑問に思われるかもしれません。Google としても興味深いので、簡単な比較テストを設定して具体的な数字を出してみました。
まず、プリロード用に構成された総容量 2.74 TB の 40 個のテーブルのデータを含む、極めて典型的な HANA 環境を生成しました。次に、HANA の起動開始からすべてのプリロード テーブルがメモリに読み込まれるまでの経過時間を測定しました。最初に、Compute Engine を使用してメモリ最適化仮想サーバーをプロビジョニングしましたが、高速再起動は使用しませんでした。
Compute Engine M1 メモリ最適化サーバー
起動開始: 11:41:47
プリロードの完了: 12:22:05
IO 速度: 約 1.17 GB/秒
起動にかかった総経過時間: 40 分
この後に、高速再起動を使用して、同じ仮想サーバー上で起動にかかった経過時間を測定しました。
起動開始: 11:12:32
プリロードの完了: 11:13:09
IO 速度: 約 28 MB/秒
起動にかかった総経過時間: 1 分
SAP HANA が独自のバイナリを読み込み、インメモリ データの検証に必要なチェックサム情報を読み取る分の時間を考えると、パフォーマンスを向上させることは困難です。HANA の構成内容によっては高速再起動のプロセスに 4～5 分かかる場合がありますが、高速再起動でない場合との起動時間の違いは歴然です。
Google Cloud での高速再起動: HANA の稼働時間を保護するための多くのツールの一つ
高速再起動は、Google Cloud 上で HANA を実行している場合でも、以前のオンプレミス システムを使用している場合でも、別のクラウド プロバイダを使用している場合でも、SAP HANA を実行する組織に最適なオプションです。ただし、高速再起動を使用すると、重要な疑問が生じることにご注意ください。たとえば、計画的なメンテナンスや計画外の問題によってホスト VM をシャットダウンする必要がある場合など、高速再起動だけではギャップを埋めることができない場合、ダウンタイムを最小限に抑えるためにはどうすればよいのでしょうか？
ここで、多角的な可用性戦略の価値が出てきます。それは、Google Cloud 上で SAP HANA を運用している組織にとって、次のような高可用性ソリューションの連動を指します。
ライブ マイグレーション: 定期メンテナンスを開始する前に、実行中の HANA インスタンスを新しい VM にシームレスに移動します。管理者によるモニタリングや介入は必要ありません
ホストの自動再起動: 異なるホスト上で Compute Engine が VM インスタンスを自動的に再起動できるようにします。これにより、通常はお客様指定の起動スクリプトを使用して、影響を受けたアプリケーションを迅速に再起動できます。
高可用性データベースのサポート: 代表的なのは、Google Cloud の SAP HANA システムの同期レプリケーションや SAP HANA ホストの自動フェイルオーバーのサポートです。
高可用性を考慮した Google Cloud のアプローチ: SAP HANA のユーザーは、冗長なグローバル インフラストラクチャを活用して、複数のゾーンやリージョンにまたがるアプリケーションをデプロイし、厳しい可用性に関する目標に対応できます。
前述のように、ビジネス クリティカルな SAP HANA システムの可用性を維持することに関しては、「これで十分」ということはほとんどありません。高速再起動は、システムの可用性向上に役立つ、見過ごされがちな重要なツールです。ただし、可用性への最善のアプローチは、一体となって動作する多くのソリューションに依存しています。これこそが、すでに Google Cloud 上で SAP HANA を運用している組織にとって高速再起動が貴重なツールとなる理由です。
詳しくは Google Cloud での SAP をご覧ください。
-テクニカル プログラム マネージャー Abdelkader Sellami
