Understand Your Deployment Architecture Options
When initially provisioned, all instances of Oracle Content Management are deployed on Oracle Cloud Infrastructure. This architecture is a high-availability topology across multiple availability domains within a single geographic region. It uses Oracle Container Engine for Kubernetes (OKE) with its elastically scalable Kubernetes clusters across these availability domains.
- Availability Domains—An availability domain is one or more data centers located within a region. Availability domains are isolated from each other, fault tolerant, and unlikely to fail simultaneously. Because availability domains don’t share physical infrastructure, such as power or cooling, or the internal availability domain network, a failure that impacts one availability domain is unlikely to impact others. Availability domains in a region are connected to each other by a low-latency, high-bandwidth network. This predictable, encrypted interconnection between availability domains provides the building blocks for both high availability and disaster recovery.
- Fault Domains—A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. As a result, hardware failures or maintenance events that affect one fault domain do not affect instances in other fault domains. You can optionally specify the fault domain for a new instance at launch time, or you can let the system select one for you.
In a default deployment, OKE automatically creates multiple clusters (or nodes) across availability domains. All sites and assets are synchronized to each availability domain. If one availability domain goes down, OKE automatically directs all incoming traffic to the operational availability domains. That way end users won't notice a service outage while the failed availability domain is being restored.
We encourage you to use our Upgrade Schedule option to control when your instance receives a new release of Oracle Content Management. In most cases your instance that serves production traffic should use the delayed upgrade option. Instances that are meant for development and testing purposes should use the upgrade immediately option. This combination of settings will provide you a full release cycle to ensure your code is robust and provide you time to address any issues before they might impact your production traffic. The Upgrade Schedule option is set when you create your Oracle Content Management instance.
Oracle Content Management Native Disaster Recovery
Oracle Content Management provides a native disaster recovery product option. The Oracle Content Management disaster recovery product capability essentially provides a full-stack orchestration of the service that includes comprehensive disaster recovery failover capabilities for all layers of the Oracle Content Management application stack including the Oracle Content Management application tiers, database, search index, and object storage.
The terms "Oracle Content Management full-stack disaster recovery", "full-stack disaster recovery", and "disaster recovery" are used interchangeably throughout this documentation. All the terms refer to the same service.
Full-stack disaster recovery assures comprehensive business continuity from a variety of data center outages to ensure that organizations have a minimal impact from region-wide outages.
Oracle Content Management disaster recovery is easily enabled for your Oracle Content Management instance as an add-on product service option. You can actively monitor Oracle Content Management enabled disaster recovery instances via Oracle Cloud Console operations. You can also validate and monitor business continuity readiness and compliance by periodically running disaster recovery switchover tests.
Benefits of Oracle Content Management Disaster Recovery
Oracle Content Management disaster recovery provides multiple benefits in the area of business continuity.
- Provides full application recovery: Oracle Content Management disaster recovery provides recovery for the entire application stack, which includes the components such as database, search indexes, object storage, and the application tier. This full-stack disaster recovery allows for business continuity that depends on recovering the entire application stack instead of a few select components.
- Minimizes disaster recovery time: Oracle Content Management disaster recovery eliminates the need to perform manual disaster recovery for individual resources.
- Eliminates the need for special skills: The operators and administrators don't require any special skills or domain expertise in areas such as applications and storage replication.
- Single pane of glass monitoring and management: Oracle Content Management disaster recovery provides a single pane of glass monitoring and management capability for all Oracle Content Management disaster recovery enabled instances. You can create disaster recovery instances, monitor disaster recovery readiness and check status using the Oracle Cloud Console.
Disaster Recovery Terminology and Concepts
Before using Oracle Content Management disaster recovery, familiarize yourself with the following key terms and concepts.
- Disaster Recovery (DR)—The process of restoring some or all parts of a business system (a service) after an outage. The recovery of this business system occurs across data centers within the same localized geographic area.
- Full Stack—A term used to collectively refer to all the functional layers of a business system, application, or software service. An application can be comprised of different functional layers or tiers such as application layer, middleware layer, database layer, and infrastructure layer.
- Recovery Point Objective (RPO)—The RPO defines the maximum amount of data loss that can be tolerated as part of the DR restoration. RPO is typically expressed in units of time.
- Recovery Time Objective (RTO)—The RTO defines the maximum amount of time that the application or service under DR protection can be unavailable until service is restored. RTO is typically expressed in units of time.
- Primary—The production version of an application or service that is currently in use. Disaster recovery refers to the primary version of an application as having a primary role.
- Standby—The reserved version of an application or service. Standby is also used to refer to the alternate region in which the application or service will be restored. Disaster recovery refers to the standby version of an application as having a standby role.
- Warm Standby—A DR model in which some or all of the components of an application or service are pre-deployed in the standby region to prepare for a future DR transition. This model involves higher operating costs but a lower RTO. Oracle Content Management DR support uses a warm standby implementation.
- Cold Standby—A DR model in which very few or none of the components of an application or service need to be pre-deployed in the standby region in preparation for a future DR transition. The application components are deployed as part of the DR transition. This model involves lower operating costs but a higher RTO.
- Role—Specifies whether an application and its region is currently the primary (production) version or the standby (reserved) version. An application's role and its region's role changes as a result of a DR transition.
- Association—A pair relationship defined between two Oracle Content Management instances. An Oracle Content Management DR enabled instance is associated (paired) in a primary and standby relationship before they can be used to implement DR services.
- Switchover—In the case of Oracle Content Management this is a scheduled DR event that performs a planned transition of Oracle Content Management from the primary DR instance to the standby DR instance. Switchover performs an orderly transition by shutting down the application stack in the primary region and then activating the standby service to become active.
- Failover—In the case of Oracle Content Management this would be an unscheduled event that requires Oracle to perform a failover transition by activating the Oracle Content Management warm standby instance in the standby region, in the event of a service outage in the primary region.
Failover Recovery Process
Oracle controls when failover is activated for your Oracle Content Management service. For Oracle Content Management the disaster recovery performance targets are as follows:
- Recovery Time Objective (RTO) = one hour—The RTO is the target time that is required to restore your application functionality after a disaster happens.
RTO is Oracle’s objective for the maximum period of time between Oracle’s decision to activate the disaster recovery processes and the point at which you can resume production operations in an alternative site. If the decision to activate disaster recovery processes is made during the period in which an upgrade is in process, the RTO extends to include the time required to complete the upgrade.
- Recovery Point Objective (RPO) = one hour—The RPO is Oracle's target timeframe of lost data that your applications can potentially lose during a failover event.
Oracle’s objective for the maximum period of data loss measured as the time from which the first transaction is lost until Oracle’s declaration of the disaster. The RPO does not apply to any data loads that are underway when the disaster occurs.
Switchover Testing Process
Oracle allows customers to test a switchover of their Oracle Content Management disaster recovery enabled instances. To test switchover, log a service request against your Oracle Content Management instance, and the Oracle support team will work to schedule the test.
Implement Disaster Recovery
To implement disaster recovery, you must select the following options when you create an Oracle Content Management instance:
- Advanced Hosting—You must enable the Advanced Hosting license option. Advanced hosting enables a dedicated autonomous transactional processing (ATP) database which is required to support Oracle Content Management's disaster recovery feature. Advanced hosting is an optional feature you can add when creating an Oracle Content Management instance with a Premium Edition or BYOL license. There is an additional billing charge for this option. Refer to your prepaid subscription contract or your Universal Credit contract for additional costs.
- Disaster Recovery—Under Advanced Options, you must enable the Disaster Recovery option. Disaster recovery is an optional feature you can add when creating an Oracle Content Management instance with a Premium Edition or BYOL license.
New instances only—Disaster recovery can be enabled only on new instances, not existing ones.
Data Center Support for Disaster Recovery
Support for disaster recovery is available in the following Oracle Content Management data center combinations:.
| Primary Region | Standby Region |
|---|---|
| Ashburn | Phoenix |
| Phoenix | Ashburn |
| San Jose | Phoenix |
| Toronto | Montreal |
| Montreal | Toronto |
| Tokyo | Osaka |
| Osaka | Tokyo |
| Mumbai | Hyderabad |
| Hyderabad | Mumbai |
| Frankfurt | Amsterdam |
| Amsterdam | Frankfurt |
| Seoul | Chuncheon |
| Chuncheon | Seoul |
| Dubai | Abu Dhabi |
| Abu Dhabi | Dubai |
| Sydney | Melbourne |
| Melbourne | Sydney |
| Sao Paulo | Vinhedo |
| Vinhedo | Sao Paulo |
| Santiago | Sao Paulo |
| Zurich | Stockholm |
| Stockholm | Zurich |
| Cardiff | London |
| London | Cardiff |
| Singapore | Hyderabad |
| Jeddah | Abu Dhabi |
| Johannesburg | Jerusalem |
| Jerusalem | Johannesburg |
| Milan | Marseille |
| Marseille | Milan |
| Paris (future) | Madrid (future) |
| Neom (future) | Jeddah |
| Queretaro (future) | Santiago |
| Chicago (future) | Ashburn |
| Madrid (future) | Paris (future) |
Beyond High Availability
While a high-availability service is designed to deliver a high degree of uptime and accessibility, many customers have additional needs that can be met with different architectures. These additional architectures, while still benefiting from the high availability provided out-of-the-box by Oracle Cloud Infrastructure and OKE, can be built to support development processes, even multi-region failover, or enhanced with private high-performance connections. To find the architecture that's right for your needs, you'll need to determine your organization's development process needs, your acceptable recovery time objectives (RTO), and your recovery point objectives (RPO).
Private Instance Using Oracle Cloud Infrastructure FastConnect
Some customers may also need additional performance or security that may not be available over the public internet. Oracle Cloud Infrastructure FastConnect can be used to provide a more performant, robust, and secure connection to your Oracle Content Management instance. This type of connection is often used by customers who want to ensure access is limited to internal networks or that end users have the best and most reliable connection possible.
If you want to create such an instance, you need to set up Oracle Cloud Infrastructure FastConnect and perform some additional prerequisite steps. FastConnect provides a dedicated private connection with higher bandwidth and a more reliable and consistent networking experience when compared to internet-based connections.
See Create a Private Instance Using FastConnect.
Development Process
This refers to the process your organization uses to build and deploy new functionality and content for Oracle Content Management. It can include multiple environments that new functionality and content must go through before being approved for high-level environments and production. A common setup would include environments for development, testing, staging, and, finally, production. You organization's needs may vary.
Customers who want to utilize multiple instances to support their development processes should provision their additional instances as described in this document but do not need to provision a web application firewall (WAF) in front of them as they will be accessed directly. After you develop content in one of your instances, you can use the command-line interface (CLI) of the Oracle Content Management Toolkit to propagate that content from one Oracle Content Management instance to another.
When you create an additional instance that won't serve production traffic, you must mark it as non-primary so you don’t pay for duplicated assets. Primary instances are charged for the total number of assets in the instance. Non-primary instances are charged for a single block of assets per month (for example, 5,000 assets, and, if you have Video Plus, 250 Video Plus assets) regardless of the total number of assets being replicated. For more information, see Oracle PaaS and IaaS Universal Credits Service Descriptions.
To propagate changes, you can use Oracle Content Management Toolkit commands to create sites and manage their life cycles on development, test, and production instances. You can make changes to sites in a development environment and propagate those changes to test and production environments. You can also incorporate this set of command-line utilities into your scripting environments to manage your deployments. With the CLI utilities, you can roll out new items, such as assets and components, as well as updates of existing content.