FG Cloud challenge: using theSlipStreamTM multi-cloud solution tofederate French Cloud infrastructures

Documentation for SlipStream v2.9

July 9, 2015

1

Contents1 Goal of the challenge 3

1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Introduction to SlipStream 52.1 SlipStream account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Registration of Cloud credentials and ssh keys . . . . . . . . . . . . . . . . 5

3 Use case: running a VM on each infrastructures 63.1 End-user client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 StratusLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.2 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.3 OpenNebula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Connecting VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Obtaining information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 More advanced use case: running a Torque Cluster 94.1 Torque master image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Torque worker image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Torque deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3.1 StratusLab end-user client . . . . . . . . . . . . . . . . . . . . . . . 104.3.2 Connecting VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.4 Testing the cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4.1 Worker nodes status . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4.2 Basic job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.5 Obtaining information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 General use case: running an application for the Cloud Challenge 13

2

1 Goal of the challengeIn the framework of France Grilles (FG)1, the French Cloud Federation offers a Cloud

challenge to FG users. The French actors of academic Cloud computing are grouped in aFederation2 [1] in order to offer Cloud services to user. Several sites provide Infrastructure-as-a-Service (IaaS) based on open source Cloud solutions such as StratusLab, Open-Stack and OpenNebula with specific resources as shown in Fig. 1.

Figure 1: Map of the French Federation of academic Clouds. Production sites already offer stable Cloud infrastructures.

For more information on Cloud computing, see tutorials3.

1.1 Requirements

Users who would like to participate to the Cloud challenge need first to have theirprojects accepted by the French Cloud Federation. Secondly, in order to realise thechallenge, users need to obtain credentials from the organisers before registering to theSlipStream service. The general Cloud account will allow the connexion to each of theCloud infrastructures.

1.2 Resources

Physical resources allowed for the Cloud challenge are geographically localised in foursites as described in Tab. 1. Users can find a description of each Cloud (end-user clientand ressources) in the corresponding Web page (see Documentation section in Tab. 1).

1France Grilles: http://www.france-grilles.fr2French Cloud Federation: http://www.france-grilles.fr/6-Cloud3StratusLab tutorial: http://stratuslab.readthedocs.org/en/latest/user-tutorial/index.

html; OpenStack tutorial: http://docs.openstack.org/user-guide/content/; General tutorial:https://www.apc.univ-paris7.fr/FACeWiki/pmwiki.php?n=Cloud.Cloud

3

Plateform Stratuslab@LAL OpenStack OpenStack@IPHC CloudMIP@IRIT@CC-IN2P3

Provider/ IN2P3/LAL, IN2P3/CC, IN2P3/IPHC, IRIT,partner Orsay Lyon Strasbourg Toulouse

Technology Stratuslab OpenStack OpenStack OpenNebulaCPU 416 400 160 256

Memory 636 GB 512 GB 1 TBStorage 10 TB 32 TB 5 TB 15 TB

Inter-connexion 1 GbE/s 1 GbE/s 400 MbE/snetwork (10 GbE/s soon)

Documentation Wiki4 Wiki5 Wiki6 Wiki7

Table 1: Resources of the four sites allowed for the Cloud challenge.3Stratuslab@LAL: http://stratuslab.eu; 4OpenStack@CC-IN2P3: https://ccwiki.in2p3.fr/infrastructure:cloud:start; 5OpenStack@IPHC: http://www.grand-est.fr/index.php/support/documentation; 6CloudMIP@IRIT: http://cloudmip.univ-tlse3.fr

Users will have the possibility to run Virtual Machines (VMs) by using the SlipStreamTM

multi-cloud solution (see Sec. 2). Several examples of use-case of SlipStreamTM will beshown in Sec. 3 and 4.

4

2 Introduction to SlipStream

Figure 2: SlipStreamTM connectors.

The SlipStreamTM solution8 allows to automatically deploy environnement on VMs.This open source software provides the ability to connect to several Cloud solutions (seeFig. 2) as an Plateform-as-a-Service (PaaS) Cloud model.With the help of the Web interface, users just need to:

• create an SlipStreamTM account.

• register Cloud credentials and ssh keys.

• run VM or deployment of VMs.

• access by ssh to VMs.

The official documentation of SlipStreamTM describing in detail these different steps andseveral examples can be found in .

2.1 SlipStream account

The SlipStreamTM server for the Challenge Cloud can be accessed at:https://slipstream.lal.in2p3.fr.On the Web interface, users can ask an account in Pick a username and Enter your emailfields.

