Setting up CTDB on OCFS2 and VMs ...

[Michael Adam]

On 2014-12-06 at 20:59 +0100, steve wrote:
> 
> Now please let us talk about Setting up CTDB on OCFS2 and VMs ...
> 
> One way to set up an active:active 2 node cluster is to use ocfs2, drbd and
> ctdb. We have documented it and 3 independent domains are using it. It is
> available now. It has been tested in the field since September. That's what
> we offer. We thought we'd mention it. It may save you a lot of time getting
> your cluster into production. Take it or leave it. But please do not
> misrepresent it.

From reading your various posts here on the list,
which were pretty vague, one could get the impression that

  you are using drbd in parallel/addition to ocfs2
  to provide a split brain prevention mechanism
  as a substitute for the recovery lock file
  placed on ocfs2.

When asked, you never detailed how you accomplished
this (to use drbd for split brain), though.
(Neither did you elaborate in which way the recovery
lock file did not work in your setup.)

Now I read your blog post, and it sheds some light...
I am not an expert of ocfs2 or drbd, and you don't
really explain it but merely give the instructions
(and do some amount of bashing of available documentation..).
But here is what I understand from your post:

- You use drbd to replicate the block storage for ocfs
  between the two nodes.
- You format the drbd block device with ocfs2.
  This gives you a clustered ocfs2 active on both nodes.
- You configure ctdb on the two node cluster
  with mangement of public addresses and Samba,
  but *without* split brain protection.
- Samba is run in all-active clustered mode using ctdb
  for databases and failover and the ocfs2 for shares.

So the important bit is that in your case ctdb
is running unprotected from split brain.
The only reference to split brain is a notification
of user steve in case drbd detects a split brain.
If I get it right (there are no details about this
in the blog post), this means that until user steve
reacts to that notification the ctdb/samba cluster
runs happily in the split brain situation and
corrupts the users' data.

Note: notification of a split brain does
not imply protection of the damages it can do!
So the question is really: what apart from
notifying steve is your cluster doing when
a split brain occurs?


One more comment to your blog post:

According to your instructions, you call "net ads join"
before starting ctdb. This can not work. net ads join
needs ctdb running to operate, because it needs to
store the join information in the clustered secrets.tdb
handled by ctdb.

A procedure I'd recommend is this:

- configure ctdb without MANAGES_SAMBA and MANAGES_WINBIND
- start ctdb
- do net ads join
- configure ctdb to use MANAGES_SAMBA and MANAGES_WINBIND
- restart ctdb


Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141207/b4c260bd/attachment.pgp>