トレンド・イベント・セミナーレポート｜SAP、基幹システムクラウド
徹底解説、SAP S/4HANAのインフラ構築（バックアップとDR編）
SAP S/4HANAは、インメモリデータベースのSAP HANAをプラットフォームとする次世代ERPだ。
この SAP S/4HANAを実装する基盤インフラを検討する上では、インメモリデータベース「SAP HANA」の特性を十分に配慮する必要がある。
伊藤忠テクノソリューションズ（以下CTC）株式会社と各分野のエキスパートは、SAP HANAのデータバックアップとディザスタリカバリ（DR）に関する検証を実施した。
- 共同検証にご協力いただいた企業(順不同、敬称略）
- SAPジャパン株式会社
- 株式会社 クニエ
- Commvault Systems Japan株式会社
- サイオステクノロジー株式会社
- シスコシステムズ合同会社
- SUSE Japan（ノベル株式会社）
- Dell EMC（EMCジャパン株式会社）
- ヴイエムウェア株式会社
そこで本記事では検証結果に基づいて、SAP HANA環境下におけるバックアップとディザスタリカバリについての考察をお伝えする。尚、検証レポートについては、最下部よりダウンロードいただくことができる。
▼ 目次
・SAP S/4HANAのDR ～レプリケーション機能の検証結果～
・SAPシステムのバックアップではフルや差分などの組み合わせ方が肝に
・SAPシステムのバックアップで注目すべきは時間よりもデータ容量
・SAP S/4HANAのインフラ構築方法を検証から読み解く(可用性編)
1. SAP S/4HANAのDR ～レプリケーション機能の検証結果～
"9社共同検証報告大容量メモリSAP HANAの仮想・クラウド環境における可用性・バックアップ・DRの勘所" と題するセッションに登壇したのは、CTCクラウドサービス企画開発部 部長代行の神原宏行だ。
神原は本検証環境の概要を解説した後、SAPシステムのDRに関する検証結果の説明と考察を行った。ここでは、ミドルウェアレプリケーション──つまり「SAP HANA System Replication（HSR）」とバックアップリプリケーションに、どれだけの時間の差があるかの検証が行われた。ミドルウェアレプリケーションとバックアップリプリケーションを実際に試してみた結果、ミドルウェアレプリケーションに要した時間は5分、バックアップリプリケーションに要した時間は13分となった。
図 1. DR 検証環境概要図
切り替え時間についてはSAP HANAが起動している状態のほうが当然速くなるが、ここで注目したい点は更新単位の違いだ。ミドルウェアレプリケーション（＝HSR）の場合はトランザクション単位で同期されているのに対し、バックアップリプリケーションの同期単位はバックアップデータのみとなる。
神原の説明は次の通りだ。
- 「RTOに関しても、ミドルウェアレプリケーションであればトランザクション単位で送っているので、回線の帯域やその時の更新データ量にもよるが、基本的には障害発生の直前、つまりリカバリーポイントは1つになる。」
- 「一方でバックアップリプリケーションでは、更新単位はバックアップ頻度次第になる。例えば1日に一回のバックアップ頻度であればリカバリーポイントは1日前となり、そこから現在までのデータは失われることになる。」
しかしながら、バックアップリプリケーションにはメリットもあるという。
その1つがリカバリーポイントを数多く持つことができる点だ。
- 「様々な業種のお客様と会話をするなかで、実はリアルタイムで同期するよりも、一定の区切りのある時間でリカバリーポイントがあったほうが仕事しやすいと言われることが多い。その理由を聞くと、ユーザーに対し昼間12時からの作業は消えてしまったのでもう一度やって欲しいなどと具体的に言いやすいからだという。したがって自社の要件によってどちらが向いているのか検討すべきだろう。」（神原）
もう1つの考慮点として、神原はSAP HANA以外のレプリケーション対象との整合性を挙げた。
当然ながら、DRの際にはSAP HANAだけをリプリケーションすればいいわけではない。そのため他のシステムとの整合性を検討する必要が生じるのである。この際にHSRに関しては、データベースであるSAP HANAのレプリケーションに特化しているので、他のシステムについては別途レプリケーションソリューションの購入が必要となってくる。
- 「一方のバックアップリプリケーションについては、バックアップタイミングを合わせることで様々なデータを送ることができるので整合性はとりやすい。」（神原）
また、DR先としてクラウドを選択した場合には、HSRを利用していると受ける側も常時起動している必要があるため、常に課金されることになる点にも注意が必要だ。対してバックアップリプリケーションではその必要がないため、DR先にクラウドを使用する場合にはコスト面で有利になる。
- 「切り替え時間に関しては圧倒的にミドルウェアレプリケーション、つまりHSRに軍配が上がるが、実際に検討する際には、自社の業務を踏まえて、災害時に許される停止時間やコストとの兼ね合いなど様々な要件を考慮することになるだろう」（神原）
2. SAPシステムのバックアップではフルや差分などの組み合わせ方が肝に
続いては、SAPシステムのバックアップについての検証である。
ここでまずバックアップの考え方についてだが、アプリケーションサーバの場合は基本的にシステムバックアップが推奨されている。
- 「仮想環境下であれば、仮想マシン全体のバックアップも簡単にとることができ、最新のVMware vSphereであれば差分も含めてバックアップとることもできるので、アプリケーションサーバの場合こちらを採用するのが一般的だ」（神原）
これがDBサーバ（SAP HANA）になると、当然ながら大容量となるため毎回システムバックアップを行うというのは現実的ではない。そこでシステムバックアップとデータバックアップを組み合わせて利用するかたちを採用することになる。
- 「データバックアップについては非常に複雑になってくる」とした神原は、その詳細な内容を解説した。
表 2. SAP HANA バックアップ種別
まずSAP HANAのバックアップ対象領域には、データボリュームとログボリュームが存在している。このうちデータボリュームはデフォルトで5分ごとのタイミングでセーブポイントが設けられるようになっており、一方のログボリュームではこの5分の間のデータをとることができる。
- 「そのためデータのロストを防ぎたいのであれば、まず外部ストレージへのデータのバックアップはもちろんだが、ログのバックアップもしておく必要がある」（神原）
図 3. SAP HANA データ保持（永続化）の仕組み
バックアップの方法としては、データボリュームに対しては、フルバックアップと増分差分のデルタバックアップの2種類がある。
- 「毎回フルバックアップするというのは非現実的であるため、デルタバックアップとログバックアップの2つを組み合わせるのが一般的だ」（神原）
では、どのようなタイミングでバックアップすればいいのだろうか。ここで神原はSAP HANAにおけるリカバリーの考え方を示した。
図 4. SAP HANAにおけるリカバリの考え方
- 「CTCでもメモリサイズ1TBでSAP HANA使っているが、15分に一回のログバックアップ、毎日のデルタバックアップ、毎週日曜日のフルバックアップという構成にしている」（神原）
ここであるリカバリーポイントに対してどうやってリカバリーされるのかを見てみよう。まずフルバックアップのデータが戻されて、次に差分や増分を当てていく。この間のログバックアップについては差分増分に含まれている。そして最後、まだログバックアップがされていないオンラインのログエントリーが残っていれば、完全に最新の状態にまで戻すことができるのである。
神原は次のように強調する。
- 「SAP HANAは非常に大きなデータボリュームとなるため、こうした組み合わせてバックアップ＆リカバリーを検討する必要がある」
3. SAPシステムのバックアップで注目すべきは時間よりもデータ容量
では、SAPシステムのバックアップの検証結果を見ていこう。
検証は次の2つのテーマについて実施された。
- 大容量仮想マシンイメージバックアップ（≒システムバックアップ）対応
- SAP HANA標準バックアップvsバックアップソフトウェア
まず大容量仮想マシンイメージバックアップ対応についての検証では、2.12TBの仮想マシンと1.22TBの仮想マシン、計3.34TBのデータサイズの仮想マシンについて、同時にバックアップとリストアを行った。その結果、バックアップにかかる時間は5分52秒でリストアにかかる時間は6時間59分10秒となった。
この検証結果を受けて神原は次のようにコメントした。
- 「バックアップについては、ほとんど仮想マシンのSnapShotを対象にした時間で完了していることがわかる。一方のリストアについては、バックアップボリュームからの展開となるため時間がかかると言える。もちろん、すべてのデータをフルリストアするようなケースなどまずないと思われるが、いざとなったらこれぐらいの時間がかかるのだという目安にはなるはずだ」
続いてSAP HANA標準バックアップとバックアップソフトウェア（Commvault）を比較した検証では以下のような結果となった。
表 3. 検証結果｜SAP HANA標準バックアップ vs バックアップソフトウェア
この検証結果を見ると、フルバックアップに要する時間の差は、SAP HANAのBACKINTとBackup Agent経由のオーバーヘッド、それに圧縮や重複排除の時間から来ていると推測できる。一方でリストアの時間に関してはそれほど差がなかった。
- 「フルバックアップの時間は78分と308分で差はあるが、この間にシステムが使えないというわけではない。そしていずれの環境でもバックアップ中の負荷は2%未満であるため、オンラインバックアップとして十分だと言える」（神原）
ここで注目すべきは、時間よりもバックアップデータの容量である。SAP HANA標準バックアップではほぼ100％の容量のデータがそのままバックアップされるのに対し、圧縮有、重複排除有のCommvaultバックアップでは、実に77％ものデータを削減することができるのだ。
- 「クラウドストレージのコストなどを考えると、バックアップデータ容量の差は大きいので、そこも自社の業務での要求を踏まえて検討すべきだろう」（神原）
最後に
本セミナーで解説した検証結果の詳細な内容については、SAPシステムの可用性についての検証と合わせて、下記よりダウンロード可能となっている。ぜひ目を通していただき、自社に最適なSAP S/4HANA基盤の構築に役立てていただきたい。
さいごに神原は「SAP S/4HANA の導入を検討している方に、本検証結果を参考にしていただきたい」と訴え、CTCが提供するSAP S/4HANAに最適化したIaaS「CUVICmc2（キュービックエムシーツー）」であれば、DR機能もバックアップ機能も標準で提供していることを紹介した。
CUVICmc2 が SAP ERP に最適である理由については、以下よりご覧いただけます。
-