Managing High Availability • Chapter 6 227 of setting up the same IP address subnet in two different data centers is extremely complex. With Windows 2008 you now have the option to set up a cluster using different IP address subnets for each site. This makes the process much easier to set up. Configuring & Implementing… Combining Solutions In the real world setting up a geographically dispersed cluster is extremely difficult even with the advancements that have been made the clustering software in Windows Server 2008. You may in fact find it easier to combine two of these solutions instead. If you needed to replicate data from a west coast data center to an east coast data center, but still maintain a high-availability solution at your primary West Coast data center, one configuration you may choose is a cluster on the WEST COAST, then use database mirroring to replicate your data from the WEST COAST to the EAST COAST. This would allow you to satisfy the requirements of having a local high-availability solution on the west coast (your Windows cluster); and still giving you the option of replicating your data to the east coast using database mirroring. In this case you would probably want to use database mirroring in the high performance mode so that your front end application is not slowed down by the WAN link latency between the two sites. When deciding on how to replicate data between sites over a WAN, keep in mind that no matter the solution you use data takes approximately three microseconds for every kilometer of fiber cable. A 100 kilometer distance will have a round trip time of approximately 600 microseconds (0.6 milliseconds). Going from a data center in New York to a data center in Los Angeles and back will take approximately 26 milliseconds. This is in addition to any latency that is added by firewalls, encryption devices, and the time it takes the storage to actually write the data to the hard drive. To us 26 extra milliseconds is not much, but to the SQL server this amount of time is a very long wait, which will be shown within the local SQL server as blocking while you wait for the data to be transmitted and the acknowledgment to be returned. 228 Chapter6•ManagingHighAvailability When you set up a geographically dispersed cluster you do not use a quorum drive. This is because you can’t replicate the quorum drive from site to site and have the cluster work correctly. Instead you use what is called a Majority Node Set. When you use a Majority Node Set whenever a node fails or the cluster is told to fail over a service, all the nodes take a vote as to which node should start the service. The node that wins then starts the service. A majority node set requires an odd number of servers so that there cannot be a tie—for example if you have three nodes at your primary site and two nodes at your backup site as shown in Figure 6.17. Figure 6.17 A Majority Node Set In the event that your primary site fails and the two servers on the right cannot connect to the three servers on the left they will take a vote between themselves and decide if the remote servers are offline. Once they decide that the three servers at the primary site are offline they will take control of the clustered resources and begin starting the clustered resources such as the SQL Server Service and the SQL Server Agent Service. Once the primary site comes back online, the storage arrays at each site will begin replicating back the changes that have been made. Once this process is completed the cluster will be ready to move the services back to the original site. ManagingHighAvailability•Chapter6 229 If you have automatic failback enabled then the cluster will take a vote as to which servers should control everything. The site with three nodes will win the vote and the services will be automatically moved back. If you do not have automatic failback enabled then you will need to manually trigger the failback when it is most convenient to do so. Troubleshooting a clustered installation of SQL Server can be a bit trickier than troubleshooting a stand-alone SQL Server installation. This is because of the clustered component. In the event that SQL Server is not starting, check the ERRORLOG file for information. This will tell you if the SQL Server service is starting or not. If the SQL Service is not starting check the application log and system log for errors about the cluster. If the ERRORLOG file shows that the SQL Server is starting and stopping then your issue is probably not going to be related to the cluster. If you recently have changed the resource dependencies of the cluster and the SQL Server will no longer start, make sure that the SQL Server is dependent on all the correct hard drives and on the network name. If the SQL Service is not dependent on the hard drives the SQL Server will not start. Changing the IP Address of a clustered SQL Server is not as easy as simply changing the IP Address of the SQL Server IP address resource in the cluster administrator. You will also need to search the registry and change any references from the old IP address to the new IP address, or the SQL Server will start, but not listen correctly. If you have multiple instances of SQL Server installed in a clustered environment make sure that the instances are configured to listen on their own IP address only or that each instance uses a different TCP port number. If you do not, the SQL Service will attempt to listen on all the IP addresses on the node of the cluster on which it is being hosted. If all SQL Services have the same port number, only the first SQL Server to start will actually be able to listen on that port since only a single Windows Service can use any one port number. If you use the default of dynamic port numbers for the named instances this will not be a problem because the SQL Server will pick a port number at random of the ports that are not in use. If you are using the SQL Server Maintenance plans to back up the database, and you are backing up the database to a disk that is a clustered resource, but is in a different Resource Group than the SQL Server, be sure to create a network share via the cluster administrator and back up the database over the network to that net- work share. If you do not, and the Resource Group that holds the hard drive you are backing up to is hosted by a different node of the cluster than your SQL Server Resource Group, the backups will fail as the hard drive cannot be accessed locally. 230 Chapter6•ManagingHighAvailability In the example cluster shown earlier, you would want to host the hard drive in the SQL01 Resource Group where the SQL Server is hosted in the SQL01V01 Resource Group. You would then want to create a network share \\SQL01\ SQLBackups that points to a folder on that new hard drive. You would then set up the backups to point to the network share instead of a local drive. Replication Replication is another technique that can be used for high availability. By replicating the data from one system to another you can easily redirect your clients to the secondary system in the event that your primary system fails. Since you are going to want the changes that are made to the backup system replicated back to the primary system after it is brought back online, you will want to use merge replication so that the subscriber can replicate its changes back to the publisher. Refer to Chapter 9 for information on setting up SQL Server Replication. When using Merge replication, failover and failback are relatively easy. Simply redirect your clients to connect to the subscriber. Once the publisher is back online and in sync you can configure your clients to connect back to the publisher. If you are using transaction replication then you will need to set up your subscriber as a publisher, and publish the data back to your original publisher. After the two servers are in sync, stop all client connections and remove the replication. Point all your clients to the publisher and configure that server to publish its data back to the subscriber. Replication typically does not make a good high-availability solution because new objects are not replicated to the subscriber automatically. It is also difficult to make schema changes since replication limits what can be done to the table schemas. It also requires that you manually deploy procedures, views, functions, and such to the subscribers whenever they are updated. The upside to using SQL Server Replication for your high-availability solution is that is you are using merge replication and your database is designed without having the requirement of unique columns that are not part of your primary key. You can use your high-availability solution to spread the load of your database between multiple SQL Servers. If your database has a table that requires uniqueness as shown in the following example then it is not a good candidate for running both machines actively because you could create a record in one server, then create a second record with the same value for the unique column on the other server before the data is able to replicate. Even with a unique index or constraint on this column, uniqueness cannot be guaranteed since the unique index or constraint can be enforced only after the data ManagingHighAvailability•Chapter6 231 has been replicated to the other server. If you have a unique index on the UserName column then your replication will fail because it cannot successfully add the row to the other server. CREATE TABLE Authentication (UserId INT PRIMARY KEY IDENTITY(1,1), UserName NVARCHAR(50) /*This column must be unique*/, Password NVARCHAR(100), Active BIT) Troubleshooting replication when used for a high-availability solution will be the same as when using normal SQL Server replication. This is discussed in Chapter 9. When using SQL Server Replication for your high-availability solution like log shipping and database mirroring you will need to license each machine to which the database is being replicated. Recovery Model Depending on Which high-availability model you select will determine which recovery models are available to you for your database. Database mirroring, clustering, and replication will support any of the available database recovery models. When using log shipping you should use the full recovery model. This is because you have to keep the transaction log available and every transaction needs to be logged so that it can be backed up and shipped to the backup server. All recovery models log most or all transactions to the transaction log. The bulk logged recovery model is different from the simple and full recovery models in that all transactions are fully logged with the exception of bulk insert tasks. These bulk insert tasks are only minimally logged. With the simply recovery model the transactions are purged from the transaction log file every few minutes at most. Expandability In addition to having the redundant hardware some systems will allow you to add CPUs and RAM to the system on the fly. These are Enterprise class features, but as more time goes on these features will make their way into more and more systems. Hot Add CPU The ability to add CPUs into the server is a hardware and operating system function as well as a function of the SQL Server. This gives you the ability to physically add physical CPUs to the server without powering down the system. This typically is . and the two servers on the right cannot connect to the three servers on the left they will take a vote between themselves and decide if the remote servers are offline. Once they decide that the. on the hard drives the SQL Server will not start. Changing the IP Address of a clustered SQL Server is not as easy as simply changing the IP Address of the SQL Server IP address resource in the. dependencies of the cluster and the SQL Server will no longer start, make sure that the SQL Server is dependent on all the correct hard drives and on the network name. If the SQL Service is