On 08/24/2015 12:20 PM, Digimer wrote: > Speaking from a gfs2 background, but assuming it's similar in concept to > ocfs2... > > Cluster locking comes at a performance cost. All locks need to be > coordinated between the nodes, and that will always be slower that local > locking only. They are also far less commonly used than options like nfs. > > Using a pair of nodes with a traditional file system exported by NFS and > made accessible by a floating (virtual) IP address gives you redundancy > without incurring the complexity and performance overhead of cluster > locking. Also, you won't need clvmd either. The trade-off through is > that if/when the primary fails, the nfs daemon will appear to restart to > the users and that may require a reconnection (not sure, I use nfs > sparingly). > > Generally speaking, I recommend always avoiding cluster FSes unless > they're really required. I say this as a person who uses gfs2 in every > cluster I build, but I do so carefully and in limited uses. In my case, > gfs2 backs ISOs and XML definition files for VMs, things that change > rarely so cluster locking overhead is all but a non-issue, and I have to > have DLM for clustered LVM anyway, so I've already incurred the > complexity costs so hey, why not.
Your point is well-taken. Thanks for the advice Digimer! -- Jorge _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org