Disaster Recovery pomocí Oracle Cloudu

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

Oracle Database Disaster Recovery to Cloud Patrik Plachy Senior Consultatnt, CoreTech Competency Center September 2016

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

Why You Need Disaster Recovery Plan ?

• Avoid Single Point of Failure

• Prevent Data Loss

• Reduce Downtime Cost & Revenue Impact for Planned & Unplanned Outages

• Disaster and Data Protection for Compliance & Regulatory Purposes

Business Continuity


Typical Challenges with Disaster Recovery Deployment

• Complexity in deployment and management

• It takes time for planning & deployment of DR

• Cost associated with CAPEX / OPEX for maintaining another data center and standby

• Keeping up DR site’s resources with production

• On-demand elasticity after failover / switchover

• Return on investment challenges

• Lack of data protection when deploying storage replications based DR

3


Challenges Addressed: Oracle Database DR to Cloud

• Technologies Used

– Oracle Database Enterprise Edition

– Data Guard (or) Active Data Guard features for replicating changes and for data protection

– Oracle Public Cloud – Database Cloud Services / Exadata Cloud Services used for cloud-based standby database

• Engineering Validation

– Maximum Availability Architecture engineering team

4


Active Data Guard – Data Protection, DR – Query Offload

GoldenGate – Active-active replication – Heterogeneous

Active Replica

Oracle Database Backup Service – Backup to cloud

Enterprise Manager Cloud Control – Site Guard, Coordinated Site Failover

Application Continuity – Application HA

Global Data Services – Service Failover / Load Balancing

RAC – Scalability – Server HA

ASM – Local storage protection

Production Site

Flashback – Human error correction

Oracle Maximum Availability Architecture (MAA)

5

On-Prem, Public Cloud, Hybrid Cloud

RMAN, Oracle Secure Backup, Zero Data Loss Recovery Appliance

– Backup to disk, tape, or to cloud


Note: A single DR copy may be multi-purposed for different combinations of the use cases described

SYNC

or

ASYNC

Data Guard &

Active Data Guard

Use Cases: Data Guard and Active Data Guard Real-Time Data Protection and Availability for Oracle Database

New DB

Version Standby First Patching,

Database Rolling Maintenance

Exact copy

of primary Query & Report Offload

Open Read-Only

Snapshot

Standby

Convert to Test Database (open read-write)

Single Command Refresh

Exact copy

of primary Offload RMAN Backups

Exact copy

of primary Disaster Recovery

Manual or Automatic Failover

Redo Far Sync,

GoldenGate Downstream

Exact copy

of primary Source for thin snaps/clones

Exact copy

of primary Extract offload, source for

GoldenGate ALO mode


Data Guard and Active Data Guard Feature Sets

Data Guard (included with EE) Data Protection with HA

• Zero or near-zero data loss protection

• Transparent – all datatypes, workloads

• Continuous data validation

• Detect silent corruption

• Automatic database failover

• Dual-purpose DR as test system

• Simple migrations and upgrades

• Oracle Enterprise Manager integration

Active Data Guard (Option) Advanced Protection with High ROI

• Zero data loss at any distance

• Automatic corruption repair

• Auto-replay of inflight transactions

• Offload transport compression*

• Offload read-only workload

• Offload read-mostly workload

• Offload fast incremental backups

• Automation for rolling upgrades

* Also requires Advanced Compression Option


Data Guard Protection Modes

Mode Risk of data loss Transport If no acknowledgement from standby:

Maximum Protection

Zero Data Loss

Double Failure Protection

SYNC Stall primary until acknowledgement is

received from replica

Maximum Availability

Zero Data Loss

Single Failure Protection

SYNC

FASTSYNC

Far Sync

Stall primary until acknowledgement is received or timeout threshold period expires –

then resume processing

Maximum Performance

Potential for

Minimal Data Loss ASYNC

Primary never waits for standby acknowledgement

(Suitable for Cloud DR)

