Virtualization

Abstract

Virtualize this

Computer Science theory #1: when in doubt, add [yet] another layer of indirection. That is all virtualization does. This is nothing new really. We see and practice this everyday as professionals in the field, when we write code, when we are setting up a network, etc… Polymorphism is the perfect example of code level virtualization. The fact is that everything we have known to be true is one or more layers of abstraction of the underlying pieces (i.e. virtualization). We have seen the ever growing popularity of the Virtual Machines over the past decade. We are somewhat familiar with the concept, and some of us have actually used a Virtual Machine or two such as the Java Virtual Machine or the Microsoft Common Language Infrastructure.

Virtualization and Grid Computing

How, if at all, these two are related? Why some are foregoing the name Grid for the term Virtualization? The fact of the matter is that you can virtually virtualize (punt intended) anything these days: OS, Storage, CPU, or even things like USB Virtualization. Well, when the objective is simply to virtualize, you can see how that will be like opening up Pandora's Box of projects. Here is another way to look at this problem: do I really need to virtualize anything? I am the CTO of a Grid solution provider company called SoftModule, so you can imagine that we get brought into a numerous of situations where the client wishes us to help them make the best use of their resources. A number of commercially available products tend to tie the Grid with the term virtualization. Grid framework[1] needs to virtualize your compute resources, but the reverse is not necessarily true. Virtualizing your storage system does not equate to a data Grid, for example. Virtualizing your resources co-located across many locations would give you that Single System Image (SSI) that you need to have to use resources effectively; however, you need something else. The piece that pulls everything together and ties your resources to the incoming demands is the resource manager.

Resource manger or the scheduler is as it known in the Grid world, is a very complex and difficult piece of software to write. The scheduling problem is by definition NP-Complete unless you are talking about scheduling across a very small number of resources (2 or 3 machine shop problems). Therefore, heuristics to the rescue! For the most part, you make a guess about the resource requirements and try not to starve any given client. The problem, as you know, gets very interesting when you are talking about a global Grid spanning the four corners of the world. Getting back to the topic at hand, how does virtualization help this effort? I am going on a limb here, and saying that it does not! Well, at least it does not help the way we think it does.

The goal is to find the best way to effectively use a resource. So tell me, how effective is it to send a job to a resource in New York from a user in London when the data transfer time takes longer than the processing time? Virtualizing foregoes that old notion that we held dear when we calculated speedup time. Virtualization by definition removes us from some of the details of the underlying infrastructure, and the metadata that we need to know in order to use a resource efficiently. This is not to say that I am not a supporter of the Virtual Organization (VO) concept. What basically I am saying is that when building a VO, care must be given to details of the organization in order to allow the participants to realize a higher return on their investment. This is one thing that the concept of VO actually supports thru their use of policies.

To this extent, one would argue that Virtualization and Grid are going in two different directions. There are many features of the virtualization that is useful to a Grid, but one needs to read the footnotes to realize what is gained or lost in the process.

Virtualization and Polices

Policies could refer to anything, which is good in our case as we require the means to tighten our grip around the access and use of our Grid infrastructure. Polices, to me, are a very general terms used when we cannot explain what we want to enforce via any other means. In the realm of virtualization that we just spoke about, policies play an important role in both assisting the resource manager with metadata about the resources it is managing and about the clients that it is granting access. One could argue that Policies are the third pillar that holds everything that is the grid together. Resource manager without any policies, not even the basic scheduling policies, is useless in most cases[2].

The question is then whether to enforce policies or to force them? Better put, whether polices are driven by the users or the resource providers? I like to think both, but one needs to have the final saying. Most real world scenarios are programmed so the resource provider has the final saying, but I am not too crazy about that either. In a true shared environment such as an enterprise, there is no distinction between the provider and the user. But there are scenarios, most notably security, which neither of the two parties have much control over. Security should be a policy that is enforced by a trusted entity, as is in case of using a Certificate of Authority.

Ontologies can be used as the means to represent polices. The ideal scenario is to have ontologies representing the needs of the resource provider, the user, along with relevant data from a trusted third party. In a given organization the ontologies that are prevalent to that organization is then set via a committee that oversees the construction and enforcement of ontologies. With a committee now overseeing the ontology creation and knowledge management, we forego the notion of conflict in policies. Ideally one would prefer a meta-ontology that needs little intervention, but we long way from that with our present understanding of ontology engineering and knowledge management.

Policy Enabled Grids

An infrastructure that is maintained by the use of ontologies as opposed to a plain virtualized environment is what we need to strive for when we look at Grid. Virtualization is the side-effect of a Grid framework and not the means to get there. As you know, the high-performance computing and cluster computing concepts have around since the dawn of computers. What has changed over the years is the way we think about the architecture which enables these concepts. We have more tools at our disposal, communication speeds have risen, processing power has increases greatly, but the reasons that we needed such infrastructures have remained. With new tools, we need to take extra care when we build new infrastructures.

The question you need to be asking before taking on a project that virtualizes something is whether or not this thing really needs to be virtualized. Are you currently having difficulties making the best use of this specific resource? Is your enterprise storage system for example, becoming too large for your IT staff to manage properly? Is there a solution that meets your needs without introducing extra complexities into the picture? Let us not even look this question from a pure monetary standpoint, and more from the time-saving stand-point. The old saying Time is Money does not really apply when the alternative to shaving a couple of seconds off of your daily tasks means a project that will take six months to implement. Another way to look at this is that in the long run you might be faced with a situation in which daily maintenance will simply overtake the uptime of a given resource. Do you take a proactive or a reactive approach to this type of problem?

Let us look at this from the perspective of quality of work being done before and after the virtualization project standpoint. For example, virtualizing your storage system so it can be accessed from anywhere within your enterprise globally is very appealing. Assuming that you have terabytes of storage that is scattered across your enterprise, and that data mining is a daily task that every employee undertakes on regular basis. Virtualizing your storage system to allow your employees to better search for a given document without the need to search for hours is worth the cost of implementation.

Have you and a couple of your colleagues ever sat in the car during your lunch hour simply because you didn't know where to go to grab a bite to eat? All you wanted to do was to eat lunch, but when it came down to it, you actually needed to make a decision between Chinese, Sushi or Mexican food. Knowing that you need to eat lunch is not enough when you leave the building, is it? Have you ever sat in a meeting when the project scope was so abstract that you were simply mind-boggled, and all you could think about was, who came up with this project? This exactly how I feel every time I hear a project with the name virtualization in its title. I cringe and look for the closest exit.

Art Sedighi
Founder and CTO of SoftModule,
sediga@alum.rpi.edu

Footnotes

1

I use the term framework because Grid software does not make sense. Grid software could be confused with the application that is running on the Grid. I like to think of GT or one of many commercially available Grid vendors' products as the Grid framework.

2

You can think of things like First Come, First Serve (FCFS), or Shortest Job First (SJF), etc as polices.