A GRID SYSTEM OFFERS EFFICIENT VIRTUAL ENVIRONMENT

A GRID SYSTEM OFFERS EFFICIENT VIRTUAL ENVIRONMENT

Abstract:

Grid technologies can allocate resources to applications dynamically, in an on-demand fashion. By defining standardized protocols for discovering, accessing, monitoring, and managing remote computers, storage systems, networks, and other resources.   To ensure that once a resource is accessed, it fulfils user expectations for quality of service (QoS) and to provide execution guarantees. Grid provide access to many resources with diverse software configurations, a user’s application will typically run only in a specific, customized software environment. Variations in operating systems, middleware versions, library environments, and file system layouts all pose barriers to application portability. Thus, in practice, users are often unable to leverage the available resources without tedious debugging and porting efforts that drain time and energy from their primary objectives, thus compromising their “quality of life” in interactions with Grid software an application can abstract the properties of an environment it requires for execution in terms of memory size, the number of processors, or library. A resource can define its offered capabilities in similar terms. Such environment abstractions can be implemented by using a variety of sandboxing technologies and can be mapped onto resources, offering the required degree of isolation, fine-grained enforcement, and configuration.           The virtual workspace (VW) abstraction to describe such environments.  It describes how a workspace deployed on a physical resource can provide a deployment capability for setting up virtual machines, matchmaking, with negotiation and advance reservation protocols [5], can be used to create complex workspaces.

INDEX TERMS: Virtual Workspace, Grid Technology, Protocols, Remote Systems, Quality of service, Middleware.

1. Introduction

A virtual environment is an abstraction of an execution environment that can be made dynamically available to authorized clients by using well-defined protocols. The abstraction captures the resource quota assigned to the execution environment as well as its software configuration. Different workspace implementations provide different workspace management capabilities.

1.1 Workspaces as Site-Provided Installations

Nodes on site installations, often configured to support the needs of specific communities such as Open Science Grid or TeraGrid, can provide workspaces to Grid clients. One way of providing workspaces relevant to a specific community is to obtain a priori agreement on required configurations, and then simply deploy those configurations, advertise them, and provide access. This approach is often practiced today. A more flexible way is to allow for automated boot of physical nodes based on a configuration description and boot images.

The final step in making a site-provided installation available as a workspace is providing access to Grid clients. Such access is typically provided by the use of dynamic accounts: accounts generated on the fly or assigned from a pre-generated pool. In addition to workspace creation, this implementation provides a flexible interface for access management and policy inspection. The account cleaning process is configurable by the site administrator and, for additional security, includes an optional quarantine. Typically resources are made available in a relatively coarse-grained manner allocating the number of nodes or amount of available disk space but not enforcing fine-grained quotas, such as percentage of CPUs between users of a specific resource.

While providing access to site-configured workspaces is a fast and widely accepted solution it lacks flexibility in that it offers little choice in shaping the workspace’s configuration or the resource allocation associated with it.

1.2 Virtual Cluster Workspaces

Workspaces implemented via any of the methods just described can be grouped to create virtual clusters of various topologies. A virtual cluster workspace can be constructed via, an existing cluster with tools for dynamically enabling access, or a cluster of virtual machines. When using a virtual machine implementation, a virtual cluster workspace is implemented in terms of multiple VM images that may represent specialized nodes such as worker or head nodes. 

2. Virtual Workspace Concept

A workspace description should contain sufficient information for a deployment service to create the environment represented by this workspace. This information is of two kinds: (1) description of packages or other data that need to be obtained from potentially external sources and put together (such as a software installation package or a VM image), and (2) deployment logistics information, which needs to be interpreted and configured at deployment time .

The quantity of information that must downloaded and the amount of deployment-time configuration will depend on both workspace implementation and the deployment service implementation.        We adopt an approach that strikes a balance between definition flexibility and deployment-time configurability and speed. We describe a workspace using the XML schema depicted in block form in Figure 1.

The description associates a workspace name with its definition and deployment logistics information. The workspace name is a Uniform Resource Identifier (URI) that can be resolved to obtain more information about the workspace, such as its provenance, creation and modification times, or detailed software catalogue.   While irrelevant to deployment, this information is valuable to a workspace client.

We represent a workspace as a collection of modules that can be combined to define the workspace’s content. These modules may include a variety of components such as a system module, a community specific configuration layer, or an application module. These different components can be obtained at different times and from different sources, thus optimizing VM image transfer.  Thus, the definition section of the workspace description contains a definition of workspace modules together with information describing how they should be obtained and put together, as well as deployment information describing how the workspace should be configured on deployment. In order to enable verification prior to deployment, the definition section additionally specifies prerequisites for workspace deployment.

The deployment service must be able to resolve how to acquire the partitions, verify their integrity, and instantiate the VM such that the proper image is loaded by the VM at the expected device. Thus, for each individual module we specify a module name, the location at which the module can be obtained, the device binding to which it should be bound, and modes of operation (permissions). Like the workspace metadata, a partition name is a URI that can be used in conjunction with other services to obtain more information about a specific partition including dependencies on other partitions.

A partition location can be resolved to locate and transfer an actual image partition. We are currently creating an additional attestation element to describe who developed a partition and attested to its content. To complete VM instantiation, we also need to describe deployment information on how to provide networking and (potentially) additional storage. This content is contained in the deployment section of the workspace. To reflect that fact that a VM can have an arbitrary number of network interfaces (NICs) that are mapped to physical hardware in different ways, networking is described as a collection of NIC elements. For each NIC, we describe naming (the method used to obtain an IP address), network binding describing how VM’s network interfaces are bridged and managed outside the VM, and the IP address.

The network binding can be bridged directly to a physical NIC, bridged to a VPN, configured behind a NAT of one of the host machine’s IP addresses, or configured to use an isolated LAN.

Atomic workspaces, describing one execution environment, can be combined to form aggregate workspaces such as virtual clusters. An aggregate workspace is defined to contain sets of homogeneous atomic workspaces. This approach allows us to define heterogeneous a head node and worker nodes.

 

Figure 1: Graphical representation of the workspace schema. Plus signs denote “one or more elements”.

 All information about a cluster workspace is derived from the metadata of the atomic workspaces describing those nodes. While workspace metadata describes where VM image parts can be obtained, it does not include them. Images as well as workspace descriptions can be put together by VO deployment teams supporting specific groups of applications. Such workspaces can then be shared, copied, and incrementally refined, allowing users to further customize VWs to suit a particular set of needs. VMPlant  implements such a service, which however combines the process of VM configuration with its deployment. In this architecture those roles are split: once put together, a workspace description may be deployed many times, each time potentially with a different resource allocation.

3. Creating, Deploying, and Managing Virtual Workspaces

We use the term Workspace Service to denote the entity responsible for deploying a workspace and associating it with a specific resource allocation. Figure 2 illustrates these services and their function. To obtain a workspace description, a client first works with either workspace configuration services to create a new workspace, or selects from existing workspaces using an information  service that associates workspace images with information about those images and the deployment capability (services) they provide. Workspace deployment comprises two phases: obtaining the workspace data required for deployment and using that data to deploy the workspace onto a requested set of resources. Implementing the first phase  may require orchestrating workspace data transfer from remote sources to the site where the workspace will be deployed. Efficiently scheduling such transfers can require global knowledge and coordination. In the second phase, the workspace data is available at the selected site and the workspace can now be deployed using this site’s workspace service. In order to do this, the workspace service must be able to interpret the workspace description and be in control of resources that provide the deployment capability for this kind of workspace (e.g., a hypervisor for virtual machines).              At deployment, a workspace is associated with a resource allocation requested by the client. This resource allocation, as well as other deployment-specific properties of the workspace, can be managed throughout its deployment. All workspace service operations are subject to authorization; authorization policy may be expressed in terms of both the requesting client and the workspace itself. Once the workspace is deployed, an authorized client can interact with services within the workspace.        Note that at this point, the client is authorized by services executing within the workspace. By the act of deploying the workspace and associating it with a resource allocation, the workspace service effectively delegates to the workspace the use of this allocation.

 

Figure 2: Creating and deploying workspaces.

Work on other services is pursued elsewhere; here we focus on the Workspace Service. We define Workspace Service protocols based on the Web Services Resource Framework (WSRF), which provides standard methods for the creation and management of manageable state descriptors called “WS resources.” A Workspace Factory Service uses a “create” operation to create a WS resource representing the new workspace. Associated with each WS Resource are a limited lifetime and other resource properties that can be inspected, queried, and managed in standard ways, and that can be used in conjunction with WS-Notifications  to provide updates on change. A resource can be destroyed either explicitly or by allowing its lifetime to expire. The Workspace Factory “create” operation takes as input a workspace description and a description of a resource allocation to be applied to the workspace on start up. The resource allocation request contains a request for association with a resource allocation for a specified length of time. The resource allocation is specified as constrained values that are bound to specific values when the request is accepted. The workspace to start may take a relatively long time. In addition to the operations used to manage the WS resource, we define operations that allow a client to start a workspace and to shut down a started workspace. Workspace shutdown takes an argument that allows the client to express properties of the shutdown, such as pause, pause and serialize, hard-reboot, and trash (shut down and destroy images). A workspace may be started and shut down many times throughout the lifetime of the WS resource associated with it. A client may use the resource properties to adjust the resource allocation given to a workspace using the WSRF SetResourceProperties operation.

