There have always been several ways to do high availability in SQL Server, but choosing the right one has always been difficult as each approach has obvious benefits coupled with unavoidable limitations:
Clustering looks after a whole instance of SQL Server containing many databases and is completely transparent to an application. However shared storage adds cost and complexity and there is only the one copy of the database(s) on that shared storage.
Mirroring creates a continuously updating replica of a given database, failover is really fast and it’s easy for a DBA to setup. However mirroring has several significant limitations:
- A special connection (SQL Server native client )is needed to mirroring so not all applications can work with it
- Protecting multiple databases so that if one fails they all fail over is not really possible.
- There is only one mirror of the database
- The mirror is not directly usable it just sits there unless you are prepared to work with snapshots.
Log shipping is sort of manual mirroring which allows more than one replica to be kept; perhaps a local one and a remote one. This is more difficult to setup and failover is not automatic you have to reset all of this yourself.
To build a better SQL Server mousetrap, you would want a solution that:
- Looks like a cluster to any application i.e. there is a DNS entry to the cluster to which the application connects without ‘knowing’ which node SQL Server is running on
- You would want to treat a group of databases as an object so that they can be failed over etc. as needed in one go.
- As with log shipping, there wouldn’t just be one other node behind the primary there would be multiple mirrors/secondaries
- The mirror could be read only and therefore available for reporting
- You could opt to have some nodes connecting asynchronously and thus have a remote replica of your databases without needlessly slowing down the primary.
Up until know that meant that we would have use more than one feature in concert e.g. mirroring and clustering together to achieve the high availability we wanted. What SQL Server 2012 AlwaysOn does is to provide this combination in one single feature:
It uses the Windows Failover Cluster feature in Windows Server but doesn’t use any shared storage. A normal install of SQL Server 2012 is then done on each node and the SQL Server 2012 service is then configured to use the cluster..
Having done that you then tell the SQL Server service on each node to use the cluster the new AlwaysOn High Availability tab in the properties for the service..
However AlwaysOn is actually doing something very similar to mirroring under the covers, in that there are replicated copies of the databases being protected not just one copy on shared storage as there is for clustering – and AlwaysOn doesn’t need to use shared storage. You’ll also notice that for databases to be protected by AlwaysOn they need to be in full recovery mode and backed up (preferably to a share that’s visible from the other nodes). However with AlwaysOn you can have multiple secondaries and you create availability groups, which are sets of the databases you want to keep together.
There’s a wizard in SQL Server Management Studio for this where you can specify the nodes, the databases and the options for accessing each node. Note this uses TCPIP ports like mirroring does (so port 5022 by default) and these need to be opened in the firewall for this all to work.
There’s a dashboard to confirm all is well ..
There is also an option to create a TCPIP listener which provides an address and DNS entry for the cluster. If you set this up you can connect directly to the cluster from any tool that can connect to SQL Server, in this case I have connected to the TechNet cluster from management studio in the same way I would connect to any other instance or cluster..
However you can also connect directly to the primary or secondary as well and for a read only secondary that’s how you would do reporting.
I have a short (8 min) AlwaysOn screen cast if you want to know more or have a guide to help you try it yourself.
Finally be aware that this is not replacing clustering, mirroring or log shipping but it is only going to be available in SQL Server 2012 Enterprise edition.