GCJ: What is a "Virtual Workspace?"

Keahey: A Virtual Workspace is an abstraction of an execution environment that can be made dynamically available in the Grid, and it's primarily focused on two broad requirements. One of them is the ability to associate an activity in the Grid with a certain quantum of resource, a certain percentage of CPU... say, memory, or disk, and so forth. The other requirement is recreating the necessary environment (in terms of software configuration) that the user needs on the Grid. Most applications require a very specific configuration - how do you provide it on a remote resource in the Grid reliably and dynamically? Those are the main issues that Virtual Workspaces are trying to tackle.

GCJ: So tell us a little bit about the initial Grid community reactions when you kicked off your proof of concept work with VMWare and Xen.

Keahey: About two years ago, when we first started talking to users about our prototypes using virtual machines for the Grid all the focus was on VMWare. And because the licensing fees are high, the project was slow to take off. We'd hear people ask "If I have to spend $5K on a virtual machine, why wouldn't I just buy a real one?"

Last summer we start experimenting with Xen, which is a very efficient open source hypervisor implementation slated to become a part of the Linux kernel in the near future. Suddenly we started getting traction as a lot of people became more interested in exploring virtual machines in Grid environments. So these two aspects - efficiency and availability -- provided a crucial critical mass for the project.

Of course in order to provide a really wide appeal the key is to have balance: what I also hear in many situations is that "licenses are cheaper than people." If you use open source software your choice of available versions and scalable support may in practice be limited. This is where commercial support, provided by companies like VMware or XenSource, is of critical importance. This allows sites to suit the deployment to their needs.

For today, our Virtual Workspaces project with the Globus Toolkit is primarily focused on Xen. Within a month, we hope to release a preview workspace service that will provide a glimpse into what is possible with Virtual Workspaces on the Grid. And that service is going to have a back-end capable of creating and managing Xen virtual machines. If you were to install that, and install a hypervisor on your nodes, then you could remotely deploy virtual machines using GT4.

GCJ: Other than cost, are there any ways that Xen is more attractive than VMWare for Grids?

Keahey: It's pretty much the fastest hypervisor available right now. Another way that Xen is particularly valuable is that it provides very good enforcement mechanisms -- so it's possible, for example, to say, this virtual machine will run on 50% CPU, and the other virtual machine will run on 40%, and they will split the CPU on the machine in those proportions.

GCJ: Those are what are referred to as virtualization's great "isolation properties" for the Grid, right? Can you elaborate a bit on that concept?

Keahey: Typically, isolation is understood in the security sense, meaning if I have two different virtual machines, then users cannot easily get access - unless you're authorized, of course - to go from one virtual machine to the other. Nowadays, when you have two different applications executing on the same node, they can probably share some files, they can see themselves in the process listing and so forth. If you have a virtual machine, you don't get that information. You're completely isolated.

Another isolation concept refers to isolation of the software stack. Because the virtual machines virtualize at the level of the instruction set architecture (ISA), all the software that goes on top of that will be specific to the virtual machine. So the software stacks is completely isolated.

Performance isolation is also talked about in the sense that you may want to "isolate" your usage of CPU or bandwidth: that makes running alongside many users much more attractive.

GCJ: What sorts of organizations are currently evaluating your Virtual Workspaces project?

Keahey: We are actually working with Open Science Grid (OSG) on a project called "Edge Services." The way most of our scientific sites are structured is that typically you have a private network for the site, and then you have a few nodes that run services which start up computations on the site or move data back and forth between the site and some entities external to the site. These services, executing on the edge of private and public network, are called "Edge Services".

Often various communities that use the sites might have their Edge services configured in different ways. Sometimes these configurations are conflicting, because they require different operating system installations or other prerequisites. Putting each Edge Service in a virtual machine would solve this problem.

Also, the nodes on which Edge Services execute often become bottlenecks to the sites: they often have to handle large volumes of requests leading to high load conditions which might affect responsiveness of a site. How do we ensure that one community does not adversely affect Edge Services run by another community? Again, leveraging the fine-grain enforcement capabilities of virtual machines will help.

So what we're exploring with in this project is to start Edge Services in virtual machines, isolate those configuration requirements and allow for controlled resource enforcement between the different services.

GCJ: Are there any networking tie-ins back to your Virtual Workspaces project?

Keahey: Yes, to understand how networking ties in, let's talk about workspaces in a larger context: groups of workspaces that we call "virtual playgrounds" - a concept that corresponds to a virtual Grid. A Virtual Workspace was conceived of as a sandbox, and once you have more than one sandbox, you essentially have a "playground". Workspaces in a playground could be connected with virtual network overlays also providing some concept of quality of service, associated with virtual storage etc. This project was recently funded by the NSF CSR project.

The first step in creating such a virtual Grid is to give a virtual machine a presence on the network, in other words, an IP address. One approach would be to give each virtual machine its own public IP address. Well, people are not very willing to do that, and this way you quickly run out of IP addresses and problems arise when you try to figure out how to migrate the virtual machines, and so forth.

The solution that we're working on is to put those virtual machines on a virtual network - to give each virtual machine a virtual IP address, such that the traffic to this address gets redirected when the virtual machine gets migrated. This also creates the opportunity to manage that traffic to enforce quality of service. Of course we'd need to then also need to manage interactions between those various virtual networks as needed.

So one of the things that we do in the Playgrounds project, is the development of a network overlay that will allow us to manage, in a sensible way, the allocation of these addresses. Potentially such an overlay would be connected with a specific Grid. A Grid project could have its own IP overlay, and that IP overlay could interface with other private networks, through some well-defined points.

GCJ: How might CNRI's Handle System help?

Keahey: It certainly would be a good idea to explore the affinities of the Handle System with the naming of workspaces. We could use this technology to manage information about a workspace and its attributes in a policy controlled way. That's something that we have discussed at a very high level at this point and it might not happen for a little while.

GCJ: Is your group looking for any additional help or contributions from other developers or IT vendors in the community?

Sure. The more we go into the nitty-gritty details of how virtual machines will connect to the Grid, the more we're finding problems in networking, various configuration setups, and security - for example we may need additional interactions between the hypervisor and Grid computing than what is possible now. And those are specifically issues that I think we would like to isolate and identify the right experts to collaborate with to solve.

Also, right now for the IP overlay we're working on, we're using OpenVPN - open source virtual private network software. But if we could collaborate on other implementations of tunneling or use software that a vendor might contribute, we would be very interested and willing to collaborate with them.

For additional information see this paper: Virtual Workspaces in the Grid

close window