Your are here: Home > Blog

Our friends at DataCore ran a press release yesterday positioning the new release (v8.1) of SANsymphony-V as a “storage hypervisor.” On the surface, that may just sound like some nice marketing spin, but the more I thought about it, the more sense it made – because it highlights one of the major differences between DataCore’s products and most other SAN products out there.

To understand what I mean, let’s think for a moment about what a “hypervisor” is in the server virtualization world. Whether you’re talking about VSphere, Hyper-V, or XenServer, you’re talking about software that provides an abstraction layer between hardware resources and operating system instances. An individual VM doesn’t know – or care – whether it’s running on an HP Server, a Dell, an IBM, or a “white box.” It doesn’t care whether it’s running on an Intel or an AMD processor. You can move a VM from one host to another without worrying about changes in the underlying hardware, bios, drivers, etc. (Not talking about “live motion” – that’s a little different.) The hypervisor presents the VM with a consistent execution platform that hides the underlying complexity of the hardware.

So, back to DataCore. Remember that SANsymphony-V is a software application that runs on top of Windows Server 2008 R2. In most cases, people buy a couple of servers that contain a bunch of local storage, install 2008 R2 on them, install SANsymphony-V on them, and turn that bunch of local storage into full-featured iSCSI SAN nodes. (We typically run them in pairs so that we can do synchronous mirroring of the data across the two nodes, such that if one node completely fails, the data is still accessible.) But that’s not all we can do.

Because it’s running on a 2008 R2 platform, it can aggregate and present any kind of storage the underlying Server OS can access at the block level. Got a fibre channel SAN that you want to throw into the mix? Great! Put fiber channel Host Bus Adapters (HBAs) in your DataCore nodes, present that storage to the servers that SANsymphony-V is running on, and now you can manage the fibre channel storage right along with the local storage in your DataCore nodes. Got some other iSCSI SAN that you’d like to leverage? No problem. Just make sure you’ve got a couple of extra NICs in the DataCore nodes (or install iSCSI HBAs if you want even better performance), present that iSCSI storage to the DataCore nodes, and you can manage it as well. You can even create a storage pool that crosses resource boundaries! And now, with the new auto-tiering functionality of SANsymphony-V v8.1, you can let DataCore automatically migrate the most frequently accessed data to the highest-performing storage subsystems.

Or how about this: You just bought a brand new storage system from Vendor A to replace the system from Vendor B that you’ve been using for the past few years. You’d really like to move Vendor B’s system to your disaster-recovery site, but Vendor A’s product doesn’t know how to replicate data to Vendor B’s product. If you front-end both vendors’ products with DataCore nodes, the DataCore nodes can handle the asynchronous replication to your DR site. Alternately, maybe you bought Vendor A’s system because it offered higher performance than Vendor B’s system. Instead of using Vendor B’s product for DR, you can present both systems to SANsymphony-V and leverage its auto-tiering feature to automatically insure that the data that needs the highest performance gets migrated to Vendor A’s platform.

So, on the back end, you can have disparate SAN products (iSCSI, fibre channel, or both) and local storage (including “JBOD” expansion shelves), and a mixture of SSD, SAS, and SATA drives. The SANsymphony-V software masks all of that complexity, and presents a consistent resource – in the form of iSCSI virtual volumes – to the systems that need to consume storage, e.g., physical or virtual servers.

That really is analogous to what a traditional hypervisor does in the server virtualization world. So it is not unreasonable at all to call SANsymphony-V a “storage hypervisor.” In fact, it’s pretty darned clever positioning, and I take my hat off to the person who crafted the campaign.

Back at the end of January, DataCore announced the availability of a new product called SANsymphony-V. This product replaces SANmelody in their product line, and is the first step in the eventual convergence of SANmelody and SANsymphony into a single product with a common user interface.

Note: In case you’re not familiar with DataCore, they make software that will turn an off-the-shelf Windows server into an iSCSI SAN node (FibreChannel is optional) with all the bells and whistles you would expect from a modern SAN product. You can read more about them on our DataCore page.

We’ve been playing with SANsymphony-V in our engineering lab, and our technical team is impressed with both the functionality and the new user interface – but that’s another post for another day. This post is focused on the packaging and pricing of SANsymphony-V, which in many cases can come in significantly below the old SANmelody pricing.

