Caching - Capabilities and Limitations

This page provides the technical capabilities and limitations of the Managed Databases (also called Cloud Databases) for Caching offer.

We continuously improve our offers. You can follow and submit ideas to add to our roadmap.

Capabilities and limitations

Supported regions

To view Cloud Databases availability, please see our regions and availability webpage.

Entire database instances have to be in the same region.

Caching versions

The Cloud Databases offer supports the following Redis® open source versions:

• Redis® open source 7.0

Please refer to the Cloud Databases - Lifecycle Policy for recommendations on version upgrades and end-of-life announcements of major versions. Additionally, you can follow the Redis® Release Cycle on their official page.

Caching clients

You can use any of the clients recommended by Redis® to access your instance.

Plans

Two plans are available:

• Essential
• Business

Here is an overview of the various plans' capabilities:

Your choice of plan affects the number of nodes your cluster can run, the SLA, and a few other features such as read replicas or backup retention.

Nodes and replicas

• Essential: the cluster can support at most one node.
• Business: the cluster is delivered with two nodes by default.
• Enterprise: the cluster is delivered with three nodes by default.

License type

Redis® open source software prior to version 7.4 is under the 3-Clause-BSD license, a liberal open-source license.

Redis® open source software starting from version 7.4, Redis Stack, and all Redis modules created by Redis Ltd. (e.g., RediSearch, RedisJSON, RedisGraph, RedisTimeSeries, and RedisBloom) are dual-licensed under the Redis Source Available License v2 (RSALv2) and SSPL. The RSALv2 license model prohibits OVHcloud, and any other service provider, from offering these modules to third parties as a service, meaning that this software and these modules are not available.

More information is available on the official Redis site.

Hardware resources

Here are the node types you can choose from:

Right now, all nodes of a given cluster should be of the same type and distributed in the same region.

Features

Network

Caching clusters are reachable through the port defined in the OVHcloud Control Panel.

Public as well as private networking (vRack) can be used for all the offers.

Ingress and Egress traffic are included in the service plans and unmetered.

The database service's IP address is subject to change periodically. Thus, it is advised not to rely on these IPs for any configuration, such as connection or egress policy. Instead, utilize the provided DNS record and implement CIDR-based egress policies for more robust and flexible network management.

Private network considerations

Here are some considerations to take into account when using a private network:

• Network ports are created in the private network of your choice. Thus, further operations on that network might be restricted - e.g. you won’t be able to delete the network if you didn’t stop the Cloud Databases services first.
• When connecting from an outside subnet, the OpenStack IP gateway must be enabled in the subnet used for the Database service. The customer is responsible for any other custom network setup.
• Subnet sizing should include considerations for service nodes, other co-located services within the same subnet, and an allocation of additional available IP addresses for maintenance purposes. Failure to adequately size subnets could result in operational challenges and the malfunctioning of services.

Authorized IPs

Once your service is up and running, you will be able to specify IP addresses (or CIDR blocks) to authorize incoming traffic. Until then, your service will be unreachable.

Maximum simultaneous connections

The number of simultaneous connections in Cloud Databases for Caching depends on the available total memory on the server. We allow 4 * megabytes_of_bytes_memory connections per RAM GB, but at least 10000 connections, even on the smallest servers.

So for example on a server with 7GB memory, you will get up to 7 * 4096 = 28672 simultaneous connections.

Advanced parameters

You can further customize your service by using advanced parameters. See the Advanced parameters references documentation for more information on the supported parameters.

Backups

Essential plan clusters are automatically backed up every 12 hours during their maintenance window. Backup retention is 1 day.

Business plan clusters are automatically backed up every 12 hours during their maintenance window. Backup retention is 3 days.

See the Automated Backups guide for more information.

Logs and metrics

Logs and metrics are available through the Control Panel and the API. Additionally, cross-service integration can be configured to leverage your logs and metrics in other Cloud Database services. You could then view your service logs in OpenSearch and metrics in Grafana (metrics have to be exported first in a time series compatible engine such as PostgreSQL or M3db). See the Cross Service Integration documentation for more information.

• Logs retention: 1000 lines of logs
• Metrics retention: 1 calendar month

Please note that if the database instance is deleted, logs and metrics are also automatically deleted.

Users and roles

The creation of users is allowed via the Control Panel and API.

For each user, you can specify:

• Username
• Keys (such as "cached:*")
• Categories (such as "@set")
• Commands (such as "+ping +info +echo +get +set")
• Channels (such as "*")

You can follow the official Redis® documentation about Commands.

Here is the list of unsupported commands:

• bgrewriteaof
• cluster
• command
• debug
• failover
• migrate
• role
• slaveof
• script
• eval
• evalsha
• acl
• bgsave
• config
• replicaof
• lastsave
• save
• shutdown
• monitor

Go further

For more information and tutorials, please see our other Cloud Databases support guides or explore the guides for other OVHcloud products and services.