[INSIGHT OUT 2011] C27 今こそBCPを考える～コスト・要件に応じたデータベースのディザスタ・リカバリを提案しよう！～(kishida)

今こそＢＣＰを考える
～コスト・要件に応じたデータベースの
ディザスタ・リカバリを提案しよう！～

2011/10/20
株式会社日立ソリューションズ
サービス事業統括本部ビジネスフロント部

岸田聡

© Hitachi Solutions, Ltd. 2011. All rights reserved.

Contents
～コスト・要件に応じたデータベースのディザスタ・リカバリを提案しよう！～

１. BCPの必要性

２. データベースのディザスタ・リカバリ

３．データ同期方式

４. 各データベース製品におけるデータ同期方式

５．その他、検討事項



１. BCPの必要性


１ BCPの必要性

システム単位にサーバを一拠点集中型で管理

天災(地震/台風等)や大規模停電に
よりサーバ設置場所が被災
被災
システム全停止

サービス提供ができない＝機会損失
大規模災害時のシステム停止時間を最小限とする
金融決済業務では1時間で6億円

© Hitachi Solutions, Ltd. 2011. All rights reserved. 3

１ BCPの必要性

本番稼動しているシステムと同一の構成を別拠点に
用意し、被災時に接続先を変更することで、同一業務が
継続可能

被災

システム全体のコストを削減するために
災対サイトは最低限運用可能なスペックの
サーバーを用意するという考え方もある



２. データベースのディザスタリカバリ


２データベースのディザスタ・リカバリ

システム内でデータベースの更新はリアルタイムで発生
災対サイトのデータベースに対して現用サイトでの
更新が反映されていなければ、業務継続は困難

現用サイト
災対サイト

更新情報
リアルタイム
更新

顧客要件を満たす
データ同期方式の提案


３. データ同期方式


３-１データ同期方式決定のための顧客要件

顧客要件として最低限必要な情報は2点

RPO：Recover Point Objective (目標復旧時点)
業務／情報システムの停止からの復旧時に、
どの時点のデータまでを保証するか。

RTO：Recover Time Objective(目標復旧時間)
業務／情報システムの停止から、定められたレベルに
サービスが復旧するまでに必要となる経過時間。


３-１データ同期方式決定のための顧客要件

RPOとRTO
更新更新更新更新

障害サービス
再開

バックアップ
リストア

RPO RTO
時間軸


３-２データベースのデータ同期方式の選択

RPO/RTOを満たすデータ同期方式を提案

RPO要件が0～数時間 RPO要件が半日以上

• 各データベース製品の機能 • ストレージの遠隔地コピー機能
• 3rdベンダーのデータベース • クラウド利用
同期製品

更新情報の同期バックアップの転送

RPO：0秒 ⇒ 完全同期

RPO：1秒以上 ⇒ 非同期


３-２データベースのデータ同期方式の選択
更新情報の同期転送
現用サイト災対サイト

ﾈｯﾄﾜｰｸ

更新 DB DB
情報
両サイトのデータベースがどちらも更新完了
した時点でデータがcommitされる

更新情報の非同期転送

ﾈｯﾄﾜｰｸ

更新 DB DB
情報
現用サイトのcommitを最優先する
更新ログは順次転送する

３-３データ同期方式決定における検討事項

• 完全同期方式の同期失敗時(システム障害)の対応
同期方式による影響 • 非同期の場合の被災時データ欠落の対処

サイト間通信速度 • RPO要件により転送速度を決定

• データ同期によるリソースの使用状況
現用サイトへの影響 • ジョブや監視等の運用関連


３-３データ同期方式決定における検討事項

• 被災時のサービルレベル
災対サイトリソース • 通常時のリソース活用
• 災対サイトのハード・ソフト及び保守費用

現用サイト
災対サイト

更新情報参照

参照系・分析系の業務を
提供するシステム(例) 提供するシステム(例) 災対サイトで実施することで
・基幹システム・基幹システム現用サイトのデータベースの
・情報系システム負荷を軽減することが可能。



４.各データベース製品におけるデータ同期方式


４-１ Oracleデータベースの同期方式

