CTDB and the road ahead.

[Taylor, Jonn]

On 01/21/2013 04:46 PM, Andrew Bartlett wrote:
> On Mon, 2013-01-21 at 15:41 -0600, Taylor, Jonn wrote:
>> On 01/20/2013 08:18 PM, Martin Schwenke wrote:
>>> On Mon, 14 Jan 2013 17:27:52 -0600, "Christopher R. Hertel"
>>> <crh at ubiqx.mn.org> wrote:
>>>
>>>> On 01/14/2013 05:06 PM, Amitay Isaacs wrote:
>>>>> So
>>>>> CTDB branch 1.13 (CTDB version 1.44) is now completely defunct and should
>>>>> not be used. I would prefer to do regular releases of CTDB 2.x (time
>>>>> permitting). Currently 2.x releases are done from master which makes it
>>>>> easier to manage.
>>>> With my vendor hat on (and you know what color that is), I need to be able
>>>> to identify a release of CTDB to ship with products.  I can back-port fixes,
>>>> as needed, but I need a foundation from which to work.
>>> There isn't much (any?) feature development being done.  Most of
>>> the changes we're making are bug fixes, performance improvements or
>>> code cleanups to improve maintainability.
>> What are the plans for CTDB to be used on a AD DC cluster on the new
>> 4.0? I currently am running a 2 node cluster (samba 3.6+CTDB, DRDB
>> active/active on CentOS5) that I would like to upgrade to 4.0 with AD
>> but the notes say that this is not recommended.
> Correct, you don't mix CTDB replication with the AD replication used in
> the AD DC.
>
> If you are using CTDB, then your data is important enough to afford
> distinct servers for your AD DC.  The two replication schemes cannot be
> combined, they are at different layers.
Correct, I understand that. I am only interested in files server part to 
be on CTDB.

dc1 = samba 4 AD DC
dc2 = samba 4 AD DC
SHR01 = CTDB(DC1 and DC2 fileserver)

Is this possible? Otherwise I am looking at a XEN cluster/active 
failover with DRBD
>
> You can of course use CTDB with a Samba 4.0 file server, in the same way
> you can replicate a Samba 3.6 file server.
>
> The CTDB folks can fill you in on the status of CTDB with Samba 4.0, but
> I understand it is fully supported.
>
> Andrew Bartlett
>