This is the second post for the mini-series entitled “Hosting SQL Server in Window Azure IaaS Fundamentals”. In this post I will teach you about Azure disks and images. The concept of Azure images and disks is a key concept that I have found is at least initially often confusing to customers wanting to use SQL Server. As we progress into this mini-series we talk about some of the different ways to get SQL Server into Azure IaaS, such as capturing an existing Windows Azure image or loading a VHD into the Azure IaaS Cloud. So you will need to understand what makes up an Azure disk, an Azure image, and when you would use either to host SQL Server in Azure IaaS. I will review your licensing options for SQL Server on Windows Azure IaaS for disks and images, and offer recommendations for sizing of your VMs based upon your version of SQL Server. I will offer some key points and summarize this post at the end.
When you use SQL Server in the Azure IaaS environment it is no different than any other hosting environment in that you need to properly license your software. Your choice of licensing options can be a big factor in the option you choose to get SQL Server into Azure IaaS. If you choose to use a pre-installed version of SQL Server that is already installed on the VM, you have two options for the VM size.
• Standard VM (in all sizes) that will cost you around ~$1700 per month for a Medium size VM., or $1830 for a Large (4CPU/7GB RAM)
• Memory intensive VMs comes in just two sizes:
o Large (4CPU/28GB RAM) at $2321 per month
o Extra Large (8CPU/56GB RAM) at $4643 per month
If you choose to install your own version of SQL Server on the VM, your Azure costs are based solely upon the base Windows Server VM. You can take advantage of Windows Software Assurance through Licensing Mobility to manage the licensing of SQL Server on your VM once you install it yourself. And if you move a VM with SQL Server already installed from your on premises VM you just use that license with no changes.
When you deploy SQL Server to the Azure IaaS Cloud, you need to make the correct choice of Azure VM size to host the SQL Server. Regardless of the licensing mode you choose for running SQL Server on a VM you will want to use at least a size Medium. This contains two cores, and 3.5 GB of RAM in the current configuration. This is the minimum choice for SQL Server Standard Edition. If using the SQL Server Enterprise Edition to take advantage of advanced features such as Reporting or Analysis Services, you will want to use at least a size Large. This contains 4 cores and 7 GB of RAM in the current configuration.
An often overlooked feature of the chosen VM size is related to the size of your SQL Server database. You want to make sure that the VM size you choose will support the size of database in its current and future size. There is a limit on the size of an individual disks in Azure IaaS of 1 TB. If you have a SQL Server database that is say 10TB, would need 10 of these disks to accommodate it. And you would have to create multiple physical disks and span them into one large logical disk. That process is beyond the scope of this post. But realize there are limits on number of disks based upon the VM size you select. Refer to Virtual Machine and Cloud Service Sizes for Windows Azure for the available sizes and options for the virtual machine-based compute resources you can use to run your apps and workloads.
You will use Azure images as a base image with which to create one or more instances of VMs.
An Azure Image needs to be generalized so they can be used to generate specific VM instances. To generalize the VM Image, you must first run the Sysprep utility and check the Generalize checkbox. The Sysprep utility sterilizes a VHD by removing system-specific data. This permits you to use it generically as an image base for more than one VM instances. So if you run Sysprep on a VHD you can load it as an Azure VM Image. You will want to run Sysprep before you capture a VM image (to be discussed shortly).
There are situations when you may not want to run Sysprep on a VHD since in some cases making that disk generic can render it useless for its desired application. But you still want to run your VHD in Azure. For instance, you may have a Domain Controller on your VHD and executing Sysprep would make it ineffective as a DC. You will also most likely not be creating duplicate VMs from an image of a DC and therefore not need to run Sysprep. If you don’t Sysprep the VHD then you can only load it into Azure as a VM Disk. This serves as a specific base for a unique VM. It is not a generic image from which you will be creating multiple generic images.
• Azure Disks and Images look very much the same from a portal storage standpoint. Both VHDs in blob storage. The difference it in how they are prepared before they are loaded into Azure.
• VM Disks are generic images from Sysprep and create multiple generic Azure Image VMs
• VM Disks are not made generic with Sysprep and create a unique Azure Disk VM
• Azure VMs use Hyper-V fixed format VHDs. So if you upload a dynamically formatted VHD it will be converted to fixed format. This may cause an unexpected bloat during the upload and yield a size greater than the 127 GB disk size limit imposed for Azure IaaS VM images. Thus it is recommended that you create a fixed format VHD before you upload it to Azure and don’t rely upon the conversion from dynamic to fixed format during the upload process. VHDs can be uploaded using a PowerShell cmdlet Add-AzureVhd or using the CSUPLOAD SDK utility and must be 127Gb or less in size
• When you delete a VM Azure creates a Cloud service to preserve the DNS value as well as hold onto any resources that are linked to that VM such as VNETs and attached disks.
• Be conscious of the cost for the size of the M sizes – cost and capacity
• Licensing – BYOL or pay increased costs for VM
• Azure Images – Generic and allow you to create multiple VMs
• Azure Disks – Specific to configuration and create a single unique VM