2010/12/23 J. Ryan Earl <span dir="ltr"><<a href="mailto:oss@jryanearl.us">oss@jryanearl.us</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Thu, Dec 23, 2010 at 11:23 AM, Tim Mauerbach <span dir="ltr"><<a href="mailto:tim.mauerbach@googlemail.com" target="_blank">tim.mauerbach@googlemail.com</a>></span> wrote:<br></div>
</div><div class="gmail_quote"><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I am thinking about the structure of a new mailserver on top of raid1/lvm/xen.<br><br>Two different approaches come to my mind:<br><br>1. One big LV as DRBD
backing device for the whole guest (os + data).<br>2. One small LV without drbd for the base system + one big LV as DRBD
backing device only for data (maildirs+mariadb).<br><br>Is the maintenance overhead of 2 worth the performance gain?<br></blockquote><div><br></div></div></div><div>I'd definitely go with 1, and it has nothing to do with performance. If you put the whole VM on top of DRBD, and then make that a primary/primary (aka active/active) DRBD then you can live-migrate the VM between host and/or use Remus VM-mirroring for VM-HA. I don't see why anyone would ever go with 2 as leaving the OS unreplicated on the small LV exposes you to big potential downtime as you rebuild a new OS for the replicated-data in the event of a failure. Am I misinterpreting what you mean?</div>
<div><br></div><font color="#888888"><div>-JR</div></font></div>
</blockquote></div>Thanks for your input.<br>You´re right. It has nothing to do with performance, I meant efficiency:<br><br>The idea of 2 is to prevent live-replication of not that important non-user data (os + tmp|log files) that could be replicated via rsync at midnight. Thus I could use my DRBD capacity more efficiently and only for important data, though at the expense of maintainability.<br>
<br>Best Regards<br>Tim<br><br>