Oracle Database Cloud Data Guard機能について

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

Oracle Database CloudData Guard 機能について2016年9月27日 (v1.8)

日本オラクル株式会社Cloud Platform 事業推進室丸川祐考


以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

2

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


(あらためて)Data Guard機能の役割

•いつでもフェイルオーバー可能なもう一つのデータベース・セットを保持

•バックアップ・リカバリよりも短いRPO、RTO

•参照専用データベースによるプライマリDB負荷のオフロード(Active Data Guard)

•プライマリDB破損時の自動ブロック・メディア・リカバリー(Active Data Guard)

•ローリング・メンテナンスによる定期停止の極小化

3

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | 4

リアルタイム・データベース複製、災害対策

Data Guard の基本アーキテクチャ

データベースのログを転送

REDOログ REDO適用

REDOログ情報を自動的に転送

プライマリ・データベーススタンバイ・データベース

特徴：① データ誤差無し

② 高速なデータ同期、ネットワーク帯域小

③ トランザクションの順次性保障

用途：• 本番データベースのコピーを作成し、データを保護

• 災害対策/データ保護、移行/アップグレード

• (ADG) 検索、バックアップ、データ破損対策

転送モード仕組み

同期転送 (SYNC) 非同期転送 (ASYNC)

データ保護完全に保護転送済トランザクションのみ

アプリへの性能影響

転送時間に依存なし

※ADG：Active Data Guard Option


Oracle Database CloudのData Guardのアプローチ

5

クラウド・データベースの高可用性を目指す2つのアプローチ

1. クラウド上のデータベースの可用性を向上させる

→ オンプレミスで培ったMAAアーキテクチャを順次クラウドに実装

2. クラウドを活用しオンプレミスのデータベースの可用性を向上させる

→ オンプレミスとクラウドをまたがるハイブリッド・クラウド・モデルによる高可用性データベース・ソリューションの提供


オンプレミス to クラウドのData Guard手動構築用の手順(MAAホワイト・

ペーパー)公開

クラウド to クラウドのData Guard自動構築

管理用ツール、GUI、API

6

オンプレミス to クラウドのData Guardの自動構

築・管理

クラウド上のData Guardの提供プラン

1 2 3

2016/6 New!!提供済


クラウド to クラウドのData Guard

7

2016/6 New!!

• インスタンス作成時にData Guardが構成できるGUI機能

• 2つの配置タイプ

1. 高可用性(High Availability)同データセンター、別ゾーン

2. 障害回復(Disaster Recovery)別データセンター(例)US2(chicago)→US6(Ashburn)





9

対応エディション

Standard Edition

Enterprise Edition

EE – High Perfomrance

EE – Extreme Performance

使用不可

Data Guard 使用可

Active Data Guard 使用可



• アイデンティティ・ドメインがマルチゾーン対応していること

– マルチゾーン対応かどうかは、Compute Cloud のサービスコンソールで確認可能

– 対応していれば「サイトセレクタ」へのリンクが表示される

– 基本的に新しいアイデンティティ・ドメインは全てマルチゾーン対応、古いものも順次

10

作成の条件

参考 : サイトの最初5桁はデータセンターを意味しますUS002 – Chicaco(IL)US006 – Ashburn(VA)EM001 – Amsterdam(NL)EM002 – Slough(UK)


(参考)Oracle Cloudのマルチサイト化

11

マルチサイト化の考え方

アイデンティティ・ドメインData CenterChicago(US002) Zone 20 ゾーン

ゾーン

アイデンティティ・ドメイン




Chicago(US002) Zone 12

Chicago(US002) Zone 23

Ashburn(US006) Zone 10

Ashburn(US006) Zone 18

アイデンティティ・ドメインは、特定のゾーンのリソースしか使用できなかった

今までのOracle Cloud (~2016/5) 現在のOracle Cloud (2016/6~)

アイデンティティ・ドメインの中で、予め決められた複数のDC、ゾーンを任意に選択して使用可能ただしPaaSでは任意選択不可、インスタンス作成時に特定の1つのゾーンが選択される

PaaS配置

IaaS配置可能

