Kenichiro Nakamura

Posted on Mar 13, 2018

Azure vs GCP part 10: Virtual Machine - Scaling (Azure)

#azure #gcp #cloud

In previous article, I use Azure VM to host my application, as single instance.

I look into scaling options this time.

Availability

One of the reasons why I recommend multi-instance is availability. There are two types of concerns.

Hardware failure
Software update

Azure offers solutions for each.

Scale out

In addition to availability, I need to have multiple instances when I get high load. Azure offers scale out solution, as well as load balancing.

Availability Set

One option is to use Availability Set. According to the document here

Availability Set is a logical grouping capability that you can use in Azure to ensure that the VM resources you place within it are isolated from each other when they are deployed within an Azure datacenter.
When you put your VMs in an availability set, these VMs are split into multiple fault domain and update domain.

Fault domain: This is for hardware failure. A hardware failure won't affect another domain.
Update domain: This is for software update. OS reboot due to update won't happen in multiple domains at same time.

Scale Sets

Another option is to use Scaling Set. According to the document here

A virtual machine scale sets allows you to deploy and manage a set of identical, auto-scaling virtual machines. VMs in a scale sets are distributed across logic fault and update domains in one or more placement groups. These are groups of similarly configured VMs, similar to availability sets.

Difference

They are similar but there are differences.

Any VMs or identical VMs
Availability oriented or scale out oriented

Let's say, you have multiple VMs works as a set, then you may consider using availability set as you want to control how each VM sit together. On the other hand, if you simply scale out each layer, then scale sets sounds right.

Load Balancer

Creating multiple instances with Availability Set or Scale Sets won't load balance them automatically. Azure offers Load Balancer service. According to the document here

An Azure load balancer is a Layer-4 (TCP, UDP) load balancer that provides high availability by distributing incoming traffic among healthy VMs. A load balancer health probe monitors a given port on each VM and only distributes traffic to an operational VM.

Let's try!

There are several steps to make this work.

Create image

When scale-out, it requires a seed image to copy from. There are multiple ways to prepare the image. I use the one I deployed in the last article.

1. Go to Azure Portal and navigate to the VM you created.

2. Click "Connect" and remote desktop in to the image.

3. Once login, press Windows key + "R" and enter Sysprep, then run it.

4. Generalize it with following settings. It will shutdown the OS.

5. Come back to Azure Portal and wait until the VM shutdown. Then click "Capture".

6. Enter name. I specified new resource group. If you want to delete once image captured, you can check "Automatically delete..." checkbox.

Seed image is ready now.

Try Availability Set

I try Availability Set first.

1. Go to newly created Resource Group, click add and search Availability Set.

2. Enter name and set values. I use default values for domains. Click "Create".

3. Go to seed image, and click "Create VM".

4. Enter configuration values.

5. Select size in the next step. I selected "B1MS" for test.

6. Select created "Availability Test" and change settings as you need. All the settings come from seed image. I just used the default settings.

7. Click "OK" to create the image.

8. Repeat the steps to create 2nd VM in same Availability Set. As a result, I have many resources created. This is because the seed image has them.

9. Go to each VM and confirm the public IP address. Access them one by one to see the application runs as expected.

10. Now I have two VMs up and running. Next, create load balancer. In Resource Group, click Add and find it.

11. Set parameters. I set public dynamic IP address for this test.

12. Once load balancer created, go to the load balancer, select "Backend pools", then click "Add".

13. Select "Availability set" to association and select the AG. Now you can add VMs in the Availability Set. Add all VMs and click "OK" to save.

14. Next, create probe for health check. Select "Health probes" and click "Add", then create a probe. In this case, I created port 80 probe.

15. Lastly, create a rule. Select "Load balancer rules" and click "Add", then create a rule. Specify the probe just created for the rule.

16. Check overview to confirm public IP address. The probe and rule are also linked. Access to the public IP via browser to confirm you can access to the app.

17. I don't need the public IPs for each VM now. You can delete them if you want.