Once users are connected to their SlipStreamTM account, they can access to projectsin and dashboard in (see Fig. 3). The project section contains examples ofimage and deployment. The dashboard part is a list of all running machines/deploymentson each Cloud platforms.

2.2 Registration of Cloud credentials and ssh keys

Before to run VMs, users need to fill their information in . For each infras-tructures, users have to give their Cloud credentials (the general Cloud account aslogin/password) by using . In the general section, users have to copy the publicpart of their ssh keys in order to connect later on VMs.

8SlipStreamTM: http://sixsq.com/products/slipstream.html

5

Figure 3: SlipStreamTM Web interface.

3 Use case: running a VM on each infrastructures

In the /Projects section of the SlipStream interface, users can find in the directoryexamples/images two base images to run (Ubuntu and CentOS, also reachable from

/App Store section). Choose one and launch it with . A message will ask you toselect which Cloud to run the image on. Choose the first infrastructure and run the VM.This step will redirect you to a page showing the running VM with information like IPaddress as shown in Fig. 4. You can do the same process for each Cloud infrastructures(LAL, CC-IN2P3/IPHC, IRIT).

3.1 End-user client

If you have installed the command-line clients corresponding to the three Cloud solu-tions (StratusLab, OpenStack and OpenNebula), you can see from a terminal the runningVM on each Clouds.

3.1.1 StratusLab

$ stratus-describe-instanceid state vcpu memory cpu% host/ip nameid Running 2 6291456 0 onevm-xxx.lal.in2p3.fr machine:ss_id

3.1.2 OpenStack

$ nova list+-----+---------------+--------+------------+-------------+------------------------+| ID | Name | Status | Task State | Power State | Networks |+-----+---------------+--------+------------+-------------+------------------------+| id | machine:ss_id | ACTIVE | - | Running | lap=172.17.5.x, || | | | | | 134.158.246.xxx |

6

Figure 4: SlipStreamTM Web interface: example of running VM.

3.1.3 OpenNebula

$ onevm listID USER GROUP NAME STAT UCPU UMEM HOST TIME IPv4id user users machine:ss_id runn 0 2G wn1 0d 00h00 172.28.112.xxx (vm-xxx)

3.2 Connecting VM

