ptg 664 CHAPTER 21 SQL Server Clustering FIGURE 21.5 An Excel spreadsheet for a two-node active/passive SQL Cluster configuration. The cluster controls the following resources: . Physical disks (Q: is for the quorum disk, S: is for the shared disks, and so on.) . The cluster IP address . The cluster name (network name) . The Distributed Transaction Coordinator (MSDTC) . The SQL Server virtual IP address . The SQL Server virtual name (network name) . SQL Server . SQL Server Agent . The SQL Server Full-Text Search service instance (if installed) After you successfully install, configure, and test your cluster (MSCS), you are ready to add the SQL Server components as resources to be managed by MSCS. This is where the magic Download from www.wowebook.com ptg 665 Installing SQL Server Clustering 21 happens. Figure 21.6 shows how the Cluster Administrator should look after you install/configure MSCS. It doesn’t have SQL Server 2008 installed yet. Installing SQL Server Clustering When you install SQL Server in a clustered server configuration, you create it as a virtual SQL Server. A virtual SQL Server is not tied to a specific physical server; it is associated with a virtualized SQL Server name that is assigned a separate IP address (not the IP address or name of the physical servers on which it runs). Handling matters this way allows for your applications to be completely abstracted away from the physical server level. Failover clustering has a new workflow for all Setup scenarios in SQL Server 2008. The two options for installation are . Integrated installation—This option creates and configures a single-node SQL Server failover cluster instance. Additional nodes are added by using the Add Node functionality in Setup. For example, for Integrated installation, you run Setup to create a single-node failover cluster. Then you run Setup again for each node you want to add to the cluster. . Advanced/Enterprise installation—This option consists of two steps; the prepare step prepares all nodes of the failover cluster to be operational. Nodes are defined and prepared during this initial step. After you prepare the nodes, the Complete step is run on the active node—the node that owns the shared disk—to complete the failover cluster instance and make it operational. Figure 21.7 shows the same two-node cluster configuration as Figure 21.1, with all the SQL Server components identified. This virtual SQL Server is the only thing the end user will ever see. As you can also see in Figure 21.7, the virtual server name is VSQLSERVER2008, and the SQL Server instance name defaults to blank (you can, of course, give your instance a name). Figure 21.7 also shows the other cluster group resources that will be part of the SQL Server Clustering configuration: MSDTC, SQL Agent, SQL Server Full-Text Search, and the shared disk where the databases will live. FIGURE 21.6 Windows 2003 Cluster Administrator, showing managed resources prior to installing SQL Server. Download from www.wowebook.com ptg 666 CHAPTER 21 SQL Server Clustering SQL Connections SQL Clustering basic configuration CLUSTER 1 CLUSTER GROUP Resources CLUSTER 2 Windows 2003 EE SQL Server 2008 (physical) Windows 2003 EE MS DTC SQL Agent SQL Full Text Search Q: Quorum Disk SQL Server 2008 (physical) SQL Server 2008 (Virtual SQL Server) ClusterPublic ClusterInternal Local Binaries Local Binaries C: C: Master DB TempDB Appl 1 DB VSQLSERVER2008 SSShhhaaarrreeeddd Shared FIGURE 21.7 A basic SQL Server Clustering configuration. SQL Server Agent will be installed as part of the SQL Server installation process, and it is associated with the SQL Server instance it is installed for. The same is true for SQL Server Full-Text Search; it is associated with the particular SQL Server instance that it is installed to work with. The SQL Server installation process completely installs all software on all nodes you designate. Configuring SQL Server Database Disks Before we go too much further, we need to talk about how you should lay out a SQL Server implementation on the shared disks managed by the cluster. The overall usage intent of a particular SQL Server instance dictates how you might choose to configure your shared disk and how it might be best configured for scalability and availability. In general, RAID 0 is great for storage that doesn’t need fault tolerance; RAID 1 or RAID 10 is great for storage that needs fault tolerance but doesn’t have to sacrifice too much perfor- mance (as with most online transaction processing [OLTP] systems); and RAID 5 is great for storage that needs fault tolerance but whose data doesn’t change that much (that is, low data volatility, as in many decision support systems [DSSs]/read-only systems). All this means that there is a time and place to use each of the different fault-tolerant disk configurations. Table 21.1 provides a good rule of thumb to follow for deciding which SQL Server database file types should be placed on which RAID level disk configuration. (This would be true regardless of whether or not the RAID disk array was a part of a SQL Server cluster.) Download from www.wowebook.com ptg 667 Installing SQL Server Clustering 21 TIP A good practice is to balance database files across disk arrays (that is, controllers). In other words, if you have two (or more) separate shared disk arrays (both RAID 10) avail- able within a cluster group’s resources, you should put the data file of Database 1 on the first cluster group disk resource (for example, DiskRAID10-A) and its transaction log on the second cluster group disk resource (for example, DiskRaid10-B). Then you should put the data file of Database 2 on the second cluster group disk resource of DiskRAID10-B and its transaction log on the first cluster group disk resource of DiskRAID10-A. In this way, you can stagger these allocations and in general balance the overall RAID controller usage, minimizing any potential bottlenecks that might occur on one disk controller. In addition, FILESTREAM filegroups must be put on a shared disk, and FILESTREAM must be enabled on each node in the cluster that will host the FILESTREAM instance. You can also use geographically dispersed cluster nodes, but additional items such as network latency and shared disk support must be verified before you get started. Check the Geographic Cluster hardware Compatibility List (http://msdn.microsoft.com/en-us/library/ms189910.aspx). On Windows 2008, most hardware and ISCSI supported hardware can be used, without the need to use “certi- fied hardware.” When you are creating a cluster on Windows 2008, you can use the cluster validation tool to validate the Windows cluster; it also blocks SQL Server Setup when problems are detected with the Windows 2008 cluster. TABLE 21.1 SQL Server Clustering Disk Fault-Tolerance Recommendations Device Description Fault Tolerance Quorum drive The quorum drive used with MSCS should be isolated to a drive by itself (often mirrored as well, for maximum availability). RAID 1 or RAID 10 OLTP SQL Server database files For OLTP systems, the database data/index files should be placed on a RAID 10 disk system. RAID 10 DSS SQL Server database files For DSSs that are primarily read-only, the database data/index files should be placed on a RAID 5 disk system. RAID 5 tempdb This is a highly volatile form of disk I/O (when not able to do all its work in the cache). RAID 10 SQL Server transaction log files The SQL Server transaction log files should be on their own mirrored volume for both performance and database protection. (For DSSs, this could be RAID 5 also.) RAID 10 or RAID 1 Download from www.wowebook.com ptg 668 CHAPTER 21 SQL Server Clustering Installing Network Interfaces You might want to take a final glance at Cluster Administrator so that you can verify that both CLUSTER1 and CLUSTER2 nodes and their private and public network interfaces are completely specified and their state (status) is up. If you like, you should also double- check the IP addresses and network names against the Excel spreadsheet created for this cluster specification. Installing MSCS As you can see in Figure 21.8, the MSCS “service” is running and has been started by the ClusterAdmin login account for the GOTHAM domain. NOTE If MSCS is not started and won’t start, you cannot install SQL Server Clustering. You have to remove and then reinstall MSCS from scratch. You should browse the Event Viewer to familiarize yourself with the types of warnings and errors that can appear with MSCS. Installing SQL Server For SQL Clustering, you must install a new SQL Server instance within a minimum two- node cluster. You should not move a SQL Server instance from a nonclustered configura- tion to a clustered configuration. If you already have SQL Server installed in a nonclustered environment, you need to make all the necessary backups (or detach data- bases) first, and then you need to uninstall the nonclustered SQL Server instance. Some FIGURE 21.8 You n eed to make su re M SCS is r unning an d st ar ted by the cluster account for the domain. Download from www.wowebook.com ptg 669 Installing SQL Server Clustering 21 upgrade paths and migration paths are possible from prior versions of SQL Server and Windows server. You are also limited to a maximum of 25 instances of SQL Server per failover cluster. There is no uninstall SQL Server failover cluster option; you must run Setup from the node that is to be removed. You must specify the same product key on all the nodes that you are preparing for the same failover cluster. You also should make sure you use the same SQL Server instance ID for all the nodes that are prepared for the failover cluster. With all MSCS resources running and in the online state, you run the SQL Server Setup program from the node that is online (for example, CLUSTER1). You are asked to install all software components required prior to installing SQL Server (.NET Framework 3.0 or 3.5, Microsoft SQL Native Client, and the Microsoft SQL Server 2008 Setup support files). SQL Server integrated failover cluster installation consists of the following steps: 1. Create and configure a single-node SQL Server failover cluster instance. When you configure the node successfully, you have a fully functional failover cluster instance. At this point, it does not have high availability because there is only one node in the failover cluster. 2. On each node to be added to the SQL Server failover cluster, run Setup with Add Node functionality to add that node. Alternatively, you can use the following SQL Server Advanced/Enterprise failover cluster installation: 1. On each node that will be an owner of the new SQL Server failover cluster, follow the Prepare Failover Cluster setup steps listed in the Prepare section. After you run the Prepare Failover Cluster on one node, Setup creates the Configuration.ini file, which lists all the settings you specified. On the additional nodes to be prepared, instead of following these steps, you can supply the Configuration.ini file from first node as an input to the Setup command line. This step prepares the nodes ready to be clustered, but there is no operational instance of SQL Server at the end of this step. 2. After the nodes are prepared for clustering, run Setup on one of the prepared nodes, preferably on the node that owns the shared disk that has the Complete Failover Cluster functionality. This step configures and finishes the failover cluster instance. After completing this step, you have an operational SQL Server failover cluster instance. and all the nodes prepared previously for that instance are the possible owners of the newly created SQL Server failover cluster. After you take these steps, the standard Welcome to SQL Server Installation Center Wizard begins. It starts with a System Configuration check of the node in the cluster (CLUSTER1). Figure 21.9 shows the SQL Server Installation Center launch dialog and the results of a successful system check for CLUSTER1. Download from www.wowebook.com ptg 670 CHAPTER 21 SQL Server Clustering NOTE SQL Server Clustering is available with SQL Server 2008 Standard Edition, Enterprise Edition, and Developer Edition. However, Standard Edition supports only a two-node cluster. If you want to configure a cluster with more than two nodes, you need to upgrade to SQL Server 2008 Enterprise Edition. If this check fails (warnings are acceptable), you must resolve them before you continue. If the check is successful, you are then prompted for the checklist of features you want to install. Figure 21.10 shows the Feature Selection to install dialog. You then see the Instance Configuration dialog, as shown in Figure 21.11, where you specify the network name for the new SQL Server failover cluster (the Virtual Server name, VSQLSERVER2008 in this example) and then either can use the default SQL Server instance name (no name) or specify a unique SQL Server instance name (we chose to use the default instance name of MSSQLSERVER). This virtual SQL Server name is the name the client applications will see (and to which they will connect). When an application attempts to connect to an instance of SQL Server 2008 that is running on a failover cluster, the application must specify both the virtual server name and instance name (if an instance name was used), such as VSQLSERVER2008\VSQLSRV1 (virtual server name\SQL Server instance name) or VSQLSERVER2008 (just the virtual server name without the default SQL Server instance FIGURE 21.9 A Microsoft SQL Server Setup Support Rules check. Download from www.wowebook.com ptg 671 Installing SQL Server Clustering 21 FIGURE 21.10 The SQL Server Setup Feature Selection dialog for a SQL Server Failover Cluster. FIGURE 21.11 Specifying the virtual server name (VSQLSERVER2008) and default instance. Download from www.wowebook.com ptg 672 CHAPTER 21 SQL Server Clustering name). The virtual server name must be unique on the network. You also specify the local directory locations (root) for the installation. NOTE A good naming convention to follow is to preface all virtual SQL Server names and vir- tual SQL Server instance names with a V. This way, you can easily identify which SQL Server machines on your network are clustered. For example, you could use VSQLSERVER2008 as a virtual SQL Server name and VSQLSRV1 as an instance name. Next comes the disk space requirements dialog, followed by the Cluster Resource Group specification. This is where the SQL Server resources are placed within MSCS. Here, you use the existing resource cluster group (named Cluster Group). Immediately following the resource group assignment comes the identification of which clustered disks are to be used via the Cluster Disk Selection dialog, shown in Figure 21.12. It contains an S: drive (which you want SQL Server to use) and Q: and R: drive being used for the quorum files (do not select this drive!). You simply select the available drive(s) where you want to put your SQL database files (the S: drive in this example). As you can also see, the only “quali- fied” disk is the S: drive. If the quorum resource is in the cluster group you have selected, a warning message is issued, informing you of this fact. A general rule of thumb is to isolate the quorum resource to a separate cluster group. FIGURE 21.12 Cluster resource group specification and Cluster Disk Selection. Download from www.wowebook.com ptg 673 Installing SQL Server Clustering 21 The next thing you need to do for this new virtual server specification is to identify an IP address and which network it should use. As you can see in the Cluster Network Configuration dialog, shown in Figure 21.13, you simply type in the IP address (for example, 192.168.3.110) that is to be the IP address for this virtual SQL Server for the available networks known to this cluster configuration (in this example, it is for the ClusterPublic network). If the IP address being specified is already in use, an error occurs. NOTE Keep in mind that you are using a separate IP address for the virtual SQL Server that is completely different from the cluster IP addresses. In a nonclustered installation of SQL Server, the server can be referenced using the machine’s IP address. In a clus- tered configuration, you do not use the IP addresses of the servers themselves; instead, you use this separately assigned IP address for the “virtual” SQL Server. Figure 21.14 shows the next step in identifying the Cluster Security Policy for each SQL Server component (Database Engine, SQL Server Agent, and Analysis Services). Here, you use the domain Admin group. Figure 21.14 also shows the Server Configuration “service accounts” to use for all the services within this SQL Server install. You use a ClusterAdmin account set up for this purpose. Remember, this account must have administrator rights within the domain and on each server (that is, it must be a member of the Administrators local group on any node in the cluster). This is followed by the Database Engine Configuration dialog, where you set what type of authentication mode to use, the data FIGURE 21.13 Specifying the virtual SQL Server IP address and which network to use. Download from www.wowebook.com . 2 Windows 2003 EE SQL Server 2008 (physical) Windows 2003 EE MS DTC SQL Agent SQL Full Text Search Q: Quorum Disk SQL Server 2008 (physical) SQL Server 2008 (Virtual SQL Server) ClusterPublic ClusterInternal Local. VSQLSERVER2008VSQLSRV1 (virtual server name SQL Server instance name) or VSQLSERVER2008 (just the virtual server name without the default SQL Server instance FIGURE 21.9 A Microsoft SQL Server Setup Support. have SQL Server 2008 installed yet. Installing SQL Server Clustering When you install SQL Server in a clustered server configuration, you create it as a virtual SQL Server. A virtual SQL Server