Maximum Availability Architecture (MAA) · Infrastructure for the Cloud Wei Hu . Vice President of Development, High Availability Technologies ... An Analysis of Data Corruption in

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |

Maximum Availability Architecture (MAA) Infrastructure for the Cloud

Wei Hu Vice President of Development, High Availability Technologies Oracle Corporation


クラウド・コンピューティングは高可用性が必要 • 時代がクラウドに向かうにつれて、高可用性が重要な要件になってきた

• クラウドだからといってサーバーの障害、ストレージの障害や人的ミスでダウンして良いわけがない

• クラウドにおいてもパッチ適用時やアップグレード時にも稼働を続ける必要がある

• Oracle Maximum Availability Architectureはミッションクリティカルなデータベースシステムで長年検証をされてきたアーキテクチャでアリ、クラウドでもオンプレミスでも、またハイブリッド・クラウド構成でも利用可能

2


Oracle Maximum Availability Architecture 高可用性実現のための標準アーキテクチャ

Active Data Guard – Data Protection, DR – Query Offload GoldenGate – Active-active – Heterogeneous

Oracle Secure Backup – Backup to tape / cloud

アクティブ・レプリカ

Edition-based Redefinition, オンライン再定義, Data Guard, GoldenGate –メンテナンス、アップグレード、マイグレーションに伴うダウンタイムを最小化

RAC – Scalability – Server HA Flashback –人的エラー回避

本番サイト

ASM –ボリューム管理 RMAN & Fast Recovery Area –ディスク上のバックアップ


データ障害は発生しうるもの

• データボリュームや複雑なIOサブシステムの増加により、データ破損は不可避に

• ディスク・ドライブには既知の問題が – Schroeder and Gibson, Disk Failures in the Real World: What Does an MTTF of

1,000,000 Hours Mean to You?, 2007 – Pinheiro, et al, Failure Trends in a Large Drive Population, 2007 – Elerath, Hard Disk Drives: the Good, the Bad, and the Ugly! 2007 – Krioukov, et al, Parity Lost and Parity Regained, 2008 – Bairavasundaram, et al, An Analysis of Data Corruption in the Storage Stack,

2008 – Jiang, et al, Are Disks the Dominant Contributor for Storage Failures? 2008

• 全面的なディスクの障害よりも潜在的なデータ破損の方が深刻

Oracle Confidential


Oracle

物理データ破損の例 • 潜在的なセクター・エラー、破損、lost write、torn write、間違った場所へのWrite

Krioukov, et al, Parity Lost and Parity Regained, FAST ’08: 6th USENIX Conference on File and Storage Technologies, 2008

Oracle Confidential

正常なWrite Corrupted Write 間違った場所へのWrite

Lost Write 処理前

Oracle Oracle Oracle Oracle


海外大手オンラインバンキングの障害

• 銀行のオンライン・サービスが月曜日の夜から火曜日にかけて2日間停止。水曜日の早朝にようやく復旧。システム障害が原因で、数百万のオンライン・バンキングの利用者は、請求の支払いやローン申請、自動決済などの取引が利用できない事態に．．．

Oracle Confidential


バージニア州で5日間SANが停止