対策案
BCP対策案詳細
Oracle機能／製品 Oracle Data Guard Oracle Database E.E.で標準提供される
機能。物理レベル・論理レベルの同期方
式を選択可能。
レプリケーション Oracle Databaseが標準提供するマテリ
アライズド・ビューによるレプリケー
ション
Oracle GoldenGate データ同期製品
3rdベンダーの製品 SharePlex for Oracle 日本クエスト・ソフトウェア社が提供す
る論理レベルでのデータベース同期製品

Standby Express 3G YDC社が提供する物理レベルでのデータ
ベース同期製品
クラウド連携 AWS – Oracle連携バックアップをAWS上に保持し、被災時
にAWS上のデータベースを参照する方式。



Oracle Data Guard
プライマリデータベーススタンバイデータベース

※
NSS/NSA ﾈｯﾄﾜｰｸ RFS
LGWR
更新情報の
自動転送
アーカイブ適用
更新 or SQL
情報

オンラインデータスタンバイデータ
REDOログ
REDO ファイル REDOログファイル
REDO

※ R10.2 以前の名称は、LNS


Oracle Data Guardの特徴

・完全同期を含めた厳しい顧客要件の実現が可能

・REDO APPLY（フィジカルDG）、SQL APPLY（ロジカルDG）と
要件に合わせた構成が可能

・Active Data Guard/Flash Back 機能等を併用することで
災対サイトを有効活用
(SQL APPLYの場合、常時参照可能)

・REDOログを用いるため、データベースへの負荷が少ない

・オプション機能を使用することで、ネットワーク転送量の削減や
セキュリティ対策が可能



マテリアライズド・ビューによるレプリケーション
マスター・サイトマテリアライズドビュー・サイト

ﾈｯﾄﾜｰｸ

リフレッシュ時に
更新情報を転送

更新
情報

データマテリアライズドデータ
ファイルビューログファイル



マテリアライズド・ビューによるレプリケーションの特徴

・完全同期を含めた厳しい顧客要件の実現が可能

・災対サイトのデータベースは常時参照可能

・接続互換性が保証されている場合、バージョンが異なる場合でも
レプリケーション可能

・オブジェクト単位で同期設定が可能

・アドバンスト・レプリケーション以外は Standard Edition/Standard
Edition One で構成可能



Oracle GoldenGate
ソースデータベースターゲットデータベース

DataPump
ﾈｯﾄﾜｰｸ
Trail
Trail Collector ファイル
ファイル
LGWR 更新情報の
自動転送 Replicat
CAPTURE
更新
SQL
情報

オンラインデータデータ
REDOログ
REDO ファイルファイル



Oracle GoldenGateの特徴


・バージョン、プラットフォームの前提が少なく、多様な組合せが可能

・Oracle以外のデータベースにも対応




SharePlex for Oracle
ソースデータベースターゲットデータベース

EXPORT
ﾈｯﾄﾜｰｸ
キュー
IMPORT
READER
キュー自動転送 POST
CAPTURE
更新キュー SQL
情報

オンラインデータデータ
REDOログ



SharePlex for Oracleの特徴

・Standard Edition/Standard Edition One で構成可能


・バージョン、プラットフォームの前提が少なく、多様な組合せが可能


・コミット前の情報を災対サイトに転送するため、災対サイトの
データベースへの反映が比較的高速

・オブジェクト単位で同期設定が可能



Standby Express 3G
プライマリデータベーススタンバイデータベース

Agent ﾈｯﾄﾜｰｸ Agent

自動転送
アーカイブ
適用
更新
情報

アーカイブデータデータ
REDOログ



Standby Express 3Gの特徴

・Standard Edition/Standard Edition One で構成可能

・災対サイトのデータベースは同期をスキップして参照可能




AWS連携
日次でAWS上にOracleデータベースのバックアップを保持し、On-Premiseの障害時はAWS上で
の業務継続を実現するサービスを提供致します。
日次バックアップ運用
On-Premise
ＡｍａｚｏｎＳ３へ
バックアップ

ＡｍａｚｏｎＳ３
DBサーバ

