remote-access
Introduction

Rescale has recently released additional user account job settings, which provide customers with the ability to securely connect to the remote clusters that they have provisioned in order to monitor or manage their running simulations more directly.

Users of HPC simulation tools can typically relate to the scenario wherein an analysis model is run for the first time, but the solver crashes for any number of reasons upon initializing the model’s computational domain and beginning the iterative solution. Another situation that users commonly encounter is one whereby a job has been submitted but is missing a requisite input file or an input parameter is set to an inappropriate value. Having the ability to login to the cluster directly enables users to more economically resolve these and similar issues when leveraging Rescale’s HPC platform.

Configuring your account settings on Rescale is straightforward and involves the following four steps:

Generating an SSH key pair
Adding the SSH public key to your Rescale account
Disabling the automatic termination of clusters option in your Rescale account’s job settings
Logging into a running cluster

Generating an SSH Key Pair

This section highlights for users of both *nix and Windows OS environments how to generate OpenSSH key pairs. If you’re familiar with SSH key generation, or have already generated a key pair previously that you use regularly, then you can skip ahead to the next section.

For users of *nix based operating systems, a command line utility exists named ssh-keygen that can be used to generate these public and private SSH keys from a shell prompt with the following:

Invoking this command will begin generating both public and private keys and prompt you for a location and filename on your local filesystem where you wish to store both keys. Alternatively, you can pass the ssh-keygen command the -f flag along with a path on your local filesystem where you want to store the keys (e.g. /home/rescale/Desktop/id- rsa) as its argument. Using this example, the private key file named id-rsa and the public key file named id- rsa.pub are both saved to subdirectory Desktop of user rescale’s home directory. If you omit the -f flag altogether, then you can opt to use the default which will place both id-rsa and id-rsa.pub files in a subdirectory of your home folder named .ssh (e.g. /home/rescale/.ssh).

You are also prompted to set a passphrase, and again to verify this passphrase, which is then used each time the public key is substantiated with the private key. By default, setting this passphrase is ignored, and doing so is typically preferred to avoid any hassle of entering this passphrase when logging into a remote host. Once the ssh-keygen command line utility has completed, then a 2048 bit RSA key pair should have been generated, and both private and public keys stored in their respective files at the location in your filesystem that was specified.

terminal_output

Figure 1: Generating SSH key pairs in a *nix OS

The options used to create the SSH keys—key type (RSA) and the number of bits created in the key (2048)—happen to correspond to the defaults used when invoking the ssh-keygen utility from a shell command prompt. As a result, equivalent keys could have been generated by just invoking ssh-keygen by itself at the shell prompt. These options have been highlighted here to inform end-users of options they may wish to leverage when generating their own keys. For example, those conscientious about security may wish to generate a 4096 bit key instead of the 2048 bit key used in this example. Note that if users opt for generating DSA keys rather than RSA keys, then they are limited to using exactly 1024 bit keys as specified by FIPS 186-2.

On Windows systems, there are a number of options available for generating an OpenSSH key pair. One popular tool that users typically have available on their systems is PuTTY. If not already installed, it is easy to download and straightforward to install. Once installed, start the puttygen.exe executable. In the section of The PuTTYGen window labeled “Parameters”, click the radio button next to SSH-2 RSA and enter the value 2048 in the field next to “Number of bits in a generated key:” as illustrated in Fig. 2.

Once both parameters have been set as described, then click the button labeled “Generate” in the “Actions” section of the window to begin producing the SSH key pair.  Users are next prompted to move their mouse cursor inside of the designated “blank” area within the PuTTYGen window to introduce some randomness into the key generation process. Continue moving the mouse in the designated area of the window until the blue progress bar indicates that key generation has completed. Finally, save both public and private keys to separate files on the local filesystem using the corresponding buttons located in the “Actions” section of the PuTTYGen window.

Once both keys have been saved in their respective files, then users should ensure they safeguard the the private key and note its location on their local filesystem

putty1

Figure 2a: Generating OpenSSH key pair in Windows using PuTTY

putty2

Figure 2b: Saving public and private OpenSSH keys in Windows using PuTTY

Adding the SSH Public Key to your Rescale Account

Once an OpenSSH public and private key pair have been generated, users can log in to their Rescale accounts and navigate to the ”Job Settings” page via their user account menu as highlighted in Fig. 3.

account-menu

Figure 3a: Access the job settings page from your Rescale account menu

job-settings

Figure 3b: Copy your public SSH key into the field labeled “SSH Public Key”

Users can open the file that they saved the SSH public key in their preferred text editor, copy its contents, and paste the text into the field labeled “SSH Public Key” on the “Job” settings page. Users may optionally further restrict access to the cluster hosting their simulation by specifying a Classless Inter-Domain Routing (CIDR) rule to limit access to the cluster to either a single IP address or a range of IP addresses depending on a user’s preference. Rules can be easily generated to allow access from “Everywhere”, or “My Current IP Address” using the pull-down menu options available. Users can also create a custom rule by editing the “Access Restriction (CIDR)” field directly.

Disabling Automatic Termination of Clusters

