|
Hello you out there! I just started running the first serious test of the system I’ve developed during this year’s Google Summer of Code. If I wanted to put it in sensational words, the test could be called “Distribution of Particle Physics High Performance Computing Jobs among Multiple Computing Clouds”; just to get some readers In my blog post CernVM: how to set up a local ATLAS Software Release, I presented a brutal approach how to override CVMFS (CernVM‘s filesystem with HTTP backend) to install a local ATLAS Software release. Now I worked out a very clean and smooth solution. This approach allows:
During development, a system running ATLAS Software has to be tested and validated. There are some standard tests that almost don’t need any input data, stress the system and — if they run properly — are a (very) good indicator that everything is set up correctly. I talk about the so-called JobTransforms. By combining these JobTransforms, the so-called Full Chain can be run — a convenient test. In this blog post I summarize what’s behind the Full Chain and provide a shell script to easily run it. In CernVM: local ATLAS Software — the clean solution I proposed to install an ATLAS Software release to an EBS volume. I did it to make it locally available in CernVM running on EC2. The approach allows to move an EBS volume from one EC2 instance to another without losing important components and functionality. Here are some hints (both, CernVM specific and general) to follow before installing the software via pacman. One of the main features of CernVM is its special filesystem CVMFS with http backend (based on FUSE). Using CernVM in the standard way, the different experiment softwares work out-of-the-box and are made accessible over the web via CVMFS. Although this is a great feature, I like to set up an ATLAS Software release locally — as real offline version — to be independent of the software-providing webservers. While installing an ATLAS Software release from Boston University’s mirror, I discovered a broken archive file. It was the fault of a bad network card. The mirror had to be rebuilt from scratch. In the past days I tried to set up CernVM on a Nimbus cloud to get an ATLAS Software Release (local version) running. On this way some problems came up. One of them could be solved by instructing the Xen hypervisor to choose the proper Linux kernel. CernVM for Xen comes as loopback file, containing an So I had to increase the size of the image / loopback file and to extend the filesystem afterwards. Therefore I basically used |
|
|
Copyright © 2010 Jan-Philip Gehrcke 35 queries. 0.314 seconds. |
|