[db tech showcase Tokyo 2014] B25: [In-Memory DB: SAP HANA] 障害・災害対策のメカニズム by SAPジャパン株式会社森﨑敏朗

db tech showacase Tokyo 2014
䛆In-Memory DB: SAP HANA䛇
㞀ᐖ䞉⅏ᐖᑐ⟇䛾䜰䝹䝂䝸䝈䝮 SAP䝆䝱䝟䞁ᰴᘧ఍♫
2014/11/12
Use this title slide only with an image

免責条項
このプレゼンテーションに含まれる情報は機密であり、SAPの専有情報であり、SAPの許可なく開示するこ
とはできません。このプレゼンテーションは、御社とのライセンス契約やその他のサービス、SAPとのサブ
スクリプションに関する合意書とは無関係です。SAPはこの文書や関連するプレゼンテーションに記載され
た事業を遂行することについて、またそれらに記載されている機能の開発やリリースについて何ら義務を負
いません。この文書や関連するプレゼンテーション、SAPの戦略や将来的な開発、製品やプラットフォーム
の方針や機能についてはすべて、予告なく変更される場合があります。この文書に含まれる情報は、何らか
の資料、コードまたは機能の提供を確約したり、約束したりするものではなく、また法的な義務を負うもの
ではありません。この文書は、明示・黙示を問わず、また商品性、特定目的適合性、非侵害に関する暗黙の
保証等（これらに限りません）何らの保証も提供するものではありません。この文書は情報提供の目的のも
ので、契約書には含まれません。SAPは誤字・脱字や誤りなどに責任を負わず、またこの文書の使用により
生じた直接損害、間接損害、結果損害等（これらに限りません）、いかなる種類の損害にも責任を負いませ
ん。
将来に関する記述にはすべてに様々なリスクや不確定要素があり、実際の結果が期待値と大きく異なる場合
もあります。これらの将来的な記述は書かれた時点の情報にすぎませんので、過度に信頼しないようご注意
いただくとともに、購入の意思決定の根拠としないようにしてください。　　　　　　　　　　　　　　　　　
© 2014 SAP SE or an SAP affiliate company. All rights reserved. 2

ᮏ᪥䛾䜰䝆䜵䞁䝎
p SAPHANAとは
p SAP HANAのパーシスタンスレイヤー
p バックアップのメカニズム
p 障害・災害対策のための冗⻑⾧長化⼿手段
p ⾼高可⽤用性：ホストオートフェイルオーバー
p システムレプリケーションとは
p ⾼高可⽤用性：システムリプリケーション
p ディザスターリカバリー：ストレージレプリケーション
p ディザスターリカバリー：システムレプリケーション
p 障害・災害対策のための冗⻑⾧長化⼿手段のまとめ

リアルタイムな情報活⽤用を⾏行行うための基盤を考えよう
データのコピー、集計、レポートの事前作成をやめることが必須
基幹系と情報系のデータ
ベースを統合し、リアルタ
イムなビジネスサイクルを
確⽴立立しましょう。
そのためにデータベースに
改⾰革を！
現状のシステムに
は、データベース
が原因で解決でき
ない問題がありま
す。
解決策：１つのデータセットで基幹系と情報系を！
そのためのインメモリー化
SAP HANA
(DRAM)
VS
Ÿ “今”のデータに基づく情報を、“今”⼊入⼿手できます
Ÿ インメモリー化により⾼高速なレスポンス時間で
Ÿ 複雑化したシステムを“シンプル化”します
SAP創設者
Hasso Plattner
現状課題：基幹系と情報系システムが分離離
基幹系
バッチ
情報系
バッチ
Cache
⾼高速化のための
複製など
Ÿ 情報は、基幹系データをバッチ加⼯工することに
よって初めて得られます
Ÿ 得られた情報は、すでに過去のものです
Ÿ これは、データベースの処理理能⼒力力による制限です

