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
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?