The OpenNebula Team is proud to announce the dawn of the OpenNebula Cloud. Although this can be shortened to ONE Cloud, it is in fact two, although both of them are accesible using two interfaces: OCCI and EC2.

• Dummy cloud. This cloud offers an interface to an OpenNebula instance configured using dummy drivers. This means that it will offer a seemingly infinite capacity to run VMs, but it actually won’t ever run any VM instance. This ‘dummy’ cloud is offered to test the OCCI and EC2 inte rfaces

• Real cloud. The OpenNebula instance that supports this clouds has access to physical server, and will offer the possibility of configure virtual networks, launching real VMs and access them using public IPs. This ‘real’ cloud VMs will have a limited capacity and is not meant to provide VMs on demand for personal uses, but rather to test OpenNebula cloud functionality.

The aim of these clouds is to allow for interface testing and foster the creation of an ecosystem built on top of OpenNebula clouds.

More information on configuration of the clients and usage of the two clouds can be found here.

Tino Vázquez

The OpenNebula Team is releasing a new plug-in to interface the ElasticHosts cloud provider, so it can be used to dynamically increase capacity of your virtualized infrastructure to meet fluctuating or peak demands. This can happen when the local fabric runs out of capacity to spawn a new virtual machine, therefore it may be interesting to add capacity using cloud providers.

ElasticHosts offers KVM based virtualized hosts in a cloud like fashion, i.e., à la Amazon EC2, using a very neat RESTful API. Uploading images (drives, in ElasticHosts speak) previously configured with the service that needs to meet a increased demand would allow the cloudbursting described above through OpenNebula.

Information on how to download and install the ElasticHosts plug-in can be found in the OpenNebula Trac.

Tino Vazquez

Since version 4.2.0 of the Globus Toolkit (GT), grid infrastructure administrators are posed with a dilemma whether or not to upgrade. The problem comes from the fact that versions 4.0.x and 4.2.x of the GT are incompatible, meaning that clients of one version cannot access servers of the other and vice-versa.

GridWay can interface both pre Web Services and Web Services versions of the Globus Toolkit for quite a while now, but it is not clear how to make GridWay work with the two available 4.x.x versions. If possible, this will enable the use of GridWay to encapsulate both versions and thus offer a common point of entry to both containers. Presumably, this will aid in making a smooth transition between Globus Toolkit versions.

Here is a recipe that enables GridWay to use Middleware Access Drivers (MADs) compiled for both versions of the GT, which need to be compiled and installed (not necessarily running) in the GridWay server.

1. GridWay needs to be compiled (./configure && make) against one of the available GT versions, lets say the GT4.0.x (make sure GLOBUS_LOCATION points to the GT4.0.x install).
2. Get hold of the generated jars for the EM MAD and the IM MAD, there is no need to issue the “make install” command, just grab
   • src/im_mad/gw_im_mad_ws.jar
   • src/em_mad/gw_em_mad_ws.jar

   and rename them to reflect the GT version, something like

   • gw_im_mad_ws.4.0.4.jar
   • gw_em_mad_ws.4.0.4.jar
3. Change the GLOBUS_LOCATION to the GT4.2.x install and recompile gridway against it. Now you can go the whole way (./configure && make && make install).
4. Copy the two previously generated jars to the new gridway install lib folder ($GW_LOCATIONM/lib)
5. Copy both EM and IM MAD wrappers, changing the name accordingly:
   • cp $GW_LOCATION/bin/gw_im_mad_mds4_thr $GW_LOCATION/bin/gw_im_mad_mds4_thr_4.0.4
   • cp $GW_LOCATION/bin/gw_em_mad_ws $GW_LOCATION/bin/gw_em_mad_ws_4.0.4
6. Edit the newly copied wrappers and insert the following two lines at the beginning, right after the shebang
   • unset CLASSPATH
   • export GLOBUS_LOCATION=<path-to-the-GT4.0.4-install>

   Also, change the two references to gw_em_mad_ws.jar and gw_im_mad_ws.jar to the renamed versions (in this case, gw_em_mad_ws.4.0.4.jar and gw_im_mad_ws.4.0.4.jar respectively)
   Remember that when running GridWay, GLOBUS_LOCATION should now point to GT4.2.0 in this case, since now GridWay 4.0.4 MADs know where to find the GT4.0.4 install.

