tserong at suse
Apr 30, 2012, 6:37 PM
Post #12 of 14
On 05/01/2012 08:04 AM, Seth Galitzer wrote:
> This was a bit trickier to get worked out, but I have made some
> progress. It turns out just putting the metadata on a shared disk
> resource and symlinking wasn't quite enough. nmbd (the netbios
> management daemon that samba uses) complained that the symlink to its
> working directory wasn't a real directory. On top of that, you can
> specify the path for the nmbd working dir, but only at compile time, not
> at run time. To work around this, I added a bind mount for that dir
> (/var/run/samba for debian/ubuntu) and now samba will start. It will
> even fail over if I put the primary into standby. So there's the progress.
> However, a client still can't reconnect to the share once the node has
> failed over until I rerun "net ads join" on the secondary (new primary).
> I've been running the join command using the dns name for the floating
> IP, but maybe that's not good enough. I'll look more deeply into net
> tomorrow, and see if I can specify the IP, too.
Have you got "/var/lib/samba" on shared storage (or linked to, or
"private dir" in smb.conf set to some directory on shared storage)?
IIRC when you do "net ads join", various secrets and whatnot are saved
somewhere in that directory. If that's not persistent across failover,
it'd explain what you're seeing.
> The other new oddity is that after I've put the primary into standby and
> everything has failed over to the secondary, as soon as I bring the
> primary back online, the resources try to switch back, i.e. they don't
> stay on the secondary (new primary) as expected. Granted, if I setup
> STONITH, this shouldn't be an immediate problem, but it still will be
> when I go to bring the node back online. I believe this is only the
> case with the samba resource enabled, but I'll test this more tomorrow
> to make sure.
Do you have any constraints that make the resources prefer one node?
Also look at resource stickiness.
> I'm starting to wonder if samba is practical for failover or not. I
> don't really have much choice about using it. Because of my mixed
> environment, I need to be able to export nfs and samba shares from this
> server. Manual failover is better than what I have now, which is no
> redundancy at all. At least I'd be able to get my users back up more
> quickly on the cloned node. It just won't be as smooth as I'd like with
> automated failover. It still seems like it should be doable, I just
> haven't found the proper incantation just yet.
> Any further advice is welcome.
It is (or should be) ultimately possible. I have actually done it
before, just not for rather a while, which is why I'm being a bit vague
> On 04/26/2012 10:41 PM, Tim Serong wrote:
>> On 04/27/2012 11:37 AM, Andrew Beekhof wrote:
>>> On Thu, Apr 26, 2012 at 8:38 AM, Serge Dubrouski<sergeyfd [at] gmail> wrote:
>>>> On Wed, Apr 25, 2012 at 4:28 PM, Seth Galitzer<sgsax [at] ksu> wrote:
>>>>> On 04/25/2012 05:12 PM, Dimitri Maziuk wrote:
>>>>>> On 04/25/2012 03:53 PM, Seth Galitzer wrote:
>>>>>>> Can anybody point me to recent docs on how to go about setting this up?
>>>>>>> I've found several much older posts, but not much current with any
>>>>>>> kind of helpful detail.
>>>>>> If you're running active/passive DRBD, it's what the wiki page calls
>>>>>> "mounted on one node at a time". That one's simple: use drbdlinks to
>>>>>> keep everything incl. /etc/samba on the drbd filesystem and fire up smbd
>>>>>> and nmbd after drbdlinks -- pretty much like any other daemon backed by
>>>>>> drbd storage.
>>>>> I see how that will get all the locking and user data and that should be
>>>>> easy enough to configure. But I'm also doing ADS integration instead of
>>>>> winbind, and that also seems to be a problem as only one node can be
>>>>> joined to the AD at a time, even with a shared IP. Any suggestions for
>>>> Currently there is no official RA for smbd and nmbd daemons.
>>> Really? I thought tim had one. He was heavily into samba at one point.
>> I wrote the CTDB RA, but not a Samba one. There is a Samba RA which
>> came from RedHat/rgmanager, which is present in the resource-agents repo
>> (https://github.com/ClusterLabs/resource-agents), but I haven't tried it
>>>> You can try top
>>>> create one, and include joining domain there into a stat function, though I
>>>> don't need why you'd need it because AFAIK "join domain" is a one time
>>>> action unless you want to re-register your server in the domain.
>> Correct, you wouldn't want to an AD join on resource start. You only
>> need to do it once, and anyway, if you scripted it, that'd probably mean
>> having some domain admin password lying around in a config file or
>> script or something. Yuck.
>> You should be able to run Samba under Pacemaker using the LSB script.
>> Provided your smb.conf ensures all the samba state directories (private
>> dir, lock dir, etc.) is on shared storage (or use drbdlinks), you can
>> have Pacemaker start Samba, then on the node on which it's running, do
>> "net ads join". You want to end up with your floating IP address and
>> "netbios name" added to AD, *not* the physical IP or hostname of one of
>> the nodes. Your samba instance and floating IP then look like a single
>> host to the outside world, whichever physical node they're active on.
>> I realise now I scribbled a little about this at least once before:
Senior Clustering Engineer
tserong [at] suse
Linux-HA mailing list
Linux-HA [at] lists
See also: http://linux-ha.org/ReportingProblems