Reply inline:<br><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 7:46 AM, Digimer <span dir="ltr"><<a href="mailto:linux@alteeve.com">linux@alteeve.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 01/06/2011 03:27 AM, Felix Frank wrote:<br>
>> In any case, be sure to have (at least) RAID 1 on each node backing the<br>
>> DRBD devices to help minimize downtime. Drives fail fairly frequently...<br>
>> software RAID 1 is an inexpensive route to much better uptime. :)<br>
><br>
> If the budget isn't severely restricted, I'd also throw in an actual<br>
> RAID controller, software RAID being an unnecessary pain.<br>
><br>
> Cheers,<br>
> Felix<br>
<br>
</div>If I may provide a counter-point arguing in favour of software RAID;<br>
<br>
With hardware RAID, you array and your data is bound to that controller.<br>
Should the controller fail at some point, you will find yourself<br>
scrambling trying to find a compatible controller, and you will be down<br>
until you do (shy of falling back to recovering from backup). </blockquote><div><br></div><div>Given that DRBD is mirroring the data to another host, this shouldn't matter.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I had this<br>
happen to me enough that I now won't use hardware RAID unless it's for<br>
performance (or similar) reasons the make software RAID unfeasible.<br></blockquote><div><br></div><div>A backed-write cache will offer one of the larger performance improvements for DRBD, especially with lots of transactions/FUA-style block I/O. If you're running a SQL database, you want backed write-cache on a RAID controller.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
With software RAID, you have a familiar set of tools (mdadm) that many<br>
people can help you with. More importantly though, you can move your<br>
array to almost any other machine and get it up and running again with<br>
relatively little effort, potentially dramatically reducing your mean<br>
time to recovery.<br></blockquote><div><br></div><div>Manually rebuilding MD devices is time consuming and error prone. You have to replicate the partition structure manually to the new drive, possibly expire the failed drive, and add in each partition manually for each MD device with separate mdadm invocations. Hardware RAID is operationally much better when you're working with a team of people. See amber light on drive, yank and replace. No OS level commands required, which if done incorrectly, could even corrupt the remaining data. If you're the only admin and it's sitting in your closet at home, that's one thing, if your're managing many of these things, perhaps in a team and they are distributed geographically across data centers thousands of miles away with remote hands and eyes, that's another.</div>
<div><br></div><div>If you're going to use software RAID, I suggest the first thing you do is simulate physical failure and recovery of disks, practice the process, script it out. Verify your block drivers don't crap out hot-plugging the drives, all that.</div>
<div><br></div><div>-JR</div></div>