This shows you the differences between two versions of the page.
hass:mqtt_cluster [2020/03/04 23:41] a created |
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. | 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; | + | The movement |
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, | 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, | ||
+ | Additionally, | ||
+ | |||
+ | < | ||
+ | iptables -t nat -A PREROUTING -d 192.168.29.2/ | ||
+ | </ | ||
+ | |||
+ | This allows clients connecting to the floating IP address to be redirected to the listening socket on the static address. | ||