Azure Scale Set vs Availability Set

Posted on February 27, 2019 by John Humphreys

Why Was I Worried?

I have been habitually using scale sets for all of my needs as long as my requirements only involved needing multiple copies of a VM image running safely. Then I started to worry about the difference between a scale set and an availability set… were my scale set VMs not safe?

TLDR; I actually read Azure and Azure CLI documentation and made a simple but cool command below that put my mind at ease for scale sets, so feel free to skip to that if you like.

Research

There is a good stack overflow right here which I added to just now. It has quite a few good answers about availability sets vs scale sets, including some info about a scale set by default having 5 fault domains. So, I recommend starting there if you’re interested in digging in.

A good summary of what I found is that:

Availability sets by default will spread your resources over fault domains to ensure that outage of one due to a power or network issue, etc does not affect another.
Availability sets also allow mixing of resources; e.g. 2 VMs with different configuration.
Scale sets only allow you to have an identical image deployed and they provide the ability to scale it out linearly.
Scale sets implicitly have one “placement group”. If you want to go over 100 VMs, you have to remove that restriction.
A placement group has 5 fault domains and is similar (or maybe the same as) an availability set.

Validation

As I’m responsible for highly available infrastructure, I wasn’t keen on just accepting this. So, I fiddled around with the Azure CLI for scale sets and made this simple command which indeed shows my 10 instance scale set is indeed spread across multiple fault domains – I hope you find it useful too.

az vmss get-instance-view --subscription "your-subscription-id" \ 
--resource-group "your-rg" --name "your-scale-set-name" \
--instance-id "*" | grep platformFaultDomain

    "platformFaultDomain": 0,
    "platformFaultDomain": 1,
    "platformFaultDomain": 2,
    "platformFaultDomain": 4,
    "platformFaultDomain": 0,
    "platformFaultDomain": 1,
    "platformFaultDomain": 3,
    "platformFaultDomain": 4,
    "platformFaultDomain": 2,
    "platformFaultDomain": 3

Here are some additional good resources:

Azure CLI – List Only Storage Accounts with Blob Containers Present

Posted on February 23, 2019 by John Humphreys

I just had to write a script to find all storage accounts with blobs present in a specific subscription in a specific region.

This proved to be non-trivial as the storage account function doesn’t have a region filter, and you have to manually crawl the accounts to see if they’re using blobs.

Here is the fully-working script I came up with, I hope it helps you out!

rm -f accounts_with_blobs.csv

tenant="your-tenant-id"
subscription="your-subscription-name"
region="your-region"

az login --tenant "${tenant}" --subscription "${subscription}"

# Get all subscription + region filtered storage account names.
accounts=$(az storage account list --output table --subscription "${subscription}" | grep "${region}" | awk '{print $5}')

# Filter out accounts with no blob containers.
for account in $accounts
do
    char_count=$(az storage container list --account-name $account | wc -c)
    if [[ $char_count -lt 4 ]];
    then
       echo "$account has no blobs."
    else
       echo "$account has blobs."
       echo "$account" >> accounts_with_blobs.csv
    fi
done

Azure: Tagging All Resources in a Resource Group With its Tags

Posted on February 11, 2019 by John Humphreys

Recently, I had to go back and correctly tag a whole bunch of items in a new resource group, none of which had been given tags.

This kind of task can be daunting in the Azure portal… you have to click each, click the tags tab, and then type each key/value, for each tag, and save. So… tagging 50 resources with 5 tags each ends up being 50 * 2 * 5 + 50 = 550 clicks at minimum, plus all the typing! Clearly, this is a task better suited for the CLI.

Using the Azure CLI

Microsoft actually has a very full featured tutorial on this subject right here. The more advanced code they provide will actually find every resource you have in every group and give each resource the tags from the group. It will even optionally retain existing tags for resources that are already tagged.

I wanted something a little simpler with the login included so that I can quickly copy it in to fix a resource group here and there without worrying about affecting all the other resource groups. So, here is the code. It also counts the items so you can see progress as it can take some time.

Note, I wanted to forcibly replace all the tags on the resources with the RG tags as some of them were incorrect. You can get code to merge with existing tags from the link noted above if you prefer.

tenant="your-tenant-id"
subscription="your-subscription-name"
rg="your-resource-group-name"

# Login to azure - it will give you a message and code to log in via
# a web browser on any device
az login --tenant "${tenant}" --subscription "${subscription}"

# Show subscriptions just to show that we're on the correct one.
echo "Listing subscriptions:"
az account list --output table

# Get the tags from the resource group in a useful format.
jsontag=$(az group show -n $rg --query tags)
t=$(echo $jsontag | tr -d '"{},' | sed 's/: /=/g')

# Get all resources in the target resource group, and loop through
# them applying the tags from the resource group. Count them to show
# progress as this can take time.
i=0
r=$(az resource list -g $rg --query [].id --output tsv)
for resid in $r
do
az resource tag --tags $t --id $resid
let "i+=1"
echo $i
done

Also note that you can find the total number of resources you are targeting in advance with this command so the counter is more practical :).

az resource list --resource-group "your-rg-name" --query "[].name" | jq length

MRemoteNG – SSH – Connect to Azure VM

Posted on February 1, 2019 by John Humphreys

What is MRemoteNG?

MRemoteNG is a nice Windows OS tool for managing multiple SSH sessions (and session configurations) in one window – so you can log onto 10 servers and hop around trivially. It is built on top of Putty.

How Do You Use It With Azure VMs?

When you create a VM in Azure, you give it a public key (assuming you didn’t use password authentication, which you should generally avoid).
You can generate a key pair with PuTTYGen if you don’t have one (but then I’m assuming that you do have one if you already created the VM).
Take the private key corresponding to that public key and save it into a file (it may already be in an “id_rsa” file in your .ssh directory in your user directory; e.g. C:\users\your-name\.ssh\id_rsa).
Open PuTTYgen (it should come with MRemoteNG or Putty, otherwise you can get it yourself.
Load the private key file.
Click “Save private key” with Type = RSA selected (2048 bits is fine). It will save as a “PPK” file.
Save it to your .ssh folder for consistency, or anywhere else – it really doesn’t matter much.
Open MRemoteNG -> Tools -> Options -> Advanced -> Launch Putty -> Expand “SSH” -> Click Auth (Don’t expand) -> Put your PPK file path in “Private key file for authentication”.
Click Session in putty and give the session a name in the “Saved Sessions” text box and then click Save. It should appear in the box below that.
Now you have a saved session that can use this private key via a PPK file.
Close Putty, make a new connection in MRemoteNG and select “Putty Session” = the new session you saved. It should be listed as an option.
Celebrate!

Coding Stream of Consciousness

by John Humphreys – Random code from my life.

Monthly Archives: February 2019