低コストな可用性構成を実現するポイント～ SERACでは実現できない高可用性構成

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
低コストな可用性構成を実現するポイント
～ SERACでは実現できない高可用性構成
Oracle Direct
日本オラクル株式会社
May 28, 2014
Oracle Confidential – Internal/Restricted/Highly Restricted

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |Oracle Confidential – Internal/Restricted/Highly Restricted2
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、
情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以
下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものでは
ないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載
されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。

システム構築時に考慮すべき障害ポイント
停止の種類原因説明
計画外停止サイト障害 •停電、自然災害、テロ、悪意ある攻撃
•サイト全体のNetwork障害
クラスタ障害 •クラスタ内の全サーバー停止
•インターコネクト全障害、クラスタウェア障害
ノード（サーバ）
障害
•ハードウェア、NIC障害
•OS障害、インスタンス障害
ストレージ障害 •ディスクドライブ障害
•ディスクコントローラ障害
データ破損、
書込み欠落
•OS、ストレージデバイスドライバ障害
•ソフトウェアの不具合
ユーザー・エラー •入力ミス
•ファイル、テーブル等の誤削除
計画停止システム変更 •クラスタノード、ストレージ追加、ディスク追加
•H/W、ソフトウェア、アプリケーションのアップグレード、パッチ適用
データベース・システムにおける障害の種類
約42％のユーザーが
計画外停止の主な
原因として回答
(2012 IOUG アンケート結果より)
多くのユーザーが経験済の
あなどれない原因
計画停止の
ほぼ大半の理由はこれ

1-1. 計画外停止：ストレージ障害
データリカバリ計画の重要性
要件を順守した確実な復旧には、
計画と正確な見積もり・テストが重要
許容される計画外停止時間
(SERAC の場合)
※OracleDirect でのお問い合わせ情報から
80% 以上で、30分以内の復旧要件
（例）ディスク障害時の障害復旧手順
1. 障害発生の検知
2. リカバリ作業開始通知
3. 障害箇所・障害内容の確認
4. 原因の解決（ディスク交換など）
5. バックアップからのリストア（全体＋差分）
6. 最新状態までのリカバリ
7. 停止サービスの起動
8. 動作確認
9. リカバリ作業終了通知
手順の確立と
所要時間の見積もり
が重要

例：計画外停止（ストレージの障害の場合）
想定構成例
DB size： 1TB
Backup：WeeklyでFull, Dailyで差分
更新量：日々5％程度のデータが更新（≒50GB)
Redo生成量：7GB/Day (300MB/h)
バックアップからのリストア（Disk2Disk）
60 Minutes 3 3 3
5%*3
=15%
≒ 150GB
差分リストア
1
ログ適用（リカバリ）
1 日分
=7GB
想定値: Restore 1TB/Hour (300MB/Sec) , Recovery 350GB/Hour(100MB/Sec)
このケースでは、
データベース全体をバックアップから復旧する場合、
30分以内に復旧できる DB サイズは 500GB以下、
システムとして確実に復旧させるためには、250GB程度

Oracle Data Guard
10分以内の復旧は、Oracle Data Guardで実現可能
データベースのログを転送
REDOログ適用
REDOログ情報を
自動的に転送
本番データベーススタンバイ・データベース
特徴：
① データ誤差無し
② 高速なデータ同期、ネットワーク帯域小
③ トランザクションの順次性保障
用途：
• 本番データベースのコピーを作成し、データを保護
• 災害対策/データ保護、移行/アップグレード
同期転送
(SYNC)
非同期転送
(ASYNC)
データ保護プライマリ DBでの更新
はスタンバイ DBへの転
送完了後に確定
プライマリ DBでの更新
はスタンバイ DBへの転
送未完了でも確定
性能への
影響
スタンバイ DBへの転
送時間に依存してプラ
イマリ DBの更新処理
が待機
プライマリ DBへの更新
処理はスタンバイ DB
への転送を待機しない
転送モード仕組み
RACでは防ぎきれないストレージ障害をData Guardでカバー可能
EE標準機能

