When setting up your clustered environment for SQL Server, you have several options for the network setup. Figure A shows what the minimum Microsoft-supported cluster configuration looks like. As you can see, one network adapter card in each server is reserved for a private interconnect. This private connection is only for the cluster’s heartbeat—the function that checks the health of the cluster resources. The other network adapter card is reserved for public communications and is a backup connection for the cluster’s heartbeat. You always want to have private communications on a private network in its own subnet because communications in a clustered environment use a lot of network bandwidth. The private connection can be either a cross-connect (a special network cable that directly connects the two servers) or a regular network connection. The main drawback to using this simple configuration is that it is vulnerable to a single point of failure. For example, as Figure A shows, if NIC2 fails, all communications to the cluster fail. This single point of failure is an unacceptable risk for most organizations.
The second network configuration option, which Figure B shows, eliminates the primary single-point-of-failure vulnerability in the network by replacing Figure A’s NIC2 with a dual network adapter card. As Figure B shows, NIC2 lets the private communications for the network go out one port, and the other port backs up NIC1 for public communications. The only remaining single-point-of-failure vulnerability in this configuration is the switch.
The third possible configuration, which Figure C shows, has no communications single-point-of-failure vulnerability. This configuration adds a third network adapter card to provide full redundancy for the private and public communications connections and adds a second network switch. Such a configuration can be a pricey choice because switches are costly, but if a single point of failure is unacceptable, it makes sense.
