I’ve been playing around with many storage platforms in the last ten years but I admittedly never had first hand experience with Datacore before now.
Datacore is a private company hailing from sunny Ft. Lauderdale, FL. They sport worldwide presence and 13 years in the competitive storage industry with more than 6000 customers.
Their sole product is called SANsymphony-V and it’s a software-based storage virtualization solution which runs on physical or virtual Windows Server 2008 R2 machines. The product can virtualize whatever storage is connected to itself (both direct attached or connected via SAN) and then export it using iSCSI, FC and FCoE.
SANsymphony-V approach to HA is an interesting one, they’re maintaining synchronous copies between nodes to guarantee high availability, with this approach you can separate the nodes as far as 100 KMs apart and still access them as a single entity (a scenario that vaguely resemble NetApp’s metrocluster).
To guard against multiple DC failures (or as a DR tool) SANsymphony-V offers asynchronous remote replication over IP that can be compressed natively by the Datacore nodes or accelerated using in-path network acceleration appliances from the likes of Riverbed and BlueCoat (a common design decision these days I must say).
At the volume level (or Virtual Disk as they call them) data protection is guaranteed by snapshots with either full clones or copy-on-write PIT (a major bummer for myself as I am a fierce proponent of redirect-on-write) as well as Continuous Data Protection that time stamps all the activity performed on the said volume (the system maintain a configurable rollback window) and that can be used to rollback to any point in time within the aforementioned window.
The Tests
SANsymphony-V really struck my interest so I decided to give it a spin in our Juku lab.
During my tests I’ve put SANsymphony-V under stress in two different scenarios: physical (with async replication to virtual) and fully virtual (on vSphere 5 beta), I used both direct attached storage (local disks on Dell servers) and SAN attached storage (running on a trusty HDS AMS500 connected via FC to a Brocade fabric) as backend and VMware ESXi5 servers as clients.
The tests were performed with IOmeter inside virtual machines and performances were consistent across all the tests performed, the aggressive caching that Datacore provides (up to 1TB per node can be used for caching purposes) pushed IOps up to 4x in the tests performed (comparing SANsymphony-V performance against the native backend storage) a metric that is definitely interesting if your workload is cache friendly, especially because Datacore uses standard server RAM as caching platform that is usually cheaper than purpose-built cache modules for storage arrays.
The PROs
The product is solid, during my tests I had no issue whatsoever with the Datacore software: no install shenanigans, no strange quirks and no unexpected behaviors, everything went as smooth as it can get and performance were always consistent, even when Datacore nodes were virtualized under VMware.
The CONs
Even if I wholeheartedly welcome the synchronous HA model I definitely would have liked a way to simply virtualize my backend storage using traditional multi-pathed connections between the two Datacore nodes and a single LUN presented by the backend, giving the opportunity to use the Datacore features (like IP-based replication) without having to pay a 100% tax on my disk space.
Conclusions
Even if I’m not too fond of Windows as a storage platform (even if EMC proved me wrong) I must admit that if the storage layer is solid you can achieve great results, as it’s the case with Datacore and even if I’d really like to see the products bundled with a stripped-down version of Windows server (to maximize physical resource utilization) if you’re in the market for a good software-based storage virtualization solution, Datacore is definitely something to put on your shortlist.