Architecture

MongoDB Flex on STACKIT offers a fully managed, self-service deployment of MongoDB with flexible sizing, high availability, automated backups, and instance cloning. Here’s how it’s implemented:

An instance is defined by its type, computing power, memory, underlying storage and network. You can learn more about them in Create and manage instances for MongoDB Flex.

Instance level

On the instance level you define on how many nodes your instance runs. The type property defines whether an instance is a single instance, a replica set or a sharded cluster. A replica set consists of 3 nodes for production resilience. All three nodes are a full mirror of each other. A sharded cluster consists of 9 nodes and distributes the data from each mirror across 3 nodes. You can read about advantages and disadvantages of sharding in Plan your MongoDB Flex instance. STACKIT calls scaling on this level horizontal scaling.

You can not change the type after creating your instance.

Node level

On the node level you control how every node in the instance and its storage is sized. A node is characterized by its number of CPUs, its memory and the storage connected to it. STACKIT calls scaling on this level vertical scaling.

STACKIT calls the combination of CPU and memory flavor. Available flavor sizes are: Tiny, Small, Medium, Large, X-Large. There is a compute optimized, memory optimized and database optimized variant for each flavor size available. Depending on the instance type you may only can choose from a subset of flavors.

Independently from flavors you can configure the storage. STACKIT classifies the storage independently in its size and its performance class. The performance class defines the IOPS and the bandwith of the storage.

Your instance will have a downtime after changing any parameter except upgrading the storage size. You can not change the storage class/performance class for a single instance.

Network

Each instance has its own hostname and IPv4 address. Per default it only can be reached from predefined STACKIT address ranges. With the ACL paramenter, you can add custom IPv4 single addresses and ranges from which the instance can be reached.

Backup

You manage your backups on the instance level. The system backups the transaction logs and creates snapshots. With the help of transaction logs you can recover every point-in-time for the last 30 hours. With the snapshots you can recover to specific consistent snapshots of your instance in the past.

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are both 6 hours for storage under 1 TB. RTO increases slightly for each additional 10 GB above 1 TB.

With instance cloning you can replicate your existing MongoDB Flex instance to another instance within the same project for testing, staging, or data recovery workflows.

Monitoring and Observability

Each MongoDB Flex instance has its own Prometheus proxy. You access this proxy over a metrics-endpoint. If you use STACKIT’s Observability solution, you can scrape MongoDB Flex’s telemetry (Metrics, Logs and Traces) and thus import it into your Observability instance. Besides that, you can access the most important metrics in the Portal as well without running an Observability instance.

To learn more about implementing Observability, understanding and interpretating the metrics, consult Monitor MongoDB Flex.

Management

You can manage instances with the STACKIT Portal, the STACKIT CLI, the STACKIT APIs, Terraform or Cloud Foundry:

• Provisioning new instances
• Modifying instances
• Planning and executing updates
• Monitoring performance metrics and logs
• Adjusting backup schedules
• Restoring backups and cloning instances