Infrastructure Notes - Azure Virtual Machine Scaling
- If we place two or more instances into the same ‘availability set’ Microsoft provide a 99.95 availability SLA. (The single instance SLA is 99.9).
- An ‘availability set’ is a logical container that ensures your VM instances reside on different hardware hosts, on separate racks in the same Azure data center.
- This arrangement would cover you for maintenance & local failures.
- This arrangement on its own wont help with regional/data center failures (since your set of machines are in the same data center).
- This is when we have different data centers in the same region.
- The data centers are connected by high speed redundant links.
- They are not available in every region.
Azure Traffic manager
- We could connect two regions via traffic manager and load balance between regions.
- Azure Traffic Manager operates at the DNS layer
- Directs incoming DNS requests based on the routing method of choice. (Choices are: Priority, performance, geographic, weighted round-robin, subnet, and multi-value and you can combine them)
- Example: sending requests to the closest endpoints, improving the responsiveness of an application
Managed Disks Storage
- Slight side track, but when designing IaaS remember this is the way to go, don’t use the classic storage account for this.
Resize VM’s for scale?
- You can resize Azure VM’s on the fly, either in the console or via PowerShell.
- They will go down while you do though, in the lab this was only about a minute but its hard to say if machines doing real things might take longer.
- Keep in mind, IaaS isn’t the best for horizontal scale, PaaS is designed to solve the scale issues for you and the way to go if possible/practical for the use case.
- But, “Scale sets” are what you want if you need to handle scale.
- You’ll want a “Machine Scale Set template”
- Configure the scale options, configure a load balancer and off you go.
- The Azure marketing pitches it like “Virtual Machine Scale Sets are elastic and designed to support your scale-out workloads—including stateless web front ends, container orchestration, and microservices clusters. Azure Kubernetes Service and Azure Service Fabric run on Virtual Machine Scale Sets”
- Its all about ARM (Azure Resource Manager) templates.
- I’ll do a separate post to summarize ARM templates because there is too much content but important to know a few things here…
- When you deploy a template, Resource Manager converts the template into the individual REST API operations needed to achieve the thing you’ve declared in your template.
- Visual Studio makes this easy. It has “validate” and “deploy” options built right in and produces a skeleton template for the most useful scenarios. Or, start here or here
- Small tip: Be careful of PowerShell windows that have popped up behind visual studio when testing deployments. (Your deployment might be waiting for input from you).
- Also, for what its worth, to test the declarative nature of ARM templates i deleted the NIC from a machine configured via an ARM template, then reran the template. The NIC was put back in place, and it was still the same machine (it didn’t burn the old and make a new one) because i left a ping running inside it to confirm. I did find the machine couldn’t reach the Internet anymore though, even after getting its NIC back. I used “redeploy” to move it to another host and it had Internet access again.
- If you’re worried that all this scale, redundancy and automation might land you in hot water with machines deployed in a prohibited region consider an Azure policy that describes the regions your are allowed in, attach it to the subscription and you’ll be protected from accidents of this nature.
Custom VHD Templates
- Last thing, sort of related to scale. You can work on your own VHD images. Just build them in Hyper-V locally, generalize them and use AzCopy/Storage Manager to get them into your account. You can store them on blob storage in a storage account.