1-2. 計画外停止：ユーザー・エラー
• 軽視できないユーザー・エラーによるシステム停止
– 計画外停止の主な原因の約45%はオペレータまたはユーザーのエラー
間違ったデータの削除、間違った表の削除、違うバッチを流してしまったなど
– ユーザー・エラーの復旧は非常に困難
バックアップをリストアし、障害直前の状態に復旧 ⇒ この間データベースは使用できない
• ユーザー・エラーからの復旧方法
⇒SE環境の場合、
ストレージ障害と同様に
バックアップからのリストア/
リカバリが必要
ユーザー・エラーの場合もストレージ障害と同様に、
多くのSERAC環境で許容される計画外停止時間内に復旧できない

Flashbackの機能でユーザー・エラーから迅速に復旧可能
• Flashback 機能の魅力
- ユーザー・エラーからの早急かつ容易な復旧が可能(数分でシングル・コマンドで復旧)
 DBのバックアップ全体のリストアは不要 ⇒ 変更されたブロックのみをリストア、DBを特定時点まで戻す
 過去データの参照が可能！⇒ 不正なデータ改竄防止に効果
Flashback機能の種類Flashback機能による復旧イメージ
EE標準機能

Flashbackの機能で救われた実例
RAC/ASM構成（Exadata）
＋Data Guard による DR環境
性能を重視しセカンダリに
Flashback Log を確保
RAC+ASM
カットオーバ直前(数時間前)に
実施したバッチが誤っていた
（通常の復旧作業では間に合わない・・）
DG Switch Over 運用で
ロール切替(正副入替)
Flashback DB 機能で
処理実行直前へ巻き戻し
DG Stand by 再構築
再びDG Switch Overで
ロール切替(正副)
正規の処理を確実に実施
-> 無事運用開始へ
Flashback
Database
RAC+ASM
DataGuard
https://blogs.oracle.com/dbjp/entry/exadata_000193

２．計画停止
計画停止の主な理由：サーバーメンテナンス
計画停止の主な理由
(2013 IOUG Database Availability Survey アンケート結果より)
• #１システム更改（75％）
• #２サーバーメンテナンス（71％）
• オンラインでのメンテナンスは、一般的にH/W多重化で対応。
RACだけではストレージは対応できないため、サイト多重化が必要
• #３DBパフォーマンス＆メンテナンス（57％）
→ DB機能/Optionで対応
RACだけではストレージ・メンテナンスに伴う計画停止は避けられない
⇒Oracle Data Guardによるサイト多重化で解決可能

まとめ:最適な高可用性アーキテクチャをシンプルに
SERACユーザーにオススメ！低コストで実現できるOracleの推奨構成
RAC One Node + Data Guard on ODA
= 低コストであらゆる障害に対応できる強固なシステム構築が可能
RMAN
– データ・バックアップ
– 人的ミスの抑制
RAC One Node
- ノード障害の迅速復旧
- 計画停止時間の抑止
Data Guard
- 完全なデータベース複製
- スタンバイサイトへの
参照処理のオフロード
(要Option)
ACTIVE STANDBY
Oracle Database
Appliance（ODA)
ACTIVE INACTIVE
Oracle Database
Appliance（ODA）
Flashback
-人的ミスの迅速復旧
Enterprise Manager
- DB運用監視の簡素化
- 性能分析改善の自動実行
(要Option)

RAC One Node
短時間でのフェイルオーバーを実現できるOracleの推奨HA構成
Oracle RAC One Node
Oracle Clusterware
ACTIVE STANDBY
DB
Instance
 RAC の技術を活用したシングル・インスタンス・データベース
 多数のHA環境を Gird Infrastructure を利用したグリッド環境へ統合
RAC One Nodeのメリット
• サーバー障害に対するフェイルオーバー保護
- 短時間でのフェイルオーバーが可能（約１分以内)
- 通常のHAでは実現できないデータベース・レイヤーの障
害も検知
• OMotionによるオンライン・メンテナンス
- OSおよびデータベースのローリング・アップグレードと
ローリング・パッチをオンラインで実施可能
EE Option

