Re: Cluster with shared storage on low budget

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nikola Savic wrote:
Gordan Bobic wrote:
What is main reason for you not to use LVM on top of DRBD? Is it just
that you didn't require benefits it brings? Or, it makes more
problems by your opinion?
Traditionally, CLVM didn't provide any tangible benefits (no
snapshots), and I never found myself in a situation where dynamically
growing a volume with randomly assembled storage was required. If you
are JBOD-ing a bunch of cheap SATA disks, you might as well size the
storage correctly to begin with and not have to bother with LVM. I'm
assuming this is what you are doing since you are doing it on the
cheap (SAN-less). If you are using a SAN, the SAN will provide
functionality to grow the exported block device and you can just grow
the fs onto that, without needing LVM.

So apart from snapshots (non-clustered) or a setup like what was
suggested earlier, to have DRBD on top of local LVM to gain
local-consistency snapshot capability in a cluster (not sure I'd trust
that with my data, but it may be good for non-production
environments), I don't really see the advantage. Snapshots also only
give you crash-level consistency, which I never felt was good enough
for applications like databases. A replicated slave that you can shut
down is generally a more reliable solution for backups.

Thank you for detailed response!

I generally like idea of removing unneeded levels of technology.

In case DRBD+GFS2 is used for shared storage, do I need cluster suite?
Can GFS2 in this setup without cluster setup?

No, it cannot. GFS2's locking is dependant on the cman service being up and quorate, so yes, you still need the cluster suite being up and running, since that is what handles fencing. You could replace DRBD+GFS+RHCS with, say, DRBD+OCFS2+Heartbeat, but that wouldn't gain you anything either way - you'd still need fencing configured and working.

Note that DRBD should also have fencing (stonith) configured, and on a lower time-out than the rest of the cluster layer to eliminate possibility of split-braining.

Gordan

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster


[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux