Best architecture for 2 servers, 1 storage

As much as I want to keep Xsan alive, I think it is the wrong solution for you. You have two diametrically opposed objectives here: Email server = millions of small files and file sharing = random file size. Defining a single Xsan volume that will work effectively for both of these scenarios will be impossible. And the performance penalty that you will get will make you want to throw the whole solution out.

Also, keep in mind that you need the SanLink adaptors from Promise if you want to get a mini connected to FC storage. Ah, but here is the rub. SanLink is 4 GB FC. The vTrak is 8 GB FC. So you are not getting full throughput on a link level. Also, the vTrak has 8 total FC ports. The SanLink has two. And finally, the mini has only one Thunderbolt port.

However, if you are considering this as a method of utilizing a common storage array and splitting load across two head units, then I would suggest creating two volumes on the vTrak. One volume set to handle the small file writes of mail and a second to handle the variability of file services. Then assign each volume to a controller or LUN mask them to the host. Or, if you want an FC switch, then simply zone the connections.

Now, you will not be able to mount the file sharing volume on the mail server or the inverse unless you move cables, but this can keep you out of the overhead of Xsan.

Hope that made sense.

How many users? And what's the specific usage of the servers? Is it only IMAP (or POP) email, and only file sharing for Mac OS X?

In my opinion, there is a mutually exclusive situation that makes XSan totally non-viable without dedicated XSan Metadata controllers: The MDC must have an equal or newer version of XSan than clients, meaning the MDC needs to be updated first before any clients move to the next version of Mac OS X; whereas those same updates mean significant changes to the behavior of server services in a context that demands stability and reliability.

Even biennial releases of server OS translates into significant instability, and with annual releases, I just don't see how people running a business can keep up with this. And minor bug fixes and security updates end shortly after the next major version is released. I don't see this as best practices (and thus not viable) for a deployment that appears to have the storage and performance demands that require a fibre channel SAN.