As Windows NT (okay, Windows 2000) begins to move deeper into the enterprise, companies will become increasingly dependant on clustered systems to maximize availability, scalability, and manageability. For all the hype about NT clustering, most IT professionals still have a lot more questions than answers. Fortunately, the truth is out there -- in the Windows NT Cluster Server Guidebook.
David Libertone tells you what Microsoft Cluster Server can do and explains where it's headed. He offers expert help in determining whether it makes sense for you. If it does, he walks you through planning, installation, managing and optimizing. You'll establish your cluster, install cluster members, and learn how to work with every element of an NT clustered system.
You'll master administration and security, including how to upgrade SCSI adapters and software, perform backups of clustered resources, and leverage cluster performance. And if you ever find yourself in the special circle of hell reserved for those who must troubleshoot failed clusters, offers invaluable guidance.
Bill Carmada @ Cyberian Express
A guide for those who want to quickly create and utilize clusters of NT servers. Covers building a cluster, implementing cluster available resources, the clustering SQL server, troubleshooting, and the future outlook for Microsoft Cluster Server. Appends a resource dependency table, information about the cluster API, and a glossary. Annotation c. by Book News, Inc., Portland, Or.
Read an Excerpt
Chapter 6: Clustering SQL ServerThere is a statement from the movie, "Sneakers," that can be paraphrased as follows: "It's not money that leads to ultimate power these days, it is control of the data." It is almost scary to think how accurate that statement is. Unavailability of data can be directly translated to loss of revenues.
At the time this book was being sent to press, Cluster Server is a new product, probably released only three or four months ago. Previous chapters have detailed the somewhat generic resources that can be implemented through a cluster.
The next step in the growth of clusters occurs as applications are specifically written to take advantage of features, such as fault tolerance, that a cluster can provide. Some applications can be implemented simply as generic applications or generic services and will not require rewrites, but as new versions of software become available, they will include some level of cluster support. There are a few applications that have built-in support to the Cluster Server software. For example, one resource type that will be discussed in a later chapter is the Distributed Transaction Coordinator. This product is bundled with Windows NT Server, Enterprise Edition along with Cluster Server. Other products have a separate release that includes cluster support. The Microsoft products that include cluster support are the "enterprise" editions of products. Two such products with an enterprise edition release are SQL Server and Exchange Server. The SQL Server enterprise edition will be discussed here and Exchange Server in the next chapter.
SQL Server - Overview Before discussing the implementation of SQL Server in a clustered environment, a brief overview of SQL Server in a standard environment is necessary for comparison purposes. In a typical standalone SQL Server installation, three services are installed: a SQL Executive, SQL Server, and MSDTC (Microsoft Distributed Transaction Coordinator) service. Each service performs specific tasks within the SQL Server umbrella. For example, the SQL Executive is responsible for executing scheduled SQL tasks, such as backups. Standard client access to data is provided by the SQL Server service.
Devices and Databases A device is a pre-allocated area of a disk that SQL Server will use as a storage device. From Windows NT's perspective, an SQL device is a file. From SQL Server's perspective, the device is like a logical drive. SQL Server can create and store multiple databases on a device. A 100 megabyte device might only be five to ten percent utilized, but Windows NT sees only the 100 megabyte file and must back up the entire device. This is why it is not practical to perform a Windows NT backup of an SQL Server device.
A database consists of tables, which are the basic unit of data storage for SQL Server. Databases are created on an SQL device. Outside of SQL Server, databases are hidden, residing in the file that represents the SQL Server device.
There are a number of devices and databases created during the installation process. The most common device is the master device, which holds the master, model, pubs, and tempdb databases.
Microsoft Cluster Server Support for SQL Server The Microsoft Cluster Server software supports two types of SQL Server configurations. The configuration used depends upon the desired result of the cluster/data base administrator. The type of SQL Server implementation desired also influences the hardware required by the cluster, specifically the shared SCSI disks. The two configurations possible are known as active/active and active/passive configurations. Both configurations use symmetric virtual servers.
A Symmetric Virtual Server is an instance of a SQL Server, Each symmetric virtual server can be linked to a standard SQL Server installation. To the client, the virtual server is referenced by a server name as is any other SQL Server. The difference is that the SQL virtual server is a group of resources on the cluster that can be owned by any cluster member. This equates to a fault tolerant SQL Server, at least from a hardware perspective, because the resources that implement the virtual server can fail over between cluster members. Since SQL virtual servers have their own installation, they also have their own master, model, tempdb, and user databases. One cluster node has the ability to simultaneously run one or more virtual servers.
Examine Figure 6-1. Assume two SQL Server installations have been performed along with Cluster support for SQL Server and the virtual server names are SQLSERVER 1 and SQLSERVER 2 The two SQL virtual servers are serving access to totally independent databases. If NODEA fails, the virtual server SQLSERVER 1 will be moved by the cluster software to NODEB along with all the supporting resources, such as the physical disk. To a client application, it is equivalent to turning NODEA off and then immediately back on. The client will lose all connections to the SQL Server and all uncommitted transactions are rolled back. The client application must reconnect to the server SQLSERVER1. The fact that the virtual server is now running on NODEB will be transparent to the client. The server environment is preserved as the virtual server is moved from NODEA to NODEB. Information in all open databases and logs will be consistent after the failover. In reality, the new server is working with the same data, because the physical disk that stores the devices is now owned by NODEB. Any SQL registry information is kept consistent between nodes with registry replication.
Client applications may require slight modification to take full advantage of SQL Server cluster functionality. They should be written to reestablish lost connections when the server fails. Connections to an SQL Sever can be state-oriented or stateless. Any state or data associated with a connection is lost when the connection is broken. This includes any uncommitted transactions and temporary tables. if the connection to the SQL Server is stateless, such as with Microsoft Access or Internet Information Server, the client can reconnect and continue processing with no loss of data. Stateless clients provide a more seamless failover and recovery of the SQL virtual server.
Active/Passive Configuration In an active/passive configuration, only one cluster member is running SQL Server (the active server), and the other cluster member is available as a backup if the active SQL Server fails. The second server is the passive server. Refer to Figure 6-1. To implement an active/passive configuration, install SQL Server on NODEA only. On NODEB, install the SQL Server utilities. Now one virtual server can be created, associated with the SQL Server installation on NODEA. This implementation offers fault tolerance and requires no additional hardware. The SQL Server installation, along with the master device, must be located on one of the shared SCSI devices. This allows the SQL virtual server to fail over successfully between cluster members.
Active/Active Configuration In an active/active configuration, there are multiple instances of SQL Server running as symmetric virtual servers. The cluster support for SQL Server allows more than one instance of SQL Server to be running on a node in the cluster. In a typical two-node cluster, there can be two SQL virtual servers. Normally they can be load-balanced by defining appropriate preferred owners. if one of the cluster nodes goes offline, the SQL virtual server resource will fail over to the remaining cluster member and will still be reachable by clients.
An active/active configuration requires additional hardware. There must be multiple installations of SQL Server, one per virtual server. The SQL Server installations must be on separate SCSI devices on the shared bus. In order to distribute the SQL processing load among the cluster nodes, the SQL Server installations must be on separate disk resources that can be owned independently of each other.
Upgrading from SQL Server 65 to SQL Server, Enterprise Edition 65 It is possible to upgrade an SQL Server 6.5 installation to SQLServer, Enterprise Edition 6.5. The one major consideration is replication. If replication is in use, all replicated transactions in the distribution database must be distributed before upgrading to SQL Server, Enterprise Edition 6.5. If it is unclear whether all replicated transactions have been processed, users should be unsubscribed before installation and resubscribed after the upgrade has been completed.
It is recommended that all servers which function as replication Publishers and Distributors be upgraded to either SQL Server 6.5, service pack 3, or to the Enterprise Edition version. A Distribution server running service pack 3 or Enterprise Edition can communicate properly with Publishers run versions of SQL Server earlier than service pack 3. The reverse is not true, however. A Publisher running service pack 3 should not run against a Distributor running an earlier service pack.
Replication depends extensively on server names for each node in the replication configuration. Renaming of a server involved in replication is not supported. When clustering support for SQL Server is installed, a new server name is created. In order for replication to function properly, it must be deinstalled prior to configuring the SQL Server cluster support, and re-installed after the the configuration is complete.
Installing SQL Server, Enterprise Edition 65 Installing SQL Server is a straightforward process. There are some special installation requirements when installing SQL Server to be run in a clustered environment. . . .