The RIS Compute Service is fundamentally built around Docker Containers. Docker is a container platform (see Why Docker? and What is a Container?) designed to make it easier to build and deploy software runtime environments. Users of the RIS Compute Service will be called upon to learn about Docker and its related concepts and technologies.

The Computing service is about building and executing Docker container images. While the RIS computing environment does offer ways to build containers (see Docker and the RIS Compute Service), it should be understood that users will oftentimes want their own computing environment, be that a Linux, MacOS, or Windows computing environment with which to build and work with Docker containers and Dockerfiles.

Furthermore, containers require a container registry to store the container images one builds. RIS does plan on offering a container registry service, but it is assumed that users will interact with public registries like Docker Hub.

The Compute service requires an understanding of these container technologies as well as a significant understanding of the Linux command line and related open source technologies, as well as high performance computing job schedulers.

Users of the service:

• Agree to install Docker on their own computing workstation or laptop.

• Agree to obtain accounts on Docker Hub or other public container registries.

• Acknowledge that they will be learning Docker container technologies.

• Acknowledge that they will be learning the Linux command line.

• Acknowledge that they will be learning the IBM Spectrum LSF job scheduler.

• Acknowledge that they will using a shared computing environment and that their workloads may impact others.

• Agree to be mindful of their workloads and strive to work with RIS if and when workloads negatively impact the cluster.

The use of Docker containers affords users the ability to run any software that can be built into a container. This is not fundamentally different than running arbitrary code downloaded from the Internet, which has been possible in any shared computing environment.

Users:

• Acknowledge the risks of running code obtained from unverified sources.

Use of Research Storage is primarily for research data which may include information that is classified as confidential and protected. Users of the storage who are unsure of the sensitivity of the data they intend to store should refer to the University’s information classification policies (See the information classification policy.) or contact the information security office at infosec@wustl.edu for guidance.

Information in the protected class is required by agency regulation and university policy to be encrypted in transit and at rest. Sensitive information in the Research Storage is not to be removed to unprotected networks and computing resources. It is required to be encrypted if it is not in an approved university data center, on a mobile device or other computing system. See the encryption policy.

It is the responsibility of the storage user to ensure adequate protection of the information at all times when using this service.

Users of this service:

• Agree to store only data that pertains to official business and is authorized to be stored within the service.

• Agree to ensure that sensitive information stored within the service is restricted to authorized team members on a need-to-know basis.

• Agree to ensure that access to sensitive data is based on your role or research.

• Agree to not retrieve information for someone who does not have authorization to access that information.

• Agree to ensure that Confidential and Protected information is protected against unauthorized access using encryption, according to Washington University Information Security Policy, when sending it via electronic means (telecommunications networks, e-mail, and/or facsimile) or storing it outside of protected networks (Note1) and devices (Note2). (See the encryption policy.)

• Agree to coordinate your user access requirements, and user access parameters, with the Research Infrastructure Services (RIS) WashU IT group.

• Agree to notify the service provider (RIS) if access to the storage resources is beyond that which you or they have authorized.

• Agree to report all security incidents or suspected incidents to the RIS (ris@wustl.edu) and/or INFOSEC. (infosec@wustl.edu)

• Agree to discontinue use of the service from any resources that show signs of being infected by a virus or other malware and report the suspected incident.

• Agree to safeguard storage resources against waste, loss, abuse, unauthorized users, and misappropriation.

• Agree to ensure that hard or electronic copies of Confidential and Protected information are destroyed after it is no longer needed. (See See the media reuse and disposal policy.)

• Agree to not store U.S. classified national security information or Controlled Unclassified Information (CUI) on the service.

• Agree to the monitoring of your use of this service for any violations of the above.

An unprotected network or networks with insufficient protection include any network other than WUCON or a High Trust Domain. Consult with the RIS or INFOSEC groups, if you do not know what network you are on or where the data will reside.

Any device that stores protected information and does not encrypt the information and does not have a password/passcode is considered unsafe and in violation of policy.

Details

• The general queue runs batch jobs much like the traditional HPC setting. They run in the background in the queue system.

• The general queue also makes use of cache system, which you can learn more about here.

• Jobs in the general queue can run for up to 28 days.

Policies

• The general queue falls under the fair use policy found in the Compute1 User Agreement.

• The general queue is for running jobs with large amounts of resource requirements.

• The general queue is for running large numbers of jobs, especially the same analysis on multiple samples.

• The general queue is NOT for GUI related software or interactive sessions.

Details

• The general-interactive queue runs jobs interactively so that you can interact directly with them or watch a job.

• The general-interactive queue does not use the cache system and instead interfaces with the Storage Platform directly.

• Jobs in the general-interactive queue can run for up to 24 hours.

Policies

• The general-interactive queue falls under the fair use policy found in the Compute1 User Agreement.

• The general-interactive queue is for running interactive jobs.

• The general-interactive queue is for GUI related software.

• The general-interactive queue is for software and script development.

• The general-interactive queue is NOT for jobs that require large amounts of resource requirements.

• The general-interactive queue is NOT for multiple jobs running the same analysis on multiple samples.

Details

• A subscription tier is associated with a number of resources that are guaranteed for use based on the tier.

• There are currently three subscription tiers.

• Tier 1 Resources

  • 25 vCPUs

  • 1 GPU

• Tier 2 Resources

  • 50 vCPUs

  • 2 GPU

• Tier 3 Resources

  • 100 vCPUs

  • 3 GPU

• If you go over on the number of guaranteed vCPUs for a job submitted in this queue type, your job will not be guaranteed to run.

• If you go over on the number of guaranteed GPUs for a job submitted in this queue type, the job will stay in pending and never run.

• The -sla option is required for jobs submitted in this queue type.

Policies

• The subscription queue falls under the Compute1 User Agreement.

• Usage policies are relegated by the owner of the subscription and is monitored by them.