Automatic scaling with Azure Virtual Machine Scale Sets flexible orchestration mode
At Ignite March 2021, we announced the Public Preview of Azure Virtual Machine Scale Sets with flexible orchestration mode, an evolution of Azure Virtual Machine Scale sets that makes it easier to run a variety of virtual machine workloads at high scale with high availability. We are excited to announce we are adding additional functionality to the VMSS Flexible Orchestration preview: Automatic scaling Flexible orchestration mode now allows you to scale your virtual machine application out or in manually, automatically based on metrics, or according to a schedule. Like the traditional VMSS in Uniform Orchestration Mode, you specify a virtual machine profile or template for virtual machine instances: VM size, networking configuration, data disks, etc, and the number of instances you would like. Once the profile is defined, the scale set will automatically create the number of instances you request or remove instances and associated NICs and disks. VMSS provides many options to help you scale out based on your application needs: Scale up to 1000 instances in the scale set Specify instances should be placed in a particular zone Spread across multiple fault domains Automatically scale based on metrics such as aggregate CPU load, disk throughput, memory usage, etc Use Spot or on demand priority Automatically remove NICs and Disks when deleting the VM instances When application demand goes down or you need fewer instances for your application, you can save cost by scaling and reducing the number of instances in your scale set. Faster, more reliable deployments VMSS Flexible Orchestration mode is built on our next generation datacenter deployment technologies, enabling more reliable deployment success, more consistent deployment times, and faster, more reliable scale out and scale in operations. Maintain application health with Application Monitoring and Automatic Instance Repair You can install the Application Health Extension on each instance to allow your application to report application specific health metrics to Azure. Azure can automatically remove and replace instances with unhealthy application state. Safely remove instances with Terminate Notification Your application can receive an instance termination notice and set a predefined delay to the terminate operation, allowing your application to perform any clean up activities or end of life workflow before the instance is deleted. Application aware In Guest Security Patching Orchestration Automatic VM guest patching for virtual machines helps ease update management by safely and automatically patching virtual machines to maintain security compliance. With automatic VM guest patching enabled, the VM is assessed periodically to determine the applicable patches for that VM. Updates classified as 'Critical' or 'Security' are automatically downloaded and applied on the VM during off-peak hours. Patch orchestration is managed by Azure and patches are applied following availability-first principles. Improve network security with explicit outbound connectivity Historically, Azure VMs are assigned a default outbound IP address, enabling outbound connectivity from the VM to the internet (default outbound access). There are several disadvantages of this default outbound access IP including inability to lock down access via network security groups, and SNAT port exhaustion. In order to support modern best practices based on the secure by default approach in zero trust network security, VM instances created with VMSS Flexible Orchestration will not have the default outbound access IP associated with it. VMSS Flexible Orchestration will require that you specify an explicit outbound connectivity method, for example: Associate a NAT Gateway to the subnet where the instances reside Associate a Standard Load balancer with Outbound Rules configured Associate a Public IP with the VM Network Interface Only VMs created implicitly by the VMSS scaling engine will be secure by default with no implicit IP. VMs associated with an Availability Set or VMSS Uniform Orchestration mode, or standalone VMs that are later added to a VMSS Flex will still have the default outbound access and implicit IP address enabled. If you are building new workloads for VMSS Flexible Orchestration, or migrating existing workloads to VMSS Flexible orchestration, you may need to review network configuration to ensure connectivity to external services, including: Windows Activation Key Management Service Establish Private Link to required Azure services like Storage accounts, Azure Key Vault, etc. Custom scripts that require access to external URIs, Azure Active Directory Domain jon, etc Windows Update service For more information, refer to Default Outbound Access Support for Azure Backup and Azure Site Recovery We have extended support for VM management service like Azure Backup and Azure Site Recovery to VMSS Flexible Orchestraton mode. Example: N-Tier Application with VMSS Flexible Orchestration Let’s look at a how you can use VMSS Flexible Orchestration mode to simplify a traditional N-Tier Application virtual machine architecture. Adapted from Azure Architecture Center: N-Tier application with Apache Cassandra Traditionally this application architecture requires that you managed each of the 14 VMs individually; you are responsible for monitoring each instance, performing all security patching and ensuring application update. Furthermore, if demand for your application grows or shrinks, you would have to manually create additional instances at the web and/or business tier to handle additional traffic. You can simplify deployment and management of this architecture by using a VMSS with Flexible Orchestration at each application tier, and rely on VMSS platform features to assist with monitoring and management tasks. Data-tier – As this database workload tends to be stateful and requiring that instances are spread across multiple racks or partitions, you can specify a VMSS Flexible Orchestration to spread virtual machines across fault domains Business-tier – Middle tier of the application is often stateless, so you may be able to specify VMSS Flexible with maximum spreading (allow Azure to manage spreading…no particular quorum requirement). You could take advantage of Automatic Instance Repair to monitor if application instances are reporting healthy, and automatically replacing unhealthy instances with new, healthy instances. Web tier – This also tends to be a stateless tier, and is most susceptible to dynamic changes in traffic. You can specify autoscaling rules to automatically increase or decrease the number of instances based on a schedule, or metrics based rules. You can help optimize costs by mixing demand types; adding 2-3 instance at full, on-demand pricing, and specifying auto scale rules to scale out with less-expensive Spot instances. Sample templates: vm-scale-sets/vmss-flex-n-tier-demo at master · Azure/vm-scale-sets (github.com) Looking toward General Availability and beyond We are excited to share this first step in our journey to combine Azure Virtual Machines, Availability Sets, and VMSS into a single, integrated offering in VMSS Flexible Orchestration. On the way to general availability, we expect to continue to improve the parity between VMSS Uniform and VMSS Flexible Orchestration. One feature we plan to add next is the ability to specify multi-zone deployments, so you can automatically spread instances across multiple availability zones. We also look forward to bring more API parity between VMSS Uniform and Flex for batch instance operations, support for all VM sizes, as well as VMSS orchestrations like Scale in Policy, and Instance Protection. We look forward to hearing your feedback and stories, so we can continue to help you build the applications and services for your organization. Resources to get you started Virtual Machine Scale Sets Learn how to deploy and manage VMSS FlexA little PS script for getting VM and VMSS member status
I wrote this simple PS script to see the status of our VMs and VMSS members, as I wished to monitor infrastructure with an eye to costs. The VMSS bit took me a while, probably because I'm not very bright, but I thought the construction might help others who need to do tasks on each member of a scale set. YMMV # Login-AzureRMAccount # Uncomment above to log in # add a Object to collect output $outObj = New-Object PSObject # What is your TenantID $tenantId = "your tenant ID in here" # First get a list of subscriptions in this tenant $subList = Get-AzureRmSubscription -TenantId $tenantId # Then write it to the screen in yellow Write-Host -ForegroundColor Yellow $subList.name foreach ($subName in $subList.name) { # Write each sub as we work on it below the yellow name in Green Write-Host -NoNewline -ForegroundColor Green $subName "" # Below is an odd construction # I find that if you use Select-AzureRmSubscription with a string subName # it does not always work, mostly but not always # the method below always has worked for me YMMV $subObj = Get-AzureRmSubscription -SubscriptionName $subName $subTmp = Select-AzureRmSubscription -SubscriptionId $subObj # Get list of Resource Groups $rgList = Get-AzureRmResourceGroup foreach ($rgName in $rgList.ResourceGroupName) # In each RG first get the VMSSs then the VMs { # The below logic will be useful for any thing you need to do on each member of a scale set $vmssList = Get-AzureRmVmss -ResourceGroupName $rgName foreach ($vmssName in $vmssList.Name) { $vmssObj = Get-AzureRmVMssVM -InstanceView -Name $vmssName -ResourceGroupName $rgName foreach ($instCount in $vmssObj.InstanceID) # if you want to use this logic for another task on each member of a scale set # then replace what is between {} with your tasks {$vmssTmp = Get-AzureRmVmssVM -InstanceView -InstanceId $instCount -ResourceGroupName $rgName -VMScaleSetName $vmssName $outTmp = $vmssName + "_" + $instCount + "." + $rgName + "." + $subName $outObj | Add-Member $outTmp $vmssTmp.Statuses[1].DisplayStatus } } $vmList = Get-AzureRmVM -ResourceGroupName $rgName foreach ($vmName in $vmList.Name) { $vmObj = Get-AzureRmVM -Name $vmName -ResourceGroupName $rgName -Status $outTmp = $vmObj.Name + "." + $rgName + "." + $subName $outObj | Add-Member $outTmp $vmObj.Statuses[1].DisplayStatus } } } Write-Host # Write-Host for the New line $outObj # Output the list
