Difference: NEP52RPIDocument (1 vs. 36)

Revision 362014-02-12 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
Changed:
<
<

NEP52 Batch Services

>
>

NEP52 Cloud Computing Batch Service

 

Overview

Changed:
<
<
If you already are familiar with batch computing and just want to get to running your jobs on VMs skip to the Cloud Scheduler Test Drive Section below.
>
>
If you already are familiar with batch computing and just want to get to running your jobs on VMs skip to the CloudScheduler Test Drive Section below.
 
Changed:
<
<
Cloud Scheduler is a tool which will spawn Virtual Machine (VMs) on Infrastructure-as-a-Service (IaaS) clouds in order to run batch computing jobs. With Cloud Scheduler you clone a VM or provide and existing VM batch worker node image and point your HT Condor batch jobs to that image; cloud scheduler handles the rest. For people already familiar with classic batch computing the process will be very familiar.
>
>
Cloud Computing Batch Service provides the CloudScheduler tool which will manage Virtual Machine (VMs) on Infrastructure-as-a-Service (IaaS) clouds in order to run batch computing jobs. With CloudScheduler, you prepare batch jobs by selecting VM images, applications, data and parameters needed to process your workload, and then submit these selections to an HTCondor batch queue. CloudScheduler automatically starts the VMs, required to process your jobs in the HTCondor batch queue, on any of the available clouds. For people already familiar with classic batch computing, the process will be very familiar.
  Here's how it should work for the user Jane's perspective:
Line: 30 to 31
  You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following examples will allow you to test drive this functionality quickly. In summary:
Changed:
<
<
  • "Running your first batch job" will have you launch an instance of the Cloud Scheduler image (NEP52-cloud-scheduler), configure and start Cloud Scheduler, and submit a batch job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output. At the end of the job, when there are no more jobs in the queue, Cloud Scheduler will automatically remove idle batch VMs.
  • " Running a batch job which uses the Shared Software Repository service" will have you launch an instance of the CVMFS server image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
>
>
  • "Running your first batch job" will have you launch an instance of the CloudScheduler image (NEP52-cloud-scheduler), configure and start CloudScheduler, and submit a batch job. The batch job will trigger CloudScheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output. At the end of the job, when there are no more jobs in the queue, CloudScheduler will automatically remove idle batch VMs.
  • " Running a batch job which uses the SharedSoftware Repository service" will have you launch an instance of the CVMFS server image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
 
Changed:
<
<
In order to try the Cloud Scheduler Test Drive, you will need the following:
>
>
In order to try the CloudScheduler Test Drive, you will need the following:
 
  • A DAIR login ID with a large enough quota to run the three concurrent demonstration instances. If you do not have a DAIR login ID, you may request an account by sending email to dair.admin@canarie.ca
  • To create your own keypair and save the pem file locally (see the Openstack dashboard/documentation).
Line: 48 to 49
 

Running your first batch job

Changed:
<
<
Step 1: Log into DAIR and boot a Cloud Scheduler instance
>
>
Step 1: Log into DAIR and boot a CloudScheduler instance
  Login into the DAIR OpenStack Dashboard: https://nova-ab.dair-atir.canarie.ca . Select the alberta region. Refer to the OpenStack docs for all the details of booting and managing VMs via the dashboard.
Line: 67 to 68
 
Changed:
<
<
Step 2: Log into the Cloud Scheduler instance and configure it
>
>
Step 2: Log into the CloudScheduler instance and configure it
 
Changed:
<
<
Now associate a floating IP to the machine. Click on the instances tab on the left. From the "Actions" beside your newly started Cloud Scheduler instance, choose "Associate Floating IP", complete the dialog and click "Associate".
>
>
Now associate a floating IP to the machine. Click on the instances tab on the left. From the "Actions" beside your newly started CloudScheduler instance, choose "Associate Floating IP", complete the dialog and click "Associate".
  Now ssh into the box as root (you can find the IP of the machine from the dashboard):
Line: 77 to 78
 ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 %ENDCONSOLE%
Changed:
<
<
Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically "{keypair_name}", "{EC2_ACCESS_KEY}", and "{EC2_SECRET_KEY}", for both the Alberta and Quebec DAIR clouds. Then start the Cloud Scheduler service:
>
>
Use your favourite editor (ie. nano, vi, or vim) to edit the CloudScheduler configuration file to contain your DAIR EC2 credentials, specifically "{keypair_name}", "{EC2_ACCESS_KEY}", and "{EC2_SECRET_KEY}", for both the Alberta and Quebec DAIR clouds. Then start the CloudScheduler service:
  %STARTCONSOLE% vi /etc/cloudscheduler/cloud_resources.conf service cloud_scheduler start %ENDCONSOLE%
Changed:
<
<
If you don't have your credentials follow this video to see how to do it. Your credentials will be used by Cloud Scheduler to boot VMs on your behalf.
>
>
If you don't have your credentials follow this video to see how to do it. Your credentials will be used by CloudScheduler to boot VMs on your behalf.
 
Line: 115 to 116
  Step 1:
Changed:
<
<
Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username). It is always a good idea to assign the instance your keypair so that you can log into it if the need arises.
>
>
Using the OpenStack dashboard and the same launch procedure as for the CloudScheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username). It is always a good idea to assign the instance your keypair so that you can log into it if the need arises.
  Step 2:
Changed:
<
<
If you are not already logged into the Cloud Scheduler VM, login and switch to the guest account:
>
>
If you are not already logged into the CloudScheduler VM, login and switch to the guest account:
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80
Line: 179 to 180
 

Take snapshots of your customized images

Changed:
<
<
If you followed all the steps above you have a customized version the Cloud Scheduler appliance running. You can now use the OpenStack dashboard to snapshot this server to save yourself the work of customizing it again.
>
>
If you followed all the steps above you have a customized version the CloudScheduler appliance running. You can now use the OpenStack dashboard to snapshot this server to save yourself the work of customizing it again.
 

Using the Batch Service VMs on private clouds

Revision 352013-09-11 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 35 to 35
  In order to try the Cloud Scheduler Test Drive, you will need the following:
Changed:
<
<
  • A DAIR login ID with a large enough quota to run the three concurrent demonstration instances.
>
>
  • A DAIR login ID with a large enough quota to run the three concurrent demonstration instances. If you do not have a DAIR login ID, you may request an account by sending email to dair.admin@canarie.ca
 
  • To create your own keypair and save the pem file locally (see the Openstack dashboard/documentation).
  • To retrieve your EC2_ACCESS_KEY and EC2_SECRET_KEY from the Openstack dashboard.
Line: 182 to 182
 If you followed all the steps above you have a customized version the Cloud Scheduler appliance running. You can now use the OpenStack dashboard to snapshot this server to save yourself the work of customizing it again.

Added:
>
>

Using the Batch Service VMs on private clouds

If you would like to use the Batch Services virtual machines on your own private cloud, you may retrieve the VM images from the DAIR repository for installation in your cloud's repository. DAIR is an OpenStack cloud with the Glance image repository. Assuming your private cloud is also an OpenStack cloud with a Glance repository, the process for copying the image from DAIR to your own repository would be:

  • On a convenient workstation:
    • Install the glance client (eg. yum install python-glanceclient, apt-get install python-glanceclient, etc.).
    • Log into the DAIR cloud and download the RC file (ie. Settings->!OpenStack API->Download RC File).
    • Source the DAIR RC file (eg. source openrc-alberta.sh).
    • Download the image to your workstation, eg:
      • glance image-list
      • glance image-download --file {image-name-on-workstation} {image-ID-from-list-on-DAIR}
    • Log into your private cloud and download the RC file (ie. Settings->!OpenStack API->Download RC File).
    • Source your cloud's RC file (eg. source openrc-yourcloud.sh).
    • Upload the image to your private cloud, eg:
      • glance image-create --file {image-name-on-workstation} --name {image-name-on-your-cloud} --disk-format qcow2 --container-format bare
 
META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369770075" name="select_key.png" path="select_key.png" size="24128" user="crlb" version="2"

Revision 342013-09-09 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 95 to 95
 %STARTCONSOLE% su - guest condor_submit demo-1.job
Changed:
<
<
cloud_status -m condor_q watch 'cloud_status -m; condor_q'
>
>
watch 'cloud_status -m; condor_status; condor_q'
 %ENDCONSOLE%

When the job completes, it disappears from the queue. The primary output for the job will be contained in the file 'demo-1.out', errors will be reported in 'demo-1.err', and the HTCondor job log is saved in 'demo-1.log'. All these file names are user defined in the job description file 'demo-1.job'.

Revision 332013-09-05 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 74 to 74
 Now ssh into the box as root (you can find the IP of the machine from the dashboard):

%STARTCONSOLE%

Changed:
<
<
ssh -i ~/.ssh/MyKey.pem root@208.75.74.18
>
>
ssh -i ~/.ssh/MyKey.pem root@208.75.74.80
 %ENDCONSOLE%

Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically "{keypair_name}", "{EC2_ACCESS_KEY}", and "{EC2_SECRET_KEY}", for both the Alberta and Quebec DAIR clouds. Then start the Cloud Scheduler service:

Line: 124 to 124
 If you are not already logged into the Cloud Scheduler VM, login and switch to the guest account:

%STARTCONSOLE%

Changed:
<
<
ssh -i ~/.ssh/MyKey.pem root@208.75.74.18
>
>
ssh -i ~/.ssh/MyKey.pem root@208.75.74.80
 su - guest %ENDCONSOLE%

Revision 322013-09-05 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 31 to 31
 You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following examples will allow you to test drive this functionality quickly. In summary:

  • "Running your first batch job" will have you launch an instance of the Cloud Scheduler image (NEP52-cloud-scheduler), configure and start Cloud Scheduler, and submit a batch job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output. At the end of the job, when there are no more jobs in the queue, Cloud Scheduler will automatically remove idle batch VMs.
Changed:
<
<
  • " Running a batch job which uses CVMFS" will have you launch an instance of the CVMFS image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
>
>
  • " Running a batch job which uses the Shared Software Repository service" will have you launch an instance of the CVMFS server image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
  In order to try the Cloud Scheduler Test Drive, you will need the following:
Line: 108 to 108
  You have just run a demonstration job on a dynamically created Virtual Machine.
Changed:
<
<

Running a batch job which uses CVMFS

>
>

Running a batch job which uses the Shared Software Repository service

 
Deleted:
<
<
CVMFS is a read only network file system that is designed for sharing software to VMs. It's a secure and very fast way to mount POSIX network file system that can be shared to hundreds of running VMs.
  We provide a VM appliance which is preconfigured with CVMFS which will allow you to share your software to multiple running VMs.
Added:
>
>
CVMFS is a read only network file system that is designed for sharing software to VMs. It's a secure and very fast way to mount POSIX network file system that can be shared to hundreds of running VMs.
 Step 1:

Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username). It is always a good idea to assign the instance your keypair so that you can log into it if the need arises.

Line: 152 to 153
 cat demo-2.out Job started at Tue May 28 15:40:22 PDT 2013 => demo-2.sh <=
Changed:
<
<
Simple wait script for testing the default CVMFS application.
>
>
Simple script for testing the default CVMFS appliance.
  Shutting down CernVM-FS: [ OK ] Stopping automount: [ OK ]
Line: 167 to 168
 Job finished at Tue May 28 15:40:27 PDT 2013 %ENDCONSOLE%
Changed:
<
<

Customizing the CVMFS server to host your applications

>
>

Customizing the Shared Software Repository server to host your applications

  In order to make the CVMFS server really useful to you, you will need to install your application software within its' repository. Modifying the content of the software repository is outside the scope of this document, but it is covered by the service documentation for "NEP52 Shared Software Repository" service.
Changed:
<
<

Running a job to exercise CVMFS modifications in the batch environment

