2131880c71
Right now we do not add any resource stickiness to the VIPs. This has one consequence when we configure IHA: Namely, when a fenced compute node comes back (i.e. it recovers), pacemaker is free to move the VIPs around the controllers (see http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_prevent_resources_from_moving_after_recovery.html) to optimize the resource placement. We can observe the VIP moving with the following message: Apr 12 06:37:04 [979790] controller-1 pengine: notice: LogAction: * Move ip-10.0.0.110 ( controller-1 -> controller-0 ) This movement of the VIP is highly undesirable because in Instance HA the fence_compute agent needs to talk to keystone via the VIP, and if the VIP is on the move we might get the following errors: Apr 12 06:37:23 [979787] controller-1 stonith-ng: warning: log_action: fence_compute[259311] stderr: [ Starting new HTTP connection (1): 10.0.0.110 ] Apr 12 06:37:23 [979787] controller-1 stonith-ng: warning: log_action: fence_compute[259311] stderr: [ keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to http://10.0.0.110:5000 ] Apr 12 06:37:28 [979787] controller-1 stonith-ng: warning: log_action: fence_compute[261144] stderr: [ REQ: curl -g -i -X GET http://10.0.0.110:5000 -H "Accept: application/json" -H "User-Agent: python-keystoneclient" ] Apr 12 06:37:28 [979787] controller-1 stonith-ng: warning: log_action: fence_compute[261144] stderr: [ Starting new HTTP connection (1): 10.0.0.110 ] Apr 12 06:37:28 [979787] controller-1 stonith-ng: warning: log_action: fence_compute[261144] stderr: [ keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to http://10.0.0.110:5000 ] By setting the resource-stickiness of the VIPs to INFINITY we control how strongly they prefer to stay running where they are. Change-Id: I6862452d2250ac4c2c3e04840983510a3cd13536 Closes-Bug: #1763586 |
||
|---|---|---|
| .. | ||
| haproxy_with_vip.pp | ||
| resource_restart_flag.pp | ||