disaster recovery pomocí oracle cloudu
TRANSCRIPT
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• 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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• 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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• 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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• 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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Instantiation from Database Backup Cloud Service
Standby Database(s) on Oracle Public Cloud
Databases Applications Clients
On-Premises (Production)
Database Backup Service
Fir
ewal
l
Exadata Cloud
Service
Dedicated Compute
General Purpose
DBCS
Oracle Public Cloud
RESTORE
RESTORE
RESTORE
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• 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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Database(s) on Oracle Public Cloud
Databases Applications Clients
On-Premises (Production)
Database Backup Service
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Database(s) on Oracle Public Cloud
Applications Clients
On-Premises (Production)
Database Backup Service
Fir
ewal
l
Database Cloud
Service
Oracle Public Cloud
Application Access – After Switchover
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
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