>
>

Running a batch job to exercise the modifications to your Shared Software Repository

  If you have followed the documentation for "NEP52 Shared Software Repository"

Revision 312013-09-03 - igable

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 182 to 182
  If you followed all the steps above you have a customized version the Cloud Scheduler appliance running. You can now use the OpenStack dashboard to snapshot this server to save yourself the work of customizing it again.
Changed:
<
<
  • rpi_cloud_architecture.png:
    rpi_cloud_architecture.png
>
>
 
META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369770075" name="select_key.png" path="select_key.png" size="24128" user="crlb" version="2"

Revision 302013-09-03 - igable

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 17 to 17
 
  1. Jane then waits for her jobs to complete.
  2. Jane gets her results.
Added:
>
>
rpi_cloud_architecture.png
 
Line: 180 to 182
  If you followed all the steps above you have a customized version the Cloud Scheduler appliance running. You can now use the OpenStack dashboard to snapshot this server to save yourself the work of customizing it again.
Added:
>
>
  • rpi_cloud_architecture.png:
    rpi_cloud_architecture.png
 
META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369770075" name="select_key.png" path="select_key.png" size="24128" user="crlb" version="2"
Added:
>
>
META FILEATTACHMENT attachment="rpi_cloud_architecture.png" attr="" comment="" date="1378171403" name="rpi_cloud_architecture.png" path="rpi_cloud_architecture.png" size="101017" user="igable" version="1"

Revision 292013-09-03 - igable

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 6 to 6
 

Overview

Added:
>
>
If you already are familiar with batch computing and just want to get to running your jobs on VMs skip to the Cloud Scheduler Test Drive Section below.

Cloud Scheduler is a tool which will spawn Virtual Machine (VMs) on Infrastructure-as-a-Service (IaaS) clouds in order to run batch computing jobs. With Cloud Scheduler you clone a VM or provide and existing VM batch worker node image and point your HT Condor batch jobs to that image; cloud scheduler handles the rest. For people already familiar with classic batch computing the process will be very familiar.

Here's how it should work for the user Jane's perspective:

  1. Jane prepares a VM image loaded with the software she needs for processing, then uploads it to an image repository. It's also possible that this could have been done previously by one of her colleagues, or she picks a pre-cooked image (as is the case in the following tutorial).
  2. Jane submits a bunch of processing jobs to a Condor pool. In the Condor jobs, she specifies regular Condor parameters, but also specifies a VM image that she would like her job to run on.
  3. Jane then waits for her jobs to complete.
  4. Jane gets her results.

The following tutorial will walk you though the steps necessary to run your first job on the cloud using the DAIR cloud. Only access to additional clouds is required for you to run your jobs distributed at multiple cloud sites. We start by assuming that you have access to the DAIR cloud.

 

Cloud Scheduler Test Drive

You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following examples will allow you to test drive this functionality quickly. In summary:

Revision 282013-08-29 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

NEP52 Batch Services

Line: 19 to 19
 
  • To create your own keypair and save the pem file locally (see the Openstack dashboard/documentation).
  • To retrieve your EC2_ACCESS_KEY and EC2_SECRET_KEY from the Openstack dashboard.
Added:
>
>

Preparation

The NEP52 Batch Services service and the related NEP52 Shared Software Repository service make use of the network and require specific ports to be open. These ports must be added to your OpenStack default security group by logging into the OpenStack dashboard, selecting the "Access & Security" tab and clicking "Edit Rules" beside the default security group. Use the "Add Rule" dialog at the bottom of the form and ensure that all the ports shown in the figure below are included before proceeding with the test drive:

DefaultSG.png

 

Running your first batch job

Step 1: Log into DAIR and boot a Cloud Scheduler instance

Login into the DAIR OpenStack Dashboard: https://nova-ab.dair-atir.canarie.ca . Select the alberta region. Refer to the OpenStack docs for all the details of booting and managing VMs via the dashboard.

Changed:
<
<
Go to the 'Images and Snapshot' tab on the left of the page then click the button that says 'Launch' next to the "NEP52-cloud-scheduler" image.
>
>
Go to the 'Images and Snapshot' tab on the left of the page then click the button that says 'Launch' next to the NEP52-cloud-scheduler image.
  Fill in the form to look the same as the screen shot below substituting your username where you see the string "hepnet".

Revision 272013-08-28 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
Changed:
<
<

Cloud Scheduler Test Drive

>
>

NEP52 Batch Services

 
Added:
>
>

Overview

Cloud Scheduler Test Drive

 You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following examples will allow you to test drive this functionality quickly. In summary:

  • "Running your first batch job" will have you launch an instance of the Cloud Scheduler image (NEP52-cloud-scheduler), configure and start Cloud Scheduler, and submit a batch job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output. At the end of the job, when there are no more jobs in the queue, Cloud Scheduler will automatically remove idle batch VMs.
  • " Running a batch job which uses CVMFS" will have you launch an instance of the CVMFS image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
Deleted:
<
<
  • And finally, "Adding an application to the CVMFS server", will have you log into the CVMFS server, add a new application, and then run another batch job to excercise the new application.
  In order to try the Cloud Scheduler Test Drive, you will need the following:
Line: 85 to 88
  Step 1:
Changed:
<
<
Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username) and assign the instance your keypair. Once the instance has launched, you should associate an floating IP with the instance.
>
>
Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username). It is always a good idea to assign the instance your keypair so that you can log into it if the need arises.
  Step 2:
Line: 136 to 139
 Job finished at Tue May 28 15:40:27 PDT 2013 %ENDCONSOLE%
Changed:
<
<

Adding an application to the CVMFS server

In this section we will show you how to modify the CVMFS server to distribute your own software.

Step 1:

Log into the CVMS server (if you didn't already assign a floating IP you can associate one now), switch to the distributed software directory, and copy the "Hello" bash script to the file "Goodbye". Then edit the "Goodbye" script to echo a different message.

%STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 <---- IP of CVMFS server cd /cvmfs/dair.cvmfs.server cp Hello Goodbye vi Goodbye %ENDCONSOLE%

When you have saved your changes to the Goodbye script, publish your newly changed script to the world via CVMFS: %STARTCONSOLE% chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server cvmfs-sync cvmfs_server publish %ENDCONSOLE%

>
>

Customizing the CVMFS server to host your applications

 
Changed:
<
<
Step 2:
>
>
In order to make the CVMFS server really useful to you, you will need to install your application software within its' repository. Modifying the content of the software repository is outside the scope of this document, but it is covered by the service documentation for "NEP52 Shared Software Repository" service.
 
Changed:
<
<
Now run a job that calls your newly created "Goodbye" script: make sure to edit the demo-3.job script with your "{user-name}" as you did with demo-2 job before. %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 <--- IP of Cloud Scheduler Server su - guest vi demo-3.job condor_submit demo-3.job watch 'cloud_status -m; condor_q' %ENDCONSOLE%

The "demo-3" job runs the "Goodbye" application and its output file, "demo-3.out", should contain your message.

>
>

Running a job to exercise CVMFS modifications in the batch environment

 
Changed:
<
<
So you can publish any arbitrary files using this method. We use CVMFS to publish our 7 GB ATLAS software distributions which dramatically reduces the size of the VM and allows us to make changes to the software without changing the VM images.
>
>
If you have followed the documentation for "NEP52 Shared Software Repository" and have created the sample "Goodbye" application, then you may want to run the third demonstration job to exercise your CVMFS modifications in the batch envirnoment. The procedure is identical to the one given for the second demonstration job above, substituting "demo-3" for "demo-2" wherever it appears.
 

Take snapshots of your customized images

Changed:
<
<
If you followed all the steps above you have customized versions of both the Cloud Scheduler and the CVMFS appliances running. You can now use the OpenStack dashboard to snapshot these two servers to save yourself the work of customizing them again.

Also, you may wish to create a customized batch client image which is permanently configured to talk to a particular CVMFS server. This can be done by:

  • Launching and logging into an instance of NEP52-batch-cvmfs-client,
  • modifying the CVMFS client configuration (the "demo-2.sh" and "demo-3.sh" scripts both contain code to modify the CVMFS client configuration which demonstrates the modifications that you need to make),
  • and using the OpenStack dashboard to take a snapshot of your modified image.
>
>
If you followed all the steps above you have a customized version the Cloud Scheduler appliance running. You can now use the OpenStack dashboard to snapshot this server to save yourself the work of customizing it again.
 
META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369770075" name="select_key.png" path="select_key.png" size="24128" user="crlb" version="2"

Revision 262013-08-23 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Line: 46 to 46
 ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 %ENDCONSOLE%
Changed:
<
<
Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically "{access_key_id}", "{secret_access_key}", and "{keypair}". Then start the Cloud Scheduler service:
>
>
Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically "{keypair_name}", "{EC2_ACCESS_KEY}", and "{EC2_SECRET_KEY}", for both the Alberta and Quebec DAIR clouds. Then start the Cloud Scheduler service:
  %STARTCONSOLE% vi /etc/cloudscheduler/cloud_resources.conf

Revision 252013-08-23 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Line: 46 to 46
 ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 %ENDCONSOLE%
Changed:
<
<
Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically access_key_id and secret_access_key, and start the Cloud Scheduler service:
>
>
Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically "{access_key_id}", "{secret_access_key}", and "{keypair}". Then start the Cloud Scheduler service:
  %STARTCONSOLE% vi /etc/cloudscheduler/cloud_resources.conf

Revision 242013-05-30 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Line: 6 to 6
  You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following examples will allow you to test drive this functionality quickly. In summary:
Changed:
<
<
  • "Running your first batch job" will have you launch an instance of the Cloud Scheduler image (NEP52-cloud-scheduler), configure and start Cloud Scheduler, and submit a batch job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output.
>
>
  • "Running your first batch job" will have you launch an instance of the Cloud Scheduler image (NEP52-cloud-scheduler), configure and start Cloud Scheduler, and submit a batch job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output. At the end of the job, when there are no more jobs in the queue, Cloud Scheduler will automatically remove idle batch VMs.
 
  • " Running a batch job which uses CVMFS" will have you launch an instance of the CVMFS image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
  • And finally, "Adding an application to the CVMFS server", will have you log into the CVMFS server, add a new application, and then run another batch job to excercise the new application.

In order to try the Cloud Scheduler Test Drive, you will need the following:

Changed:
<
<
  • A DAIR login ID.
>
>
  • A DAIR login ID with a large enough quota to run the three concurrent demonstration instances.
 
  • To create your own keypair and save the pem file locally (see the Openstack dashboard/documentation).
Changed:
<
<
  • Retrieve your EC2_ACCESS_KEY and EC2_SECRET_KEY from the Openstack dashboard.
>
>
  • To retrieve your EC2_ACCESS_KEY and EC2_SECRET_KEY from the Openstack dashboard.
 

Running your first batch job

Step 1: Log into DAIR and boot a Cloud Scheduler instance
Line: 38 to 38
  Step 2: Log into the Cloud Scheduler instance and configure it
Changed:
<
<
Now associate an external IP ("floating IP" in OpenStack terminology) address to the machine. Click on the instances tab on the left. From the "Actions" beside your newly started Cloud Scheduler instance, choose "Associate Floating IP", complete the dialog and click "Associate".
>
>
Now associate a floating IP to the machine. Click on the instances tab on the left. From the "Actions" beside your newly started Cloud Scheduler instance, choose "Associate Floating IP", complete the dialog and click "Associate".
  Now ssh into the box as root (you can find the IP of the machine from the dashboard):
Line: 85 to 85
  Step 1:
Changed:
<
<
Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username) and assign the instance your keypair. Once the instance has launched, you should associate an external IP with the instance.
>
>
Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username) and assign the instance your keypair. Once the instance has launched, you should associate an floating IP with the instance.
  Step 2:
Line: 142 to 142
  Step 1:
Changed:
<
<
Log into the CVMS server (if you didn't already assign an external IP you can associate one now), switch to the distributed software directory, and copy the "Hello" bash script to the file "Goodbye". Then edit the "Goodbye" script to echo a different message.
>
>
Log into the CVMS server (if you didn't already assign a floating IP you can associate one now), switch to the distributed software directory, and copy the "Hello" bash script to the file "Goodbye". Then edit the "Goodbye" script to echo a different message.
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 <---- IP of CVMFS server

Revision 232013-05-30 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Changed:
<
<
You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following example will allow you to test drive this functionality quickly. In summary, you will start the Cloud Scheduler VM (NEP52-cloud-scheduler image), log into it and execute a batch the job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud.
>
>
You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following examples will allow you to test drive this functionality quickly. In summary:
 
Added:
>
>
  • "Running your first batch job" will have you launch an instance of the Cloud Scheduler image (NEP52-cloud-scheduler), configure and start Cloud Scheduler, and submit a batch job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud automatically, the job will run, and you can monitor its progress and check the job output.
  • " Running a batch job which uses CVMFS" will have you launch an instance of the CVMFS image (NEP52-cvmfs-server), submit a batch job, and check the output of the distributed application.
  • And finally, "Adding an application to the CVMFS server", will have you log into the CVMFS server, add a new application, and then run another batch job to excercise the new application.

In order to try the Cloud Scheduler Test Drive, you will need the following:

  • A DAIR login ID.
  • To create your own keypair and save the pem file locally (see the Openstack dashboard/documentation).
  • Retrieve your EC2_ACCESS_KEY and EC2_SECRET_KEY from the Openstack dashboard.

Running your first batch job

 Step 1: Log into DAIR and boot a Cloud Scheduler instance

Login into the DAIR OpenStack Dashboard: https://nova-ab.dair-atir.canarie.ca . Select the alberta region. Refer to the OpenStack docs for all the details of booting and managing VMs via the dashboard.

Line: 18 to 29
  launch.png
Changed:
<
<
Now you need to select an SSH key to associate with the instance so that you can login to the image. Click the access and security tab, pick a key, click "launch" (see screen shot below) and wait for the instance to become active.
>
>
Now you need to select your SSH key to associate with the instance so that you can login to the image. Click the access and security tab, pick your key, click "launch" (see screen shot below) and wait for the instance to become active.
  select_key.png
Line: 35 to 46
 ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 %ENDCONSOLE%
Changed:
<
<
Edit the Cloud Scheduler configuration file to contain your Dair EC2 credentials, specifically access_key_id and secret_access_key, and start the Cloud Scheduler service:
>
>
Use your favourite editor (ie. nano, vi, or vim) to edit the Cloud Scheduler configuration file to contain your DAIR EC2 credentials, specifically access_key_id and secret_access_key, and start the Cloud Scheduler service:
  %STARTCONSOLE%
Changed:
<
<
nano /etc/cloudscheduler/cloud_resources.conf
>
>
vi /etc/cloudscheduler/cloud_resources.conf
 service cloud_scheduler start %ENDCONSOLE%
Line: 48 to 59
  Step 3: Run a job and be amazed
Changed:
<
<
Switch to the guest user on the VM and then submit a 'hello world' type of demo job. You can then see what's happening with cloud_status and condor_q or you can issue these two commands periodically through "watch" to monitor the job progress:
>
>
Switch to the guest user on the VM and then submit the first demonstration job which calculates pi to 1000 decimal places. You can then see what's happening with cloud_status and condor_q or you can issue these two commands periodically through "watch" to monitor the job progress:
  %STARTCONSOLE% su - guest
Line: 66 to 77
  You have just run a demonstration job on a dynamically created Virtual Machine.
Changed:
<
<

Running a Job which uses CVMFS

>
>

Running a batch job which uses CVMFS

  CVMFS is a read only network file system that is designed for sharing software to VMs. It's a secure and very fast way to mount POSIX network file system that can be shared to hundreds of running VMs.
Line: 74 to 85
  Step 1:
Changed:
<
<
Using the OpenStack dashboard, launch an instance of NEP52-cvmfs-server setting the keypair, external IP, and instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username).
>
>
Using the OpenStack dashboard and the same launch procedure as for the Cloud Scheduler image, launch an instance of NEP52-cvmfs-server. You must set the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username) and assign the instance your keypair. Once the instance has launched, you should associate an external IP with the instance.
  Step 2:
Changed:
<
<
Log into the Cloud Scheduler VM you already launched, edit the job description file, and replace the string "{username}" with your username.
>
>
If you are not already logged into the Cloud Scheduler VM, login and switch to the guest account:
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 su - guest
Changed:
<
<
nano demo-2.job
>
>
%ENDCONSOLE%

Edit the second demonstration job description file, and replace the string "{username}" with your username.

%STARTCONSOLE% vi demo-2.job

 %ENDCONSOLE%

The line you must change looks like this:

Line: 120 to 136
 Job finished at Tue May 28 15:40:27 PDT 2013 %ENDCONSOLE%
Changed:
<
<

Adding an application to the CVMFS server

>
>

Adding an application to the CVMFS server

  In this section we will show you how to modify the CVMFS server to distribute your own software.

Step 1:

Changed:
<
<
Log into the CVMS server (if you didn't already assign an external IP you can associate one now) and copy the "Hello" bash script to the file "Goodbye". Then edit that script to say something different.
>
>
Log into the CVMS server (if you didn't already assign an external IP you can associate one now), switch to the distributed software directory, and copy the "Hello" bash script to the file "Goodbye". Then edit the "Goodbye" script to echo a different message.
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 <---- IP of CVMFS server cd /cvmfs/dair.cvmfs.server cp Hello Goodbye
Changed:
<
<
nano Goodbye
>
>
vi Goodbye
 %ENDCONSOLE%
Changed:
<
<
Publish your newly changed script to the world via CVMFS:
>
>
When you have saved your changes to the Goodbye script, publish your newly changed script to the world via CVMFS:
 %STARTCONSOLE% chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server cvmfs-sync
Line: 148 to 164
 %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 <--- IP of Cloud Scheduler Server su - guest
Changed:
<
<
nano demo-3.job
>
>
vi demo-3.job
 condor_submit demo-3.job watch 'cloud_status -m; condor_q' %ENDCONSOLE%
Line: 157 to 173
  So you can publish any arbitrary files using this method. We use CVMFS to publish our 7 GB ATLAS software distributions which dramatically reduces the size of the VM and allows us to make changes to the software without changing the VM images.
Changed:
<
<

Take snapshots of your now customized setup.

>
>

Take snapshots of your customized images

  If you followed all the steps above you have customized versions of both the Cloud Scheduler and the CVMFS appliances running. You can now use the OpenStack dashboard to snapshot these two servers to save yourself the work of customizing them again.
Added:
>
>
Also, you may wish to create a customized batch client image which is permanently configured to talk to a particular CVMFS server. This can be done by:

  • Launching and logging into an instance of NEP52-batch-cvmfs-client,
  • modifying the CVMFS client configuration (the "demo-2.sh" and "demo-3.sh" scripts both contain code to modify the CVMFS client configuration which demonstrates the modifications that you need to make),
  • and using the OpenStack dashboard to take a snapshot of your modified image.
 
META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369770075" name="select_key.png" path="select_key.png" size="24128" user="crlb" version="2"

Revision 222013-05-29 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Changed:
<
<
You can use the software provided in this RPI project to easily run your bach jobs on the dair cloud. The following example will allow you to test drive this functionality quickly. In summary, you will start the Cloud Scheduler VM (NEP52-cloud-scheduler image), log into it and execute a batch the job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud.
>
>
You can use the software provided in this RPI project to easily run your batch jobs on the DAIR cloud. The following example will allow you to test drive this functionality quickly. In summary, you will start the Cloud Scheduler VM (NEP52-cloud-scheduler image), log into it and execute a batch the job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud.
  Step 1: Log into DAIR and boot a Cloud Scheduler instance
Line: 74 to 74
  Step 1:
Changed:
<
<
Using the OpenStack dashboard, launch an instance of NEP52-cvmfs-server setting the keypair, external IP, and instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username).
>
>
Using the OpenStack dashboard, launch an instance of NEP52-cvmfs-server setting the keypair, external IP, and instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username).
  Step 2:
Line: 86 to 86
 nano demo-2.job %ENDCONSOLE%
Added:
>
>
The line you must change looks like this:

%STARTCONSOLE% Arguments = {user-name} %ENDCONSOLE%

 Now submit the job and watch it like we did before:

%STARTCONSOLE%

Line: 120 to 126
  Step 1:
Changed:
<
<
Log into the CVMS server(associate a floating IP) and copy the "Hello" bash script to the file "Goodbye". Then edit that script to say something different.
>
>
Log into the CVMS server (if you didn't already assign an external IP you can associate one now) and copy the "Hello" bash script to the file "Goodbye". Then edit that script to say something different.
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 <---- IP of CVMFS server
Line: 138 to 144
  Step 2:
Changed:
<
<
Now run a job that calls your newly created "Goodbye" script: make sure to edit the script with your "{user-name}"
>
>
Now run a job that calls your newly created "Goodbye" script: make sure to edit the demo-3.job script with your "{user-name}" as you did with demo-2 job before.
 %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 <--- IP of Cloud Scheduler Server su - guest
Line: 147 to 153
 watch 'cloud_status -m; condor_q' %ENDCONSOLE%
Changed:
<
<
The "demo-3" job runs the "Goodbye" application and the its output file, "demo-3.out", should contain your message.
>
>
The "demo-3" job runs the "Goodbye" application and its output file, "demo-3.out", should contain your message.
  So you can publish any arbitrary files using this method. We use CVMFS to publish our 7 GB ATLAS software distributions which dramatically reduces the size of the VM and allows us to make changes to the software without changing the VM images.

Revision 212013-05-29 - mhp

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Line: 8 to 8
  Step 1: Log into DAIR and boot a Cloud Scheduler instance
Changed:
<
<
Login into the DAIR OpenStack Dashboard: https://nova-ab.dair-atir.canarie.ca . Refer to the OpenStack docs for all the details of booting and managing VMs via the dashboard.
>
>
Login into the DAIR OpenStack Dashboard: https://nova-ab.dair-atir.canarie.ca . Select the alberta region. Refer to the OpenStack docs for all the details of booting and managing VMs via the dashboard.
  Go to the 'Images and Snapshot' tab on the left of the page then click the button that says 'Launch' next to the "NEP52-cloud-scheduler" image.
Line: 78 to 78
  Step 2:
Changed:
<
<
Log into the Cloud Scheduler VM you already launched, edit the job description file, and replace the string "{username}" with your username.
>
>
Log into the Cloud Scheduler VM you already launched, edit the job description file, and replace the string "{username}" with your username.
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18
Line: 120 to 120
  Step 1:
Changed:
<
<
Log into the CVMS server and copy the "Hello" bash script to the file "Goodbye". Then edit that script to say something different.
>
>
Log into the CVMS server(associate a floating IP) and copy the "Hello" bash script to the file "Goodbye". Then edit that script to say something different.
  %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 <---- IP of CVMFS server
Line: 138 to 138
  Step 2:
Changed:
<
<
Now run a job that calls your newly created "Goodbye" script:
>
>
Now run a job that calls your newly created "Goodbye" script: make sure to edit the script with your "{user-name}"
 %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 <--- IP of Cloud Scheduler Server su - guest

Revision 202013-05-28 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Line: 12 to 12
  Go to the 'Images and Snapshot' tab on the left of the page then click the button that says 'Launch' next to the "NEP52-cloud-scheduler" image.
Changed:
<
<
Fill in the form to look the same as the screen shot below substituting your username where you see the string "hepnet".
>
>
Fill in the form to look the same as the screen shot below substituting your username where you see the string "hepnet".
  launch.png
Line: 61 to 61
 When the job completes, it disappears from the queue. The primary output for the job will be contained in the file 'demo-1.out', errors will be reported in 'demo-1.err', and the HTCondor job log is saved in 'demo-1.log'. All these file names are user defined in the job description file 'demo-1.job'.

%STARTCONSOLE%

Changed:
<
<
less demo-1.out
>
>
cat demo-1.out
 %ENDCONSOLE%

You have just run a demonstration job on a dynamically created Virtual Machine.

Line: 74 to 74
  Step 1:
Changed:
<
<
Using the OpenStack dashboard, launch an instance of NEP52-cvmfs-server setting the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username).
>
>
Using the OpenStack dashboard, launch an instance of NEP52-cvmfs-server setting the keypair, external IP, and instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username).
  Step 2:
Line: 96 to 96
 Once the job finishes you should see something like this in the file "demo-2.out":

%STARTCONSOLE%

Changed:
<
<
cat demo-2.job
>
>
cat demo-2.out Job started at Tue May 28 15:40:22 PDT 2013 => demo-2.sh <= Simple wait script for testing the default CVMFS application.

Shutting down CernVM-FS: [ OK ] Stopping automount: [ OK ] Starting automount: [ OK ] Starting CernVM-FS: [ OK ]

-rwxr-xr-x 1 cvmfs cvmfs 110 Mar 28 16:00 /cvmfs/dair.cvmfs.server/Hello -rw-r--r-- 1 cvmfs cvmfs 47 Mar 28 16:00 /cvmfs/dair.cvmfs.server/empty

 Hello! You have successfully connected to the skeleton CVMFS server and run its software.
Deleted:
<
<
%ENDCONSOLE%
 
Changed:
<
<
In the next section we will show you how to modify the CVMFS server to distribute your own software.
>
>
Job finished at Tue May 28 15:40:27 PDT 2013 %ENDCONSOLE%
 

Adding an application to the CVMFS server

Changed:
<
<
In the previous section, you saw how to boot a CVMFS server and run the applications it provides. Now we are going to show you how to change the software that this CVMFS server is hosting.
>
>
In this section we will show you how to modify the CVMFS server to distribute your own software.
  Step 1:

Revision 192013-05-28 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"

Cloud Scheduler Test Drive

Line: 144 to 144
 If you followed all the steps above you have customized versions of both the Cloud Scheduler and the CVMFS appliances running. You can now use the OpenStack dashboard to snapshot these two servers to save yourself the work of customizing them again.

META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
Changed:
<
<
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369760233" name="select_key.png" path="select_key.png" size="23363" user="crlb" version="1"
>
>
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369770075" name="select_key.png" path="select_key.png" size="24128" user="crlb" version="2"

Revision 182013-05-28 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
Changed:
<
<
-- ColinLeavettBrown - 2013-04-25

NEP52 Batch Services for RPI

>
>

Cloud Scheduler Test Drive

 
Changed:
<
<

Introduction

NEP52 provides a powerful, scalable batch processing capability to the Research Platform Initiative (RPI). This function is enabled through the following Virtual Machine (VM) images:

>
>
You can use the software provided in this RPI project to easily run your bach jobs on the dair cloud. The following example will allow you to test drive this functionality quickly. In summary, you will start the Cloud Scheduler VM (NEP52-cloud-scheduler image), log into it and execute a batch the job. The batch job will trigger Cloud Scheduler to boot a VM on the DAIR OpenStack Cloud.

Step 1: Log into DAIR and boot a Cloud Scheduler instance

Login into the DAIR OpenStack Dashboard: https://nova-ab.dair-atir.canarie.ca . Refer to the OpenStack docs for all the details of booting and managing VMs via the dashboard.

Go to the 'Images and Snapshot' tab on the left of the page then click the button that says 'Launch' next to the "NEP52-cloud-scheduler" image.

Fill in the form to look the same as the screen shot below substituting your username where you see the string "hepnet".

launch.png

Now you need to select an SSH key to associate with the instance so that you can login to the image. Click the access and security tab, pick a key, click "launch" (see screen shot below) and wait for the instance to become active.

select_key.png

Step 2: Log into the Cloud Scheduler instance and configure it

Now associate an external IP ("floating IP" in OpenStack terminology) address to the machine. Click on the instances tab on the left. From the "Actions" beside your newly started Cloud Scheduler instance, choose "Associate Floating IP", complete the dialog and click "Associate".

Now ssh into the box as root (you can find the IP of the machine from the dashboard) :

%STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 %ENDCONSOLE%

Edit the Cloud Scheduler configuration file to contain your Dair EC2 credentials, specifically access_key_id and secret_access_key, and start the Cloud Scheduler service:

%STARTCONSOLE% nano /etc/cloudscheduler/cloud_resources.conf service cloud_scheduler start %ENDCONSOLE%

If you don't have your credentials follow this video to see how to do it. Your credentials will be used by Cloud Scheduler to boot VMs on your behalf.

Step 3: Run a job and be amazed

Switch to the guest user on the VM and then submit a 'hello world' type of demo job. You can then see what's happening with cloud_status and condor_q or you can issue these two commands periodically through "watch" to monitor the job progress:

%STARTCONSOLE% su - guest condor_submit demo-1.job cloud_status -m condor_q watch 'cloud_status -m; condor_q' %ENDCONSOLE%

When the job completes, it disappears from the queue. The primary output for the job will be contained in the file 'demo-1.out', errors will be reported in 'demo-1.err', and the HTCondor job log is saved in 'demo-1.log'. All these file names are user defined in the job description file 'demo-1.job'.

%STARTCONSOLE% less demo-1.out %ENDCONSOLE%

You have just run a demonstration job on a dynamically created Virtual Machine.

 
Changed:
<
<
  • NEP52-cloud-scheduler - This VM hosts Cloud Scheduler, a service to auto-provision VMs, together with its HTCondor batch job scheduling environment. In addition, this node provides user login capabilities to allow users to submit their workload to the scheduler for execution, monitor and retrieve their results.
  • NEP52-cvmfs-server - Provides a software distribution appliance VM that can host and distribute software for multiple VMs and VM types. The VM provided contains only one simple demonstration application and should be considered a template for building efficient, project specific software repositories. Using this server in a project can greatly reduce image sizes and improve image and software propagation efficiency.
  • NEP52-batch-cvmfs-client - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.

Procedures:

