Upload
oracle4engineer
View
10.288
Download
4
Embed Size (px)
Citation preview
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 Restricted 2
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
システム構築時に考慮すべき障害ポイント
停止の種類 原因 説明
計画外停止 サイト障害 •停電、自然災害、テロ、悪意ある攻撃 •サイト全体のNetwork障害
クラスタ障害 •クラスタ内の全サーバー停止 •インターコネクト全障害、クラスタウェア障害
ノード(サーバ) 障害
•ハードウェア、NIC障害 •OS障害、インスタンス障害
ストレージ障害 •ディスクドライブ障害 •ディスクコントローラ障害
データ破損、 書込み欠落
•OS、ストレージデバイスドライバ障害 •ソフトウェアの不具合
ユーザー・エラー •入力ミス •ファイル、テーブル等の誤削除
計画停止 システム変更 •クラスタノード、ストレージ追加、ディスク追加 •H/W、ソフトウェア、アプリケーションのアップグレード、パッチ適用
データベース・システムにおける障害の種類
約42%のユーザーが 計画外停止の主な 原因として回答 (2012 IOUG アンケート結果より)
多くのユーザーが経験済の あなどれない原因
計画停止の ほぼ大半の理由はこれ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
1-1. 計画外停止:ストレージ障害 データリカバリ計画の重要性
要件を順守した確実な復旧には、 計画と正確な見積もり・テストが重要
許容される計画外停止時間 (SERAC の場合) ※OracleDirect でのお問い合わせ情報から
80% 以上で、30分以内 の復旧要件
(例)ディスク障害時の障害復旧手順 1. 障害発生の検知 2. リカバリ作業開始通知 3. 障害箇所・障害内容の確認 4. 原因の解決(ディスク交換など) 5. バックアップからのリストア(全体+差分) 6. 最新状態までのリカバリ 7. 停止サービスの起動 8. 動作確認 9. リカバリ作業終了通知
手順の確立と 所要時間の見積もり が重要
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
例:計画外停止(ストレージの障害の場合)
想定構成例
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程度
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Oracle Data Guard 10分以内の復旧は、Oracle Data Guardで実現可能
データベースのログを転送
REDOログ 適用
REDOログ情報を 自動的に転送
本番データベース スタンバイ・データベース
特徴:
① データ誤差無し
② 高速なデータ同期、ネットワーク帯域小
③ トランザクションの順次性保障
用途:
• 本番データベースのコピーを作成し、データを保護
• 災害対策/データ保護、移行/アップグレード
同期転送 (SYNC)
非同期転送 (ASYNC)
データ保護 プライマリ DBでの更新はスタンバイ DBへの転送完了後に確定
プライマリ DBでの更新はスタンバイ DBへの転送未完了でも確定
性能への 影響
スタンバイ DBへの転送時間に依存してプライマリ DBの更新処理が待機
プライマリ DBへの更新処理はスタンバイ DB への転送を待機しない
転送モード 仕組み
RACでは防ぎきれないストレージ障害をData Guardでカバー可能
EE標準機能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
1-2. 計画外停止:ユーザー・エラー
• 軽視できないユーザー・エラーによるシステム停止
– 計画外停止の主な原因の約45%はオペレータまたはユーザーのエラー
間違ったデータの削除、間違った表の削除、違うバッチを流してしまった など
– ユーザー・エラーの復旧は非常に困難
バックアップをリストアし、障害直前の状態に復旧 ⇒ この間データベースは使用できない
• ユーザー・エラーからの復旧方法
⇒SE環境の場合、 ストレージ障害と同様に バックアップからのリストア/ リカバリが必要
ユーザー・エラーの場合もストレージ障害と同様に、 多くのSERAC環境で許容される計画外停止時間内に復旧できない
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Flashbackの機能でユーザー・エラーから迅速に復旧可能
• Flashback 機能の魅力 - ユーザー・エラーからの早急かつ容易な復旧が可能(数分でシングル・コマンドで復旧)
DBのバックアップ全体のリストアは不要 ⇒ 変更されたブロックのみをリストア、DBを特定時点まで戻す 過去データの参照が可能!⇒ 不正なデータ改竄防止に効果
Flashback機能の種類 Flashback機能による復旧イメージ
EE標準機能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
2.計画停止 計画停止の主な理由:サーバーメンテナンス
計画停止の主な理由 (2013 IOUG Database Availability Survey アンケート結果より)
• #1システム更改(75%) • #2サーバーメンテナンス(71%)
• オンラインでのメンテナンスは、一般的にH/W多重化で対応。 RACだけではストレージは対応できないため、サイト多重化が必要
• #3DBパフォーマンス&メンテナンス(57%) → DB機能/Optionで対応
RACだけではストレージ・メンテナンスに伴う計画停止は避けられない ⇒Oracle Data Guardによるサイト多重化で解決可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
まとめ:最適な高可用性アーキテクチャをシンプルに 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)
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
RAC One Node 短時間でのフェイルオーバーを実現できるOracleの推奨HA構成
Oracle RAC One Node
Oracle Clusterware
ACTIVE STANDBY
DB Instance
RAC の技術を活用したシングル・インスタンス・データベース
多数のHA環境を Gird Infrastructure を利用したグリッド環境へ統合
RAC One Nodeのメリット
• サーバー障害に対するフェイルオーバー保護
- 短時間でのフェイルオーバーが可能(約1分以内)
- 通常のHAでは実現できないデータベース・レイヤーの障害も検知
• OMotionによるオンライン・メンテナンス
- OSおよびデータベースのローリング・アップグレードと ローリング・パッチをオンラインで実施可能
EE Option
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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
• シンプルで、高い信頼性を、手頃な価格で
システム製品
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
各テクノロジーの比較 SE RAC, RAC One Node, Data Guard
SERAC RAC One Node Data Guard(DG)
概要
Active-Activeのサーバー冗長化機能 Active-Standbyのサーバー冗長化機能 リアルタイム・データ連携による データベースの複製機能
メリット
•サーバー障害に対してゼロダウンタイムで 対応可能 •複数リソースをまたいだ柔軟なリソース活用ができる
•ゼロではなくとも1分程度の短時間でのサーバー障害からの復旧が可能 •SEでは使えないさまざまなEE機能を低コストで使用可能 •EERACと比較し、ソフトウェア・ライセンスにかかるコストが格段少ない
•完全なデータベース複製ができ、あらゆる障害への対応が可能 •DGだけであればEE標準機能。共有ディスクは不要なため、ストレージコストが浮く。 •Active DGオプション追加により、スタンバイ側での参照業務/バックアップが可能
デメリット
•広範囲に障害リスクを回避した網羅的な障害対策ができない -計画外停止:ストレージ障害と人為的エラーには迅速に対応できない
-計画停止:ストレージメンテナンス時に停止が発生する
•SEなので、EE機能は使えない
•広範囲に障害リスクを回避した網羅的な障害対策ができない -計画外停止:ストレージ障害には迅速に対応できない
-計画停止:ストレージメンテナンス時に停止が発生する
•RACと比較すると、障害復旧に時間がかかる
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
要件とテクノロジーの適材適所のススメ 今回お伝えしたかったポイント
• とにかくゼロダウンタイムを極めたい!
• できる限りダウンタイムを短くしたい! • EE機能やオプションを活用したい!
• 広範囲に障害リスクを回避したい! • EE機能やオプションを活用したい!
SE RAC
RAC One Node
Data Guard
目指すべきシステム像を実現するためにも、求められる要件を クリアできるテクノロジーを適材適所で活用いただきたい
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Oracle Direct ~あなたにいちばん近いオラクル システムの導入や提案を支援する日本オラクルのご相談窓口
Oracle Directは製品のご購入・ご導入に関する無料のご相談窓口です。 お問い合わせ後はお客様ごとに担当が付き、ご質問・ご要望にスピーディにお応えします。専任のエンジニアもおりますので、導入前の技術的なご質問にも対応可能です。
お問い合わせ方法 お電話、またはお問い合わせフォーム(Webフォーム)にてお問い合わせ下さい。
オラクルダイレクト 検索
無償支援サービスのご案内 データベースシステムの運用・更改の際に、お客様の環境に基づいたアドバイス& 最適なソリューションをご提案します。サービスの詳細および申し込みについては、 Oracle Directまでお問い合わせください。
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 17