On Tue, Nov 2, 2010 at 9:15 AM, Manuel Prinz <span dir="ltr"><<a href="mailto:manuel.prinz@uni-due.de">manuel.prinz@uni-due.de</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A short introduction: I have two RAID arrays which I'd like to join via<br>
LVM (as PVs) and replicate them via DRBD.<br></blockquote><div><br></div><div>2 RAID arrays *per host* you mean? How are your RAID arrays configured?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
First, I can think of two solutions to that:<br>
<br>
A. Create two DRBD resources on top of the arrays. The DRBD<br>
resource would be on each of /dev/sd[bc]. The two DRBD resources<br>
would be used as PV and the VG and LV(s) created on top of that.<br>
The FS would reside on the LV.<br>
B. Create one DRBD resouce on top of an LV. Both /dev/sd[bc] would<br>
be used as PV. A LV would be created, with a DRBD resource on<br>
top. The FS would reside on the DRBD resource.<br></blockquote><div><br></div><div>I recommend:</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I did not find any information about which setup two prefer. </blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Second, I have some questions regarding Active/Active setups. I<br>
understand the need of a FS that has support for distributed locking. If<br>
such a setup runs on top of LVM, would I need CLVM or is LVM with<br>
locking_type=3 sufficient?</blockquote><div><br></div><div>"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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Do I need to pass --clustered=y to vgcreate?<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">As there should be no problem with concurrent access, is STONITH<br>
required in such a setup? The LinuxTag white paper disables it but does<br>
not give an explanation. I guess it's because of the FS but am not sure.<br></blockquote><div><br></div><div>Fencing is required for cman and thus CLVM and GFS2. Not sure why you think there should be no concurrent access issues, there are.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There's also a lot of FUD on the net regarding GFS2 and OCFS2,<br>
especially in regards to PaceMaker integration. Is GFS2 really better<br>
integrated and more reliable?<br></blockquote><div><br></div><div>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. :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Last, I wonder what's the best solution to export the storage to other<br>
nodes. I have bad experiences with NFS, and iSCSI looks like the way to.<br>
With a DLM-aware FS it should be OK to access them from several nodes.<br>
Or is there a better way to export the storage to other nodes?<br></blockquote><div><br></div><div> Now you're in a different land. I thought you were talking about putting a clustered file-system on your DRBD nodes.</div>
<div><br></div><div>-JR</div></div>