Skip to content

RS: Added missing networking docs back to 7.4 version #1333

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

Merged
merged 2 commits into from
Mar 28, 2025
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
3 changes: 1 addition & 2 deletions content/operate/rs/7.4/databases/configure/proxy-policy.md
Original file line number Diff line number Diff line change
@@ -138,8 +138,7 @@ 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" >}}).
independent physical NICs. For more details, refer to [Manage IP addresses]({{< relref "/operate/rs/networking/multi-ip-ipv6" >}}).
{{< /note >}}

Having multiple proxies for a database can improve RS's ability for fast
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
---
Title: AWS Route53 DNS management
alwaysopen: false
categories:
- docs
- operate
- rs
description: How to configure AWS Route 53 DNS
linkTitle: AWS Route 53 DNS
weight: $weight
url: '/operate/rs/7.4/networking/configuring-aws-route53-dns-redis-enterprise/'
---

Redis Enterprise Software uses DNS to achieve high availability and fail-over regardless of where it is installed.


## What is AWS Route 53?

Route 53 is a scalable DNS service by Amazon Web Service (AWS). It routes user traffic to AWS resources and external sites, offering DNS health checks, traffic management, and failover capabilities. It's integral for high-availability architectures and also provides domain registration services.

## Create a hosted zone

Creating a hosted zone in Amazon Route 53 is a foundational step in managing your domain's DNS settings.

A hosted zone functions as a container for the DNS records of a specific domain. To create one, you first need to:

1. Log into the AWS Management Console
2. Navigate to the Route 53 dashboard
3. Select "Create Hosted Zone"
4. Enter your domain name, and choose public hosted zone

The hosted zone provides you with a set of Name Server (NS) records, which you will need to update at your domain registrar. This process effectively delegates the DNS management of your domain to Route 53, allowing you to create, update, and manage DNS records for your domain within the AWS ecosystem.

{{< image filename="/images/rs/00-CreateHostedZone-en.png" >}}

Once created, it will appear in the list of **Hosted zones**

{{< image filename="/images/rs/03-HostedZoneSelection-en.png" >}}

## Create glue records

A **glue record** is a type of DNS record that helps prevent circular dependencies by providing the IP addresses of your nameservers. To create glue records in Route 53, you first need to set up a hosted zone for your domain. You will create a separate A record for each node in your Redis Enterprise cluster. The **Record name** will be a subdomain definition of the NS record you will define and the **value** should be set to the IP address of the node in your cluster.

{{< image filename="/images/rs/05-NS1Configuration-en.png" >}}

Once complete, it should look something like this

{{< image filename="/images/rs/06-NSList-en.png" >}}


## Create nameserver record

When you create a new hosted zone in Route 53 for your domain, a set of NS records is automatically generated. These records list the nameservers assigned by Route 53 to your domain.

You will need to create a new NS record which will point to the glue records created in the previous step.

{{<note>}}
It is important to make sure that the **Record Name** of the NS record equals the FQDN (Fully Qualified Domain Name) of your Redis Enterprise cluster. If not, DNS resolution will not function correctly.
{{</note>}}

{{< image filename="/images/rs/07-NSRecord-en.png" >}}


## Validate

Once all steps are completed, the configuration should look similar to this

{{< image filename="/images/rs/08-FinalConfig-en.png" >}}

You can test and validate your settings by using the ```dig``` command.

```sh
dig ns test.demo-rlec.redislabs.com

; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> ns test.demo-rlec.redislabs.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25061
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.demo-rlec.redislabs.com. IN NS

;; ANSWER SECTION:
test.demo-rlec.redislabs.com. 3409 IN NS node2.test.demo-rlec.redislabs.com.
test.demo-rlec.redislabs.com. 3409 IN NS node1.test.demo-rlec.redislabs.com.
test.demo-rlec.redislabs.com. 3409 IN NS node3.test.demo-rlec.redislabs.com.

;; Query time: 31 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Feb 14 16:49:13 CET 2017
;; MSG SIZE rcvd: 120
```