これまでのデータベースとの違い
インメモリー化＋更更新/参照性能の両⽴立立
これまでのデータベースSAP HANA
CPU
I/O遅延時間
50ナノ秒
Memory
I/O遅延時間
50,000ナノ秒
SSD
Hard DISK
Storage
マルチコア
超並列列処理理
最適化された単⼀一プラッホーム
64-‐‑‒bit アドレススペース
100GB/s スループット
6TB RAMサポート
並列列処理理のための
パーティショニング
CPU
Memory
+
ローストア＋
⼤大量量データに強いカラムストア
+
++
+
更更新処理理を⾼高速化する
デルタマージ
容量量効率率率を上げる
圧縮
データ保存を保証する
半導体 / フラッシュ / HDD
Disk
1000倍
I/O遅延時間
5,000,000ナノ秒
データ
ベース
の
配置場所
• データベースはストレージ（ハードディスク、
SSD）に置かれています。
• メモリーと⽐比較すると、SSDは1000倍、ハード
ディスクは100,000倍の遅さです。
データ
ベース
の
配置場所
• データベースはメモリー上に置かれるため段違いの速さ
です。
• 基幹系データから瞬時に集計、レポートを⽣生成します。
• 基幹系の更更新も⾼高速化

SAP HANAのパーシスタンスレイヤー
SAP HANAの永続化メカニズム
パーシスタンスレイヤ
Ø HANAデータベースのストレージ管理理、トランザ
クションログ管理理、システムリスタート時のリス
トア管理理など
Ÿ データボリューム
– データとundoログを維持するストレージ領領域
Ÿ ログボリューム
– トランザクションログ(Redo)を維持するスト
レージ領領域
– データベースの変更更ログを保存するエリア
Ÿ セーブポイント
– データの変更更分をデータボリュームに書き込む
– バッファー領領域をログ領領域に書き込む
Ÿ Commit
– ログエントリーをログボリュームに書き込む
SAP HANA
メモリ
データベース
ローストアカラムストア
Commitによる変更更
の書き出し
定期的な⾃自動
セーブポイント
ログボリュームデータボリューム
Undoログ Data
ストレージ
Redoログ

データ書込の概要 Write(カラムストア,ローストア)、Commit
パーシスタンス
レイヤー(ディスク)
Virtual Fileとredoログ/
undoログエントリを書く
Commitを書くCommitログ
エントリーを
書く
ログを
ディスクに書く
ディスク
アプリケーションカラムストアローストアトランザクション
マネージャ
レイヤー
Write
オペレーション
Write
Commit
インメモリーオペレーション
Virtual Fileをデルタログに書く
インメモリーオペレーション
ログを書く
Commit

データ書込の概要デルタマージ、セーブポイント
アプリケーションカラムストアローストアトランザクション
マネージャ
レイヤー
レイヤー(ディスク)
デルタマージ
（テーブル毎）
Phase1
変更更ページの永続化
永続化されていない
ページの取得取得したページ
の永続化
Phase1で変更更されたページをコピ
ー
リスタート情報とオープン
トランザクションのリストを書く
コピーページを書く
アンカーページを
書く
Phase2
Phase3
セーブポイント
ディスク

テーブルロードのメカニズム
テーブルロード
– ストレージ上のData Volumeからメモ
リー上にテーブルをロード
• ブート時、または、初回アクセス時
– 適⽤用すべきログが存在するときは、ログ
リプレイを⾏行行い、最新の状態に
SAP HANA
メモリ
データベース

ブート時にメモ
リー上にロードさ
れる
Data Volume
ログリプレイ
Log
Volume
ストレージ

即ち、Data Volume, Log VolumeはHANAインメモリーデータベースのバックアップ

バックアップのメカニズム
SAP HANAのバックアップ機能
バックアップ
– メモリー上のデータベースを直接バックアップ
するものではない（メモリーtoディスクはパー
シスタンスレイヤーの役割）
– リカバリのデータソース
• データボリューム
• ログボリューム
• オンラインredoログ
– ストレージ上のデータボリューム/ログボ
リュームを複製する作業
• 常にデータ/ログボリュームの全体が対象
• HANA Boxの外部にバックアップを配置することが
望ましい
– バックアップが始まると、メモリー上の未永続
化情報はストレージに書き込まれるので最新の
状態がバックアップされる
SAP HANA Box
メモリ
データベース
Log
Volume
Data
Volume
ストレージ
Log
Volume
Data
Data
LogVolume
Volume
Data
Volume
LogVolume
Volume

