This page provides the technical capabilities and limitations of the Managed Databases (also called Cloud Databases) M3 Aggregator 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.
M3 Aggregator versions
The Cloud Databases offer supports the following M3 Aggregator versions:
- M3 Aggregator 1.5
Please refer to our Cloud Databases - Lifecycle Policy guide for recommendations on version upgrades and end-of-life announcements of major versions.
Plans
Two plans are available:
- Business
- Enterprise
Here is an overview of the various plans' capabilities:
| Plan | Number of nodes by default | Additional nodes |
|---|---|---|
| Business | 3 | No |
| Enterprise | 6 | No |
Your choice of plan affects the number of nodes your cluster can run.
Nodes and replicas
- Business: the cluster is delivered with 3 nodes by default.
- Enterprise: the cluster is delivered with 6 nodes by default.
License type
Each cluster is provided with the M3 Aggregator Community (GPL) license.
Where applicable, the cost of the license is included in the service plans. It is not possible to bring your own licenses.
Hardware resources
Here are the node types you can choose from:
Business plans
| Name | Storage | vCores | Memory (GB) |
|---|---|---|---|
| db1-7 | N/A | 2 | 7 |
| db1-15 | N/A | 4 | 15 |
| db1-30 | N/A | 8 | 30 |
| db1-60 | N/A | 16 | 60 |
| db1-120 | N/A | 32 | 120 |
Enterprise plans
| Name | Storage | vCores | Memory (GB) |
|---|---|---|---|
| db1-15 | N/A | 4 | 15 |
| db1-30 | N/A | 8 | 30 |
| db1-60 | N/A | 16 | 60 |
| db1-120 | N/A | 32 | 120 |
Right now, all nodes in a given cluster must be of the same type and located in the same region.
Features
Network
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.
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 M3 Aggregator logs in OpenSearch. 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.
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.