7. Now that everything is set up, the last step is to configure GridWay to access each resources with the appropriate MAD. TM_MAD can be the same for both GT4.0.x and GT4.2.x, since gridftp is compatible across these GT versions. So, in this case:
   for GT4.0 hosts 
   • IM_MAD = mds4_42:gw_im_mad_mds4_thr_42:-s <GT4.0.x hostname>:gridftp:ws_42
   • EM_MAD = ws_42:gw_em_mad_ws_42::rsl2

   for GT4.2 hosts

   • IM_MAD = mds4:gw_im_mad_mds4_thr:-s <GT4.2.x hostname>:gridftp:ws
   • EM_MAD = ws:gw_em_mad_ws::rsl2

And that should do the trick. If you bump into any problems, write us a line.

Tino Vazquez

The OGF-23 took place in Barcelona last week, hosted by the Barcelona Supercomputing Center. Simultaneously and at the same location, the BEinGRID Industry Days were held. The main purpose of this event was to review the first wave of business experiments. dsa-research is involved in BE14, one of the experiements of the first wave. We had a demonstration presented by people from the BSC and from the University of Surrey, both partners in this experiment. The demonstration showed a portal hiding the complexity of and offering access to GridAD, born out of the union GridWay and Grid Superscalar using DRMAA.

Even more interesting was the final review of the experiment, were David Linke from Linkat (our business partner) explained the results of the experiment under the point of view of the end user, and also presented the desgined explotation plan. The results were even better than what I was expecting. Simplifying it, the objective was to open new process development in the field of the chemical industry by cutting down the simulation time needed by the software created by the University of Surrey. This software simulates a chemical process in order to find the optimum set up. Because the process relies on independent simulations, it is embarrassing parallelizable. The numbers in David’s presentation showed a mind blogging cut down from 55 hours to only 7 hours for one complete optimization. And, to top it all, this new solution was able to discover a new process to produce acetic acid more efficiently than what is being used in the real industry!. This is really a good indicator of the experiment success, no major discoveries were made in the production of this acid for the last 10 years.

So the experiment is over, and here at dsa-research are quite pleased of the excellent third position it achieved (out of 18).

In the BEinGRID context, and in collaboration with the Barcelona Supercomputing Center, we (and by we, I mean the dsa-rearch.org group) have integrated GridWay and Grid Superscalar (GRIDs) using DRMAA, creating GridAD.

With the goal of promoting the adoption of the grid technologies from the business and enterprise, BEinGRID EU project is organized as a set of pilots with partners with complementary roles, from end users to technology providers. The expected output is a set of business reference cases leading towards the business exploitation of the grid. The dsa-research.org group is involved in Bussiness Experiment 14,  which can be described as:

 This experiment addresses the integrated environment required to develop new products and processes in the chemistry sector. This implies the parallel execution and coordination of multiple heterogeneous and widely distributed resources (databases,computer models, property and cost data,technical reports,and images) achieved by the combination of two outstanding Grid tools.

The combination of such tools is what we call GridAD, and it surely benefits from its components. From GRIDs takes the ability to be able to write gridified applications in a really easy way, by just defining which functions we want to execute remotely on an IDL file. GRIDs then automatically generates the necessary code and in run-time it uses techniques to assure an optimal use of data locality. From GridWay it takes the fault tolerance mechanisms, the ability to dynamically deploy the application, the ability to interoperate with different middlewares (EGEE, TeraGrid, Open Science Grid ,etc) and the resource provisioning among others.

Also, there are benefits for their separated components. We can see this in the use of DRMAA for the components communication, how it benefits GRIDs since now it can be plugged to traditional DRMS and run the application on a local cluster or it can be plugged to GridWay and run it on a Grid infrastructure.

Tino Vázquez