バックアップオペレーション
バックアップを開始
Ÿ SAP HANA Studioを開きます。
Ÿ Administration Consoleで、利利⽤用している
SAP HANAシステム上で右クリックします。
Ÿ “Backup and Recovery” を選択し、
“Back up System…”を選択します。
Ÿ Backup Destination（バックアップ先）と
Backup Prefix（バックアップファイルのプ
リフィクス）を指定します。
Ÿ 設定を確認します。
Ÿ 最終確認し実⾏行行します。

データバックアップの内部プロセス
データベース
クライアントバックアップマネージャServer1Server2Server3
バックアップマネー
ジャにフォワード
バックアップ
リクエスト
Global savepointの開始
データベースのスナップ
ショットとして保存
変更更ページを
データベース全体のス
ナップショットの作成
Phase2
Savepointの
phase2を実⾏行行
Savepointの
Savepointの
Phase3
残りのデータを書く残りのデータを書く残りのデータを書く
Savepointに基づいた
内部スナップショット
を作る
を作る
を作る

データバックアップの内部プロセス
データベース
クライアントバックアップマネージャServer1Server2Server3
Savepointに
基づいた内部
スナップショット
を作る
Savepointに
基づいた内部
を作る
Savepointに
基づいた内部
を作る
Backup Executorにsavepoint
をファイルに書き出すように指⽰示
レイヤからの
savepointの
ページを読みこみ
⼀一貫性チェック
を⾏行行い、
バックアップ
ファイルに
書く
レイヤからの
savepointの
を⾏行行い、
バックアップ
ファイルに
書く
レイヤからの
savepointの
を⾏行行い、
バックアップ
ファイルに
書く
スナップショットをファイルへ出⼒力力
Backup 終了了のエントリーを
バックアップカタログに出⼒力力

SAP HANAバックアップ⽅方式
SAP HANAに格納されているデータ及びログのバックアップ⽅方式は、2通りあります。
HANAのバックアップコマンドを
利用した方式
3rdパーティバックアップツールを
利利⽤用した⽅方式
l HANAのバックアップコマンドの出⼒力力先とし
てNFSマウントされたバックアップストレー
ジを使⽤用する⽅方法
SAP HANA
Database
バックアップ
ストレージ
（NFS）
l 3rdパーティバックアップツールを介して出
⼒力力先としてNFSマウントされたバックアッ
プストレージを使⽤用する⽅方法
SAP HANA
Database
バックアップ
ストレージ
（NFS）
バックアッ
プエージェ
ント（ 3rd
パーティ）
2014/11現在、以下のツールがCertifiedされています。
l Symantec NetBackup 7.5
l IBM Tivoli Storage Manager 6.4、7.0
l Commvault Systems Simpana 10.0
l HP Data Protector 7.0/8.1
l EMC Data Domain Boost for Databases and Applications 1.0
l EMC NetWorker 8.2
l SEP Sesam 4.4
*バックアップストレージは、別途ご準備頂く環境になります。

SAP HANAのリカバリー機能
リカバリー
– 以下の⼀一連の作業が実⾏行行される
• バックアップからデータボリューム、ログボ
リュームをリストアする
• HANAインスタンスのリブート
• テーブルのメモリーへのロード
• ログリプレイ
– リカバリーポイント
• Data + Log → 最新状態
• Data→ ログ内容は反映されない
• ポイント・イン・タイム
SAP HANA Box
メモリ
ログリプレイ
Log
Volume
Log
Volume
データベース

メモリー上にロード
Data Volume
ストレージ

Data
Data
LogVolume
Volume
Data
Volume
LogVolume
Volume

データベースの通常オペレーション中のバックアップ
3
データバックアップ
(外部バックアップ先)
2
ログバックアップ
(外部バックアップ先)
Time
0
Crash
1
ログエリアから
最新のログエン
トリ

