- Group that holds identically configured VMs
- Used for
- Need to create and manage multiple VMs
- Centrally create and manage multple VMs (Windows Server or Linux)
- Need for high availability and app resiliency
- Horizontal scaling, scaling up and down based on spikes
- Need for large (1000) scale
- E.g. Azure Batch uses scale sets under the hood
- Need for IaaS autoscale
- Scale out and in based on metrics based autoscale
- Need to create and manage multiple VMs
- Azure App Service
- High agility at the expense of administrative power
- The underlying Hyper-V Vms are almost totally abstracted from you
- Easy manual, scheduled, or automatic scale out and scale back
- Virtual Machine Scale Set (VMSS)
- Maximum administrative power at the expense of agility
- VMSS represents Azure's approach to IaaS horizontal scaling
- Create virtual machine scale set
- Availability zone
- Scale scale sets across one and more availability zones
- ❗ All regions do not support availability zone
- Instance count & instance set
- Low priority
- Take advantage of unutilized capacity
- Compute power that customers/Microsoft is not using
- Save costs
- Good for workloads that can handle interruption
- Stateless workloads
- VMs in the scale set may be evicted at any time
- You set eviction policy:
- Stop / Deallocate
- Delete
- Take advantage of unutilized capacity
- Use manage/unmanaged disks
- ❗ Managed disks are not supported with availability zones
- Networking
- Application Gateway
- 💡 Useful if your scale sets are web servers
- ❗ Do not support RDP
- Load Balancer
- Supports RDP
- You set public IP address name and domain name label (
domain-name.region.cloudapp.azure.com
)
- Application Gateway
- Availability zone
- You can also use ARM template e.g. Deploy a Windows VM Scale Set with a Custom Script Extension that deploys VMs, load balancer and a powershell script to be executed after deployment.
- In portal: Choose VM → Settings → Instances you can see all the instances
- To connect to individual instances you need load balancer and NAT (network address translation)
- You can't RDP/SSH into individual instances directly
- You can connect to load balancer IPs
- In portal: Load Balancer → Inbound NAT rules
- NAT maps different VMs on different ports.
- Manual: Through Portal/SDK/CLI/PowerShell
- Autoscale
- Scheduled: If you know when the load will be high you can plan for that and scale with time triggers
- Metrics: Use various metrics from various sources to determine when to scale in/out
- Manage in VMSS → Scaling →
- Enable auto-scaling
- Select scale-mode
- Scale based on metric
- Add rule
- E.g. increase instance count by 1 when CPU percentage above 70%
- 💡 You should also create scale mode that bring down the scale count
- Properties
- Duration: Good to not be confused when scaling out/in, so set a duration to e.g. 10 minutes
- Cooldown: Waits after scale operation before new scale operation
- Scale to specific instance count
- Time-based scaling
- Set start and end date