I had a feeling it was something to do with that. It was confusing because I could use the move command to move between my three original hosts, just not the fourth. Then there was the device not found errors which added to the confusion.
I have the resource stickiness set because I have critical things running that I don't want to move around (such as a windows kvm) and I'd rather not see any downtime from the reboots. (It tries to actually migrate kvm's but it doesn't work, lxc vm's are stopped and started.) I moved them to specific servers because I thought I could do a better job at balancing the cluster on my own (based on knowing what my VM's were capable of). I'm not sure if my methods are a good idea or not, just sounded right to me at the time. On Tue, Nov 8, 2016 at 2:00 PM Ken Gaillot <kgail...@redhat.com> wrote: > On 11/08/2016 12:54 PM, Ryan Anstey wrote: > > I've been running a ceph cluster with pacemaker for a few months now. > > Everything has been working normally, but when I added a fourth node it > > won't work like the others, even though their OS is the same and the > > configs are all synced via salt. I also don't understand pacemaker that > > well since I followed a guide for it. If anyone could steer me in the > > right direction I would greatly appreciate it. Thank you! > > > > - My resources only start if the new node is the only active node. > > - Once started on new node, if they are moved back to one of the > > original nodes, it won't go back to the new one. > > - My resources work 100% if I start them manually (without pacemaker). > > - (In the logs/configs below, my resources are named "unifi", > > "rbd_unifi" being the main one that's not working.) > > The key is all the location constraints starting with "cli-" in your > configuration. Such constraints were added automatically by command-line > tools, rather than added by you explicitly. > > For example, Pacemaker has no concept of "moving" a resource. It places > all resources where they can best run, as specified by the > configuration. So, to move a resource, command-line tools add a location > constraint making the resource prefer a different node. > > The downside is that the preference doesn't automatically go away. The > resource will continue to prefer the other node until you explicitly > remove the constraint. > > Command-line tools that add such constraints generally provide some way > to clear them. If you clear all those constraints, resources will again > be placed on any node equally. > > Separately, you also have a default resource stickiness of 100. That > means that even after you remove the constraints, resources that are > already running will tend to stay where they are. But if you stop and > start a resource, or add a new resource, it could start on a different > node. > > <snip>
_______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org