About OCI Cache
OCI Cache is a managed service that enables you to build and manage Cache clusters, which are memory-based storage solutions for applications.
OCI Cache handles the management and operations of clusters, including operations such as security updates.
OCI Cache supports clusters configured with one to five nodes. One node in the cluster is always configured as the primary node, any other nodes configured as replicas. All nodes in the cluster are in the same region, however the service tries to distribute them across fault domains and availability domains (for multiple availability domain regions) as much as possible.
You can resize clusters, either by increasing or decreasing the node count or the amount of memory available per cluster node. To improve redundancy, you can increase a cluster's node count. If you need more memory for the cache, you can increase the memory per cluster. Bandwidth is allocated to the cluster as you adjust memory. If you need more memory to increase bandwidth, then increase the memory for the cluster.
For more information, see Resizing Nodes for a Cluster and Resizing Memory for a Cluster.
OCI Cache Engine Version
OCI Cache supports the open source Redis version 7.0.5.
Sharding isn't yet supported by OCI Cache.
Resource Identifiers
OCI Cache supports clusters and work requests as Oracle Cloud Infrastructure resources. Most types of resources have a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID). For information about the OCID format and other ways to identify resources, see Resource Identifiers.Availability
OCI Cache is available in all Oracle Cloud Infrastructure commercial regions. See About Regions and Availability Domains for the list of available regions for Oracle Cloud Infrastructure, along with associated locations, region identifiers, region keys, and availability domains.
Ways to Access OCI Cache
You can access OCI Cache using the Console (a browser-based interface), the CLI, or the REST API. Instructions for the Console, CLI, and API are included in topics throughout this guide.
To access the Console, you must use a supported browser. To go to the Console sign-in page, open the navigation menu at the top of this page and click Infrastructure Console. You're prompted to enter your cloud tenant, your username, and your password.
For a list of available SDKs, see SDKs and the CLI. For general information about using the APIs, see REST API documentation.
Limits
The limits for OCI Cache are as follows:
- 5 nodes per cluster
- 500 GB per node
- 20 nodes
- 1000 GB
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groups , compartments , and policies that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, and so on. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
- For details about writing OCI Cache policies, see OCI Cache IAM Policies.
- For details about writing policies for other services, see Policy Reference.
Monitoring and Alarms
You can monitor the health, capacity, and performance for clusters by using metrics , alarms , and notifications. For more information, see OCI Cache Metrics.
Cluster Patching
OCI Cache handles a cluster's management and maintenance operations for you, including applying scheduled patches and security updates for a cluster's nodes. When the service patches a cluster's node, a new node is created with the patched image. Data is then replicated to the new node in the background. After the new node is fully populated, the service swaps out the old node, replacing it with the new node. Your library should automatically reconnect after a node swap, and in the unlikely event of a delay, a 1 millisecond connection loss can sometimes occur.