Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RS: Add proxy policy use cases, advantages, and disadvantages #503

Merged
merged 6 commits into from
Dec 9, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
135 changes: 66 additions & 69 deletions content/operate/rs/databases/configure/proxy-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,77 +9,93 @@ description: null
linktitle: Proxy policy
weight: 40
---
Redis Enterprise Software (RS) provides high-performance data access
Redis Software provides high-performance data access
through a proxy process that manages and optimizes access to shards
within the RS cluster. Each node contains a single proxy process.
within the Redis Software cluster. Each node contains a single proxy process.
Each proxy can be active and take incoming traffic or it can be passive
and wait for failovers.

## Proxy policies

A database can have one of these proxy policies:
A database can have one of the following 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 primary shards | There are multiple proxies that are bound to the database, one on each node that hosts a database primary 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, such as [using a load balancer]({{< relref "/operate/rs/networking/cluster-lba-setup.md" >}}). |
| Proxy policy | Description | Recommended use cases | Advantages | Disadvantages |
|--------------|-------------|-----------------------|-----------|-----------------|
| Single | Only a single proxy is bound to the database. This is the default database configuration. | Most use cases without high traffic or load | Lower resource usage, fewer application-to-cluster connections | Higher latency, more network hops |
| All primary shards | Multiple proxies are bound to the database, one on each node that hosts a database primary shard. | Most use cases that require multiple endpoints, such as when using the [OSS Cluster API]({{<relref "/operate/rs/clusters/optimize/oss-cluster-api">}}) | Lower latency, fewer network hops, higher throughput | Higher resource usage, more application-to-proxy connections |
| All nodes | Multiple proxies 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. | When using [load balancers]({{<relref "/operate/rs/networking/cluster-lba-setup">}}) for environments without DNS | Higher throughput | Highest resource usage |

{{< note >}}
Manual intervention is also available via the rladmin bind add and
remove commands.
{{< /note >}}

## Database configuration
## View proxy policy

A database can be configured with a proxy policy using rladmin bind.
You can use the Cluster Manager UI, [`rladmin`]({{<relref "/operate/rs/references/cli-utilities/rladmin">}}), or the [REST API]({{<relref "/operate/rs/references/rest-api">}}) to view proxy configuration settings.

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.
The [`rladmin info cluster`]({{<relref "/operate/rs/references/cli-utilities/rladmin/info#info-cluster">}}) command returns the current proxy policy for sharded and non-sharded (single shard) databases.

```sh
$ 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
...
```

## Configure database proxy policy

You can use the [Cluster Manager UI](#cluster-manager-ui-method), the [REST API](#rest-api-method), or [`rladmin`](#command-line-method) to configure a database's proxy policy.

{{<warning>}}
Any configuration update that unbinds existing proxies can disconnect existing client connections.
{{</warning>}}

### Cluster Manager UI method

You can change a database's proxy policy when you [create]({{<relref "/operate/rs/databases/create">}}) or [edit]({{<relref "/operate/rs/databases/configure#edit-database-settings">}}) a database using the Cluster Manager UI:

1. While in edit mode on the database's configuration screen, expand the **Clustering** section.

1. Select a policy from the **Database proxy** list.

1. Click **Create** or **Save**.

### REST API method

You can specify a proxy policy when you [create a database]({{<relref "/operate/rs/references/rest-api/requests/bdbs#post-bdbs-v1">}}) using the REST API:

```sh
POST /v1/bdbs/<database-id>
{
"proxy_policy": "single | all-master-shards | all-nodes",
// Other database configuration parameters
}
```

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 named "db1" with an endpoint id "1:1" to "All
primary shards" proxy policy.
To change an existing database's proxy policy, you can use an [update database configuration]({{<relref "/operate/rs/references/rest-api/requests/bdbs#put-bdbs">}}) REST API request:

```sh
PUT /v1/bdbs/<database-id>
{ "proxy_policy": "single | all-master-shards | all-nodes" }
```

### Command-line method

You can configure a database's proxy policy using [`rladmin bind`]({{<relref "/operate/rs/references/cli-utilities/rladmin/bind">}}).

The following example changes the bind policy for a database named "db1" with an endpoint ID "1:1" to "All primary shards" proxy policy:

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

The next command performs the same task using the database id in place of the name. The id of this database is "1".
The next command performs the same task using the database ID instead of the name. The ID of this database is "1".

```sh
rladmin bind db db:1 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.
You can find the endpoint ID for the endpoint argument by running `rladmin status`. Look for the endpoint ID information under
the `ENDPOINT` section of the output.
{{< /note >}}

### Reapply policies after topology changes
Expand All @@ -105,44 +121,25 @@ disconnected, and hence might not entirely enforce the policies. In such
cases, you can enforce the policy using the appropriate rladmin
commands.

## About multiple active proxy support
## Multiple active proxies

RS 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, RS 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).
Each database you create in a Redis Software cluster has an endpoint, which consists of a unique URL and port on the FQDN. This endpoint receives all the traffic for all operations for that database. By default, Redis Software 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. 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
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
operations 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, RS 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
You can configure a database to have multiple internal proxies, which can improve performance in some cases.
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 RS. With
nodes that have multiple physical NICs (Network Interface Cards), you
can configure RS to separate internal and external traffic onto
independent physical NICs. For more details, refer to [Multi-IP &
IPv6]({{< relref "/operate/rs/networking/multi-ip-ipv6.md" >}}).
When the network on a single active proxy becomes the bottleneck, consider enabling multiple NIC support in Redis Software. With nodes that have multiple physical NICs (Network Interface Cards), you can configure Redis Software to separate internal and external traffic onto independent physical NICs. For more details, refer to [Multi-IP & IPv6]({{< relref "/operate/rs/networking/multi-ip-ipv6.md" >}}).
{{< /note >}}

Having multiple proxies for a database can improve RS's ability for fast
failover in case of proxy and/or node failure. With multiple proxies for
a database, there is no need for a client to wait for the cluster
to spin up another proxy and a DNS change in most cases, the client
just uses the next IP in the list to connect to another proxy.
Having multiple proxies for a database can improve Redis Software's ability for fast failover in case of proxy or node failure. With multiple proxies for a database, a client doesn't need to wait for the cluster to spin up another proxy and a DNS change in most cases. Instead, the client uses the next IP address in the list to connect to another proxy.
Loading