Clusters that host a user’s running simulation are provisioned and configured on-demand. Once the simulation has completed running, the user’s runtime files are moved off of the cluster, and the cluster resources are shut down. If you’re troubleshooting issues with your simulation, you may want to avoid this automatic shut down behavior, so that you can login to the cluster directly, review and correct any issues that arise, and restart the simulation. In order to prevent the cluster from shutting down automatically, uncheck the box next to the option labeled “Terminate Clusters Automatically” at the very bottom of the “Job” settings page.

Note, that users disabling this option are responsible for terminating their clusters manually, and Rescale is not responsible for charges that accrue as a result of user forgetfulness which leaves the cluster running beyond the intended duration. Users should be mindful of the potential repercussions that may result when disabling this option.

Logging Into a Running Cluster on Rescale

Once your public SSH key has been added to your Rescale account’s job settings and you submit a new job, Rescale’s platform uploads the public SSH key associated with your account to the cluster that you provision. The job status message window will display the username and IP address of the head node for this cluster as depicted in Fig. 4.

job-logs

Figure 4: “Job Log” window on Rescale’s “Status” page

Using these credentials, users can login into the remote cluster directly. In *nix OS environments users can run the following command at a shell prompt:

Here <path-to-your-private-SSH-key-file> would be replaced with the corresponding UNIX filesystem path (e.g. /home/rescale/Desktop/id-rsa). If the SSH private key is located at $HOME/.ssh, then ssh will automatically look for private keys stored at that location and the -i flag with its path argument aren’t required. If users are interested in forwarding their remote X-Window display to their local display, then they can invoke the X11 forwarding feature built-in to ssh by passing the -Y flag to the above ssh command. This enables some basic interaction with GUI applications running on the remote cluster for customers if needed.

PuTTY is again utilized to demonstrate establishing the remote SSH connection for users in Windows OS environments. After launching putty.exe, users can specify the location of the private SSH key file stored on their local filesystem by navigating to the Connection -> SSH -> Auth pane and clicking on the “Browse…” button. Next return to the “Session” pane, ensure that the radio button next to SSH in the “Connection type” section is selected, enter the username and IP address provided via Rescale’s job status log message window into PuTTY’s field labeled “Host Name (or IP address)” (e.g. zach_Gcaaa@54.91.153.220), and finally click on the button labeled “Open”. A remote connection session window should open and login to the remote cluster using the credentials provided.

Once your simulation has completed running, be sure to transfer any runtime files back to your local environment, and be sure to click the “Terminate” button on the “Status” page for that particular job to avoid incurring any additional charges.

This article was written by Zach Davis.

too-hot-too-cold-a

Within offices, there is a constant struggle between turning the air conditioner on or off, as well as raising or lowering the thermostat’s temperature. This makes some too warm, while others put on additional layers of clothing just to maintain their warmth. This battle over the thermostat rages on even as the seasons change!

We will make Rescale our sample environment  and take the  initiative to explore the flow of our office’s airflow and temperature distribution. In particular, the goal is to identify a simple and easy way to implement a configuration that will make most people in the office happy and end the manual “tug-of-war”!

For those only looking for the conclusion, Figure 1 below shows the distribution of temperature for the five different air conditioning configurations. The resolution to this problem may be to try case 2 or 3. For those interested in how this conclusion is reached, read on.

dist2

Figure 1: The distribution of temperature 1 meter off the floor.

Cloud Solution
The Rescale office has six vents and each vent can be completely closed or opened–or positioned in any state in between. It is also possible to change temperature as well as to vent out  air to the outside. We limit this vast combination of states by fixing the temperature to a constant and only varying the vent flow velocity to 0.1 m/s or 1 m/s. We will leverage the design of experiment (DOE) capability of Rescale to explore the solution space. Creating your own six vent flow velocity variable will create 64 (26) runs. We can rule out most cases, including all vents flowing at 0.1 m/s and those having a skewed condition, such as the first three vents having a low velocity and rest of the vents having a high velocity. The five chosen cases are shown in the table below.

Case/Vent 1 2 3 4 5 6
1 1 1 1 1 1 1
2 1 1 0.1 1 1 1
3 1 1 0.1 0.1 1 1
4 0.1 1 0.1 1 1 1
5 0.1 1 0.1 0.1 1 1
vents

Figure 2: Vent positions on the office floor.

The analysis was done using OpenFOAM 2.3 and each run took 40 minutes on 8 cores. To complete the run faster, two slots (parallel executions) were used; all five runs took 2 hours to complete. The rest of the figures are the solutions for each of the five cases.

1

Figure 3: The streamlines correspond to the airflow while the varying colors represent temperature differences for Case 1.

2

Figure 4: The airflow and temperature differences for Case 2.

3

Figure 5: The airflow and temperature differences for Case 3.

4

Figure 6: The airflow and temperature differences for Case 4.

5

Figure 7: The airflow and temperature differences for Case 5.

Case 1 is the coldest of all the cases we could expect and serves a reference point to compare all other results. Cases 4 and 5 are polarizations of hot and cold ends where one side turns on the air conditioning while the other side turns it off–leading to situations we wish to avoid. The cases where we see a better temperature distribution are Case 2 and Case 3.

Whether a solution will be implemented is yet to be determined–potential additional work could include an optimizer wrapping the CFD analysis. But this was a first step towards ending the fight over the thermostat.

This article was written by Hiraku Nakamura.