As a user, when virtualisation 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 virtualisation 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 virtualisation 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 virtualisation. You own VMware, but isn't there still competition?
There are many ways to do virtualisation. 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 virtualisation 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 organisation 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 virtualisation?
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 virtualisation 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 virtualisation 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 virtualisation 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.
1%
1%
