When initially provisioned, all instances of Oracle Content and Experience 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 restored.
We encourage you to use our Upgrade Schedule option to control when your instance receives a new release of Oracle Content and Experience. In most cases your instance that serves production traffic and any instance that may serve traffic in the event of a failure 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 and Experience instance.
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 organizations’ development process needs, your acceptable recovery time objectives (RTO), and your recovery point objectives (RPO).
- Recovery Time Objective (RTO)—The RTO is the target time that is required to restore your application functionality after a disaster happens. The goal is to measure how quickly you must recover from a disaster. Typically, the more critical the applications, the lower the RTO.
- Recovery Point Objective (RPO)—The RPO is the acceptable timeframe of lost data that your applications can tolerate. RPO is about how much data your applications can afford to lose in a disaster scenario.
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 and Experience 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.
This refers to the process your organization uses to build and deploy new functionality and content for Oracle Content and Experience. 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 OCE Toolkit to propagate that content from one Oracle Content and Experience 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 OCE 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.