It’s very much the case that many organisations rely on a single SQL Server instance to host mission critical ERP, CRM, finance and stock control systems. In the event of a serious issue with your SQL Server instance your organisation will face a system down incident potentially on a mission critical production system.
In SQL Server there are a number of options for disaster recovery and high availability should the worst happen. AlwaysOn is a term used by Microsoft to refer to a number of options for deploying a highly available SQL Server solutions resilient to single points of failure.
You should check with application vendor(s) to confirm support of AlwaysOn technologies. This isn’t just a technological question but also competency from their implementation and support teams too. If you are in the process of or considering a fresh deployment of an application – for example if you are upgrading to the latest version alongside new infrastructure – you should definitely consider including AlwaysOn as part of the solution requirements.
Prior to the introduction of AlwaysOn DBAs would consider using Log Shipping and Database Mirroring however these have now been deprecated in favour of AlwaysOn. If you are using Log Shipping and/or Mirroring for a current deployment use AlwaysOn for any future deployments.
Broadly speaking there are two AlwaysOn methods by which high-availability can be implemented. Both technologies rely on Windows Server Failover Clustering feature to be configured. AlwaysOn options are:
AlwaysOn Availability Groups (AG) provide database level failover and secondary reads for availability databases that are members of an availability group.
If you are using SQL Server Standard Edition the AlwaysOn feature is known as Basic Availability Groups (BAG) and will be limited to two members of which the secondary is read-only.
AlwaysOn Failover Clustering Instances (FCI) as the name implies provides instance level redundancy via active or passive nodes and as such relies on using a shared storage medium such as a shared disk or SAN.
There are advantages and disadvantages to both AlwaysOn methods. Ongoing maintenance from a DBA is necessary to manage the deployment and monitor performance.
Conclusion
In this post we’ve discussed why your organisation should consider adding high-availability options into your Microsoft SQL Server based solution and briefly mentioned the two key methods of achieving such resilience.
If you organisation needs support for AlwaysOn technologies for SQL Server or disaster recovery following an incident Digital Incite and Matter Ltd are here to help you. Please get in touch with us today to discuss your requirements.
