user4495: 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?

user4382: 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. 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!


4495: <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>
 4382: <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.stack.imgur.com/NvEx9.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/NvEx9.png" alt="Example of Load Balancer Diagram" /></a></p>
