Azure Virtual Machine Scale Set (VMSS) Part1 — Architecture and Deployment
As I am almost playing around with Azure virtual machines and Azure Kubernetes service every day, I thought the administration tasks for VMSS are not that different. I was wrong. VMSS is indeed a service on its own and unfortunately, the official documentation is not that thorough.
The reasons for implementing VMSS instead of VM.
- Easy to create and manage multiple VMs
- Provides high availability and application resiliency
- Allows your application to automatically scale as resource demand changes
- Works at large-scale
The differences could be reviewed here, but in short, the management overhead is different.
Architecture
The simplified architecture is pretty straightforward. Just like any other VMs in availability sets or availability zones, VMSS instances would be logically grouped in one and have the associated load balancer to distribute incoming workload and provide accessibility.
Deployment
Network Management
If you follow this article to setup both VMSS and its associated load balancer, mostly likely, administrators could not access any instance within. Using either PowerShell or Azure CLI would at least have all the required configurations.
On top of that, we would need to add another inbound security rule for accessing backend instance service ports (RDP with port 3389 / SSH with port 22).
The PowerShell/Azure CLI would create VMSS with load balancer and most likely, administrators would be using network address translation to access each instance. So, we would need to know what frontend port is NATed into what backend port.
The command is to get NAT information. Please be aware that there is a port range start and end. Each VMSS instance would be using one of port in the range as its NAT frontend port.
az network lb inbound-nat-pool show -g MyResourceGroup --lb-name MyLb -n MyNatPool
This command is to get NAT mapping information.
az vmss list-instance-connection-info \
--resource-group myResourceGroup \
--name myScaleSet
This command in PowerShell is to test whether the port is actually listening to any client trying to connect to server.
psping 20.98.121.11:50000
Depending on what you chose to connect to the VM instances when creating VMSS, you could now use either password or private key to perform identity authentication.
ssh jonw@20.98.121.11 -p 50000
If somehow, you follow Azure portal to create VMSS and are missing the load balancer piece, please follow this article to add/update/delete load balancer and its NAT rules.
Disk Management
Administrators could create data disks at VMSS creation or attach them later on. For more information, please check this site. After the operation, we would see a disk under the resource group.
Each instance would have connection to the attached disk.
Prepare the data disk to be used in OS with custom script extension.
az vmss extension set \
--publisher Microsoft.Azure.Extensions \
--version 2.0 \
--name CustomScript \
--resource-group <resource group name> \
--vmss-name <scale set name> \
--settings '{"fileUris":["https://raw.githubusercontent.com/Azure-Samples/compute-automation-configurations/master/prepare_vm_disks.sh"],"commandToExecute":"./prepare_vm_disks.sh"}'# SSH into one of the instances
- ssh <username>@<VMSS public IP> -p <LB frontend assigned port># examine partitions
- sudo fdisk -l
# examine filesystems and mount points
- sudo df -h
Term Explanation
- Reimage: This means the instance within VMSS will be deleted and replaced by an instance created from the original assigned image.
- Update: This is used when there is no upgrade policy.
- Upgrade: This is used changes made on the scale set need to be applied to each instance. There are 3 different policies, automatic, manual and rolling.
The rest of the functions are pretty self-explanatory.
