222 Chapter6•ManagingHighAvailability It is recommended that the domain accounts that will be running the services are put into the domain groups before you run the SQL Server installer. Even though the SQL Installer allows you to select the NT AUTHORITY\ NETWORK SERVICE and NT AUTHORITY\SYSTEM accounts to run the services under, the only service that can actually run under these accounts is the SQL Server Browser. All clustered services must run under a domain account. On the next page you select your authentication mode, set your sa password, and specify yourself as a member of the fixed server role. The Data Directories tab is the same for a clustered install with the exception that the Data Root Drive and all the other folders listed will be based on the first drive letter selected on the Cluster Disk Selection screen. Although the UI will allow you to select from any drive on the system, you will get a validation warning if you attempt to continue past this screen using any drive letters for any fields that are not selected on the Cluster Disk Configuration. If you enable use of the FILESTREAM you will notice that the Allow Remote Clients To Have Streaming Access To FILESTEAM Data check box is checked and grayed out. It is disabled because having this access is a requirement of using the FILESTREAM in a clustered environment. In order to use the FILESTREAM in a clustered environment on a Windows 2003 Cluster you must install hotfix KB937444 from the Microsoft Knowledge Base. This is not a public hotfix so you will need to open a ticket with Microsoft CSS in order to get the hotfix. This hotfix must be installed before the SQL 2008 installer is run because the hotfix requires a reboot. The need for this hotfix is detected only on the Cluster Installation Rules page and not at the beginning of the process. The final difference you will see when installing SQL Server 2008 in a clustered environment is that the Installation Rules page is called Cluster Installation Rules. This will check various requirements against the system to ensure that you meet all the required items. At this point in the installer the process is the same as the stand-alone installer. After you have completed the installer on the first node of the cluster you must then complete the installation on the other nodes of the cluster. Launch the installer from the SQL Server 2008 DVD and return to the screen shown in Figure 6.10. Then select the Add node to a SQL Server failover cluster option on the menu selecting the correct instance you wish to install the second node for (if there are multiple instances installed on the primary node). This will install the binaries and registry settings on the other node. This action should be taken on all the other nodes of the cluster. Unlike SQL Server 2005 and prior, SQL Server 2008 no longer pushes the installers to each node in the cluster. Along these same lines the hotfixes and service packs will also need to be manually installed on each server of the cluster. When ManagingHighAvailability•Chapter6 223 patching this gives the advantage of being able to perform what is called a rolling upgrade. This allows you to patch the cluster with only two to three minutes of downtime as each instance is patched separately. The recommended method for installing patches on a SQL Server 2008 cluster is to patch your active node, test the patch giving you the option of failing over to an un-patched node if there is an issue. Once you are sure that the active node is working as you expect it to, you can continue to patch the other nodes in the cluster. This new technique gives you the obvious advantage of being able to test the hot fixes and service packs on one node before deploying them to all the nodes in the cluster. The downside to this technique is that much more work is required when patching a large multinode cluster. Special Hardware Requirements Using the Microsoft Cluster Service is a very high-end solution. It requires some fairly specialized equipment, which has a very high buy-in price because of the costs involved in setting up the shared storage solution. There are some less expensive solutions available but they are far less flexible in the number of servers that can be attached to them, and the number of machines that you can put in each cluster. The operating system you select also has a large impact on the number of nodes that you can set up in each cluster. If you use a SCSI storage solution for Windows 2003, you can configure only a two-node cluster. Windows 2008 no longer supports clustering using SCSI disks. If you are using a local fiber channel storage solution or SAN solution, Table 6.1 will show you the maximum number of nodes supported in a Windows Cluster. Operating System Maximum Number of Nodes Windows 2003 Enterprise Edition 4 nodes Windows 2003 Data center Edition 8 nodes Windows 2008 Itanium 8 nodes Windows 2008 ×86 / ×64 16 nodes Table 6.1 Nodes Supported in a Windows Cluster Special Software Requirements Not all Editions of SQL Server can be clustered using the Microsoft Cluster Service. Until SQL Server 2005 only the Enterprise Edition of SQL Server supported 224 Chapter6•ManagingHighAvailability clustering. Starting with SQL Server 2005 clustering was available under the Standard Edition. The ability to cluster SQL Server using the Standard Edition has been extended into SQL Server 2008 as well. This greatly reduces your software licensing costs while still giving you the option to cluster your SQL Server. If you wish to increase your Standard Edition cluster to a three-node cluster or higher, then you will need to upgrade the software version to the Enterprise Edition of SQL Server before you can increase the size of the cluster. Beyond the two-node limit of SQL Server standard edition, most of your design choices when designing your cluster will be dictated by the version of the operating system you select. When configuring your Windows 2003 cluster, you must use static IP addresses, which are all on the same subnet. When configuring a cluster under Windows 2008, you may use a DHCP address. While Windows 2008 clusters support having the nodes of different subnets, the SQL Server 2008 installer does not have room for a second set of IP addresses, so it is recommended to use a single subnet for your cluster. EXERCISE 6.4 SE t Up SQL SE R v E R In a CL U S t E R If you have access to a SAN, VMware, or Hyper-V, set up two Windows 2003 Enterprise or Windows 2008 Enterprise servers and cluster them. Install SQL Server in a clustered configuration. If you are using VMware and Windows 2003 guest OSes to host your Windows Cluster, there is an excellent walkthrough that will help you set up the shared server stored in the virtual environment without needing access to a SAN. This site assumes that you have ESX server available, but this technique should work with VMware Server, which is a free download at http://exchangeexchange.com/blogs/bkeane/ archive/2007/07/30/mscs-clustering-invmware.aspx. If you are using Windows 2008 guest OSes to host your Windows cluster, you will need to present iSCSI LUNs to your guests OSes. You can either present LUNs to your guest OSes through a physical iSCSI solution of by using a software iSCSI target such as Starwind iSCSI target by RocketDivision. When you are installing SQL Server in a clustered environment, special attention must be paid to the SQL Server Integration Service (SSIS). If you wish to use SSIS on your cluster you will need to manually install SSIS on each node of the cluster. ManagingHighAvailability•Chapter6 225 After you install SSIS on each node of the cluster you will need to edit the config- uration file for SSIS to tell it where the MSDB database is. By default SSIS looks for the default local instance for the location of the MSDB database to which it wants to connect. Because the location of the SQL Instance is a different name, or possibly has an instance name, you will need to edit the MsDtsSrvr.ini.xml file. By default it is found in the C:\Program Files\Microsoft SQL Server\100\DTS\Binn folder. Open the file in your favorite XML editor (NOTEPAD will do fine) and find the branch with the xsi:type = “SqlServerFolder” and change the ServerName child from “.” to your virtual host name that you configured during the SQL Server Installation. The relevant portion of the XML file is shown here. <Folder xsi:type="SqlServerFolder"> <Name>MSDB</Name> <ServerName>.</ServerName> </Folder> TE s T Da y Tip Be familiar with the name of this configuration file. The editing of this file was left out of the SQL Server 2005 exams, but there are questions about it in the SQL Server 2008 exams. Manually moving an instance of SQL Server from one node of a cluster to another is a very simple procedure. Simply open the Cluster Administrator and connect to the cluster. Right-click on the Resource Group or any resource within the group and select the Move option. This will Move all the resources within the Resource Group to another node in the cluster. (Do not do this on a production cluster as there is a short outage while the service is started on the remote machine.) If you will be using MSDTC in a clustered environment some changes should be made to the MSDTC configuration within the Component Services applet in the Administrative Tools menu. Navigate to My Computer and right-click on it and select Properties. Select the MSDTC tab, and click the Security Options button. In order for MSDTC to work correctly in a clustered environment be sure to select the No Authentication Required option. Each server that will be perform- ing a distributed transaction must be set in this way. This will not allow users to connect to the database without providing authentication credentials, it simply 226 Chapter6•ManagingHighAvailability allows a machine to begin a distributed transaction with the coordinator without authenticating against the machine. This is a requirement of a cluster only. If you will be using MSDTC on a server, through a firewall you will need to specify the number of TCP ports that RPC can use by following MSKB 250367 (http://support.microsoft.com/kb/250367). In a clustered environment when following this MSKB article you will need to increase the number of TCP ports available to RPC. This setting not only sets the number of ports that MSDTC used to talk through the firewall, but it restricts all RPC communication to the server to these ports. The MSDTC monitoring page of the Component Services uses RPC to query the MSDTC services, and the Cluster Administrator also uses RPC to manage the cluster, as does the SQL Server Instance when communicating with the MSDTC service. It is recommended that in a clustered environment you increase this number to at least 100 (from the 20 shown in the MSKB article) if not higher. When considering clustering for your high-availability solution, you need to license only the nodes of the cluster that are actively running SQL Server. If you have a two-node cluster and are running a single instance then you need to purchase licenses for only a single node (whichever one has more CPUs if the number of CPUs is different between the nodes). If you have a four-node cluster with three instances and each instance is running on a separate node then you would need licenses for three of the nodes. You do not need to license the passive node because it is considered a cold standby, because the services are not actively running on the machine at the time. When the cluster fails over, since it is a single instance that is failing over, Microsoft considers the license to transfer to the now active machine from the formally active machine. Geo-Clustering Geo-Clustering is a special setup of Windows Clustering where you are spreading the nodes of your Windows cluster between two different data centers usually in two different cities. Setting up a geographically dispersed cluster requires extremely expensive storage solutions to configure. This is because your storage solution must be able to automatically replicate the data from the storage solution at the local site to the storage solution at the remote site. This data transfer not only needs to be done, but it must be done in an asynchronous manner in order to keep both sites completely up to date. Under Windows 2003 and prior, setting up a geographically dispersed cluster was even more complex. This is because each node of the cluster had to be on the same IP address subnet. This creates a problem in most facilities because typically each data center will have a different IP address subnet assigned to them. The technique . of the cluster you must then complete the installation on the other nodes of the cluster. Launch the installer from the SQL Server 2008 DVD and return to the screen shown in Figure 6.10. Then. install the binaries and registry settings on the other node. This action should be taken on all the other nodes of the cluster. Unlike SQL Server 2005 and prior, SQL Server 2008 no longer pushes the. familiar with the name of this configuration file. The editing of this file was left out of the SQL Server 2005 exams, but there are questions about it in the SQL Server 2008 exams. Manually