Grid Middleware

Introduction

According to the arrangement of Daoli project, the task for HUST is described as Grid middleware to achieve virtualization of the software/hardware platforms so that the VO will only need a unique grid application to achieve policy enforcement in a delegation manner. This is a very important virtualization step!"

Considering a need to run a given code in a heterogeneous environment of a diversified hardware/software platforms. Perhaps it's a complex code of a user which needs to use distributed and proprietary data not owned by the user, and therefore the user would have to deploy the code to run "out there". Imagine your code is a curling stone. A middleware is created to form a smooth ice surface over the bumpy platforms, as illustrated in the figure below: You may need to run your code this way because you have "the" code to do your job, while the data needed are distributed in various platforms. You don't want to code various codes because you may not know where the data are in the first place, it's a service level agreement broker who will deploy your code to the right places to have the job done for you. But this is an old way of curling. The "middleware" may only aim at a few number of platforms, and is usually too large to be practical.

A new way to "curl" is to wrap the "curling stone" with an ice coat so that it can be curled on a coarse or even bumpy surface still travelling afar at ease. Let the user have a code. A request of "running the code out there" is made to a service provider (frontend node). The SLA server (as a frontend node) will find targeting data center and an "image" to wrap the user code so that the result will be a virtual machine (VM) for a targeted data center's platform (a computing resource provider where the proprietary data are, as a backend node), and then deploy the VM to the targeted platform for execution. The method is described below.

A trusted VM factory service, as depicted in Figure 6, is introduced to take the role of the above mentioned grid middleware. This service, deployed on the CGSP container, allows a legal grid client to deploy a Trusted VM on a trusted virtual node according to the client's deployment request. An application (it means a piece of code) submitted by the client run on the trusted VM. A trusted VM is an abstraction of a trusted execution environment, which is used as a sandbox to protect the trusted host against the malicious code. The virtual node is also trusty by deploying TPM and MVMM. The VM image files are securely kept in a host, protected by TPM. Control interfaces are provided by the trusted VM factory for a user to manage VM configuration, pause, shut down, and restart his/her VM.
.

Trusted VM factory service

1) Secure remote deployment and management of VMs
The trust VM factory service provides a set of security interfaces,

by which the Clients can deploy, pause, restart and shutdown VMs after inter-authentication with the client, which should be transparent to the end users. Once a VM is deployed by the Trusted VM factory, the client can monitor VM properties, such as its lifecycle state, time-to-live, or the resources assigned to the VM, which are described by WSRF resource properties. The client can reset these above properties, such as increase the time-to-live of a VM. The client can specify the properties of site configurations when its VM is deployed, for example, what VMM is required for the client?      2) VM image searching and resource allocation

When the grid client submits its request to the trusted VM factory service, the trusted VM factory service needs to verify the identity of the grid client. After authentication, the service retrieves a suitable VM image file from trusted image storage for the client, and securely deploys a VM to a suitable virtual node with the VM image files. The trusted VM factory service assigns resources, including deployment time, CPUs, memory, disk space, network address, and so on, to the VM.

3) VM backend plug-in VM backend plug-ins are installed on the virtual nodes, where VMs are deployed. The trust VM factory Service communicates with VMs via VM backend plug-ins. A VM backend plug-in plays the role of a local resource manager with the capability to manage the deployed VMs in a virtual node.

Trusted image store

The host for storing trusted image files is actually an image database, used for deploying various kinds of VMs. Some kinds of grid components are included in the image files. A VM is deployed by using an image file to support some kind of grid application. The trusted VM factory service needs to search suitable image files from the trusted image storage to meet the requirement of grid clients. Trusted image storage is tamper-proof. Hash values for the image files are created and protected by the TPM platform.

Secure migration

When a trusted VM is deployed by the trusted VM factory service, The VM is combined with the client's proxy certificate. In order to deploy multiple VMs on different trusted virtual nodes for a grid client( it means a VO should be created for the client task), SSO (Single-Sign-On) should be provided. The image file needs to be migrated among multiple MVMM platforms and the user proxy certificate also needs to be migrated from one MVMM to another MVMM. We can implement the secure migration of proxy certificates based on Daoli.

Comments