After few minutes, VM is ready to use. To access it, you can connect to the VM froma terminal or directly from the SlipStream interface (ssh://root@134.158.75.xxx in theMachine section, see below). In both cases, the ssh connexion is as root user:

$ ssh root@134.158.75.xxx

If your ssh keys are well registered in the user section of SlipStream, everything will be fine.

3.3 Obtaining information

On the VM, an important file is the SlipStreamTM log:

root@onevm-xxx $ cat /tmp/slipstream/reports/machine.slipstream.log

This file can be also directly accessed from the interface in the Reports section. Whenusers will use recipe scripts as in the Torque Cluster application (see below), the log filewill be useful to debug script problems.

Another interesting information is given in the Machine section of the Web interface(see Fig. 5). Users can find some parameters associated with values like the IP addressof the machine (machine:hostname=134.158.75.xxx). This information can be use in

7

recipe script of other machines as we will see in the Torque application.

Figure 5: SlipStreamTM Web interface: parameters of running VM.

To terminate the VM, press .

8

4 More advanced use case: running a Torque ClusterTo understand all the possibilities of the SlipStreamTM tool, a more advanced use case

is presented here. The goal of this example is to launch a Torque Cluster9 on severalnodes managed by SlipStreamTM. The Torque Cluster is compound of one master andseveral workers and the nodes are interacting by Torque services (torque-server andtorque-sched on master, torque-mom on workers and munge on all nodes). The nodescan exchange information to setup the Cluster with the help of an orchestrator and specificenvironment variables.In the section of the SlipStream interface and in the examples/tutorials/torquedirectory, users can find all the components of the Torque project.

4.1 Torque master image

The Torque master image (examples/tutorials/torque/torque-master) is alreadysetup and users just need to have a look of the components. The image is a base Ubuntuwhich will be customised during the boot of the VM. The customisation is based on arecipe (script) containing installation packages and configuration files. The SlipStreaminterface shows the following fields:

• Cloud Image Identifiers and Image Hierarchy: Ubuntu.

• Cloud Configuration:

– Cloud: volatil disk (in GB), network type (public/private).

– Infrastructures: flavor (m1.smal...) or CPU/RAM (in GB), disks bus type(virtio/scsi), security.

• Image Creation Recipes: use only to customise disk images (different from de-ployment recipes).

• Deployment Recipes and Coordination Parameters:

– Execute: script shell.

#!/bin/bash -x

## ==========# Following section could be put into image recipe for those# clouds that support image creation.# ==========#

# install prerequisitesapt-get cleanapt-get updateapt-get -y install munge torque-scheduler torque-server python-pip...

– Parameters: parameters that can be exchanged between the nodes.

hostname | hostname/ip of the image | Output...

9Torque Cluster: http://www.adaptivecomputing.com/products/open-source/torque/

9

The main ingredients of the deployment are the deployment recipe and the coordina-tion parameters. The parameters are environment variables that will be transferred toother nodes (if the category is output). In the Torque master, the parameters are:

• instanceid (mandatory): ID on the Cloud infrastructure.

• hostname (mandatory): IP (134.158.75.xxx or another).

• master_hostname: full name (onevm-xxx.lal.in2p3.fr or another).

• user_id_rsa64: ssh private key with encoding.

• munge_key64: munge key with encoding.

In the recipe script, these variables are managed by the SlipStream’s commands (ss-*).As an example, to use the ss-get command allowing to take back the hostname of themaster:

ss-get --timeout 480 master.1:hostname

As an other example, to use the ss-set command allowing to send the munge key to theother nodes:

ss-set munge_key64 ‘cat /etc/munge/munge.key | base64 --wrap 0‘

4.2 Torque worker image

The Torque worker image (examples/tutorials/torque/torque-worker) is similarto the Torque master one. Differences reside in the deployment recipe and parameters.As an example, to use the ss-get command allowing to take back the munge key of themaster:

ss-get --timeout 480 master.1:munge_key64

4.3 Torque deployment

In the examples/tutorials/torque/torque directory, the two previous images arereferenced with their respective paths (examples/tutorials/torque/torque-*).Choose the first infrastructure and run the Cluster from the SlipStreamTM interface. Thisstep will redirect you to a page showing the running Cluster as shown in Fig. 6

As previously, user can see the nodes of the Cluster with the end-user client from aterminal.

4.3.1 StratusLab end-user client

id1 Running 4 8388608 11 onevm-xxx.lal.in2p3.fr worker.2:ss_id1id2 Running 4 8388608 14 onevm-xxx.lal.in2p3.fr worker.1:ss_id2id3 Running 2 6291456 14 onevm-xxx.lal.in2p3.fr master.1:ss_id3

4.3.2 Connecting VM

After few minutes, the virtual Cluster is ready to use. To access it, you need to usessh connexion from a terminal as tuser on master:

$ ssh tuser@134.158.75.xxx

The general user tuser (automatically created) is useful to test the Torque Cluster.

10

Figure 6: SlipStreamTM Web interface: example of a Torque deployment on a virtual Cluster of one master node and

two worker nodes.

4.4 Testing the cluster

With few commands users can test if the Torque Cluster is properly working.

4.4.1 Worker nodes status

The pbsnodes command gives the status of the worker nodes and other informationsuch as the number of CPU.

$ pbsnodes -aonevm-1.lal.in2p3.fr

state = freenp = 1ntype = clusterstatus = rectime=1384596949,varattr=,jobs=...

onevm-2.lal.in2p3.frstate = freenp = 1ntype = clusterstatus = rectime=1384596950,varattr=,jobs=...

4.4.2 Basic job

Users can run a basic job with the qsub command and check the state of the job withthe qtstat one.

$ echo "sleep 30" | qsub$ qstat -an

11

onevm-0.lal.in2p3.fr:Req’d Req’d Elap

Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time--------------- -------- -------- ---------- ------ ----- --- ------ ----- - -----1.onevm-0.lal tuser batch STDIN 25306 1 1 -- 01:00 R --

onevm-1

4.5 Obtaining information

As previously, the Web interface gives interesting information such as the parametersdefined in the Torque images in the Master.1 section and Worker.1 section (see Fig. 7).

Figure 7: SlipStreamTM Web interface: parameters of running worker.

To terminate the Cluster, press .

12

5 General use case: running an application for theCloud Challenge

In general, to use SlipStream solution, users have to:

• create master and worker images based on:

– example based image (CentOS or Ubuntu).

– user image coming from a catalog (MarketPlace, Glance catalog image or Open-Nebula one) and referenced in SlipStream (use and Cloud ImageIdentifiers and Image Hierarchy to give the corresponding catalog identi-fier).

• write recipes for both images (see examples in the master/worker image of theTorque cluster).

– install packages (system and scientific ones).

– install softwares (if not present in the image).

– configure services.

– use SlipStream’s environment variables.

• set SlipStream’s environment variables to export.

• create deployment based on previous images.

• run the deployment

• connect by ssh to the VM/cluster and run your application.

References[1] Airaj et al., hal-00927506 (2013)

13