Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Nov 2, 2010 at 9:15 AM, Manuel Prinz <manuel.prinz at uni-due.de>wrote: > A short introduction: I have two RAID arrays which I'd like to join via > LVM (as PVs) and replicate them via DRBD. > 2 RAID arrays *per host* you mean? How are your RAID arrays configured? > > First, I can think of two solutions to that: > > A. Create two DRBD resources on top of the arrays. The DRBD > resource would be on each of /dev/sd[bc]. The two DRBD resources > would be used as PV and the VG and LV(s) created on top of that. > The FS would reside on the LV. > B. Create one DRBD resouce on top of an LV. Both /dev/sd[bc] would > be used as PV. A LV would be created, with a DRBD resource on > top. The FS would reside on the DRBD resource. > I recommend: C. Create an software RAID0 'md' device between your two array controllers. Use the md device as your backing storage. Put LVM on top of the final DRBD device. > I did not find any information about which setup two prefer. B is particularly bad, there is no reason you should ever do this. In general, 'md' performance beats LVM performance when it comes to striping and aggregating block devices. A is going to be a bigger headache to manage than C and you may incur some extra CLVM overhead with the 2 shared PVs. > Second, I have some questions regarding Active/Active setups. I > understand the need of a FS that has support for distributed locking. If > such a setup runs on top of LVM, would I need CLVM or is LVM with > locking_type=3 sufficient? "CLVM" and "LVM" with locking_type=3 are pretty much the same thing. For locking_type=3 to be used, the clvmd service needs to be running but yea, changing the locking type to 3 is what turns LVM into CLVM. > Do I need to pass --clustered=y to vgcreate? > Or later modify the VG to be clustered. The VG must be clustered, which means all the RHCS cluster infrastructure must be running including clvmd. > As there should be no problem with concurrent access, is STONITH > required in such a setup? The LinuxTag white paper disables it but does > not give an explanation. I guess it's because of the FS but am not sure. > Fencing is required for cman and thus CLVM and GFS2. Not sure why you think there should be no concurrent access issues, there are. > There's also a lot of FUD on the net regarding GFS2 and OCFS2, > especially in regards to PaceMaker integration. Is GFS2 really better > integrated and more reliable? > GFS2 is an enterprise ready, stable, proven, robust clustered filesystem with OK performance. I'd definitely say OCFS2 of 1.2.x and earlier did not qualify as that. There were/are outstanding bugs open for years. I haven't done any work with OCFS2-1.4.x which was released a few months ago. How about you go bleeding edge and let us all know if you're willing to do the leg work and/or take the risk. :-) > Last, I wonder what's the best solution to export the storage to other > nodes. I have bad experiences with NFS, and iSCSI looks like the way to. > With a DLM-aware FS it should be OK to access them from several nodes. > Or is there a better way to export the storage to other nodes? > Now you're in a different land. I thought you were talking about putting a clustered file-system on your DRBD nodes. -JR -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20101102/63034c3c/attachment.htm>