Azure VM中IIS网站：结合VM Scale Sets实现伸缩冗余及更新部署咨询

1. Combining Scalability & Redundancy for High Load + Fault Tolerance #

VMSS was built to handle exactly this combination—here’s how to set it up properly:

• Deploy VMSS across multiple Availability Zones: When creating your scale set, select 2+ available zones (matching your existing VM setup). Azure will distribute instances evenly across zones, so if one zone goes down, the others keep serving traffic. This gives you zone-level redundancy out of the box.
• Configure autoscaling rules: Head to your VMSS in the Azure portal, go to Scaling > Autoscale, and set up rules based on your load metrics (e.g., CPU > 70% for 5 minutes triggers adding 2 instances; CPU < 30% removes instances). You can also use custom metrics like HTTP request count if you’re using Application Gateway.
• Add a load balancer with health probes: Pair your VMSS with an Azure Load Balancer or Application Gateway. Configure health probes (e.g., check the IIS default page or a dedicated health endpoint) so unhealthy instances get automatically removed from the traffic pool. The load balancer will route traffic only to healthy instances across all zones.
• Enable Automatic Instance Repair: In your VMSS settings, turn on this feature. It uses the same health probe to detect faulty instances and automatically replaces them with new ones—so you don’t have to manually fix or replace VMs when they fail.
• Use shared storage for website content: Don’t store static assets (images, CSS, JS) on local VM disks. Instead, mount an Azure Files share to all VMSS instances, or use Azure CDN for cached content. This ensures every new instance spins up with access to the same content, and you only update content in one place.

2. Deploying Website Updates to VMSS (No Need for New VHDs Every Time) #

Creating a new VHD for every update is a huge pain—you’re right to avoid that. Here are far better approaches:

• Custom Script Extension: Package your website update (e.g., a zip of your IIS site files) and store it in Azure Storage (with SAS token for secure access). Then, update the Custom Script Extension on your VMSS to download and deploy the zip to each instance. You can trigger this via the Azure portal, CLI (az vmss extension set), or CI/CD pipeline. This works great for quick content updates.
• CI/CD Pipeline with Rolling Updates: Use Azure DevOps, GitHub Actions, or another tool to set up a deployment pipeline. Configure your VMSS to use Rolling Update mode (in Updates > Update policy). The pipeline will push updates to a subset of instances at a time, wait for them to become healthy, then move to the next batch—zero downtime. You can deploy directly to the IIS sites on each instance without touching VM images.
• Azure Compute Gallery for Managed Images: If you do need to update the VM base image (e.g., install new Windows updates, IIS patches), use Azure Compute Gallery (formerly Shared Image Gallery). Create an updated image version, then trigger a VMSS update to roll out the new image to instances gradually. This is more efficient than creating new VHDs manually, as you can manage image versions centrally and roll back if needed.
• Shared Content Repository: As mentioned earlier, if your website content is stored in Azure Files or a network share, updating the content only requires modifying the files in the shared location. All VMSS instances will pick up the changes automatically (you might need to restart the IIS site, which can be done via a script run across instances).

Pro tip: Avoid making manual changes to individual VMSS instances—any manual tweaks will be overwritten when new instances scale out or when you apply updates. Keep all configurations as code (ARM templates, Bicep) or use extensions to ensure consistency across all instances.

内容的提问来源于stack exchange，提问作者Alex Stephens