Quorum Uses

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Standard Quorums

Standard quorums should be sufficient for the majority of situations that users will encounter. Typical situations include:

  • Highly available data in a single location – most customers that require their data to be highly available only need this on a per site basis. If they have multiple sites, each site has its own cluster. Typical applications that use this type of cluster include Microsoft SQL Server™, Exchange Server, file shares, printer queues, and network services (e.g. DHCP & WINS).

  • Stateful applications – applications or NT services that require only a single instance at any time and require some sort of state to be stored, typically use standard quorums, as they already have some sort of shared storage for maintaining the state.

Majority Node Set Quorums

While majority node set quorums are an exciting new feature of Windows Server 2003 clusters, they do have very strict requirements to ensure they work correctly, and therefore should only be considered by people who fully understand the issues involved in using MNS based clusters. The following are the key situations that the product team thought of when creating MNS quorums:

  • Geographically Dispersed Clusters – this involves a single MSCS cluster that has members in multiple geographic sites. While geographic clusters are possible using a standard quorum (for example, there is a separate geographic cluster Hardware Compatibility List (HCL)), a number of issues arise in terms of presenting the quorum as a single, logical shared drive between all sites. Majority Node Set quorums solve these issues by allowing the quorum to be stored on the local hard disk.

  • Clusters with No Shared Disks – there are some specialized configurations that need tightly consistent cluster features without having shared disks. For example:

    • Clusters that host applications that can failover, but where there is some other, application-specific way to keep data consistent between nodes (e.g. database log shipping for keeping database state up-to-date; file replication for relatively static data, etc.).

    • Clusters that host applications that have no persistent data, but need to cooperate in a tightly coupled way to provide consistent volatile state.

    • Independent Software Vendors – by abstracting storage from the Cluster service, it provides independent software vendors with much greater flexibility in how they design sophisticated cluster scenarios.