• VITA (バージニア州情報技術機関）、ノースロップ・グラマン、EMCおよび被害を受けた州政府の機関は、昼夜を問わず、サービス再開に向けて取り組んでいる。今回のネットワーク・ストレージ・システムの停止により、89ある州政府の機関のうち、27機関が影響を受けた。DMV（自動車管理部）は運転免許証も発行できない。 http://www.vita.virginia.gov/ 2010年8月31日

http://www.vita.virginia.gov/


Data Protection vs Disaster Recovery • これらの障害は「いわゆる自然災害」ではない

• ただしビジネスへの影響は甚大

• データ破損を原因とする障害は自然災害よりもその影響度は大きい – お客様がもし地震が原因によるデータセンターの火事や停止があったとしても理解はしてくれるだろう

– しかし、お客様はもしサービス停止がストレージの問題であった場合には、理解を示してくれることはないだろう

• Data Guardによるデータ保護は、たんに自然災害に対する対策だけではない。


データ保護の要件 1. 独立した障害モードでデータのコピーを複数持つ

– ただ1度の間違ったオペレーションで、プライマリとセカンダリのコピーを両方失わないように

2. コピーに変更を加える際には厳密なチェックが行えるインターフェースを経由すること

– 厳密なインターフェースとはチェック機能が優れており、エラーが発生した場合に切り離すことができるもの

3. 問題が発生した場合には、フォールバックで迅速に回復


Oracleの最適化されたデータ保護

• 2つのバージョンを比較して一貫性を確認する方法がデータ保護の基本アプローチ。例：ディスク・ミラーリングやチェックサム比較など。

• ストレージやOracle以外のソリューションでは、データベース・ブロックを不透明なバイナリ・ビットとしてみなす

– OSやファイルシステム、ストレージは、Oracleのデータブロックが正常か、さらにはデータが入っているかどうかも判断できない

• Oracleでは、ブロックの中身を把握できるため、より良いチェックができ、2つの異なるバージョンが存在する場合には、正しい方を選択できる

$!$%% !#@!! !$ *&^@ /^$++%!$94999^

Jane Doe, 123 Elm St,

Nowhere, CA 94999


• Oracle Databaseのデータ可用性と保護を実現 • アプリケーションのダウンタイム無しに自動的にブロック修復 • スタンバイ・データベースは、クエリやレポート、テスト、バックアップなどに使用

• Active Data Guardがリアルタイム・データのクエリを可能に

Active Data Guard スタンバイ・データベース

本番データベース

Oracle Active Data Guard 最適なデータ保護

同期/非同期 Redo転送


ORA-00600: internal error code, arguments: [3020],.. ORA-10567: Redo is inconsistent with data block (file# 4, block# 315) ORA-10564: tablespace TRANS1 ORA-01110: data file 4: 'O:¥ORADATA¥TBS01.DBF‘

Oracleの最適化されたデータ保護の内部 Data Guardはデータを破損から保護

• ストレージ・レプリケーションはビットをコピー (正常なデータも破損したデータも同様) –もしプライマリー・データベースのデータが破損したら、この破損はレプリカに伝搬することが保証されてしまう

• Active Data GuardはRedoベースのレプリケーション –最適に定義され検証可能な構造とセマンティックを持ち変更点のみを同期 –伝搬された時点で破損を防ぐことが可能


MAAはActive-Active • RAC はActive/Active構成

• Active Data Guardのスタンバイ・データベースも本番データベースと同期しながら同時に検索することが可能 – ストレージ・ミラーリングと異なり、最新のデータにアクセスできる

• 従来の可用性技術ではアイドル・スペアが必要 – コールド・フェイルオーバー・クラスタ、パッシブ・DRサイト

• この方法は非経済的 • かつ信頼できない

– 必要な時にバックアップ・システムが動くかどうかがわからない • スタンバイ・ストレージに潜在的な破損はないだろうか?

– お客様は災害対策サイトを使うことをためらってしまう – 皆さん、車のスペアタイヤの空気圧をチェックしたことがありますか?


データ保護の要件 1. 独立した障害モードでデータのコピーを複数持つ

– ただ1度の間違ったオペレーションで、プライマリとセカンダリのコピーを両方失わないように

2. コピーに変更を加える際には厳密なチェックが行えるインターフェースを経由すること

– 厳密なインターフェースとはチェック機能が優れており、エラーが発生した場合に切り離すことができるもの

3. 問題が発生した場合には、フォールバックで迅速に回復


Flashbackテクノロジー

• Flashback Tableは間違ったデータ更新を取り消す

• Flashback Databaseはデータベース全体を “巻き戻し”

• Flashback Query – エラー調査 – データを過去の一時点として参照する

• Flashback Transactionはトランザクションを取り消す

Oracle Databasesの「巻き戻し」ボタン

@T2 Col-1 Col-.. Col-n

Row-1 tom 1234 vp

Row-2 ben 8834 vp

Row-3 charlie 9837 vp

Row-n tom 8793 vp

@T1 Col-1 Col-.. Col-n

Row-1 abby 1234 officer

Row-2 ben 8834 mgr

Row-3 Charlie 9837 officer

Row-n tom 8793 vp Wrong Update

Flashback Table

DB @ T1 DB @ T2

Batch Update

Flashback Database

Wrong Update

15


データベースに統合されたバックアップ・リカバリ Oracle Recovery Manager: RMAN

• データベース・ファイル・フォーマットとリカバリ手順を理解した仕組み – Oracle Blockの検証 – オンライン・ブロック・レベル・リカバリ – ネイティブの暗号化と圧縮 – 表/パーティション単位のリカバリ – Oracle Multitenantのサポート

• テープ及びクラウドへバックアップ

• 統合された管理

RMAN

Data Files Fast Recovery

Area (FRA)

16

Cloud

Tape

Disk Tape


RMAN 細かなテーブル・リカバリ

• シンプルなRECOVER TABLE コマンドで一つもしくは複数のテーブルを最新又は古いバージョンにRMANバックアップからリカバリ

• 手動でのリストア、リカバリやエクスポートによる時間や複雑さを削減 – テーブルスペース全体のコンテンツではなく、個別テーブルへのポイントインタイム・リカバリを実現

RMAN Backups


バックアップの制約 • RMANを利用したとしても従来のバックアップには制約がある

1. バックアップからリストアする場合にはデータが失われることを理解しないといけない

– 最後のバックアップを取得してからのデータベース変更は失われる

2. バックアップは本番データベースの性能に影響を与える

18

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. | 19

Recovery Appliance: ビジネス及びITにメリットをもたらす

バックアップの影響を最小に

本番データベースは変更ログを転送するだけ。すべてのバックアップやテープ処理はオフロードされる

Data Lossをなくす

リアルタイムにRedoを転送することで最新トランザクションの容易に保護

Cloud-Scaleの保護

超並列のスケーラブルなサービスによって、データセンター内のすべてのデータベースを容易に保護

データベース単位でリカバリ可能

バラバラのファイルを管理することなくエンド・トゥ・エンドでの信頼性、可視性、データベースの制御


データロスからの保護 Zero Data Loss Recovery Appliance

Delta Store • 検証済みで圧縮された更新データをディスク上に保存 • 任意の時点にポイントインタイムで高速にリカバリ • エンド・トゥ・エンドでリカバリ・ウィンドウを管理

Recovery Appliance

Delta Push • 永遠に増分バックアップ • リアルタイムRedo転送

保護対象のデータベース

すべてのOracle Databaseを保護 • ペタバイト級のデータ • Oracle Database 10gR2から12cまでのすべてのプラットフォーム

• 負荷の高いバックアップ・エージェントはない

テープバックアップをオフロード

災害対策のためにリモートのアプライアンスにレプリケーション

統合管理 • Enterprise Manager


MAA – その他のHA技術


性能影響が少なくしたいがデータロスはなくしたい

• すべてのお客様はData Guardをデータロスが発生しない構成(Maximum Availability モード)したいが、同期通信による性能の影響を考慮する必要がある

• 距離が遠ければ遠いほど性能への影響は大きい

長距離レプリケーションの性能影響

本番データベーススタンバイ・データベース

Commit

Commit Ack

Network Send

Network Ack


本番サイト

スタンバイサイト

最小ではあるが災害発生時にいくらかのデータロスは発生する Compromise by running Data Guard Customers in Async mode

非同期


本番サイト


Far Sync インスタンス

Active Data Guard Far Sync: 運用フロー

非同期

同期

24

• Oracleの制御ファイルとログファイル • データベース・ファイルは不要 • 転送時の圧縮をオフロード


本番サイト


Far Sync インスタンス

Active Data Guard Far Sync: 運用フロー(続き)

どんな距離でもデータロス無しを実現!

非同期

SYNC

本番サイト

25


Global Data Services

• Oracle Database 12c以前は、データベース・サービスは1つのRACデータベース上でしか動かなかった

• Oracle Database 12cの新機能であるGlobal Database Servicesは複数のRACまたは非RACデータベースにまたがって動作可能 – RAC型のサービス・フェイルオーバーを実現し、ワークロ

ードのルーティングや負荷分散を複数のレプリカにまたがって実現

– Active Data GuardとGoldenGateをサポート

– アカウント・ネットワークのレイテンシやレプリケーション・ラグそしてサービス配置ポリシーを考慮

• アプリケーションの可用性とレプリカ内で発揮する性能を最大化

• Active Data Guard又はOracle GoldenGateで利用可能

レプリケーションしたデータベース間でワークロードのルーティングや分散、そしてサービス・フェイルオーバーを実現

Oracle GoldenGate

本番アクティブスタンバイ

Active Data Guard or Oracle GoldenGate

サイト A サイト B

Global Data Services

Global Service フェイルオーバー

ロード・バランシング

26

SALES GDS POOL (OE_service)

HR GDS POOL (payroll_service)

マスターマスター


計画停止のオプション

Tech Refresh & Select Migrations

Standby-First パッチ検証

Transient Logical ローリング・

アップグレード

Data Guard

スイッチ・オーバー

Tech Refresh and Migrations

My Oracle Support Note 413484.1を参照 - 本番/スタンバイのクロスプラットフォームの組み合わせ ‒ フィジカル・スタンバイを使って旧バージョン-新バージ

ョン間のレプリケーション

Transient Logical

Oracle Patchsetと新しいDatabase Releases ‒ e.g. 11.2.0.1 > 11.2.0.3 ‒ e.g. 11.2.0.3 > 12.1

アップグレード時 ‒ 最初はフィジカル・スタンバイ ‒ 旧バージョン-新バージョン間をロジカ

ル・レプリケーション ‒ 本番及びスタンバイが新バージョンに

アップグレードができたら、フィジカル・スタンバイに復帰

Standby-First

Patch Set Update Critical Patch Update Patch Set Exception Exadata bundled patch Exadata storage server

software patch Uses physical replication

between old and new environments My Oracle Support Note

1265700.1を参照

27


パッチ適用とアップグレード – 継続的なイノベーション

Oracle Confidential – Internal/Restricted/Highly Restricted 28

より簡単により高速に/オンラインでより安全に Multitenantにて1つのコマンドですべてのCDBとPDBをアップグレード

Data Guard およびGoldenGateによるローリング・アップグレード

Real Application Testing (DB Replay, SQL Performance Analyzer)

unplug/plugでのMultitenantパッチ適用

RAC およびExadataのローリング・アップグレード

SQL Plan Management

OPatch /Exadata Patchmgr自動化 Application Continuity, TAF 検証のためのSnapshot Standby

集積パッチ(PSU, BP, MLR)がOne-off Patch適用回数を削減

RAC service relocate, FAN, Global Data Services, Active GridLink

Flashback DatabaseとRestore Point

多数のパッチとアップグレードのためのEM gold imageの利用

Parallel upgrade Standby-first patching

インストーラーの事前検証、DBUA, Exachk, Orachk, pre-upgrade script

Edition-based Redefinition, オンライン再定義, オンラインDDL

オンディスク互換性管理とダウングレード

四半期毎の推奨パッチの提供によりメンテナンスウィンドウを管理

PSU/BPがRAC ローリングとstandby-first を適用可能に

Out-of-place patching

Rapid Home Provisioning Transportable tablespace, Full Transportable Export/Import

Patchsetsをフルバージョンで提供


その他のOracle Database 12c における新機能 Data Guard

Active Data Guardを使用したローリング・アップグレードシンプルなPL/SQLパッケージ:DBMS_ROLLING (12.1.0.2以

降)で複雑な処理を自動化 – シンプルな初期化、構築、スイッチオーバーの実施と終了処理

追加のデータ型のサポート: XML OR, Binary XML, Spatial, Image, Oracle Text, DICOM, ADTs (simple types, varrays), …

ロール変更の事前検証自動的なヘルスチェックによってData Guard構成がスイッチ

オーバー可能な状態にあるかどうかを確認 - ログのギャッ

プがないこと、ログスイッチの実行、あらゆる一貫性の問題を検知、スタンバイ上でオンラインログファイルがクリアされたことの確認など

グローバル一時表に対するDML 一時UNDOはREDOログには書かれない

Active Data Guard上のグローバル一時表へのDMLを可能にすることで、よりレポーティング処理を使いやすく

Active Data Guard standbyにデフォルト設定

Unique Sequences プライマリがそれぞれのスタンバイ毎にユニークなレンジ

のシークエンス番号を割り当て

Active Data Guardでさらに柔軟なレポーティングを実現


計画停止をなくすための双方向でのロジカル・レプリケーション Oracle GoldenGate

• 無停止メンテナンスとマイグレーション • Active-Activeでの高可用性 • 異機種間レプリケーション、データ配信と統合

Source & Target Oracle & Non-Oracle Database(s)

Target & Source Oracle & Non-Oracle Database(s) 双方向

LAN / WAN / Internet Over TCP/IP

30


Active Data GuardとGoldenGate – 補完関係 • Active Data Guardは非計画停止への対策に最適

– DR機能: データロス無し、Far Sync、Fast Start Failover – 本番とスタンバイは物理的に同じ (SCNのレベルで) – 障害検知に有効 : データ破損やLost Write – 障害修復に有効: Automatic Block Repair、スタンバイからのバックアップを本番環境に適用(その反対も)

• GoldenGateは計画停止への対策に最適 – GoldenGate のレプリカは物理的には同じではない – アップグレードのような計画的な運用を実現するためには強力な機能 – 特に異なるプラットフォーム間で行う場合には最高の機能

31


MAA Customer Case Studies


Maximum Availability Architecture 高可用性実現のための標準アーキテクチャ

• 多くの企業がOracle MAAで標準化済 • MAAはオンプレミスだけではなくクラウド構成でも最高の可用性を実現 • 本当のミッションクリティカル顧客で有効に活用: Salesforce, PayPal, NYSE, を始めとした多くの企業で

• これらの顧客は最大規模で最も要求の厳しいワークロードで運用 – この事実はMAAが本当に最も高い可用性の要件を満たすことの証明

• MAAはクラウドで検証済みのアーキテクチャ

Oracle Confidential 33


Documents

Maximum Availability Architecture (MAA) · Infrastructure for the Cloud Wei Hu . Vice President of Development, High Availability Technologies ... An Analysis of Data Corruption in