The task of upgrading a SQL Server 2008 R2 cluster to SQL Server 2012 with the idea of using the AlwaysOn accessibility groups in the future can be quite complex; it depends on the final deployment.Upgrading a clustered instance of SQL Server 2008 R2 to SQL Server 2012 is just as easy as upgrading SQL Server 2005 to SQL Server 2008. However, when upgrading a SQL Server 2008 R2 cluster (or earlier version) to SQL Server 2012, you have to Make one additional decision - if you plan to use the new SQL Server 2012 tool, namely the AlwaysOn availability groups. If you are going to work with these groups, you should decide whether the instances that will become replicas within the AlwaysOn availability group are clustered. By organizing instances in a cluster that will become replicas, you can maintain system health in the event of additional failures of physical servers without losing access to the database replica.
When deploying AlwaysOn Availability Groups to use non-clustered instances of replicas, it will be much easier to work with this configuration. However, in the event of a server outage due to a system failure or as part of system maintenance, less database replicas will remain at your disposal. As a result, it will take more time to restore the synchronization of the contents of a replica hosted on a disconnected server with a working database.
Upgrade to Clustered Instance
The process of upgrading a clustered instance of SQL Server 2008 R2 to SQL Server 2012 is fairly simple. It is a lot like the procedure for upgrading a clustered instance of SQL Server 2005 to SQL Server 2008. The only difference is that instead of the installation tools implemented in SQL Server 2008, you should use the installation tools of SQL Server 2012.
So the upgrade process is simple. However, it provides a significant reduction in the downtime of a database application. This reduction is achieved due to the fact that the corresponding database instance after installation saves the settings of the clustered instance and the AlwaysOn availability group uses the clustered instance of SQL Server as a replica.
Having completed the cluster testing and sent it to the production network, you can start creating AlwaysOn accessibility groups.
Upgrade to Non-Clustered instance
Converting an installed clustered instance to a nonclustered one is a rather complicated process. The fact is that this scenario does not have its own modernization process. The best way to upgrade is to add additional nodes to the Windows cluster and install standalone instances on these new nodes. At the same time, you can install additional hardware components on an existing Windows cluster or get away with existing ones.
Installation without using new equipment. The idea of acquiring new hardware to upgrade installed clustered instances to a non-clustered level may cause management disapproval. After all, by installing nonclustered instances on an existing SQL Server 2008 R2 cluster, we remove the issue of acquiring new nodes for SQL Server, or at least postpone the solution of this issue until the initial instances of SQL Server 2012 are brought to a working state.
Note that although such an approach to the modernization process can provide financial savings, it is fraught with certain risks. Installing SQL Server 2012 systems on existing SQL Server 2008 R2 cluster nodes may cause problems with the operation of existing clustered SQL Server systems. In addition, difficulties may arise in the process of reconfiguring storage SAN.
When installing SQL Server 2012 systems on existing SQL Server 2008 R2 nodes of a Windows cluster, follow the instructions below.
- Modify the storage device array settings to match the storage configuration requirements so that the storage media is provided to the independent nodes and at the same time the cluster storage media is provided to the existing nodes.
- Provide independent storage for each cluster node on which SQL Server 2012 will be installed. Ensure that each node uses the same drive letters and the same routes.
- Install the SQL Server 2012 systems on the appropriate nodes.
Installation using new hardware components. By installing new hardware, we eliminate the risk that deploying SQL Server 2012 systems will make it difficult for existing SQL Server systems to work. In addition, potential problems associated with reconfiguring storage for existing Windows cluster nodes are eliminated.
SQL Server 2012 nodes can be brought up as follows.
- Install Windows 2008 R2 Enterprise Edition on new sites. Use the same update level as an existing Windows cluster.
- Configure the storage array so that independent storage is provided for each new node. Make sure that each new node uses the same drive letters and the same routes.
- Add new nodes to existing Windows clusters.
- Install the SQL Server 2012 package on new nodes in a format of independent instances.
You may have installed SQL Server 2012 nodes on new hardware components, or maybe? On existing ones; in any case, the next step in the process will be to test these nodes. Ensure that they function correctly and that the storage media attached to them provides the necessary performance.
If the nodes are working correctly, you can start migrating the databases. If you move databases, you can’t do without downtime, because a more traditional database migration should be completed. The most traditional upgrade option is to deliver these databases to an instance of SQL Server 2012 using the log shipping mechanism. As a result, if you migrate a database from a clustered instance of SQL Server 2008 R2 to a nonclustered instance of SQL Server 2012, idle time will be minimized.
After the databases are restored on a new instance of SQL Server 2012 and after they are included in the production system, you can create AlwaysOn availability groups.
At this stage, an instance of SQL Server 2008 R2 can be removed using the traditional process of uninstalling SQL Server 2008 R2 on both nodes in the cluster. Care is required here, since you only need to remove the components of SQL Server 2008 R2, but not the components of SQL Server 2012.
Windows Server 2008 based clusters
SQL Server 2012 packages are usually installed on servers running Windows Server 2008. However, these clusters need to be upgraded to at least Windows Server 2008 SP2, as well as the updates described in the Microsoft article This update is required to install Visual Studio components that are used by SQL Server 2012.
Before installing the SQL Server 2012 package on a Windows Server 2008 cluster, it is highly desirable to upgrade such a cluster to the Windows Server 2008 R2 level; the fact is that the Failover Clustering component of SQL Server 2008 R2 has been modified specifically for accessibility groups AlwaysOn and for listeners for these availability groups. To implement this upgrade, it is necessary to replace the existing cluster with a new Windows cluster due to the lack of a method for upgrading systems that exist within the cluster. If the same physical servers are used in the process of creating a new Windows cluster, they can be removed from the cluster (one node at a time), formatted, installed into a new cluster, and prepared for installing SQL Server 2012.
Clusters based on Windows Server 2003 or Windows Server 2003 R2
Before you start upgrading to SQL Server 2012, SQL Server clusters built on the basis of Windows Server 2003 or Windows Server 2003 R2, you need to upgrade to a more modern version of Windows. Unfortunately, this is not as easy as it may seem, since clustered Windows systems do not allow operating different versions of Windows on different nodes of the same cluster. In essence, this means that before proceeding with the installation of SQL Server 2012, you have to create a completely new Windows Server 2008 R2 cluster with a new network cluster name and a new IP address.
Conclusion
The blog discusses how can you upgrade SQL Server 2008R2 to version 2012 using AlwaysOn. It covers step-by-step process to upgrade from clustered as well as non-clustered instance. Also the blog covers the upgradation based on Windows Server 2008, 2003, 2003R2 instance.
EmoticonEmoticon