リカバリオプション
3 2 1
0Crash
オプション条件ステップ
1最新の状態に
直近のコミットされた状態にリストアする
と以降降のログが存在
すること
時間
1. データバックアップからセーブポイントを
データ領領域にリストアする
2. リストアされたセーブポイントからデータ
ベースをリスタートする
3. ログバックアップからログをリプレイする。
（可能ならば、オンラインログも）
2過去のある時点に
ポイント・イン・タイムリカバリ – 任意
の指定時間の状態にリストアする
指定する時点を含む
とログバックアップ
が存在すること
3. ログバックアップとオンラインログから、指
定した時点までログをリプレイする
3指定したデータバックアップかスト
レージスナップショットを使⽤用（ロ
グの再⽣生なし）
データバックアップの状態にリストアする。
（データバックアップ以降降の変更更は失われる）
が存在すること
3. オンラインログをクリアする

リカバリーオペレーション
リカバリを開始
Ÿ SAP HANA Studioを開きます。
Ÿ Administration Consoleで、利利⽤用している
SAP HANAシステム上で右クリックします。
Ÿ “Backup and Recovery” を選択し、
“Recover System…”を選択します。
Ÿ SIDadmとパスワードを⼊入⼒力力します。
Ÿ リカバリータイプを指定します。
Ÿ 関連するデータバックアップとログエント
リを指定します。
Ÿ 最終確認し実⾏行行します。

障害・災害対策のための冗⻑⾧長化⼿手段
⾼高可⽤用性とディザスターリカバリー
ビジネス継続性
データセンター内の⾼高可⽤用性データセンター間のディザスターリカバリー
1. SAP HANA ホストオートフェィルオーバー
(スケールアウト構成でのスタンバイ)
2. SAP HANA システムレプリケーション
1. SAP HANA ストレージレプリケーション
2. SAP HANA システムレプリケーション

センター内での⾼高可⽤用性⼿手段
SAP HANAで⾼高可⽤用性のシステムを構築するにあたり、2つの⽅方法が準備されてい
ます。
①ホストオートフェールオーバー
②ソフトウェアベースのシステム
レプリケーション
プライマリシステムセカンダリシステム
アクティブスタンバイ
Master
Name
Server
Index
Server
Data
Disks
Log
Disks
Name
Server
Index
Server

センター間で実現可能な冗⻑⾧長化⼿手段
SAP HANAでディザスターリカバリーシステムを構築するにあたり、2つの⽅方法が準
備されています。
①ハードウェアベースのストレージ
data
logs
プライマリシステムリプリケーションさ
れたシステム
②ソフトウェアベースのシステム
プライマリシステムセカンダリシステム

⾼高可⽤用性：ホストオートフェィルオーバー
SAP HANA マルチノードアーキテクチャ
ランドスケープ情報のメンテナンス
データ保持と全オペレーションの実⾏行行
パフォーマンスデータの収集
テキスト分析のプリプロセッサ
HANAスタジオ・リポジトリの更更新
リモートからのstart/stop制御
ソフトウェア更更新の管理理
シングルノード
構成
SAP HANA Appliance
(Master) Node
マルチノード構成
(Master) Name Server
(Master) Index Server
Statistics Server
Preprocessor
SAP HANA Studio Repository
SAP Host Agent
Software Update Manager
(Slave) Node 1
Name ServerName Server
Index Server
Preprocessor
SAP Host Agent
(Slave) Node n
Index Server
Preprocessor
SAP Host Agent
フェィルオーバーやリカバリー⽤用の共有ストレージ

SAP HANA データベースランドスケープ
LOG
DISK
DATA
DISK
インメモリ
LOG
DISK
DATA
DISK
LOG
DISK
DATA
DISK
パーシスタンスレイヤ
LOG
DISK
DATA
DISK
LOG
DISK
DATA
DISK
*Standby Host:
Name Server (active)
Index Server (standby)
シングルノード及びス
ケールアウト構成でも、
Shared Nothing
Conceptで稼働
スタンバイホストは固有
のパーシスタンスを持た
ない

