Architecture

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’s 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 pre defined 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 creates a backup every 4 hours. Independently you also can schedule manual backups everytime. All backups are stored for 14 days.

Monitoring and Observability

Each Redis instance has its own Prometheus proxy. You access this proxy over a metrics-endpoint. If you use STACKIT’s Observability solution, you can scrape Redis’s telemetry (Metrics, Logs and Traces) and thus import it into 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.