Jonathan Tripathy put forth on 1/13/2011 2:24 AM:

...

Ok so this is interesting. As long as I use Postfix native delivery, along with Dovecot director, NFS should work ok? One has nothing to do with the other. Director doesn't touch smtp (afaik), only imap. The reason for having Postfix use its native local(8) delivery agent for writing into the maildir, instead of Dovecot deliver, is to avoid Dovecot index locking/corruption issues with a back end NFS mail store. So if you want to do sorting you'll have to use something other than sieve, such as maildrop or procmail. These don't touch Dovecot's index files, while Deliver (LSA) does write to them during message delivery into the maildir. Yes, I thought it had something to do with that

...

For any meaningful use of virtualized clusters with Xen, ESX, etc, a prerequisite is shared storage. If you don't have it, get it. The hypervisor is what gives you fault tolerance. This requires shared storage.
If you do not intend to install shared storage, and intend to use things like drbd between guests to get your storage redundancy, then you really need to simply throw out your hypervisor, in this case Xen, and do direct bare metal host clustering with drbd, gfs2, NFS, etc. Why is this the case? Apart from the fact that Virtualisation becomes "more useful" with shared storage (which I agree with), is there anything wrong with doing DR between guests? We don't have shared storage set up yet for the location this email system is going. We will get one in time though. I argue that datacenter virtualization is useless without shared storage. This is easy to say for those of us who have done it both ways. You haven't yet. Your eyes will be opened after you do Xen or ESX atop a SAN. If you're going to do drbd replication between two guests on two physical Xen hosts then you may as well not use Xen at all. It's pointless. Where did I say I havn't done that yet? I have indeed worked with VM infrastructures using SAN storage, and yes, it's fantastic. Just this

On 13/01/11 10:57, Stan Hoeppner wrote: particular location doesn't have a SAN box installed. And we will have to agree to disagree as I personally do see the benefit of using VMs with local storage

What you need to do right now is build the justification case for installing the SAN storage as part of the initial build out and setup your virtual architecture around shared SAN storage. Don't waste your time on this other nonsense of replication from one guest to another, with an isolated storage pool attached to each physical Xen server. That's just nonsense. Do it right or don't do it at all.

Don't take my word for it. Hit Novell's website and VMWare's and pull up the recommended architecture and best practices docs. You don't need to tell me :) I already know how great it is One last thing. I thought I read something quite some time ago about Xen working on adding storage layer abstraction which would allow any Xen server to access directly connected storage on another Xen server, creating a sort of quasi shared SAN storage over ethernet without the cost of the FC SAN. Did anything ever come of that?

I haven't really been following how the 4.x branch is going as it wasn't stable enough for our needs. Random lockups would always occur. The 3.x branch is rock solid. There have been no crashes (yet!)

Would DRBD + GFS2 work better than NFS? While NFS is simple, I don't mind experimenting with DRBD and GFS2 is it means fewer problems?