Beware the storage virtualization quick fix
Steinhardt's role is to stay ahead of the trends in storage, feeding the company's ideas out to EMC's customers and the customer's ideas back to the company's management. Sitting at this cross-roads gives Steinhardt a unique perspective on the storage market, so ZDNet UK caught up with him just a few days after he took up his new role.
One of the really hot areas of development in the storage world is virtualization. Steinhardt has some very clear ideas on the future and in particular what he sees as a key mistake many companies are making, going for a quick solution.
The lesson is to avoid the siren call of a low cost, easier-to-implement in-band virtualization solution, as out-of-band is trickier but the only way to go, he says.
Q: What major trends do you see developing storage?
A: There are three things that are hot: virtualization across the entire IT infrastructure; iSCSI; and business continuity--the concept of continuous data protection as an adjunct to back-up, recovery and disaster recovery.
For a whole heap of reasons, I think the value proposition of continuous data protection is just so overwhelming that it will become ultimately as common as backup itself.
iSCSI, as a standard, has been around for some time. Is it really coming to the forefront now, and if so, why?
When the standard was finalized, roughly about three years ago now, this finally gave all the vendors clear direction in terms of, "how can I build things so that all of our products will play together?"
There were some vendors who jumped in before the standard, stirring things up, and I think that led people to wonder what was happening and why was it taking so long to get a standard. But they wound up with products that couldn't work with the reality of the market. Some of the most vocal vendors ultimately wound up not even being competitors.
The other challenge was that to make it work, you needed all of the pieces of the chain. Some vendors who have one piece of the standard that was rock solid, and would believe that was all they needed. But if they were an HBA vendor and the network infrastructure wasn't there, or the management tools weren't there, then [they failed].... You needed it all.
It was one those scenarios where, if one of the links wasn't there, then none of them were there.
Now, in 2006, all of the pieces are there. You've got the interfaces from the network card sitting up there on the server, operating system support, physical network infrastructure down to the storage with management tools that can see this, replication software and so, for many customers, all of the pieces of the puzzle are now there.
So I see iSCSI as a complement to NAS and Fibre Channel (FC) technologies rather than something that replaces either. I think there is a bright future for all three.
If we look at information lifecycle management (ILM), I envisage people will deploy different storage architectures as they do different network architectures, differentiated by different levels of service. They will be based on performance, availability and application requirements.
I think you will see iSCSI deployed that way. With some people it will be their network attached storage, for example, but they find they need a higher level of performance and the next logical jump could be iSCSI. And you will see it come from the other direction. People who are currently using FC will see that iSCSI might meet their requirements, so they can reduce their costs. So they can scale down and scale out from what they do with FC. But I also see some organizations deploying all three. They will apply the appropriate cost for the appropriate service and cost level.
It should really be a case of starting now with NAS and saying "why not?" before they jump to a different technology.
What about users who want one architecture, not three, for the sake of simplicity?
Well, the economic arguments are so strong now. If you don't need FC, then the argument is compelling. You don't have to buy HBAs or fibre channel switches. If iSCSI meets the service level then will be less expensive and so it will be an appropriate choice.
But then what I am also seeing is bridging products. In January we announced Multi-path file system iSCSI (MPFSi) which we haven't really talked about but it gives you the best of both worlds in one product.
MPFS and iSCSI lets a user make a request in iSCSI and the request always comes through the NAS side. The delivery of the information back--depending on the size and nature of the object, big request versus small simple one--will be delivered back on the NAS side if it was small object and if it was a large one it can be delivered through iSCSI, through the same infrastructure. Why would I do it through iSCSI? Two to four times the performance, even over the same wires.
So this is ideal for applications where the request is small but the delivery very large. The user will say: "Wow, that came back fast."
Where is EMC on virtualization?
As a user, when virtualization is done right I should be able to choose whichever vendors and technologies are appropriate at each and every level and I should be able to keep my applications continuously live and available while being able to adapt to new technologies.
At the server level with VMware, we have the ability to abstract multiple operating systems--Linux, NetWare, etc--transparently onto a single hardware platform. We can provide transparent failover, transparent migration while they stay logically alive, even through multiple servers and the like. And then down at the storage level, we are able with Rainfinity, our NAS environment, to abstract multi-vendor NAS products that get presented as a single, global, universal file system. As well as having the ability to do dynamic load balancing, data movement and so on.
The aim is that I neither know, nor care what physical infrastructure I am using or what storage I am using.
How far away are we?
Hard to say. No one has been able to do that level of the network yet. At the storage level, that is working quite nicely. Server virtualization works quite nicely. But to abstract that level of the network there are multiple ways to approach that, which haven't fully washed themselves out yet.
But this is something that EMC is working on?
Today with a product like Invista, storage virtualization is really quite robust. I was speaking to a customer who just migrated 190TB of storage, non-disruptively from one storage environment to another while still presenting the live application to the users. These are things people couldn't dream of doing even a year-and-a-half ago.
The real winners in this are going to be the customers, because it gives the ability to say "whatever technology is best at any point in time and from whatever vendor is best at any point in time, I can deploy and I am no longer locked in".
But you are not the only company talking about virtualization. You own VMware, but isn't there still competition?
There are many ways to do virtualization. Our decision was that it was better to do it right than to do it fast. A lot of the other people have come quickly to market but they have strategically limited it going forward.
For example, one of the basic architectural considerations of doing storage network virtualization is whether you go in-band [where data and control information flow over the same path] or or out-of-band [where they travel over different infrastructure].
Now some people may attempt to dismiss that, but I think it is a hugely important issue with far-reaching implications that have to do with availability, integrity and flexibility.
We chose to go out-of-band because it enables us to use standard component and open technology from all of the major switch and director vendors as well as giving us the flexibility to choose openly. And, unlike the in-band approach we don't intrude on the performance of the I/Os as they flow through and we don't inject a fourth level of complexity into the physical infrastructure which in turn can inject another level of integrity and availability concerns.
They are very serious strategic concerns. The reason I think other people chose in-band solutions was because it was quick and easy, and quick and easy isn't always the right way, especially when you consider how important the physical infrastructure for information in an organization becomes. Things that help are more important than things that make an infrastructure inherently weaker than if you had never virtualised.
What is the performance overhead in virtualization?
In terms of out-of-band it is no more than the overhead in the switches. In the case of in-band it can be extremely significant.
If you are imaging an infrastructure, if I am in-band I insert myself between everything. I fool the switches into thinking they are talking to the servers, when [the servers] are talking to me and I fool them into thinking they are talking to the storage, when they are talking to me. As a result, you are never any faster than your weakest link.
So you have servers that are capable of pushing millions of I/Os per second, switches that are capable of pushing millions of I/Os per second, storage devices that are capable of pushing millions of I/Os per second, and not a single, in-band virtualization device today, to my knowledge, that is capable of pushing millions of I/Os per second.
Also, because I am a fourth tier in the infrastructure, if I ever have a code issue, there is no way for, say, the storage device and a server either [side of the virtual pool] to know about it.
If I flip bits, they are abstracted from each other and so I, as the virtual device, have injected an integrity issue.
With out-of-band, we stay completely out of the data path and let the data flow back and forth and instead have a device that hand-shakes and talks to the switches and directors using, incidentally, a fabric application interface standard.
So, contrary to popular belief, there is an emerging standard for how storage network virtualization gets done. Anyway, using that standard I will talk to the devices, but I will never, never, ever interfere with the data flow so it is physically impossible for me, as the virtualization device, to interfere with data flowing through the I/Os. I also cannot impact the integrity of those I/Os, since I never touch them.
So I have removed the performance block. In an in-band device, 100 percent of the I/Os will slow down 100 percent of the time. That just does not happen with out-of-band.
The catch in doing this is that to get it right, you must get it perfect right out of the chute. That is why Invista was the longest running and most heavily tested product in our entire history.