Introduction to the JASMIN Cloud

In addition to the traditional batch computing (LOTUS) and storage (Group Workspaces) services, JASMIN also provides a cloud computing service.

Many users will already be familiar with cloud services through the use of one of the large public providers (e.g. Amazon AWS or Microsoft Azure). The JASMIN Cloud is similar in that it allows an institution or project to consume compute resources as a utility, with no need to provision and maintain the associated physical infrastructure. Users can provision their own virtual machines (VMs), allowing for greater flexibility. The JASMIN Cloud also allows users to provision clusters using the Azimuth Portal.

Cloud terminology  

Different cloud providers have different terms for the users within their cloud and the chunks of resource they have been allocated. In the JASMIN Cloud documentation, we will use the following terminology:

JASMIN Cloud Architecture  

The JASMIN Cloud is hosted on the STFC Cloud  , a dedicated cloud infrastructure provided by STFC for STFC staff and partner organisations. It is operated by the STFC Scientific Computing Department  .

Tenants are primarily expected to use the JASMIN Azimuth Portal to administer their tenancies for creating machines, volumes, clusters etc. Tenants can also log into STFC Cloud’s Horizon Portal  , and use the OpenStack API and CLI tools to manage resources.

Tenants are allowed root access and have complete responsibility for all system administration tasks. This means that tenants are able to provision their own infrastructure (e.g. web portals, remote desktop services), but it also means that tenants are responsible for the security of their machines (e.g. patching, firewall configuration) and for managing their own users. The Azimuth Platform also provides “Platforms” which are Platform-as-a-Service offerings that tenants can use to deploy clusters such as:

• Kubernetes clusters
• Jupyter Notebooks
• VMs with a web browser accessible shell and desktop

Each tenancy has its own local network, where machines have IP addresses in the range 192.168.3.0/24 - all machines in the tenancy can talk to each other on this network. In addition, each tenancy has an “edge device”, which is effectively a virtual router. Similar to your home broadband router, this allows machines within the tenancy to talk to machines outside the tenancy, and ensures packets coming back into the tenancy are forwarded to the correct machine. These “edge devices” also provide a Network Address Translation (NAT)  facility, which allows machines to be allocated an IP address that is visible outside of the tenancy.

Because we allow root access on cloud based VMs, tenancies in the JASMIN Cloud cannot access the JASMIN storage (including PFS, and SOF), and so there is no filesystem level access to the CEDA Archive or Group Workspaces - all access to these data is via the usual external interfaces (i.e. the Object Store, OpenDAP, HTTP).

Our Expectations from Tenants  

We expect Tenants to abide by the terms and conditions set out by JASMIN  , STFC Cloud  , and UKRI  . Importantly, this includes abiding by the patching policy  set out by UKRI.

We also expect tenants to adhere to good practices around machine lifecycle: patching machines and updating clusters regularly, and working in a reproducible way; i.e. treating machines as “cattle” not “pets”.

Patching and Machine Lifecycle  

Machines should be kept up to date and patched regularly, and also rebooted where required so that updates can be applied. The suggested interval for this is 6 weeks.

Machines should also be cycled out of production regularly. VMs should not be left to age for a number of reasons, primarily that older images are more vulnerable to security vulnerabilities. Older flavors are also cycled out of production, as is older hardware, so updating to newer images will improve the reliability of the machine.

Regularly cycling machines out of production also encourages the use of reproducible deployment methods to make deployments easier and faster.

Reproducible Deployments  

All services and workflows deployed in the JASMIN cloud should be deployed in a reproducible way. That is that the VMs themselves should be considered “cattle” rather than “pets”. There are a number of methods and technologies to do this which generally are considered Infrastructure-as-Code (IaC). These include: Ansible, Terraform, Docker, Cluster API, Kubernetes, and Helm.

The Azimuth Portal is able to provision Kubernetes Clusters which can be used to make machine lifecycle and reproducible deployments easier, including:

• deployments can be deployed with Helm charts, meaning that a deployment is a single command away from being redeployed or updated
• in event of machine loss, Kubernetes will redeploy the workload to another worker
• Azimuth Kubernetes clusters auto-heal and can auto-scale to dynamically create and replace worker nodes

More detail on suggested IaC technologies are available in the Best Practice section.

Documentation pages for some general advice are also available for Linux Administration, and OpenStack.

Getting a JASMIN Cloud Tenancy  

To start a conversation with us about getting a JASMIN Cloud Tenancy for your project, please contact JASMIN Support.