For the 5th year in a row, ITCamp Community is organising Global Azure Boot Camp (https://global.azurebootcamp.net/).
This is a global event that takes place in over 159 locations around the world. Like last year, Cluj-Napoca is hosting a GABC and appears on the Azure map.
On April 22nd, you are invited to join this event which will have three 90 minute workshops which will be part theoretical and part practical, so we advise you to bring a laptop 🙂
I will be speaking at the event, and my workshop is about ARM templates 🙂
The event will start at 9:00 AM and will finish at around 2:00 PM.
Here are the event workshops:
Azure Functions (Radu Vunvulea)
What are Azure Functions? AWS Lambda from Azure. This is the fastest way how we can present Azure Functions. During this workshop, we will have a challenge to create a system that can process and analyze data without VMs or other computation units. We will use only Azure Functions for it. Sounds interesting, then let’s meet from 09:30 and find out how you can do this.
Machine learning for mere mortals with Azure ML (Silviu Niculita)
Machine learning has been leveraged to radically change many industry verticals. The problem is the learning curve has always been very steep. Exotic languages, complex tools, little or no documentation.But innovative cloud-based ML platforms are changing that and democratizing access. During this session, you will learn the basics of machine learning, and you will see a demo of how you can build a prediction model using real-world data, evaluate several different algorithms and modeling strategies, then deploy the finished model as a scalable RESTful API within minutes.
ARM Templates, how to create them, and use them in your CD pipeline (Florin Loghiade)
Azure has an excellent API that permits the user to automate the creation of every complex environment, using one single JSON document. Those documents are called ARM Templates, and they can be used to create, manage and even refresh any type of resource available in Azure. Using ARM templates and PowerShell combined with a CI/CD tool like VSTS, TeamCity, Jenkins, you can automate the build and deployment of the most complex application out there. In this hands-on lab, you will learn about the benefits of using Azure Resource Manager templates, when and how to use PowerShell in the CI/CD pipeline, and what it takes to create ARM Templates.
Here is the meetup link and I hope to see you at the next Global Azure BootCamp!
Acesta este al cincilea an când ITCamp community organizează Global Azure Boot Camp. Acesta este un eveniment la nivel global care are loc în peste 159 de locaÈ›ii. Ca È™i anul trecut, Clujul nu se lasă mai prejos È™i apare pe harta Azure. Pe data de 22 Aprilie vă invităm pe toÈ›i la acest eveniment din Cluj-Napoca, care va conÈ›ine 3 workshop-uri.Part…
In my last blog post, I talked about why we should stop using regular storage accounts for our IaaS VMs and why should we use Managed Disks. In today’s blog post I will talk about how you can modify your existing ARM templates that deploy your VMS to use Managed Disks from now on.
Let’s take a look at a regular storage account based ARM Template:
We have a resources block where we specify a storage account, and we use that resource to create an OS Disk and a Data Disk for the particular VM.
If we want to add more disks then we copy paste the what’s between the dataDisks array a couple of times, modify the LUN and name and we’re happy.
Converting the template to a managed disk format is pretty easy. You first need to reference in the template the API Compute (do note that we’re not modifying storage API) version 2016-04-30-preview or a later version (never use -preview in your production templates!)
You change the storage profile to reference managed disks as shown the code snip below:
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"storageProfile":{
"imageReference":{
"publisher":"[variables('imagePublisher')]",
"offer":"[variables('imageOffer')]",
"sku":"[variables('sku')]",
"version":"latest"
},
"osDisk":{
"createOption":"FromImage"
},
"dataDisks":[
{
"diskSizeGB":1023,
"lun":0,
"createOption":"Empty"
}
]
Hard? I don’t think so, MS made it very easy to convert existing templates to use Managed Disks. You basically remove some code from the template 🙂
This sample is for single VMs;
If you have multiple VMs in an Availability set, you need to add a “managed” property to the Availability Set block like shown below:
JavaScript
1
2
3
4
5
6
7
8
9
10
{
"apiVersion":"2016-04-30-preview",
"type":"Microsoft.Compute/availabilitySets",
"name":"[variables('availabilitySetName')]",
"location":"[resourceGroup().location]",
"properties":{
"platformFaultDomainCount":"2",
"platformUpdateDomainCount":"2",
"managed":"true"
}
Hope this was usefull, if you have any comments, write them down below 🙂
Every service that you use in Azure uses storage. We want everything that we create in Azure to be persistent because if it would be temporary, then we would have a problem. When you create a Virtual Machine, you need to create one or two storage accounts where the VMs disks and diagnostic data will sit. This worked well for a while, but when we’re talking about scale, then this becomes an issue when you’re talking about high availability, disaster recovery or even disk maintenance.
To solve the problems from above and all other VM storage-related problems, Microsoft announced a new type of offering called “Managed Disks.”
Why were storage accounts a problem for Virtual Machines?
For starters; Using the ARM model, you would create VMs in a Resource Group and select one single storage account where all those VM disks would sit in. The problem was that when you’re provisioning a storage account, basically you’re tying it to a storage stamp (cluster) and you would get limited performance and scalability. Storage in Azure has the biggest SLA when compared to other services, but it’s not 100%, and mistakes/issues do happen. When you’re saving all your OS / Data disks in one storage account thus having all your eggs in one basket which you should know by now that that’s a bad thing 🙂
To make matters worse, each storage account has a limited amount of IOPS and can have a limited number of disks, e.g., 30000 IOPS for standard storage and 50000 IOPS for premium storage. With ten premium storage disks, you would hit the storage account limits.
Usually, people created 5-10-20 VMs per a single storage account and then they had performance issues because, in peaks, those VMs were consuming all the IOPS of that storage account. Performance is not the single problem that you would have, the other problem was availability, you would create a couple of VMs, set them in an Availability Group for that 99.95% SLA and then a storage issue would happen, and all of them go down. Why? Well because your storage account was created in a single storage cluster which had a problem.
The solution to most of the performance/availability problems were to architect your VM deployments in such a way to benefit from multiple storage accounts. You would create for example 5 storage accounts and use them in a mesh so that if one of them goes down then you’re still online, but that added more work to the IT Admin who had to manage more than one storage account.
Another problem was the security aspect. You would have all your eggs in one basket and no easy way to grant access to that storage account. If you would allow access to the storage account then anybody would be able to download what’s in it. You had no way to assign permissions in a granular form as ARM allows you to. That’s one aspect of the problem. The other element was that storage accounts have access keys and anybody who has access to those keys, would have access to all the contents inside of it.
How does Managed Disks solve all of those problems?
The idea of Managed Disks was to simply IaaS VMs management and security by removing storage accounts from the equation. When you want to create a VM with a managed disk, you specify the type (Standard or Premium) and Azure does all the work for you. No more architecting and managing storage accounts, no more scalability issues and the best one is that each managed disk is considered an ARM resource in the Azure portal, thus granting you the ability to apply RBAC rules to them.
By using Managed Disks, you would get some excellent benefits like:
1. Independent resource management from a security and operation perspective
2. No single point of failure
3. Copy disks instantly inside the same region.
4. Share images without storage account copy operations.
This is just the tip of the iceberg.
Now from a price standpoint things changed a bit. With regular standard storage accounts (not premium) you would be billed the Pay-As-You-Go model, meaning that if I use 1 GB then I pay for 1GB even tho I provisioned a 1 TB disk for my VM. Managed disks are don’t have the same billing model. With them, you pay a fixed amount for each one you provision. If you provision ten 1 TB disks, then you would pay ten times x 1 TB disk at today’s rate. If you use premium disks, then you know exactly the price model. You won’t pay the same price as you would pay for a premium disk but just so that you know, this will be a fixed price depending on the size of the disk.
From a business standpoint, this makes much more sense because you can actually price VMs much easier. You have one VM, and an N amount of disks that costs X. No more storage transactions or any other “hidden” costs.
I won’t reference any price because these change and this would become outdated information faster than I press submit 🙂
The size model is almost identical to the premium disk offering; You have S4, S6, S10, S20 and S30 Standard disks and for reference, I have attached a screenshot with Standard and Premium disks performance and limits.
As you can see, HDD storage is marked with an S (Standard) and SSD storage is marked as before with P (Premium). So if I want a 1 TB HDD storage disk, then I would go for an S30 disk. That simple.
Talking about simplicity, creating a VM with a Managed Disk is easy as you would say 1,2,3. When you create a VM from the portal, you have a step where you have to configure networking, and in that step, you will be asked if you want to use managed disks. If you press yes then that’s it 🙂
From a high availability standpoint, you are not obligated anymore to put all your eggs in one basket or do storage account design to have high availability in case of an underlying storage issue. When you create a Managed Disk, you provision that much space on a storage stamp, and when you create another one, it will go to a different stamp thus having multiple fault domains.
This can be controlled by using availability sets. When you specify an availability set for your deployment, the fault domains for your VMs will also be applied to your Managed Disks.
There is one catch though; Managed Disks are LRS (Locally Redundant Storage) which means that if you need GRS (Geo-Redundant Storage), then you’re still stuck with storage accounts.
I will end this right here as I don’t want to add too much wall of text to a single blog post. I suggest that you give them a try and see what you get 🙂
A friend of mine was having issues connecting to a couple of VMs that he provisioned using an ARM template. The template worked perfectly until he added the JSON block to add an NSG.
Every time he started a deployment with the NSG block in the ARM template, he wouldn’t be able to connect to the VMs in any way. The fun fact was that even deleting the NSG didn’t solve the issue, so he had to recreate the whole environment from scratch and trust me that took a while 🙂
So what was the problem, you may ask?
He was using a source TAG Internet which for some reason (I still haven’t figured this one out), killed the connectivity on the VMs on both sides (Private and Public IPs) and funnily enough, the logs didn’t show anything.
If you encounter a problem like this one, double check your NSG blocks to not have sourceAddressPrefix: Internet but sourceAddressPrefix: *
Problematic example:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"name":"default-allow-rdp-connections",
"properties":{
"description":"Allow RDP Connections",
"protocol":"Tcp",
"sourcePortRange":"*",
"destinationPortRange":"3389",
"sourceAddressPrefix":"Internet",
"destinationAddressPrefix":"*",
"access":"Allow",
"priority":1000,
"direction":"Inbound"
}
}
Working example:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"name":"default-allow-rdp-connections",
"properties":{
"description":"Allow RDP Connections",
"protocol":"Tcp",
"sourcePortRange":"*",
"destinationPortRange":"3389",
"sourceAddressPrefix":"*",
"destinationAddressPrefix":"*",
"access":"Allow",
"priority":1000,
"direction":"Inbound"
}
}
So far I haven’t been able to reproduce it, and I’m still looking into what’s causing the issue for that particular ARM template but if you encounter something similar, give it a try and let me know your findings 🙂
Virtual network peering is a new mechanism in Azure Resource Manager that allows two virtual networks from the same region to be connected through the Azure backbone network. From a connectivity standpoint, this mechanism allows virtual machines in separate virtual networks to communicate with each other using private IP addresses. In this post, I will talk about what Virtual Network Peering is and how we can use it. (more…)
