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.

Sign up for GitHub

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 default_non_sharded_proxy_policy all-nodes to cluster load balancer setup #193

Merged
merged 5 commits into from
May 10, 2024
Merged

RS: Add default_non_sharded_proxy_policy all-nodes to cluster load balancer setup #193

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
96e80fe
Copy edits for style
rrelledge May 6, 2024
77f67eb
DOC-2495 Add default_non_sharded_proxy_policy all-nodes to cluster lo…
rrelledge May 6, 2024
50e2e82
Merge branch 'main' into DOC-2495
rrelledge May 8, 2024
737b414
More copy edits
rrelledge May 8, 2024
42e224b
More copy edits
rrelledge May 8, 2024
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
95 changes: 46 additions & 49 deletions content/operate/rs/networking/cluster-lba-setup.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,22 +1,22 @@
---
Title: Set up cluster behind a load balancer
Title: Set up a Redis Enterprise cluster behind a load balancer
alwaysopen: false
categories:
- docs
- operate
- rs
description: Set up a cluster using a load balancer instead of DNS to direct traffic to cluster nodes.
description: Set up a Redis Enterprise cluster using a load balancer instead of DNS to direct traffic to cluster nodes.
linkTitle: Cluster load balancer setup
weight: $weight
---
When you want to setup a Redis Enterprise cluster in an environment that doesn't allow DNS, you can use a load balancer (LB) to direct traffic to the cluster nodes.
To set up a Redis Enterprise cluster in an environment that doesn't allow DNS, you can use a load balancer (LB) to direct traffic to the cluster nodes.

## DNS role for databases

Normally, Redis Enterprise uses DNS to provide dynamic database endpoints.
A DNS name such as `redis-12345.clustername.domain` gives clients access to the database resource:

- If multiple proxies are in use, the DNS name resolves to multiple IP addresses so that clients can load balance.
- If multiple proxies are in use, the DNS name resolves to multiple IP addresses so clients can load balance.
- On failover or topology changes, the DNS name is automatically updated to reflect the live IP addresses.

When DNS cannot be used, clients can still connect to the endpoints with the IP addresses,
Expand All @@ -25,96 +25,93 @@ but the benefits of load balancing and automatic updates to IP addresses won't b
## Network architecture with load balancer

You can compensate for the lack of DNS resolution with load balancers that can expose services and provide service discovery.
A load balancer is configured in front of Redis Enterprise cluster, exposing several logical services:
A load balancer is configured in front of the Redis Enterprise cluster, exposing several logical services:

- Control plane services, such as the RS admin console to access cluster administration interface
- Data plane services, such as a database endpoint to connect from client applications
- Control plane services, such as the Cluster Manager UI
- Data plane services, such as database endpoints for client application connections

Depending on which Redis Enterprise services you want to access outside the cluster you may need to configure the load balancers separately.
One or more Virtual IPs (VIPs) are defined on the load balancer to expose Redis Enterprise services.
The architecture is shown in the following diagram with 3 nodes Redis Enterprise cluster with one database (DB1) configured on port 12000:
Depending on which Redis Enterprise services you want to access outside the cluster, you may need to configure the load balancers separately.
One or more virtual IPs (VIPs) are defined on the load balancer to expose Redis Enterprise services.
The architecture is shown in the following diagram with a 3-node Redis Enterprise cluster with one database (DB1) configured on port 12000:

{{< image filename="/images/rs/cluster-behind-load-balancer-top-down.png" alt="cluster-behind-load-balancer-top-down" >}}
## Setting up an RS cluster with load balancers

## Set up a cluster with load balancers

### Prerequisites

- [Install]({{< relref "/operate/rs/installing-upgrading" >}}) the latest version of RS on your clusters
- [Install]({{< relref "/operate/rs/installing-upgrading" >}}) the latest version of Redis Enterprise Software on your clusters
- Configure the cluster with the cluster name (FQDN) even though DNS is not in use.
Remember that the same cluster name is used to issue the licence keys.
Remember that the same cluster name is used to issue the license keys.
We recommend that you use a “.local” suffix in the FQDN.

### Configuring the load balancers
### Configure load balancers

- Make sure that the load balancer is performing TCP health checks on the cluster nodes.
- Expose the services that you require through a Virtual IP, for example:
- Web Management Portal (8443)
- Rest API service (Secured - 9443; Non-secured - 8080)
- Database ports (In the range of 10000-19999)
- Expose the services that you require through a virtual IP, for example:
- Cluster Manager UI on port 8443
- Rest API on port 9443 for secure HTTPS connections and port 8080 for HTTP
- Database ports 10000-19999

Other ports are shown in the list of [RS network ports]({{< relref "/operate/rs/networking/port-configurations.md" >}}).
Other ports are shown in the list of [Redis Enterprise network ports]({{< relref "/operate/rs/networking/port-configurations" >}}).

{{< note >}}
Sticky, secured connections are needed only for RS admin console service (provided on port 8443).
Sticky, secured connections are needed only for the Redis Enterprise Cluster Manager UI on port 8443.

