Cluster Install Introduction

Applies to: Forefront Security for Exchange Server

In recent years, clustered installations have become more popular. Microsoft® Exchange Server 2007 can be installed on clustered systems, using both Cluster Continuous Replication (CCR) and Single Copy Cluster (SCC) configurations. Microsoft® Forefront Security™ for Exchange Server (FSE) can then be installed on Exchange mailbox servers in clustered systems. FSE supports volume mount points.

For more information about configuring and running FSE, see the Forefront Security for Exchange Server User Guide.

Definitions

These are terms you may encounter when working with clusters.

Local Continuous Replication (LCR)

LCR allows for data replication to an alternate drive attached to the same system. This is not a cluster configuration because it does not provide true high availability in the event of system failure. It is intended to provide protection against local storage failures, but does not protect against the failure of the server itself. LCR is a single-server solution that uses built-in asynchronous log shipping and log replay technology to create and maintain a copy of a storage group on a second set of discs that are connected to the same server as the production storage group. LCR provides a quick manual switch to a secondary copy of your data. The procedure for installing Forefront Security for Exchange Server on an LCR system is the same as that for a normal Standalone installation.

Cluster Continuous Replication (CCR)

This type of clustered mailbox server combines the replication and replay features in Exchange 2007 with failover features in Microsoft Cluster services. CCR is a solution that can be deployed with no single point of failure in a single data center or between two data centers. A node that is currently running a Clustered Mailbox Server (formerly called an Exchange Virtual Server) is an active node; a node in the cluster that is not currently running a Clustered Mailbox Server is a passive node.

CCR uses the database failure recovery functionality in Exchange 2007 to enable the continuous and asynchronous updating of a second copy of a database with the changes that have been made to the active copy of the database. Logs are not copied until they are closed and no longer in use by the Mailbox server. During installation of the passive node in a CCR environment, each storage group and its database is copied from the active node to the passive node. This operation is called “seeding”, and it provides a baseline for replication of the database. After the initial seeding is performed, log copying and replay are performed continuously. CCR uses the passive node to copy and replay the logs. Logs are accessed by the passive node via a secured file share.

In a CCR environment, replication capabilities are integrated with the Cluster service to deliver a high availability solution. In addition to providing data and service availability, CCR also provides for scheduled outages. When updates need to be installed or when maintenance needs to be performed, you can move a Clustered Mailbox Server manually to a passive node. After the move operation is complete, you can perform the needed maintenance.

Single Copy Cluster (SCC)

This type of clustered mailbox server uses shared storage in a failover cluster configuration to permit multiple servers to manage a single copy of the storage groups. In this architecture, although all nodes in the cluster can access shared data, they cannot access it at the same time.

In a Single Copy Cluster, an Exchange 2007 mailbox server uses its own network identity, not the identity of any node in the cluster. This network identity is referred to as a Clustered Mailbox Server. If the node running a Clustered Mailbox Server experiences problems, the Clustered Mailbox Server goes offline for a brief period until another node takes control of it and brings it online (a process known as “failover”). The shared storage is available to each possible host node of the Clustered Mailbox Server. As the failover happens, the storage associated with the clustered mailbox is logically detected from the failed node and placed under the control of the new host node.

Standby Continuous Replication (SCR)

This is a replication technology, not a cluster configuration. Unlike CCR, which requires that both servers belong to a Windows cluster (typically residing in the same data center), SCR can replicate data to a non-clustered server located in a different data center. This configuration creates redundancy for data center storage by permitting an additional copy of the data to exist inside or outside the data center. SCR uses the continuous replication technology to move data from one mailbox server to another. SCR enables a mailbox server to be a continuous replication target for a standalone mailbox server that does not have LCR enabled. A mailbox server can also be a passive node in a failover cluster where the mailbox role is installed, but no clustered mailbox server has been installed in the cluster.

Failover

The process by which a server in the cluster takes over the functions of another server in the cluster in the case of a failure of the first device. The term can also be used for a deliberate transfer of services to another server in the cluster.

Quorum

The storage device that keeps track of which node owns a clustered application. When a failover occurs, this is the device that decides which server then becomes active.

Supporting third-party vendors

Microsoft Customer Support Services (CSS) supports FSE clustering based on the failover clustering features of the Microsoft Cluster Service (MSCS). Several third-party vendors offer clustering services and solutions that do not rely on MSCS for applicable versions of Microsoft Windows operating system software. Microsoft cannot provide information about the actual performance or interaction of third-party clustering services and solutions that are running Exchange.

CSS will attempt to help you troubleshoot Exchange-related issues when Exchange is installed on a third-party clustering solution. CSS will help until it is reasonably believed that the cause of the issue is an incompatibility between the third-party clustering solution and Exchange. CSS may suggest removing the third-party solution to help resolve the issue, although this is not a precondition to receiving CSS support services. CSS may also refer you to the vendor of the third-party clustering solution for additional troubleshooting support. It is your responsibility to engage the third-party vendor's support organization. CSS will try to provide reasonable assistance in working with a third-party vendor's support organization; however CSS cannot be considered the primary liaison between you and the third-party vendor. It is strongly recommended that you develop support relationships with each vendor whose hardware or software is part of your Exchange solution.