IaaS配置可能

IaaS配置可能

IaaS配置可能


(参考)Oracle Cloudのマルチサイト化• 2016年6月現在では、以下の数のサイトが使用可能(将来変動の可能性あり)

– 商用のアイデンティティ・ドメイン : 5サイト以上

– 新しいトライアルのアイデンティティ・ドメイン : 2サイト以上

– 古いトライアルのアイデンティティ・ドメイン : マルチサイト非対応のものあり

• どのサイトが使えるかはドメイン作成時に決められる(ユーザー選択不可)

• リージョンまたぎ(北米と欧州両方使う)は不可

12

商用ドメイン

ゾーン1(PaaS Primary)

ゾーン2

Chicago DC Ashburn DC

ゾーン1

ゾーン2

ゾーン3

トライアルドメイン

ゾーン1(PaaS Primary)


ゾーン1


(参考)マルチサイト for PaaS (DBCS,JCSなど)

• 現在PaaSではIaaSと異なり、インスタンス作成の際にサイト(DC + ゾーン)を選択することができません

– インスタンスを作成した後、どのサイト(DC + ゾーン)に作成されたかがわかります

• 将来は、PaaSもIaaS同様のマルチサイト対応が予定されています

– 例えばDBCSインスタンス作成時に、ゾーンを指定してインスタンスが作成できるようになる見込みです

• 現時点で IaaSと PaaSを同じサイト(DC + ゾーン)で使うには

– まずPaaSインスタンスを作成→ どのサイトに作成されたかがわかる

– その後、Compute Cloud のサイトセレクタで、そのサイトを選択して、そこにIaaSのインスタンスを作る

13



14

2タイプのインスタンス配置高可用性 (High Availablity) 障害回復 (Disaster Recovery)

ドメイン

ゾーン

ゾーン


ゾーン

ゾーン

ゾーン

P

S

P

S

ドメイン

ゾーン

ゾーン


ゾーン

ゾーン

ゾーン

P S

プライマリ・インスタンス

スタンバイ・インスタンス

同じデータセンターの別ゾーンに配置別データセンターのゾーンに配置

プライマリDBやスタンバイDBの配置候補のゾーンが複数ある場合でもユーザーが選ぶことはできません



• アイデンティティ・ドメインにおいて、それぞれの配置タイプに必要なゾーンが存在しない場合は、作成時の検証に失敗して、Data Guard を作成することができません

– 高可用性 (High Availability) が作成できないケース

• 同じデータセンターに別ゾーンがない場合

– 障害回復 (Disaster Recovery) が作成できないケース

• 同じリージョンの別データセンターにゾーンがない場合※マルチゾーン未対応のアイデンティティドメイン

15

未対応のアイデンティティ・ドメインの場合


ゾーン

ゾーン

Data Center Data Center

ゾーン

ゾーン

P

S

S

HA

DR

作成不可

作成不可


クラウド to クラウド Data Guard 適用範囲(障害)

16

障害範囲シングル

インスタンスRAC

Data Guard –高可用性(High

Availability)

Data Guard –障害回復(Disaster

Recovery)

サーバー障害△数分~

(自動再起動)

◎数秒

○数十秒

○数十秒

ゾーン障害 ☓停止

☓停止

○数十秒

○数十秒

データセンター障害 ☓停止

☓停止

☓停止

○数十秒


クラウド to クラウド Data Guard 適用範囲(定期停止)

17

停止タイプシングルインスタ

ンスRAC

Data Guard –高可用性 (High

Availability)

Data Guard –障害回復 (Disaster

Recovery)

Oracle Cloud定期メンテナンス

☓停止

☓停止

☓停止

※将来Availability Domainが実装されれば対応可能にな

る見込み

○無停止

※事前に手動でスイッチオーバーが

必要


• インスタンス(仮想マシン)の状態を監視し、エラーの場合には再起動をかける Oracle Compute Cloud Service の機能

• すべての Database Cloud / Java Cloud などの PaaSサービス・インスタンスにデフォルトで実装

– 関連するOracle Database等のサービスも自動起動

• サーバー等クラウドインフラの障害にも対応