SAP HANA スケールアウトとホストオートフェィルオーバー
スケールアウトクラスタは、データの分散も可能です。
Ÿ 1つのホストよりも⼤大きいデータサイズを扱え、シェアードナッ
シングアーキテクチャーを基に拡張します。
Ÿ スペア/スタンバイとして1つ以上のホストを置くことで、容易易に
HAオプションを提供します。
Ÿ 完全なトランスペアレントでRead/Writeの分散
ホストオートフェィルオーバーは、Name Serviceによっ
て提供されます。
Ÿ 構成されたクラスターは、SAP HANAの中のname serviceにより
管理理されます。
Ÿ 定期的に、アクティブなクラスターメンバーをチェックします。
Ÿ 問題が発⽣生した場合、スタンバイハードウェアへ完全に⾃自動化さ
れたテイクオーバーを開始します。
複数スタンバイサーバーを構成することができます。
Ÿ オプション: スタンバイサーバーへWorkerをマップすることで
フェイルオ－バグループを構成します。
Shared Storage
Server 1
Server 2
Server 3
Server 4
Server 5
Server 6
Standby Server
Name
server
Name
server
Name
server
Name
server
Name
server
Name
server
Name
server
最⼩小限のセットアップ:
Server 1
Standby Server
SAN
Storage
Storage
Connector
API
Name
server
Name
server

ホストオートフェィルオーバー構成
スタンバイサーバを⽤用意し、障害発⽣生時に障害サーバに代わり起動させる⾼高可⽤用性
のためのクラスタリング構成です。
障害が発⽣生した場合、予め⽤用意した「スタンバ
イ」サーバが共有ディスクストレージから障害
が発⽣生したサーバのデータを読み込むことでそ
のサーバを代替します。
※図はスケールアウト構成時の動作ですが、こ
の構成はシングル構成時にも取ることが可能で
す。

スケールアウトとクライアント管理理
クライアント:
Ÿ クライアントにインストールした時、HANAデータベースへのコンタ
クト⽅方法について初期情報を取得します。－多くの場合、1つのホ
ストが提供されます。
Ÿ シングルポイント障害を防⽌止するために、スケールアウトのケース
では多くのホストが提供されるべきです。
Ÿ リストは、HANAクラスタへ最初の接続を確⽴立立するために必要なだけ
です。－その後、クライアントは、データベースName Serverから
完全なトポロジを取得します。
Ÿ スタンバイホストを含むホスト名の完全なリストは、保存する必要
があります。
User store:
Ÿ ユーザーと暗号化されたパスワード情報の次
に、“hana1;hana2;hana3”のホスト名のリストが含まれます。
Ÿ データベースインターフェースのsqldbc (SAP Appl. Server,
hdbsql, ODBC, pythonなど) が、このuser store使⽤用することがで
きます。
アルゴリズム:
Ÿ 最初のコンタクトポイントを⾒見見つけるために、ラウンドロビン処理理
を使⽤用します。
SQL clients:
SAP Appl. Server
hdbsql
User Store
hana1;hana2;hana3
ラウンドロビン
hana1 hana2 hana3
HANA Scale-Out
hana1
Name
Server
Index
server
Data
Disks
hana3
standby
Name
Server
Index
server
Log
Disks
hana2
Name
Server
Index
server

システムレプリケーションとは
システムレプリケーション
Ÿ HANA組込みのインメモリーDBレプリ
ケーション機能
構成
Ÿ 最⼩小構成は、プライマリ／セカンダリー
の２ホスト
Ÿ プライマリーホスト：稼働系
Ÿ セカンダリホスト：同⼀一のデータ内容を
保持する待機
– データのプリロードが必要
クラスターマネージャソフト
Ÿ HP ServiceGuard
Ÿ SUSE Cluster
Ÿ SAP Landscape Virtualization
Management中)
Ÿ その他~∼動作確認中、または、個別の導
⼊入コンサルティングサービスで対応

システムリプリケーションモードの種類
同期⾮非同期
Synchronous
（FULLオプション付き）
Synchronous
Synchronous in memory
Asynchronous