The following procedures are designed to demonstrate the capabilities of the NEP52 batch processing services. By executing these procedures, you should learn how to utilize these services to process your own batch workload. The procedures will accomplish the following:

  1. Interactively run the demonstration application allowing you to become familiar with OpenStack services, OpenStack networking, and the CVMFS software distribution appliance (procedure #1).
  2. Customize the NEP52-cvmfs-server image to create a CVMFS server of your own (procedure #2).
  3. Customize the NEP52-batch-cvmfs-client image to create a VM to run a demonstration job using your CVMFS server (procedure #3).
  4. Customize the NEP52-cloud-scheduler image to create a user login ("head") node and scheduling environment to run your batch workloads on the DAIR clouds (procedure #4).
  5. Run a demonstration batch job, monitor its progress, and check its output (procedure #5).

These procedures use the DAIR OpenStack dashboard available at:

https://nova-ab.dair-atir.canarie.ca
and a terminal capable of using the "ssh" or "putty" commands.

The screen-shots in the following documentation were developed using the HEPnet account/user name. Whenever a screen-shot contains the word "HEPnet" or the instructions contain the text "{account}", you should substitute your own account/user name.

1. Getting started

    i. Open a terminal and login to the DAIR OpenStack dashboard:

2. Running the "Hello" demonstration application from the software repository

    i. Launch an instance of NEP52-cvmfs-server:


       

        setting the instance name to "{account}-cvmfs":


       

        assigning your own key pair:


       

        and associating a floating IP:


       

    ii. Using the same methodology, launch an instance of NEP52-batch-cvmfs-client, setting the name to "{account}-client:, assigning a "keypair" and a floating IP. When your instance of "{account}-client" becomes "active" :


       

        login as root:


       

    iv. Reconfigure the client to use your server name:

        * In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the string "{account}" in the URL on line #18 to your account name:


       

        * In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the string "{account}" in the URL on line #1 to your account name:


       

        * Activate the new configuration:


       

    v. Run the demonstration application from the CVMFS server:
       

        vi. Create a snapshot of your working, customized client:

        * Change the image name within the "/.image.metadata":


       

        * Delete network related UDEV rules created by this kernel for each unique MAC address: , ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".


       

        * Use the OpenStack dashboard to take a snapshot of your batch client.


       

3. Creating a customized software repository

        i. Logout of your client and login to your CVMFS server:


       

        ii. Modify the content of the "/cvmfs/dair.cvmfs.server/" directory. As distributed, this directory contains the "empty" placeholder and the "Hello" script. The content of this directory, including any directory subtree, will be distributed to requesting clients once the repository has been signed and published. As a demonstration, copy "Hello" to "Goodbye" and modify the echoed text in "Goodbye" as desired.


       

        iii. Sign and publish the repository by issuing the following three commands:

>
>

Running a Job which uses CVMFS

 
Changed:
<
<
>
>
CVMFS is a read only network file system that is designed for sharing software to VMs. It's a secure and very fast way to mount POSIX network file system that can be shared to hundreds of running VMs.

We provide a VM appliance which is preconfigured with CVMFS which will allow you to share your software to multiple running VMs.

Step 1:

Using the OpenStack dashboard, launch an instance of NEP52-cvmfs-server setting the instance name to "{username}-cvmfs" (obviously replacing "{username}" with your own username).

Step 2:

Log into the Cloud Scheduler VM you already launched, edit the job description file, and replace the string "{username}" with your username.

%STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 su - guest nano demo-2.job %ENDCONSOLE%

Now submit the job and watch it like we did before:

%STARTCONSOLE% condor_submit demo-2.job watch 'cloud_status -m; condor_q' %ENDCONSOLE%

Once the job finishes you should see something like this in the file "demo-2.out":

%STARTCONSOLE% cat demo-2.job Hello! You have successfully connected to the skeleton CVMFS server and run its software. %ENDCONSOLE%

In the next section we will show you how to modify the CVMFS server to distribute your own software.

Adding an application to the CVMFS server

In the previous section, you saw how to boot a CVMFS server and run the applications it provides. Now we are going to show you how to change the software that this CVMFS server is hosting.

Step 1:

Log into the CVMS server and copy the "Hello" bash script to the file "Goodbye". Then edit that script to say something different.

%STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.80 <---- IP of CVMFS server cd /cvmfs/dair.cvmfs.server cp Hello Goodbye nano Goodbye %ENDCONSOLE%

Publish your newly changed script to the world via CVMFS: %STARTCONSOLE%

 chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server cvmfs-sync cvmfs_server publish
Changed:
<
<
>
>
%ENDCONSOLE%

Step 2:

Now run a job that calls your newly created "Goodbye" script: %STARTCONSOLE% ssh -i ~/.ssh/MyKey.pem root@208.75.74.18 <--- IP of Cloud Scheduler Server su - guest nano demo-3.job condor_submit demo-3.job watch 'cloud_status -m; condor_q' %ENDCONSOLE%

The "demo-3" job runs the "Goodbye" application and the its output file, "demo-3.out", should contain your message.

So you can publish any arbitrary files using this method. We use CVMFS to publish our 7 GB ATLAS software distributions which dramatically reduces the size of the VM and allows us to make changes to the software without changing the VM images.

Take snapshots of your now customized setup.

If you followed all the steps above you have customized versions of both the Cloud Scheduler and the CVMFS appliances running. You can now use the OpenStack dashboard to snapshot these two servers to save yourself the work of customizing them again.

 
Changed:
<
<
        iv. Use the OpenStack dashboard to take a snapshot of your CVMFS server.

We will be exercising your new application under preocedure #5, "Runnng a batch job", but if you want to check your changes now, you could login to you running client a try the application now.

4. Configuring and starting the Cloud Scheduler service

  1. Launch an instance of NEP52-cloud-scheduler, assigning a "keypair" and a floating IP.
  2. When your instance of the NEP52-cloud-scheduler becomes "active", login as root (ie. "ssh -i <pub-key> root@<floating-ip>").
  3. Configure the cloud resources that you want to use. The configuration file, located at "/etc/cloudscheduler/cloud_resources.conf" documents all cloud resource parameters and contains template definitions for the Alberta and Quebec DAIR clouds at the bottom of the configuration file. The following items within each template should be modified:
    • Copy your ec2 credentials, "key_name", "access_key_id", and "secret_key_id", into the places indicated.
    • Review/adjust the resources, "vm_slots", "cpu_cores", "storage", and "memory" to be used on the cloud.
    • Be sure to set "enabled: true" for the appropriate clouds.
  4. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
  5. Add Cloud Scheduler to the list of services to be started automatically at boot, ie. "chkconfig cloud_scheduler on"
  6. Save a copy of your Cloud Scheduler:
    • You may wish to review procedure #5, prior to taking your snapshot, which also makes customizations (specifically #5.3 and #5.4) to the Cloud Scheduler image.
    • Delete network related UDEV rules created by this kernel for each unique MAC address, ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".
    • Use the OpenStack dashboard to take a snapshot of your batch client.

5. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #4), a running custom software repository (procedure #2), and that you have a customized client (procedure #3).
  1. Login to the Cloud Scheduler, ie. "ssh -i <pub-key> root@<floating-ip>").
  2. Switch to the sysadmin account, ie. "su - sysadmin". This normal user account has password-less sudo access and a template job description file and simple job script.
  3. Determine the "ami" of your customized client:
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated within the /home/sysadmin/.ec2/ec2_credentials personal configuration file.
    • Issue "list_ami" to list all the images/ami IDs that you may access; ami IDs have the format "ami-xxxxxxxx" where "xxxxxxxx" are hexadecimal digits.
  4. Finalize the demonstration "/home/sysadmin/demo.job" job description file:
    • Change "<image-name>" to match the unique name you set within the your batch client's /.image.metadata file (see procedure #3.5).
    • Change "<ami-id>" to the ami ID of your client image.
  5. Submit the job for execution, ie. "condor_submit demo.job". The results of the job will be returned to the file "demo.log", "demo.out", and "demo.error" upon job completion.
  6. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. try "watch 'cloud_status -t; cloud_status -m; condor_q'" - use "Control-C" to exit the "watch" command. Cloud Scheduler has several polling cycles, so it can take several minutes before the VM starts and one or two more before the job runs. If your job won't run, the Cloud Scheduler log at /var/log/cloudscheduler.log probably contains the reason why.

META FILEATTACHMENT attachment="p1.1.png" attr="" comment="" date="1369340666" name="p1.1.png" path="p1.1.png" size="1287406" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.1.png" attr="" comment="" date="1369343052" name="p2.1.png" path="p2.1.png" size="322614" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.2.png" attr="" comment="" date="1369343052" name="p2.2.png" path="p2.2.png" size="269124" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.3.png" attr="" comment="" date="1369343052" name="p2.3.png" path="p2.3.png" size="255344" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.4.png" attr="" comment="" date="1369344739" name="p2.4.png" path="p2.4.png" size="215272" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.5.png" attr="" comment="" date="1369344739" name="p2.5.png" path="p2.5.png" size="268120" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.6.png" attr="" comment="" date="1369344739" name="p2.6.png" path="p2.6.png" size="24529" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.7.png" attr="" comment="" date="1369345836" name="p2.7.png" path="p2.7.png" size="68609" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.8.png" attr="" comment="" date="1369345836" name="p2.8.png" path="p2.8.png" size="22844" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.9.png" attr="" comment="" date="1369345836" name="p2.9.png" path="p2.9.png" size="50386" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.10.png" attr="" comment="" date="1369345836" name="p2.10.png" path="p2.10.png" size="61178" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.7a.png" attr="" comment="" date="1369347095" name="p2.7a.png" path="p2.7a.png" size="84736" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.8a.png" attr="" comment="" date="1369347095" name="p2.8a.png" path="p2.8a.png" size="40277" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.10a.png" attr="" comment="" date="1369347095" name="p2.10a.png" path="p2.10a.png" size="61320" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.9a.png" attr="" comment="" date="1369347328" name="p2.9a.png" path="p2.9a.png" size="50512" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.11.png" attr="" comment="" date="1369349515" name="p2.11.png" path="p2.11.png" size="36862" user="crlb" version="2"
META FILEATTACHMENT attachment="p2.12.png" attr="" comment="" date="1369349515" name="p2.12.png" path="p2.12.png" size="72687" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.13.png" attr="" comment="" date="1369349515" name="p2.13.png" path="p2.13.png" size="230691" user="crlb" version="1"
META FILEATTACHMENT attachment="p3.1.png" attr="" comment="" date="1369350659" name="p3.1.png" path="p3.1.png" size="92572" user="crlb" version="1"
META FILEATTACHMENT attachment="p3.2.png" attr="" comment="" date="1369350659" name="p3.2.png" path="p3.2.png" size="113328" user="crlb" version="1"
>
>
META FILEATTACHMENT attachment="launch.png" attr="" comment="" date="1369760233" name="launch.png" path="launch.png" size="59258" user="crlb" version="1"
META FILEATTACHMENT attachment="select_key.png" attr="" comment="" date="1369760233" name="select_key.png" path="select_key.png" size="23363" user="crlb" version="1"

Revision 172013-05-23 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 23 to 23
 
  1. Customize the NEP52-cloud-scheduler image to create a user login ("head") node and scheduling environment to run your batch workloads on the DAIR clouds (procedure #4).
  2. Run a demonstration batch job, monitor its progress, and check its output (procedure #5).
Changed:
<
<

1. Running the "Hello" demonstration application from the software repository

  1. Launch an instance of NEP52-cvmfs-server. If you are able (ie. it is not already being used by someone else), set the instance name to "cvmfs-server". The NEP52-batch-cvmfs-client is already configured to communicate with a server named "cvmfs-server" and you will not have to perform step 4 if you choose this name. Also, though it is not necessary for this procedure, assigning a "keypair" and "floating-ip" to the server would allow you to re-use this server in procedure #2.
  2. Launch an instance of NEP52-batch-cvmfs-client, assigning a "keypair" and a floating IP.
  3. When your instance of the NEP52-batch-cvmfs-client becomes "active", login as root (ie. "ssh -i <pub-key> root@<floating-ip>").
  4. If you were unable to choose the server name of "cvmfs-server", reconfigure the client to use the name you chose for the server"
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name from "cvmfs-server" in the URL on line #18 to the name you chose in step 1.
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name from "cvmfs-server" in the URL on line #1 to the name you chose in step 1.
    • Activate the new configuration with the command "service cvmfs restartautofs".
  5. Issue the command "/cvmfs/dair.cvmfs.server/Hello".

2. Creating a customized software repository

  1. If you are able to re-use the NEP52-cvmfs-server from procedure #1, login as root (ie. "ssh -i <pub-key> root@<floating-ip>"). Otherwise, launch an instance of NEP52-cvmfs-server, assigning a "keypair" and a floating IP and, when "active", login as root.
  2. Modify the content of the "/cvmfs/dair.cvmfs.server/" directory. As distributed, this directory contains the "empty" placeholder and the "Hello" script. The content of this directory, including any directory subtree, will be distributed to requesting clients once the repository has been signed and published. As a demonstration, copy "Hello" to "Goodbye" and modify the echoed text in "Goodbye" as desired.
  3. Sign and publish the repository by issuing the following commands:
    • chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server
    • cvmfs-sync
    • cvmfs_server publish
  4. Use the OpenStack dashboard to take a snapshot of your CVMFS server.

3. Creating a customized client to use a customized software repository

  1. Launch an instance of your CVMFS server snapshot created in procedure #2. The name you choose for this instance will be used in subsequent steps of this procedure.
  2. If you are able to re-use the NEP52-batch-cvmfs-client from procedure #1, login as root (ie. "ssh -i <pub-key> root@<floating-ip>"). Otherwise, launch an instance of NEP52-batch-cvmfs-client, assigning a "keypair" and a floating IP and, when "active", login as root.
  3. Modify the CVMFS client configuration as follows:
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name (was originally "cvmfs-server') in the URL on line #18 to the name you chose in step 1.
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name (was originally "cvmfs-server') in the URL on line #1 to the name you chose in step 1.
    • Activate the new configuration with the command "service cvmfs restartautofs".
  4. Check the functionality of your client/server:
    • Use standard linux commands to view the content of your software directoy, eg. "ls -l /cvmfs/dair.cvmfs.server/*".
    • Execute applications from your software directory.
  5. Save a copy of your client:
    • Change the image name within the "/.image.metadata" to something unique.
    • Delete network related UDEV rules created by this kernel for each unique MAC address, ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".
>
>

These procedures use the DAIR OpenStack dashboard available at:

https://nova-ab.dair-atir.canarie.ca
and a terminal capable of using the "ssh" or "putty" commands.

The screen-shots in the following documentation were developed using the HEPnet account/user name. Whenever a screen-shot contains the word "HEPnet" or the instructions contain the text "{account}", you should substitute your own account/user name.

1. Getting started

    i. Open a terminal and login to the DAIR OpenStack dashboard:

2. Running the "Hello" demonstration application from the software repository

    i. Launch an instance of NEP52-cvmfs-server:


       

        setting the instance name to "{account}-cvmfs":


       

        assigning your own key pair:


       

        and associating a floating IP:


       

    ii. Using the same methodology, launch an instance of NEP52-batch-cvmfs-client, setting the name to "{account}-client:, assigning a "keypair" and a floating IP. When your instance of "{account}-client" becomes "active" :


       

        login as root:


       

    iv. Reconfigure the client to use your server name:

        * In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the string "{account}" in the URL on line #18 to your account name:


       

        * In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the string "{account}" in the URL on line #1 to your account name:


       

        * Activate the new configuration:


       

    v. Run the demonstration application from the CVMFS server:
       

        vi. Create a snapshot of your working, customized client:

        * Change the image name within the "/.image.metadata":


       

        * Delete network related UDEV rules created by this kernel for each unique MAC address: , ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".


       

       

 
    • Use the OpenStack dashboard to take a snapshot of your batch client.
Added:
>
>

       

3. Creating a customized software repository

        i. Logout of your client and login to your CVMFS server:


       

        ii. Modify the content of the "/cvmfs/dair.cvmfs.server/" directory. As distributed, this directory contains the "empty" placeholder and the "Hello" script. The content of this directory, including any directory subtree, will be distributed to requesting clients once the repository has been signed and published. As a demonstration, copy "Hello" to "Goodbye" and modify the echoed text in "Goodbye" as desired.


       

        iii. Sign and publish the repository by issuing the following three commands:

chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server
cvmfs-sync
cvmfs_server publish

        iv. Use the OpenStack dashboard to take a snapshot of your CVMFS server.

We will be exercising your new application under preocedure #5, "Runnng a batch job", but if you want to check your changes now, you could login to you running client a try the application now.

 

4. Configuring and starting the Cloud Scheduler service

  1. Launch an instance of NEP52-cloud-scheduler, assigning a "keypair" and a floating IP.
  2. When your instance of the NEP52-cloud-scheduler becomes "active", login as root (ie. "ssh -i <pub-key> root@<floating-ip>").
Line: 83 to 222
 
    • Change "<ami-id>" to the ami ID of your client image.
  1. Submit the job for execution, ie. "condor_submit demo.job". The results of the job will be returned to the file "demo.log", "demo.out", and "demo.error" upon job completion.
  2. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. try "watch 'cloud_status -t; cloud_status -m; condor_q'" - use "Control-C" to exit the "watch" command. Cloud Scheduler has several polling cycles, so it can take several minutes before the VM starts and one or two more before the job runs. If your job won't run, the Cloud Scheduler log at /var/log/cloudscheduler.log probably contains the reason why.
\ No newline at end of file
Added:
>
>
META FILEATTACHMENT attachment="p1.1.png" attr="" comment="" date="1369340666" name="p1.1.png" path="p1.1.png" size="1287406" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.1.png" attr="" comment="" date="1369343052" name="p2.1.png" path="p2.1.png" size="322614" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.2.png" attr="" comment="" date="1369343052" name="p2.2.png" path="p2.2.png" size="269124" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.3.png" attr="" comment="" date="1369343052" name="p2.3.png" path="p2.3.png" size="255344" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.4.png" attr="" comment="" date="1369344739" name="p2.4.png" path="p2.4.png" size="215272" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.5.png" attr="" comment="" date="1369344739" name="p2.5.png" path="p2.5.png" size="268120" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.6.png" attr="" comment="" date="1369344739" name="p2.6.png" path="p2.6.png" size="24529" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.7.png" attr="" comment="" date="1369345836" name="p2.7.png" path="p2.7.png" size="68609" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.8.png" attr="" comment="" date="1369345836" name="p2.8.png" path="p2.8.png" size="22844" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.9.png" attr="" comment="" date="1369345836" name="p2.9.png" path="p2.9.png" size="50386" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.10.png" attr="" comment="" date="1369345836" name="p2.10.png" path="p2.10.png" size="61178" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.7a.png" attr="" comment="" date="1369347095" name="p2.7a.png" path="p2.7a.png" size="84736" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.8a.png" attr="" comment="" date="1369347095" name="p2.8a.png" path="p2.8a.png" size="40277" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.10a.png" attr="" comment="" date="1369347095" name="p2.10a.png" path="p2.10a.png" size="61320" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.9a.png" attr="" comment="" date="1369347328" name="p2.9a.png" path="p2.9a.png" size="50512" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.11.png" attr="" comment="" date="1369349515" name="p2.11.png" path="p2.11.png" size="36862" user="crlb" version="2"
META FILEATTACHMENT attachment="p2.12.png" attr="" comment="" date="1369349515" name="p2.12.png" path="p2.12.png" size="72687" user="crlb" version="1"
META FILEATTACHMENT attachment="p2.13.png" attr="" comment="" date="1369349515" name="p2.13.png" path="p2.13.png" size="230691" user="crlb" version="1"
META FILEATTACHMENT attachment="p3.1.png" attr="" comment="" date="1369350659" name="p3.1.png" path="p3.1.png" size="92572" user="crlb" version="1"
META FILEATTACHMENT attachment="p3.2.png" attr="" comment="" date="1369350659" name="p3.2.png" path="p3.2.png" size="113328" user="crlb" version="1"

Revision 162013-05-22 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 17 to 17
 

The following procedures are designed to demonstrate the capabilities of the NEP52 batch processing services. By executing these procedures, you should learn how to utilize these services to process your own batch workload. The procedures will accomplish the following:

Changed:
<
<
  1. Interactively run the demonstration application allowing you to become familiar with OpenStack services, OpenStack networking, and the CVMFS software distribution appliance (procedure #3).
  2. Customize the NEP52-cvmfs-server image to create a CVMFS server of your own (procedure #4).
  3. Customize the NEP52-batch-cvmfs-client image to create a VM to run a demonstration job using your CVMFS server (procedure #5).
  4. Customize the NEP52-cloud-scheduler image to create a user login ("head") node and scheduling environment to run your batch workloads on the DAIR clouds (procedure #6).
  5. Run a demonstration batch job, monitor its progress, and check its output (procedure #7).
>
>
  1. Interactively run the demonstration application allowing you to become familiar with OpenStack services, OpenStack networking, and the CVMFS software distribution appliance (procedure #1).
  2. Customize the NEP52-cvmfs-server image to create a CVMFS server of your own (procedure #2).
  3. Customize the NEP52-batch-cvmfs-client image to create a VM to run a demonstration job using your CVMFS server (procedure #3).
  4. Customize the NEP52-cloud-scheduler image to create a user login ("head") node and scheduling environment to run your batch workloads on the DAIR clouds (procedure #4).
  5. Run a demonstration batch job, monitor its progress, and check its output (procedure #5).
 

1. Running the "Hello" demonstration application from the software repository

  1. Launch an instance of NEP52-cvmfs-server. If you are able (ie. it is not already being used by someone else), set the instance name to "cvmfs-server". The NEP52-batch-cvmfs-client is already configured to communicate with a server named "cvmfs-server" and you will not have to perform step 4 if you choose this name. Also, though it is not necessary for this procedure, assigning a "keypair" and "floating-ip" to the server would allow you to re-use this server in procedure #2.

Revision 152013-05-22 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 23 to 23
 
  1. Customize the NEP52-cloud-scheduler image to create a user login ("head") node and scheduling environment to run your batch workloads on the DAIR clouds (procedure #6).
  2. Run a demonstration batch job, monitor its progress, and check its output (procedure #7).
Changed:
<
<

1. Launching and logging in to a NEP52 public image instance

  1. Using the OpenStack dashboard, launch the desired NEP52 public image assigning a "keypair" to the instance to allow you to login as root. The OpenStack dialog requires the specification of a unique instance name. The name you choose can be used to communicate between instances and will be used in the following procedures.
  2. Associate a floating IP with the instance just launched.
  3. Log in to the instance as "root" via the floating IP using your keypair; ie. ssh -i <keypair.pem> root@<floating.IP>.

2. Taking a snapshot of a NEP52 public image instance

  1. Log in to the instance as root (procedure #1).
  2. Delete the UDEV rules associated with the network configuration, ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".
  3. Using the OpenStack dashboard, snapshot the image.

3. Running the "Hello" demonstration application from the software repository

  1. Launch an instance of NEP52-cvmfs-server (procedure #1). Set the instance name to "cvmfs-server"; the NEP52-batch-cvmfs-client is configured to communicate with a server with this name. If you are unable to choose this name because it is in use by someone else, then you should choose a different name and follow #5.3 and #5.4 within the client. Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
  2. Launch and login to an instance of NEP52-batch-cvmfs-client (procedure #1).
  3. Issue the command "/cvmfs/dair.cvmfs.server/Hello".
>
>

1. Running the "Hello" demonstration application from the software repository

  1. Launch an instance of NEP52-cvmfs-server. If you are able (ie. it is not already being used by someone else), set the instance name to "cvmfs-server". The NEP52-batch-cvmfs-client is already configured to communicate with a server named "cvmfs-server" and you will not have to perform step 4 if you choose this name. Also, though it is not necessary for this procedure, assigning a "keypair" and "floating-ip" to the server would allow you to re-use this server in procedure #2.
  2. Launch an instance of NEP52-batch-cvmfs-client, assigning a "keypair" and a floating IP.
  3. When your instance of the NEP52-batch-cvmfs-client becomes "active", login as root (ie. "ssh -i <pub-key> root@<floating-ip>").
  4. If you were unable to choose the server name of "cvmfs-server", reconfigure the client to use the name you chose for the server"
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name from "cvmfs-server" in the URL on line #18 to the name you chose in step 1.
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name from "cvmfs-server" in the URL on line #1 to the name you chose in step 1.
    • Activate the new configuration with the command "service cvmfs restartautofs".
  5. Issue the command "/cvmfs/dair.cvmfs.server/Hello".
 
Changed:
<
<

4. Creating a customized software repository

  1. Launch and login to the NEP52-cvmfs-server public image (procedure #1).
>
>

2. Creating a customized software repository

  1. If you are able to re-use the NEP52-cvmfs-server from procedure #1, login as root (ie. "ssh -i <pub-key> root@<floating-ip>"). Otherwise, launch an instance of NEP52-cvmfs-server, assigning a "keypair" and a floating IP and, when "active", login as root.
 
  1. Modify the content of the "/cvmfs/dair.cvmfs.server/" directory. As distributed, this directory contains the "empty" placeholder and the "Hello" script. The content of this directory, including any directory subtree, will be distributed to requesting clients once the repository has been signed and published. As a demonstration, copy "Hello" to "Goodbye" and modify the echoed text in "Goodbye" as desired.
  2. Sign and publish the repository by issuing the following commands:
    • chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server
    • cvmfs-sync
    • cvmfs_server publish
Changed:
<
<
  1. Take a snapshot of your repository (procedure #2).
>
>
  1. Use the OpenStack dashboard to take a snapshot of your CVMFS server.
 
Changed:
<
<

5. Creating a customized client to use a customized software repository

  1. Launch an instance of your custom software repository (procedure #1). Choose an instance name, say "my-cvmfs-server". Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
  2. Launch and login to an instance of NEP52-batch-cvmfs-client (procedure #1).
>
>

3. Creating a customized client to use a customized software repository

  1. Launch an instance of your CVMFS server snapshot created in procedure #2. The name you choose for this instance will be used in subsequent steps of this procedure.
  2. If you are able to re-use the NEP52-batch-cvmfs-client from procedure #1, login as root (ie. "ssh -i <pub-key> root@<floating-ip>"). Otherwise, launch an instance of NEP52-batch-cvmfs-client, assigning a "keypair" and a floating IP and, when "active", login as root.
 
  1. Modify the CVMFS client configuration as follows:
Changed:
<
<
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1) in the URL on line #18.
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1) in the URL on line #1.
  1. Activate the new configuration with the command "service cvmfs restartautofs".
  2. You may use standard linux commands to view/execute the content of your software repository, eg. "ls -l /cvmfs/dair.cvmfs.server/*".
  3. Modify the image name within the "/.image.metadata" file.
  4. Take a snapshot of your client (procedure #2).

6. Configuring and starting the Cloud Scheduler service

  1. Launch and login to the NEP52-cloud-scheduler public image (procedure #1).
  2. Configure the cloud resources that you want to use. The configuration file, located at "/etc/cloudscheduler/cloud_resources.conf" documents all cloud resource parameters and contains template definitions for the Alberta and Quebec DAIR clouds at the bottom of the configuration file. The following items within each template should be modified:
>
>
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name (was originally "cvmfs-server') in the URL on line #18 to the name you chose in step 1.
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name (was originally "cvmfs-server') in the URL on line #1 to the name you chose in step 1.
    • Activate the new configuration with the command "service cvmfs restartautofs".
  1. Check the functionality of your client/server:
    • Use standard linux commands to view the content of your software directoy, eg. "ls -l /cvmfs/dair.cvmfs.server/*".
    • Execute applications from your software directory.
  2. Save a copy of your client:
    • Change the image name within the "/.image.metadata" to something unique.
    • Delete network related UDEV rules created by this kernel for each unique MAC address, ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".
    • Use the OpenStack dashboard to take a snapshot of your batch client.

4. Configuring and starting the Cloud Scheduler service

  1. Launch an instance of NEP52-cloud-scheduler, assigning a "keypair" and a floating IP.
  2. When your instance of the NEP52-cloud-scheduler becomes "active", login as root (ie. "ssh -i <pub-key> root@<floating-ip>").
  3. Configure the cloud resources that you want to use. The configuration file, located at "/etc/cloudscheduler/cloud_resources.conf" documents all cloud resource parameters and contains template definitions for the Alberta and Quebec DAIR clouds at the bottom of the configuration file. The following items within each template should be modified:
 
    • Copy your ec2 credentials, "key_name", "access_key_id", and "secret_key_id", into the places indicated.
    • Review/adjust the resources, "vm_slots", "cpu_cores", "storage", and "memory" to be used on the cloud.
    • Be sure to set "enabled: true" for the appropriate clouds.
Changed:
<
<
  1. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
  2. Add Cloud Scheduler to the list of services to be started automatically at boot, ie. "chkconfig cloud_scheduler on"
  3. To retain your customizations, take a snapshot (procedure #2). You may wish to review process #7, prior to taking your snapshot, which also makes customizations (specifically #7.3 and #7.4) to the Cloud Scheduler image.

7. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #3), a running custom software repository (procedures #5 and #1), and that you have a customized client (procedure #6).
  1. Login to the Cloud Scheduler (procedure #1.3).
>
>
  1. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
  2. Add Cloud Scheduler to the list of services to be started automatically at boot, ie. "chkconfig cloud_scheduler on"
  3. Save a copy of your Cloud Scheduler:
    • You may wish to review procedure #5, prior to taking your snapshot, which also makes customizations (specifically #5.3 and #5.4) to the Cloud Scheduler image.
    • Delete network related UDEV rules created by this kernel for each unique MAC address, ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".
    • Use the OpenStack dashboard to take a snapshot of your batch client.

5. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #4), a running custom software repository (procedure #2), and that you have a customized client (procedure #3).
  1. Login to the Cloud Scheduler, ie. "ssh -i <pub-key> root@<floating-ip>").
 
  1. Switch to the sysadmin account, ie. "su - sysadmin". This normal user account has password-less sudo access and a template job description file and simple job script.
  2. Determine the "ami" of your customized client:
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated within the /home/sysadmin/.ec2/ec2_credentials personal configuration file.
    • Issue "list_ami" to list all the images/ami IDs that you may access; ami IDs have the format "ami-xxxxxxxx" where "xxxxxxxx" are hexadecimal digits.
  3. Finalize the demonstration "/home/sysadmin/demo.job" job description file:
Changed:
<
<
    • Change "<vm-name>" to the client image name (see #5.6).
>
>
    • Change "<image-name>" to match the unique name you set within the your batch client's /.image.metadata file (see procedure #3.5).
 
    • Change "<ami-id>" to the ami ID of your client image.
  1. Submit the job for execution, ie. "condor_submit demo.job". The results of the job will be returned to the file "demo.log", "demo.out", and "demo.error" upon job completion.
Deleted:
<
<
  1. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. watch "cloud_status -m; condor_q". Cloud Scheduler has several polling cycles, so it can take up to two minutes before the VM starts and one or two more before the job runs.
 \ No newline at end of file
Added:
>
>
  1. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. try "watch 'cloud_status -t; cloud_status -m; condor_q'" - use "Control-C" to exit the "watch" command. Cloud Scheduler has several polling cycles, so it can take several minutes before the VM starts and one or two more before the job runs. If your job won't run, the Cloud Scheduler log at /var/log/cloudscheduler.log probably contains the reason why.

Revision 132013-05-15 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 15 to 15
 

Procedures:

Added:
>
>

The following procedures are designed to demonstrate the capabilities of the NEP52 batch processing services. By executing these procedures, you should learn how to utilize these services to process your own batch workload. The procedures will accomplish the following:

  1. Interactively run the demonstration application allowing you to become familiar with OpenStack services, OpenStack networking, and the CVMFS software distribution appliance (procedure #3).
  2. Customize the NEP52-cvmfs-server image to create a CVMFS server of your own (procedure #4).
  3. Customize the NEP52-batch-cvmfs-client image to create a VM to run a demonstration job using your CVMFS server (procedure #5).
  4. Customize the NEP52-cloud-scheduler image to create a user login ("head") node and scheduling environment to run your batch workloads on the DAIR clouds (procedure #6).
  5. Run a demonstration batch job, monitor its progress, and check its output (procedure #7).
 

1. Launching and logging in to a NEP52 public image instance

  1. Using the OpenStack dashboard, launch the desired NEP52 public image assigning a "keypair" to the instance to allow you to login as root. The OpenStack dialog requires the specification of a unique instance name. The name you choose can be used to communicate between instances and will be used in the following procedures.
  2. Associate a floating IP with the instance just launched.

Revision 122013-05-07 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 65 to 65
 For this procedure, we will assume you have a running Cloud Scheduler (procedure #3), a running custom software repository (procedures #5 and #1), and that you have a customized client (procedure #6).
  1. Login to the Cloud Scheduler (procedure #1.3).
  2. Switch to the sysadmin account, ie. "su - sysadmin". This normal user account has password-less sudo access and a template job description file and simple job script.
Changed:
<
<
  1. Use the list_ami command to determine the "ami" of your customized client:
>
>
  1. Determine the "ami" of your customized client:
 
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated within the /home/sysadmin/.ec2/ec2_credentials personal configuration file.
    • Issue "list_ami" to list all the images/ami IDs that you may access; ami IDs have the format "ami-xxxxxxxx" where "xxxxxxxx" are hexadecimal digits.
  1. Finalize the demonstration "/home/sysadmin/demo.job" job description file:
Changed:
<
<
    • Change "<vm-name>" to the client image name (see #6.6).
>
>
    • Change "<vm-name>" to the client image name (see #5.6).
 
    • Change "<ami-id>" to the ami ID of your client image.
  1. Submit the job for execution, ie. "condor_submit demo.job". The results of the job will be returned to the file "demo.log", "demo.out", and "demo.error" upon job completion.
Changed:
<
<
  1. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. watch "cloud_status -m; condor_q".
>
>
  1. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. watch "cloud_status -m; condor_q". Cloud Scheduler has several polling cycles, so it can take up to two minutes before the VM starts and one or two more before the job runs.

Revision 112013-05-07 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 16 to 16
 

Procedures:

1. Launching and logging in to a NEP52 public image instance

Changed:
<
<
  1. Using the OpenStack dashboard, launch the desired NEP52 public image assigning a "keypair" to the instance to allow you to login as root. The OpenStack dialog requires the specification of an instance name. The name you choose can be used to communicate between instances and will be used in the following procedures.
>
>
  1. Using the OpenStack dashboard, launch the desired NEP52 public image assigning a "keypair" to the instance to allow you to login as root. The OpenStack dialog requires the specification of a unique instance name. The name you choose can be used to communicate between instances and will be used in the following procedures.
 
  1. Associate a floating IP with the instance just launched.
Changed:
<
<
  1. Log in to the instance as "root" via the floating IP using your keypair; ie. ssh -i <keypair.pem> root@.
>
>
  1. Log in to the instance as "root" via the floating IP using your keypair; ie. ssh -i <keypair.pem> root@<floating.IP>.
 

2. Taking a snapshot of a NEP52 public image instance

  1. Log in to the instance as root (procedure #1).
Line: 27 to 27
 

3. Running the "Hello" demonstration application from the software repository

Changed:
<
<
  1. Launch an instance of NEP52-cvmfs-server (procedure #1). Set the instance name to "cvmfs-server". Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
>
>
  1. Launch an instance of NEP52-cvmfs-server (procedure #1). Set the instance name to "cvmfs-server"; the NEP52-batch-cvmfs-client is configured to communicate with a server with this name. If you are unable to choose this name because it is in use by someone else, then you should choose a different name and follow #5.3 and #5.4 within the client. Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
 
  1. Launch and login to an instance of NEP52-batch-cvmfs-client (procedure #1).
  2. Issue the command "/cvmfs/dair.cvmfs.server/Hello".

Revision 102013-05-07 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 57 to 57
 
    • Copy your ec2 credentials, "key_name", "access_key_id", and "secret_key_id", into the places indicated.
    • Review/adjust the resources, "vm_slots", "cpu_cores", "storage", and "memory" to be used on the cloud.
    • Be sure to set "enabled: true" for the appropriate clouds.
Changed:
<
<
  1. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
  2. To retain your customizations, take a snapshot (procedure #2). You may wish to review process #7, prior to taking your snapshot, which also makes customizations (specifically #7.3 and #7.4) to the Cloud Scheduler image.
>
>
  1. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
  2. Add Cloud Scheduler to the list of services to be started automatically at boot, ie. "chkconfig cloud_scheduler on"
  3. To retain your customizations, take a snapshot (procedure #2). You may wish to review process #7, prior to taking your snapshot, which also makes customizations (specifically #7.3 and #7.4) to the Cloud Scheduler image.
 

7. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #3), a running custom software repository (procedures #5 and #1), and that you have a customized client (procedure #6).

Revision 92013-05-07 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 54 to 54
 

6. Configuring and starting the Cloud Scheduler service

  1. Launch and login to the NEP52-cloud-scheduler public image (procedure #1).
  2. Configure the cloud resources that you want to use. The configuration file, located at "/etc/cloudscheduler/cloud_resources.conf" documents all cloud resource parameters and contains template definitions for the Alberta and Quebec DAIR clouds at the bottom of the configuration file. The following items within each template should be modified:
Changed:
<
<
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated.
    • Review/adjust the resources, vm_slots, cpu_cores, storage, and memory to be used on the cloud.
>
>
    • Copy your ec2 credentials, "key_name", "access_key_id", and "secret_key_id", into the places indicated.
    • Review/adjust the resources, "vm_slots", "cpu_cores", "storage", and "memory" to be used on the cloud.
    • Be sure to set "enabled: true" for the appropriate clouds.
 
  1. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
Changed:
<
<
  1. If you wish to retain your customizations, take a snapshot (procedure #2). You may wish to review process #7, prior to taking your snapshot, which also makes customizations (specifically #7.3 and #7.4) to the Cloud Scheduler image that you might want to retain.
>
>
  1. To retain your customizations, take a snapshot (procedure #2). You may wish to review process #7, prior to taking your snapshot, which also makes customizations (specifically #7.3 and #7.4) to the Cloud Scheduler image.
 

7. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #3), a running custom software repository (procedures #5 and #1), and that you have a customized client (procedure #6).

Revision 82013-05-06 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 57 to 57
 
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated.
    • Review/adjust the resources, vm_slots, cpu_cores, storage, and memory to be used on the cloud.
  1. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
Changed:
<
<
  1. If you wish to retain your customizations, take a snapshot (procedure #2).
>
>
  1. If you wish to retain your customizations, take a snapshot (procedure #2). You may wish to review process #7, prior to taking your snapshot, which also makes customizations (specifically #7.3 and #7.4) to the Cloud Scheduler image that you might want to retain.
 

7. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #3), a running custom software repository (procedures #5 and #1), and that you have a customized client (procedure #6).

Revision 72013-05-06 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 44 to 44
 
  1. Launch an instance of your custom software repository (procedure #1). Choose an instance name, say "my-cvmfs-server". Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
  2. Launch and login to an instance of NEP52-batch-cvmfs-client (procedure #1).
  3. Modify the CVMFS client configuration as follows:
Changed:
<
<
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1).
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1).
>
>
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1) in the URL on line #18.
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1) in the URL on line #1.
 
  1. Activate the new configuration with the command "service cvmfs restartautofs".
  2. You may use standard linux commands to view/execute the content of your software repository, eg. "ls -l /cvmfs/dair.cvmfs.server/*".
  3. Modify the image name within the "/.image.metadata" file.

Revision 62013-05-03 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 9 to 9
 

Introduction

NEP52 provides a powerful, scalable batch processing capability to the Research Platform Initiative (RPI). This function is enabled through the following Virtual Machine (VM) images:

Changed:
<
<
  • NEP52-cloud-scheduler.v1 - This VM hosts Cloud Scheduler, a service to auto-provision VMs, together with its HTCondor batch job scheduling environment. In addition, this node provides user login capabilities to allow users to submit their workload to the scheduler for execution, monitor and retrieve their results.
  • NEP52-cvmfs-server.v1 - Provides a software distribution appliance VM that can host and distribute software for multiple VMs and VM types. The VM provided contains only one simple demonstration application and should be considered a template for building efficient, project specific software repositories. Using this server in a project can greatly reduce image sizes and improve image and software propagation efficiency.
  • NEP52-batch-cvmfs-client.v1 - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.
>
>
  • NEP52-cloud-scheduler - This VM hosts Cloud Scheduler, a service to auto-provision VMs, together with its HTCondor batch job scheduling environment. In addition, this node provides user login capabilities to allow users to submit their workload to the scheduler for execution, monitor and retrieve their results.
  • NEP52-cvmfs-server - Provides a software distribution appliance VM that can host and distribute software for multiple VMs and VM types. The VM provided contains only one simple demonstration application and should be considered a template for building efficient, project specific software repositories. Using this server in a project can greatly reduce image sizes and improve image and software propagation efficiency.
  • NEP52-batch-cvmfs-client - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.
 

Procedures:

Deleted:
<
<

Launching Cloud Scheduler

  1. Launch the CS-RPI VM (image name?, ami?) using the dashboard or other tool
  2. Log in to the VM using your keypair
  3. copy your ec2 credentials access key id, and secret key id into /etc/cloudscheduler/cloud_resources.conf
  4. set the amount of instances, memory, and disk you want Cloud Scheduler to use in the cloud_resources.conf
  5. start cloudscheduler using $service cloud_scheduler start

Running your first job

  1. copy your ec2 credentials into the get_ami.py script
  2. run get_ami.py to see the AMIs available for the cloud
  3. edit the provided testjob.sub to change the ami if needed.
  4. condor_submit testjob.sub
  5. you can see the vm boot by checking cloud_status -m
 \ No newline at end of file
Added:
>
>

1. Launching and logging in to a NEP52 public image instance

  1. Using the OpenStack dashboard, launch the desired NEP52 public image assigning a "keypair" to the instance to allow you to login as root. The OpenStack dialog requires the specification of an instance name. The name you choose can be used to communicate between instances and will be used in the following procedures.
  2. Associate a floating IP with the instance just launched.
  3. Log in to the instance as "root" via the floating IP using your keypair; ie. ssh -i <keypair.pem> root@.

2. Taking a snapshot of a NEP52 public image instance

  1. Log in to the instance as root (procedure #1).
  2. Delete the UDEV rules associated with the network configuration, ie. "sed -i '/ATTR{address}/ D' /etc/udev/rules.d/70-persistent-net.rules".
  3. Using the OpenStack dashboard, snapshot the image.

3. Running the "Hello" demonstration application from the software repository

  1. Launch an instance of NEP52-cvmfs-server (procedure #1). Set the instance name to "cvmfs-server". Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
  2. Launch and login to an instance of NEP52-batch-cvmfs-client (procedure #1).
  3. Issue the command "/cvmfs/dair.cvmfs.server/Hello".

4. Creating a customized software repository

  1. Launch and login to the NEP52-cvmfs-server public image (procedure #1).
  2. Modify the content of the "/cvmfs/dair.cvmfs.server/" directory. As distributed, this directory contains the "empty" placeholder and the "Hello" script. The content of this directory, including any directory subtree, will be distributed to requesting clients once the repository has been signed and published. As a demonstration, copy "Hello" to "Goodbye" and modify the echoed text in "Goodbye" as desired.
  3. Sign and publish the repository by issuing the following commands:
    • chown -R cvmfs.cvmfs /cvmfs/dair.cvmfs.server
    • cvmfs-sync
    • cvmfs_server publish
  4. Take a snapshot of your repository (procedure #2).

5. Creating a customized client to use a customized software repository

  1. Launch an instance of your custom software repository (procedure #1). Choose an instance name, say "my-cvmfs-server". Since we do not need to login to the service to run the application, we do not need to associate a floating IP to the instance.
  2. Launch and login to an instance of NEP52-batch-cvmfs-client (procedure #1).
  3. Modify the CVMFS client configuration as follows:
    • In the domain configuration file "/etc/cvmfs/domain.d/cvmfs.server", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1).
    • In the configuration file "/etc/cvmfs/config.d/dair.cvmfs.server.conf", change the server name from "cvmfs-server" to "my-cvmfs-server" (to match the name chosen in #6.1).
  4. Activate the new configuration with the command "service cvmfs restartautofs".
  5. You may use standard linux commands to view/execute the content of your software repository, eg. "ls -l /cvmfs/dair.cvmfs.server/*".
  6. Modify the image name within the "/.image.metadata" file.
  7. Take a snapshot of your client (procedure #2).

6. Configuring and starting the Cloud Scheduler service

  1. Launch and login to the NEP52-cloud-scheduler public image (procedure #1).
  2. Configure the cloud resources that you want to use. The configuration file, located at "/etc/cloudscheduler/cloud_resources.conf" documents all cloud resource parameters and contains template definitions for the Alberta and Quebec DAIR clouds at the bottom of the configuration file. The following items within each template should be modified:
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated.
    • Review/adjust the resources, vm_slots, cpu_cores, storage, and memory to be used on the cloud.
  3. Start the Cloud Scheduler service, ie. "service cloud_scheduler start".
  4. If you wish to retain your customizations, take a snapshot (procedure #2).

7. Running a batch job

For this procedure, we will assume you have a running Cloud Scheduler (procedure #3), a running custom software repository (procedures #5 and #1), and that you have a customized client (procedure #6).
  1. Login to the Cloud Scheduler (procedure #1.3).
  2. Switch to the sysadmin account, ie. "su - sysadmin". This normal user account has password-less sudo access and a template job description file and simple job script.
  3. Use the list_ami command to determine the "ami" of your customized client:
    • Copy your ec2 credentials, access key id, and secret key id, into the places indicated within the /home/sysadmin/.ec2/ec2_credentials personal configuration file.
    • Issue "list_ami" to list all the images/ami IDs that you may access; ami IDs have the format "ami-xxxxxxxx" where "xxxxxxxx" are hexadecimal digits.
  4. Finalize the demonstration "/home/sysadmin/demo.job" job description file:
    • Change "<vm-name>" to the client image name (see #6.6).
    • Change "<ami-id>" to the ami ID of your client image.
  5. Submit the job for execution, ie. "condor_submit demo.job". The results of the job will be returned to the file "demo.log", "demo.out", and "demo.error" upon job completion.
  6. The progress of the job can be monitored with the "condor_q" and "cloud_status" commands", eg. watch "cloud_status -m; condor_q".

Revision 52013-05-02 - mhp

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 14 to 14
 
  • NEP52-batch-cvmfs-client.v1 - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.

Procedures:

Added:
>
>

Launching Cloud Scheduler

 
  1. Launch the CS-RPI VM (image name?, ami?) using the dashboard or other tool
  2. Log in to the VM using your keypair
Deleted:
<
<

Launching Cloud Scheduler

 
  1. copy your ec2 credentials access key id, and secret key id into /etc/cloudscheduler/cloud_resources.conf
  2. set the amount of instances, memory, and disk you want Cloud Scheduler to use in the cloud_resources.conf
  3. start cloudscheduler using $service cloud_scheduler start
Changed:
<
<

Running your first job

>
>

Running your first job

 
  1. copy your ec2 credentials into the get_ami.py script
  2. run get_ami.py to see the AMIs available for the cloud
  3. edit the provided testjob.sub to change the ami if needed.

Revision 42013-04-29 - mhp

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
-- ColinLeavettBrown - 2013-04-25
Line: 14 to 14
 
  • NEP52-batch-cvmfs-client.v1 - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.

Procedures:

Added:
>
>
  1. Launch the CS-RPI VM (image name?, ami?) using the dashboard or other tool
  2. Log in to the VM using your keypair
 

Launching Cloud Scheduler

Added:
>
>
  1. copy your ec2 credentials access key id, and secret key id into /etc/cloudscheduler/cloud_resources.conf
  2. set the amount of instances, memory, and disk you want Cloud Scheduler to use in the cloud_resources.conf
  3. start cloudscheduler using $service cloud_scheduler start
 

Running your first job

Added:
>
>
  1. copy your ec2 credentials into the get_ami.py script
  2. run get_ami.py to see the AMIs available for the cloud
  3. edit the provided testjob.sub to change the ami if needed.
  4. condor_submit testjob.sub
  5. you can see the vm boot by checking cloud_status -m
 \ No newline at end of file

Revision 32013-04-26 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
Deleted:
<
<
 -- ColinLeavettBrown - 2013-04-25

NEP52-RPI Documentation

Line: 5 to 4
 

NEP52-RPI Documentation

Added:
>
>
 

Introduction

NEP52 provides a powerful, scalable batch processing capability to the Research Platform Initiative (RPI). This function is enabled through the following Virtual Machine (VM) images:

  • NEP52-cloud-scheduler.v1 - This VM hosts Cloud Scheduler, a service to auto-provision VMs, together with its HTCondor batch job scheduling environment. In addition, this node provides user login capabilities to allow users to submit their workload to the scheduler for execution, monitor and retrieve their results.
  • NEP52-cvmfs-server.v1 - Provides a software distribution appliance VM that can host and distribute software for multiple VMs and VM types. The VM provided contains only one simple demonstration application and should be considered a template for building efficient, project specific software repositories. Using this server in a project can greatly reduce image sizes and improve image and software propagation efficiency.
  • NEP52-batch-cvmfs-client.v1 - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.
\ No newline at end of file
Added:
>
>

Procedures:

Launching Cloud Scheduler

Running your first job

Revision 22013-04-26 - crlb

Line: 1 to 1
 
META TOPICPARENT name="ColinLeavettBrown"
Deleted:
<
<
 -- ColinLeavettBrown - 2013-04-25

NEP52-RPI Documentation

Line: 6 to 5
 

NEP52-RPI Documentation

Changed:
<
<

With the contribution of three Virtual Machine (VM) images, the NEP52 project is enabling a powerful batch processing capability for cloud environments. The images are as follows:

>
>

Introduction

NEP52 provides a powerful, scalable batch processing capability to the Research Platform Initiative (RPI). This function is enabled through the following Virtual Machine (VM) images:

 
Changed:
<
<
  • NEP52-cloud-scheduler.v1 - This virtual machine
  • NEP52-cvmfs-server.v1
  • NEP52-batch-cvmfs-client.v1
>
>
  • NEP52-cloud-scheduler.v1 - This VM hosts Cloud Scheduler, a service to auto-provision VMs, together with its HTCondor batch job scheduling environment. In addition, this node provides user login capabilities to allow users to submit their workload to the scheduler for execution, monitor and retrieve their results.
  • NEP52-cvmfs-server.v1 - Provides a software distribution appliance VM that can host and distribute software for multiple VMs and VM types. The VM provided contains only one simple demonstration application and should be considered a template for building efficient, project specific software repositories. Using this server in a project can greatly reduce image sizes and improve image and software propagation efficiency.
  • NEP52-batch-cvmfs-client.v1 - This VM provides a minimal Scientific Linux 6.3 kernel installation for both interactive and batch processing. It has been configured to access software from a CVMFS server and, if instantiated by Cloud Scheduler, to register with a HTCondor batch scheduler and run batch jobs.
 \ No newline at end of file

Revision 12013-04-25 - crlb

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="ColinLeavettBrown"

-- ColinLeavettBrown - 2013-04-25

NEP52-RPI Documentation

With the contribution of three Virtual Machine (VM) images, the NEP52 project is enabling a powerful batch processing capability for cloud environments. The images are as follows:

  • NEP52-cloud-scheduler.v1 - This virtual machine
  • NEP52-cvmfs-server.v1
  • NEP52-batch-cvmfs-client.v1
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback