At 07:25 PM 10/29/2003 +0000, you wrote:
>Very spendy but very nice. You can connect two head-ends to two separate
>disk arrays with fibre-channel, and then cross-connect both head-ends to the
>*opposite* disk array also with fibre-channel. If one head-end dies, the
>other one will take over its disks, and its IP address.
Just taking a look at it right now. I'll probably need to call them and get
some prices. Looks like a very good idea.
From what I understand about these, in theory, I would just need to get
one of these, set it up and I should be done, correct?
I'm sure there is more to it, but this could be a very simple setup.
>The problems are:
>(1) Round-trip time will be high, which will affect performance badly,
>especially for things like searching through mailbox contents
>(2) Any packet loss will give severe performance degradation, especially
>since NFS data tends to transfer in 4K chunks (lose any one fragment and the
>whole 4K will be retransmitted)
>(3) You don't gain any resilience against the link into the data centre
>failing (or catastrophic failure of the data centre itself)
>Because of point (3), I can't see any advantage in hosting a remote
>POP3/IMAP server with WAN NFS connection. You may as well just put another
>POP3/IMAP server in the same building, perhaps on a different power supply.
Something I will need to definitely consider, as my guess is they want to
be able to have our future branch offices connect to the corporate network
>If you just want to point to a second IMAP server and have users *manually*
>copy mails from one server to another, that would be fine.
Basically, have a second IMAP server setup, soley for the purposes of storage?
Did not think of that.
>As I say, better just to have a second mail server in the same location, so
>that the NFS traffic remains over a LAN (preferably switched 100Mbps)
Yes, network is switched. 100Mbps min, some parts are 1000Mbps.
>Hmm. I don't think Maildir-over-Samba is something you want to get into. It
>may work, but being a Microsoft protocol, its semantics may well be more
>broken even than Sun's NFS. Samba over WAN will have similar problems to NFS
I never thought this was a great idea either. Just wanted to clarify it.
>http://www.netapp.com/ and talk to your friendly sales engineer :-)
>(Don't think numbers less than $50K; double that for clustered solutions)
>However in summary: the Netapp has a wonderful filesystem called WAFL -
>"Write Anywhere File Layout". Whenever you write a file, the data is written
>to disk but does *not* overwrite the old file; the pointers are updated
>instead. Hence it's possible to maintain a snapshot of the filesystem at any
>previous time, until you want to free up the space, and it maintains a
>history of all changes between snapshot A and snapshot B.
>Hence you have a really efficient way of keeping two disk sets in sync:
>1. Take a snapshot (A)
>2. Copy the snapshot to the remote system. [Meanwhile, the local system is
> still 'live' and taking reads and writes]
>3. Take another snapshot (B)
>4. Send across the differences between snapshots (A) and (B) to the remote
>5. Repeat steps 3-4 every few minutes
>Snapshots give you a great way to do data recovery for those cases of
>imbeciles typing 'rm *' accidentally; just keep a few daily snapshots
>around, and they can restore the deleted file simply by cd'ing into
>.snapshots/daily.0 and cp'ing the file.
>The other great thing about WAFL is that you can expand a volume just by
>chucking in another disk, with zero down-time. Oh, and the speed is amazing;
>try creating 10,000 files over NFS onto a Netapp, and then try creating
>10,000 files on *local disk* on a Solaris box :-)
Sounds like you have used these before? They sound very enticing.
Let me ask this. I may be on a time line here, of about 2-3 weeks.
If anyone had this time line and needed to do this setup, what type of
setup would you do?
Basically, my thinking is, I need to setup something very quickly, yet
stable and secure.
Thanks for you help everyone. I cant thank you enough.