blog-ryan

One of the common challenges related to running engineering simulations in the cloud is trying to leverage an existing license. Many applications will periodically connect to a license server in order to checkout license tokens. Typically, companies will have a license server running on premise, sitting behind the corporate firewall. ISVs will provision licenses that are locked to single machine in order to prevent unauthorized duplication and thus it is not possible to “lift and shift” the license server into the cloud due to this hardware dependency. The challenge then is how to securely allow clusters launched in the cloud to communicate with the license server sitting on premise.

The most robust way of making an on-premise license server available to cloud instances is to setup a VPN connection to the cloud provider. However, setting up a VPN is something that typically requires corporate IT involvement and approval. This is a process that could very easily take several weeks to resolve. Are there any easier, secure alternatives available to engineers on a tight deadline?

One attractive option is to leverage SSH. Rather than modifying the corporate firewall to allow inbound connections from the cloud, we can create a reverse SSH tunnel that makes an outbound connection to a secured license proxy server instead. Then, cloud instances can be configured to connect to the license proxy server and traffic will flow through to the license server sitting behind the firewall. There are several benefits to this approach:

  1. All data being sent over the wire is encrypted since we are using SSH.
  2. No firewall modifications are needed. Outbound SSH access is typically permitted in most corporate environments.
  3. The customer is in complete control of the connection. The tunnel can be shutdown at any time and all access to the on-premise license server from the cloud instances is severed at that point.

The following diagram depicts the reverse SSH tunnel configuration. The license proxy server and all of the cloud instances can freely communicate with each other but are walled off to everyone else. The license proxy server can be configured to allow inbound SSH access from a set of IPs controlled by the company.

Ryan 1

Let’s look at a sample FlexLM configuration as a concrete example. With FlexLM there are two ports that need to be mapped: the vendor daemon port and the license server port. These ports can vary depending on the installation but for the purposes of this example, assume they are set to 7701 and 32916 respectively.

First, upon request, Rescale can deploy a license proxy and provide the private key, username, and host information to the company.

Then, once the vendor daemon and license server port information is determined, the following SSH command can be run from Joe Engineer’s workstation, which is sitting behind the firewall and has access to the on-premise license server:

This command will route TCP traffic sent to port 7701 on the license proxy to port 7701 on the company’s license server. Similarly, TCP traffic sent to port 32916 on the proxy will be forwarded to port 32916 on the license server. After the command is run, the user can submit jobs through the Rescale user interface and point the FlexLM environment variable to the license proxy. To do this, select an application from your Rescale job’s Software Settings page and check the Provide Existing License box. Then, enter the license server port (32916 in our example) and the hostname of the license proxy (company-proxy.rescale.com) in the following format 32916@company-proxy.rescale.com.

Ryan 2

In the above screenshot, the LM_LICENSE_FILE environment variable and the port@hostname format is being used to specify the license server. Please note that this can vary depending on the selected application.

Please don’t hesitate to contact us at support@rescale.com if you are interested in learning more about license server connectivity options.

This article was written by Ryan Kaneshiro.

visualization

The Challenge of Remote Visualization

We have received many requests to integrate some type of visualization solution on Rescale. At Rescale, we agree that this is an important part of some engineering work flows. However, performing visualization in the cloud, doing it securely, and in a user-friendly way is not an easy task.

We do not want to provide a solution where our customers have to follow a complicated script to make it all work on their end. We do want to provide a wide range of solutions for a wide range of applications. These applications include, pre-processing, job progress monitoring, optimization status tracking and post-processing. We want to provide third party pre- and post-processing solutions such as FEMAP, Tecplot, Ensight, and Paraview to our customers as well as making native GUIs of software like Star-CCM+, ANSYS, and AVL FIRE available. Bringing all these solutions to our customers are wrought with challenges such as network performance, handling large data sets, and utilizing GPUs for 3D visualization.

An Incremental Process

Because of all the challenges involved, we want to make integrating these visualization solutions an incremental process. We have decided to start off with providing a basic remote desktop solution to a visualization node which can be provisioned as part of the hardware for a Rescale job. This visualization node will have access to all the files on each machine associated to the Rescale job through a shared file system. Our user can then access this visualization node through SSH, or access the remote desktop using VNC over SSH.

Of course, we do not want to reinvent the wheel. There are already several software-based solutions out there which provide excellent remote visualization technology. For example, Paraview and many other software provide server-client visualization solutions, which perform fairly well. Our second incremental step is making these solutions available to Rescale users.

Finally, we want to improve the overall user experience for everyone. Not everyone wants to perform computationally expensive post-processing. Some only want to track the progress of their job in a GUI that is familiar to them, some may just want to reduce the size of a large data set to minimize transfer costs and some may want to make small changes to their job setup and then rerun their job. We want to provide the capability to perform all these tasks on remote visualization.

A Remote Visualization Preview

Our initial step is to provide a simple remote desktop solution using VNC over SSH. Our solution is currently not available to everyone. If you would like to test drive the remote visualization solution, please contact support@rescale.com.

The following is a short example of using this solution with RFD tNavigator on Rescale.

The first step is to set up an SSH key and is described in a previous blog post.

Having set up a key, the job should be set up as normal. The only difference is that on the hardware selection page our users will be able to select a remote visualization hardware configuration from a set of predefined configurations. If a configuration is selected, an additional node will be provisioned for visualization.

Image 1

 

Once the clusters have started, a tunneling command will be printed to the screen. This command can be copied and pasted in a shell terminal.

Presentation2

 

Once the tunnel has been established, the visualization node can be accessed at vnc://localhost:5901/. The VNC password is ‘rescale’.

Presentation3

To bring up the tNavigator GUI, we can open up a shell and type in tnav-gui, which will launch the GUI. The job files are located in /enc/mount/<ip-of-compute-cluster>/work. There will be one directory in /enc/mount for each compute cluster in the job.

Presentation4

Using the tNavigator GUI, we can now visualize the in-progress job.

Presentation5

Here are some more samples of remote visualization on Rescale:

Presentation6

CONVERGE

Presentation7

HEEDS

Presentation8

LS-Pre/Post

Help us improve remote visualization.

We’d love to hear about what features are important to you when using remote visualization. Please let us know at support@rescale.com.

 

This article was written by Mulyanto Poort.