On 03/11/2011 16:53, Patrick Westenberg wrote:
Ed W schrieb:
I'm using NexentaStor (Solaris, ZFS) to export iSCSI-LUNs and I was thinking about a SSD based LUN for the indexes. As I'm using multiple servers this LUN will use OCFS2.
Given that the SAN always has the network latency behind it, might you be better to look at putting the SSDs in the frontend machines? Obviously this then needs some way to make users "sticky" to one machine (or some few machines) where the indexes are stored?
Storing the indexes on several machines? In this case I have to synchronize them.
See the "sticky" in my reply. You use one of several techniques to ensure that users always end up on the server with the indexes on. That way much of the IO is served from that local machine and you only access the SAN for the (in theory much less frequent) access to the mail files themselves.
Clearly if the machine with the indexes on dies then the load balancer needs to pick a new machine and there will be delay/io/etc while the indexes are regenerated. Various techniques could mitigate this...
I don't have such a larger system - please ignore all my advice... The basis for the suggestion is that I understand file access (locking in particular) is "expensive" on OCFS2/GFS. Therefore I read here on this list that others have found performance issues accessing maildir over OCFS2? It's also not hard to find benchmarks that show OCFS2/GFS are "fast", but slower than accessing the same storage without using a cluster filesystem - this makes sense. Hence it seems like a trade between convenience of storing everything on a central store and "some" performance improvement from a more complex system...
I think if you search on benchmarks of DRBD vs OCFS2 and read here on the list about the "director" and "proxy" services you can see the point? I'm just trying to help you see the effects you might want to measure! (I don't have a system large enough to know much about this stuff from experience...)
Good luck!
Ed W