You can see that the name are given a prefix of `ns-`. This answer does not come
from *Route53* but from the cluster nameservers themselves.

2 changes: 1 addition & 1 deletion content/operate/rs/7.4/networking/mdns.md
Original file line number Diff line number Diff line change
@@ -47,7 +47,7 @@ To prepare a client or node for mDNS:
$ service avahi-daemon start
```

1. If you are using [mDNS with IPv6 addresses]({{< relref "/operate/rs/networking/multi-ip-ipv6.md" >}}),
1. If you are using [mDNS with IPv6 addresses]({{< relref "/operate/rs/networking/multi-ip-ipv6" >}}),
update the hosts line in `/etc/nsswitch.conf` to:

```yaml
175 changes: 175 additions & 0 deletions content/operate/rs/7.4/networking/multi-ip-ipv6.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,175 @@
---
Title: Manage IP addresses
alwaysopen: false
categories:
- docs
- operate
- rs
description: Information and requirements for using multiple IP addresses or IPv6 addresses with Redis Enterprise Software.
linkTitle: Manage IP addresses
weight: $weight
url: '/operate/rs/7.4/networking/multi-ip-ipv6/'
---

Redis Enterprise Software supports servers, instances, and VMs with
multiple IPv4 or IPv6 addresses.

## Traffic overview

Redis Enterprise Software traffic is divided into internal traffic and external traffic:

- "Internal traffic" refers to internal cluster communications, such as communications between the nodes for cluster management.

- "External traffic" refers to communications between clients and databases and connections to the Cluster Manager UI.

When only one IP address exists on a machine that serves as a Redis Enterprise node, it is used for both internal and external traffic.

## Multiple IP addresses

During node configuration on a machine with multiple IP addresses, you must assign one address for internal traffic and one or more other addresses for external traffic.

If the cluster uses IPv4 for internal traffic, all communication between cluster nodes uses IPv4 addresses. If the cluster uses IPv6 for internal traffic, all communication between cluster nodes uses IPv6 addresses.

