Microsoft Azure is quite a known entity when it comes to cloud computing essentials. Based on raw technology, Azure offers two variants of relational services pertaining to SQL Server deployments. First off, the Azure database for SQL server works on the lines of PaaS or Platform-as-a-Service, followed by the 'SQL Server Instance' for IaaS or Infrastructure-as-a-Service. While the former offers primary benefits—eliminating the minor glitches associated with overheads—the second one brings in the new concept of unrestricted access—mainly towards minimizing the overall costs.
That said, we need to get into the details of 'Azure SQL Database' for churning out most of this self-proclaimed cloud platform. Our only concern for the time being should be on the resiliency of the SQL Server deployments, especially the one concerning On-Premise services. In this post, we will be separating the two functionalities—covered under the concept of 'Azure Recovery' solution.
Automating SQL Server Deployment
But, before even delving into the aspects of SQL Server Deployment, we must look for a few ways to get it enrolled into the world of Azure IaaS VMs. This way we will be better served with handling aspects of the same:
- We can use an easily available Azure Gallery that supports SQL server Installation. This might be the one optimized for data warehousing.
- The featured 'Azure Gallery Images' need to incorporate the 'Windows server installation guidelines' for getting the best out of the 'SQL Server Deployments'.
- We can also upload the custom OS on the Azure storage—making it work like a virtual machine. For better options regarding the models and orientations, VPSserver.com might just be the perfect alternative for most users. Once the concepts regarding the ‘SQL Server Instance’ are clear—one can begin with the OS deployment.
- The last option would be to upload or create a custom OS image—working in tandem with the featured SQL server. This calls for the introduction of the pre-staged ‘SQL Server Installation’.
If details are to be spilled—the first option is the easiest for the organizations. The complete deployment procedure can, therefore, be scripted with Windows PowerShell. The drawbacks for the same would be automatic installations and less scope for customizations. Some applications might not be useful and removing them might be a difficult and time-consuming affair.
The second option of using ‘Azure Gallery Image’ is a better alternative but this service is still under scrutiny and not at its prime. Using this one can automate the entire procedure and customize the installation—based on preferences.
We can also make a variation with the third option that allows us to upload something to the Azure storage. This way we are better off with the myriad organizational policies. Most operating systems pertaining to Azure belong to corporate mandates and, therefore, we need to implement this alternative for accessing the Cloud Resident Virtual Machines.
The previously mentioned options can again be amalgamated into the 4th alterative—offering options for implementing Custom-Configured ‘SQL Servers’. The instances can then be applied to the virtual machines with minimal hassles.
However, irrespective of the procedure, one must follow a few guidelines toward automating the deployment procedure. Multiple disks with data need to be used besides ensuring the credibility of the Geo-Replicated Storage account. Disk caching needs to be turned off followed by the implementation of ‘Buffer Pool Extensions’.
Starting Off With the Resiliency Plan
It would be good to begin with the underlining concepts of Azure Site Recovery—a cloud-centric service, facilitating the skillful implementation of disaster management plans. For these to succeed we need to get hold of orchestration and even replication.
The first entity happens to be replication—handling data synchronization between secondary and primary sites. This extends up to semi-protected and protected systems—pertaining to the cloud computing technology. Next, we have orchestration—meant for managing multiple processes. These include the instances of unplanned, planned, and the test failovers—mainly between the intertwined sites. This process can be initiated following a series of easy steps—termed as the fated ‘recovery plan’. One can follow the same by automating the execution and controlling the order of steps. Most of these ideas are the backbones of the PowerShell scripts or the automation runbooks—pertaining to the ‘Azure Site Recovery’. Using orchestration one can host the secondary site to some other on-premise location, or on to a virtual Azure network—following the IaaS model.
Again the ‘Azure Site Recovery’ can accommodate multiple platforms and workloads. Following this, we can skillfully implement virtual and physical servers with the same. The virtual servers are perfectly hosted on Hyper-V and the VMware ESX. This can be implemented with or without the Virtual Machine Manager layer—based on the System Center Management.
While both these recovery scenarios have viability associated with them—the choice depends on our existing environment. In the upcoming parts, we will be focusing on the methods to safeguard IaaS deployment concerning Microsoft Azure. Our primary focus will be on the design choices—offering multi-site resiliency for the dependent SQL Server.
The concept of Failover Cluster Instance comes in handy when we need to host the replica of multiple availability groups—mainly with primary over the secondary. The AlwaysOn FCI works only with the concerned AlwaysOn availability group. This version of a resiliency plan must mean that FCI must readily reside on-premise with the IaaS VM. The reason for the same is shared storage—an option that isn’t supported by Azure VMs. Then we need the SQL Server Enterprise for countering the pricing issues. Azure Virtual Machines offer licenses via gallery based images or the BYOL. One can leverage the existing license with the ‘Windows Server Image’. After the cost effective licenses are taken care of, we need to select the asynchronous commit—mainly for segregating the remote replica. This is turn avoids the negative impacts, owing to the network latency.
- The next step would be to make sure that AlwaysOn FCI resides On-Premises and allows hosting a local data instance—concerning the mirrored database. The remote instance for the same is, however, available in the Azure IaaS Virtual Machine—working in unison with the ‘SQL Server Instance’. As mentioned, we need the Failover Cluster Instance to work with On-Premise instances—owing to the concept of shared storage. However, when it comes to the mirrored database we need not deploy the server enterprise—associated with SQL. The reason for the same is the harmony of database mirroring with the standard edition—considerably reducing the licensing fares. Another dwindling constraint might be the availability of Dual-Nodes, but this anomaly is minimized by the introduction of single secondary and single primary. For IaaS VMs, we have to play with both synchronous and asynchronous modes. While the first one relies primarily on safety— the secondary one is only concerned about performance. Both of these need to work together in order to strike the perfect balance between availability and disaster management. Based on the resilient approach, we must work with the second option—mainly for keeping the network connection and latency in mind.
- The next approach towards AlwaysOn FCI would be to work with two or more ‘SQL Server Instances’. While these might go on replicating synchronously, the remote instance associated with the same will surely get hosted in Azure IaaS virtual machine, putting forth the concerned instance. This gets configured with the asynchronous commit while keeping up with the involvement of the enterprise edition. Using this edition for both of the environments allows for better ‘Recovery Time Objective’. The next resilient approach would be the availability of better RPO or ‘Recovery Point Objective’. This is skillfully followed by superior scalability of sorts. While these approaches wouldn’t preclude the entire concept of FCI, based on the availability group, one can only make use of one failover clustering instance—depending upon the requirements.
- The next approach would be the involvement of the ‘Standalone SQL’ server instance. These techniques make use of the Azure Storage Account followed by other on-premise approaches. One can therefore skillfully safeguard the SQL servers using the ‘Azure Site Recovery’. One aspect that needs to be taken into account is the featured page blobs. These are the replication targets clubbed with the VHD files. These files make up the backbone of the Azure IaaS VMs—facilitating seamless hosting of the Server Instances. These SQL entities are readily brought online, in case of a failover.
However, in the above-mentioned cases, ‘Azure Site Recovery’ works with the underlining concepts of orchestration and even replication.
In the end, users can make the perfect concoction of SQL-specific features and the underlining perks of ‘Azure Site Recovery’. The former, after installation, brings in high-availability features that are extremely resilient. This way we can perfect the continuity objective associated with the businesses. Be it the budget defined goals or the design solutions, resiliency in the approach allows us to be creative with the cloud computing needs. Again, we must take into account the infrastructural prerequisites before starting off with the entire procedure. This includes authentic active directory authentication and even the on-premise Azure connectivity.
Look out for more on high-end scenarios offering resilient approaches to ‘SQL Server Deployments’.