Architecture of Key Value Store

Key Value Store on STACKIT offers a fully managed, self-service deployment with flexible sizing, high availability, and automated backups. Here’s how it’s implemented:

An instance is defined by its type, number of vCPUs, RAM, underlying storage and networking. You can learn more about them in Create and manage instances for Key Value Store.

Instance level

On the instance level you define the number of nodes your instance runs on. The type property defines whether an instance is a single instance or a replica set. A replica set consists of 3 nodes for production resilience and is implemented using high-availability replication. So, all three nodes are a full mirror of each other and act as Active-Active. 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 vCPUs, its RAM and the storage connected to it. STACKIT calls scaling on this level vertical scaling.

On STACKIT Key Value Store the number of vCPUs, the size of RAM and disk is determined by a plan. With Service Plans you have a reference over all available plans.

Your instance will have a downtime after changing any parameter except ACL and disk threshold.

Networking

Each instance has its own hostname and IPv4 address. Per default it only can be reached from defined STACKIT address ranges. With the ACL parameter, 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 creates a backup every 4 hours. Independently you also can schedule manual backups every time. All backups are stored for 14 days.

Monitoring and observability

Integration with STACKIT Observability for Key Value Store is currently in progress and not yet available for general use. The following describes the planned architecture once released.

Every ordered service can be monitored using an Observability service. To enable monitoring for your Key Value Store instance, you must provide your Observability instance ID (monitoring_instance_id) and set the enable_monitoring parameter to true during provisioning or through an update.

Ensure you are using a supported plan: Your STACKIT Observability instance must have a plan with sufficient capacity to store metrics. For a detailed list of supported plans, check the Key Value Store FAQ and expand the question “Which STACKIT Observability plan is required for the Key Value Store integration?”

Once applied, the service broker uses the Observability API to register the instance. The wrapper creates technical credentials (visible as a Service Key with a monitoring_ prefix) that are used exclusively by Observability for monitoring. The connection URL is securely transferred to the Observability instance.

On the Observability side, Telegraf uses these credentials to securely access your database and pull the metrics. You are then able to see metrics prefixed with the corresponding service from your Thanos source directly in the Grafana dashboard of your Observability instance.

Management

• You manage instances with the STACKIT Portal, the STACKIT CLI, the STACKIT APIs, Terraform or Cloud Foundry:
  • Provisioning instances
  • Modifying instances
  • Monitoring performance metrics and logs
  • Restoring backups

Deployment separation

Key Value Store services created through Cloud Foundry and those created using STACKIT Portal/CLI are completely separated. Services created in one environment must be managed and deleted in the same environment - cross-environment management is not supported for technical reasons.

Services must always be managed in the environment they were created in. * Services

created in the STACKIT Portal/CLI must also be managed/deleted in the STACKIT Portal/CLI. In the STACKIT Portal, some (not all) services may be displayed that were created using Cloud Foundry (esp. the Flex databases). * Services created using Cloud Foundry must be managed/deleted using Cloud Foundry. Services displayed in Cloud Foundry as part of an organization prefixed by stackit_portal_prod_ have been created using the STACKIT Portal/CLI and must be managed from there, even if management options are displayed in Cloud Foundry. For technical reasons it is not possible to create a service in Cloud Foundry and delete it using the STACKIT Portal/CLI, or vice versa.