Virtual Clusters hosting Azure SQL Managed Instance are enhanced
Published Nov 16 2022 07:51 AM 5,070 Views
Microsoft
SQL Managed Instance product group continues its investment in platform security, reliability, and usability. With the latest release of November 2022 Feature Wave, there is a new set of capabilities available for Virtual Cluster.
 

Capability list

In the following table you can find the comparison between previous and new experiences.

 

Experience Previous New
API version
and earlier
Number of clusters in subnet
Multiple
One
Property “version”
Not available
Available
Association with subnet
RNL (resource navigation link)
SAL (service association link)
Support for Tags
No
Yes
Property "family”
Available
Not available
Property “maintenanceConfigurationID”
Available
Not available
Update DNS Servers API pattern
Synchronous
 Asynchronous

 

Number of clusters and association with subnet

 

At a high level, SQL Managed Instance is a set of service components that run inside the customer's virtual network subnet. These components are hosted on a dedicated set of isolated virtual machines that form a virtual cluster.  
 
With new experience, customers would be able to see only one virtual cluster per subnet in their resource groups. The reason for this is that virtual cluster represents the connector between the subnet and managed instances deployed inside that subnet. What additionally is changing is that virtual clusters now use SAL (service association link) for establishing the association between subnet and the cluster, instead of RNL (resource navigation link) that was used so far.
 

Version property

 
Major ask from the customers that run and manage SQL Managed Instance environments at scale is if there is a way to programmatically determine if something is or is not supported, can be deployed and so on. As Virtual Cluster enhancements come with a new November 2022 Feature Wave release, we wanted to provide a way for the customers to determine if:
  • Set of features that are part of the wave are available for some managed instance?
  • Deploying managed instance in some subnet will result with feature wave enabled or not?
 
Pre-requisite for having access to the Feature Wave is that it is enabled for the subscription type used and in desired region. Further to programmatically check if:
  • Feature Wave is available on your instance use set of commands to:
  • Check if using some subnet will result in deploying instance with Feature Wave, use set of commands to:
    • Get your subnet that you plan to use for deployment,
    • Get SAL on that subnet.
    • If SAL exists, extract the Virtual Cluster ID from SAL,
    • Get Virtual Cluster,
    • Extract the "version" property from Virtual Cluster.
 
In case that subnet is empty or contains Virtual Cluster with property version and value 2.0, deploying instance in such subnet will result in getting instance with Feature Wave enabled. Just to remind, pre-requisite is having subscription and region used for deployment enabled for Feature Wave.
 

Obsolete properties

 

“Family” and “maintenanceConfigurationID” were properties present as part of the Virtual Cluster resource for a period. However, these options caused confusion since they were not actionable, and specifying these properties in the “Update” command would result in an error. With the change of having only one Virtual Cluster per subnet, keeping these properties as part of the Virtual Cluster would make the confusion bigger, so they are no longer part of it.
 

Update DNS servers

 

In certain situations, it's necessary for the SQL Server database engine to resolve domain names that don't exist in public DNS records. When you update the DNS servers for a virtual network, SQL Managed Instances in that network must also be notified of this change. If the DNS server setting is changed in a virtual network which already hosts SQL Managed Instances, then their virtual clusters need to synchronize with the changes in the DNS configuration. With older API versions, it was a synchronous experience, but due to the recent change of one Virtual Cluster being a host for all instances in the subnet, the new API version has been switched to use asynchronous Request-Reply API pattern.
 

Can I switch my Virtual Cluster to the latest version?

 

It is not possible to create or delete virtual clusters, as its lifecycle is controlled by the system. It gets created with the creation of first instance in the subnet and removed with the removal of last instance from the subnet.
 
If your subscription type has been enabled for Feature Wave usage, and instance(s) and Virtual Cluster are deployed in the region that supports Feature Wave, you can move your instance to the new subnet. If it does not contain managed instances, you will automatically get a new enhanced virtual cluster, and managed instance running on it will have Feature Wave enabled.
 
To learn more about Feature Wave, its availability, and how to get started, visit the November 2022 Feature Wave announcement.
 

Is there any impact of this change on management operations?

 

From the Virtual Cluster perspective, all the existing flows are still in place. Virtual Cluster infrastructure can be resized, new infrastructure must be built, or the existing infrastructure removed. What will be improved through time are the durations of these operations. We are constantly investing in management operations space, and with Feature Wave release, we are announcing improvement in time required to create first SQL Managed Instance in the subnet.
 

Next steps

 

Visit one of the following blog or documentation articles and learn more about:
 
Call to action: If you have ideas that you would like to share, feel free to leave comments to this blog post or contact us using https://aka.ms/contactSQLMI link.
Co-Authors
Version history
Last update:
‎Nov 16 2022 07:50 AM
Updated by: