You 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.

iSCSI vs. Fibre Channel

July 22nd, 2010 | Posted by Sid Herron in Storage | Virtualization - (5 Comments)

We’ve had several posts here about storage virtualization (a.k.a. SANs) and the role that storage virtualization plays in both server and desktop virtualization. We made the decision some time ago to promote iSCSI SAN products rather than fibre channel, primarily because iSCSI uses technologies that most IT professionals are already familiar with – namely Gigabit Ethernet and TCP/IP – whereas fibre channel introduces a whole new fiber optic switching infrastructure into your computing environment, together with the new skills required to manage it.

But there are many who maintain that, although a fibre channel SAN infrastructure may be more expensive, and may require a different set of skills to manage, it offers superior performance.

So I was particularly interested to run across an article by Greg Shields on techtarget.com entitled “Fibre Channel vs. iSCSI SANs: Who Cares?” I would encourage you to click through and read this article in its entirety, although you may have to register and give up your email address to do so. But here are a couple of tidbits from the article to whet your appetite:

iSCSI vs. Fibre Channel: Who cares?
The answer: Statistics suggest that it doesn’t really matter…In most real-world scenarios, the performance difference between Fibre Channel and iSCSI SANs is negligible. Partisans will extol the raw performance statistics of their favorite SAN type, but it’s fantastically difficult to translate raw performance specifications into real-world user experience…

Performance alone may not be a decisive factor, but a SAN’s ease of administration can be. The management tools and techniques for Fibre Channel and iSCSI storage infrastructures are substantially different…the skills and experience required to run a Fibre Channel storage infrastructure are difficult to come by – often requiring additional consulting support for most implementations to start correctly. On the other hand, iSCSI SANs lean heavily on the existing TCP/IP protocol. If you have network engineers in your environment, they probably possess most of the necessary skills to successfully manage an iSCSI storage infrastructure.

So, while I would once again encourage you to read Greg’s post in its entirety (so you can assure yourself that I’m not quoting him out of context), I must say that I find his comments gratifying, because they tend to reinforce our own conclusions: unless you already have a fibre channel SAN infrastructure, there’s no compelling reason not to go with an iSCSI solution, and several reasons in favor of doing so, including cost and simplicity of management.

Anybody out there disagree? And, if so, can you tell me why, exactly, you feel that fibre channel is superior?

I am a big fan of Storage Area Network (“SAN”) technology. SAN technology offers high performance, highly flexible storage for Physical and Virtual Systems and is particularly valuable to empower advanced features for virtualization solutions such as VMWare, XENServer, and Hyper-V Virtual Hosts to name a few. 

The moral of this story is that you need to know that SANs have some very different management requirements compared to traditional Direct Attached Storage (“DAS”).  Many if not most IT Staff in small to medium size organizations are most familiar with throwing hard disks into physical servers in single or RAID configurations.  Now that they are are purchasing and deploying SAN technology we find that many problems occur if they do not fully understand how to implement and manage these new beasts. 

I would suggest that the difference between DAS and SAN technology is similar in spirit to the difference between a passenger car and a high performance race car.  Most passenger cars are designed to be slower and more forgiving than race cars, if you get into trouble it’s much easier for the average driver to recover.  Race cars will do many things that passenger cars won’t, but if you push them too far you will require very specific skills to recover or you will spin out of control.  SANs are in my opinion similar to this analogy, they will do many things that DAS won’t but if you don’t design and manage them properly you may quickly find yourself in spinning out of control. 

Here are a couple of things you need to know.

  1. Most popular SAN’s offer some impressive features such as “Thin Provisioning.”  Thin provisioning is one of those features that you will absolutely love, that is, until you don’t.  Thin Provisioning is a feature that allows you to provision gobs of storage – more, in fact, than you actually have – to Physical and Virtual Systems.  For example, you might have a SAN with 2 terabytes of physical storage, but then “provision” 10 individual 2 terabyte “volumes" and present them to your physical and virtual servers.  Your servers will see this as a combined total of 20 terabytes of storage. This is great but requires you to be very careful.  The reason is that you have offered 20 terabytes of “Virtual Storage” but of course you really only have 2TB of actual or “physical” storage.  So while your systems believe there is 20TB of available storage you have to insure that you do not attempt to put more than 2TB of physical data on this system or bad things will happen. 

    What bad things? Well in most cases once you fill up the physical space the volume will become unusable.  You must make sure you carefully monitor the system and pay close attention to it so that if you start reaching capacity, you’ll know in time to do something about it.  Our own SANs alert us when total available free space reaches 20%.  We have from time to time been between 70% and 90% utilization of our total capacity, and while everything is running just fine we know we have to watch this carefully.  If we hit 100% (intentionally or otherwise), the result could be catastrophic: the storage could immediately shut down and the recovery might not be quick. 

    This happened to a client last week. They started a backup, and when they realized that this was causing one of their thinly-provisioned SAN volumes to fill up to capacity, they immediately stopped the backup and deleted the data.  Unfortunately this caused the volume to fill to 100% and immediately shut down.  Fortunately this volume was mirrored to a second SAN and since there was a little more room on the mirror volume the workload actually stayed online until we could assist the client in recovering from this problem.  If the mirrored side had filled to 100% as well, the result would have been an immediate failure of a critical SQL server workload. 

    The client didn’t realize that copying all this backup data to a Windows Server VM would fill up the SAN volume, nor did they realize that simply deleting that data from the VM would not necessarily delete it from the SAN.  We were able to configure a new volume and replace the full half of the mirror with an empty volume, but only because their was some un-provisioned space available to use for this purpose.

  2. And that brings me to my second point – which is that deleting data from a Physical or Virtual server that is using SAN storage may not in many cases free the physical space on the SAN.  Again, DAS is like the passenger car, if you over-commit your storage you can simply press the brake (a.k.a. delete key) and recover immediately. With SAN storage it is common that once the space is committed you may have to perform specific tasks to free up this space.  This task might require special tools or utilities, or even require adding more physical disks.  In extreme cases it may require that you remove and recreate the over-committed SAN Volumes, and that is time consuming and painful.  In this scenario an ounce of prevention is worth a hundred pounds of cure. 

    We have been running our SAN over-provisioned for years with no ill affects or degradation in performance…but we know we are “on the bubble” and we carefully monitor and maintain this situation.

So please be aware that SAN technology is wonderful, but its important to learn some new skills to keep the systems performing their best.

A while back we had a couple of posts talking about application virtualization and server virtualization as part of our “What is Virtualization” series. We continue with our series now with the exploration of storage virtualization.

Storing data has been and will always be an issue for most companies, particularly given the rate at which storage requirements are increasing. Data storage is much more difficult than, say, storage of your own personal physical stuff.

To help me understand a bit better how storage virtualization works I go back to my condo reference. Assume that I live in a condominium complex with a bunch of other people. Since the units are a bit small, the complex offers storage units for the tenants’ use…a place to hold that extra bookcase, the leaf to your dining table, or your velvet Elvis painting. Unfortunately, each tenant gets only one storage unit. This means that if your unit is full it does you no good to know that your neighbor’s unit has nothing in it, because you have no access to it.

Now I like to travel, and when traveling I tend to pick up some knickknacks and tchotchkes from wherever I end up. I get back to my condo and find that my storage unit is already so full there is a note on my door from the fire marshal.  So what do I do? I do what most folks do:  No, I don’t get rid of anything (are you kidding?) – instead I rent a storage unit from the self-storage guys down the street. Now I have stuff in 2 different places. After a few years I have to get a third unit – but the unit down the street is full so I have to rent yet another storage unit across town. Clearly I have a problem: Aside from the obvious problem of being a pack rat, I have 3 storage units in 3 different locations. What happens if I need to find something that I’ve stored?  Will I even know where to look? (Clue: Probably not, because if I was sufficiently organized to keep a record of what stuff is in which storage unit, I probably wouldn’t be the kind of person to accumulate that much stuff in the first place!)

How does this apply to your business data? Well, one of the biggest problems we run into when trying to organize data in the traditional way, where each server has its own local storage, is that Murphy’s Law dictates that free storage space never exists in the server that needs it.  If my Exchange Server is running out of disk space, it does me no good to have 200 Gb free in my file server – just as it does me no good to know that your condo storage space is empty if mine is full.  In fact, it’s even worse. If my condo storage space is full, and I really trust you, I might make a deal with you to use some of your condo storage space – but there’s just no way to make that free space in your file server available to your Exchange Server.

“Storage virtualization” refers to the process of taking a bunch of physical disks and turning them into a central “storage pool,” portions of which can then be allocated back to your individual servers in such a way that they believe that the storage is local to them when, in fact, it is not. This separation of the drives from the individual servers is the key to storage virtualization and its benefits.

Since the drives are now managed as one large pool it is possible to perform tasks that previously were not possible, such as the migration of data between drives without down time, or being able to allocate storage on demand to the servers that need it. Storage virtualization allows you to perform these helpful tasks from a single management point.  We generally refer to this kind of storage virtualization system as a “Storage Area Network,” or “SAN.”

“Thin-provisioning” makes it even better.  Instead of trying to guess in advance how much storage to allocate to each server, and then potentially having to adjust things later, I can tell each server that it has way more storage than is actually available.  For example, I might tell ten different servers that they each had access to a terabyte of storage when, in fact, I only had a total of two or three terabytes of physical space in my storage pool.  I then let my SAN dynamically allocate the physical storage to the servers that need it – but only allocate as much physical storage as necessary to store the actual data.  The SAN will then alert me when I get close to running out of physical space so I can increase the size of my storage pool.

If my condo implemented storage virtualization, I imagine it would work like this. I would have one key and one drop off spot for all my storage items. Once I drop off my velvet Elvis I wouldn’t have to worry about where it would be stored and how much space it would take up. The storage management elves would find a place for it, and fetch it for me again when I requested it.  Since I have so much stuff and my neighbor hardly has any we may end up sharing a storage closet, but neither of us knows, or cares.  Heck, our stuff may be scattered across every storage closet in the complex.

After a bit of traveling, I may have enough stuff to fill up 2 storage closets all by myself. But I can still bring it to the general drop off location and not need to worry about which closet it goes in…because to me it looks like there is only one big closet. If management decides it would be easier to manage my stuff if it was all together in one room, they may elect to put all my stuff in a new, larger storage unit. All this would happen without me knowing or caring where my stuff is physically located.

Storage virtualization is not the newest technology out there – in fact, people were deploying SANs for all of the reasons listed above long before server virtualization became a big deal.  But storage virtualization enables many of the coolest server virtualization features, such as live motion – the ability to migrate a running VM from one virtualization host to another.  And we haven’t even begun to talk about the additional tools you may have for data protection, backup, and disaster recovery, such as the ability to leverage SAN replication to automatically send a copy of your critical data off-site. At the end of the day storage virtualization is great tool to save time, improve hardware utilization, increase agility, and most importantly save you money.

Your data needs to be organized and secure…just like my personal stuff. In fact, protecting your data is arguably more important, because the condo burns down I can probably get an insurance check for my physical stuff. But simply monetary damages may not be sufficient if you lose your data. (Can you even put a price tag on your data? Hint: How much is your business worth? Hint #2: What’s it worth to stay out of jail for violating laws on record retention?) Storage virtualization gives you another big toolbox full of tools to help you organize and secure it.

However it is still not an excuse to not throw a few things out every now and then.

Latest Blog Feeds
Testimonials
“Our business is all about process and margins; we rely on Moose Logic to install and manage network solutions that enable us to control both. Moose Logic created solutions that transformed our business relationships and processes.”
Ron Horowitz
Birchwood Park Homes
Read our Newsletter
Copyright © 2010 All rights reserved.
Wordpress Delicate template designed by NattyWP