Documentation - Redise Pack

A guide to Redise Pack installation, operation and administration

open all | close all

Multiple active proxy support

Redis Enterprise Pack (RP) provides high-performance data access through a proxy process that manages and optimizes the access to shards within the RP cluster. In RP 4.4 and above, each node contains a single proxy process. Each proxy can be active and take incoming traffic or passive and wait for failovers.

RP allows multiple databases to be created. Each database gets an endpoint (a unique URL and port on the FQDN). This endpoint receives all the traffic for all operations for that database. By default, RP binds this database endpoint to one of the proxies on a single node in the cluster. This proxy becomes an active proxy and receives all the operations for the given database. (note that if the node with the active proxy fails, a new proxy on another node takes over as part of the failover process automatically).

In most cases, a single proxy can handle a large number of operations without consuming additional resources. However, under high load, network bandwidth or a high rate of packets per second (PPS) on the single active proxy can become a bottleneck to how fast database operation can be performed. In such cases, having multiple active proxies, across multiple nodes, mapped to the same external database endpoint, can significantly improve throughput.

With the multiple active proxies capability, RP enables you to configure a database to have multiple internal proxies in order to improve performance, in some cases. It is important to note that, even though multiple active proxies can help improve the throughput of database operations, configuring multiple active proxies may cause additional latency in operations as the shards and proxies are spread across multiple nodes in the cluster.

Note: When the network on a single active proxy becomes the bottleneck, you might also look into enabling the multiple NIC support in RP. With nodes that have multiple physical NICs (Network Interface Cards), you can configure RP to separate internal and external traffic onto independent physical NICs. For more details, refer to Multi-IP & IPv6.

Having multiple proxies for a database can improve RP’s ability for fast failover in case of proxy and/or node failure. With multiple proxies for a database, there will be no need for a client to wait for the cluster to spin up another proxy and a DNS change in most cases, the client will just use the next IP in the list to connect to another proxy.

Proxy policies

A database can have one of the following four proxy policies:

Proxy Policy Description
Single There is only a single proxy that is bound to the database. This is the default database configuration and preferable in most use cases.
All Master Shards There are multiple proxies that are bound to the database, one on each node that hosts a database master shard. This mode fits most use cases that require multiple proxies.
All Nodes There are multiple proxies that are bound to the database, one on each node in the cluster, regardless of whether or not there is a shard from this database on the node. This mode should be used only in special cases.
Legacy The proxy binding is done with the behavior that existed in earlier versions. The binding is static and a slave listener is only created if replication is available.

Note: Manual intervention is also available via the rladmin bind add and remove commands.

Shard placement policy

A database can have one of two shard placement policies:

Placement Policy Description
Dense The cluster should attempt to place as many shards as possible on the smallest number of nodes as possible. This mode is useful when there is a single proxy in order to reduce the latency between the proxy and the database shards.
Sparse The cluster should attempt to spread the shards across as many nodes in the cluster as possible. This mode is useful when multiple proxies are bound to the database in order to spread the traffic as much as possible across cluster nodes.

Database configuration

A database can be configured with any combination of proxy policy and shard placement policy using rladmin bind and rladmin placement.

Warning: Any configuration update which causes existing proxies to be unbounded can cause existing client connections to get disconnected.

You can run rladmin to control and view the existing settings for proxy configuration.

The info command on cluster returns the existing proxy policy for sharded and non-sharded (single shard) databases.

$ rladmin info cluster
cluster configuration:
   repl_diskless: enabled
   default_non_sharded_proxy_policy: single
   default_sharded_proxy_policy: single
   default_shards_placement: dense
   default_shards_overbooking: disabled
   default_fork_evict_ram: enabled
   default_redis_version: 3.2
   redis_migrate_node_threshold: 0KB (0 bytes)
   redis_migrate_node_threshold_percent: 8 (%)
   redis_provision_node_threshold: 0KB (0 bytes)
   redis_provision_node_threshold_percent: 12 (%)
   max_simultaneous_backups: 4
   watchdog profile: local-network

You can configure the proxy policy using the bind command in rladmin. The following command is an example that changes the bind policy for a database called “db1” with an endpoint id “1:1” to “All Master Shards” proxy policy.

$ rladmin bind db db1 endpoint 1:1 policy all-master-shards

Note: you can find the endpoint id for the endpoint argument by running status command for rladmin. Look for the endpoint id information under the ENDPOINT section of the output.

Critical Note for 4.4 and above

multi-proxy policies need to be manually reapplied after topology changes like node restarts, failovers and migrations. To reset the policy, users can run:

$ rladmin bind db <db_name> endpoint <endpoint id> policy <all-master-shards||all-nodes>

This is not required with single or legacy policies.

Other implications

During the regular operation of the cluster different actions might take place, such as automatic migration or automatic failover, which change what proxy needs to be bound to what database. When such actions take place the cluster attempts, as much as possible, to automatically change proxy bindings to adhere to the defined policies. That said, the cluster attempts to prevent any existing client connections from being disconnected, and hence might not entirely enforce the policies. In such cases, you can enforce the policy using the appropriate rladmin command(s).