Intro

To leverage the computing power of pleiades, we port verdi to run bare-metal on pleiades and have it communicate with the HySDS cluster (a.k.a. PCM) on the Amazon Cloud to obtain jobs and submit results via the queues between the AWS Cloud and pleiades. The Docker virtualization system is considered unsafe for the shared supercomputer environment and therefore is not supported on pleiades. So verdi in its Docker form cannot be run directly on pleiades. Furthermore, all the PGEs in Docker containers have to be converted to singularity, another virtualization system that is allowed on pleiades. The porting of ARIA HySDS to pleiades consists of two major parts: (1) The container-builder. The Jenkins pipeline running on the ci (continuous integration) server triggers the new container-builder to, in addition to building the PGEs in the form of Docker containers, convert the Docker container into a singularity container, build a sandbox from the singularity container, and upload the singularity sandbox to the S3 storage; and (2) job_worker. The singularity extension dequeues jobs from Mozart on AWS, downloads the PGE in the form of a singularity sandbox from S3, forms the singularity exec command line, runs the PGE, and submit the results to GRQ on AWS.

Running HySDS Verdi Job Worker on Pleiades

HySDS PCM in AWS can also be used to control Verdi job workers in HECC cluster (e.g. Pleiades), AWS, on-premise. For Pleiades, the job workers can call home to PCM via VPN, ssh port tunnel, VPN, or AWS Transit Gateway.

The control of compute nodes in Pleiades is designed to parallel auto-scaling approach in AWS. We separate the queue from scaling logic, auto-scaler that sets desired nodes, from auto-scaling service, from the infrastructure itself. Here we use PBS as analogous to the auto-scaling service.

Open

The verdi job workers on Pleiades then can call back to PCM in AWS via secured tunnels using direct ssh passthrough as suggested by NAS. https://www.nas.nasa.gov/hecc/support/kb/setting-up-ssh-passthrough_232.html

Open

In this design, verdi job workers call home via secure ssh remote port tunnels through a head node to PCM components for rabbitmq, redis, ES, and REST API calls. But for all other larger traffic (e.g. AWS S3 transfer), the transfers are routed to a separate NAT head node

Verdi runs Singularity containers on Pleiades due to security restrictions on Pleiades not allowing Docker. see Job_worker-singularity

Compute node types available on Pleiades HECC

source: https://www.nas.nasa.gov/hecc/support/kb/pbs-resource-request-examples_188.html

Queues for Pleiades, Aitken, and Electra Users

source: https://www.nas.nasa.gov/hecc/support/kb/pbs-job-queue-structure_187.html

qstat -Q

Running Jobs Before Dedicated Time

source: https://www.nas.nasa.gov/hecc/support/kb/running-jobs-before-dedicated-time_306.html

The PBS batch scheduler supports a feature called shrink-to-fit (STF)

qsub -l min_walltime=6:00:00,max_walltime=168:00:00 job_worker-singularity.sh

This says if the Pleiades can fit 90-minute jobs, then go ahead and dispatch our PBS jobs for job_worker-singularity.sh

CLI to PBS

Quickly delete all running+queued jobs

qstat -r -q hysds > qstat.txt

PBS script

#PBS -l select=xx:ncpus=yy:model=zz

For Broadwell

#PBS -l select=10:ncpus=28:model=bro

For Haswell
#PBS -l select=10:ncpus=24:mpiprocs=24:model=has

For Ivy Bridge
#PBS -l select=12:ncpus=20:mpiprocs=20:model=ivy

For Sandy Bridge
#PBS -l select=15:ncpus=16:mpiprocs=16:model=san

Running one verdi per compute node with shrink-to-fit

use select=1 for 1-node per verdi job, but submit many with shrink-to-fit.

qsub -l min_walltime=2:00:00,max_walltime=168:00:00 job_worker-singularity.sh

This requests Pleiades to schedule verdi if have even 2-hours available. That would be enough time to run one nominal processing job.

where the job_worker-singularity.sh contains:

#PBS -l select=1:ncpus=28:model=bro

Setting hardware threads / cores for jobs

To complement the ncpu:N setting for PBS, can also export the environment variable OMP_NUM_THREADS

see https://www.nas.nasa.gov/hecc/support/kb/default-variables-set-by-pbs_189.html

Local RAM “drive” for faster scratch disk

On Pleiades, each compute node does not have any on-board disk storage (sImilar to AWS’s EBS-only EC2 instance types). Using this instead of NFS file system for work dir will significantly improve performance.

PBS jobs also have an available environment variable ${TMPDIR} in PBS job, which defaults to /tmp/pbs.job_id on the vnodes.

https://www.nas.nasa.gov/hecc/support/kb/pbs-environment-variables_178.html

NAS currently allocates about 50%-60% of node’s RAM to this ram drive. (it is observed that it varies by cluster)

Enable “auto-scaling”-like behavior with PBS

set_desire_worker.sh

mimics scale-out (scale up)

reference: https://www.nas.nasa.gov/hecc/support/kb/commonly-used-pbs-commands_174.html

Short-circuiting job worker if not enough time remaining to completed the next job

Recommendations for running on Pleiades:

1. Make fairly long time job requests

2. Short-circuiting job workers if not enough time remaining to completed the next jobs

At the beginning of a PBS job wrapper script (invoked by verdi job worker), check if the job has sufficient time allocation remaining to complete the max estimated duration of a job. This ensures that the running job has at least X hours left in the PBS job for the node running the job, and exiting the verdi job worker if the PBS job does not have sufficient time remaining to complete the estimated job duration.

Inside job worker, before the start of each job, delegate to check login on Pleiades if have enough time for at least the next job duration (2-hours). Can run qstat -f $PBS_JOBID and compare the output for resources_used.walltime and Resources_List.walltime to see how much time remains. If insufficient time, then the pbs wrapper script can sigterm gracefully the PID of verdi job worker to trigger verdi job worker to exit the process and therefore end the PBS node. have job worker gracefully exit.

Based on current metrics, topsapp-singularity generating one S1-GUNW takes a mean of 1.5 hours on Broadwell. So add some margin and use that as max. e.g. requiring at least 2-hours remaining for current PBS job. if not, then exit the PBS job.

@Lei.Pan@jpl.nasa.gov (Unlicensed) TODO

Auto-exit of verdi job workers--harikiri_pid

see: https://jira.jpl.nasa.gov/projects/ARIA/issues/ARIA-291?filter=doneissues

Adapted harikiri to detect done workers on pleiades

This should be based on adapting existing harikri agent that runs as thread in each verdi job worker script and determines when job worker has not more jobs and then kills the job worker process.

Could be as simple as pbs job worker script:

run job worker script in background mode
save its PID
run hariki (blocks) # hariki detects for no more jobs after 10-min wait, then sigterm kills PID of job worker running in background.exit for PBS job to exit.

scale-down being handled inside job_worker-singularity via harikari-pid.py.

see https://github.com/hysds/job_worker-singularity

What happens to the job worker when PBS kills the job?

On the verdi job worker that is running as a PBS job, when PBS kills the job (e.g. when the max time limit is reached), the verdi worker will gracefully exit. On HySDS PCM Mozrt/figaro, a WorkerLostError event is detected.

On the Pleiades verdi job worker log, we may see the following when PBS kills the job:

The two relevant log entries are:

Adaptations of HySDS/Pleiades

ARIA HySDS running Sentinel-1A/B S1-GUNW processing on Pleiades