MCS vs NLB

Microsoft Cluster Service (MCS)

This is a list of Pros and Cons for Clustering and Network load balancing. A couple of months ago, the company I work for was looking to provide HA/redundancy for web servers.  This was the list I complied of Pros and Cons.  Each of these services has their place. Each will require different skill sets. It is up to you to choose the right path.

Pros

• MSCS offers fault tolerance of resources, services, and servers.
• Most administration can be done within a standard Microsoft Management Console (MMC), with an equivalent command-line utility offering scripting capabilities.
• Many Server services (e.g., WINS, DHCP, file shares, printing, IIS, Exchange, and SQL) are now cluster-aware to take advantage of this technology, and many generic applications and services can be configured in the cluster.
• MSCS enables you to monitor at the resource level and customize dependencies—for example, not just monitoring the IIS service but also the network name, address, and disk that this service uses.
• You can configure failed clustered groups to restart before attempting to failover.
• MSCS works independently of the protocol that is being used to access the servers.
• Install Patches without stopping Production

Cons

• MSCS requires special hardware (the whole unit must be on the clustering section of the Windows Hardware Compatibility List) because fault-tolerant clustered servers (e.g., SCSI disks) require shared storage that should be hardware RAID protected.
• Servers must be in a domain and cannot be in a workgroup. They are therefore better suited to back-end servers than those on a demilitarized zone (DMZ). Note that permissions should be assigned to global and not local groups.
• MSCS is heavily dependent on good hardware. Effective clustering runs on the assumption that the data is good. It cannot protect or recover from corrupted databases or failed disks.
• When a clustered server fails, there will still be some disruption. Connected users will be disconnected and typically asked to reauthenticate on the failed-over server.
• The shared data store does not support IDE disks, software RAID, dynamic volumes, EFS, mounted volumes and reparse points, or remote storage.

Network load balancing (NLB)

Pros

• NLB offers fault tolerance at the network layer, ensuring that connections are not directed to a server that is down.
• NLB is good for scaling out. It supports up to 32 servers per segment and can also employ DNS round robin for multiple clusters on different segments.
• NLB is highly configurable, with rules allowing for client affinity, weighting, filtering, etc.
• NLB is ideal on DMZs to simply distribute traffic to back-end servers and to encrypt/decrypt data to offload this task from busy back-end servers.
• No special hardware is required. You simply need two network adapters to mitigate a single point of failure.
• Install Patches without stopping production

Cons

• NLB is unable to detect if a service on the server has crashed, so it could direct a user to a system that can’t offer the requested service.
• There is no shared data. NLB can direct clients only to a back-end server or to independently replicated data.
• You can use NLB only with TCP/IP traffic—although this is not a problem on most networks today. But that does not include IPSec traffic.
• After initial configuration, maintenance and monitoring is done with a command-line utility, which is good for scripting but not as easy as a GUI application, such as an MMC, for ad hoc administration.
• All servers in a cluster must be in the same subnet. To provide redundant network links with NLB, you’ll need two (or more) clusters, and you’ll need to employ DNS round robin.