Virtual Workspaces

  Home
  Overview
  Features
  Documentation   
  Downloads
  Publications
  Clouds
  Marketplace
  Deployments
  Contributors
  Roadmap
  Funding
  Contact
  News
  

Science Clouds

Science Clouds deliver compute cycles in the cloud for scientific communities using software provided by the workspace tools. The simple workspace cloud client allows you to provision customized compute nodes (that we call "workspaces") that you have full control over using a leasing model similar to Amazon's EC2 service. The objective of science clouds is to make it easy for scientific and educational projects to experiment with this mode of resource provisioning. We want to learn how you would like to use a cloud of this type, whether there are features or usage modalities that you would like us to provide and what would make this service appealing to your application or community. If you use any of these clouds, and have requests, comments, or suggestions please send them to us at workspace-user@globus.org. We will very much appreciate your feedback.

In a typical session you will make a request to deploy a workspace based on a specified VM image. You can either use one of the VM images already available on a cloud (the workspace cloud client provides a command that allows you to see what's already there) or upload your own VM image. On deployment, the image will be configured with an ssh public key you provide -- in this way once the workspace is deployed, you will be able to ssh into it and configure it further, upload data, or run your applications. Specific instructions are available below. Have fun!

Warning: Science clouds are a beta project deployed on a modest allocation of resources. Over the next few months we will be evolving the software in response to your requests and comments. Therefore, be aware that the client code may change frequently as new features, services and clouds become available. Each change will be announced on workspace-user@globus.org -- please subscribe (see "contact" tab on the left) and keep an eye on those announcements to ensure that your client is up-to-date.

Available Science Clouds:

To obtain access to a cloud, please contact the administrators of the clouds below.

To use the science clouds you will need to use the workspace cloud client. Some clouds may also require you to use of virtual private networks. Read cloud configuration notes carefully to ensure that you end up with the right software and configuration.

Workspace Cloud Client Instructions

Install the cloud client

In order to install the client you will need to have Java (1.4+) installed on your system and you will need a vaild grid credential.

Download the latest workspace cloud client (15M), untar the file, and change to the cloud client directory.

Congratulations -- you are now the happy owner of a brand new cloud client! From now on you should cry for help in the following idiom:

$ ./bin/cloud-client.sh --help

Make sure to subscribe to workspace-user@globus.org (see the contact page for instruction on how to subscribe) to hear about client version updates.

Configure and prepare for deployment

First, create a proxy credential. To do that you can use the Globus libraries embedded in the nimbus client distribution, like so:

$ source lib/this-globus-environment.sh
$ grid-proxy-init

Test the security setup:

$ ./bin/cloud-client.sh --security

Issues? See the help resources for help.

If you have not yet given your DN to the cloud administrators, this would be a good time to do so -- just send the distinguished name printed after 'Identity:' in the output of the ./bin/cloud-client.sh --security command.

Some clouds require the use of virtual private networks. Check the configuration notes for the cloud you want to use and if private networks are required first follow the VPN installation steps.

Finally, configure the cloud client. If the default client configuration answers your needs you are done with the installation step. To decide take a look at the conf/cloud.properties file. The options are as follows:

  • You can point the client at the cloud you will be using by defining the workspace factory and image node (obtained them from the cloud administrator).
  • You can set up the location of the ssh public key that you want to put on the workspace
If you do nothing (a highly recommended and vastly undervalued course of action) these things will be picked up from default locations specified in the file (among others, you will try connecting to Nimbus). Otherwise, see the configuration notes for the cloud you want to use and download the configuration file associated with that cloud. Should you change your mind about the configuration options you can overried these properties by commandline flags (listed by calling the client with the --extrahelp option).

Prepare a virtual machine image to deploy

In order to deploy a workspace with custom configuration you need to upload a VM image to the cloud. To make it easy for you we already uploaded some images to the Nimbus that you can use. You can find more detailed descriptions of those image at the workspace marketplace. To see what is available list the images as follows:

$ ./bin/cloud-client.sh --list

If you are feeling adventurous you could also create an image yourself and upload them to the cloud. The image must conform in this manner:
  • The IP address is obtained via DHCP broadcast at boot
  • The ext2/ext3 partition file that is mounted to /dev/sda1
  • The image runs SSHd after boot so that you can login and adapt the image to your needs. Your SSH key will be written to /root/.ssh/authorized_keys on the VM before it is booted (see client configuration instructions above for how to pick which key this is).
To transfer an image use the --transfer option of the client. Images are named by their filenames. For example, to transfer an image called "helloworld" located in the "/tmp" directory on local resource run the following command:

$ ./bin/cloud-client.sh --transfer --sourcefile /tmp/helloworld

Deploy a workspace

To run a workspace use the --run option of the client. There are two required run options: (1) --name defines the name of an image and (2) --hours specifies the number of hours for which the image will be deployed. For example, if you want to run the image called "helloworld" for 1 hour, run the following command:

$ ./bin/cloud-client.sh --run --name helloworld --hours 1

If you want to transfer the image to the cloud and run using one command, you don't have to specify the 'name' argument explicitly; the image name will be deduced from the sourcefile argument. Eg., the command below transfers and runs helloworld:

$ ./bin/cloud-client.sh --transfer --sourcefile /tmp/helloworld --run --hours 1

(The order of commandline flags does not matter, the client will do the sensible thing.) If successful, the run command should produce roughly this output: 

SSH public keyfile contained tilde:
  - '~/.ssh/id_rsa.pub' --> '/home/guest/.ssh/id_rsa.pub'

Launching workspace.

Using workspace factory endpoint:
    https://cloudurl.edu:8443/wsrf/services/WorkspaceFactoryService

Creating workspace "vm-023"... done.

       IP address: 123.123.123.123
         Hostname: ahostname.cloudurl.edu
       Start time: Fri Feb 29 09:36:39 CST 2008
    Shutdown time: Fri Feb 29 10:36:39 CST 2008
 Termination time: Fri Feb 29 10:46:39 CST 2008

Waiting for updates.

State changed: Running

Running: 'vm-023'

The output prints out the endpoint information of the workspace factory associated with the cloud you are using followed by information about the deployed workspace. This information includes: the name you will use to terminate the workspace, the instantiation/termination times, and the contact information for the workspace. The latter contains the network address for the workspace which you will need in order to log in.

Interact with a workspace

Recall that your public key has been configured in the conf/cloud.properties file. On workspace deployment the public key file was installed to /root/.ssh/authorized_keys on the VM image, so that after the workspace boots you should be able to log in by typing:

$ ssh root@ahostname.cloudurl.edu

Make sure that you log in to the root account -- that's the only one that gets set up with the key. You can create and configure other accounts once you log in.

Enjoy! And may we ask that you send us a postcard (workspace-user@globus.org).

Querying a workspace

Should you ever find yourself somewhat out of touch with your workspace there is an easy way to reestablish relations:

$ ./bin/cloud-client.sh --status --handle vm-023

If you don't recall what the name of the workspace you ran was, there are running logs of each run kept in the "history" directory. The highest numbered subdirectory name in the history directory is probably a good guess.

Saving workspace changes

You can save a template image's changes after use, this command will shutdown the workspace and send the altered file back to your personal repository directory.

$ ./bin/cloud-client.sh --save --handle vm-023 --newname custom-1

Note that without the "--newname" parameter this will overwrite the source file. If you do not have permissions to overwrite the source file (for example, you are using the pre-populated template images that are provided), you must use the "--newname" parameter. Failing to do so will cause a permissions error and you will lose the changes on that run. If you uploaded the image personally, you will have the permissions to overwrite the source file (ability to use the "--save" option without also using "--newname").

As explained in the query section above, if you do not know the name of the workspace you ran, have a look in the history directory.

Terminate a workspace

All good things come to an end. So it is with workspaces which come to an end in the following way:

$ ./bin/cloud-client.sh --terminate --handle vm-023

As explained in the query section above, if you do not know the name of the workspace you ran, have a look in the history directory.

Help resources

For help with security issues, run grid-proxy-init -help and/or mail us at workspace-user@globus.org (see the contact page).

A commonly encountered problem:grid-proxy-init cannot find your credential's CA files? Try running this before running grid-proxy-init:

$ export X509_CERT_DIR="/path/to/certificates_directory"