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,
• authorize access of a service principal hosted by a third party (Schrödinger) to the tenant directory,
• 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, a public SSH key, and the client ID as well as a client secret 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.

The client ID and the client secret will also be provided to you by the Schrödinger Solutions Architect. These values allow your Azure account to use a Schrödinger-owned application to access a shared image gallery owned by Schrödinger. This gallery contains the base images used to build all cluster instances.

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. In addition the output shows an URI ("Base_Image_Reader_URI"). This URI will be required in the next step.

Example output of the resource manager template

Grant Permission to the Reader Application

In order to access the base images owned by Schrödinger it is required to share these images using cross-tenant access. The procedure is described here. Most of the required configuration is already in place. However, you need to grant access to the Schrödinger application that was created as part of the deployment of the orchestrator. This allows it to copy the images from the Schrödinger image gallery into your Azure account and gallery. Access the URL shown in the output of the template in a web browser to acknowledge these permissions. Additionally, you must grant "Contributor" permissions for this Schrödinger application to allow it to update the gallery. In order to do this, please go to the "Access Control (IAM)" section of the resource group in your subscription. Click on "Add" and select "Add role assignment". Click on "Privileged administrator roles" and select "Contributor". Click on "Next" at the bottom of the page. Click on "Select members", and search for and select the service principal name as provided by the Schrödinger Solutions Architect (typically its name starts with "virtual-cluster-base-image-reader"). Click on "Review + assign" at the bottom of the page.

Add new role assignment

Select contributor role

Allow `Contributor` access for service principal

Search for the service principal name as provided by the Schrödinger Solutions Architect

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.