My Photo

« April 2007 | Main | June 2007 »

May 31, 2007

University of Canterbury buys Blue Gene

My alma mater, the University of Canterbury in New Zealand, just announced that they will acquire a 4,096 CPU IBM Blue Gene (BG/L) supercomputer. This will give New Zealand a second entry in the Top 500 list, well ahead of Weta Digital. (Funnily, the local paper in Christchurch reported that they were acquiring a 130,000 CPU, 270 teraop/sec Blue Gene. That would have been something.)
I'm off to New Zealand the first week of July for the KAREN Forum in Auckland--basically an eScience conference, organized by the New Zealand advanced network organization.

May 28, 2007

Globus Training at Karlsruhe

Ruediger Berlich from the Forschungszentrum Karlsruhe comments on my article on European middleware:

[it is] worth noting that the uptake of Globus by European summer schools is quite big. These are at least partially supported by the EU.
In particular, GridKa School [September 12, Karlsruhe] will again run a comprehensive course on Globus this year, led by Jennifer Schopf and Ben Clifford.
Last year, almost 120 participants attended the school, and the Globus course was very well regarded (indeed it had the second highest rating of all courses in the school!).

The GridKA school is one of several upcoming training events in Europe and the US to feature Globus software. By all accounts, the Karlsruhe event is particularly well run 

May 25, 2007

And then there were five ...

Following my post about the four European middleware platforms, I am told about a fifth, ExtreemOS. "The XtreemOS system will offer an alternative to the Globus toolkit, which is currently the most widespread middleware system." A noble goal!

ExtreemOS will extend Linux with native (kernel-level) support for virtual organizations. I like the concept of building support for grid execution in at the lowest levels, so that every computer, whether desktop or palmtop, is ready to participate in collaborative activities. On the other hand, I am not at all sure what form that support should take--or even if we need more than is already provided in today's kernel. I would think that a working hypothesis should be that we don't need any.

Interestingly, Red Hat announced plans to integrate Condor scheduling capabilities into their Linux distribution. However, their goals are fairly narrow, focused on facilitating the use of remote computers for computation.

May 24, 2007

Grid middleware in Europe

Trips to Germany and Spain in the past month have helped me catch up the latest state of grid middleware in Europe. It's an exciting but also curious scene:

  • Tens of millions of Euros are being spent on the Enabling Grid for eScience (EGEE) grid infrastructure and its gLite middleware, and on applying that middleware in various domains and  promoting its adoption internationally. EGEE and gLite are heavily focused on the computing requirements of the Large Hadron Collider.
  • In the Nordic countries, we have the NorduGrid infrastructure and its Advanced Resource Connector (ARC) middleware. NorduGrid and ARC are also focused on physics.
  • Unicore has been developed with German and European funding over the past eight years. Unicore is focused on enabling remote access to supercomputer centers, and sees heavy use in Germany, where much of its development occurs.
  • Finally, the UK has put much money into OMII-UK, which in addition to supporting the popular myGrid and OGSA-DAI products, has created its own distinct middleware platform.

So there are at least four distinct European middleware solutions [actually five: see below]. Is this a good  thing? Officially, yes. Each is a big success, diversity is positive, and  interoperability is assured.

Unofficially, users talk with frustration about being pressured to use their funding agency's middleware, software developers bemoan the need to target different middlewares, and sites complain about having to support multiple software stacks. Meanwhile, interoperability is stymied by differing versions of standards and different configurations and policies.

The only software that no-one in Europe is pressured to use or deploy is Globus, and I am personally satisfied to see how many projects use it nonetheless. Indeed, while I cannot back up the following assertion with data (for one thing, privacy-conscious Europeans tend to turn off Globus usage reporting), I'd bet good money that Globus is the most widely used grid middleware in Europe. (That's not taking into account the Globus components included in ARC and gLite.) The people that talk to me must be somewhat self selecting, but they speak with tremendous enthusiasm about what it lets them do.

It's hard to see where this will all lead. While "made in Europe" (or "made in the Nordic countries" or "made in the UK") is a powerful rallying cry, surely four different systems can't be sustained indefinitely. Nevertheless, I don't see anything changing soon. Perhaps we can just hope for incremental steps: e.g., integrating the latest Globus components into gLite (they're using code that is several years old) and achieving interoperability between Globus and Unicore (we're on the hook for that).

It also seems strange to have no EU support for European Globus users--surely that would make good scientific sense? The reason seems to be that Globus is viewed by the EU as "US software"--even though it is all open source, and its developer and user community includes many Europeans.

ADDED LATER ON May 24: I discover that there are in fact not four but five grid middleware projects in Europe--ExtreemOS is the latest. They say: "The XtreemOS system will offer an alternative to the Globus toolkit, which is currently the most widespread middleware system." A noble goal!

May 23, 2007

Ignacio Llorente's Talk

I wrote about Ignacio Llorente's nice talk on Grid Scheduling Architectures. The talk is now available online. As well as introducing the Gridway metascheduler, he presents a taxonomy of metaschedulers, describing and giving concrete examples of a range of different architectures, such as:

  • Single metascheduler grids: one metascheduler instance with access to resources within one or several administrative domains. Examples: European Space Astronomy Center (several clusters); AstroGrid-D (22 resources, 5 sites, 800 CPUs); UABGrid (3 resources: PBS, SGE, Condor).
  • Multiple metascheduler grids: each metascheduler serving the needs of a distinct community. Example: Fusion and Biomedical users on EGEE.
  • Multiple grid infrastructures: metascheduler maps user requests to different infrastructures. Example: dispatch to OSG, EGEE, TeraGrid.
  • Multiple metascheduler layers: Hierarchical organization of multiple metaschedulers, with requests handed off to lower layers to meet peak demands. Example: offload from GRIDIMadrid to EGEE.
  • From the cluster to the Grid: Transfer queues used to offload tasks from a cluster to remote grid resources.

May 22, 2007

Opportunities to Learn about Globus

There are many good opportunities in coming months to learn about Globus technologies. Here are the events that I know about:

For up-to-date information on these and other events, see the Globus Outreach Wiki.

Please let me know of others that I have missed.

May 21, 2007

German eScience Conference

I was at the German eScience conference last week. Germany created its "D-Grid" project a couple of years ago, under the leadership of Wolfgang Gentzsch. Wolfgang is a great guy, so I expected D-Grid to do good things. My impression is that it has done very well. They are pursuing a variety of interesting application projects.Dgrid

D-Grid does not require the use of any particular software: they support Globus, gLite, and Unicore. The result is, apparently, that "11-12 of their 15 application projects are using Globus." That's the sort of endorsement I like to see.

The German eScience Conference was the first international conference at which they presented the results of this program and other related activities. It was impressive to see what they have achieved. The number of international participants was limited, which was a shame. Hopefully next year the numbers will grow. Baden Baden is a lovely place, and the conference was excellent.

I gave the latest version of my talk on "Scaling eScience Impact." I think it's an important message to deliver and I always enjoy the opportunity to present it. (Update: Video is available.)

May 17, 2007

Swift in Munich

SwiftI visited LRZ in Munich a few weeks ago. As well as meeting the excellent team there working on Globus for D-Grid and related projects, I gave a talk on our recent work with Swift. (See earlier post.) The talk includes results that my colleague Yong Zhao we will present at the IEEE Workshop on Scientific Workflows in July, and also some results on dynamic provisioning that Ioan Raicu obtained for a recent SC submission. I'm excited about how this work is going--we're running increasingly large computations for an increasing number of applications.

The abstract for the talk follows:

Continue reading "Swift in Munich" »

May 15, 2007

Gridway in Santiago de Compostela

I had the good fortune to attend the 1st Iberian Grid Infrastructure Conference this week, in beautiful Santiago de Compostela, Galicia, Spain. (Having also attended the 1st German eScience Conference two weeks before, I had to skip OGF 20 in Manchester last week.) It was an excellent meeting in every respect.

Gridway_2 The keynote today was given by Professor Ignacio Martin Llorente from the Universidad Complutense de Madrid. He gave a nice survey of scheduling strategies for distributed grid systems and also presented the GridWay metascheduler developed in his group. This Globus-based system (and dev.globus project) enables large-scale, reliable and efficient sharing of computing resources (clusters, computing farms,servers, supercomputers...), managed by different local resource management systems, such as PBS, SGE, LSF, Condor..., within a single organization or distributed across several  administrative domains.

Writing this entry, I realize that I like GridWay for five reasons:

  1. It provides powerful capabilities, including interfaces to many local resource managers, rich scheduling policies, interfaces from many schedulers (via so-called transfer queues.)
  2. It is used by many people to solve real problems--including people who are not paid to use it! (Example users: UABGrid at the University of Alabama Birmingham, AstroGrid-D in Germany, projects in China and India.)
  3. The GridWay team understands Globus deeply, and leverages Globus mechanisms to great advantage--just as the designers of those mechanisms intended.
  4. The GridWay team has embraced the dev.globus community development process.
  5. The GridWay team (like D-Grid and other brave souls) have been prepared to resist EU pressure to use only European software. Instead, they believe (correctly in my view) that we all benefit from the development and use of international software.

I also found this interesting comparison of GridWay and the EGEE workload management system, which shows GridWay in a good light. (Admittedly it was written by the GridWay team!)

Cabecera_ibergrid

May 10, 2007

Fundamentalist physics: why Dark Energy is bad for Astronomy

While visiting Alex Szalay in Munich recently, I spent some time talking with Simon White, director of the Max Planck Institute for Astrophysics. Alex later pointed me at an article that  Simon authored recently, entitled Fundamentalist physics: Why Dark Energy is bad for Astronomy. It's a fascinating commentary on the goals and cultures of two scientific communities that one the surface might appear to have much in common. The abstract:

Continue reading "Fundamentalist physics: why Dark Energy is bad for Astronomy" »

May 09, 2007

Univa Globus Cluster Edition

We've been increasingly concerned within the Globus community on creating end-user "solutions" as well as the enabling technologies that make such solutions possible. Thus I've been excited by the UCLA Campus Grid Portal and the Swift efforts, for example. Another new effort, Univa Globus Cluster Edition, looks like a significant step forward in terms of level of integration. Combining Grid Engine, Ganglia, Rocks, the Globus Toolkit, and other components, it provides a complete open source cluster management and job scheduling solution. It will be interesting to see who picks up on this.

May 04, 2007

Globus at OGF 20, May 7-11

May 7-11 is the Open Grid Forum meeting in Manchester (OGF 20). I can't be there myself, as I was already in Europe this week (speaking at the very nice 1st German eScience Conference--more about that later). However, many colleagues from around the world will be there.

In particular, the Globus team will be participating in a broad set of session. There'll be a session in the Software Forum track on Tuesday, 2pm, which will include a discussion of what's new in the core software, and more in depth information about GridWay, the latest Globus project, and OGSA-DAI's upcoming 3.0 release. There will also be some "meet the developer" times in the Exhibit Hall, so you can chat with Globus developers informally. Additional information on Globus at OGF is available online. Or, you can contact Jennifer Schopf.

May 01, 2007

Forest Observation via GT4

It seems that every day I learn about a neat new GT4-based cyberinfrastructure project that I had previously not heard of. This week, Bill St Arnaud writes about the SAFORAH forest observation system:

The Canadian SAFORAH has many objectives - of which one is to measure the 
amount of carbon dioxide absorbed by Canadian forests. This cyber-infrastructure
project also supports studies in bird habitat across Canada. It uses
Globus Toolkit v.4 at all of the SAFORAH participating sites. Currently,
four Canadian Forestry Centres located in Victoria British Columbia,
Cornerbrook Newfoundland, Edmonton, Alberta and Laurentian Québec are
operationally connected to the SAFORAH data grid.  SAFORAH offers
Grid-enabled OGC services which are used to increase interoperability of
EO data between SAFORAH and other geospatial information systems. The
Grid-enabled OGC services consist of the following main components:
Grid-enabled Web Map Service (GWMS), Grid-enabled Web Coverage Service
(GWCS), Grid-enabled Catalog Service for Web (GCSW), Grid-enabled Catalog
Service Federation (GCSF), Control Grid Service (CGS) and the Standard
Grid Service Interfaces and OGC Standard User Interfaces.

I want to learn more!