> > RE your bug, what do you use for a mount point for the nfs
storage?
>
> In the log you attached to your bug, it looks like you're using localhost
as
> the nfs mount point. I use a dns name that resolves to the virtual IP
hosted
> by ctdb. So, you're only ever talking to one nfs server at a time, and
failover
> between the nfs hosts is handled by ctdb.
I also tried your setup, but hit other complications. I used localhost
in an old setup,
previously as I was under the assumption when accessing anything gluster
related,
the connection point only provides the volume info and you connect to any
server in the volume group.
As I understand it, with Gluster's nfs, the server you mount is the
only one you're accessing directly, which is why you need to use something
else to distribute the load, like round robin dns, with gluster's nfs.
>
> Anyway, like I said, my main testing rig is now using this configuration,
> help me try and break it. :)
rm -rf /
Jokes aside, are you able to reboot a server without losing the VM ?
My experience with ctdb (based on your blog) was even with the
"floating/virtual IP" it wasn't fast enough, or something in the gluster
layer delayed the failover. Either way, the VM goes into paused state and
can't be resumed.
I have rebooted my hosts without issue. If I want to reboot the host
that's serving the nfs storage, I've stopped ctdb first on that host,
to make it hand off the nfs -- I've done this out of caution, but I
should try just pulling the plug, too.
The main source of VM pausing I've seen is when you have two nodes, one
goes down, and the gluster quorum business goes into effect. With my
current 3 node, replica 3 setup, gluster stays happy wrt quorum.
I'll be sure to post about it if I have problems, but it's been working
well for me.
Jason