Cloud Computing is the buzzword for the business and Windows Azure with SQL Server provides much more flexibility on availability. The key factor for the Azure is TCO – Total Cost Ownership, which is reduced where the Windows Azure VM enables the reduction of deployment, management and support for those servers. Using Windows Azure and migrating the needed SQL Server applications to these VMs requires minimal code changes. As these Virtual Machines are built with Enterprise standards, DBAs and Developers can continue their development and administration as usual on-premises.
The key factor to move towards Windows Azure will be High Availabilty (HA) and Disaster Recovery (DR) – HADR. This solutions is available in SQL Server and Windows Azure VMs, as a cloud solution and Hybrid-IT solutions. From the Microsoft documentation it refers that: … In a cloud database solution, the entire HADR system runs in Windows Azure, and client applications can connect to it from within Azure or from the internet, such from an on-premise network. In a hybrid-IT database solution, part of the HADR system runs in Windows Azure and part of the system runs on-premise in your organization.
As per the Service Level Agreements (SLA) DBAs can ensure that cloud databases can have similar levels of availability by using the HA mechanims provided by Windows Azure + SQL Server HA options. Also during the server patching or possible lengthy downtimes the Applications can be moved over to ensure availability is addressed.
Technet documentation refers the possible scenarios covered by SQL Server HADR Solutions along with Windows Azure Infrastructure which is called Infrastructure-as-a-service (IaaS), this is a combination of SQL Server HA + DR along with cloud-only or hybrid enviornment. See the table below:
|AlwaysOn Availability Groups (see AlwaysOn Availability Groups (SQL Server))||Database Mirroring (see Database Mirroring (SQL Server))||Log Shipping (see About Log Shipping (SQL Server))|
|Azure-only||All availability replicas running in Windows Azure VMs for local high availability.The Windows Server Failover Clustering (WSFC) cluster requires an Active Directory domain running on a domain controller.
You cannot run the availability group across Azure datacenters because cross-datacenter virtual networks are not currently supported in Windows Azure, and an active directory domain cannot span multiple Windows Azure datacenters.
|Principal, mirror, and witness servers all running in Windows Azure VMs. No domain controller is required if deployed using server certificates. Two scenarios are possible:
||While you can run log shipping database servers in the same Windows Azure datacenter, log shipping is not a high availability solution.|
|Hybrid IT||Some availability replicas running in Windows Azure VMs and other replicas running on-premise for cross-site disaster recovery.Because all availability replicas must be in the same WSFC cluster, the WSFC cluster must span both networks (a multi-subnet WSFC cluster). This configuration requires a VPN connection between Windows Azure and the on-premise network.||
||One server running in a Windows Azure VM and the other running on-premise for cross-site disaster recovery. Log shipping depends on Windows file sharing, so a VPN connection between the Windows Azure virtual network and the on-premise network is required.|
Furthere the following links are very useful to understand how these Availability Groups are handled in the form of Tutorials:
- Tutorial: AlwaysOn Availability Groups in Windows Azure
- Tutorial: AlwaysOn Availability Groups in Hybird IT
- Tutorial: Database Mirroring for High Availability in Windows Azure
- Tutorial: Database Mirroring for Disaster Recovery in Windows Azure
- Tutorial: Database Mirroring for Disaster Recovery in Hybrid IT
- Tutorial: Connect to SQL Server in the same cloud service
- Tutorial: Connect to SQL Server in a different cloud service
- Tutorial: Connect ASP.NET application to SQL Server in Windows Azure via Virtual Network