Mathieu Chateau
2015-Aug-09 18:05 UTC
[Gluster-users] Need help making a decision choosing MS DFS or Gluster+SAMBA+CTDB
Hello, By DFS, you mean DFS-R. Because DFS can also be used only as domain space (DFS-N). This allow to publish share that hide real server name and so allow to move target somewhere else as needed. As I do quite a lot of DFS-R, here are the differences using DFS-R instead of Gluster: - Replication occurs between servers. Client only connect to one of ther server (can be based on AD topology), and is not aware that it's DFS-R. - Replication only transmit block changed in files, not the whole file - Replication is tracked using an internal Jet database - You have reporting tool to see differences & co between servers - This is active/active. If a client can/connect to a server, it will work there. - Lock on files are not replicated. If same file is changed on 2 servers at same time, replication will log that in event log and put file that lost in lost&found folder (the more recent win) - Not any issue browsing files/folder tree. Everything act like if it was just a file server. - You can use NTFS permission to fine grain access (Go further than unix style from my point of view) - Quota are working - You can prevent file based on extension - New version can deduplicate content (file server standard) - Writes are not synchronous. Once file is written, it's replicated in the background. Main difference is that you can't strip inside share content over multiple servers like if they were just one (the distributed feature of Gluster). Things are evolving with Windows Server 2016, but not yet RTM. You can also use shared storage in a more cluster way, with or without DFS replication (to survive a server down). We nearly always use both DFS-R and DFS-N, so we can migrate share to a different server without changes on client side. NAS & SAN vendors don't have choice. NetApp can't use Windows, else they can't customize it deeper enough, and they would have to pay license to MS. I always found that using a linux for CIFS is far away from feature you have on Windows side, and issue it generate (like robocopy diff. not working without /FFT flag). Backup of NetApp or EMC CIFS is just not working if doing that through share, you have to use NDMP, which is proprietary and generate others issue to backup (NDMP license, need to write directly itself on tape...). What will be your clients ? Windows box ? Linux ? Both ? If both, going to same shares? Cordialement, Mathieu CHATEAU http://www.lotp.fr 2015-08-09 17:56 GMT+02:00 David <david.peer at gmail.com>:> Hi, > > I need some help in making this call choosing between the two. > I have no experience with MS DFS or with Windows server OS as a file > server. > > There are some developers that pushing the DFS direction, mostly because > the applications that will use it and access will be from Microsoft using > CIFS. > > Now I know that most serious storage, NAS and SAN vendors work with Linux > or Unix based because of performance and flexibility, and I'm afraid that > DFS will just won't carry the expected load. > > Does anyone has experience with it? > Can some tell what are the PROS and CONS of each that can help us to make > a call? > > Many thanks, > David > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150809/b965e22d/attachment.html>
David
2015-Aug-09 19:18 UTC
[Gluster-users] Need help making a decision choosing MS DFS or Gluster+SAMBA+CTDB
Hi, Thank you very much for detailed answer. Most of the clients are Windows based OS's, but Linux will come in the future. Now I know that Windows does a bad job with NFS, so this is one concern that I have, but I also worried about performance and stability. I used to work with NFS clustered environments, also with GPFS and CTDB exporting both NFS and CIFS servicing 100s of users and render farms with no issues. Are you aware of any performance challenges/limitations of DFS-R, I mean real world ones compared to Linux? I aware of MS official DFS docs. Wonder if there is a comparison of same HW, one runs Gluster replica (ontop of XFS/Ext4) compared to two nodes DFS-R. (checking concurrent CIFS session, IOps, network utilization while sync etc..) Thanks again, David On Sun, Aug 9, 2015 at 9:05 PM, Mathieu Chateau <mathieu.chateau at lotp.fr> wrote:> Hello, > By DFS, you mean DFS-R. > Because DFS can also be used only as domain space (DFS-N). This allow to > publish share that hide real server name and so allow to move target > somewhere else as needed. > > As I do quite a lot of DFS-R, here are the differences using DFS-R instead > of Gluster: > > - Replication occurs between servers. Client only connect to one of > ther server (can be based on AD topology), and is not aware that it's DFS-R. > - Replication only transmit block changed in files, not the whole file > - Replication is tracked using an internal Jet database > - You have reporting tool to see differences & co between servers > - This is active/active. If a client can/connect to a server, it will > work there. > - Lock on files are not replicated. If same file is changed on 2 > servers at same time, replication will log that in event log and put file > that lost in lost&found folder (the more recent win) > - Not any issue browsing files/folder tree. Everything act like if it > was just a file server. > - You can use NTFS permission to fine grain access (Go further than > unix style from my point of view) > - Quota are working > - You can prevent file based on extension > - New version can deduplicate content (file server standard) > - Writes are not synchronous. Once file is written, it's replicated in > the background. > > > Main difference is that you can't strip inside share content over multiple > servers like if they were just one (the distributed feature of Gluster). > Things are evolving with Windows Server 2016, but not yet RTM. > You can also use shared storage in a more cluster way, with or without DFS > replication (to survive a server down). > > We nearly always use both DFS-R and DFS-N, so we can migrate share to a > different server without changes on client side. > > NAS & SAN vendors don't have choice. NetApp can't use Windows, else they > can't customize it deeper enough, and they would have to pay license to MS. > I always found that using a linux for CIFS is far away from feature you > have on Windows side, and issue it generate (like robocopy diff. not > working without /FFT flag). > > Backup of NetApp or EMC CIFS is just not working if doing that through > share, you have to use NDMP, which is proprietary and generate others issue > to backup (NDMP license, need to write directly itself on tape...). > > What will be your clients ? Windows box ? Linux ? Both ? If both, going to > same shares? > > > > > > > Cordialement, > Mathieu CHATEAU > http://www.lotp.fr > > 2015-08-09 17:56 GMT+02:00 David <david.peer at gmail.com>: > >> Hi, >> >> I need some help in making this call choosing between the two. >> I have no experience with MS DFS or with Windows server OS as a file >> server. >> >> There are some developers that pushing the DFS direction, mostly because >> the applications that will use it and access will be from Microsoft using >> CIFS. >> >> Now I know that most serious storage, NAS and SAN vendors work with Linux >> or Unix based because of performance and flexibility, and I'm afraid that >> DFS will just won't carry the expected load. >> >> Does anyone has experience with it? >> Can some tell what are the PROS and CONS of each that can help us to make >> a call? >> >> Many thanks, >> David >> >> >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-users >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150809/04853e3a/attachment.html>