Microsoft Low-priority VMs in Action

Following our recent announcement, the Low-priority VMs team at Microsoft has rolled a major update last week which makes it even easier to run Low-priority VMs for Web Applications (outside of the Batch offering) by attaching Batch Instances to custom VNets and additional OS Images.

After testing it last week, we have taken it for a spin this morning (in production 🙂 and migrated one of our Web Services to run on Low-priority VMs.

Here are the results, we are paying now around 84% less than what we’ve used to pay before 🙂

Now, let’s take a quick look at our configurations, and how we actually achieved it in under 5 minutes.

Here is a deep dive into each sub-config including: Compute, Network, Storage and Load Balancing options.

Capacity Configuration

• Scaling 2(min) to 4(max) servers
• We also want to run it entirely on Low-priority capacity (we can also set up a cluster that runs only certain % on LPVMs)

{
  "group": {
    "name": "spotinst-asset-management",
    "capacity": {
      "maximum": 4,
      "minimum": 2,
      "target": 2
    },
    "strategy": {
      "lowPriorityPercentage": 100,
      "drainingTimeout": 300
    },

Compute Configuration

• Region: Us East
• Resource group: spotinst
• VM Sizes: standard A1, standard A2, Standard A3 (I chose a list of sizes to increase my availability over different capacity pools of Low-priority VMs, and to minimize my interruption chances)
• Centos 7.3 as the Image for our Operation System
• Start-up script that installs some of our packages and deploys the software latest version etc..
• A public SSH Key

  
"compute": {
      "launchSpecification": {
        "image": {
          "publisher": "OpenLogic",
          "offer": "CentOS",
          "sku": "7.3"
        },
        "sshPublicKey": "ssh-rsa xxxyyyzzzkkkwww",
      },
      "product": "Linux",
      "region": "eastus",
      "resourceGroupName": "spotinst",
      "vmSizes": {
        "lowPrioritySizes": [
          "standard_a1",
          "standard_a2",
          "standard_a3"
        ]
      },
        "userData": {
          "commandLine": "sudo /bin/bash -c \"curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -;sudo yum -y install nodejs;sudo yum -y install gcc-c++ make;sudo npm install -g azure-cli;sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc;sudo sh -c 'echo -e \\\"[azure-cli]\\nname=Azure CLI\\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\\nenabled=1\\ngpgcheck=1\\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc\\\" > /etc/yum.repos.d/azure-cli.repo';yum check-update;sudo yum -y install azure-cli; ./asset_management_deploy.sh\""
        },

  }

Network configuration

• I’ve attached my Web Service to my "spotinst-prod-vnet" VNet (Virtual Network)

"network": {
    "virtualNetworkName": "spotinst-prod-vnet",
    "subnetId": "default"
},

Load Balancing Configuration

• Attached to a Multai Load Balancer (L7 Load Balancer for Microsoft Azure that is equivalent to Amazon ELB)
• Health Check – set as a regular HTTP Port-based Health-Check, with a grace period of 300 seconds

       
"loadBalancersConfig": {
          "loadBalancers": [
            {
              "targetSetId": "ts-123abc",
              "balancerId": "lb-ccc000"
            }
          ]
        },
      "health": {
        "healthCheckType": "MULTAI_TARGET_SET",
        "autoHealing": false,
        "gracePeriod": 300
      }
    }

What does this mean for you?

Well, that all depends. If you’re not using Azure, just know that Microsoft has released Low-Priority VMs, their equivalent of the EC2 spot. And it’s pretty easy to integrate into your production environment.

In this example, we configured a web app with 2-4 machines running on Azure. These machines were connected to our production Virtual Network behind a load balancer running on HTTP. It all took less than 5 minutes.

And if you’re already using Azure but not yet using LPVMs, you can implement LPVMs here to save up to 84% on your instances.

Happy savings!