To update IP address configuration after cluster setup, see [Change internal IP address](#change-internal-ip-address) or [Configure external IP addresses](#configure-external-ip-addresses).

## Enable IPv6 for internal traffic

IPv6 for internal communication is supported only for new clusters with Redis Enterprise Software version 7.4.2 or later.

If the server has only IPv6 interfaces, IPv6 is automatically used for internal and external traffic. Otherwise, internal traffic uses IPv4 by default.

To use IPv6 for internal traffic on a machine with both IPv4 and IPv6 interfaces, set `use_internal_ipv6` to `true` when you create a cluster using the [bootstrap REST API request]({{< relref "/operate/rs/references/rest-api/requests/bootstrap#post-bootstrap" >}}):

```sh
POST /v1/bootstrap/create_cluster
{
"action": "create_cluster",
"cluster": {
"name": "cluster.fqdn"
},
"credentials": {
"username": "admin_username",
"password": "admin_password"
},
"node": {
"identity": {
"addr": "2001:DB8::/32",
"external_addr": ["2001:0db8:85a3:0000:0000:8a2e:0370:7334"],
"use_internal_ipv6": true
},
},
...
}
```

When other IPv6 nodes join a cluster that has `use_internal_ipv6` enabled, they automatically use IPv6 for internal traffic. Do not manually set `use_internal_ipv6` when joining a node to an existing IPv6 cluster, or a `NodeBootstrapError` can occur if the values do not match.

If you try to add a node without an IPv6 interface to a cluster that has `use_internal_ipv6` enabled, a `NodeBootstrapError` occurs.

The host file `/etc/hosts` on each node in the cluster must include the following entry:

```sh
::1 localhost
```

## Change internal IP address

Before you change an internal IP address, consider the following:

- Verify the address is valid and bound to an active interface on the node. Failure to do so prevents the node from coming back online and rejoining the cluster.

- Joining a node that only has IPv4 network interfaces to a master node with IPv6 enabled causes a `NodeBootstrapError`.

- Joining a node that only has IPv6 network interfaces to a master node that does not have IPv6 enabled causes a `NodeBootstrapError`.

- You cannot change the internal address from IPv4 to IPv6 or IPv6 to IPv4 in a running cluster. You can only change the internal address within the same protocol as the cluster.

If you need to update the internal IP address in the OS, one option is to remove that node from the cluster, change the IP address, and then add the node back into the cluster.

Alternatively, you can use the following steps to update a node's internal IP address without removing it from the cluster:

1. Turn the node into a replica using [`rladmin`]({{< relref "/operate/rs/references/cli-utilities/rladmin/node/enslave" >}}):

```sh
rladmin node <ID> enslave demote_node
```

1. Deactivate the `rlec_supervisor` service on the node:

```sh
systemctl disable rlec_supervisor
```

1. Restart the node.

1. Follow the operating system vendor's instructions to change the node's IP address.

1. From a different cluster node, use [`rladmin node addr set`]({{< relref "/operate/rs/references/cli-utilities/rladmin/node/addr" >}}) to update the first node's IP address:

```sh
rladmin node <ID> addr set <IP address>
```

1. Enable the `rlec_supervisor` service on the node:

```sh
systemctl enable rlec_supervisor
```

1. Restart `rlec_supervisor` or restart the node.


```sh
systemctl start rlec_supervisor
```

1. Verify the node rejoined the cluster:

```sh
rladmin status nodes
```

Repeat this procedure for other cluster nodes to change their internal IP addresses.

## Configure external IP addresses

You can configure external addresses that are not bound to an active interface, but are otherwise mapped or configured to route traffic to the node (such as AWS Elastic IPs or a load balancer VIP).

You can use [rladmin node external_addr]({{< relref "/operate/rs/references/cli-utilities/rladmin/node/external-addr" >}}) to change a node's external IP addresses.

Add an external IP address:

```sh
rladmin node <ID> external_addr add <IP address>
```

Set one or more external IP addresses:

```sh
rladmin node <ID> external_addr set <IP address 1> <IP address N>
```


Remove an external IP address:

```sh
rladmin node <ID> external_addr remove <IP address>
```

{{< note >}}
While [joining a new node to a
cluster]({{< relref "/operate/rs/clusters/add-node.md" >}})
during the node bootstrap process,
when prompted to provide an IP of an existing node in the cluster,
if you use the node's IP, provide the node's internal IP address.
{{< /note >}}

## Known limitations

- Using IPv6 for internal traffic is supported only for new clusters running Redis Enterprise Software version 7.4.2 or later.

- Changing an existing cluster's internal traffic from IPv4 to IPv6 is not supported.

- All nodes must use the same protocol for internal traffic.

- If a Redis Enterprise node's host machine has both IPv4 and IPv6 addresses, internal communication within the node initially uses IPv4 until the bootstrap process finishes.
Original file line number Diff line number Diff line change
@@ -11,7 +11,7 @@ title: "Enable private and\_public database endpoints"
weight: $weight
url: '/operate/rs/7.4/networking/private-public-endpoints/'
---
Each node in Redis Enterprise can be configured with [private and external IP addresses]({{< relref "/operate/rs/networking/multi-ip-ipv6.md" >}}). By default, Redis Enterprise Software databases expose a single endpoint, e.g. cluster.com (FQDN), using the external IP addresses, making it available to the public network (e.g. the internet). Additionally, the cluster can be configured to expose a private FQDN, which utilizes the private IP addresses for access from the private network only (e.g. VPC or an internal network).
Each node in Redis Enterprise can be configured with [private and external IP addresses]({{< relref "/operate/rs/networking/multi-ip-ipv6" >}}). By default, Redis Enterprise Software databases expose a single endpoint, e.g. cluster.com (FQDN), using the external IP addresses, making it available to the public network (e.g. the internet). Additionally, the cluster can be configured to expose a private FQDN, which utilizes the private IP addresses for access from the private network only (e.g. VPC or an internal network).

When you create a cluster via the UI, you can configure it to expose private and public endpoints.
This is common for environments such as cloud platforms and enterprises.