Balance Data Protection with Performance and Availability


Virtual Image VM + DB + Disk Image

• Similar to Azure image or AMI • Full distribution extracted on disk • Same as on premise hosts • Customer manages their database

Database Cloud Service VM + DB + Full Provisioning

• Backup/recovery automation • Patching and upgrade automation • Data Guard setup • Monitoring & management portals • Local management console

Oracle Database Cloud Services - Offerings

• Oracle Linux 6.4 • On-demand storage & compute • Choice of editions SE1, EE and Database 12c 12.1.0.2, and 11g 11.2.0.4 • Bundles: EE High Performance (most options), EE Extreme Perf (all options) • Full network, VM and OS isolation, Full SQL*Net access • Self-managed with SSH access into VM with root privilege

Database as a Service Full Database Instance Service


Hybrid Cloud: DR to Cloud

• DR to Cloud for Databases

– On-premise Primary OPC Standby (PaaS)

– Using Data Guard or Active Data Guard

– Manual do-it-yourself model (Customer Managed)

• Validation Process

–MAA with OPC team validated end-to-end deployment procedure

• Delivered

–MAA Technical Paper published*

– Scripts & some level of automation provided

10

(Active) Data Guard

On-Premises Primary Database

Oracle Cloud Standby Database

Sandbox Test/Dev in the cloud

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

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











Customer Benefits: Cloud-based Disaster Recovery Site

• Huge CAPEX & OPEX savings

–No need to maintain DR infrastructure

• Instantaneous availability of DR site

– No need to wait for months

• DR for compliance & regulatory purposes – Physically remote location with data protection

• Use standby in the cloud for DR and also reporting and testing

– Multiple use cases with DR site

• Short and long time DR site

– Commission or de-commission on-demand

11


General Hybrid DR Considerations

• Service Level Agreements

– RTO and RPO

– Latency between on-premises and Oracle Public Cloud

• Network Security

– End-to-end data encryption

– Key management

• Standby encryption at rest

• Management of Standby database using cloud portal

• Database & Application layer failovers 12


• Database Versions

– Oracle Database EE 11.2.0.4 or above

– Oracle Database EE 12.1.0.2 or above

• Platform (64-bit)

– Generic Platform:Linux, Windows, Solaris-X86

– Exadata: Linux

• If using Active Data Guard based DR

– On-premises to be licensed for Active Data Guard

• Database Versions

– Oracle Database 11.2.0.4 – Enterprise Edition

– Oracle Database 12.1.0.2 – Enterprise Edition

• Platform (64-bit)

– Generic : Linux

– Exadata: Linux

• Minimum DBCS Subscription

– Data Guard: Enterprise Edition

– Active Data Guard: Extreme Performance Edition (DBaaS or Exadata Cloud Service)

• Automated (Production) / Virtual Image (Evaluation)

13

DR to Cloud: Supported Environment

Standby Site in the Cloud Primary Site On-Premises


• Using Data Guard

– Instantaneous remote DR Site in the cloud

– Use cloud-based Standby for temporarily testing the data by converting to read/write

– Offload regular backups from standby

– Use cloud-based Standby for standby-first patching, rolling upgrades

• Using Active Data Guard

(in addition to Data Guard use cases)

– Use cloud-based Standby for read-only workloads

– Repair on-premises primary corrupted blocks automatically from standby

– Offload fast backups from standby

– Create many standby databases with real-time cascading (12c)

– Application continuity (12c)

– Advanced database rolling upgrade features (12c)

14

DR to Cloud: Use Cases


DR to Cloud: Lifecycle

Subscription & Licensing

Pre-paid DBCS Subscription

On-premises Active Data Guard licensing

Cloud Service Creation

Instance creation

Automated or Virtual Image

Extreme Performance

Network Configuration

Cloud-side SSH

Restrict IP address access

Create listener port

On-premises network security

Enabling Security

On-Premises SQL*Net

