Microsoft® Failover Support for SQL Server, in conjunction with Microsoft Windows NT® Clustering Service for Windows NT Server, Enterprise Edition, allows you to set up a cluster of two servers to provide high-availability support for Microsoft SQL Server™.
The following figure shows the main components of a Microsoft Failover Support for SQL Server configuration.
The main components are:
These are the physical Windows NT Servers controlling SQL Server. Each server in the cluster is available to do work and the secondary server is available to recover the resources and workload of the primary server in the cluster.
A copy of Windows NT, Enterprise Edition and Clustering Service is installed on each server’s local hard drive.
Depending on the type of failover configuration (active/passive or active/active), one or more copies of SQL Server are located on one or more shared drives.
A working connection is necessary so that each server in the cluster can detect whether or not the other server has failed.
A SQL Server virtual server is the composite entity to which clients connect. The SQL Server virtual server has a network name, IP address, disk array, peripherals, and services. Clients are unaware of which physical Windows NT Server in the failover configuration currently has control of SQL Server. When a failure occurs, control of all the services and resources migrates to the remaining physical Windows NT Server.
A virtual server configuration is not the same as a standby server configuration. A standby server contains a second copy of SQL Server and a second copy of the SQL Server database. In a virtual server configuration, there is a single copy of the database, located on a common external disk, that is shared by the primary and secondary physical servers that make up the cluster and host the virtual server. Only one server in the cluster has control over the shared disk resource at a time.
Rather than associating SQL Server with a physical Windows NT Server, Clustering Service virtual server technology allows you to place SQL Server and SQL Server Agent cluster resources into a virtual server. The SQL Server virtual server’s name is independent of the physical node name on which the virtual server runs (the names of the physical Windows NT Servers and the SQL Server virtual server must be different). Regardless of which physical Windows NT Server in the cluster controls SQL Server, the virtual server name and address remains the same.
Clients connect to a SQL Server virtual server using the virtual server name, rather than a physical Windows NT Server name. The SQL Server virtual server name is implemented as a cluster network name resource and maps to a primary or backup node, depending on which node hosts the virtual server. Any client that uses WINS or directory services to locate servers can track the virtual server automatically as it moves between nodes. Automatically tracking the SQL Server virtual server does not require client modification or reconfiguration (this includes SQL Server Enterprise Manager and any OLE DB, ODBC, or DB-Library client applications).
At failover, client reconnection is necessary (the clients reconnect to the same virtual server name). SQL Server is started on the secondary node and any transactions that were in process during the system failure are rolled back automatically.
There are two main types of failover configurations:
In an active/passive configuration, there is one virtual server, one copy of SQL Server on one or more shared drives, and two physical Windows NT Servers. The active server, which can be either of the two physical Windows NT Servers, controls SQL Server. The secondary server does not take control of SQL Server until the primary server fails, or until an administrator moves control of SQL Server to the secondary server.
In an active/active configuration, there are two SQL Server virtual servers, two copies of SQL Server on one or more sets of shared drives, and two physical Windows NT Servers. The configuration is set up so that each of the two virtual server configurations are reverse arrangements of each other, with each physical Windows NT Server controlling one SQL Server virtual server and acting as a secondary or failover for the other virtual server.
SQL Server supports a subset of available network protocols when running in a clustered configuration. Clustering Service support allows failover of network addresses and names, which is supported for TCP/IP Sockets and Named Pipes. Server cluster setup, which sets up SQL Server cluster support, depends on Named Pipes. You can configure SQL Server to use TCP/IP Sockets support as long as Named Pipes is also supported. If you do not want SQL Server to listen for Named Pipes connections you can remove Named Pipes support prior to clustering, or after cluster setup by first unclustering and running SQL Server setup.
For more information, see the online Clustering Service Administrator’s Guide, available with Windows NT Server, Enterprise Edition.
Note The SQL Server Full-Text Search feature does not currently support Windows NT Clustering Service.