<p><strong>Short Answer:</strong> No there is not any technical limitations from the protocol or topology updater preventing you from doing this.</p>
<p><strong>Considerations:</strong> Starting external and working in, we need to consider the DNS vs Public IP side of this. In my opinion a Public IP should be avoided because if it changes, you have to resubmit your stake-pool registration.</p>
<p>Excluding a public IP, we are left with DNS. There are 2 main ways you can setup the DNS: just an A Record or an <a href="https://support.dnsimple.com/articles/srv-record/" rel="nofollow noreferrer">SRV Record</a>. It is worth noting that the SRV record doesn't know if a network is down/a-server-is-down, so it will not replace your load balancer for those type of services.</p>
<p>Either decision, the next step is your load balancer(s). I haven't actually set one of up for this use case but my initial thought would be this is where you run the topology-updater script. As well as, you know, balance the load. For the topology updater, make your valency equal to the number of relays you have (<em>if using DNS, otherwise this won't work</em>). Doing this allows more than one connection per peer. This is important because you are using a load balancer which could <em>potentially</em> create a situation where there are no incoming peers to a relay. You will still want to run a topology pull script to set your relay nodes' topology.</p>
<p>I hope this helps!</p>
<p><a href="https://i.sstatic.net/NvEx9.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/NvEx9.png" alt="Example of Load Balancer Diagram" /></a></p>

CC BY-SA 4.0
2021-11-02T16:35:12.193Z
2021-11-02T16:35:12.193Z
Jacob - SNOWY Pool
<p>I'm thinking of adding multiple relay-node instances behind a load-balancer to avoid downtime during maintenance windows, updates, restarts, etc.</p>
<p>From the outside world (public network), this would be seen as a single relay (single IP address / single DNS record), but internally, each instance would be an independent node, performing its own sync procedure. There's a chance for these instances to be slightly out of sync between each other (eg: after a restart of one).</p>
<p>My question: is there any problem from the protocol perspective (Ouroboros, topology updater, etc) with having multiple round robin nodes answering as the same relay?</p>

CC BY-SA 4.0
2021-11-02T01:30:13.480Z
Do you have more details on how you plan on handling your topology inside the network?
Jacob - SNOWY Pool
CC BY-SA 4.0
2021-11-02T11:44:47.420Z
This would be a cloud setup. Each relay-node instance would be connected to two subnets (1 public, 1 private). A single BP node would be running in the private subnet. Relay instances would point their topology config to the BP node + other peer relays downloaded from api.clio.one (cron job). The BP node would have a static topology file pointing only to the relay instances through the private subnet.
santi
<ouroboros><spo><topology>
Highly-available relay node (round robin & Ouroboros)
# Highly-available relay node (round robin & Ouroboros)

(Asked by: username_0 on 2021-11-01)

I'm thinking of adding multiple relay-node instances behind a load-balancer to avoid downtime during maintenance windows, updates, restarts, etc.

From the outside world (public network), this would be seen as a single relay (single IP address / single DNS record), but internally, each instance would be an independent node, performing its own sync procedure. There's a chance for these instances to be slightly out of sync between each other (eg: after a restart of one).

My question: is there any problem from the protocol perspective (Ouroboros, topology updater, etc) with having multiple round robin nodes answering as the same relay?

**Tags:** ouroboros, spo, topology
> **Comments:**
> **username_1**: Do you have more details on how you plan on handling your topology inside the network?  
> **username_0**: This would be a cloud setup. Each relay-node instance would be connected to two subnets (1 public, 1 private). A single BP node would be running in the private subnet. Relay instances would point their topology config to the BP node + other peer relays downloaded from api.clio.one (cron job). The BP node would have a static topology file pointing only to the relay instances through the private subnet.  

---

## 1 answers

### Answer by username_1 on 2021-11-02. Score: 1 | Accepted answer

**Short Answer:** No there is not any technical limitations from the protocol or topology updater preventing you from doing this.

**Considerations:** Starting external and working in, we need to consider the DNS vs Public IP side of this. In my opinion a Public IP should be avoided because if it changes, you have to resubmit your stake-pool registration.

Excluding a public IP, we are left with DNS. There are 2 main ways you can setup the DNS: just an A Record or an [SRV Record](https://support.dnsimple.com/articles/srv-record/). It is worth noting that the SRV record doesn't know if a network is down/a-server-is-down, so it will not replace your load balancer for those type of services.

Either decision, the next step is your load balancer(s). I haven't actually set one of up for this use case but my initial thought would be this is where you run the topology-updater script. As well as, you know, balance the load. For the topology updater, make your valency equal to the number of relays you have (*if using DNS, otherwise this won't work*). Doing this allows more than one connection per peer. This is important because you are using a load balancer which could *potentially* create a situation where there are no incoming peers to a relay. You will still want to run a topology pull script to set your relay nodes' topology.

I hope this helps!

[![Example of Load Balancer Diagram](https://i.sstatic.net/NvEx9.png)](https://i.sstatic.net/NvEx9.png)


---

