In this blog, we will present a change in the instance delete flow that is part of the investment into the #sqlmiops space (presented in Azure SQL Managed Instance – introduction to #SQLMIOPS article). With change described in this article, delete experience gets aligned with the steps present in the instance create flow.
At a high level, SQL Managed Instance is a set of service components. These components are hosted on a dedicated set of isolated virtual machines that run inside the customer's virtual network subnet. These machines form a virtual cluster.
A virtual cluster can host multiple managed instances. If needed, the cluster automatically expands or contracts when the customer changes the number of provisioned instances in the subnet. Depending on the state of underlying compute, there are several subnet states in which customers can end up today:
- The subnet contains one Virtual Cluster and one or multiple SQL Managed Instances inside.
- The subnet contains multiple Virtual Clusters and one or multiple SQL Managed Instances inside of each cluster.
Virtual cluster resource doesn’t support CREATE command – it gets automatically created during first instance deployment – for the reference check Overview of Azure SQL Managed Instance management operations. Together with a virtual cluster, two more components are deployed: network intent policies (NIP) that ensures subnet remains properly configured through time and resource navigation link (RNL) that represents a connection between the subnet and virtual clusters deployed inside.
Previous experience
Before changes in the delete flow, there were two ways how virtual cluster was removed:
- Manually,
- Automatically.
Both ways required a virtual cluster to be empty for the deletion to be successful. In case that virtual cluster is not manually removed, there is a timer task (12 hours) that triggers its removal. After a virtual cluster is deleted (manually or automatically), .
New experience
With new experience in place, virtual cluster and other dependent components are removed with last instance deletion in the subnet, if there are no ongoing create operations inside the subnet. With this change in place, there is no need for customers to take care of virtual clusters and the rest of the components (NIP and RNL). Same way they get automatically created during instance deployment, now they are automatically dropped during instance deletion.
Depending on the subnet state, there are two different outcomes of instance deletion:
- Complete removal – Operation result will be returned when both instance and cluster are removed. The operation duration is prolonged and can take up to 1.5 hours.
- Instance removal only – Operation result will be returned as soon as is removed. The operation completes in couple of minutes.
The durations of the management operations are documented on the management operations overview page.
If we map outcomes to the subnet states mentioned at the beginning of the article, we get the following tables:
| One virtual cluster – Multiple managed instances |
Removal type | Description | Operation duration |
| Non-last instance in subnet | Instance removal only | There are remaining instances therefore cluster cannot be dropped. | Short |
| Last instance in subnet | Complete removal | Virtual cluster dropped with managed instance. | Prolonged |
| Multiple virtual clusters – Multiple managed instances | Removal type | Description | Operation duration |
| Non-last instance in subnet and non-last instance in cluster | Instance removal only | There are remaining instances therefore cluster cannot be dropped. | Short |
| Non-last instance in subnet and last instance in cluster | Instance removal only | Virtual Cluster is dropped as there are no remaining instances inside, however it is dropped in the background as there are other instances in the subnet and another virtual cluster. Virtual Cluster drop is initiated immediately after instance is removed. | Short |
| Last instance in subnet |
Complete removal |
Virtual cluster dropped with managed instance. | Prolonged |
There is no billing implication
Customers should not be concerned about billing as there are no implications of this behavioral change. As soon as delete operation is triggered, no matter whether only managed instance is being deleted or other resources get removed as well (and operation gets prolonged), billing is disabled as soon as delete operation starts.
Benefits of the new experience
A new experience is driven by two large groups of customers and their feedback:
- Customers that rely on IaC (Infrastracture-as-Code) deployments
- Customers that were not aware of the Virtual Cluster
For IaC customers, previous experience was not well suited because of the dependent resources – they get automatically deployed and customers don’t have control over them. When deployment templates are updated and, for example, managed instance and subnet used for deploying the instance are removed, scripts get blocked on removing the subnet as there are still resources tightened to it. No matter that managed instance is deleted, virtual clusters and other resources remain and wait for timer tasks to remove them.
The second set of customers is not aware of how virtual cluster operates. After instance removal, they expect all dependent resources to be removed. After a couple of hours, they come back and see that a virtual cluster is still present. Often, the removal process is automatically started, while on top of that customers try manually to remove it. This operation results in failure as there is ongoing removal which brings even bigger confusion. At the very end, virtual cluster magically disappears.
With new experience in place, customers don’t need to take care of resources that get deployed with managed instance and managed instance becomes the only resource they should manage. From the other hand, IaC tools like ARM or Terraform can now include managed instance as part of the templates.
Best practices
In case you plan to create new instance in the same subnet and remove the old one, first create the new instance, and then remove the old one. New instance creation in the same subnet will (in most cases) trigger virtual cluster resize operation which is faster than buildout operation triggered on first instance creation. After that, remove the old one.
Posted at https://sl.advdat.com/2WHB3R7
