In this video, Sharon will provide an overview of virtual machines, their benefits, and why using them makes financial and technical sense in your business. The demonstration will include creating an Azure virtual machine from a template. Azure virtual machine settings and how to modify these settings will also be covered.
- [Instructor] As an IT professional focusing on infrastructure, Azure Virtual Machines is the first place I went to, they're familiar, they're easy, and let's face it, they're really cool. Azure Virtual Machines can be created in one of two ways, you can use a template that are provided for you within Azure, there are several templates to choose from, these templates are not just the Windows stock either, there are several varieties of Linux distributions in Azure as well. In some cases, these templates are not just for one server, you can deploy an entire farm with one template.
You can also create templates of either one or several machines from existing deployments. You can also bring you own image from your on-premise environment, if you wish. This can be uploaded into Azure in one of two ways, you can use PowerShell to move it into Azure, or you can use Azure Site Recovery, not as it was intended, as a replication tool, but as a migration tool. One thing to note, as of today, August 8th, 2016, VHDX is not supported in Azure, VHD is, therefore, if you're going to bring your own images, they will need to be converted to VHD for Azure.
From experience, I would highly recommend you do the conversion from VHDX to VHD on-premise, and then move the VHD into Azure. Sometimes visualizing virtual machines in Azure can be a little daunting. Let's compare it to your on-premise, and that will help define how they look in Azure. In your on-premise environment, you would have your host system, my example here, I have Server 2012 R2. You would have the Hyper-V role running, and from that Hyper-V role, you would provision your guest operating systems.
In my example, we have Server 2012 R2, we have a Linux distro, and we'd have a Server 2008 R2. This is a very simplistic view. Moving into Azure, it's very similar, we have our Azure Resource Manager, our Cloud Service, depending on if you're working within the classic portal, you will have a cloud service. If you're working in the Azure Resource Manager, or ARM, you will have resource groups. Within these two containers, you will have the different operating systems, and again, these operating systems could be, Server 2012 R2, Linux, Server 2008 R2, Exchange Server could be in here, it could be a SQL server, the choice is yours.
So as you can see, there really isn't much difference, you don't have to worry about any of the patching from the concrete up to that Hypervisor level, as you do in an on-premise environment. Microsoft handles all of that for you, all you're going to do is create the Cloud Service or the Resource Manager, and then deploy from there. Well you may be thinking, why on Earth would I want to go to the cloud, when I can do all this on-premise and they look pretty similar? Well there's going to be a couple differences here, first of all, on-premise, you're going to pay for everything.
Whereas, when you move into Azure, or any cloud solution, you're basically going to be paying for what you use, therefore, if you spin up a virtual machine, you're going to pay for the consumption of that virtual machine as long as it is running. In the on-premise environment, you have to ensure that your outside connections can access internally. Normally we don't want to start poking holes in our firewalls, to allow outside access in. In Azure, your virtual machines are accessible with an internet connection, that doesn't mean that you do not protect your virtual machines, you still have to do so.
Creating virtual machines in Azure are easy, the templates are already there, if you go ahead and select that template for a basic virtual machine, it's about seven minutes to create. If using the templates, for the most part, the licensing is included, but always double check. Once you have a deployment, or your virtual machine is up and running, you can go ahead and duplicate them as well. Think about it from the point of view, of let's say a test and dev environment. If I reached out to every one of you right now and provided you with a build sheet, you would all provide a basic deployment, and it would be very similar.
The key here is that each deployment would be similar, they would not be the exact same. In a test and dev environment, you may need to have the exact same deployment every single time. Using templates and Azure Virtual Machines, you can ensure the virtual machine is deployed exactly the way you need it, over and over and over again. Azure Virtual Machines are highly scalable, if you need to scale up that virtual machine for a heavy workload, let's say at the end of the quarter, you'll have all the reporting that needs to be done.
Your virtual machines can scale to handle that workload, and then scale back down when the workload lightens. Let's provide a classic Azure scenario, you have a pizza place, and let's say we know one of their busiest days of the year will be during the Olympics. Everybody's focused on watching the Olympics, they don't want to cook dinner, so they're going to order in pizza. Back in the day, that pizza place would have had to provisioned the maximum hardware capacity for that single day.
Now what they can do, is they can provision that maximum hardware in Azure for that single day. After 12 hours, all those virtual machines now scale back, during the next event, or the next Olympics, as demand increases, so does the virtual machine capacity. In the on-premise environment, using Hyper-V, or VMware, allowed us to easily manage our virtual machines, the same is true in Azure, we can easily manage them from the portal.
For those of you who love PowerShell, you can manage them through PowerShell, we can script them as necessary, we can move them around, repackage them. We can move them from Azure back to on-premise, and then on-premise back to Azure. When we're done with them, we can delete them. In the test and dev scenario, we may not want that virtual machine running all night, we can go ahead and stop it, therefore we're not paying for consumption. And finally, a pro tip about Azure Virtual Machines, I've just mentioned about stopping the Azure Virtual Machine, so you're not paying for it, please be sure that you stop the virtual machine from the Azure portal.
This de-allocates the resources that are assigned to that virtual machine. If you log into the virtual machine, and you're in Server, or whatever operating system you choose, and you go down to the little button and tell the virtual machine to shut down from within the operating system, yes, that virtual machine is stopped, but it's not de-allocated. You are still paying for the consumption of it, and along those same lines, you can script out your virtual machines to shut down and de-allocate on a schedule, if you wish to do so, therefore, reducing consumption costs.
- Understanding cloud technologies
- Why Azure?
- Creating virtual networks and storage
- Using Azure Active Directory for identity management and protection
- Disaster recovery with Azure Backup and Azure Site Recovery
- Working with virtual machines