Ten More Reasons to go to Oakland

By Ian Foster

Rich Wellner came up with four reasons to attend the Open Source Grid and Cluster Conference, to be held in Oakland May 12-16. I outdid him and came up with 10:

1) Globus program is fantastic, including tutorials, advanced
technical presentations, contributed talks, and community events on
every aspect of Globus.

2) Gobs of other material on Sun Grid Engine and Rocks, and
other open source grid and cluster software.

3) Gathering: A great opportunity to meet colleagues, peers,
collaborators from the grid and cluster community. The only grid
meeting in the US the rest of this year--the next two OGFs are in Spain
(June) and Singapore (September).

4) GT4.2: You'll get to learn about the exciting new features
in Globus Toolkit 4.2. New execution, data, security, information,
virtualization, and core services.

5) Gratfication (immediate) as you get to provide your input
on future directions for Globus, Sun Grid Engine, Rocks, and other open
source systems--and maybe sign up to contribute to those developments.

6) Grid solutions: You'll get to meet the people using Globus
to build enterprise grid solutions in projects like caBIG, TeraGrid,
Earth System Grid, MEDICUS, and LIGO, and learn about solution tools
like Introduce, MPI-G, Swift, Taverna, and UniCluster.

7) Gurus: You get to grill the Globus gurus--or, if you prefer,
show off your own Globus guru status.

8) Great price: $490 registration is substantially cheaper than
OGF or HPDC, for example, and the hotel rate is reasonable ($149).

9) Gorgeous location: Oakland is easy to get to -- SFO (with
easy BART  train ride), Oakland, and San Jose airports also nearby.
Just a 10 minute train ride to download San Francisco. A lovely time to
be in the Bay Area.

10) Gorilla and guerilla free: None of the corporate marketing
talks that diluted the last GridWorld conference--apart from two
sponsor talks, this is pure tech, and highly useful tech at that!

A Grid OS?

By Roderick Flores

I have recently been working on a test plan for a framework designed to deliver applications to grid users. The framework is useful for the specific environment in which the customer operates. However it has led me to imagine something more generic that anybody who manages a Grid intended for use by a diverse community would find useful.

You need to have a solid software infrastructure consisting of compilers, libraries, middleware, languages, and services. Your customers want to be able to run the applications that suit their goals best with as little fuss as possible. These include off-the-shelf, commercial customizations, open-source, freeware, supported in-house, and individually built software packages.

While there may be few interoperability issues within a small group or company, you can bet that not all programs will play well with others. Some applications will require very specific libraries and middleware while others will prove to be quite flexible. Some applications require supporting software for 64-bit architectures while others need 32-bit. Other software has different feature-sets on different hardware (e.g. SPARC versus x86) as well as software (e.g. Linux versus IRIX) systems. Still other applications, particularly those that are on long development cycles, tend to use older feature sets whose behavior may have changed or been eliminated from subsequent package releases. Meanwhile your in-house developers might be working on the bleeding-edge and therefore use software that is too unstable for the general user community. Face it: very few software developers expect their products to co-exist with others.

This is a big challenge for anybody who is expected to create a shared-computing environment for a big user community. Typically system administrators will create an operating-system image based upon anticipated usage patterns, security, stability, feature-sets, and availability. They will have specific builds for their web-farm, mail-servers, storage-nodes, and (most importantly) for our Grid computation nodes. They would also like to be proactive and keep their systems up to the latest security and bug-fix patch
levels. In addition, they are going to try to provide the best product they can; therefore they would like to provide the most feature-rich infrastructure with which they feel-comfortable. However, and most importantly, they will use a package manager to maintain software releases on their machines. Why would any system manager want to reinvent the wheel when it comes to building software when the vendors will do it for them?

This last practice has a significant impact on the software you will find on the Grid. If the hardware vendor has a build for the software you use, chances are that is what you will get. These package managers tend to keep only one version of a particular software package on a system at a time. Consequently if a newer version of a package is desired, the older one is removed. Even if they tried to make multiple packages coexist, files would be overwritten. There are a few "compat" versions but these are exceptions.

Clearly, when your mandate is to provide a shared computing environment that has a significant number of processing nodes as well as users, you will have to provide a more substantive infrastructure. At this point you could either build specialized virtual machines for each operating environment or you can create a shared infrastructure that any image can use. Utility-computing players like Amazon have you create your own machine image (AMI) but I think it is unreasonable to expect application users to have the skills to create a proper operating environment.

The second option, creating a shared infrastructure that any image can use could be considered a grid operating system from scratch vis-à-vis Linux from scratch. This type of framework would force us to place our software into a categorized structure capable of differentiating operating systems, hardware architectures, and application versions. This infrastructure should not replace the standard installs for the operating system in order to avoid conflicts – providing application support for a grid is orthogonal to managing a compute node.

All of this needs to work without overtaxing your customers (i.e. application users). The typical user doesn’t care which operating environment they are provided as long as their software runs. Rather they would prefer to be able to call their application as if it were the only version using the only installed system libraries and middleware on the only supported compute node configuration. Basically if a user wishes to use an application, they simply want to call it by name: for example python and perhaps python-2.3.7 or python-2.4.5 should they require a particular version.

A big component of your effort in creating the proposed framework is providing the correct versions of libraries and middleware to your customers’ frontline applications; this is a task that demands specialized configuration scripts whose job is to set-up the operating environment to match the user request and the operating environment. There are a few tools out there that are quite capable of accomplishing something like this. However there is nothing that I am aware of whose goal it is to specifically deliver applications on a grid. Instead this class of tools provides far more flexibility than what is necessary, let alone wanted.

Ultimately I think that the best thing for the industry would be to establish a standard Grid directory structure for placing software in shared environments (e.g. /<root-directory>/bin/<operating-system>/<architecture>/<application name>-<application version>). A standard method for exposing applications should be decided upon as well. This could be anything from link-farms, to wrapper-scripts, or even environment set-up scripts. If this were to happen software developers and Grid administrators could create standardized packages including configuration scripts that would install into this framework. Setting up python would then be as easy as installing the standard packages for each desired operating environment and then calling "python".

A Virtual Infrastructure Layer for Cluster and Grid Computing

Ignacio Martin Llorente

Cluster, and so Grid site, administrators have to deal with the following requirements when configuring and scaling their infrastructure:

• Heterogeneous configuration demands. Users often require specific versions of different software components (e.g. operating system, libraries or post-processing utilities). The cost of the installation, configuration and maintenance of user-specific or VO-specific worker nodes limits the flexibility of the infrastructure.
• Performance partitioning. Most of the computing infrastructures do not allow administrators to isolate and partition the performance of the physical resources  they devote to different computing clusters or Grid infrastructures. This limits the quality of service and reliability of actual computing platforms, preventing a wide adoption of the Grid paradigm.

In order to overcome these challenges, we propose a new virtualization layer between the service and the physical infrastructure layers, which seamless integrates with existing Grid and cluster middleware stacks. The new virtualization layer extends the benefits of VMMs (Virtual Machine Monitors) from a single physical resource to a cluster of resources, decoupling a server not only from the physical infrastructure but also from the physical location. In the particular case of computing clusters, this new layer supports the dynamic execution of  computing services, working nodes, from different computer clusters on a single physical cluster.

OpenNebula is the name of a new open-source technology that transforms a physical infrastructure into a virtual infrastructure by dynamically overlaying VMs over physical resources. So computing services, such as working nodes managed by existing LRMs (Local Resource Managers) like SGE, Condor, OpenPBS..., could be executed on top of the virtual infrastructure; so allowing a physical cluster to dynamically execute multiple virtual clusters.

The separation of resource provisioning, managed by OpenNebula, from job execution management, managed by existing LRMs, provides the following benefits:

• Cluster consolidation because multiple virtual working nodes can run on a single physical resource, reducing the number of physical systems and so space, administration, power and cooling requirements. The allocation of physical resources to virtual nodes could be dynamic, depending on its computing demands, by leveraging the migration functionality provided by existing VMMs
• Cluster partitioning because the physical resources of a cluster could be used to execute virtual working nodes bound to different virtual clusters
• Support for heterogeneous workloads with multiple (even conflicting) software requirements, allowing the execution of software with strict requirements as jobs that will only run with a specific version of a library or legacy application execution

Consequently, this approach provides the flexibility required to allow Grid sites to execute on-demand VO-specific working nodes and to isolate and partition the physical resources. Additionally, the architecture offers other benefits to the administrator of the cluster, such as high availability, support for planned maintenance and changing capacity availability, performance partitioning, protection against malicious use of resources...

The idea of a virtual infrastructure which dynamically manages the execution of VMs on physical resources is not new. There exist several VM Management proprietary solutions to simplify the use of virtualization, so providing the enterprise with the potential benefits this technology may offer. Examples of products for the centralized management of the life-cycle of a VM workload on a pool of physical resources are: Platform VM Orchestrator, IBM Virtualization Manager, Novell ZENworks, VMware Virtual Center, and HP VMManager.

The OpenNebula Virtual Infrastructure Engine differentiates from those VM management systems in its highly modular and open architecture  to meet the requirements of cluster administrators. The OpenNebula Engine provides a command line interface for monitoring and controlling VMs and physical resources quite similar to that provided by well-known LRMs. Such interface allows its integration with third-party tools, such as LRMs, service adapters, VM image managers...; to provide a complete solution for the deployment of flexible and efficient computing clusters. The service layer decoupling from the infrastructure layer allows an straightforward extension of the previous idea to any kind of service. In this way any physical infrastructure can be transformed into a very effective provisioning platform.

A Technology Preview of OpenNebula is available for download under the terms of the Apache License, version 2.0.

Ignacio Martín Llorente
Reprinted from blog.dsa-research.org

My favorite grid application

By Ian Foster

My esteemed Grid Gurus moderator, Rich Wellner, asked "what is the most creative use for grid technology that you've ever seen?" This is a difficult question to answer, but I will attempt to do so anyway.

I choose the work of George Karniadakis, Suchuan Dong, Nick Karonis, and their colleagues on modeling blood flow in the human body. Why I like it is the wacky (sorry, wonderful) way in which they mapped this apparently highly tightly coupled problem onto the distributed sites of the NSF TeraGrid. Quoting  one of their papers:

Motivated by a grand-challenge problem in biomechanics, we are striving to simulate blood flow in the entire human arterial tree. The problem originates from the widely accepted causal relationship between blood flow and the formation of arterial disease such as atherosclerotic plaques. These disease conditions preferentially develop in separated and recirculating flow regions such as arterial branches and bifurcations. Modeling these types of interactions requires significant compute resources to calculate the three-dimensional unsteady fluid dynamics in the sites of interest. Waveform coupling between the bifurcations, however, can be reasonably modeled by a reduced set of one-dimensional
equations that capture the cross-sectional area and sectional velocity properties. One can therefore simulate the entire arterial tree using a hybrid approach based on a reduced set of one-dimensional equations for the overall system and detailed 3D Navier-Stokes equations at arterial branches and bifurcations.

In other words, they mapped different parts of the human body (chest, legs, arms, head, and their arterial branches) to different TeraGrid sites, linking them by a simple, non-communication intensive 1-D problem.

The tools used to make this happen were MPICH-G2 (recently renamed as MPIG) and of course Globus.

Will You Move the Jobs or the Nodes?

By Ignacio Martin Llorente

The history of High Performance Computing (HPC) can be told as a continuous search for the optimal use of the underlying hardware platform. As new architectures are delivered with impressive peak performance specifications, a parallel  effort is made by HPC community to exploit these new machines. This has been the case from the development of message passing frameworks in the early 80's to today's challenges of multi-core processors.

An important piece in this quest is the Distributed Resource Management System (DRMS). A DRMS can be roughly defined as a software component that provides an uniform and single view of a set of (possibly heterogeneous) computational resources. A DRMS can be found in any distributed system from tightly coupled MPPs to Grid or even Peer2Peer environments. The goal of the DRMS in any of these platforms is to find an optimal assignment (in terms of a given target like utilization or wall-time) between a computational workload and computational resources.

Virtualization has opened up avenues for resource management techniques e.g. server consolidation and isolation, custom execution environment provisioning... Although, probably the most exciting feature is its ability to dynamically shape a hardware infrastructure. The same set of hardware blades can be shaped to be a web server and a database server, or a set of cluster worker nodes for scientific computing, or a set of workstations for a virtual classroom...

In  this way, virtualization has completely changed the habitat of DRMS species. In fact, their goal can be reformulated the other way around: find the optimal computational resources to execute a given computational workload. Traditionally a DRMS assigns pending jobs to local resources, and lately with the advent of Grid Computing also to remote resources in other administration domains.

There are two alternatives today to extend the limits of a computing cluster:

• Moving the jobs to the resources. Grid computing enables the interoperation of different DRMS, so a meta-scheduler can transfer the jobs to another cluster. GridWay on top of Globus provides a solution to balance workload across several clusters. This federation of administration domains may even follow a typical customer-provider relationship in a utility fashion.
• Moving the resources to the jobs. The cluster can be provided with additional worker nodes to execute the extra workload. A very interesting example of this approach, that combines Grid computing and virtualization (Workspace Service and Amazon EC2), has been made in the context of the STAR project. Other interesting reference that implements this idea is the Hedeby project.

