This piece was written by Sheryl Sage, Director of Partner Marketing at Redis Labs.
We live in a connected world and expect that our services are always-on and instantly delivered. The Red Hat OpenShift Container Platform helps you easily build and deploy applications in nearly any public, private or multi-cloud environment. But what about building geographically distributed applications? Operating geo-distributed applications that are both accurate and efficiently distributed is extremely challenging.
Fortunately, Redis Labs offers active-active with Conflict-Free Replicated Data Types (CRDTs) for distributed applications using Redis Enterprise on OpenShift. To provide some clarity on the topic, this post will cover why you need an active-active architecture, an overview of common consistency models, and how you can start building a Redis active-active environment on OpenShift.
What is a multi-region active-active architecture?
An active-active architecture is a multi-master configuration where every database replica is a master, and can handle write operations. With an active-active database, each location has its own version, but eventually, all of them will synchronize in real time. Generally speaking you want to have a active-active architecture to improve latency for end-users, handle regional outages, and utilize platform resources better with parallel application processing. Furthermore, this architecture addresses the business requirements to store data in the region where the users reside.
In contrast, in an active-passive architecture, there is only one master with read-replicas. With active-passive, a read request will use the replica in region and a write operation is executed on the master.
What type of applications benefit from an active-active architecture?
Modern applications such as e-commerce, mobile, gaming, IoT, fraud mitigation and social personalization need end-to-end response times of less than 100-milliseconds, while operating databases at sub-millisecond latency at scale. This is where an active-active architecture is extremely valuable. For example, a gaming or voting application uses a distributed leaderboard. With active-active, the votes from each region are stored locally, eventually the replicas are synchronized, and you have the same count everywhere. Another common use case is multi-region data ingest. When you are ingesting data in different regions, you can collect the data with multiple masters at each location and eventually all the data is merged. This architecture also works well for a distributed cache.
Requirements for a multi-region active-active architecture
There are a couple of challenges when you talk about an active-active database - latency and conflict resolution. There is always latency because of the network, which cannot be avoided. But in the case of conflict resolution, there are three different approaches:
- Strong consistency requires all database instances to receive messages in the same order. All databases must be updated all the time. In a distributed environment strong consistency degrades the availability and latency of application write operations.
-
Eventual consistency means that in the absence of updates, all data store replicas will converge towards identical copies of each other. With eventual consistency, changes made to one copy of the dataset will eventually converge to be logically equivalent and propagated to all replicas, allowing all access to the data to return the last updated value.
-
Strong eventual consistency strikes a compromise between strong and eventual consistency. It guarantees that whenever two replicas have received the same set of updates -- possibly in a different order -- their view of the shared state is identical, and any conflicting updates are merged automatically to a consistent state. This allows for a decentralized deployment architecture, allowing local execution at each database instance to proceed without waiting for communication with other instances. Updates across instances will happen asynchronously with no data loss. These guarantees are tailor-made for a distributed asynchronous world.
How Redis Enterprise implemented Active-Active with CRDTs?
Redis Enterprise has implemented strong eventual consistency in an active-active architecture with CRDTs. Redis Enterprise CRDTs are implemented using a global database that spans multiple clusters. There are several benefits to this architecture:
- Seamless conflict resolution for simple as well as complex data types.
-
Local latency on read and write operations, regardless of the number of geo-replicated regions and their distance from each other.
-
Even if the majority of the geo-replicated regions are down, the multi-master cluster will continue to handle read and write operations.
The most common CRDT compatible use cases are counters, activity trackers, session stores, distributed caching, inventory management. To understand how CRDTs work at a deeper level, you may enjoy reading more about Redis Enterprise CRDTs and their conflict resolution semantics.
How to use Redis Enterprise Active-Active on OpenShift
Redis Labs has partnered with Red Hat to integrate Redis Enterprise Active-Active on OpenShift, using a Redis Enterprise Operator and OpenShift Route. The enhanced Redis Enterprise Operator uses the routes mechanism to expose two inter-cluster services: the Redis Enterprise Cluster API service and the DB service. Both services are used during the creation and management of an active-active CRDT deployment.
Before you create an active-active deployment with Red Hat OpenShift Service Broker, you must create a cluster using the Redis Enterprise Cluster custom resource, with a Service Broker deployment. To configure the environment refer to the Redis Labs documentation.
Conclusion
In this post you have learned why you need an active-active architecture, common consistency models, capabilities offered by Redis Enterprise, and how you can get started building a Redis Active-Active environment on OpenShift. Red Hat OpenShift provides excellent capabilities to build and deploy your distributed applications. But you still need to make sure your modern applications run seamlessly across regions with an instant response. To address these challenges Redis Enterprise Active-Active with CRDTs will help you run your distributed applications as a stateful service on OpenShift.
Learn more
If you are interested in learning more, watch this recent OpenShift Commons Briefing, visit the OperatorHub.io today and take the Redis Enterprise Operator for a test run!
About the author
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit