When scaling Azure based upon load, you can scale horizontally (add more compute instances) or vertically (increasing the size of the VM). Azure Auto-scaling functionality works with horizontal scaling. For more details about these options see my previous blog post on “Cloud Scaling Patterns“.
Azure Scale Units (SU) apply to vertical scaling, where you are wanting to scale ‘up’ the unit on which your VM is partitioned. As new hardware becomes available Microsoft builds them into a new “scale unit”. If scaling UP, there are some sizes you can’t scale up (resize) to depending upon what SU your VM is currently partitioned. VMs can only be resized to a size supported in the SU where the VM is deployed. Currently there are five scale unit types:
- Scale Unit 1: A0-A4 (original VM sizes) Basic VMs, no LB, no Autoscale, can only scale between A0-A4)
- Scale Unit 2: A0-A7 (like SU1 but adds A5-A7)
- Scale Unit 3: A8/A9 (“HPC” VMs, optimized networking with Infiniband)
- Scale Unit 4: A0-A7 and D1-D14 (D’s series with SSDs and better CPUs, and all A0-A7)
- Scale Unit 5: G1-G5 (monster powerful VMs up to 32 core Xeon CPUs/448 GB RAM/6596 GB SSD storage/64 data disks)
How to check the SU unit a VM is currently allocated
- VM/Configure tab
- Click on VM Size and drop down all sizes. Here, you see A0-A4 so you can tell what SU (#1) you are using. So you cannot scale up to anything above S4 in this case.
How to choose scale unit
- To ensure you get a SU that will meet your needs for scaling up, ensure the first VM deployed in that Cloud Service (or legacy Affinity Group) is in the upper range. So if you want SU2, deploy an S5 or above (S6 or S7) and you will be in SU2 at that point for all subsequent allocations
- When you deploy a smaller size, like A2, you can get put into many different scale units. You won’t necessarily be in SU1.
How to move to a bigger size VM that is not in your current SU:
- If you are in SU1 and need to move to a VM size that is not in SU1 (say A5-A7 in SU2) you can’t change it directly from the UI
- Note the OS disk name in the usage overview
- Delete the disk but “Keep the Attached Disks”
- Go to VM/Disks and make sure that disk is not attached to any other VMs
- Go to Gallery and choose that OS Disk and select the upgraded size you want to upgrade it to.
Network Security Groups (NSG) are an improvement upon VM endpoint Access Control List (ACL) rules. They provide network segmentation within an azure VNET at the infrastructure management level. This is an improvement over the earlier endpoint protection where you can define an ACL to define rules and permit or deny ingress traffic to the public IP port. ACLs only apply to incoming traffic, whereas NSGs apply to both ingress and egress traffic.
- You must first remove an ACL from any endpoints on a VM to use NSGs. The two (ACL and NSG) cannot co-exist on the same endpoint.
- Each VM endpoint has both a private and a public port. The private port is used by other VMs in the subnet to communicate with each other and does not use the Azure load balancer. The public port is exposed to the implicit Azure load balancer for ingress Internet traffic. ACLs apply to the public port. For a VM endpoint you’ll need to ensure that the VM firewall allows data to be transferred using the protocol and private port corresponding to the endpoint configuration
- Today there is no support in the portal for NSGs. It all needs to be done via the REST API or PowerShell.
- NSGs offer full control over incoming/outgoing traffic into a virtual machine in a VNET
- NSGs do not work with VNETs that are linked to an affinity group.
- Filters requests before they hit VM (ingress) and before they go out to Internet
- Provides a logical DMZ for database and app servers to be protected
- Web proxies (mask actual incoming and outgoing IP addresses) and DNS servers are usually put in DMZ since they are exposed to the internet. NSGs can logically create this type of abstraction for your VNET.
- NSG provides control over traffic flowing in and out of your Azure services in a subnet or a VNET as a set of ACL rules
- Are applied to all VMs in a subnet in a VNET in the same region. VMs must be in a regional VNET.
- NSGs can be applied to an individual VM as well.
- To give additional layers of protection you can associate a NSG to both a VM and another NSG to the VMs subnet
- Ingress traffic the packet goes through the access rules first specified in the subnet, then secondly by the VM NSG rules
- Egress traffic goes through the VM rules first, then the NSG rules in the subnet.
- You can now control access coming in and out of the Internet to your VMs for an entire subnet via a since ACL rule
- ACL rules on multiple VMs can be quickly changed in one operation vs. having to go into the firewall on each VM individually. You make the changes at the NSG level and don’t even need to go into the VM.
- Azure provides default NSG rules around the VNET, and access to the internet, that you can modify if needed. It also provides default ‘tags’ to identify the VIRTUAL_NETWORK, AZURE_LOADBALANCER and the INTERNET. These tags can be used in the Source/Destination IP address to simplify the process of defining rules.
- Defined rules are prioritized in their execution (as in the case in most business rules engines) so that the most importantly prioritized rules are executed first.
- You define the rules (in PowerShell or REST) using the following fields
- Priority, Access Permissions, Source IP/ Source Port, Destination IP/Destination Port, Protocol
For more information on NSGs refer to “About Network Security Groups” at https://msdn.microsoft.com/library/azure/dn848316.aspx.
Well it’s official! Even though you probably have read the article “Kardashians to Kick Bruce and their Affinity Groups to the Curb” in People magazine, you were not really sure what to believe until you saw the official word from Microsoft. Check out the content “About Regional VNets and Affinity Groups” at https://msdn.microsoft.com/library/azure/jj156085.aspx. Improvements to the Azure virtual network infrastructure that have made communication between different parts of the Azure DC very quick. No longer do you need to explicitly group resources in close proximity to each other to minimize latency between items like VNETs, VMs, and storage.
Take a look at my new book on the topic of Azure Automation (part of the Azure Essentials series from Microsoft Press). http://blogs.msdn.com/b/microsoft_press/archive/2015/03/06/free-ebook-microsoft-azure-essentials-azure-automation.aspx This is the PDF format released ahead of Epub and Mobi, which will be released later in the month.
Microsoft Azure Essentials: Azure Automation (ISBN 9780735698154), by Michael McKeown. This is the second ebook in Microsoft Press’s free Microsoft Azure Essentials series. Future ebooks will cover specific Azure topics, such as Azure Machine Learning, Azure Websites for Developers, and others.