• RTO < 数分程度の可用性要件に対応

18

(参考)Oracle Cloud のインスタンス自動リスタート機能

インスタンスの状態を外部から監視し、エラーなら強制再起動

Oracle Cloud (PaaS & IaaS)

NG?Restart!!

OK OK OK


• Compute Cloud ではユーザーがインスタンス作成時に自動リスタート機能の使用/不使用を選択します

– インスタンス作成ウィザードで高可用性ポリシーをアクティブに設定

• インスタンスクラッシュ時の挙動

– アクティブ→ インスタンスを自動的に再作成

– モニター→ 検知してインスタンスのステータスを「エラー」に設定

– なし→ 何もしない

• 内部的にはオーケストレーションの機能で実装

– “ha-policy” : “active”19

(参考) Compute Cloud Service での自動リスタート機能の利用

oplans":[{

"status": "ready", "obj_type": "launchplan", "ha_policy": "active"

}]

オーケストレーションの設定


Oracle Cloud上での高可用性構成上の注意点

•高可用性構成を取るには、アプリケーションもセットで考える必要があります

•アプリを配置するサービスで取りうる高可用性について考慮が必要です

20



• 現在のPaaSサービス(JCS,App Container)は、特定の1つのゾーンにしかインスタンスを配置できないため、APは高可用性構成が取れません

– Data Guardのスタンバイ先にアプリを配置できない

– APからDBに、ゾーンやDCを跨いでの接続や接続切替(Oracle Net)は可能

• 前述の、PaaSマルチゾーン対応ができるようになれば、APも合わせて高可用性構成がとれるようになる予定です

21

アプリケーションが、PaaS(JCS,ACCなど)にある場合

ドメイン

ゾーン

ゾーン

DC DC

ゾーン

DB

DB

AP DB

AP

AP

Data Guard(HA)

Data Guard(DR)

DB

DB

赤 : プライマリ

緑 : スタンバイ

配置不可

配置不可



• アプリケーションがIaaSであれば、Data Guardのスタンバイ・インスタンスと同じゾーンにインスタンスを配置することで、アプリケーションまで含めた高可用性構成を取ることができます

– Data Guard スタンバイの作成先ゾーンは自分で選択できないので、先にDGを構成してからComputeインスタンスを作成してください

• 注意

– APサーバーに対する接続の切り替えは、現在は手動になります、将来Load Balancer機能が実装されると、透過的な接続ができるようになる見込みです

22

アプリケーションが、IaaS(Compute Cloud)上にある場合

ドメイン

ゾーン

ゾーン

DC DC

ゾーン

DB

DB

AP DB

AP

AP

Data Guard(HA)

Data Guard(DR)

DB

DB

赤 : プライマリ

緑 : スタンバイ

配置可

配置可



• Data Guard 機能の使用に伴う追加課金は発生しない

• RACのような最小OCPU縛りはなし、1 OCPUから作成可能

• インスタンスが2つ立ち上がるので、その分の課金が発生

• プライマリとスタンバイは異なるシェイプを構成できます

• プライマリ 4 OCPU スタンバイ 1 OCPU のような構成が可能、別々にスケールアップ/ダウンできる

• 通常時は 1 OCPUで受信しておいてDR発動後にスケールアップ、という使い方が可能

• 最初は同じシェイプで作成し、1ノードだけをスケールアップ/ダウンして構成します

• 最小課金構成

– Data Guard : 10.15USD/hour(metered) 3050USD/month(Non-metered)

• EE 1 OCPU x2 + Block Storage 1TBのとき

– Active Data Guard : 16.87USD/hour(metered) 5050USD/Month(Non-metered)

• EE-EP 1 OCPU x2 + Block Storage 1TBのとき

24

課金


オンプレミス to クラウド by Data Guard

•オンプレミスDBをクラウドで保護

– Primary：オンプレミス => Standby: クラウド

– Data Guard または Active Data Guardを利用

–現時点でDG構成は手動で実施(将来的に自動化を進める予定)

• MAA 構成として

– MAA 及び Cloud Team により検証済

–技術ホワイトペーパーとして構成手順を発行

