Showing posts with label fail over. Show all posts
Showing posts with label fail over. Show all posts

Wednesday, August 7, 2013

Running web application on AWS

In most cases, you will not just be running just an Oracle database on AWS.  You will be running a web based application.  For Oracle focused developers and engineers, running web applications on AWS is not an area of expertise. Here are the best documents, documentation, and diagrams to review for developing web based applications on AWS:




Support for session state and database failover when application server goes down are a couple of details that most Oracle folks ask about.  Information can be found here:

Session state: Good blog post here: http://harish11g.blogspot.com/2012/10/web-session-synchronization-aws-ec2.html . The last option is DynamoDB which is the method used most often.
Database failover:
  1. Using RDS this is automatic: When automatic failover occurs, your application can remain unaware of what's happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your client library must be able to close and reopen the connection in the event of a failover.
  2. Using Oracle on EC2 : You would use Elastic Ips and use this pattern : http://aws.amazon.com/articles/2127188135977316 . You cloud use ENIs so private Ips could be used http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#create-a-low-budget-high-availability-solution

Thursday, June 27, 2013

Oracle RAC on AWS

Oracle Real Application Clusters (RAC) is not natively supported on AWS. The word natively is used because it is possible to run Oracle RAC in an AWS Direct Connect facility http://aws.amazon.com/directconnect/.

There are a number of options when migrating an Oracle RAC database to AWS.  The option you use depends upon the reason RAC is being used.  For HA and fail over, AWS offers multi-AZ capabilities which can provide the same level of service.  For very large databases that require high transaction through put that can not be achieved on a single instance database, Direct Connect would be the solution.  Details on these options are as follows:
1. RDS with multi-AZ :  Oracle RDS is the managed database service from AWS.  Oracle RDS has builtin multi-AZ capabilities.  Because RDS is a managed service, AWS takes care of installation, configuration and management of the secondary database, the replication between AZs, and the fail over and fail back of the database instance.
2. EC2 with multi-AZ :  Running on EC2 requires the customer or partner to install, configure, manage, and take care of the replication.    Oracle Data Guard or GoldenGate can be used for replication.
3. Direct Connect : The AWS partner Datapipe runs RAC in a managed service model using Direct Connect.


Note: Remember that AWS RDS only supports databases up to 6 TB in size. Note this number changed to 6 TB in June 2015 after being 2 TB. https://aws.amazon.com/about-aws/whats-new/2015/06/amazon-rds-increases-storage-limits-to-6TB-for-piops-and-gp2/. Check the whats new web page for any updates related to Oracle on RDS.

Note:  The reason Oracle Real Application Clusters (RAC) is not supported on AWS is:
1. Multicast is not supported on the AWS network. An overlay network is possible on AWS: http://cloudconclave.blogspot.com/2013/06/overlay-networks-on-aws.html
2. AWS EBS is not a shared disk / clustered file system.
So, even if you use a solution such as Amazon EFS, GlusterFS, Zadara, SoftNAS, or custom NFS for shared disk you can not use RAC on AWS as you need multicast support.  More on Amazon Elastic File System (EFS): https://aws.amazon.com/blogs/aws/amazon-elastic-file-system-shared-file-storage-for-amazon-ec2/ 

Monday, June 3, 2013

AWS VPN connection as a Direct Connect fail over connection


Another question that comes up often: