
トレンド・イベント・セミナーレポート|SAP、基幹システムクラウド
検証結果から読み解く、SAP S/4HANAのインフラ構築(可用性編)
次世代ERPとして注目を集め続けるSAP社のSAP S/4HANA。稼働する基盤インフラを検討する際には、オンプレミス・クラウドに関わらず、仮想環境おけるインメモリデータベース「SAP HANA」の特性を十分に配慮する必要がある。
伊藤忠テクノソリューションズ(以下、CTC)株式会社と各分野のエキスパートは、SAP HANAの可用性(ハイアベイラビリティ、HA)の向上に関する検証を実施した。
- 共同検証にご協力いただいた企業(順不同、敬称略)
- SAPジャパン株式会社
- 株式会社 クニエ
- Commvault Systems Japan株式会社
- サイオステクノロジー株式会社
- シスコシステムズ合同会社
- SUSE Japan(ノベル株式会社)
- Dell EMC(EMCジャパン株式会社)
- ヴイエムウェア株式会社
そこで本記事では、検証結果に基づいてSAP HANA環境下における「可用性」についての考察をお伝えする。尚、検証レポートについては、最下部よりダウンロードいただくことができる。
▼ 目次
・SAPシステムの一般的な可用性対策それぞれの特徴とは
・可用性検証結果
・SAP S/4HANAのインフラ構築方法を検証から読み解く(バックアップとディザスタリカバリ編)
1. SAPシステムの一般的な可用性対策それぞれの特徴とは
「9社共同検証報告大容量メモリHANAの仮想/クラウド環境における可用性・バックアップ・DRの勘所」と題するセッションに登壇したのは、CTC クラウドサービス本部インテグレーション企画開発部部長代行(兼)クラウドサービス企画開発部部長代行(兼)ハイブリッドクラウド企画開発課課長の神原宏行だ。
神原は最初に今回の検証環境の概要を紹介した後に、SAPシステムの可用性についての検証結果を報告した。
一般的なSAPシステムにおける仮想環境の可用性対策(クラスタ)方式としては大きく以下の4つとなる。
1-1. ハイパーバイザーのホストHA 機能
ハイパーバイザーが標準で備えるホストHA機能は、APサーバやDBサーバ、仮想マシン上のOSなどに関係なく汎用的に動くものであり、クラウドサービスにおいてもほぼ全てのIaaSで標準実装されている。
ただし、基本的にはハードウェアの障害にのみ対応するものであるため、例えばオペレーションミスやバグによるインスタンスのダウンが起きてしまうと動かない点に注意が必要だ。
「ハイパーバイザーのホストHA機能では、アプリケーションの障害を保護できないので、本番環境、とりわけERPでホストHA機能のみというのは厳しいだろう」と神原はコメントした。
表 1. ハイパーバイザーのホスト HA 機能

1-2. HAクラスタウェア
ホストHA機能と組み合わせて使うことになるのがHAクラスタウェアである。HAクラスタウェアを導入することにより、アプリケーション障害にも対応できるようになる。共有ディスクが構成できる仮想環境であれば、採用ソフトは多数選択可能であり、一方、共有ディスクが構成できないクラウド(IaaS)の場合は、共有ディスクを持たずに構成できるものを選択する必要がある。
ここで神原はこう強調した。
「HAクラスタウェアはプロセスやログを監視してアプリケーション障害などがあれば自動的に再起動する。オペレーションミスやバグによりインスタンスのダウンが起きたとしてもきちんとフェイルオーバーされる。しかし注意が必要なのがRTOに関してだ。ほぼインスタンスの起動時間に依存するため、特に大規模なメモリを要するSAP HANAではサイジングや事前検証が欠かせない」
表 2. HAクラスタウェア (共有ディスク有 / 無)

1-3. SAP HANA System Replication
続いて言及したのは、SAP HANA標準のレプリケーション(データ複製)機能である「SAP HANA System Replication(HSR)」だ。
HSRは、サイト内におけるHA構成だけでなく、サイト間のDR構成などにも対応可能となっている。そして、セカンダリインスタンスは起動状態であることから、前述したHAクラスタウェアで課題となる大規模HANAのRTOにおける「切替」の時間も短縮される。ただしHSRで問題となるのが、切替が手動で行われる点である。そのため人手のない深夜などには、障害が発生してから検知して切替を行うまでの実質的なRTOは長くなる可能性が高い。
「このことからHSRのみで可用性を担保するのは厳しいと言える」(神原)
手動切替が必要であるため、本機能のみでは実質的なRTOは長くなる可能性が大きい
(運用実装に依存)
表 3. SAP HANA System Replication (HSR)

1-4. HAクラスタウェア + SAP HANA System Replication
こうしたことから、可用性を担保するための現実的な選択肢として上がってくるのが、HAクラスタウェアとHSRを組み合わせて活用することである。
これにより、異常を検知して自動で切り替えるところはHAクラスタウェアが担い、一方のHSRではその切替時間を短縮する役割を担うという使い方が可能になるのだ。
「特にTBクラスの大容量のメモリを必要とするSAP HANAの場合は、個人的にはこの方法しかないのではないかと考える。この構成にすることで、あらゆる障害に対応するとともに、自動化による切替も迅速に行えるようになる」(神原)
表 4. HA クラスタウエア + SAP HANA System Replication

ただし、ここで紹介する内容はCTCのクラウドサービスやオンプレミス環境でも使えるものの、他のいくつかのクラウドサービスではHAクラスタウェアが対応しているか別途検討することが欠かせない。
2. 可用性検証結果
それでは、SAP HANAとHAクラスタウェアを組み合わせた構成では実際にどの程度の可用性が確保できるのだろうか。
まず検証環境だが、プライマリーとセカンダリーのSAP HANAの仮想サーバを用意して、メモリは1TB、HDDは2.6TBで構成。
この環境でHSRとサイオステクノロジーのHAクラスターソフトウェア「LifeKeeper」を稼働させた。HSR転送方式はLogreplayを、同期方式はSynchronous in-memoryを採用している。

図 1. SAPシステムの可用性検証環境概要
2-1. HSRにおけるテーブル構成の影響についての検証結果
「SAP HANAは、ローストアテーブルとカラムストアテーブルのいずれにも対応しているものの、HSRにおける挙動は大きくことなる点に注目してほしい」(神原)
HSRにおいては、ローストアテーブルではTakeOver後にメモリへロードされるのに対し、カラムストアテーブルの場合は設定によりTakeOver前にメモリへロードする事が可能となる。では、それぞれのテーブル構成によるTakeOver処理にはどれぐらいの時間差があるのだろうか──。

図 2. HSR におけるテーブル構成の影響について
2,300万レコード/2,388MB×300テーブル(≒約1TB)というデータサイズで、ローストアとカラムストア(事前のメモリロード設定)それぞれについて、プライマリーの仮想マシンのパワーオフから障害検知、IPリソースの切り替えなどのイベントを経て、最終的にHSRの切替終了までの時間を検証した。
その結果は、最後のHSRの切替時間に大きな差があることが判明した。カラムストアでは79秒ほどで切替が完了したのに対し、ローストアではメモリの吸出しに時間がかかるため719秒(11分59秒)も時間がかかったのである。
表 5. テーブル構成によるTakeover処理の時間差

「この約12分の差をどう見るかだ。基幹系システムでは1分1秒でもすばやく切り替えたいものなので、このような差にも注意する必要がある」と神原はコメントした。
2-2. 通常起動時の起動時間の検証結果
HSRやクラスタウェアが無い場合と比較するために、単純な起動時間を計測した。
するとカラムストアが84秒、ローストアが28分という結果となった。ただし、このように見た目の起動完了はカラムストアが早く見えるものの、実際にはバックグラウンドでメモリロードが行われている状態であり、メモリロード完了まではローストと同じ28分かかっている。
「実際には、この28分に加えて、切替検知時間や手動切替実施までの時間も必要になってくるため、ゆうに1時間を超えることになるだろう。それが先のHSR+HAクラスタウェアの組み合わせであれば長くても12分程度で切り替わるのでかなり有効だと思われる」と神原は語ると、今回の検証結果を次のように総括した。
「HSRはテーブル構成により挙動に差異はあるものの、切替時間の短縮に貢献する。一方のHAクラスタウェアは、様々な障害を検知して切替を自動化する役割を担う。オペミスやバグによる論理障害時でも、RTOを1時間以内にするためには、この2つの組み合わせは必須と言えるだろう。
最後に
検証結果の詳細な内容については、SAPシステムの可用性についての検証と合わせて、下記よりダウンロード可能となっている。ぜひ目を通していただき、自社に最適なSAP S/4HANA基盤の構築に役立てていただきたい。