My Oracle Support Banner

Exadata Cloud at Customer Network Architecture Options for Disaster Recovery (Doc ID 2568676.1)

Last updated on NOVEMBER 22, 2021

Applies to:

Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A to N/A
Information in this document applies to any platform.

Goal

Oracle's Cloud at Customer offering comes in different infrastructure shapes. It is managed by using the Oracle Cloud at Customer Control Plane software suite run on dedicated hardware (Oracle Cloud Control Plane - OCC). The software suite also includes various services such as the Cloud Portal, PaaS Service Manager, Storage Cloud Service, Domain Name Server (DNS), Network Time Protocol (NTP) and others. One or more Exadata Cloud at Customer (ExaCC) systems can be integrated into this (ExaCC) and it will use these services. In a disaster condition where the OCC is lost so will be these services. The ExaCC systems are physically separate from the OCC but they still have a dependency on those services.

Cloud at Customer uses Fully Qualified Domain Names (FQDN) to direct applications to the services it is responsible for. To accomplish this it uses a pair of highly available DNS servers on the OCC. These DNS servers integrate into a customer’s DNS by being a conditional forwarder for a unique domain (name similar to oraclecloudatcustomer.example.com). However, in the case of the loss of connectivity to the OCC, these DNS servers will no longer be available to resolve host names in that domain. To resolve this failure condition, most customer’s DNS is designed with disaster recovery (DR) in mind so it can be used to offload the OCC DNS and become the Authority for that domain.

The Cloud at Customer uses a central NTP server to synchronize the time on all the components. In the case where communication to the OCC is lost, the ExaCCs can be configured to use the customer’s NTP instead.

There are two general configurations that will be covered here, which is a single OCC and where there are two or more OCCs in different data centers. For a more complete decision matrix see <Document 2558737.1>.

For the configuration where there is a single OCC, its Top of Rack (ToR) switch will be connected to the ToR switch of a remote ExaCC through the customer’s network over either a Generic Routing Encapsulation link or using a Network Address Translation link. In the case where communication to the OCC is lost, this link can also be considered lost so there will be a few Cloud Automation applications that will become unavailable, but the ExaCCs should still be available.

Note: The IP addresses used in this note conform to RFC 5737.  The hostnames used have been changed to a notation format.

 

Solution

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Goal
Solution
 Configurations
 Separate Cloud at Customer Installations
 Single OCC Separate ExaCC Installations
 East – West Between Data Centers
 DNS Offload Required for DR Solution
 NTP Change Required for DR Solution
 Conclusion
 Appendix
References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.