Introduction
The SQL Server Setup process is really straight-forward. An experienced user who has got a little knowledge in setting up other applications can also perform a SQL Cluster Setup but what if issues occur? What will you do if you don’t see the newly added disks in the SQL Cluster Setup wizard? What will you do if you don’t see the list of available nodes in the SQL Cluster Setup screen? What if SQL Cluster Setup wizard fails to configure other nodes in the cluster?
The main objective of this article is to explain the internal process behind the SQL Server Cluster Setup. Please note this article only explains the SQL Cluster Setup process. It doesn’t explain the SQL Server Standard Setup process. By reading this article you can explain the mechanism SQL Setup uses to find the list of nodes, list of disks and list of interfaces available in the cluster and also the SQL Cluster Setup DLL (SQLCluster.DLL) which is responsible to do the initial pre-work for SQL Setup wizard. This article also explains the how SQL Cluster Setup detects that it is going to operate in a cluster environment.
The second series of this article will explain all the registry entries and SQL modules/files which are important for a successful failover and how you can play with these registry entries and files to troubleshoot the SQL Cluster. Most of the article talks about the SQL Server 2000 but the process and troubleshooting techniques are the same for SQL Server 2005. This article will also explain how SQL Cluster Setup configures other nodes to be cluster-aware.
The failover clustering is used by the SQL Server because SQL Servers are state-full applications. When the SQL Server setup wizard realizes that it is going to operate in a cluster environment, the setup wizard will give you an option to create SQL Virtual Server. You will select this option to create a SQL Cluster. After you select the Virtual Sever option, the setup proceeds to invoke the SQL Cluster modules and perform many tasks in the background. These tasks and process will be explained in detail later in this article.
The main objective of this article is to explain the internal process behind the SQL Server Cluster Setup. Please note this article only explains the SQL Cluster Setup process. It doesn’t explain the SQL Server Standard Setup process. By reading this article you can explain the mechanism SQL Setup uses to find the list of nodes, list of disks and list of interfaces available in the cluster and also the SQL Cluster Setup DLL (SQLCluster.DLL) which is responsible to do the initial pre-work for SQL Setup wizard. This article also explains the how SQL Cluster Setup detects that it is going to operate in a cluster environment.
The second series of this article will explain all the registry entries and SQL modules/files which are important for a successful failover and how you can play with these registry entries and files to troubleshoot the SQL Cluster. Most of the article talks about the SQL Server 2000 but the process and troubleshooting techniques are the same for SQL Server 2005. This article will also explain how SQL Cluster Setup configures other nodes to be cluster-aware.
The failover clustering is used by the SQL Server because SQL Servers are state-full applications. When the SQL Server setup wizard realizes that it is going to operate in a cluster environment, the setup wizard will give you an option to create SQL Virtual Server. You will select this option to create a SQL Cluster. After you select the Virtual Sever option, the setup proceeds to invoke the SQL Cluster modules and perform many tasks in the background. These tasks and process will be explained in detail later in this article.
FIGURE 1.1 – SQL Cluster Server Setup process and Registry Entries.
How does SQL Cluster Setup process detect that it is going to operate in a cluster environment?When you start the SQL Server Setup wizard, it will give you the three options to install the SQL Server Database engine. The three options are:
· Local Computer,
· Remote Computer and
· Virtual Server
The last option is to install the SQL Server Database engine in a cluster. The setup checks to see if it is going to install the SQL Database instance in a cluster environment. The Setup doesn’t really look for cluster modules or DLL files. Instead it checks the Cluster Service status. If Cluster Service is running it will give the option to install the SQL Virtual Server Instance. You will not see Virtual Server option if Cluster Service is not running or stopped for any reason. If you’re troubleshooting a SQL Server cluster installation, make sure the cluster is up and running (e.g. Cluster Service is running). Please note the Setup Wizard doesn’t check the registry of the Cluster Service at HKLM\System\CurrentControlSet\Services\ClusSvc. Instead it checks the ClusSvc.exe system instance which is running in Task Manager and executes a series of API calls via Service Control Manager (SCM ) to check the status of the Cluster service.
How SQL Setup knows which files to copy After SQL Server Cluster Setup wizard detects that it is going to install the SQL Server instance in an existing cluster, it invokes the SQLCluster.dll from its BINN directory to execute the following functions:
DoSQLClusterSetUpWork - Installs the SQL instance in the cluster
DoUnClusterSetup - Uninstalls the SQL instance from the cluster
CheckDatabasesForInstance - Checks existing SQL Instances already installed
These functions are explained later in this article.
SQL Setup copies files during the setup process. Setup doesn’t really know which files to copy. It reads a file on the CD named 70cluster.lst. This file resides at x:\x86\setup directory on the SQL Server Setup CD. You can se all files copied during the setup by opening the file in notepad as shown in below figure 1.2:
FIGURE 1.2 – SQL Setup Files copied during installation
These files are copied to %INSTPATH%. %INSTPATH% is a system variable. The complete path in this variable is the value which is entered during the installation process. The user running the SQL Setup supplies the complete path. If you ever encounter any problems with the copy, make sure the 70cluster.lst file contains the entries for SQL Modules. The best way is to copy this file from the SQL Installation media to the source folder from which you are running the SQL Server setup.
There are other files which are copied by the SQL Server setup wizard. These files are not part of the 70cluster.lst.
Which SQL module is responsible for SQL Cluster Setup and what all basic functions it implements for a successful installation?
As explained earlier, SQL Server setup invokes the SQLCluster.dll module from its BINN directory when it realizes that it is going to install the SQL Instances in a cluster environment.
It executes the following functions from SQLCluster.dll module:
DoSQLClusterSetUpWork
As shown in Figure 1.1, this function is defined in the SQLCluster.dll module. The main purpose of this function is to install the new SQL Instances in the cluster. This is the main step for installation. The setup performs the pre-tasks for the SQL installation by using this function. For example, gather the list of nodes, list of disks, list of network interfaces etc. If you add any new disks to the cluster while the SQL Server setup is running, the disk will not be recognized by the SQL setup process unless you exit the setup and start it again from scratch. This is because the DoSQLClusterSetUpWork function executed from SQLCluster.dll gathers the cluster configuration information before it comes to select the disks or nodes available in the SQL Setup.
DoUnClusterSetup
The next function is DoUnClusterSetup. The main responsibility of this function is to prepare the setup to uninstall any existing SQL instances from the cluster. You uninstall existing SQL instances from the cluster with the help of this function. If this function is not implemented then you will never be given an option to uninstall existing SQL instances.
CheckDatabasesForInstance
The last function of SQLCluster.dll is CheckDatabasesForInstance. The main purpose of this function is to check any existing instances in the cluster. This function is useful in both the cases (when installing an instance and when uninstalling an instance). Before SQL Server setup installs or uninstalls any instance from the cluster, it executes to check to see if the given instance name is already installed on the system. SQL Server setup process will not allow you to install the same instance if it is already installed. This is how SQL cluster detects the existing installed SQL instances.
After the SQL Server setup process has finished with this, the next step is to detect the list of nodes, list of disks and list of interfaces available in the cluster. This work is done by the DoSQLClusterSetUpWork. The next section explains this in detail.
From where does SQL Setup get a list of disks, nodes and interfaces available in the cluster?After you have selected the “Virtual Server” option, the wizard will gather the required information from the cluster. The information may include the List of Disks, List of Nodes available in the cluster, list of Interfaces etc. This information is required for proper installation of the SQL Database instances in the cluster.
The SQL Server Setup wizard completely depends on the Cluster Configuration Database. The SQL Setup retrieves the cluster configuration information from HKLM\Cluster hive. This hive is mapped with %SystemRoot%\Cluster\CLUSDB file. The Setup doesn’t really have knowledge of the number of disks available in the cluster. So it always queries the registry to get this information. The “Cluster Disk Selection” dialogue box will be displayed to select the cluster disk on which the SQL Databases will be installed as shown in Figure 1.3:
FIGURE 1.3 Cluster Disks selection for SQL Server Databases.
This information about the disks is retrieved from the following location in the registry:
HKEY_LOCAL_MACHINE\CLUSTER\Resources\{GUID of the Resource}.
A function will be executed from the SQL Setup to find all the resources for which the Resource Type is “Physical Disk”. The name of the Disk is indicated by a registry entry called “Name=disk_name”. In Figure 1.3 you can see SQL Server Setup wizard has found two disks available in the cluster. The below figure shows the registry entries created for a Physical Disk Resource:
FIGURE 1.4 Cluster Disks stored in Registry.
The GUIDs shown above are retrieved programmatically by the SQL Server Setup Wizard. Setup will filter all the resources for type=Physical Disk. This list will be presented to the SQL Server Setup screen to select a disk for the SQL Database. Please note only the Disks that are online will be displayed in the SQL Server Setup wizard. For example, if there are 3 disks in the cluster and 1 is offline for some reason. The Setup Wizard will only show two disks. Thus you should always check the cluster for disks on which you are going to install the SQL Databases.
If you ever encounter any problem or SQL Server Setup doesn’t show the disks correctly try to check the above registry entry for disks or open the Cluster Administrator. Please note, creating disk resources manually in the above registry location will not help. Because when the IsAlive interval for Physical Disk expires, a query will be executed to check the status of the disk. IsAlive checks to see if the disk is operating normally. If not, IsAlive will take the disk offline or the disk will be considered to have failed. The PersistentState value indicates the disks status (1=online and 0=offline) as shown in Figure 1.4.
After you have selected the Cluster Disk for SQL Databases, the Setup asks you to enter the Virtual Server IP Information as shown in below Figure 1.5:
HKEY_LOCAL_MACHINE\CLUSTER\Resources\{GUID of the Resource}.
A function will be executed from the SQL Setup to find all the resources for which the Resource Type is “Physical Disk”. The name of the Disk is indicated by a registry entry called “Name=disk_name”. In Figure 1.3 you can see SQL Server Setup wizard has found two disks available in the cluster. The below figure shows the registry entries created for a Physical Disk Resource:
FIGURE 1.4 Cluster Disks stored in Registry.
The GUIDs shown above are retrieved programmatically by the SQL Server Setup Wizard. Setup will filter all the resources for type=Physical Disk. This list will be presented to the SQL Server Setup screen to select a disk for the SQL Database. Please note only the Disks that are online will be displayed in the SQL Server Setup wizard. For example, if there are 3 disks in the cluster and 1 is offline for some reason. The Setup Wizard will only show two disks. Thus you should always check the cluster for disks on which you are going to install the SQL Databases.
If you ever encounter any problem or SQL Server Setup doesn’t show the disks correctly try to check the above registry entry for disks or open the Cluster Administrator. Please note, creating disk resources manually in the above registry location will not help. Because when the IsAlive interval for Physical Disk expires, a query will be executed to check the status of the disk. IsAlive checks to see if the disk is operating normally. If not, IsAlive will take the disk offline or the disk will be considered to have failed. The PersistentState value indicates the disks status (1=online and 0=offline) as shown in Figure 1.4.
After you have selected the Cluster Disk for SQL Databases, the Setup asks you to enter the Virtual Server IP Information as shown in below Figure 1.5:
FIGURE 1.5: SQL Virtual Server IP Information
The information entered here will be recorded later in the registry and using this information the SQL Virtual Server will be assigned an IP Address for clients to access the SQL instance over the network. You notice one thing here; the SQL Setup also gets a list of interfaces available in the cluster. The SQL Server Setup can also get a list of interfaces from the Network Connections folder in the system but it doesn’t. Instead it queries cluster database or registry to get this information. The registry entry for Network Interfaces is located at the following location:
HKLM\Cluster\Networks
FIGURE 1.6: Cluster Network Interfaces list
After you select the Cluster Disk for SQL Databases, you will be presented with the list of nodes available in the cluster. SQL Server Cluster Setup allows you to configure the nodes to be cluster-aware for SQL Virtual Server Instance you create. The Setup doesn’t have this information. It always queries the cluster configuration database at the following registry location to find the available nodes in the cluster:
FIGURE 1.6: Cluster Network Interfaces list
After you select the Cluster Disk for SQL Databases, you will be presented with the list of nodes available in the cluster. SQL Server Cluster Setup allows you to configure the nodes to be cluster-aware for SQL Virtual Server Instance you create. The Setup doesn’t have this information. It always queries the cluster configuration database at the following registry location to find the available nodes in the cluster:
HKEY_LOCAL_MACHINE\CLUSTER\Nodes
FIGURE 1.7: SQL Server Setup wizard and SQL Nodes.
The Setup executes a query against the above registry key to retrieve a list of nodes in the cluster. The node name is retrieved from the NodeName registry entry as shown in the above figure.
After setup process has collected the above information it starts copying the SQL binary files on C:\ drive (this path can also be changed) and the SQL database files on the drive you selected during the setup.
Conclusion
In this article we saw the SQL Server Cluster Setup internal process. This article explained the mechanism SQL Cluster Setup DLL (SQLCluster.DLL) uses to find the list of nodes, disks and interfaces in the cluster. In the next article of this series we will see troubleshooting techniques, registry entries and files which are important in the failover process. We will also see how the SQL Cluster Setup process configures a node to be cluster-aware.
FIGURE 1.7: SQL Server Setup wizard and SQL Nodes.
The Setup executes a query against the above registry key to retrieve a list of nodes in the cluster. The node name is retrieved from the NodeName registry entry as shown in the above figure.
After setup process has collected the above information it starts copying the SQL binary files on C:\ drive (this path can also be changed) and the SQL database files on the drive you selected during the setup.
Conclusion
In this article we saw the SQL Server Cluster Setup internal process. This article explained the mechanism SQL Cluster Setup DLL (SQLCluster.DLL) uses to find the list of nodes, disks and interfaces in the cluster. In the next article of this series we will see troubleshooting techniques, registry entries and files which are important in the failover process. We will also see how the SQL Cluster Setup process configures a node to be cluster-aware.
No comments:
Post a Comment