Gluster users - Aug 2015 - Need help making a decision choosing MS DFS or Gluster+SAMBA+CTDB

Hello,

what do you mean by "true" clustering ?
We can do a Windows Failover cluster (1 virtual ip, 1 virtual name), but
this mean using a shared storage like SAN.

Then it depends on your network topology. If you have multiple geographical
sites / datacenter, then DFS-R behave a lot better than Gluster in
replicated mode. Users won't notice any latency,
At the price that replication is async.


Cordialement,
Mathieu CHATEAU
http://www.lotp.fr

2015-08-10 7:26 GMT+02:00 Ira Cooper <ira at redhat.com>:
> Mathieu Chateau <mathieu.chateau at lotp.fr> writes:
>
> > I do have DFS-R in production, that replaced sometimes netapp ones.
> > But no similar workload as my current GFS.
> >
> > In active/active, the most common issue is file changed on both side
(no
> > global lock)
> > Will users access same content from linux & windows ?
>
> If you want to go active/active.  I'd recommend Samba + CTDB + Gluster.
>
> You want true clustering, and a system that can handle the locking etc.
>
> I'd layer normal DFS to do "namespace" control, and to help
with
> handling failover, or just use round robin DNS.
>
> Thanks,
>
> -Ira
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150810/fc17a8cf/attachment.html>

If you're looking at a Gluster+Samba setup of any description for
people extensively using Microsoft Office tools (either Windows or Mac
clients), I *strongly* suggested exhaustive testing of Microsoft Word
and Excel.

I've yet to find a way to make these work 100% on Gluster.  Strange
client-side locking behaviour with these tools often make documents
completely unusable when hosted off Gluster.   We host our large
production files (VFX industry) off Gluster, however have a separate
Windows Server VM purely for administration to host their legacy
Microsoft Office documents (we've since migrated largely to Google
Apps + Google Drive for that stuff, but the legacy requirement remains
for a handful of users).

-Dan

----------------
Dan Mons - R&D Sysadmin
Cutting Edge
http://cuttingedge.com.au


On 10 August 2015 at 15:42, Mathieu Chateau <mathieu.chateau at lotp.fr>
wrote:
> Hello,
>
> what do you mean by "true" clustering ?
> We can do a Windows Failover cluster (1 virtual ip, 1 virtual name), but
> this mean using a shared storage like SAN.
>
> Then it depends on your network topology. If you have multiple geographical
> sites / datacenter, then DFS-R behave a lot better than Gluster in
> replicated mode. Users won't notice any latency,
> At the price that replication is async.
>
>
> Cordialement,
> Mathieu CHATEAU
> http://www.lotp.fr
>
> 2015-08-10 7:26 GMT+02:00 Ira Cooper <ira at redhat.com>:
>>
>> Mathieu Chateau <mathieu.chateau at lotp.fr> writes:
>>
>> > I do have DFS-R in production, that replaced sometimes netapp
ones.
>> > But no similar workload as my current GFS.
>> >
>> > In active/active, the most common issue is file changed on both
side (no
>> > global lock)
>> > Will users access same content from linux & windows ?
>>
>> If you want to go active/active.  I'd recommend Samba + CTDB +
Gluster.
>>
>> You want true clustering, and a system that can handle the locking etc.
>>
>> I'd layer normal DFS to do "namespace" control, and to
help with
>> handling failover, or just use round robin DNS.
>>
>> Thanks,
>>
>> -Ira
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users

Mathieu Chateau <mathieu.chateau at lotp.fr> writes:
> Hello,
>
> what do you mean by "true" clustering ?
> We can do a Windows Failover cluster (1 virtual ip, 1 virtual name), but
> this mean using a shared storage like SAN.
>
> Then it depends on your network topology. If you have multiple geographical
> sites / datacenter, then DFS-R behave a lot better than Gluster in
> replicated mode. Users won't notice any latency,
> At the price that replication is async.
I assumed a Gluster context.  In order to cluster on gluster, you'll
need CTDB to keep the locking between the nodes consistent so you don't
run into the issues you mentioned with DFS-R from your mail.  (I don't
use DFS-R, and I haven't.)

If you have multi-site replication... you probably want it async, unless
you have really good links or low throughput requirements :).

Thanks,

-Ira