4. Putting It All Together: Workspaces, Agreements, and Brokers

While virtual machines provide a compelling solution for environment deployment, their own deployment, as well as its scope, relies on the presence of compatible hypervisors on a resource. In this section, we discuss how different implementations of workspaces can be put together to implement the full stack of interactions required for workspace deployment. A workspace is associated with a deployment capability. As the figure below illustrates such capabilities can support the deployment of jobs or other workspaces. The Workspace Service, implementing workspace deployment, can operate at each layer; however, at each layer, workspace deployment is associated with different implementations and ownership.

 

Figure 3: Environment layers: A and C are hypervisor workspaces, each supporting the deployment of different types of virtual machines, which in turn provide job execution capabilities. Workspace B provides job execution capability.

Virtual machines,  whose deployment and shutdown can easily be controlled by a site without impairing the availability of its resources, can be configured by communities wishing to support specific applications. While today a site typically simply advertises the supported deployment capability, such advertisements are static and do not allow much flexibility in the support of deployment capabilities. If, in practice, one dominant capability is required by the site users (  hypervisor ) this model is sufficient. However, systems such as COD offer a more flexible model that implements site-specific workspace services that allow an authorized client to request the deployment of a workspace from a limited set. Providing standardized interfaces to such services would enable a client to flexibly negotiate required workspaces at different sites.

These interfaces are likely to be based on emerging standards such as WS-Agreement [5]. Figure 3 shows how the full workspace deployment could be negotiated using    WS-Agreement. A broker negotiates an agreement with a site for the availability of a set of resources and obtains a resource allocation agreement. Workspace deployment requests, defining a deployment capability and a resource allocation request, can now be made against that resource allocation agreement. If the request is successful, a workspace deployment is bound to the available resource allocation, and the hypervisor configuration is deployed on the requested resources.

 

Figure 4: Negotiating workspaces in the Grid.

It should be noted that it is the deployment capability that is advertised by a site.     The power of using virtual machines relies on the fact that maintain configuration images required by many different communities, in practice only a few images can be maintained. However, maintaining a few generic hypervisor images gives the sites a platform that can be used to deploy a large variety of environments.

5. Summary and Future Work

Virtual machines, enable many scenarios that are hard to achieve with current tools. We expect that providing reliable quality of service enforcement will lead to more widespread use of agreement-based protocols and commercial interactions in resource use and contributions. The ability to deploy remote workspaces reliably will provide much needed “quality of life” for Grid users, who will be able to use more resources with greater confidence. Workspaces also make it easier for resource owners to contribute resources to the Grid and to manage virtual organizations. Workspaces can be used for management at different layers. Virtual organizations can manage workspaces for their applications while still giving a site coarse-grained control over workspace images via attestation.

Much research is still required to realize this vision. In future work, we plan to further refine and experiment with virtual workspaces and to work on ensuring their security, developing networking infrastructure, and devising methods that leverage the migration capability and other aspects.

6. References

1. Foster, I., C. Kesselman, J. Nick, and S. Tuecke, The Physiology of the Grid: An Open

Grid Services Architecture for Distributed Systems Integration. 2002: Open Grid Service Infrastructure WG, Global Grid Forum.

2. Foster, I., C. Kesselman, and S. Tuecke, The Anatomy of the Grid: Enabling Scalable

Virtual Organizations. International Journal of Supercomputer Applications, 2001. 15(3): p. 200-222.

3. Goldberg, R., Survey of Virtual Machine Research. IEEE Computer, 1974. 7(6): p. 34-45.

4. Keahey, K., I. Foster, T. Freeman, X. Zhang, and D. Galron, Virtual Workspaces in the Grid. anl/mcs-p1231-0205, 2005.

5. Andrieux, A., K. Czajkowski, A. Dan, K. Keahey, H. Ludwig, J. Pruyne, J. Rofrano, S.Tuecke, and M. Xu, Web Services Agreement Specification (WS-Agreement) Draft 20. 2004: https://forge.gridforum.org /projects/graap-wg/.