Quick way of achieving HA when a POC becomes dependable to the business!

By Dan Stillwell – Data Platform Solution Architect.

The great thing about Azure is the flexibility that it offers to customers and how they can use it. I have been working with customers who have various levels of strategy when it comes to the cloud, some customers are actively moving workloads, whilst others are testing its capabilities to see where it fits with their organisation needs.

I have seen Azure being used for POC's (proof of concepts). This is a great use of Azure, it can give flexibility, latest technology and deployment speed. No longer does a project team have to wait for the provisioning and deployment of hardware and software (excluding the fact that through Scripting, System Centre you can deploy to on- premise in an automated and timely manner).

Very quickly in Azure you can deploy a SQL Server which can consume workloads. You have choices in which method you deploy; IaaS, PaaS, or a hybrid scenario. Being quick to deploy to is a key advantage of Azure, but it can also be a disadvantage if proper planning of the solution has not taken place.

I am working with one customer at the moment where they have deployed a POC and are using SQL Server IaaS within Azure. They love the elasticity, scale and other benefits that come with VM's in Azure. The POC and project has gained momentum within the organisation and the POC now has many more users which is not an issue for the performance due to its scalability. The issue they are now facing is that some senior members of the organisation are testing and using the POC. The project team have now taken the decision that they need some form of High Availability and redundancy.

When the POC was deployed within Azure, it's focus was to ensure functionality. As such, the architecture consisted of one SQL IaaS VM. One VM does not give any SLA's to the customer, this made the project team uneasy. In Azure and within a month period there will always be downtime, this could be planned (patching) or unplanned (emergency patching, host failure), if you have a failure on one VM the VM will come back up in a short period of time, but if the SQL Server is being used at this time, then there will be a service outage to its users.

To ensure that there was an SLA of 99.95%, there needs to be 2 or more SQL Server VM's. The other advantage of more than one VM is Availability Sets, this gives the HA advantages of VM's being placed in separate racks, it also allows the Azure fabric controller to identify what hosts to patch so the VM's hosts are not patched at the same time causing downtime. This would give the VM's (IaaS supporting SQL Server) HA but not at the SQL Server workload or data level. If this was an on premise solution you would look to add SQL Server AlwaysOn. It is no different in Azure, using IaaS, you still need a technology to give HA at the SQL Server level. Typically, AlwaysOn would be a great choice.

At this point we hit the issue that SQL Server was deployed using the Marketplace and on Standard Edition of SQL Server. AlwaysOn in 2014 requires Enterprise Edition and because the license cost is covered by the Marketplace image, there is no way to upgrade the edition of SQL Server.

The choice now was to either deploy the AlwaysOn configuration using the MarketPlace or deploy two IaaS VM's running SQL Server Enterprise Edition utilising your license with Software Assurance (mobility) and configuring the domain controllers, Clustering and AlwaysOn. To deploy SQL Server AlwaysOn within VM's gives more complexities around setup and support going forward. As this is a POC minimal support would be available which led to another option.

Due to the SQL Server database (both schema and data) having to be migrated off the Marketplace image, the effort would be the same if we were to migrate the database to another IaaS VM or migrate to Azure SQL Database. Azure SQL Database (PaaS) gives an SLA of 99.99%. Again, they only required a standard pricing tier as they had no more than 250GB of data and the performance requirement was low. The service tier can always be increased or decreased depending on usage without impacting the availability of service. If you require more information on service tiers then read the following https://azure.microsoft.com/en-gb/documentation/articles/sql-database-service-tiers/?rnd=1

The additional benefit for PaaS over IaaS for this POC was the service is managed by Microsoft. PaaS on a standard tier gives a 14-day point in time restore point which is adequate for their RPO. Geo- Restore of the database is also available across all service tiers meaning that if a site went down, you can recover your database to another site. SQL Database at a standard tier now (since April 2016) gives Active Geo- replication, this more than met their requirements for DR as this protects against Azure regional outages by maintaining a secondary SQL Database copy. From April 2017 any implementations of standard Geo-replication will be automatically upgraded to Active Geo-replication. This is in addition to the HA that SQL Database gives within a datacentre which is managed by the service (two additional copies of the primary database, 3 in total). SQL Databases are built on a fault- tolerant architecture meaning that the local copies (3 in total) are on difference fault domains with automatic failover when failure is detected. This will protect against most failures apart from loss of datacentre.

Next up will be how to migrate your schema and data from the IaaS SQL Server to the Azure SQL Database (PaaS). This will also apply to migrating data from on premise to Azure or Azure to on premise.