Architecture of Redis

Redis on STACKIT offers a fully managed, self-service deployment of Redis with flexible sizing, high availability, automated backups, and instance cloning. 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 Redis.

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 or a replica set. A replica set consists 3 nodes for production resilience and is implemented as a Galera Cluster. 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 Redis 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 Redis 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 via an Observability service. To enable monitoring for your Redis instance, you must provide your Observability instance ID (monitoring_instance_id) and set the enable_monitoring parameter to true during provisioning or via 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 Redis FAQ and expand the question “Which STACKIT Observability plan is required for the Redis 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 new instances
  • Modifying instances
  • Monitoring performance metrics and logs
  • Restoring backups

Deployment separation

RabbitMQ services created through Cloud Foundry and those created via 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.