Oracle Database Appliance
シンプルかつ低コストで高可用性＆高性能なデータベース基盤を実現
シンプルな構築、管理、障害対応を実現
オラクルのベストプラクティス構成をすぐに利用可能
高可用性を
シンプルに
最適化されたHW設計 + SW設定 + Oracle DB EE
圧倒的なコストパフォーマンスを実現
コスト
パフォーマンス
必要なCPU能力に合わせてライセンスを拡張購入可能
Oracle DB EE が4コアからスタートできる
スモール
スタート
オラクルが全てのコンポーネントを提供
世界中の数千台が同一構成で稼働している安心感
サポート
• サーバ・ノード x 2台
– Xeonプロセッサ x 2基 x 2台 (計48コア)
– 256GB メモリ x 2台 (計512GB)
• ストレージ・シェルフ (SAS-2接続)
– HDD 18TB (SAS-2 900GB x 20台)
• 使用可能容量 6TB / 9TB (三重化 / 二重化)
– SSD 800GB (SAS-2 SLC 200GB x 4台)
• REDO ログ用
• ネットワーク (サーバ当り)
– 10G BASE-T x 4 (Bonding x 2)
– インターコネクト用 (10GbE SFP+ x 2)
データベースをよりシンプルに
• 第三世代｜Oracle Database Appliance X4-2
• シンプルで、高い信頼性を、手頃な価格で
システム製品

各テクノロジーの比較
SE RAC, RAC One Node, Data Guard
SERAC RAC One Node Data Guard(DG)
概
要
Active-Activeのサーバー冗長化機能 Active-Standbyのサーバー冗長化機能リアルタイム・データ連携による
データベースの複製機能
メ
リ
ッ
ト
•サーバー障害に対してゼロダウンタイムで
対応可能
•複数リソースをまたいだ柔軟なリソース活
用ができる
•ゼロではなくとも１分程度の短時間での
サーバー障害からの復旧が可能
•SEでは使えないさまざまなEE機能を低コ
ストで使用可能
•EERACと比較し、ソフトウェア・ライセンス
にかかるコストが格段少ない
•完全なデータベース複製ができ、あらゆる
障害への対応が可能
•DGだけであればEE標準機能。共有ディ
スクは不要なため、ストレージコストが浮く。
•Active DGオプション追加により、スタン
バイ側での参照業務/バックアップが可能
デ
メ
リ
ッ
ト
•広範囲に障害リスクを回避した網羅的な
障害対策ができない
-計画外停止:ストレージ障害と人為的
エラーには迅速に対応できない
-計画停止:ストレージメンテナンス時に停
止が発生する
•SEなので、EE機能は使えない
•広範囲に障害リスクを回避した網羅的な
障害対策ができない
-計画外停止:ストレージ障害には迅速
に対応できない
-計画停止:ストレージメンテナンス時に停
止が発生する
•RACと比較すると、障害復旧に時間がか
かる

要件とテクノロジーの適材適所のススメ
今回お伝えしたかったポイント
• とにかくゼロダウンタイムを極めたい！
• できる限りダウンタイムを短くしたい！
• EE機能やオプションを活用したい！
• 広範囲に障害リスクを回避したい！
• EE機能やオプションを活用したい！
SE RAC
RAC One Node
Data Guard
目指すべきシステム像を実現するためにも、求められる要件を
クリアできるテクノロジーを適材適所で活用いただきたい

Oracle Direct ～あなたにいちばん近いオラクル
システムの導入や提案を支援する日本オラクルのご相談窓口
Oracle Directは製品のご購入・ご導入に関する無料のご相談窓口です。
お問い合わせ後はお客様ごとに担当が付き、ご質問・ご要望にスピーディにお応えします。
専任のエンジニアもおりますので、導入前の技術的なご質問にも対応可能です。
お問い合わせ方法
お電話、またはお問い合わせフォーム（Webフォーム）にてお問い合わせ下さい。
オラクルダイレクト検索
無償支援サービスのご案内
データベースシステムの運用・更改の際に、お客様の環境に基づいたアドバイス＆
最適なソリューションをご提案します。サービスの詳細および申し込みについては、
Oracle Directまでお問い合わせください。

低コストな可用性構成を実現するポイント～ SERACでは実現できない高可用性構成

低コストな可用性構成を実現するポイント～ SERACでは実現できない高可用性構成

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 低コストな可用性構成を実現するポイント～ SERACでは実現できない高可用性構成

Similar to 低コストな可用性構成を実現するポイント～ SERACでは実現できない高可用性構成 (20)

More from オラクルエンジニア通信

More from オラクルエンジニア通信 (20)

Recently uploaded

Recently uploaded (14)