Azure SQL Managed Instance is fully managed SQL Server instance hosted in Azure cloud and placed in your Azure Virtual Network. In this post, I will explain how you can prepare network environment for Managed Instance.
Azure SQL Database Managed Instance is a new data service currently in public preview. It is a dedicated resource placed in customer’s Virtual Network, and currently one of the biggest issue that we are hitting in preview is configuration of Virtual Networks that is not compliant to the requirements. This problem usually delays provisioning and can make instance unavailable if a network admin cut-off Managed Instance from Azure Management Service using some network rule. This is possible because you own the Virtual Network where we are placing Managed Instance, and you can customize access rules on your network. As a result, some configuration may cause problems during Managed Instance deployment.
Although the networks requirements are documented, I will summarize the most important things that you need to be aware when you prepare Virtual Network for Managed Instance. Configuring network environment has the following steps:
- Configure Virtual Network where Managed Instance will be placed.
- Create Route table that will enable Managed Instance to communicate with Azure Management Service.
- Optionally create dedicated subnet for Managed Instance (or use default one that is created when the Virtual Networks is created)
- Assign the Route table to the subnet.
- Double-check that you have not added something that might cause the problem.
If you follow these steps, I believe that you will be able to create and use your Managed Instance without any issue. Otherwise, some incorrect settings in your environment may block Managed Instance deployment or make it unavailable.
1. Virtual network configuration
Managed Instance is your dedicated resource that is placed in Azure Virtual network with assigned private IP address. Before you create Managed Instance, you need to create Azure Virtual network using Azure portal, PowerShell, or Azure CLI.
If you are using Azure portal, make sure that you use Resource Manager ake sure that Service Endpoints option is Disabled in Creating Virtual Network Blade (this is default option so don’t change it).
If you want to have only one subnet in your Virtual Network (Virtual Network blade will enable you to define first subnet called default), you need to know that Managed Instance subnet can have between 16 and 256 addresses. Therefore, use subnet masks /28 to /24 when defining your subnet IP ranges for default subnet. If you know how many instances you will have make sure that you have at least 2 addresses per instance + 5 system addresses in the default subnet.
2. Create Route table
The second prerequisite is to create Route table that will allow Managed Instance to communicate with the Azure Management Service. This is required because Managed Instance is placed in your private Virtual Network, and if it cannot communicate with Azure service that manages it it will became inaccessible.
The route table contains a set of rules, called routes, that specifies how packets sent from Managed Instance should be routed in the virtual network. Route table is associated to subnets where Managed Instances are deployed, and each packet leaving a subnet is handled based on the associated route table. A subnet can only be associated to a single route table. There are no additional charges for creating route tables in Microsoft Azure.
Go to Azure portal, add new resource “Route table”, and once it is created for to Routes blade and add a route “0.0.0.0/0 Next Hop Internet route”. This route will enable Managed Instances that are placed in your Virtual Network to communicate to Azure Management Service that manages the instance. Without this, the Managed Instance cannot be deployed.
This is the current requirement in public preview, and it will be changed in future. Some networking policies are restrictive and we will relax them.
Once you configure your route table it should look like:
3. Create additional subnet for Managed Instance (optional)
Managed Instance is deployed in your subnet, so you need to create it before you provision Managed Instance. If you want to put instances in default subnet and if you have not changed default route, then you can skip this step.
Subnet is dedicated to Managed Instance and cannot contain any other resource (i.e. Azure VMs should not be placed in that subnet.)
Subnet must have at least 16 addresses, 5 addresses are reserved for Azure internal services, while you would need 2 addresses for every Managed Instance that you put in the subnet. This is important to plan because once you put Managed Instance in your subnet, you cannot change the size of the subnet.
4. Configure subnet
The subnet (default one or new) must have a User Route Table (UDR) with 0.0.0.0/0 Next Hop Internet as the only route assigned to it. If you have created you route table with 0.0.0.0/0 Next Hop Internet route, you can assign it to the subnet where you will place Managed Instance.
Find your subnet using Azure portal, go to details and make sure that:
- You have a Managed Instance Route table assigned to the subnet
- There should be no Networks Security Groups in your subnet.
- There should be no service-endpoint in your subnet.
- There are no other resources in subnet.
Your subnet should look like:
Finally, make sure that you have not accidentally added something that can break Managed Instance deployment or make the instance unavailable. Here are some quick rules that you need to check:
- Virtual Network should have Service Endpoints disabled
- Subnet must have between 16 and 256 IP addresses (masks from /28 to /24)
- There should be no other resources in your Managed Instance subnet.
- Subnet must have route with 0.0.0.0/0 Next hop internet
- Subnet must not have any Network Security Group
- Subnet must not have any service endpoint
Once you have configured everything, you can use Azure portal to create new Managed Instance, and assign the Virtual Network/subnet that you have created.
This is the simplest way to configure your network with new clean network, route table and subnet. If you are expert for networking and you want to customize your Virtual Network or subnets, or to use some existing Virtual Networks or subnets to place Managed Instances there you can find detailed instructions how to configure infrastructure on Azure documentation. If you want to have custom DNS make sure that you read Configuring a Custom DNS article.
Configuring and troubleshooting issues in network configuration is one of the biggest problem in the process of deployed Managed instance. If you are not sure how to configure Virtual Network or if you need a quick check-list, make sure that you follow advices in this article.
Some of the recommendations and constraint described in this post will be changed during public preview because we are relaxing network requirements. However, steps in this post will enable you to get your Managed Instance without major issues.
Source: Microsoft Blog – SQL Server Storage Engine – How to configure network for Azure SQL Managed Instance