Edit

Virtual cluster architecture - Azure SQL Managed Instance

  • Article

Applies to: Azure SQL Managed Instance

This article describes the architecture and operation management of the virtual cluster that hosts Azure SQL Managed Instance.

Overview

Azure SQL Managed Instance is a single-tenant, platform-as-a-service (PaaS) made up of service components that are hosted on a dedicated set of isolated virtual machines and joined to a virtual cluster. These dedicated sets of virtual machines are placed into virtual machine groups based on similar instance configuration attributes, such as hardware generation and maintenance windows. One or more instances can be in a virtual machine group, and one or more virtual machine groups form a virtual cluster. A virtual cluster automatically expands or contracts as needed to accommodate new and removed instances.

Each virtual cluster is associated with one subnet and automatically deployed when the first SQL managed instance in a subnet is created. Likewise, a virtual cluster is automatically removed when the last instance in a subnet is deleted, leaving the subnet empty and ready to be removed. The virtual cluster connects the subnet to the managed instances deployed inside that subnet. A service association link (SAL) is used to establish the association between a subnet and the cluster.

The following diagram shows the conceptual layout of the virtual cluster:

Diagram that shows the virtual cluster architecture for Azure SQL Managed Instance.

Role in management operations

The role of the virtual cluster in management operations is to find appropriate compute resources for the operation, as well as manage the resources within the cluster, such as the virtual machines that create the instance, and the virtual machine groups. Management operations include creating new instances, as well as deleting, or modifying the configuration of, existing instances. The virtual cluster expands, shrinks, or deletes existing virtual machine groups, or creates new virtual machine groups, depending on the operation.

Since virtual machine groups are defined by similar instance configuration attributes (such as hardware generation and maintenance windows), making changes to any of these attributes for an instance triggers the virtual cluster to perform an action to the virtual machine groups that form it. Actions triggered by management operations include creating new or deleting existing virtual machines, and virtual machine groups, as well as expanding existing groups and moving instances between groups. If all virtual machines are removed out of a group, the virtual cluster also deletes the virtual machine group.

For example, if you change the hardware generation of an instance, the virtual cluster creates a new virtual machine group for the hardware generation if one doesn't already exist, and moves the instance to that group.

The duration of virtual group change operations depends on the operation type. For more information, see SQL Managed Instance management operations.

Number of virtual machine groups

The number of virtual machine groups in a virtual cluster depends on the following:

You can determine the number of virtual machine groups in a virtual cluster by multiplying the number of different hardware generation configurations by the number of different maintenance window configurations in your subnet. For example, if you have two hardware generation configurations (such as one Standard-series and one Premium-series instance) and two different maintenance window configurations, the virtual cluster has four virtual machine groups.

SQL Managed Instance supports three different hardware generation configurations and three different maintenance window configurations. Therefore, the minimum number of virtual machine groups in a virtual cluster is 1 (one hardware generation configuration, one maintenance window configuration), and the maximum is 9 (three different hardware generation configurations, three different maintenance window configurations).

Important

Since there is a limit to the number of virtual machines that can join a group, a lack of space in an existing group can result in creating a virtual machine group with identical specifications. It's possible for a subnet with a large number of instances to have multiple machine groups with the same configuration, and exceed 9 virtual machine groups.

Role in IP address usage

The built-in high availability of Azure SQL Managed Instance is implemented with Azure Service Fabric. A Service Fabric cluster is a network-connected set of virtual or physical machines. Each machine or VM that is part of a Service Fabric cluster is called a cluster node, and each node reserves one IP address. As such, each virtual machine in the dedicated set of VMs that create a SQL managed instance is considered a node in the Service Fabric cluster. The virtual cluster that hosts one or more SQL managed instances assigns IP addresses to each VM to form a Service Fabric cluster for high availability.

Since the virtual cluster is responsible for assigning IP addresses to the virtual machines inside it, and each virtual cluster is associated with a single subnet, you have to carefully consider the number of instances that you expect to deploy into the subnet when determining an appropriate size for the subnet.

When determining an appropriate size for the subnet where you'll deploy your managed instances, take into account:

  • The number of instances that you expect to deploy into the subnet
  • The number of different virtual machine groups that you expect in the subnet

To learn more, see determine required subnet size and range for Azure SQL Managed Instance.

DNS synchronization

The virtual cluster synchronizes DNS server settings changes in a virtual network that hosts existing SQL managed instances. The virtual cluster triggers the synchronization and propagates it to the instances inside the cluster. For more information, see resolve private domain names in Azure SQL Managed Instance.

Delete a subnet after deleting an Azure SQL Managed Instance

Before deleting a subnet used for SQL managed instances, the subnet needs to be empty. Since virtual clusters are automatically created when the first instance in the subnet is created, and automatically deleted when the last instance in the subnet is deleted, you first need to delete all instances in the subnet before you can delete the subnet.

Important

  • Creating and deleting the virtual cluster is automatic and requires no manual action past creating the first instance or deleting the last instance in a subnet.
  • Deleting a virtual cluster is a long-running operation that can last up to 1.5 hours. The virtual cluster will still be visible in the portal until deleting the virtual cluster completes.

In rare circumstances, creating an instance fails and results in an empty virtual cluster. Additionally, since you can cancel creating an instance, it's possible for a virtual cluster to be deployed with instances in a failed to deploy state. Empty virtual clusters, or clusters with instances that have failed to deploy, are automatically removed in the background, and there are no charges associated with these clusters.

Next steps