He analyzes the latency introduced by the switching components (assuming a zero latency in the direct-connected configuration) and concludes that the suggestion to use SSD just like a faster disk falls short, especially when you hide this fast storage in a large box. This is exactly the reason, why the hybrid storage pool of ZFS is a good idea, he writes. You can have both: centralized storage and the SSD near your server. You put the pool on your centralized storage and put the L2ARC on the local SSD. The L2ARC is unimportant for a disaster recovery scenario. You have only to warm the cache at the other side.
Moellenkamp writes that the location of the separated ZIL needs more thoughtful consideration. For a cluster failover it has to be available for all nodes of the cluster, he contends, so you integrate the outstanding changes written in the ZIL to the pool, but this depends on your application and your replication strategy. When you just do asynchronous replication between your sites, it can make sense to keep the SSD outside the general SAN and use a directly connected SAS-JBOD with some SSDs to share them between the cluster nodes.
By using such a mechanism we can still use the centrally managed rotating rust for data, but a locally provided SSD for speeding up things and reducing the load on our central infrastructure.
Moellenkamp suggests that the hybrid storage pool may be an answer to the latency question but even as he looks to that technology he looks to science for yet another possibility that will cut latency even further.
Customized news reports about Sun Microsystems. Just the news you need, none of what you don't. 50,000+ Members. 20,000+ Articles Published since 1998.