The common concept of server virtualization has grown through breaking new technologies before years to a point today, when server virtualization vendors tend to implement similar features with minor innovation. There are two virtualization features in my mind which could be the next move in IT virtualization:

Application-Centric Virtualization

Virtualization systems today work with operating systems. They support deploying virtual machines, failing them over to another physical hardware when disaster strikes, they optimize physical memory utilization and many more OS-related tasks. What is more, the virtualization platform can deploy new operating system automagically, according preset scenarios. Well, where’s a problem?

It’s application, not operating system what the end users really need to work with. They need the application interface to be available on demand, to respond fast, to stay available should one of company’s facilities fail. And there are many services like databases, fileservers, mail stores and other which that application interface depend on. And it’s the operating system at the end of this application dependency chain.

This means we have a mature technology available to cover the last link of chain. Now it’s time to move operating systems’ role to background, wher they’ll provide a simple runtime environment for applications. Let’s move the focus to applications and let them be managed through the same interfaces we use to manage virtual servers.

It’s not enough, however. We need to keep those applications highly-available and their data consistent. There’s one problem with current OS virtualization systems’ high availability solutions, however: If one physical hardware fails, the application stops until the OS is auto-restarted on another. Not to mention the consistency is usually corrupted in such events.

To move further to 100% available applications there are two options:

1. To redesign each (suitable) application separately to cluster their transactions among multiple running instances and thus be ready to transparently failover in case a single hardware fails.
2. To create a generic API layer in operating system to take care of applications HA features. Similarly to what Volume Shadow Copy did for applications’ consistent snapshots on Windows platform.

Server-bound storage

Most of current server virtualization features depend on central storage, connected to many physical servers. Few companies realize this to be a single point of failure case, when that array’s failure causes a disruption to all connected virtual machines running applications. Mirroring that array or yet better – clustering it using technologies like those by LeftHand or Equallogic – can eliminate this SPOF issue.

There’s another option, however – use the same x86 box for both the virtualization system and storage. Just imagine a common server used for virtualization – it boots from an internal flash drive and still have some 6 drive slots available to accommodate SAS or SATA drives.

By implementing a synchronous block replication feature – or implementing an existing one – to replicate data between boxes, we could start building an autonomous virtualization cluster. Should one box fail, the other one will transparently take over both it’s applications and storage.

Do you worry about such storage performance? You might be right, you need tens of SAS drives to satisfy some applications’ IOps needs. Soon, however, such performance will accommodate in both read and write operations a single SSD drive.

Putting right virtualization system platform, block replication system, 2 SSD drives and some large capacity SATA drives into a single box is a dream solution of most server administrators. We have all technologies available to build such system, the time some server vendor designs it is comming. I believe.

 

Lukas Kubin is an expert at the Insight Community. To get insight from Lukas Kubin and other experts, please visit www.insightcommunity.com.