Skip to content

Onboarding and Initial Configuration

This page contains initial configuration steps which need to be completed before a Virtual Cluster can be deployed. Certain permissions are required for hosting a Virtual Cluster on supported resources providers. Infrastructure components and services may be described or implemented in a provider-dependent manner. Regardless of the resource provider, the requisite resources can be mapped to the overall architecture of the cluster.

The deployment process for the Virtual Cluster can be split in two logical steps:

  1. The first step creates the Virtual Cluster infrastructure in an isolated environment. The network resources and connectivity of the Virtual Cluster system as well as the IAM resources created during this step are not expected to change during the lifetime of the system and are not managed by Schrödinger Solutions Architects. An orchestrator instance is deployed in this step which has sufficient permissions to create and modify the resources that are required to perform the final deployment of the Virtual Cluster in the second step and allow maintenance of the Virtual Cluster on the instance level.

  2. In the second step a Schrödinger Solutions Architect deploys and configures the instances of the Virtual Cluster using the orchestrator instance deployed in the first step.

    The orchestrator instance serves two purposes:

    1. It serves as bastion host to the Virtual Cluster for the Schrödinger Solutions Architect/Operator.
      • This instance is locked down such that it only accepts incoming connections originating from the Schrödinger corporate network, and login is restricted to members of Schrödinger Solutions Architect team in possession of an authorized ssh key.
      • Whenever the orchestrator instance is running, an operator from Schrödinger is capable of accessing the instance in order to deploy and manage the Virtual Cluster.
      • The instance needs to be running during the deployment process, but can be shut down once the deployment is finalized to prevent access although this is not recommended since it can help Schrödinger to provide timely support in case of problems and for maintenance.
      • The orchestrator instance should not be decommissioned as long as the Virtual Cluster is in production in case access needs to be re-enabled for maintenance or troubleshooting by a Schrödinger Solutions Architect or the cluster Operator.
    2. The permissions required to deploy the Virtual Cluster in the isolated environment are attached to the orchestrator instance.
      • No dedicated personal accounts need to be created for Solutions Architects deploying and managing the Virtual Cluster.

Note

Schrödinger Solutions Architects manage all instances which are part of the Virtual Cluster in terms of configuration, and software upgrades, but the network infrastructure and connectivity to other systems is managed by the customer.

Specific permissions are resource provider dependent and are described in following sections.

Virtual Cluster Connectivity#

A Virtual Cluster contains at least - a service instance, - a frontend instance, - an (optionally) auto-scaled backend with either compute instances or session instances (hosting graphical desktops) or both.

Network Overview#

A Virtual Cluster is comprised of instances that are grouped into subnets related to their purpose. Each Virtual Cluster comprises a single frontend subnet and one or more backend subnets. Instances in the frontend subnet are meant to be accessible to systems which are not part of the Virtual Cluster, whereas systems in the backend subnet(s) are not directly accessible.

Subnets#

frontend#

The frontend subnet contains all instances which allow for incoming connections, potentially have a public IP address and a DNS name which can be resolved by DNS servers available to the clients.

The frontend instance located in this network serves as gateway to the Virtual Cluster, i.e., all ingress and egress network traffic is routed through this instance.

backend#

The backend subnet(s) contain all instances which provide infrastructure-related services to the scalable backend of the cluster shown at the right-hand side of the diagram below or to instances in the public subnet. The number of backend subnets depends on the geographical distribution of the Virtual Cluster. A system which spans multiple availability zones or even regions has more than one backend subnet.

./images/onboarding-system-model.svg
Instances and subnets which are part of a Virtual Cluster. The frontend and backend-0 subnets (dark orange border) contain the frontend and backend service instances (gray shading), respectively, and are required for baseline cluster operation. The orchestrator instance is required for initial provisioning and maintenance. The remaining instances (white shading) may be auto-scaled or running permanently (depending on the cluster configuration), and the remaining subnets (light orange) are provisional, and may span multiple regions.

Service Quotas and Limits#

All supported resource providers implement limits on the number of instances, number of CPUs and GPUs, or block storage used. Please make sure that these limits are set in a way that enough resources are available for the Virtual Cluster when it is scaling up to its maximum size.