レプリケーションモードの違い
Synchronous（Fullオプション）
Primary 㻿㼀㻻㻼
Secondary
トランザクション
Data Log Data Log
l ログはセカンダ
リーサイトに同期
転送される
l ログ転送は、セカ
ンダリーサイトの
ディスク保存まで
セカンダリと接続が失われても障害が回復復されるまでプラ
イマリも待ち状態
Synchronous
Primary Secondary
トランザクションlオプションと同様
Data Log Data Log
l 正常時の動きは
Syncronous（Ful
Synchronous in memory
Primary Secondary
トランザクションメモリ
ACK
Data Log Data Log
Asynhcronous
Primary Secondary
トランザクション
バ⑁フ␼ー
Data Log Data Log
セカンダリと接続が失われると障害によるデータロスはあり得る
リーサイトに同期
転送される
l ログ転送は、セカ
ンダリーサイトで
のメモリー保存ま
で
リーサイトと接続
されているネット
ワーク経路路にログ
転送が開始される
と完了了。
l ⾮非同期転送される

ᮏ᪥䛾䜰䝆䜵䞁䝎
p SAPHANAとは
p SAP HANAのパーシスタンスレイヤー
p バックアップのメカニズム
p 障害・災害対策のための冗⻑⾧長化⼿手段
p ⾼高可⽤用性：ホストオートフェイルオーバー
p システムレプリケーションとは
p ⾼高可⽤用性：システムリプリケーション
p ディザスターリカバリー：ストレージレプリケーション
p ディザスターリカバリー：システムレプリケーション

⾼高可⽤用性：システムレプリケーション
パフォーマンス最適化
パフォーマンス最適化オプ
ション
Ÿ いつでもテイクオーバーできる
ように事前に準備したセカンダ
リシステム
Ÿ いつでもテイクオーバーできる
ように、セカンダリーのSAP
HANAのメモリにデータはプリ
ロードされる
Ÿ 最⼤大限に短縮したテイクオー
バーとパフォーマンスランプ
Data Center 1
Clients Application Servers
OS: DNS, hostnames, virt. IPs
Primary
(active)
Name Server
Index server
Secondary
(active, data pre-loaded)
Name Server
Index server
HA Solution Partner
HA Solution Partner
Transfer
by
HANA
database
kernel
Internal
Disks
Internal
Disks
Data
Disks
Log
Disks
Data
Disks
Log
Disks

⾼高可⽤用性：システムレプリケーション
コスト最適化
コスト最適化オプション
Ÿ セカンダリーで⾮非本番システム
(QA/DEV)を稼動
Ÿ リソースは、1つ以上の⾮非本番
(QA/DEV)システムで利利⽤用するた
め、データのプリロードはでき
ない
Ÿ テイクオーバーする際、⾮非本番
のオペレーションは終了了する必
要がある。
Ÿ コールドスタートアップと同様
のテイクオーバーパフォーマン
ス
Data Center 1
Primary
(active)
Name Server
Index server
Secondary
PRD
shadow
operation
Name Server
QA/DEV
running
Index server
HA Solution Partner
HA Solution Partner
Transfer
by
HANA
database
kernel
Internal
Disks
Data
Disks
Log
Disks
Internal
Disks
Data
Disks
Log
Disks
Data
Disks
QA/DEV
Log
PRD Disks

ディザスターリカバリー：ストレージレプリケーション
HA環境におけるDisaster Toleranceの1つのオプションとして、ハードディスクI/
Oサブシステムを使⽤用したレプリケーションをサポートします。
n ストレージミラーリング⽅方式
§ 同期ストレージミラーリング
§ ⾮非同期ストレージミラーリング
n 再スタートフェールオーバーデータセンター
（全てのデータがDISKにありHANA上にロー
ドする必要があります。）
データセンター1 データセンター2
OS: DNS, hostnames
Primary
Name
Server
Index
server
Name
Server
Index
server
Name
Server
Index
server
　　　　　OS: Mounts
Data
Volumes
Log
Volume
HA Solution Partner
Data
Volumes
Log
Volume
䝜䞊䝖㻌1755396 - Released DT solutions for SAP HANA with disk replicationཧ↷
Secondary
(inactive)
Name
Server
Index
server
Name
Server
Index
server
Name
Server
Index
server
　Storage
　Mirroring
HA Solution Partner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume

ディザスターリカバリー：ストレージレプリケーション
2つの利利⽤用⽅方法
ストレージレプリケーションでは、2つの利利⽤用⽅方法があります。
n セカンダリーサイトでQA、DEV環境との共存
Clients Application
Servers
Data Center 1 Data Center 2
OS: DNS, hostnames
Primary
Name
Serve
Index
server
Name
Servr
Index
server
OS: Mounts
Data
Volumes
Log
Volume
Name
Servr
Index
server
Secondary
Prod. (inactive),
QADEV (active)
Name
Server
Index
server
Name
Server
Index
server
Name
Server
Index
server
HA Solution Partner
Storage Mirroring
HA Solution Partner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
QA/DEV
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
n セカンダリーサイトでコールドスタンバイ
Clients Application
Servers
OS: DNS, hostnames
Primary
Nam
Servr
Index
server
Name
Serve
Index
server
OS: Mounts
Data
Volumes
Log
Volume
Name
Servr
Index
server
Secondary
(inactive)
Name
Server
Index
server
Name
Server
Index
server
Name
Server
Index
server
HA Solution Partner
Storage Mirroring
HA Solution Partner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume

ディザスターリカバリー：システムレプリケーション
パフォーマンス最適化
パフォーマンス最適化オプション
Ÿ ⾼高速テイクオーバー
Ÿ 最⼤大限短縮したパフォーマンスランプ
(seconds to less minutes)
Ÿ SYNC ASYNC が可能
いくつかのクラスターオプション
Ÿ いくつかのHWパートナーは、予め
パッケージ化されたオプションを準備。
Step-‐‑‒by-‐‑‒Step Implementation
Guide (updated recently to
SPS8):
Ÿ https://scn.sap.com/docs/DOC-‐‑‒47702

Primary
(active)
Name
Serve
r
Index
serve
r
Name
Serve
r
Index
serve
r
OS: Mounts
Data
Volumes
Log
Volume
Name
Serve
r
Index
serve
r
Secondary
(active, data pre-loaded)
Name
Server
Index
server
Name
Server
Index
server
Name
Server
Index
server
HA Solution Partner
HA Solution Partner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Transfer
by
HANA
database
kernel

コスト最適化
コスト最適化オプション
Ÿ SYNC ASYNC が可能
セカンダリーの⾮非本番と併⽤用
稼動によるTCO削減
Ÿ ⾮非本番⽤用で使⽤用するもう⼀一つの
DISKスタックが必要
Step-‐‑‒by-‐‑‒Step Implementation
Guide (updated recently to
SPS8):
Ÿ https://scn.sap.com/docs/DOC-‐‑‒47702

Primary
(active)
Name
Serve
r
Index
serve
r
Name
Serve
r
Index
serve
r
OS: Mounts
Data
Volumes
Log
Volumes
Name
Serve
r
Index
serve
r
Secondary
(active,)
shadow
operation
Name
Server
Index
server
PRD
Name
Server
QA/Index
DEV
running
server
Name
Server
Index
server
HA Solution Partner
HA Solution Partner
Data
Volumes
Log
Volumes
Data
Volumes
PRD QA/DEV
Log
Volumes
Data
Volumes
Log
Volumes
Transfer
by
HANA
database
kernel
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume

System Replication応⽤用構成１
System Replicationでは下記のように段重ねや1:nのレプリケーションが可能です。
キャンパス
クラスタ
メトロ
クラスタ
ジオ
クラスタ
遠隔地
10km程度度100km程度度
１：１１：ｎ
100km以上
カスケード⽅方式や1:nのSystem replicationも可能です。

System Replication応⽤用構成２
レプリケーションの種類を変えることが可能で、下記のように更更に強固な構成を
組むことも出来ます。
キャンパス
クラスタ
メトロ
クラスタ
同期
⾮非同期
100km以上
遠隔地
RPO ≠ 0
RTO 30 min
本番ローカルスタンバイ
ジオ
クラスタ
同期
遠隔地のスタンバイ構成にも更更に
スタンスタンバイを持たせる

