Showing posts with label DR. Show all posts
Showing posts with label DR. Show all posts

Monday, April 7, 2014

Oracle RDS GoldenGate support

Oracle GoldenGate can be used with Amazon RDS for Oracle for active-active database replication, zero-downtime migration and upgrades, disaster recovery and data protection, and cross region replication. 

Thursday, January 2, 2014

Accenture white paper : Disaster Recovery with Amazon Web Services


Disaster Recovery with Amazon Web Services:
A Technical Guide
The paper covers
1. Define the challenges that enterprises face in adopting public cloud solutions for disaster recovery.
2. Describe the value that large enterprises can gain by adopting cloud-based DR with services such as Amazon Web Services (AWS) for disaster recovery.
3. Provide recommended disaster recovery architecture patterns.

http://www.accenture.com/microsite/reinvent-2013/Documents/Accentue-Smart-Disaster-Recovery-with-Amazon-Web-Services.pdf

Monday, November 18, 2013

AWS Database reference implementation

This reference implementation provides the architecture and associated CloudFormation templates for a standard, enterprise class, large enterprise class and high performance Oracle 11g configuration on AWS EC2:
http://media.amazonwebservices.com/AWS_RDBMS_Oracle_11g_on_EC2_Reference_Architecture.pdf

Friday, August 30, 2013

AWS re:Invent enterprise sessions


DAT202 - Using Amazon RDS to Power Enterprise Applications Amazon Relational Database Service (Amazon RDS) makes it cheap and easy to deploy, manage, and scale relational databases using a familiar MySQL, Oracle or MS SQL server database engine. Amazon RDS can be an excellent choice for running many large, off-the-shelf enterprise applications from companies like JD Edwards, Oracle, PeopleSoft, and Siebel. Sign up for this session to learn how to best leverage Amazon RDS for use with enterprise applications and learn about best practices and data migration strategies.


DAT401 - Advanced Data Migration Techniques for Amazon RDS Migrating data from the existing environments to AWS is a key part of the overall migration to Amazon RDS for most customers. Moving data into Amazon Relational Database Service (Amazon RDS) from existing production systems in a reliable, synchronized manner with minimum downtime requires careful planning and the use appropriate tools and technologies. Because each migration scenario is different in terms of source and target systems, tools, and data sizes, you'll need to customize your data migration strategy to achieve the best outcome. In this session we will do a deep dive into various methods, tools and technologies that can be put to use for a successful and timely data migration to Amazon RDS.


STG301 - AWS Storage Tiers for Enterprise Workloads - Best Practices Enterprise environments utilize many different kinds of storage technologies from different vendors to fulfill various needs in their IT landscape. These are often very expensive and procurement cycles quite lengthy. They also need specialized expertise in each vendor's storage technologies to configure them and integrate them into the ecosystem, again resulting in prolonged project cycles and added cost. AWS provides end-to-end storage solutions that will fulfill all these needs of Enterprise Environments that are easily manageable, extremely cost effective, fully integrated and totally on demand. These storage technologies include Elastic Block Store (EBS) for instance attached block storage, Amazon Simple Storage Service (Amazon S3) for object (file) storage and Amazon Glacier for archival. An enterprise database environment is an excellent example of a system that could use all these storage technologies to implement an end-to-end solution using striped PIOPS volumes for data files, Standard EBS volumes for log files, S3 for database backup using Oracle Secure Backup and Glacier for long-time archival from S3 based on time lapse rules. In this session, we will explore the best practices for utilizing AWS storage tiers for enterprise workloads

STG305 - Disaster Recovery Site on AWS - Minimal Cost Maximum Efficiency Implementation of  disaster recovery (DR) site is crucial for business continuity of any enterprise. Due to the fundamental nature of features like elasticity, scalability and geographic distribution, DR implementation on AWS can be done at 10-50% of the conventional cost. In this session, we will do a deep dive into proven DR architectures on AWS and best practices, tools and techniques get the most out of them.


STG303 - Running Microsoft and Oracle Stacks on Elastic Block Store Run your Enterprise applications on Elastic Block Store (EBS). This session will discuss how you can leverage the block storage platform (EBS) as you move your Microsoft (SQL Server, Exchange, SharePoint) and Oracle (Databases, E-business Suite, Business Intelligence) workloads onto Amazon Web Services (AWS). The session will cover high availability, performance, and backup/restore best practices

