You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Azure SQL Managed Instance must be deployed within an Azure [virtual network](../../virtual-network/virtual-networks-overview.md). The number of managed instances that can be deployed in the subnet of a virtual network depends on the size of the subnet (subnet range).
20
20
21
-
When you create a managed instance, Azure allocates a number of virtual machines that depends on the tier you selected during provisioning. Because these virtual machines are associated with your subnet, they require IP addresses. To ensure high availability during regular operations and service maintenance, Azure might allocate more virtual machines. The number of required IP addresses in a subnet then becomes larger than the number of managed instances in that subnet.
21
+
When you create a managed instance, Azure allocates a number of virtual machines that depend on the tier you selected during provisioning. Because these virtual machines are associated with your subnet, they require IP addresses. To ensure high availability during regular operations and service maintenance, Azure might allocate more virtual machines. The number of required IP addresses in a subnet then becomes larger than the number of managed instances in that subnet.
22
22
23
23
By design, a managed instance needs a minimum of 32 IP addresses in a subnet. As a result, you can use a minimum subnet mask of /27 when defining your subnet IP ranges. We recommend careful planning of subnet size for your managed instance deployments. Consider the following inputs during planning:
24
24
25
25
- Number of managed instances, including the following instance parameters:
- Plans to scale up/down or change the service tier
30
+
- Plans to scale up/down or change the service tier, hardware generation, or maintenance window
31
31
32
32
> [!IMPORTANT]
33
33
> A subnet size of 16 IP addresses (subnet mask /28) allows the deployment of a single managed instance inside it. It should be used only for evaluation or for dev/test scenarios where scaling operations won't be performed.
@@ -38,7 +38,7 @@ Size your subnet according to your future needs for instance deployment and scal
38
38
39
39
- Azure uses five IP addresses in the subnet for its own needs.
40
40
- Each virtual cluster allocates an additional number of addresses.
41
-
- Each managed instance uses a number of addresses that depends on pricing tier and hardware generation.
41
+
- Each managed instance uses a number of addresses that depend on pricing tier and hardware generation.
42
42
- Each scaling request temporarily allocates an additional number of addresses.
- The **Total** column displays the total number of addresses that are used by a singledeployed instance to the subnet.
61
-
- When you add more instances to the subnet, the number of addresses used by the instance increases. The total number of addresses then also increases. For example, adding another Gen4 GP managed instance would increase the **Instance usage** value to 10 and would increase the **Total** value of used addresses to 16.
62
-
- Addresses represented in the **Azure usage** column are shared across multiple virtual clusters.
58
+
- The **Total** column displays the total number of addresses that are used by a single-deployed instance to the subnet.
59
+
- When you add more instances to the subnet, the number of addresses used by the instance increases. The total number of addresses then also increases.
60
+
- Addresses represented in the **Azure usage** column are shared across multiple virtual clusters.
63
61
- Addresses represented in the **VC usage** column are shared across instances placed in that virtual cluster.
64
62
65
63
Also consider the [maintenance window feature](../database/maintenance-window.md) when you're determining the subnet size, especially when multiple instances will be deployed inside the same subnet. Specifying a maintenance window for a managed instance during its creation or afterward means that it must be placed in a virtual cluster with the corresponding maintenance window. If there is no such virtual cluster in the subnet, a new one must be created first to accommodate the instance.
66
64
65
+
The same scenario as for the maintenance window applies for changing the [hardware generation](resource-limits.md#hardware-generation-characteristics) as virtual cluster is built per hardware generation. In case of new instance creation or changing the hardware generation of the existing instance, if there is no such virtual cluster in the subnet, a new one must be created first to accommodate the instance.
66
+
67
67
An update operation typically requires [resizing the virtual cluster](management-operations-overview.md). When a new create or update request comes, the SQL Managed Instance service communicates with the compute platform with a request for new nodes that need to be added. Based on the compute response, the deployment system either expands the existing virtual cluster or creates a new one. Even if in most cases the operation will be completed within same virtual cluster, a new one might be created on the compute side.
68
68
69
69
70
70
## Update scenarios
71
71
72
-
During a scaling operation, instances temporarily require additional IP capacity that depends on pricing tier and hardware generation:
| Gen4<sup>1</sup> | GP or BC | Scaling vCores | 5 |
77
-
| Gen4<sup>1</sup> | GP or BC | Scaling storage | 5 |
78
-
| Gen4 | GP or BC | Switching from GP to BC or BC to GP | 5 |
79
-
| Gen4 | GP | Switching to Gen5 | 9 |
80
-
| Gen4 | BC | Switching to Gen5 | 11 |
81
-
| Gen5 | GP | Scaling vCores | 3 |
82
-
| Gen5 | GP | Scaling storage | 0 |
83
-
| Gen5 | GP | Switching to BC | 5 |
84
-
| Gen5 | BC | Scaling vCores | 5 |
85
-
| Gen5 | BC | Scaling storage | 5 |
86
-
| Gen5 | BC | Switching to GP | 3 |
87
-
88
-
<sup>1</sup> Gen4 hardware is being phased out and is no longer available for new deployments. Updating the hardware generation from Gen4 to Gen5 will take advantage of capabilities specific to Gen5.
89
-
72
+
During a scaling operation, instances temporarily require additional IP capacity that depends on pricing tier:
We recommend the following formula for calculating the total number of IP addresses. This formula takes into account the potential creation of a new virtual cluster during a later create request or instance update. It also takes into account the maintenance window requirements of virtual clusters.
85
+
We recommend the following formula for calculating the total number of IP addresses. This formula takes into account the potential creation of a new virtual cluster during a later create request or instance update. It also takes into account the maintenance window and hardware generation requirements of virtual clusters.
93
86
94
87
**Formula: 5 + (a * 12) + (b * 16) + (c * 16)**
95
88
96
89
- a = number of GP instances
97
90
- b = number of BC instances
98
-
- c = number of different maintenance window configurations
91
+
- c = number of different maintenance window configurations and hardware generations
99
92
100
93
Explanation:
101
94
- 5 = number of IP addresses reserved by Azure
102
-
- 12 addresses per GP instance = 6 for virtual cluster, 3 for managed instance, 3 additional for scaling operation
103
-
- 16 addresses per BC instance = 6 for virtual cluster, 5 for managed instance, 5 additional for scaling operation
95
+
- 12 addresses per GP instance = 6 for virtual cluster, 3 for managed instance, 3 more for scaling operation
96
+
- 16 addresses per BC instance = 6 for virtual cluster, 5 for managed instance, 5 more for scaling operation
104
97
- 16 addresses as a backup = scenario where new virtual cluster is created
0 commit comments