お客様のデータをＡｍａｚｏｎＳ３のバケットへバックアップします。
保存されたデータはＡｍａｚｏｎＳ３のバージョニング機能やアクセス制御メカニズムで保護されます。
On-Premise障害(被災)時
On-Premise
障害発生

DBサーバ DBサーバ

ＡｍａｚｏｎＳ３ＡｍａｚｏｎＥＣ２

ＡｍａｚｏｎＥＣ２に代替サーバを起動、ＡｍａｚｏｎＳ３のバックアップデータによりＤＢをリストアします。


AWS連携の特徴

・災対データベースサーバの初期投資費用が不要
被災時ディザスタサイト切り替えまで、Amazon S3の課金料のみ発生
⇒ ただし、運用(ジョブ)に関する費用は発生

※Oracle Data Guard構成も実現可能であるが、通信料やEC2の
課金料を考慮するとオンプレミス環境の方が安価となることが
考えられる。


４-２ SQL Serverデータベースの同期方式

SQL Server ログ配布
プライマリサーバセカンダリサーバ

ﾈｯﾄﾜｰｸ

コピージョブ
による転送
トランザク復元ジョブによる
ションログトランザクション
バックアップ
更新ログの適用
情報

トランザクデータデータ
ションログファイルファイル


４-２ SQL Serverデータベースの同期方式

SQL Server ログ配布の特徴

・SQL Serverの標準機能で構成可能


４-３ MySQL データベースの同期方式

マスタースレーブ構成
マスターデータベーススレーブデータベース

ﾈｯﾄﾜｰｸリレーログ

更新情報の
自動転送
リレーログの
自動適用
更新バイナリログ
情報

ストレージストレージ
エンジンエンジン


４-３ MySQL データベースの同期方式

マスタースレーブ構成の特徴



４-４ストレージ機能によるデータベースの同期方式


【参照時】
同期停止
更新 ↓
情報ディスク内データベース起動
差分情報の
自動転送
or
定時転送

データベースﾈｯﾄﾜｰｸデータベース


４-４ストレージ機能によるデータベースの同期方式

ストレージ機能によるデータベースの同期方式の特徴

・災対サイトのデータベースは参照可能(ディスク同期の停止)

・ストレージ内の差分のみを転送するため、データベース機能よりも
ネットワーク転送量が少なくなる場合がある。



５. その他、検討事項


５その他、検討事項

• 災対サイトデータベースへの初期データ移行方法
初期データ移行 • 初期データ移行時システム停止時間の考慮

現在稼動しているシステムに対して災対サイトを構成する場合、
データ同期開始前に現用サイトと災対サイトのデータベース内の
データを完全に一致させる必要がある。
(データベース全体ではなくレプリケーション対象のみでも可)

現用サイト運用システム停止(データ移行) 現用サイト運用再開

計画起動
現用サイト停止

災対サイト起動

データ移行データ確認他災対運用開始


• 同期用ネットワークの専用線化
セキュリティ対策 • ネットワーク転送時の暗号化

• 災対サイトのアプリケーションサーバの構成検討
アプリケーション • クライアントの接続先変更

現用環境
• 現用環境自身をクラウド化
構成再検討



今回御紹介したデータベースのディザスタリカバリ方式は、
あくまでも一例です。

顧客要件に応じて考え方が変わってきます。

今後の提案時のお役に立てれば幸いです。


END

2011/10/20
株式会社日立ソリューションズ
サービス事業統括本部ビジネスフロント部


[INSIGHT OUT 2011] C27 今こそBCPを考える～コスト・要件に応じたデータベースのディザスタ・リカバリを提案しよう！～(kishida)

[INSIGHT OUT 2011] C27 今こそBCPを考える～コスト・要件に応じたデータベースのディザスタ・リカバリを提案しよう！～(kishida)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to [INSIGHT OUT 2011] C27 今こそBCPを考える～コスト・要件に応じたデータベースのディザスタ・リカバリを提案しよう！～(kishida)

Similar to [INSIGHT OUT 2011] C27 今こそBCPを考える～コスト・要件に応じたデータベースのディザスタ・リカバリを提案しよう！～(kishida) (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (14)