Try Scale Sets

I try Scale Sets next.

1. Go back to the resource group and click "Add", then find "Template Deployment" and click "Create". I need to use this to deploy custom image to scale sets.

2. Click "Build your own template in the editor link. Here you need to enter a template. The code below is minimum template to create:

Virtual Networks: myVnet, 10.0.0.0/16
Subnet: mySubnet, 10.0.0.0/16
virtual Machine Scale Sets: myScaleSet,

VM for the scale sets is specified as virtualMachineProfile. It uses the seed image, start with vm, which has NIC(myNIC) connects to myVnet and size is Standard_A1.

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "adminUsername": {
            "type": "String"
        },
        "adminPassword": {
            "type": "SecureString"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Network/virtualNetworks",
            "name": "myVnet",
            "apiVersion": "2016-12-01",
            "location": "[resourceGroup().location]",
            "properties": {
                "addressSpace": {
                    "addressPrefixes": [
                        "10.0.0.0/16"
                    ]
                },
                "subnets": [
                    {
                        "name": "mySubnet",
                        "properties": {
                            "addressPrefix": "10.0.0.0/16"
                        }
                    }
                ]
            }
        },
        {
            "type": "Microsoft.Compute/virtualMachineScaleSets",
            "sku": {
                "name": "Standard_A1",
                "capacity": 2
            },
            "name": "myScaleSet",
            "apiVersion": "2016-04-30-preview",
            "location": "[resourceGroup().location]",
            "properties": {
                "upgradePolicy": {
                    "mode": "Manual"
                },
                "virtualMachineProfile": {
                    "storageProfile": {
                        "imageReference": {
                            "id": "[resourceId('Microsoft.Compute/images', 'vmtest1234-seed-image')]"
                        }
                    },
                    "osProfile": {
                        "computerNamePrefix": "vm",
                        "adminUsername": "[parameters('adminUsername')]",
                        "adminPassword": "[parameters('adminPassword')]"
                    },
                    "networkProfile": {
                        "networkInterfaceConfigurations": [
                            {
                                "name": "myNic",
                                "properties": {
                                    "primary": "true",
                                    "ipConfigurations": [
                                        {
                                            "name": "myIpConfig",
                                            "properties": {
                                                "subnet": {
                                                    "id": "[concat(resourceId('Microsoft.Network/virtualNetworks', 'myVnet'), '/subnets/mySubnet')]"
                                                }
                                            }
                                        }
                                    ]
                                }
                            }
                        ]
                    }
                }
            },
            "dependsOn": [
                "Microsoft.Network/virtualNetworks/myVnet"
            ]
        }
    ]
}

3. Save the template and do deploy. Fill the parameters username and password.

4. Wait until the deployment done. Once deploy completed, go to the resource.

5. As Scale Sets deployed, I create new load balancer.

6. Once the load balancer created, go to backend pools and click "Add".

7. Select "Virtual machine scale sets" as association and select myScaleSet.

8. Create a probe and a rule same as before.

9. Access to the application via public IP of the load balancer to confirm the application is up and running.

Auto scale settings for Scale Sets

The reason why I want to use Scale Sets is to use auto-scale. Though I could set this up in the template above, I didn't. Therefore I need to configure it manually here.

1. Go to the scale sets resource and select "Scaling".

2. Click "Enable autoscale", then click "Add a rule".

3. Add new rule. I specify 70% of CPU utilization for 5 minutes to increase one instance.

4. Then enter "Autoscale settings name" and save.

That's it!

Summary

I briefly test availability and scaling feature of Azure and both works okay. The remaining task, as a developer, is to automate creating custom image, otherwise I need to keep creating image every time I have new release.

Actually it can be done from "Continuous delivery" section of the scale set. Refer to the blog at the end for further information.

In the next article, I look into GCP options

Reference

Windows Virtual Machines Documentation: Check out Tutorial Section
Best practices for Autoscale
Deploying Applications to Azure Virtual Machine Scale Sets

DEV Community