Azure Implementation

In case Azure is the resource provider the "isolated environment" corresponds to a resource group. A resource group allows to bundle all resources corresponding to a certain deployment and, additionally, allows to limit authorization to just the resources included in the resource group. Thus, it is recommended to isolate a Virtual Cluster in its own resource group as described in this section.

In order to perform the following steps, the logged in user account needs to have permissions to

• create a resource group,
• (optional) register the Microsoft.DataProtection resource provider if you want to enable automated backups of the user home disk (recommended),
• create a network, subnets, NICs, instances, IP addresses, disks, and images in the resource group,
• assign a role to a service principal in the scope of the created resource group.

Please perform the following steps after logging in to the Azure portal.

Creation of Resource Group

Create a new resource group to which the Virtual Cluster can be deployed. Note that a resource group is a regional resource, i.e., you need to select the region to which the Virtual Cluster should be deployed. An arbitrary region other than the one shown in the example below can be chosen. It is recommended to dedicate the resource group to the Virtual Cluster and not deploy other resources to the group. Any name compliant with the Azure naming scheme can be used.

Registration of the Microsoft.DataProtection Resource Provider

This is an optional step which is required to configure automated backups on a schedule for the disk containing the user home directories. Follow the steps described in the Azure documentation to enable the Microsoft.DataProtection resource provider.

Deployment of Resource Template

Apply the Azure Resource Manager (ARM) template provided by Schrödinger as shown in the pictures below to the resource group created in the first step.

Add new resource to resource group.

Select "Template" as the type of resource to add.

Select "Create" on the "Template deployment" page.

Select "Build your own template in the editor".

Click on "Load file", select the file provided by Schrödinger as the template, and click "Save".

The template requires a few parameters to be specified. At the very least, a name for the Virtual Cluster and a public SSH key need to be specified. These settings are explained in more detail in the next few paragraphs and are highlighted in the screenshot below

Essential settings required by the template.

The name for the Virtual Cluster must contain only lowercase alphanumeric characters and dashes. (It must be valid as a DNS name component.)

The public SSH key will be provided to you by the Schrödinger Solutions Architect who is helping with the deployment of the system. It is used to grant a Schrödinger Solutions Architect access to the orchestrator, so that they can perform the initial deployment and future maintenance of the Virtual Cluster.

There are optional parameters which can be specified for the template. These parameters allow one to specify certain properties of the objects the template creates (CIDR ranges for the subnets and for the security groups). In general the template can either create all network resources required for the Virtual Cluster, or it can reuse existing network resources already present in the resource group. In the latter case the parameters which configure the properties of the created object are ignored. For example: For the backend subnet you can specify either a CIDR range or an ID of an existing subnet. The IDs of the resources are identical to their names, and it is expected that they are located in the resource group selected at the top of the "Custom deployment" page. If an existing resource is used, its name must start with the value given for the "Virtual_cluster_name" parameter, followed only by a suffix that depends on the parameter:

• -orchestrator for Virtual_cluster_orchestrator_security_group_id
• -frontend for Virtual_cluster_frontend_security_group_id
• no suffix for Virtual_cluster_vpc_id
• -frontend for Virtual_cluster_frontend_subnet_id
• -backend-0 for Virtual_cluster_backend_subnet_id
• -backend for Virtual_cluster_backend_security_group_id

The following screenshot highlights all parameters which specify the properties of newly created resources with a red frame. All parameters which refer to existing resources which should be used are marked with a green frame.

Note

As soon as the value of a parameter which points to an existing resource is changed from undefined to a different value the Azure Resource Manager will try to find the existing resource instead of creating it, i.e., the parameter(s) which specify the properties of the resource are ignored in this case.

Parameters for creation of network resources (red) or which are pointing to existing resources (green). Public IP addresses can be assigned to the instances which need to be accessible from systems external to the Virtual Cluster (see the screenshot below. If you select "false" for one of these parameters you need to make sure that the instances are accessible by other means, e.g., via a VPN connection).

Parameters for creation of a public IP address for the instances which need to be accessible from systems which are not part of the Virtual Cluster.

After the template has been deployed to the resource group a network for the Virtual Cluster as well as an orchestration instance has been created (or the orchestrator instance has been deployed into the specified existing network resources). The output of the template shows the public IP address of the orchestration instance (or the private IP address if a public has not been assigned). This address needs to be provided to the Schrödinger Solutions Architect in charge of deploying the Virtual Cluster such that log in to the instance is possible from within the Schrödinger network.

Example output of the resource manager template

Note

The created orchestrator instance already has the "Contributor" role attached to it and, thus, has all required permissions required by the Schrödinger Solutions Architect to deploy and manage the Virtual Cluster.