More than ever in 2010, IO Virtualization (IOV) has been showing-up in products, written about, spoken about. Because I’ve had a few years’ experience with this technology, I wanted to give a very brief explanation of the concept, and focus more on why it will be increasingly important.
In particular, I want to draw an analogy where you should view IOV as a critical enabling feature of future IT Management… but not as a stand-alone product. Why? It's similar in concept to how the hypervisor is an enabler (but usually not used as a stand-alone product) of data center management services.
This blog is related to my 2009 installment on Fabric as an IT Enabler.
What is IOV?
Today's Physical Infrastructure |
Clearly this is convenient because it (a) eliminates multiple costly IO devices that also consume power and installation time. But it’s also convenient because IO – and it’s associated addressing such as IPs, MACs, Worldwide Names, etc. – can be instantly configured with a mouse.
The other consequence of IOV is that a single physical port means a single physical cable. In essence, a server’s logical IO is consolidated down to a single (physical) converged network which carries data, storage and KVM traffic. So this means that no matter how many logical IO devices you configure for a server, there is still only a single cable out the back. So IOV yields the ideal “wire-once” server environment that’s still infinitely re-configurable.
The overall value of IOV becomes clear fast: Fewer physical IO devices to buy, fewer cables to install, zero re-cabling, fewer physical ports to buy, and instantly re-configurable IO.
Differing Implementation Approaches
Infrastructure With IO Virtualization |
In brief, there are a few differing approaches to IO virtualization:
- Existing on-board Ethernet with new IO drivers: (e.g. Egenera)
- Converged Networking Adapters (e.g. Qlogic, Emulex)
- Appliances + high-throughput IO devices (e.g. Xsigo)
- Existing physical IO but with address hardware-based mapping/virtualization (e.g. HP VirtualConnect)
You should think of IOV using the following analogy: The way in which the hypervisor abstracts software in the application domain, IOV abstracts IO and networking in the infrastructure domain. (However, to be clear, IOV is not a software layer as-is the hypervisor)
This analogy leads to a few more observations:
- Where the hypervisor added software portability in the software domain IOV will do the same for the infrastructure domain. Higher-order services like HA and consolidation were made possibly by the hypervisor. Similarly, HA, DR and migration can be accomplished with IOV. And what’s more, a hypervisor is not required for IOV, so you can use IOV with native applications too.
- The hypervisor used to be the focus, but now it’s merely an enabling feature embedded within higher-level IT management products. Those products leverage the hypervisor to perform tasks such as migration, fail-over and consolidation. You should view IOV similarly: it is an enabling feature that will allow for analogous IO consolidation, migration and fail-over.
- Where hypervisor implementations and performance used to be hotly-debated, nobody really cares anymore. Today the real *value* is not in the hypervisor, but in the management tools surrounding it. Similarly, IOV should be judged less on how it is implemented, and more on the management tools and automation which manage it.
….Aside from benefits like reducing cabling and switch ports, I think the most interesting aspect of virtualized IO is the ability of a physical server's personality to be moved to any other server in the data center. In addition to the underlying network technology, the thing that makes this possible is integrated management of the server and data center fabric. In most cases, this won't be a stand-alone product that you acquire (though you can build your own solution from InfiniBand and PCI Express products on the market). This capability will most likely be an integrated part of whatever server and network environments you select, but now is the time to begin planning how you'll tie it in with the rest of your system management environment.IO Virtualization in the IT Management Landscape
How might IO virtualization be used as part of the IT ecosystem in an integrated manner?
In much the same way that the hypervisor has since been embedded in tools like VMware’s vCenter, IOV can (and has been) embedded with higher-level management tools.
Taking an example I’m rather familiar with, Egenera’s PAN Manager Software surrounds IOV technology with facilities such as integrated with converged fabric networking, server boot control and storage connectivity. When used alongside these and other services, IOV enables:
- Server High Availability– In the case of hardware failure, a server’s infrastructure state (IO addressing, storage naming, network topology and workload) can be re-instantiated on another bare-metal server. This provides a ‘universal’ style of failover that doesn’t require clustering software. And what’s more, the failed-over server workload could be a native OS, or a VM host. IOV is agnostic to the workload!
- Disaster Recovery – expanding on the example above, if an entire domain of servers fails, the entire group of server IO states, networking states, etc. can be recovered onto another domain (assuming shared/replicated storage). This approach to DR is elegant because it fails-over not just workloads but the entire logical server/environment configuration as well.
- Scaling-Out – where a series of server profiles can be instantly replicated into an instant cluster. Workloads, NICs, HBAs, networking addressing and storage connections (complete with fabric-based load balancing) can all be cloned… starting with the IO and networking profiles, made possible through IOV.
No comments:
Post a Comment