System Replication応⽤用構成3
キャンパス
クラスタ
メトロ
クラスタ
例例：在庫管理理
RPO=6時間、RTO=18時間
分、許容停⽌止時間＝24時間、
データの⾮非同期複製（3時間
毎）でシステム切切り替え
ジオ
クラスタ
同期
⾮非同期
⾮非同期⾮非同期
さらに多拠点DCとのレプリケーションで、BCP構成を強化距離離制限なし

障害・災害対策のための冗⻑⾧長化⼿手段のまとめ
⾼高可⽤用性ソリューションの⽐比較
スケールアウト 1+1
(ホストオートフェィルオーバー)
アクティブスタンバイ
Master
Name
Server
Index
Server
Data
Disks
Log
Disks
Name
Server
Index
Server
ストレージ
システム
2つの選択肢を持つシステムレプリケーション (1+1)
Primary
(active)
Name Server
Index server
Secondary
パフォーマンス最適化 (
データプリロード)
(active, data pre-‐‑‒loaded)
Name Server
Index server
Transfer
by

HANA
database
kernel
Internal
Disks
Internal
Disks
Data
Disks
Log
Disks
Data
Disks
Log
Disks
or
コスト最適化
Secondary
PRD
shadow
operation
Name Server
QA/DEV
running
Index server
Data
Disks
PRDQA/DEV
Log
Disks
Data
Disks
Log
Disks

ディザスターリカバリーソリューションの⽐比較
2つの選択肢を持つシステムレプリケーショ
ン (1+1)
Primary
(active)
Name Server
Index server
パフォーマンス最適化 (
データプリロード)
Secondary
(active, data pre-‐‑‒loaded)
Name Server
Index server
Transfer
by

HANA
database
kernel
Internal
Disks
Internal
Disks
Data
Disks
Log
Disks
Data
Disks
Log
Disks
or
コスト最適化
Secondary
PRD
shadow
operation
Name Server
QA/DEV
running
Index server
Data
Disks
Log
Disks
Data
Disks
Log
Disks
PRDQA/DEV
2つの選択肢を持つストレージレプリケー
ション (1+1)
Storage
Mirroring
Primary
(active)
Name Server
Index server
セカンダリーサイトでコー
ルドスタンバイ
Secondary
(stanby)
Name Server
Index server
External
Disks
External
Disks
Data
Disks
Log
Disks
Data
Disks
Log
Disks
or
セカンダリーサ
イトでQA/DEV
環境との共存
Secondary
Name Server
Index server
Storage
Mirroring QA/
Data
Disks
Data
DisksDEV

Log
Disks

⾼高可⽤用性とディザスターリカバリーのまとめ
…system operational
災
害
発
生
時
点
RPO RTO
operation resumed…
time
Sync or
backup
prepare detect recover perf. ramp
KPIs:
• ⽬目標復復旧時点 (RPO)= worst-‐‑‒case data-‐‑‒loss （データをいつの状態まで戻すか）
• ⽬目標復復旧時間 (RTO)= time to recover from outage （データをどれだけ早く戻すか）
Solution Used for Cost RPO RTO Perf. ramp
Backup Recovery HA DR $ high high med
SAP HANA Host Auto-Failover HA $ 0 med long
SAP HANA Storage Replication w/ QA, Dev. DR $$ 0* med long
SAP HANA System Replication HA DR $$$ 0* low short
SAP HANA System Replication w/ QA, Dev. HA DR $**/$$ 0* med long
*synchronous solution
** single host installations
＊⾼高可⽤用性：HA(High Availability)、ディザスターリカバリー： DR(Disaster Recovery)

[db tech showcase Tokyo 2014] B25: [In-Memory DB: SAP HANA] 障害・災害対策のメカニズム by SAPジャパン株式会社森﨑敏朗

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a [db tech showcase Tokyo 2014] B25: [In-Memory DB: SAP HANA] 障害・災害対策のメカニズム by SAPジャパン株式会社森﨑敏朗

Semelhante a [db tech showcase Tokyo 2014] B25: [In-Memory DB: SAP HANA] 障害・災害対策のメカニズム by SAPジャパン株式会社森﨑敏朗 (20)

Mais de Insight Technology, Inc.

Mais de Insight Technology, Inc. (20)