• Like
低コストな可用性構成を実現するポイント ~ SERACでは実現できない高可用性構成
Upcoming SlideShare
Loading in...5
×

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

  • 9,964 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
9,964
On Slideshare
0
From Embeds
0
Number of Embeds
15

Actions

Shares
Downloads
3
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 低コストな可用性構成を実現するポイント ~ SERACでは実現できない高可用性構成 Oracle Direct 日本オラクル株式会社 May 28, 2014 Oracle Confidential – Internal/Restricted/Highly Restricted
  • 2. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |Oracle Confidential – Internal/Restricted/Highly Restricted2 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、 情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以 下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものでは ないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載 されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
  • 3. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | システム構築時に考慮すべき障害ポイント 停止の種類 原因 説明 計画外停止 サイト障害 •停電、自然災害、テロ、悪意ある攻撃 •サイト全体のNetwork障害 クラスタ障害 •クラスタ内の全サーバー停止 •インターコネクト全障害、クラスタウェア障害 ノード(サーバ) 障害 •ハードウェア、NIC障害 •OS障害、インスタンス障害 ストレージ障害 •ディスクドライブ障害 •ディスクコントローラ障害 データ破損、 書込み欠落 •OS、ストレージデバイスドライバ障害 •ソフトウェアの不具合 ユーザー・エラー •入力ミス •ファイル、テーブル等の誤削除 計画停止 システム変更 •クラスタノード、ストレージ追加、ディスク追加 •H/W、ソフトウェア、アプリケーションのアップグレード、パッチ適用 データベース・システムにおける障害の種類 約42%のユーザーが 計画外停止の主な 原因として回答 (2012 IOUG アンケート結果より) 多くのユーザーが経験済の あなどれない原因 計画停止の ほぼ大半の理由はこれ
  • 4. 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. リカバリ作業終了通知 手順の確立と 所要時間の見積もり が重要
  • 5. 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程度
  • 6. 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標準機能
  • 7. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 1-2. 計画外停止:ユーザー・エラー • 軽視できないユーザー・エラーによるシステム停止 – 計画外停止の主な原因の約45%はオペレータまたはユーザーのエラー 間違ったデータの削除、間違った表の削除、違うバッチを流してしまった など – ユーザー・エラーの復旧は非常に困難 バックアップをリストアし、障害直前の状態に復旧 ⇒ この間データベースは使用できない • ユーザー・エラーからの復旧方法 ⇒SE環境の場合、 ストレージ障害と同様に バックアップからのリストア/ リカバリが必要 ユーザー・エラーの場合もストレージ障害と同様に、 多くのSERAC環境で許容される計画外停止時間内に復旧できない
  • 8. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Flashbackの機能でユーザー・エラーから迅速に復旧可能 • Flashback 機能の魅力 - ユーザー・エラーからの早急かつ容易な復旧が可能(数分でシングル・コマンドで復旧)  DBのバックアップ全体のリストアは不要 ⇒ 変更されたブロックのみをリストア、DBを特定時点まで戻す  過去データの参照が可能!⇒ 不正なデータ改竄防止に効果 Flashback機能の種類Flashback機能による復旧イメージ EE標準機能
  • 9. 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
  • 10. 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によるサイト多重化で解決可能
  • 11. 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)
  • 12. 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
  • 13. 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 • シンプルで、高い信頼性を、手頃な価格で システム製品
  • 14. 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と比較すると、障害復旧に時間がか かる
  • 15. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 要件とテクノロジーの適材適所のススメ 今回お伝えしたかったポイント • とにかくゼロダウンタイムを極めたい! • できる限りダウンタイムを短くしたい! • EE機能やオプションを活用したい! • 広範囲に障害リスクを回避したい! • EE機能やオプションを活用したい! SE RAC RAC One Node Data Guard 目指すべきシステム像を実現するためにも、求められる要件を クリアできるテクノロジーを適材適所で活用いただきたい
  • 16. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Direct ~あなたにいちばん近いオラクル システムの導入や提案を支援する日本オラクルのご相談窓口 Oracle Directは製品のご購入・ご導入に関する無料のご相談窓口です。 お問い合わせ後はお客様ごとに担当が付き、ご質問・ご要望にスピーディにお応えします。 専任のエンジニアもおりますので、導入前の技術的なご質問にも対応可能です。 お問い合わせ方法 お電話、またはお問い合わせフォーム(Webフォーム)にてお問い合わせ下さい。 オラクルダイレクト 検索 無償支援サービスのご案内 データベースシステムの運用・更改の際に、お客様の環境に基づいたアドバイス& 最適なソリューションをご提案します。サービスの詳細および申し込みについては、 Oracle Directまでお問い合わせください。
  • 17. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |Oracle Confidential – Internal/Restricted/Highly Restricted17