TDE encryption (optional)

Instantiate Standby

From on-premises

Using RMAN DUPLICATE

Using Oracle Database Backup

Service

Runtime Management

Health Check / Monitor Lags

Validate DR setup

Failover/Switchover to Cloud

Use Standby for reporting, testing

15


• Database Cloud Service

– Up to 5TB usable capacity without backups

– Up to 2.3TB usable capacity with option to backup local in the cloud or to Database Backup Service

• Exadata Service

– Larger databases

– Best Performance

– Option to backup to Database Backup Service

16

1. Oracle Public Cloud: DBaaS


2. Service (Instance) Creation

• Choose Database Cloud Service (Automated) for production

• Virtual Image can be chosen for evaluation

• Provide the service / SID name that you want for the standby database

• Backup settings are optional

17


3. Cloud VM Instance Details

• Once the default instance is created, IP address is assigned

• Default port 1521 is configured

– Has secured SSH access

– But access open to all IP addresses

• Database is created with instance up & running – This instance is not needed and to be

deleted

– This restriction will be removed once we have automation

18


4. Cloud-side Network Settings

Procedure to create new listener port

1. Create Security IP list

– Restrict access only to the on-premises primary database’s IP address

2. Create a new Security Application

– Define a new port #

3. Create a Security Rule – For the standby database instance and

security IP list

19


5. On-Premises Network Settings

• Every customer site has different network security requirements

• Network Administrator has to make sure

– Name resolution & Firewall Access Control List to the cloud IP (On-Premises Cloud)

– Ports are open ONLY to the cloud-side IP address (Cloud On-Premises)

– Prompt-less SSH between On-Premises DB server and Cloud VM

• Oracle environment settings

– Database must be running in ARCHIVELOG mode

– Standby Redo Logs (SRL) must be configured before Standby instantiation in the cloud

– Recommended to use Data Guard Broker for easier deployment and management

20


2. From the cloud backup

1. From On-Premises production database using RMAN ACTIVE DUPLICATE

21

Standby Database Instantiation in the Cloud

Oracle Cloud

Standby Database

On-Premises Primary

Database

On-Premises Primary Database

RMAN DUPLICATE

Oracle Cloud Standby

Database


• On-Premises Primary

1. Configure promptless SSH

2. Database must be in ARCHIVELOG

3. Size Online Redo Logs

4. Create Standby Redo Logs (SRL)

5. Set TCP socket size

6. Configure Oracle Net encryption configuration

7. Configure tnsnames.ora, listener.ora

8. Perform Cloud Standby tasks

9. Run RMAN DUPLICATE command

10. Configure Data Guard Broker

• Cloud Standby

1. Delete the default database created during instance creation*

2. Configure tnsnames.ora, listener.ora

3. Create Auxiliary Database init.ora and password files

4. Start the instance in NOMOUNT

22

Standby Instantiation Directly From Production

* This step won’t be required for Virtual Image


Standby Instantiation from Production

Standby Database(s) on Oracle Public Cloud

Databases Applications Clients

On-Premises (Production)

Fir

ewal

l

Exadata Cloud

Service

Dedicated Compute

General Purpose

DBCS

RMAN DUPLICATE (Encrypted)

RMAN DUPLICATE (Encrypted)

Oracle Public Cloud


Standby Instantiation from Database Cloud Backup

• Pre-requisite

– Backup from the on-premises database already exist in Oracle Cloud

• In the cloud VM

– Perform RMAN Oracle Cloud Module installation using same credential

– Set DBID (same as primary), decryption key

– Restore SPFILE

– Edit SPFILE and fix destination path, location, DB_UNIQUE_NAME, db_file_name_convert, log_file_name_convert

– Restore standby control file

– Restore Database

– Configure Data Guard Broker

24


Standby Instantiation from Database Backup Cloud Service




Database Backup Service

Fir

ewal

l

Exadata Cloud

Service

Dedicated Compute