- Certain LBAs provide specific logic to close idle connections. Either disable this feature or make sure the applications connecting to Redis use reconnection logic.
- Make sure the LB is fast enough to resolve connections between two clusters or applications that are connected to Redis databases through LB.
- Choose the standard LB which is commonly used in your environment so that you have easy access to in-house expertise for troubleshooting issues.
- Certain load balancers provide specific logic to close idle connections. Either turn off this feature or make sure the applications connecting to Redis use reconnection logic.
- Make sure the load balancer is fast enough to resolve connections between two clusters or applications that are connected to Redis databases through a load balancer.
- Choose the standard load balancer that is commonly used in your environment so that you have easy access to in-house expertise for troubleshooting issues.
{{< /note >}}

### RS cluster configuration
### Configure cluster

There are certain recommended settings within the cluster that guarantee a flawless connectivity experience for applications and admin users when they access the cluster through a Load Balancer.
For clusters behind load balancers, we recommend using the `all-nodes` [proxy policy]({{<relref "/operate/rs/databases/configure/proxy-policy">}}) and enabling `handle_redirects`.

{{< note >}}
- Run the `rladmin` commands directly on the cluster.
- The `rladmin` commands update the settings on all nodes in the cluster.
{{< /note >}}
To allow inbound connections to be terminated on the relevant node inside the cluster, run the following `rladmin` commands on the cluster:

The following settings are needed to allow inbound connections to be terminated on the relevant node inside the cluster:
```sh
# enable all-node proxy policy by default
rladmin tune cluster default_sharded_proxy_policy all-nodes
# Enable all-nodes proxy policy by default
rladmin tune cluster default_sharded_proxy_policy all-nodes default_non_sharded_proxy_policy all-nodes

# ensure we redirect where necessary when running behind an LBA
rladmin cluster config handle_redirects enabled
# Redirect where necessary when behind a load balancer
rladmin cluster config handle_redirects enabled
```

An additional setting can be done to allow (on average) closer termination of client connection to where the Redis shard is located. This is an optional setting.
Optionally configure sparse shard placement to allow closer termination of client connections to where the Redis shard is located:

```sh
# enable sparse placement by default
rladmin tune cluster default_shards_placement sparse
# Enable sparse placement by default
rladmin tune cluster default_shards_placement sparse
```

### RS database configuration
### Configure database

After the cluster settings are updated and the LBs are configured you can go to the RS admin console at https://load-balancer-virtual-ip:8443/ and [create a new database]({{< relref "/operate/rs/databases/create.md" >}}).
After you update the cluster settings and configure the load balancers, you can go to the Redis Enterprise Cluster Manager UI at `https://load-balancer-virtual-ip:8443/` and [create a new database]({{< relref "/operate/rs/databases/create.md" >}}).

If you are creating an Active-Active database, you will need to use the `crdb-cli` utility. See the [`crdb-cli` reference]({{< relref "/operate/rs/references/cli-utilities/crdb-cli" >}}) for more information about creating Active-Active databases from the command line.
To create an Active-Active database, use the `crdb-cli` utility. See the [`crdb-cli` reference]({{< relref "/operate/rs/references/cli-utilities/crdb-cli" >}}) for more information about creating Active-Active databases from the command line.

### Keep LB configuration updated when the cluster configuration changes
### Update load balancer configuration when cluster configuration changes

When your RS cluster is located behind a load balancer, you must update the LB when the cluster topology and IP addresses change.
Some common cases that require you to update the LB are:
When your Redis Enterprise cluster is behind a load balancer, you must update the load balancer when the cluster topology and IP addresses change.
Some common cases that require you to update the load balancer are:

- Adding new nodes to the Redis Enterprise cluster
- Removing nodes from the Redis Enterprise cluster
- Maintenance for Redis Enterprise cluster nodes
- IP address changes for Redis Enterprise cluster nodes

After these changes, make sure that the redis connections in your applications can connect to the Redis database,
After these changes, make sure that the Redis connections in your applications can connect to the Redis database,
especially if they are directly connected on IP addresses that have changed.

## Intercluster communication considerations

Redis Enterprise supports several topologies that allow inter cluster replication, these include [Active/Passive]({{< relref "/operate/rs/databases/import-export/replica-of/" >}}) and [Active/Active]({{< relref "/operate/rs/databases/active-active/" >}}) for deployment options.
When your Redis Enterprise software clusters are located behind load balancers, you must allow some network services to be open and defined in the load balancers to allow the replication to work.
Redis Enterprise supports several topologies that allow intercluster replication, such as [Replica Of]({{< relref "/operate/rs/databases/import-export/replica-of/" >}}) and [Active-Active]({{< relref "/operate/rs/databases/active-active/" >}}) deployment options.
When your Redis Enterprise software clusters are behind load balancers, you must allow some network services to be open and defined in the load balancers to allow the replication to work.

### Active-Passive
### Replica Of

For Active-Passive communication to work, you will need to expose database port(s) locally in each cluster (as defined above) but also allow these ports through firewalls that may be positioned between the clusters.
For Replica Of communication to work, you must expose database ports locally in each cluster and allow these ports through any firewalls between the clusters.

### Active-Active

For Active-Active communication to work, you need to expose several ports, including every database port and several control plane ports as defined in [Network port configurations]({{< relref "/operate/rs/networking/port-configurations.md" >}}). Pay attention to services that are marked with Connection Source as "Active-Active". These ports should be allowed through firewalls that may be positioned between the clusters.
For Active-Active communication to work, you must expose several ports, including every database port and several control plane ports as defined in [Network port configurations]({{< relref "/operate/rs/networking/port-configurations" >}}). Pay attention to services that include "Active-Active" in the connection source column, and allow these ports through any firewalls between the clusters.