A hybrid cloud architecture is a good solution for a company that doesn’t want to compromise on the advantages provided by public and private clouds. Because your infrastructure is already split between two systems, it is easier to migrate to a different public cloud when a better model enters the market.
How organizations use Oracle Database varies heavily from implementation to implementation. In some situations, a database is used for online transaction processing (OLTP). In other situations, it might be used as part of a business-decision support system that uses very large databases with high reliability requirements and less stringent performance expectations. A third scenario might combine all the requirements mentioned above and might also require high availability, reliability, data protection, and high performance, as well as scalability and load distribution. These scenarios cover many use cases for an Oracle Database in most businesses.
In this blog, we discuss a few hybrid cloud deployment architectures for Oracle Database that fit very well with the scenarios discussed above. Each architecture discussed here uses a distinct disaster recovery (DR) pattern (with NetApp SnapMirror, Oracle data guard or mix of both) based on the theme of the overall architecture. The cost factor, database recovery time and load balancing will be the key decision factors while choosing between snapmirror and oracle data guard model. SnapMirror may be a cost effective solution because you don’t require your DR compute to be running all the time in cloud nor require separate licensing like Oracle data guard. Data guard may meet your near zero RTO and read load balancing needs in an active configuration. Depending on your objectives, you can mix and match the primary database and disaster recovery architectures to fit your needs. The following discussion puts the architectures in order of increasing levels of capability, complexity, and cost.
Standard Architecture -I
The standard architecture provides a relatively simple hybrid cloud in which a user can fully manage their cloud storage and compute infrastructure. You can use Oracle Data Guard (Classic or Active) for DR data replication. This configuration has a hot standby database in the cloud to provide quick (near zero RTO) and transparent DR failover for production applications . The Data Guard standby database can be hosted on NetApp Cloud Volumes ONTAP (CVO) storage in AWS or Azure. Having CVO helps you to meet your secondary needs by offloading backup requests to a standby Data Guard instance instead of the production instance. SnapCenter can be used to back up your standby database on CVO and use it for dev/test, reporting, analytics, and other requirements.
Standard Architecture -II
The primary difference with the previous version of the standard architecture is that it uses NetApp SnapMirror for DR replication. Unlike Data Guard, SnapMirror doesn’t require database VMs to be up and running on the DR site. You can spin them up during the DR failover with the help of templates stored in the cloud. The second major difference is that you cannot access the data directly from a SnapMirror destination. Rather, data access can be through NetApp FlexClone to get read/writable copy of the database instance, whereas, in active Data Guard, the read I/O can be load-balanced between on-premises and the cloud. Lastly, Automation is required to break the mirror relationship, perform in-place restore of a database storage using an Oracle consistent snapshot, mount the storage, and recover the database for applications.
Classic Architecture
The classic architecture is a commonly used enterprise configuration in which a customer’s cloud storage is fully managed by the cloud provider (AWS/ Azure), and the customer doesn’t have to maintain or patch/upgrade anything manually. In this configuration, DR data replication is performed via Oracle Data Guard (Classic type or Active). The above two classic architectures have Oracle active Data Guard standby database in common and is either hosted on Amazon FSx for NetApp ONTAP (FSxN) or Azure NetApp files, our fully managed storage service offered by Amazon and Azure. The first classic architecture listed above is slightly unique where the database service is hosted via Amazon RDS Custom with a dummy database. This dummy database is then deleted to rebuild a new active Data Guard standby database on Amazon FSx for NetApp ONTAP storage. Customers who are interested in a managed service architecture from Amazon can go for RDS Custom for Oracle service with FSx for ONTAP storage. For better and consistent network connectivity between sites for load balancing, it is better to go for a high bandwidth, low latency connections offered by AWS Direct connect or Azure Express route.
If the Data Guard relationship is replaced with NetApp SnapMirror for data replication, then you will get the below architecture. This may be a better candidate for Oracle standard edition (SE2) customer who doesn’t have Oracle data guard and are actively looking to migrate from on-premises to AWS RDS Custom service.
Enterprise /Large Enterprise Architecture
These are Enterprise-ready architectures similar to the Classic Architecture but with more focus on availability and business continuity. This architecture provides better availability and read performance because it has two Data Guard standby instances. The local relationship is synchronous with an RPO of 0 and a near-zero RTO, and the distant relationship is asynchronous to cloud storage.
Cloud Volumes ONTAP, FSxN, and ANF are the various storage options to host the standby database in which FSxN and ANF are the managed storage offerings. The remainder of the features and benefits are the same as the Standard /classic Architecture.
There are 2 models discussed below in the second architecture (mixed technology model) with the model shown below has the Data Guard relationship between the sites as synchronous, and the SnapMirror relationship between on-premises and the cloud as asynchronous.
Similarly, the second model shown below replaces the technologies in the model 1 with NetApp SMBC or Metrocluster for synchronous replication /business continuity and Oracle active data guard for asynchronous replication.
This model can help you in quick DR failover to cloud along with better read load balancing capability across sites. Any Cloud SaaS /BI applications can fetch the data from the active data guard standby database for reporting, Analytics purposes. With both the models, your 3-2-1 backup objective and Dev/Test needs can be met using NetApp SnapCenter and cloud backup for applications. You can also optionally tier your tertiary storage with cloud tiering for better space optimization.
The last and final architecture shown below has the local and remote Data replication relationship completely designed on NetApp technologies like snapmirror and metrocluster. It provides better availability across sites, and can meet your 3-2-1 backup objectives and data management cost efficiently.
What's Next?
For more information, check the NetApp documentation or contact us here for any product related queries or other feedbacks.
