We recently introduced Redis Enterprise 6.4.2-30 at its core, which has an emphasis on security features such as including extended client certificate validation and pub/sub access management.
But it also has additional enhancements for our Kubernetes-based release. One that’s worth highlighting is how we manage Redis Enterprise inside Kubernetes clusters. We’re making that easier, and you can experiment with the features before they are publicly available. That is: We are proud to introduce the public preview of Active-Active database deployments with Redis Enterprise for Kubernetes.
Redis Enterprise has had the capability to extend a database beyond one single region or single data center for some time. We call it Active-Active Geo-Distribution, though it is also known as geo-replication.
What’s new here is that Redis Enterprise for Kubernetes can extend a database to include Active-Active configuration in a simplified fashion, one that fits in with the Kubernetes declarative mannerisms.
Related content: Redis Enterprise Operator for Kubernetes
As you surely are aware, deploying a Redis Enterprise cluster requires preparation and planning. The operator uses the Kubernetes API to automate the deployment and management of Redis clusters. The task gets more complicated when you introduce data replication that reaches beyond a single data center or, in the case of cloud infrastructure, beyond a single region or availability zone.
You currently use the Operator and the new Active-Active controller to provide a repeatable and predictable deployment model for your Redis Enterprise databases. The Operator constantly monitors your cluster’s health to provide automated high availability and scalability for your data layer.
But until today, deploying cluster replication across regions or data centers was a challenging endeavor, both because of the cluster itself and also because of the database and associated resources and manual processes.
What’s that mean, practically? Here are a few new things you can now do declaratively, in a few lines of YAML, in an Active-Active controller scenario:
Here’s a quick preview of how you would express this configuration in Kubernetes. In this example, we create an Active-Active database named example-aadb-1. It has copies on two clusters, and the database has three shards on each cluster.
apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseActiveActiveDatabase metadata: name: example-aadb-1 spec: participatingClusters: - name: rec1.ns1 - name: rec2.ns2 globalConfigurations: shardCount: 3
This feature is in private preview and has some configuration to turn it on for your environment. We encourage you to explore our Redis Enterprise for Kubernetes documentation and learn how to configure an Active-Active database. Contact us with any questions or feedback.
By continuing to use this site, you consent to our updated privacy agreement. You can change your cookie settings at any time but parts of our site will not function correctly without them.