Automatic Cluster Management

Stop Tracking Hashlots and Manually Load-Balancing Redis Clusters

Developers need to focus on developing applications, and system administrators are too busy to track the intricacies of a distributed caching architecture, like hashslots, shards, and replicas. To maximize ease of use, especially during membership changes and network outages, ScaleOut StateServer’s cluster architecture was designed to fully automate management.

Users just need to deploy one ScaleOut StateServer service process on each server (“node”) in a cluster; ScaleOut StateServer takes care of the rest. The service processes work together to manage all aspects of cluster operations, including hashslots. They automatically create a Redis database with all 16K Redis hashslots and distribute the hashslots across the cluster’s nodes to achieve optimal load-balancing. The service processes automatically migrate hashslots between nodes when servers are added or removed or after recovery from server failures. They also maintain replicas for all hashslots on different nodes to ensure that data is never lost if a server fails or suffers a network outage.

Redis clients can connect to any ScaleOut StateServer server in a cluster using the standard RESP protocol. Most popular Redis client libraries then internally obtain the mapping of hashslots to servers using either the CLUSTER SLOTS or CLUSTER NODES commands and then direct Redis access requests to the appropriate ScaleOut server.

The following diagram shows Redis clients connecting to a ScaleOut StateServer cluster:

Unlike when configuring open-source Redis clusters, you can start with one node and add more nodes as your throughput and availability demands grow. Most enterprise deployments will use at least two nodes to provide data replication and protect against server failures. Here’s an example of adding a node to a ScaleOut StateServer cluster:

You just add one service process per node, and ScaleOut StateServer takes care of the rest. There’s no need to create primary and replica shards and reconfigure existing shards, as would be needed in an open-source Redis cluster. Note how existing replica 2 has to be migrated to a different node to maintain a balanced workload when adding a node in a Redis cluster:

ScaleOut StateServer hosts both primary and replica hashslots within its service process and handles all aspects of load-balancing when there are changes to the cluster’s membership:

For example, the following diagram shows how ScaleOut StateServer automatically redistributes the hashslots across two servers when a second server is added to a single-server cluster:

For each hashslot, ScaleOut StateServer maintains at least one replica on a separate node. For example, in the above diagram showing a two-node cluster, both nodes have copies of each other’s hashslots to ensure full redundancy. When additional servers are added, ScaleOut StateServer automatically redistributes both the primary and replica hashslots to maintain both load-balance and redundancy.

ScaleOut StateServer uses a coherent cluster membership with built-in, adaptive heart-beating that adjusts to the speed of the network. When it detects a missing server due to a failure or network outage, it automatically “self-heals” by creating a new cluster membership, promoting and duplicating replicas as needed, and rebalancing the workload on the surviving servers. It also detects and recovers from network subnetting (sometimes called a “split brain” configuration).

Fully Consistent Data Storage

Rely on Fully Consistent Updates to Enterprise Data

Distributed caches keep replicas for all stored objects to maintain high availability. If a server goes down or gets disconnected from the network, one or more other servers have a copy of the data and can step in to serve client requests. To make this work reliably, the distributed cache needs to keep all replicas of each stored object consistent after an update. Otherwise, a failure could occur and cause the latest updates to be permanently lost.

Redis clusters use an eventual consistency algorithm for updating stored objects. This approach is relatively simple and it allows for the maximum possible throughput. However, it is susceptible to data loss because it does not guarantee that all replicas are consistently updated.

To avoid this problem and ensure reliable data storage, ScaleOut StateServer uses a patented quorum algorithm to implement fully consistent updates to stored objects using a sequential consistency algorithm.  (For applications that need to maximize throughput at the expense of data consistency, ScaleOut StateServer can optionally be configured for eventual consistency.) When a server receives a Redis command, it executes this command on a quorum containing the primary hashslot and its replicas (one or two in the current implementation) prior to returning to the client. Redis transactions are processed in the same manner.

To illustrate the importance of fully consistent updates, the following diagram shows a Redis command updating a primary and replica copy of a stored object using Redis’s eventual consistency algorithm:

If the primary server (or the network link to its replica server) fails while sending the update to its replica but after it replies to the client, the update will be lost, and the client will be unaware of the problem.

ScaleOut StateServer avoids this problem by awaiting completion of updates to a quorum (i.e., majority) of copies of the data prior to replying to the client. This ensures that updates survive the failure of any server, and the cluster reliably stores the data. The following diagram shows how this algorithm awaits a response from the replica prior to responding to the client when one replica is used:

ScaleOut’s patented quorum algorithm for updating replicas was designed to deliver the best combination of data consistency and throughput to meet the needs of enterprise applications. It ensures that updates to mission-critical data are always reliably stored while providing high throughput using quorum-based processing.

Automatic Sharding for High Performance and Lower TCO

Eliminate Shards to Boost Throughput and Lower TCO

Redis uses a single-threaded, event-loop software architecture to execute commands. While this approach eliminates locking, it constrains throughput to that provided by a single processing core. To overcome this limitation and enable the use of multiple cores per server, Redis lets system administrators deploy multiple “shards” (service processes) per node and distribute the hashslots across them. This approach can be complex to manage and can increase costs.

ScaleOut StateServer uses multi-threaded execution for Redis commands to automatically take advantage of all processing cores and eliminate the need for multiple primary shards on each server. As commands flow in to each service process for different hashslots, ScaleOut StateServer executes them independently and in parallel on all available processing cores. ScaleOut’s multi-threaded architecture delivers the maximum possible throughput combined with reliable data storage using a single, self-managed service process on each node.

The following diagram shows the difference between Redis’s event-loop design and ScaleOut’s multi-threaded design:

ScaleOut StateServer’s highly integrated design enables each service process to automatically perform all clustering functions while delivering multi-threaded speedup for Redis commands. Designed for enterprise users, it enables system administrators to minimize management costs and lower TCO.

*Redis is a registered trademark of Redis Ltd.