ptg 654 CHAPTER 20 Database Mirroring Summary Database mirroring is one of the most significant SQL Server features to come along in a long time. This feature has provided a way for users to get to a minimum level of high availability for their databases and applications without having to use complex hard- ware and software configurations (as are needed with MSCS and SQL Server Clustering configurations). To mirror a database, you essentially ask for a complete copy of a database to be created and maintained up to the last committed transaction. The ease and simplicity of creating and monitoring database mirroring will quickly make it a configuration that many people use. Adding variations to this configuration, such as enhancing data replication or offload- ing reporting users, adds even more availability, resilience, and scalability possible than ever existed before. And, as you have seen, it is very easy to have your applications take advantage of database mirroring transparently. In addition, Microsoft has now improved on its overall performance and stability, coupled with three more years’ worth of produc- tion implementations by companies around the globe. Moving to SQL Server 2008 data- base mirroring is now more than a rock solid path. Chapter 21, “SQL Server Clustering,” delves into the complexities and significant benefits of building high-availability solutions by using SQL Server Clustering. Download from www.wowebook.com ptg CHAPTER 21 SQL Server Clustering IN THIS CHAPTER . What’s New in SQL Server Clustering . How Microsoft SQL Server Clustering Works . Installing SQL Server Clustering Enterprise computing requires that the entire set of tech- nologies you use to develop, deploy, and manage mission- critical business applications be highly reliable, scalable, and resilient. These technologies include the network, entire technology stack, operating systems on the servers, applications you deploy, database management systems, and everything in between. An enterprise must now be able to provide a complete solu- tion in regards to the following: . Scalability—As organizations grow, so does the need for more computing power. The systems in place must enable an organization to leverage existing hardware and to quickly and easily add computing power as needs demand. . Availability—As organizations rely more on informa- tion, it is critical that the information be available at all times and under all circumstances. Downtime is not acceptable. Moving to five-nines reliability (which means 99.999% uptime) is a must, not a dream. . Interoperability—As organizations grow and evolve, so do their information systems. It is impractical to think that an organization will not have many hetero- geneous sources of information. It is becoming increasingly important for applications to get to all the information, regardless of its location. . Reliability—An organization is only as good as its data and information. It is critical that the systems providing that information be bulletproof. Download from www.wowebook.com ptg 656 CHAPTER 21 SQL Server Clustering It is assumed that you will provide a certain level of foundational capabilities in regard to network, hardware, and operating system resilience. The good news is that you can achieve many of your enterprise’s demands easily and inexpensively by using Microsoft Cluster Services (MSCS), Network Load Balancing (NLB), and SQL Server Clustering (or combinations of them). What’s New in SQL Server Clustering Much of what’s new for MSCS and SQL Server Clustering has to do with the expanded number of nodes that can be managed together and several ease-of-use enhancements in MSCS, including the following: . Setup changes for SQL Server failover clustering—One option forces you to run the Setup program on each node of the failover cluster. To add a node to an existing SQL Server failover cluster, you must run SQL Server Setup on the node that is to be added to the SQL Server failover cluster instance. Another option creates an enter- prise push to nodes from the active node. . Cluster nodes residing on different subnets—With Windows 2008, cluster nodes can now reside on different network subnets across network routers. You no longer have to stretch virtual local area networks to connect geographically separated cluster nodes. This opens the door to clustered disaster recovery options. . Instances per cluster—SQL Server 2008 Enterprise Edition supports up to 25 SQL Server instances per cluster (up to 50 for a nonclustered server). . More cluster-aware applications—Many of the MS SQL Server 2008 products are cluster aware, such as Analysis Services, Full Text Search, Integration Services, Reporting Services, FILESTREAM, and others, making these applications more highly available and resilient. . Isolation of the quorum disk in MSCS—A shared disk partition that is not on the same physical drive/LUN as the quorum drive must be available in an attempt to reduce failure dependencies. . Number of nodes in a cluster—With Windows 2003 Enterprise Edition (or Datacenter), you can now create up to 8 nodes in a single cluster, and with Windows 2008 Enterprise Edition (or Datacenter), you can create up to 16 nodes. These new features and enhancements combine to make setting up SQL Server Clustering an easy high-availability proposition. They take much of the implementation risk out of the equation and make this type of installation available to a broader installation base. How Microsoft SQL Server Clustering Works Put simply, SQL Server 2008 allows failover and failback to or from another node in a cluster. This is an immensely powerful tool for achieving higher availability virtually trans- parently. There are two approaches to implementing SQL Server Clustering: active/passive or active/active modes. Download from www.wowebook.com ptg 657 How Microsoft SQL Server Clustering Works In an active/passive configuration, an instance of SQL Server actively services database requests from one of the nodes in a SQL Server cluster (that is, the active node). Another node is idle until, for whatever reason, a failover occurs (to the passive node). With a failover situation, the secondary node (the passive node) takes over all SQL Server resources (for example, databases and the Microsoft Distributed Transaction Coordinator [MSDTC]) without the end user ever knowing that a failover has occurred. The end user might experience a brief transactional interruption because SQL Server Failover Clustering cannot take over in-flight transactions. However, the end user still just looks at a single (virtual) SQL Server and truly doesn’t care which node is fulfilling requests. Figure 21.1 shows a typical two-node SQL Server Clustering configuration using active/passive mode, in which Node 2 is idle (that is, passive). 21 In an active/active configuration, SQL Server runs multiple servers simultaneously with different databases. This gives organizations with more constrained hardware requirements a chance to use a clustering configuration that can fail over to or from any node, without having to set aside idle hardware. As previously mentioned, SQL Server Clustering is actually created within (on top of) MSCS. MSCS, not SQL Server, is capable of detecting hardware or software failures and automatically shifting control of the managed resources to a healthy node. SQL Server 2008 implements failover clustering based on the clustering features of the Microsoft Clustering Service. In other words, SQL Server is a fully cluster-aware application and Basic Two–Node SQL Cluster Active/Passive Configuration MSCS Cluster Group Resources MSCS Windows 2003 EE Windows 2003 EE 2 Processors (Xeon) Memory/Cache 4 GB 2 Processors (Xeon) Memory/Cache 4 GB Network Public Networks Heartbeat Quorum Disk NODE 2 (Passive) NODE 1 (Active) MS DTC SCSI SCSI SCSI Local storage Local storage Shared Disk C: C: SQL Agent FIGURE 21.1 A typical two-node active/passive SQL Server Clustering configuration. Download from www.wowebook.com ptg 658 becomes a set of resources managed by MSCS. The failover cluster shares a common set of cluster resources (or cluster groups), such as clustered (that is, shared) disk drives. NOTE You can install SQL Ser v er on as many ser vers as you want; the number is limit ed onl y by the operating system license and SQL Server edition you have purchased. However, MSCS (for Windows 2008) can manage only up to 16 instances of Microsoft SQL Server Standard Edition at a time and up to 25 instances of Microsoft SQL Server Enterprise Edition at a time. Understanding MSCS A server cluster is a group of two or more physically separate servers running MSCS and working collectively as a single system. The server cluster, in turn, provides high availabil- ity, scalability, and manageability for resources and applications. In other words, a group of servers is physically connected via communication hardware (network), shares storage (via SCSI or Fibre Channel connectors), and uses MSCS software to tie them all together into managed resources. Server clusters can preserve client access to applications and resources during failures and planned outages. If one of the servers in a cluster is unavailable due to failure or mainte- nance, resources and applications move to another available cluster node. NOTE You cannot do clustering with Windows 2000 P rofessional or old er ser ver versions. Clustering is available only on servers running Windows 2000 Advanced Server (which supports two-node clusters), Windows 2000 Datacenter Server (which supports up to four-node clusters), Windows 2003 Enterprise Edition and Datacenter Server, and Windows 2008 Enterprise Edition and Datacenter Server. Clusters use an algorithm to detect a failure, and they use failover policies to determine how to handle the work from a failed server. These policies also specify how a server is to be restored to the cluster when it becomes available again. Although clustering doesn’t guarantee continuous operation, it does provide availability sufficient for most mission-critical applications and is the building block of numerous high-availability solutions. MSCS can monitor applications and resources, automatically recognizing and recovering from many failure conditions. This capability provides great flexibility in managing the workload within a cluster, and it improves the overall availabil- ity of the system. Technologies that are “cluster aware”—such as SQL Server, Microsoft Message Queuing (MSMQ), Microsoft Distributed Transaction Coordinator (MSDTC), and file shares—have already been programmed to work within (under the control of) MSCS. CHAPTER 21 SQL Server Clustering Download from www.wowebook.com ptg 659 How Microsoft SQL Server Clustering Works 21 TIP In previous versions of MSCS, the COMCLUST.EXE utility had to be run on each node to cluster the MSDTC. It is now possible to configure MSDTC as a resource type, assign it to a resource group, and then have it automatically configured on all cluster nodes. MSCS is relatively sensitive to the hardware and network equipment you put in place. For this reason, it is imperative that you verify your own hardware’s compatibility before you go any further in deploying MSCS (check the hardware compatibility list at http://msdn. microsoft.com/en-us/library/ms189910.aspx). In addition, SQL Server failover cluster instances are not supported where the cluster nodes are also domain controllers. Let’s look a little closer at a two-node active/passive cluster configuration. As you can see in Figure 21.2, the heartbeat (named ClusterInternal in this figure) is a private network set up between the nodes of the cluster that checks whether a server is up and running (“is alive”). This occurs at regular intervals, known as time slices. If the heartbeat is not functioning, a failover is initiated, and another node in the cluster takes over for the failed node. In addition to the heartbeat private network, at least one public network (named ClusterPublic in this figure) must be enabled so that external connections can be made to the cluster. Each physical server (node) uses separate network adapters for each type of communication (public and internal heartbeat). Active/Passive Configuration CLUSTER 1 (NODE 1) CLUSTER 2 (NODE 2) Windows 2003 EE Windows 2003 EE 2 Processors (Xeon) Memory/Cache 4 GB 2 Processors (Xeon) Memory/Cache 4 GB Network ClusterPublic ClusterInternal MSCS SCSI SCSI SCSI Local storage Local storage S: Shared Disk Q: Quorum Disk C: C: FIGURE 21.2 A two-node active/passive MSCS cluster configuration. Download from www.wowebook.com ptg 660 The shared disk array is a collection of physical disks (SCSI RAID or Fibre Channel–connected disks) that the cluster accesses and controls as resources. MSCS supports shared nothing disk arrays, in which only one node can own a given resource at any given moment. All other nodes are denied access until they own the resource. This protects the data from being overwritten when two computers have access to the same drives concurrently. The quorum drive is a logical drive designated on the shared disk array for MSCS. This continuously updated drive contains information about the state of the cluster. If this drive becomes corrupt or damaged, the cluster installation also becomes corrupt or damaged. NOTE In general (and as part of a high-availability disk configuration), the quorum drive should be isolated to a drive all by itself and be mirrored to guarantee that it is avail- able to the cluster at all times. Without it, the cluster doesn’t come up at all, and you cannot access your SQL databases. The MSCS architecture requires there to be a single quorum resource in the cluster that is used as the tie-breaker to avoid split-brain scenarios. A split-brain scenario happens when all the network communication links between two or more cluster nodes fail. In these cases, the cluster may be split into two or more partitions that cannot communicate with each other. MSCS guarantees that even in these cases, a resource is brought online on only one node. If the different partitions of the cluster each brought a given resource online, this would violate what a cluster guarantees and potentially cause data corruption. When the cluster is partitioned, the quorum resource is used as an arbiter. The partition that owns the quorum resource is allowed to continue. The other partitions of the cluster are said to have “lost quorum,” and MSCS and any resources hosted on nodes that are not part of the partition that has quorum are terminated. The quorum resource is a storage-class resource and, in addition to being the arbiter in a split-brain scenario, is used to store the definitive version of the cluster configuration. To ensure that the cluster always has an up-to-date copy of the latest configuration informa- tion, you should deploy the quorum resource on a highly available disk configuration (using mirroring, triple-mirroring, or RAID 10, at the very least). Starting with Windows 2003, a more durable approach of managing the quorum disks with clustering was created, called majority node set. It all but eliminates the single-point- of-failure weakness in the traditional quorum disk configuration that existed with Windows 2000 servers. However, even this approach isn’t always the best option for many clustered scenarios. The notion of quorum as a single shared disk resource means that the storage subsystem has to interact with the cluster infrastructure to provide the illusion of a single storage device with very strict semantics. Although the quorum disk itself can be made highly available via RAID or mirroring, the controller port may be a single point of failure. In addition, if an application inadvertently corrupts the quorum disk or an operator takes down the quorum disk, the cluster becomes unavailable. CHAPTER 21 SQL Server Clustering Download from www.wowebook.com ptg 661 How Microsoft SQL Server Clustering Works 21 This situation can be resolved by using a majority node set option as a single quorum resource from an MSCS perspective. In this set, the cluster log and configuration informa- tion are stored on multiple disks across the cluster. A new majority node set resource ensures that the cluster configuration data stored on the majority node set is kept consis- tent across the different disks. The disks that make up the majority node set could, in principle, be local disks physically attached to the nodes themselves or disks on a shared storage fabric (that is, a collection of centralized shared storage area network [SAN] devices connected over a switched-fabric or Fibre Channel–arbitrated loop SAN). In the majority node set implementation that is provided as part of MSCS in Windows Server 2003 and 2008, every node in the cluster uses a directory on its own local system disk to store the quorum data, as shown in Figure 21.3. If the configuration of the cluster changes, that change is reflected across the different disks. The change is considered to have been committed (that is, made persistent) only if that change is made to a majority of the nodes (that is, [Number of nodes configured in the cluster]/2) + 1). In this way, a majority of the nodes have an up-to-date copy of the data. MSCS itself starts up only if a majority of the nodes currently configured as part of the cluster are up and running as part of MSCS. If there are fewer nodes, the cluster is said not to have quorum, and therefore MSCS waits (trying to restart) until more nodes try to join. Only when a majority (or quorum) of nodes are available does MSCS start up and bring the resources online. This way, because the up-to-date configuration is written to a majority of the nodes, regardless of node fail- ures, the cluster always guarantees that it starts up with the most up-to-date configuration. With Windows 2008, a few more quorum drive configurations are possible that address various voting strategies and also support geographically separated cluster nodes. The “majority node set” resource uses the private network cluster connection between nodes to transfer data to the shares Majority Node Set - Quorum disk option Heartbeat (private network) quorum Node A quorum Node B quorum Node C quorum Node D FIGURE 21.3 A majority node set. Download from www.wowebook.com ptg 662 CHAPTER 21 SQL Server Clustering In Windows Server 2008 failover clustering, you have four choices on how to implement the quorum: . One option is to use Node majority; a vote is given to each node of the cluster, and the cluster continues to run as long as a majority of nodes are up and running. . A second option is to use both the nodes and the standard quorum disk, a common option for two-node clusters. Each node gets a vote, and the quorum, now called a witness disk, also gets a vote. As long as two of the three are running, the cluster continues. The cluster can actually lose the witness disk and still run. . A third option is to use the classic/legacy model and assign a vote to the witness disk only. This type of quorum equates to the well-known, tried-and-true model that has been used for years. . A fourth option is, of course, to use the majority node set (MNS) model with a file share witness. We describe only the standard majority node set approach here. TIP A quick check to see whether your hardware (server, controllers, and storage devices) is listed on Microsoft’s Hardware Compatibility List will save you headaches later. See the hardware pre-installation checklist at http://msdn.microsoft.com/en-us/library/ ms189910.aspx. Extending MSCS with NLB You can also use a critical technology called Network Load Balancing (NLB) to ensure that a server is always available to handle requests. NLB works by spreading incoming client requests among a number of servers linked together to support a particular application. A typical example is to use NLB to process incoming visitors to your website. As more visi- tors come to your site, you can incrementally increase capacity by adding servers. This type of expansion is often referred to as software scaling, or scaling out. Figure 21.4 illus- trates this extended clustering architecture with NLB. By using both MSCS and NLB clustering technologies together, you can create an n-tier infrastructure. For instance, you can create an n-tiered e-commerce application by deploy- ing NLB across a front-end web server farm and use MSCS clustering on the back end for your line-of-business applications, such as clustering your SQL Server databases. This approach gives you the benefits of near-linear scalability without server- or application- based single points of failure. This, combined with industry-standard best practices for designing high-availability networking infrastructures, can ensure that your Windows- based, Internet-enabled business will be online all the time and can quickly scale to meet Download from www.wowebook.com ptg 663 How Microsoft SQL Server Clustering Works 21 MSCS with Network Load Balancing Network Load Balancing Servers (NLB) MSCS Cluster n Clients • • • 2 1 FIGURE 21.4 An NLB configuration. demand. Other tiers could be added to the topology, such as an application-center tier that uses component load balancing. This further extends the clustering and scalability reach for candidate applications that can benefit from this type of architecture. How MSCS Sets the Stage for SQL Server Clustering Figure 21.5 shows an Excel spreadsheet that documents all the needed Internet Protocol (IP) addresses, network names, domain definitions, and SQL Server references to set up a two-node SQL Server Clustering configuration (configured in an active/passive mode). CLUSTER1 is the first node, CLUSTER2 is the second node, and the cluster group name is CLUSTER >GROUP (simple naming is used here to better illustrate the point). The public network name is ClusterPublic, and the internal heartbeat network name is ClusterInternal. This spreadsheet has also been included in the download files on the CD for this book. It’s a good idea to fill out this spreadsheet before you start installing and configuring your servers. Download from www.wowebook.com . solutions by using SQL Server Clustering. Download from www.wowebook.com ptg CHAPTER 21 SQL Server Clustering IN THIS CHAPTER . What’s New in SQL Server Clustering . How Microsoft SQL Server Clustering. cluster SQL Server 2008 Enterprise Edition supports up to 25 SQL Server instances per cluster (up to 50 for a nonclustered server) . . More cluster-aware applications—Many of the MS SQL Server 2008. up to 16 instances of Microsoft SQL Server Standard Edition at a time and up to 25 instances of Microsoft SQL Server Enterprise Edition at a time. Understanding MSCS A server cluster is a group