The generalization of this second approach and its application to any kind of services requires of a new component class for resource management. This new component can be referred as Infrastructure Management System (IMS); there is no clear consensus on its name, virtual environment manager, virtualization manager or VM manager are sometimes used.  An IMS dynamically shapes a physical infrastructure by deploying virtual machines to adapt its configuration to the services it supports and their current load. Given the characteristics of VMs (flexibility, security, portability...), the IMS will be the key resource management component for the next generation resource provisioning paradigm, i.e. cloud computing.

Some examples include commercial products like IBM Virtualization Manager, Platform Orchestrator or VMware VirtualCenter, and open source initiatives like the OpenNEbula Virtual Infrastructure Engine. OpenNEbula allows a physical cluster to dynamically execute multiple virtual clusters, so providing on-demand resource provisioning because the number of working nodes can grow according to user demands so that there are always computing slots available.So the question is: are you going to move the jobs or the nodes?.

Ruben S. Montero

The Canon of Clouds

By Rich Wellner

The emergence of cloud computing as a resource on the grid has led to a huge resurgence in interest in utility computing. Looking at the history of utility computing allows us to identify three canonical interaction models that also apply to cloud computing.

• Metascheduling
• Virtual machines
• Application virtualization

Metascheduling

Initial cloud offerings like Amazon Elastic Compute Cloud created the nomenclature around clouds. Going back before the term "cloud" was coined we see a similar offering from Sun with their utility computing offering. In both cases users submit work to the service and eventually get results returned. How the request gets prioritized, provisioned and executed is at the discretion of the service provider. In many ways this is similar to how a typical cluster works. A user selects a cluster, submits a job and waits for a response. What node is used to execute his request is largely out of his control. While acknowledging there are substantial difference between a cluster and a cloud, another similarity reveals itself when thinking about how users interact with compute resources in companies that operate multiple clusters.

As companies began adding additional clusters, users quickly demanded a facility to submit their jobs to a high level service that would manage the interactions with all the clusters that were available. Most users didn't want to have to themselves use multiple monitoring tools to access multiple clusters and use the information gathered to make a decision about where to submit their job. What they wanted was a single interface to submit jobs to and a service that would make policy based decisions about which cluster to ultimately submit the request.

The situation today is similar. Multiple cloud and utility computing vendors exist and users don't want to spend their time gathering information about the state of each in order to decide where to submit their jobs. Further, administrators and managers need to be able to enforce policy. There are several reasons for requiring this behavior, but probably the easiest to explain is that there are costs associated with resource usage at the cloud vendors and organizations require control over how that money is spent.

The answer to all these needs is to place a metascheduler between the users and the various resources. Users can then use a single interface for all their jobs regardless of where they are ultimately going to be executed.

[A metascheduler] enables large-scale, reliable and efficient sharing of computing resources (clusters, computing farms, servers, supercomputers…), managed by different LRM (Local Resource Management) systems, such as PBS, SGE, LSF, Condor…, within a single organization (enterprise grid) or scattered across several administrative domains (partner or supply-chain grid). -- GridWay

Virtual machines

Clouds are only as useful as the software running in them. Therefore, the next important interaction model is that between users and virtual machines.

Users often need very specific software stacks. This includes the application they are running, support libraries and, in some instances, specific versions of operating systems. Analysts are saying that there are now at least 35 companies addressing the needs of users in managing these interactions. This includes software to implement the enactment layer, manage images, policy engines, user portals and analytics functions.

One of the questions yet to be answered in the cloud community is how to allow users to make use of several clouds on a day to day basis. As this market continues to mature, look for many of the same challenges (e.g. security, common APIs, WAN latencies) that the grid community has been tackling for over a decade to become increasingly important to cloud users.

Application virtualization

In the context of clouds, application virtualization gains significant power by being able to add or remove instances of applications on demand. This is currently being done in the context of data center management using proprietary tools. Clouds present a cool new opportunity to do the balancing act on a regional basis. As more clouds are built and standard interfaces made available, users will be able to load balance to multiple clouds operating in different countries or cities as demand grows and shrinks.

These three models represent established, powerful interaction modes that are being used in production in a variety of settings today. It will be interesting over the next year to see which cloud operators adopt which models and how many lessons they take from existing non-cloud implementation versus trying to reinvent the wheel in a new way.

Grid Engine 6.1u4 Release

By Sinisa Veseli

The Grid Engine project has announced a new maintenance release (version 6.1 Update 4) of its software. This release fixes some 50+ issues found in earlier versions. In particular, couple of problems causing qmaster crashes have been resolved, and so were several dbwriter and accounting issues. More specifically, if you were wondering why your array job task usage is missing from the accounting file, you should consider installing this release. The new version of the software is available for download here.