Top ten considerations for running SQL Server on Windows Azure

In June 2012 we announced the public release of Windows Http://www.aliyun.com/zixun/aggregation/13357.html ">azure virtual machines and virtual networks (we call these two service sets Windows Azure infrastructure Services), organizations around the world have since started testing their Microsoft SQL Server workloads and maximizing the functionality of the preview. The capabilities of Windows Azure infrastructure services are simply unbelievable. You do not need to purchase and manage hardware, a virtual machine (VM) that can quickly deploy a variety of different types of SQL Server workloads at a lower cost, which is widely attractive. The ability to perform complex multiple VM deployments in virtual networks, support Active Directory (AD) and SharePoint, and the ability to connect virtual networks back to internal deployment networks or remote computers using virtual private network (VPN) gateways, enabling Windows Azure Infrastructure services become a more interesting remote hosting environment for IT stores and developers. Windows Azure infrastructure Services is a stepping stone that organizations can use to migrate existing workloads to the cloud without any change, while leveraging the more advanced platform-as-service functionality of Windows Azure in a mixed way. We see that many organizations handle everything in detail, from simple development to testing the workload of SQL Server to complex, distributed, critical business workloads. From their experience, we summarize the following points.

Understanding Your SLAs:

Before unplugging the power plug on the server and migrating the SQL Server workload to Windows Azure, you need to know about the service level agreement (SLA). Note This statement: "For all Internet-facing virtual machines that have deployed two or more instances in the same availability set, we guarantee that you will be able to use external connections at least 99.95% of the time." "What does this mean for SQL Server?" This means that in order to reach the SLA, you need to deploy more than one VM running SQL Server and add those VMs to the same availability set. This also means that you need to implement a SQL Server high-availability solution if you want to ensure that the database is synchronized between all virtual machines in the availability set. The basic premise is that you need to do something to ensure high availability in the cloud, just as these workloads are running locally. When properly configured, the availability set ensures that your SQL Server workload can remain running even when you perform maintenance operations such as upgrades and hardware updates.

Understand your support strategy:

The beauty of running SQL Server in a Windows Azure virtual machine is that it is just like running SQL Server elsewhere. It can run as always. You do not need to change the application, nor do you need to worry about whether the SQL Server features are supported. When SQL Server runs in the Windowsazure infrastructure service, most features are fully supported, except for some major exceptions. Let's start with the SQL Server version support. Microsoft provides technical support for SQL Server 2008 and later versions of Windows Azure infrastructure services. If you are still running workloads in SQL Server 2005 or later, you will need to upgrade to a newer version for technical support. If you are ready to upgrade, we recommend that you upgrade to SQL Server 2012. In terms of management tools, development tools, and the underlying database engine, SQL Server 2012 is designed to have "cloud ready" software with Windows Azure built-in support.

Let's talk about high availability first. If you feel you don't need to worry about implementing a high-availability solution for SQL Server deployments in Windows Azure infrastructure services, you should reconsider the issue now. As mentioned earlier, in order to reach SLA coverage, you need to implement database redundancy within the virtual machine availability set. However, the following restrictions affect SQL Server high-availability features. First, SQL Server failover clustering is not supported. But don't be nervous, if you want to configure high availability for SQL Server, there are many other options you can choose from. For example, AlwaysOn availability groups, or using old features such as database mirroring or log shipping. We recommend that you use the AlwaysOn Availability Group feature in SQL Server 2012 for high availability, but there are several points to note when using this method. The availability group listeners are not currently supported, but we are planning to increase this support in the near future and stay tuned. If you can't wait for listener support and still want to use the AlwaysOn availability Group, there's a workaround. You can use the Failoverpartner connection string property instead. You should be aware that this method will limit the use of only two replicas (one master and one secondary copy) in the AlwaysOn availability group, and that the concept of a readable auxiliary copy is not supported.

Next, let's talk about some important things to consider when configuring storage for a SQL Server database. In general, we recommend that you attach a data disk to the VM and use that disk to store all the data and log files. If you decide to extend data and log files across multiple data disks for additional storage capacity or better performance, you should not enable Cross-domain redundancy. Cross-domain redundancy cannot be used with multiple-disk configurations because it does not guarantee a consistent write order between individual disks.

Finally, we will discuss the various "distributed" features supported by SQL Server, such as replication, service agents, distributed transactions, distributed queries, and linked servers. All of these features should work well in SQL Server VMS deployed within the same virtual network, but if you need to cross network boundaries (across public Internet or virtual network VPN gateways), you might want to thoroughly test these features. These features are designed for internally deployed data centers, including LANs and WANs, rather than across the public Internet.