32

(Active) Data Guard

On-Premises Primary Database

Oracle CloudStandby Database

Sandbox Test/Dev in the cloud

Reporting



33

MAAホワイトペーパー : Disaster Recovery to the Oracle Public Cloud

http://www.oracle.com/technetwork/database/availability/dr-to-oracle-cloud-2615770.pdf











ホワイトペーパー抜粋 –オンプレミス側ネットワーク & DB設定

• オンプレミス側ネットワーク設定

– OnP-> Cloud: クラウドIPに対して名前解決とFWアクセス・コントロール

– Cloud -> OnP: クラウドIPに対してポートの開放

– オンプレミスDBサーバとクラウドVM間でのプロンプトレスSSH

• Oracle Database の設定

– ARCHIVELOG モード

– Standby Redo Log が、Standby (Cloud) DBの構成前に設定されていること

– Data Guard Broker は構成と管理の簡素化のため推奨



ホワイトペーパー抜粋 –スタンバイDBの作成方法


Oracle Database

Cloud サービスにリカバリ

オンプレミス

プライマリDB

オンプレミスプライマリDB

RMAN DUPLICATE

Oracle Cloudスタンバイ

DB

•オンプレミスDBから直接作成

– RMAN DUPLICATE を使用

• Database Backup Cloudから作成


ホワイトペーパー抜粋 –サポートされる構成


オンプレミス側クラウド側

OS Linux, Windows or Solaris X86 (64-bit) Oracle Enterprise Linux (64-bit)

Oracle DB

Oracle Database Enterprise Edition 11.2.0.4 (64-bit)またはOracle Database Enterprise Edition 12.1.0.2 (64-bit)

Data Guardの場合- AutomatedまたはVirtual Image: Enterprise Edition以上- Exadata Cloud ServiceActive Data Guardの場合- AutomatedまたはVirtual Image: Extreme Performance Edition以上- Exadata Cloud Service

DBサイズ Any sizeDBaaS: 約2.3TB (バックアップあり) *DBaaS: 約5TB (バックアップなし) *Exadata Service: Any size

* 将来拡張される予定



既存のデータベースに安価にDRサイトを追加– オンプレミス側のライフサイクルに非依存

– クラウド側のスタンバイDBは普段は小さなシェイプで稼働

– 高度なデータ保護 (c.f.オフサイト・バックアップ、遠隔レプリケーション)

参照専用データベースの追加(Active Data Guard)– 参照用データベースを追加

– 将来 : In-Memory機能を有効にし高速DWH/データマートを構築(R12.2~)

本番相当データでのテスト環境の追加– スタンバイDBを一時的にテスト用途に利用(Snapshot Standby)

– カスケード・スタンバイ(12c~)

37

利用ケース



• オンプレミス –クラウド間の通信の疎通

– 特にスイッチオーバー/フェイルオーバー後のクラウド to オンプレミスの通信

• 通信帯域

– REDO圧縮の検討

– 将来 : 専用線サービス(Oracle Fast Connect)の利用

• 初期構築時のデータ搬送の方法

– RMANのDUPLICATEコマンド

– Database Backup Cloud Serviceに取得したバックアップをクラウドでリカバリして作成

– 将来 : データの物理搬送サービス(Bulk Data Transfer)の利用

• フェイルオーバー後のオンプレミス側DBの再構成

– Flashback Database活用により、リカバリが不要

38

考慮点

* オンプレミス側のネットワーク環境に依存


参考情報

• Oracle Database Cloud Service

https://cloud.oracle.com/ja_JP/database

• Oracle Database Backup Service

https://cloud.oracle.com/ja_JP/database_backup

•オンプレミス to クラウド MAAホワイトペーパー


• Oracle Maximum Availability Architecturehttp://www.oracle.com/technetwork/jp/content/maa-094615-ja.html

39

https://cloud.oracle.com/ja_JP/database

https://cloud.oracle.com/database_backup

https://cloud.oracle.com/database_backup










http://www.oracle.com/technetwork/jp/content/maa-094615-ja.html






Data & Analytics

Oracle Database Cloud Data Guard機能について