First, we need to recap the old SANmelody pricing model. SANmelody nodes were priced according to the maximum amount of raw capacity that node could manage. The full-featured HA/DR product could be licensed for 0.5 Tb, 1 Tb, 2 Tb, 3 Tb, 4 Tb, 8 Tb, 16 Tb, or 32 Tb. So, for example, if you wanted 4 Tb of mirrored storage (two 4 Tb nodes in an HA pair), you would purchase two 4 Tb licenses. At MSRP, including 1 year of software maintenance, this would have cost you a total of $17,496. But what if you had another 2 Tb of archival data that you wanted available, but didn’t necessarily need it mirrored between your two nodes? Then you would want 4 Tb in one node, and 6 Tb in the other node. However, since there was no 6 Tb license, you’d have to buy an 8 Tb license. Now your total cost is up to $21,246.

SANsymphony-V introduced the concept of separate node licenses and capacity licenses. The node license is based on the maximum amount of raw storage that can exist in the storage pool to which that node belongs. The increments are:

  • “VL1″ – Up to 5 Tb – includes 1 Tb of capacity per node (more on this in a moment)
  • “VL2″ – Up to 16 Tb – includes 2 Tb of capacity per node
  • “VL3″ – Up to 100 Tb – includes 8 Tb of capacity per node
  • “VL4″ – Up to 256 Tb – includes 40 Tb of capacity per node
  • “VL5″ – More than 256 Tb – includes 120 Tb of capacity per node

In my example above, with 4 Tb of mirrored storage and 2 Tb of non-mirrored storage, there is a total of 10 Tb of storage in the storage pool: (4 x 2) + 2 = 10. Therefore, each node needs a “VL2″ node license, since the total storage in the pool is more than 5 Tb but less than 16 Tb. We also need a total of 10 Tb of capacity licensing. We’ve already got 4 Tb, since 2 Tb of capacity were included with each node license. So we need to buy an additional six 1 Tb capacity licenses. At MSRP, this would cost a total of $14,850 – substantially less than the old SANmelody price.

The cool thing is, once we have our two VL2 nodes and our 10 Tb of total capacity licensing, DataCore doesn’t care how that capacity is allocated between the nodes. We can have 5 Tb of mirrored storage, we can have 4 Tb in one node and 6 Tb in the other, we can have 3 Tb in one node and 7 Tb in the other. We can divide it up any way we want to.

If we now want to add asynchronous replication to a third SAN node that’s off-site (e.g., in our DR site), that SAN node is considered a separate “pool,” so its licensing would be based on how much capacity we need at our DR site. If we only cared about replicating 4 Tb to our DR site, then the DR node would only need a VL1 node license and a total of 4 Tb of capacity licensing (i.e., a VL1 license + three additional 1 Tb capacity licenses, since 1 Tb of capacity is included with the VL1 license).

At this point, no new SANmelody licenses are being sold – although, if you need to, you can still upgrade an existing SANmelody license to handle more storage. If you’re an existing SANmelody customer with current software maintenance, rest assured that you will be entitled to upgrade to SANsymphony-V as a benefit of your software maintenance coverage. However, there will not be a mechanism that allows for an easy in-place upgrade until sometime in Q3. In the meantime, an upgrade from SANmelody to SANsymphony-V would entail a complete rebuild from the ground up. (Which we would be delighted to do for you if you just can’t wait for the new features.)

This is the second of two videos addressing virtual storage and its benefits. In Part 1, we addressed thin provisioning and virtual volumes. In this video, Steve talks about multipathing, and how it contributes to a high availability storage solution:

This is the first of two videos addressing virtual storage and its benefits. There are a number of storage solutions out there on the market but we have chosen to focus on DataCore of the purposes of this video. DataCore is an iSCSI SAN solution and you can learn more about their products here.

In part one, we address thin provisioning and virtual volumes. Watching this video will help you understand part 2 of “What is Storage Virtualization” where we talk about how multipathing relates to virtual volumes and contributes to a highly available SAN solution.

Recently Steve Parlee, Moose Logic’s Director of Engineering, sat down with Tim Warden, DataCore’s Western Region Director of Sales. Moose Logic has installed a number of DataCore solutions over the last few years and highly recommends their software to anyone looking into storage virtualization. We’ve also mentioned DataCore a number of times in our blog and newsletters. If your still not sure what DataCore does, this is a great introduction to their storage solutions. In the interview, Tim Warden explains the benefits of the DataCore software and what their solution can bring to your data center.