General Purpose

DBCS

Oracle Public Cloud

RESTORE

RESTORE

RESTORE


• Primary Site (On-premises)

– Databases can be on physical systems or virtual

– Database optionally encrypted

– Network ports open and configured

– Applications are available only on-premises

– Secured log shipping

• Standby Site (Oracle Public Cloud)

– Standby database created on Database Cloud Service – Automated / Virtual Image

– Data Guard • Enterprise Edition or above

• Used for testing

– Active Data Guard • Extreme Performance

• Used for real-time reporting, testing

26

On-Premises Cloud: Steady State Operation






Fir

ewal

l

Database Cloud

Service

Active Data Guard (Encrypted)

Active Data Guard (Encrypted)

Oracle Public Cloud

Reporting

Sandbox Test/Dev in the cloud

DR to Cloud – Steady State


Switchover / Failover to Cloud based Standby

• Standby in the cloud is activated for DR by either

– manually using documented procedure (or)

– automatically using Data Guard broker

• Applications from on-premises then access the standby in the cloud

• If failed over for DR, then the standby DB is used as production DB

• If using standby for standby patch-first, or rolling upgrades

– User follows the fully documented procedure

• If Active Data Guard is used, then the standby is opened read-only

– Reporting, backups and other read-only operations

28



Applications Clients



Fir

ewal

l

Database Cloud

Service

Oracle Public Cloud

Application Access – After Switchover


Today: Self Service (DIY)

1. Disaster Recovery for Databases

2. Standby-first Patching (Switchover)

3. Rolling Upgrades (Switchover)

4. Reporting

5. Testing

Future: Semi-Automated

1. Automating scripts for certain complex operations

2. Sandbox creation (Cloning from Standby for test/dev)

30

Future: Fully Automated DRaaS

• Push button services

– Automate the whole provisioning and configuration process

– Sandbox creation

• Enable multiple DRaaS use cases

• Full stack failover (including Applications)

• Application Testing

Staged Roll-out of DR to Cloud


Today: Self Service DIY

– Mostly customer driven, hence no DR specific SLA guarantees

– Cloud Database SLAs still applicable

– Alert generation for Transport lag, RPO exposure

– Estimate time required to activate standby

Future: Hybrid DRaaS

– Automated process with limited SLAs

– Cloud Database SLAs still applicable

– Alert generation for Transport lag, RPO exposure

– SLA for activating standby

31

Future: DRaaS in the Cloud

– Services offered by Oracle

– SLAs for RTO / RPO with levels of service

• Gold, Silver, Bronze

– Fully automated with push-button services

Service Level Agreements: Now & Future


Considerations

• Application layer DR to cloud

– Application layers in OPC: JCS, BICS, Dedicated Compute (Future)

– Non JCS/BICS customers must connect their applications from on-premises

– Mitigation: DR for full-stack support planned

• Manual procedure of DR deployment

– Mitigation: Automation Planned

• Non availability of VPN

– Mitigation: VPN support planned for OPC

• Encryption

– Primary site has to be encrypted to support encrypted standby in the cloud

• High network bandwidth and low latency option with partners

32


DR to Cloud: Summary

33

Oracle Public Cloud for seamless DR deployment

Avoid single point of failure using DR

Cloud-based DR addresses compliance and regulatory requirements

No separate DR site maintenance by customer

Cloud-based instance used for DR, testing & reporting

On-demand resource elasticity in the cloud

No CAPEX

Instantaneous DR site


Reference

• Maximum Availability Architecture

– http://oracle.com/goto/maa

• Data Guard / Active Data Guard

– http://oracle.com/goto/dataguard

• Oracle Public Cloud – https://cloud.oracle.com/database

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

34

http://oracle.com/goto/maa

http://oracle.com/goto/dataguard

https://cloud.oracle.com/database




https://cloud.oracle.com/database_backup


Q & A

Technology

Disaster Recovery pomocí Oracle Cloudu