On 13/01/11 10:57, Stan Hoeppner wrote:
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
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?
