Cloudify HPC Plugin
A HPC plugin for Cloudify that enables it to manage HPC resources in one or more infrastructures. The currently supported resource types are described below.
This plugin is part of the MSO4SC H2020 European Project.
💡
|
Example blueprints can be found at the MSO4SC resources repository. |
Overview
The plugin aims to enable Cloudify to manage HPC resources, so at the end, combined with other plugins, it can orchestrate a hybrid cloud+hpc environment, with one or more cloud and hpc providerds at the same time.
It adds a new resource type, hpc.nodes.Compute, that represents a HPC infrastructure, and [hpc.nodes.job] and [hpc.nodes.singularity_job], that represents a job in the HPC and a job using a Singularity container respectively.
In order to Cloudify orchestrates properly the HPC resources, the help of an external monitor system is needed, from which the job status is retrieved. In the next release the plugin will also use the monitor to predict the overall state of the HPC and take best decisions about which partition and infrastructure to use for each job.
❗
|
Only Slurm based HPCs are supported for now as well as only Prometheus is supported as monitoring system. |
Plugin Requirements
-
Python version 2.7.x
-
Access to at least a Slurm based HPC by ssh user & password.
-
Prometheus monitoring the infrastructures to be used (Slurm exporter has been developed for this purpose)
Optional:
-
The Monitor Orchestrator can be deployed in the same host as the monitor to allow the plugin to dynamically use new HPC infrastructures defined in TOSCA.
-
Grafana can be used to visualize the status of the HPCs.
Installation & Usage
The plugin is installed as any other plugin. Check Cloudify Docs for general information about how to install and use Cloudify, and this section for concrete information about using plugins.
Additionally MSO4SC provide Vagrant and Docker images at Docker Hub to install everything. Check MSOOrchestrator-CLI to start using Cloudify CLI and bootstrap the Cloudify Manager. Use docker compose file to deploy all the external components. A Grafana dashboard can be found here.
HPC Plugin Configuration
The HPC plugin requires credentials, endpoint and other setup information in order to authenticate and interact with them.
Providing Credentials as Secrets
|
Not yet implemented |
Providing Credentials as Environment Variables that are not Stored as Secrets
If you do not use secret storage, you must provide the following credentials as properties (in the blueprint or as input):
HPC_config:
credentials:
host: "[HPC-HOST]"
user: "[HPC-SSH-USER]"
password: "[HPC-SSH-PASS]"
country_tz: "Europe/Madrid"
workload_manager: "SLURM"
This configuration properties are passed then to hpc.nodes.Compute config properties.
-
credentials: HPC and ssh credentials
-
country_tz: Country Time Zone configured in the the HPC.
-
workload_manager: Workload manager used by the HPC.
|
Only Slurm is currently accepted as workload manager. |
Types
This section describes the node type definitions. Nodes describe resources in your HPC infrastructures. For more information, see node type.
hpc.nodes.Compute
Derived From: cloudify.nodes.Compute
Use this type to describe a HPC infrastructure.
Properties:
-
config
: HPC configuration, as described in Providing Credentials as Environment Variables that are not Stored as Secrets. -
external_monitor_entrypoint
: Entrypoint of the external monitor that Cloudify will use instead of the internal one. -
external_monitor_port
: Port of the monitor. Default:9090
. -
external_monitor_type
: Specific monitor tool. DefaultPROMETHEUS
. -
external_monitor_orchestrator_port
: Monitor orchestrator port. Default:8079
. -
job_prefix
: Job name prefix for the jobs created in this HPC. Defaultcfyhpc
. -
base_dir
: Root directory in which to run the executions in this ifrastructure. Default$HOME
. -
workdir_prefix
: Prefix name of the working directory that will be created for this infrastructure. -
skip_cleanup
: True to not clean all files when destroying the deployment. DefaultFalse
. -
simulate
: If true, don’t send the jobs to the HPC and simulate that they finish inmediately. Useful for test new TOSCA files. DefaultFalse
.
Example
This example demonstrates how to add a new HPC.
hpc_node:
type: hpc.nodes.Compute
properties:
config:
credentials:
host: "[HPC-HOST]"
user: "[HPC-SSH-USER]"
password: "[HPC-SSH-PASS]"
country_tz: "Europe/Madrid"
workload_manager: "SLURM"
job_prefix: hpc_
workdir_prefix: test
...
Mapped Operations:
-
cloudify.interfaces.lifecycle.start
Checks that there is connection between Cloudify and the HPC, and creates a new working directory. -
cloudify.interfaces.lifecycle.stop
Clean up all data generated by the execution. -
cloudify.interfaces.monitoring.start
If the external monitor orchestrator is available, sends a notification to start monitoring the HPC. -
cloudify.interfaces.monitoring.stop
If the external monitor orchestrator is available, sends a notification to end monitoring the HPC.
hpc.nodes.job
Derived From: {uri-cloudify-builtin-type}[cloudify.nodes.Root]
Use this tipe to describe a HPC job.
Properties:
-
job_options
: Job parameters and needed resources.-
type
: SRUN or SBATCH (job executed using a command or using a script). -
modules
: List of modules that will be load before executing the job. Optional. -
partition
: Partition in which the job will be executed. If not provided, the HPC default will be used. -
command
: Job executable command with arguments if necessary. Mandatory. -
nodes
: Necessary nodes of the job. Default1
. -
tasks
: Number of tasks of the job. Default1
. -
tasks_per_node
: Number of tasks per node. Default1
. -
max_time
: Set a limit on the total run time of the job allocation. Mandatory if SRUN type. -
scale
: Execute in parallel the job N times according to this property. Only works with SBATCH jobs. Default1
(no scale). -
scale_max_in_parallel
: Maximum number of scaled job instances that can be run in parallel. Only works with scale >1
. Default same as scale. -
memory
: Specify the real memory required per node. Different units can be specified using the suffix [K|M|G|T
]. Default value""
lets the workload manager assign the default memory to the job. -
stdout_file
: Define the file where to gather the standard output of the job. Default value""
sets<job-name>.err
filename. -
stderr_file
: Define the file where to gather the standard error output. Default value""
sets<job-name>.out
filename. -
mail-user
: Email to receive notification of job state changes. Default value""
does not send any mail. -
mail-type
: Type of event to be notified by mail, can define several events separated by comma. Valid valuesNONE, BEGIN, END, FAIL, TIME_LIMIT, REQUEUE, ALL
. Default value""
does not send any mail. -
reservation
: Allocate resources for the job from the named reservation. Default value""
does not allocate from any named reservation. -
qos
: Request a quality of service for the job. Default value""
lets de workload manager assign the default userqos
.
-
-
deployment
: Scripts to perform deployment operations. Optional.-
bootstrap
: Relative path to blueprint to the script that will be executed in the HPC at the install workflow to bootstrap the job (like data movements, binary download, etc.) -
revert
: Relative path to blueprint to the script that will be executed in the HPC at the uninstall workflow, reverting the bootstrap or other clean up operations. -
inputs
: List of inputs that will be passed to the scripts when executed in the HPC.
-
-
skip_cleanup
: Set to true to not clean up orchestrator auxiliar files. DefaultFalse
.
ℹ️
|
The variable $CURRENT_WORKDIR is available in all operations and scripts. It points to the working directory of the execution in the HPC from the HOME directory: /home/user/$CURRENT_WORKDIR/ .
|
ℹ️
|
The variables $SCALE_INDEX , $SCALE_COUNT and $SCALE_MAX will be available in the batch script if the line # DYNAMIC VARIABLES exist (they will be dynamicaly loaded after this line). They hold, for each job instance, the index, the total number of instances, and the maximun in parallel respectively.
|
Example
This example demonstrates how to describe a new job.
hpc_job:
type: hpc.nodes.job
properties:
job_options:
type: 'SRUN'
modules:
- gcc/5.3.0
partition: 'thin-shared'
command: 'touch example.test'
nodes: 1
tasks: 1
tasks_per_node: 1
max_time: '00:01:00'
deployment:
bootstrap: 'scripts/bootstrap_example.sh'
revert: 'scripts/revert_example.sh'
inputs:
- 'example_job'
...
Mapped Operations:
-
cloudify.interfaces.lifecycle.start
Send and execute the bootstrap script. -
cloudify.interfaces.lifecycle.stop
Send and execute the revert script. -
hpc.interfaces.lifecycle.queue
Queues the job in the HPC. -
hpc.interfaces.lifecycle.cleanup
Clean up operations after job is finished. -
hpc.interfaces.lifecycle.cancel
Cancels a queued job.
hpc.nodes.singularity_job
Derived From: [hpc.nodes.job]
Use this tipe to describe a HPC job executed from a Singularity image.
Properties:
-
job_options
: Job parameters and needed resources.-
modules
: List of modules that will be load before executing the job. Optional. -
image
: Singularity image file. -
home
: Home volume that will be bind with the image instance (Optional). -
volumes
: List of volumes that will be bind with the image instance. -
partition
: Partition in which the job will be executed. If not provided, the HPC default will be used. -
nodes
: Necessary nodes of the job. 1 by default. -
tasks
: Number of tasks of the job. 1 by default. -
tasks_per_node
: Number of tasks per node. 1 by default. -
max_time
: Set a limit on the total run time of the job allocation. Mandatory if SRUN type. -
scale
: Execute in parallel the job N times according to this property. Default1
(no scale). -
scale_max_in_parallel
: Maximum number of scaled job instances that can be run in parallel. Only works with scale >1
. Default same as scale. -
memory
: Specify the real memory required per node. Different units can be specified using the suffix [K|M|G|T
]. Default value""
lets the workload manager assign the default memory to the job. -
stdout_file
: Define the file where to gather the standard output of the job. Default value""
sets<job-name>.err
filename. -
stderr_file
: Define the file where to gather the standard error output. Default value""
sets<job-name>.out
filename. -
mail-user
: Email to receive notification of job state changes. Default value""
does not send any mail. -
mail-type
: Type of event to be notified by mail, can define several events separated by comma. Valid valuesNONE, BEGIN, END, FAIL, TIME_LIMIT, REQUEUE, ALL
. Default value""
does not send any mail. -
reservation
: Allocate resources for the job from the named reservation. Default value""
does not allocate from any named reservation. -
qos
: Request a quality of service for the job. Default value""
lets de workload manager assign the default userqos
.
-
-
deployment
: Optional scripts to perform deployment operations (bootstrap and revert).-
bootstrap
: Relative path to blueprint to the script that will be executed in the HPC at the install workflow to bootstrap the job (like image download, data movements, etc.) -
revert
: Relative path to blueprint to the script that will be executed in the HPC at the uninstall workflow, reverting the bootstrap or other clean up operations (like removing the image). -
inputs
: List of inputs that will be passed to the scripts when executed in the HPC
-
-
skip_cleanup
: Set to true to not clean up orchestrator auxiliar files. DefaultFalse
.
ℹ️
|
The variable $CURRENT_WORKDIR is available in all operations and scripts. It points to the working directory of the execution in the HPC from the HOME directory: /home/user/$CURRENT_WORKDIR/ .
|
ℹ️
|
The variables $SCALE_INDEX, $SCALE_COUNT and $SCALE_MAX are available when scaling, holding for each job instance the index, the total number of instances, and the maximun in parallel respectively. |
Example
This example demonstrates how to describe a new job executed in a Singularity instance.
singularity_job:
type: hpc.nodes.singularity_job
properties:
job_options:
modules:
- gcc/5.3.0
- openmpi/1.10.2
- singularity/2.3.1
partition: 'thin-shared'
image: '$LUSTRE/openmpi_1.10.7_ring.img'
home: '$HOME:/home/$USER'
volumes:
- '/scratch'
command: 'ring > fourth_example_3.test'
nodes: 1
tasks: 1
tasks_per_node: 1
max_time: '00:01:00'
deployment:
bootstrap: 'scripts/singularity_bootstrap_example.sh'
revert: 'scripts/singularity_revert_example.sh'
inputs:
- 'singularity_job'
...
Mapped Operations:
-
cloudify.interfaces.lifecycle.start
Send and execute the bootstrap script. -
cloudify.interfaces.lifecycle.stop
Send and execute the revert script. -
hpc.interfaces.lifecycle.queue
Queues the job in the HPC. -
hpc.interfaces.lifecycle.cleanup
Clean up operations after job is finished. -
hpc.interfaces.lifecycle.cancel
Cancels a queued job.
Relationships
See the relationships section.
The following plugin relationship operations are defined in the HPC plugin:
-
job_contained_in_hpc
Sets a hpc.nodes.Compute to be executed inside the target HPC. -
job_depends_on
Sets a hpc.nodes.Compute as a dependency of the target, so the target job needs to finish before the source can start.
Tests
To run the tests Cloudify CLI has to be installed locally. Example blueprints can be found at tests/blueprint folder and have the simulate
option active by default. Blueprint to be tested can be changed at workflows_tests.py in the tests folder.
To run the tests against a real HPC / Monitor system, copy the file blueprint-inputs.yaml to local-blueprint-inputs.yaml and edit with your credentials. Then edit the blueprint commenting the simulate option, and other parameters as you wish (e.g change the name ft2_node for your own hpc name).
ℹ️
|
dev-requirements.txt needs to be installed (windev-requirements.txt for windows): pip install -r dev-requirements.txt To run the tests, run tox on the root folder tox -e flake8,py27 |