ENT303 - Migrating Enterprise Applications to AWS - Best Practices, Tools and Techniques In this session we will discuss strategies, tools and techniques for migrating enterprise software systems to AWS. We'll consider applications like Oracle eBusiness Suite, SAP, PeopleSoft, JD Edwards and Siebel. These applications are complex by themselves; they are frequently customized; they have many touch points on other systems in the enterprise; and they often have large associated databases. Nevertheless, running enterprise applications in the cloud affords powerful benefits. We'll identify success factors and best practices.

Wednesday, May 1, 2013

AWS disaster recovery for applications, database and storage


When coming up with an approach to perform disaster recovery on AWS from your on premise environment,  you need to look at these layers of your system as individual entities.  This is because for each of them their are different tools and approaches.
1. Storage Layer: The storage layer includes multi media files, batch files, log files and any other files that not directly owned by the application or database server.  These files are typically on SAN or NAS devices on premise.
More information here:

2. Database Layer:  This would be data files associated with your relational or NoSQL database.  There are many database vendor specific tools. So the best approach is typically to use the tool or facility provided by the DB vendor.  
More information in these blog entries:
http://cloudconclave.blogspot.com/2013/01/disaster-recovery-in-cloud-options.html
http://cloudconclave.blogspot.com/2013/03/aws-ebs-snapshot-volumes-for-mysql.html – More on snapshots as apply to MySQL


http://cloudconclave.blogspot.com/2013/03/aws-ec2-oracle-database-backup.html - OSB or EBS snapshots
http://cloudconclave.blogspot.com/2012/10/oracle-helps-amazon-save-money-on.html – More on OSB
http://cloudconclave.blogspot.com/2013/01/oracle-exadata-dr-to-cloud.html - Exadata
http://cloudconclave.blogspot.com/2013/02/oracle-secure-backup-restore.html – Recovery speed for OSB



3. Application Layer:  The application layer includes all source code (Java, PHP, Ruby, HTML etc), log files and anything else associated with your application server.
More entries in these blog entries:







Tuesday, April 30, 2013

On premise application replication and snap shots to AWS for DR

When devising an disaster recovery approach that used AWS for DR of an on premise environment, there are literally hundreds of options for keeping the databases in sync. Each relational database vendor will have five of their own options and their partner ecosystems will offer many more.  For the application, it is different situation.  Their are not many features built into business application  and application servers.  Depending on what DR scenario you are using http://cloudconclave.blogspot.com/2012/11/aws-four-dr-scenarios.html you will be using either replication or snapshots to keep your AWS application in sync with your on premise environment.  
For warm standby and active-active you will need replication:

  • RSync : Rsync is cheap (free) and easy.  Rsync can be chatty, does not have compression built in, and you have to code parallelism. 
  • BitTorrent : BitTorrent is most often associated with moving large media files over the Internet in a fast matter. BitTorrent now has file syncing capabilities so can be used to sync application server files.  
  • Amazon Storage Gateway " attach these volumes as iSCSI devices to your on-premises application servers.  These files will be stored in S3 where they can be instantiate as EBS volumes.

  • Riverbed Whitewater - http://www.riverbed.com/products-solutions/products/cloud-storage-whitewater/ https://aws.amazon.com/marketplace/pp/B007O0FXW4/ref=srh_res_product_title?ie=UTF8&sr=0-2&qid=1366938137611#product-detail
  • Attunity CloudBeam - http://www.attunitycloudbeam.com/solutions/disaster-recovery  https://aws.amazon.com/marketplace/pp/B00B5PB8IM/ref=srh_res_product_title?ie=UTF8&sr=0-3&qid=1366938015695


  • For backup and restore and pilot light you can use snapshots. 

    • FTP or SFTP : FTP and SFTP are the two most common methods to transfer files over the internet.
    • HTTP or HTTPs : HTTP and HTTPS can be used but they are slower than S/FTP.  However, if you don't want to require or can not have an FTP client in use than HTTP(s) can be used.  Some companies may not want to open up another port to the outside world have an FTP server running.
    • AWS import/export : If files don't need to be synced that often, FedEx, UPS, or Post Office can be the least expensive method with the least amount of hassle (limited coding, no restarting needed)
    • Attunity CloudBeam to move files into S3 and than instantiate as EBS volumes.

    Oracle EBusiness Suite does offer rapid clone http://docs.oracle.com/cd/E18727_01/doc.121/e12841/T120505T120517.htm but this is not for moving production system data files but for setting test, dev, or moving a system to another machine. Weblogic also offers a cloning feature :http://docs.oracle.com/cd/E12839_01/core.1111/e10105/clone.htm

    Thursday, March 7, 2013

    AWS EC2 Oracle Database backup

    The two most common approaches for backing up Oracle databases hosted on EC2/EBS:  
    1. The Oracle Secure Backup Cloud Module allows Oracle's Recovery Manager (RMAN) to backup/restore directly to/from S3.  https://aws.amazon.com/backup-storage/gsg-oracle-rman/ 
    2. DBAs can put their tablespaces in hot backup mode, issue EBS snapshots using the EC2 CLI (http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/OperationList-cmd.html), and then take the Oracle database out of hot backup mode as soon as the EC2 EBS snapshot API call returns.  While in hot backup mode, Oracle logs the full block images to the online and archived redo logs. There is a write up here on how this works:

    Friday, January 25, 2013

    Disaster recovery in the cloud options

    These are by all means not all the options, but at a high level these are the common options:

    • Backup and restore - Have to set up security groups set up and set up Route53. Data is not being mirrored or replication. You are doing an import and export from database to S3. When system goes down then resource S3 data to the database. You also have to provision AMIs.
    • Pilot light – In this case, you are doing Data mirroring/replication from source system to DR site. Could run GoldenGate. The EC2 instances are present but stopped. Have to prepare all required resources from automatic start – AMIS, network settings, load balancing etc.
    • Fully working low capacity standby – Blurring lines between HA and DR. In this case have an issue with RDS as the data needs to replicated both ways as traffic could go to either configuration.
    • Multi-site hot standby – production load on both sides. Cost and data sync are the biggest challenges.

    Thursday, January 24, 2013

    Tuesday, December 18, 2012

    AWS EBS cross region migration

    AWS offers the capability to migrate an EBS volume from one region to another.  The feature applies to any application or database data:
    http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html

    This can be used to move Oracle database EBS snapshot from one region to another for HA and DR.

    Thursday, November 8, 2012

    AWS Storage Gateway for application DR

    The AWS Storage Gateway along with EC2 instances is a method to start up your application in AWS in the event your data center is not functioning.

    1. Data that is written to your  data center iSCSI volumes is recorded in the AWS Storage gateway in your data center and is asynchronously stored in Amazon S3 (Simple Storage Service) in the form of Amazon EBS (Elastic Block Store) snapshots. 
    2.Create an Amazon EBS volume from a the EBS snapshot in S3
    3. Start up or create an EC2 Instance from an AMI
    4. Mount the EBS volume to an Amazon EC2 instance
    5. Use Amazon Route 53 services so users are pointed to the instance running in the cloud.
    6,. Restart the application completely from the cloud.

    Saturday, November 3, 2012

    AWS Four DR scenarios

    There are four DR scenarios that highlight usage of AWS in a DR and a 'HA-lite' situation:
    •  Backup and Restore - For systems running on AWS, customers also back up into Amazon S3. Snapshots of Elastic Block Store (EBS) volumes and backups of Amazon RDS are stored in Amazon S3. Alternatively, you can copy files directly into Amazon S3, or you can choose to create backup files and copy them to Amazon S3.
    • Pilot Light for Simple Recovery into AWS - This scenario is similar to a Backup and Restore scenario, however, you must ensure that you have the most critical core elements of your system already configured and running in AWS (the pilot light). When the time comes for recovery, you would then rapidly provision a full scale production environment around the critical core. The database data would be replicated to S3. You would typically have some pre-configured servers bundled as Amazon Machine Images (AMIs), which are ready to be started up at a moment’s notice.  These servers could be EC2 instances that have been stopped.
    • Warm Standby Solution - A warm standby solution extends the pilot light elements and preparation. It further decreases the recovery time because in this case, some services are always running. By identifying your business-critical systems, you would fully duplicate these systems on in another AWS zone or region and have them always on.  This would insure that the EC2 capacity is available in a disaster.
    •  Active-Active Solution - A multi-site solution runs in another AZ or zone in an active-active configuration. The data replication method that you employ will be determined by the recovery point (RPO) you choose.

    Wednesday, October 10, 2012

    Oracle helps Amazon save money on database backups

    Very good article on moving from tape storage to AWS S3 for Oracle Database backups and archiving:


    White paper can be found here:
    There are some very good ideas on how to secure you backup data both in transit and at rest.

    You can find the Oracle Secure Back solution for AWS here:
    http://www.oracle.com/technetwork/products/secure-backup/secure-backup-s3-484709.html