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
Copy file name to clipboardExpand all lines: articles/load-balancer/upgrade-basic-standard-with-powershell.md
+61-15Lines changed: 61 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,21 +48,44 @@ The PowerShell module performs the following functions:
48
48
- Basic Load Balancers with a Virtual Machine Scale Set backend pool member where one or more Virtual Machine Scale Set instances have ProtectFromScaleSetActions Instance Protection policies enabled
49
49
- Migrating a Basic Load Balancer to an existing Standard Load Balancer
50
50
51
+
## Install the 'AzureBasicLoadBalancerUpgrade' module
52
+
51
53
### Prerequisites
52
54
53
-
-**PowerShell**: A supported version of PowerShell version 7 or higher is the recommended version of PowerShell for use with the AzureBasicLoadBalancerUpgrade module on all platforms including Windows, Linux, and macOS. However, Windows PowerShell 5.1 is supported.
55
+
-**PowerShell**: A supported version of PowerShell version 7 or higher is recommended for use with the AzureBasicLoadBalancerUpgrade module on all platforms including Windows, Linux, and macOS. However, PowerShell 5.1 on Windows is supported.
54
56
-**Az PowerShell Module**: Determine whether you have the latest Az PowerShell module installed
55
57
- Install the latest [Az PowerShell module](/powershell/azure/install-azure-powershell)
56
58
-**Az.ResourceGraph PowerShell Module**: The Az.ResourceGraph PowerShell module is used to query resource configuration during upgrade and is a separate install from the Az PowerShell module. It will be automatically installed if you install the `AzureBasicLoadBalancerUpgrade` module using the `Install-Module` command as shown below.
57
59
58
-
##Install the 'AzureBasicLoadBalancerUpgrade' module
60
+
### Module Installation
59
61
60
62
Install the module from [PowerShell gallery](https://www.powershellgallery.com/packages/AzureBasicLoadBalancerUpgrade)
-[Validate](#example-validate-a-scenario) that your scenario is supported
73
+
- Plan for [application downtime](#how-long-does-the-upgrade-take) during migration
74
+
- Develop inbound and outbound connectivity tests for your traffic
75
+
- Plan for instance-level Public IP changes on Virtual Machine Scale Set instances (see note above)
76
+
-[Recommended] Create Network Security Groups or add security rules to an existing Network Security Group for your backend pool members, allowing the traffic through the Load Balancer and any other traffic which will need to be explicitly allowed on public Standard SKU resources
77
+
-[Recommended] Prepare your [outbound connectivity](../virtual-network/ip-services/default-outbound-access.md), taking one of the following approaches:
78
+
- Add a NAT Gateway to your backend member's subnets
79
+
- Add Public IP addresses to each backend Virtual Machine or [Virtual Machine Scale Set instance](../virtual-machine-scale-sets/virtual-machine-scale-sets-networking.md#public-ipv4-per-virtual-machine)
80
+
- Plan to create [Outbound Rules](./outbound-rules.md) for Public Load Balancers with multiple backend pools post-migration
81
+
82
+
### Post-migration steps
83
+
84
+
-[Validate that your migration was successful](#example-validate-a-scenario)
85
+
- Test inbound application connectivity through the Load Balancer
86
+
- Test outbound connectivity from backend pool members to the Internet
87
+
- For Public Load Balancers with multiple backend pools, create [Outbound Rules](./outbound-rules.md) for each backend pool
88
+
66
89
## Use the module
67
90
68
91
1. Use `Connect-AzAccount` to connect to the required Microsoft Entra tenant and Azure subscription
### Example: upgrade a Basic Load Balancer to a Standard Load Balancer with the specified name and store the Basic Load Balancer backup file at the specified path
134
+
### Example: upgrade with alternate backup path
135
+
136
+
Upgrade a Basic Load Balancer to a Standard Load Balancer with the specified name and store the Basic Load Balancer backup file at the specified path
### Example: migrate multiple Load Balancers with shared backend members at the same time
150
+
### Example: migrate multiple, related Load Balancers
151
+
152
+
Migrate multiple Load Balancers with shared backend members at the same time, usually when an application has an internal and an external Load Balancer
112
153
113
154
```powershell
114
155
# build array of multiple basic load balancers
115
156
PS C:\> $multiLBConfig = @(
116
157
@{
117
-
'standardLoadBalancerName' = 'myStandardLB01'
158
+
'standardLoadBalancerName' = 'myStandardInternalLB01' # specifying the standard load balancer name is optional
### Example: retry a failed upgrade for a virtual machine scale set's load balancer (due to error or script termination) by providing the Basic Load Balancer and Virtual Machine Scale Set backup state file
170
+
### Example: retry failed virtual machine scale set migration
171
+
172
+
Retry a failed upgrade for a virtual machine scale set's load balancer (due to error or script termination) by providing the Basic Load Balancer and Virtual Machine Scale Set backup state file
@@ -204,7 +250,7 @@ The script migrates the following from the Basic Load Balancer to the Standard L
204
250
205
251
### How do I migrate when my backend pool members belong to multiple Load Balancers?
206
252
207
-
In a scenario where your backend pool members are also members of backend pools on another Load Balancer, such as when you have internal and external Load Balancers for the same application, the Basic Load Balancers need to be migrated at the same time. Trying to migrate the Load Balancers one at a time would attempt to mix Basic and Standard SKU resources, which is not allowed. The migration script supports this by passing multiple Basic Load Balancers into the same [script execution using the `-MultiLBConfig` parameter](#example-migrate-multiple-load-balancers-with-shared-backend-members-at-the-same-time).
253
+
In a scenario where your backend pool members are also members of backend pools on another Load Balancer, such as when you have internal and external Load Balancers for the same application, the Basic Load Balancers need to be migrated at the same time. Trying to migrate the Load Balancers one at a time would attempt to mix Basic and Standard SKU resources, which is not allowed. The migration script supports this by passing multiple Basic Load Balancers into the same [script execution using the `-MultiLBConfig` parameter](#example-migrate-multiple-related-load-balancers).
208
254
209
255
### How do I validate that a migration was successful?
Copy file name to clipboardExpand all lines: articles/virtual-machines/premium-storage-performance.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -68,7 +68,7 @@ Latency is the time it takes an application to receive a single request, send it
68
68
69
69
When you are optimizing your application to get higher IOPS and Throughput, it will affect the latency of your application. After tuning the application performance, always evaluate the latency of the application to avoid unexpected high latency behavior.
70
70
71
-
The following control plane operations on Managed Disks may involve movement of the Disk from one Storage location to another. This is orchestrated via background copy of data that can take several hours to complete, typically less than 24 hours depending on the amount of data in the disks. During that time your application can experience higher than usual read latency as some reads can get redirected to the original location and can take longer to complete. There is no impact on write latency during this period.
71
+
The following control plane operations on Managed Disks may involve movement of the Disk from one Storage location to another. This is orchestrated via background copy of data that can take several hours to complete, typically less than 24 hours depending on the amount of data in the disks. During that time your application can experience higher than usual read latency as some reads can get redirected to the original location and can take longer to complete. There is no impact on write latency during this period. For Premium SSD v2 and Ultra disks, if the disk has a 4k sector size, it would experience higher read latency. If the disk has a 512e sector size, it would experience both higher read and write latency.
72
72
73
73
- Update the storage type.
74
74
- Detach and attach a disk from one VM to another.
0 commit comments