Differences

This shows you the differences between two versions of the page.

--- hass:mqtt_cluster [2020/03/04 23:41] – created a
+++ hass:mqtt_cluster [2020/03/04 23:45] (current) – a
@@ Line 36: / Line 36: @@
 Aside from provisioning the username and password on the client server, no other changes are required. However to ensure that all clients can equally access both servers, the password files should be kept in sync.
-===== Failover =====
+===== Floating IP Work-arounds =====
-Failover is only required in the event of the failure of one of the servers. This is further complicated in my set up by the use of a floating IP address; clients believe they have a persistent connection to the server. In the event of a CARP transition, the server taking over the IP will have no knowledge of these connections.
+The movement of a floating IP from one server to another can cause some inconsistencies with clients. The clients believe they have a persistent connection to the server, based on an established TCP connection. In the event of a CARP transition, the server taking over the IP will have no knowledge of these connections.
 The simplest solution I have found for this is to restart the MQTT server process on the machine taking over the floating IP. This is a little crude, but does ensure that all clients successfully re-establish their connections. It has the added benefit of forcing most clients to re-publish their discovery information, effectively updating Home Assistant of their status.
+Additionally, Mosquitto is unable to listen on the floating IP address unless the IP is present on the system at start-up. A quick work-around is to NAT incoming MQTT connections on this address to the server's static IP address.
+<code>
+iptables -t nat -A PREROUTING -d 192.168.29.2/32 -i eth0.29 -p tcp -m tcp --dport 1883 -j DNAT --to-destination 192.168.29.3:1883
+</code>
+This allows clients connecting to the floating IP address to be redirected to the listening socket on the static address.