Export (0) Print
Expand All

Planning for Single Copy Clusters

 

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Topic Last Modified: 2008-07-24

Although deploying a Microsoft Exchange Server 2007 single copy cluster (SCC) is similar to deploying a stand-alone Exchange 2007 server, and similar to deploying cluster continuous replication (CCR), there are important differences you must consider.

The general requirements for deploying an SCC are as follows:

  • Make sure that you are running Domain Name System (DNS). Ideally, the DNS server should accept dynamic updates. If the DNS server does not accept dynamic updates, you must create a DNS Host (A) record for each clustered mailbox server and one for the cluster itself. Otherwise, Exchange does not function properly. For more information about how to configure DNS for Exchange, see Microsoft Knowledge Base article 322856, How to configure DNS to use with Exchange Server.

  • If your cluster nodes belong to a directory naming service zone that has a different name than the Active Directory directory service domain name that the computer joined, the DNSHostName property does not include the subdomain name by default. In this situation, you may need to change the DNSHostName property to ensure that some services, such as the File Replication Service (FRS), work correctly. For more information, see Knowledge Base article 240942, Active Directory DNSHostName property does not include subdomain.

  • All cluster nodes must be member servers in the same Active Directory domain and site. Exchange 2007 is not supported on nodes that are also Active Directory directory servers, or nodes that are members of different Active Directory domains or sites.

  • Make sure the cluster is formed before installing Exchange 2007. Make sure that at least one physical disk resource is present in the cluster group in which you intend to install Exchange 2007 before installing Exchange 2007. After installing the clustered mailbox server, configure the appropriate disk resource dependencies in Cluster Administrator.

  • Make sure that the clustered mailbox server names are 15 characters or less.

  • The cluster in which Exchange 2007 is installed cannot contain Exchange Server 2003, Exchange 2000 Server, or any cluster-aware version of Microsoft SQL Server. Running Exchange 2007 in a cluster with any of these other applications is not supported. Running Exchange 2007 in a cluster with SQL Server Express Edition or another database application (such as Microsoft Office Access) is permitted, provided that the database application is not clustered.

  • Before you install Exchange 2007, make sure that the folder to which you will install all of the Exchange data on the physical disk resource is empty.

  • You must install the same version of Exchange 2007 on all nodes in the cluster that are configured as hosts of a clustered mailbox server. In addition, the operating system and the Exchange files must be installed on the same paths and drives for all nodes in the cluster. This requires that all computers have a similar, although not identical, disk configuration.

  • Do not install, create, or move any resources from the default cluster group to the resource group containing the clustered mailbox server. In addition, do not install, create, or move any resources from the group containing the clustered mailbox server to the default cluster group. The default cluster group should contain only the cluster IP Address, Network Name and quorum resources. Moving or combining resources to or with the default cluster group is not supported.

    importantImportant:
    Clusters running previous versions of Exchange require a clustered instance of the Microsoft Distributed Transaction Coordinator (MSDTC). Exchange 2007 removes the requirement for the clustered MSDTC resource. Clustered mailbox servers in an SCC do not use the MSDTC resource installed in the failover cluster. Third-party applications might require an MSDTC resource because of COM+ dependencies. In Windows Server 2003, the MSDTC cluster resource requires the use of shared storage in the cluster. If a clustered MSDTC resource is required by a third-party application, it should be installed in a cluster group that is separate from the group containing the clustered mailbox server. Windows Server 2008 provides a local, non-clustered MSDTC instance that removes the requirement for shared storage in a Windows Server 2008 failover cluster. For more information about MSDTC changes in Windows Server 2008, see Windows Server 2008 Help.

The hardware requirements for SCC deployments are as follows:

  • The entire solution must be listed in the Cluster Solution category in the Microsoft Windows Server Catalog of Tested Products.

  • If the SCC is geographically dispersed, it must be listed in the Geographically Dispersed Cluster Solution category in the Microsoft Windows Server Catalog of Tested Products.

The software requirements for SCC deployments are as follows:

  • All nodes in the cluster must have the Windows Server 2008 Enterprise or Windows Server 2003 Enterprise Edition operating system installed on each node of the cluster using the same boot and system drive letters, and the same Windows path. You cannot have a cluster with one or more nodes running Windows Server 2003 and other nodes running Windows Server 2008. Mixing operating system versions in a failover cluster is not supported.

  • Only the Mailbox server role can be installed in a cluster. No other Exchange server roles can be installed on a computer that is part of a failover cluster.

It is important that the networks used for client and cluster communications are configured correctly. This section provides links to the procedures that are necessary to verify that your private and public network settings are configured correctly. In addition, you must make sure that the network connection order is configured correctly for the cluster.

Consider the following when designing the network infrastructure for your SCC deployment:

  • Each node must have at least two network adapters available for the cluster. Clients and other servers only have to be able to access the nodes from one of the network adapters. The other network adapters are used for intra-cluster communication.

  • You must have a sufficient number of static IP addresses available when you create clustered mailbox servers. IP addresses are required for both the public and private networks. Requirements related to private and public addresses are as follows:

    • Private addresses   Each node requires one static IP address for each network adapter that will be used for the cluster private network. You must use static IP addresses that are not on the same subnet or network as one of the public networks. We recommend that you use 10.10.10.x with a subnet mask of 255.255.255.0 as the private IP address subnet for the private network. If your public network uses a 10.x.x.x network and a 255.255.255.0 subnet mask, we recommend that you use alternate private network IP addresses and subnet mask. If you configure more than one private network, unique addresses and subnets are required for each private network adapter and network.

    • Public addresses   Each node requires one static IP address for each network adapter that will be used for the cluster public network. Additionally, static IP addresses are required for the server cluster and the clustered mailbox server so that they can be accessed by clients and administrators. You must use static IP addresses that are not on the same subnet or network as one of the private networks.

    noteNote:
    If you are installing SCC on Windows Server 2008, you can use a dynamically assigned Internet Protocol version 6 (IPv6) address along with the static IPv4 addresses used for the private or public networks.
  • If you are installing SCC on Windows Server 2003, the Cluster service requires the private network for all nodes in a cluster to be on the same subnet. To accomplish this in a geographically dispersed environment, you can use virtual LAN (VLAN) switches on the interconnects between two nodes. If you use a VLAN, the point-to-point, round-trip latency must be less than 0.5 seconds. In addition, the link between two nodes must appear as a single point-to-point connection from the perspective of the Windows operating system running on the nodes. To avoid single points of failure, use independent VLAN hardware for the different paths between the nodes. The same subnet restriction does not apply to failover clusters running on Windows Server 2008.

  • If you are installing SCC on Windows Server 2003, the Cluster service requires the public network for all nodes in a cluster to be on the same subnet, and this subnet must be different from the subnet used for the private network. The cluster public network should provide connectivity to other Exchange servers and other services, such as Active Directory and DNS. You can prevent this from being a single point of failure by using network adapter teaming or similar technology. The same subnet restriction does not apply to failover clusters running on Windows Server 2008.

  • A separate cluster private network must be provided. The private network is used for cluster inter-node communication. This network can be localized to computers in the cluster and does not require DNS services.

  • If you are installing SCC on Windows Server 2003, the network connection order in Windows must be configured with the public networks at the top of the connection order, and the network priority in the cluster must be configured with the private networks at the top of the priority order.

  • Heartbeat requirements may not be the most stringent public network bandwidth and latency requirement for a two-datacenter configuration. You must evaluate the total network load, which includes client, Active Directory, transport, and other traffic to determine the necessary network requirements.

SCCs use shared storage to store clustered mailbox server data (storage groups and databases). The quorum resource can also be stored on shared storage. An alternative to using shared storage for the quorum resource is to use a Majority Node Set (MNS) quorum. This can be a traditional MNS quorum, or an MNS quorum with file share witness.

It is critical that the following tasks be performed in the order shown for the SCC to operate correctly:

  1. All shared storage must be configured prior to cluster formation on each node that will be part of the cluster. It is mandatory that the quorum disk be configured and available to all nodes in the cluster prior to cluster formation. The cluster formation will fail if the quorum is not available.

  2. After the cluster has been formed, and before Exchange is installed, the physical disk resources for the clustered mailbox server shared storage must be configured.

  3. After Exchange has been installed and the clustered mailbox server has been created, the physical disk resource dependencies must be configured.

noteNote:
Shared storage for a clustered mailbox server must be accessible from all nodes that can host the clustered mailbox server.

When you design your SCC storage solution, we recommend that you follow these best practices:

  • Use the general storage planning guidance in Planning Storage Configurations.

  • Store the database files and transaction log files on different logical unit numbers (LUNs).

  • Use NTFS file system volume mount points to surface the volumes to the operating system.

  • Use recognizable names that can be directly and obviously tied to the hosted storage group or database. If different volumes are used for logs and databases, the paths should identify the type of data. This approach can help prevent human errors as the number of databases and storage groups increases.

    noteNote:
    Exchange 2007 does not support placing transaction logs or database files in the root of a volume.

SCC has all the same requirements of the Active Directory infrastructure that a stand-alone server has plus additional requirements. In a multiple datacenter solution, both datacenters must have adequate Active Directory infrastructure support because, at any time, either datacenter could be hosting the clustered mailbox server. This capacity needs to be present even if the other datacenters are not available. Additionally, all nodes in the cluster must be in the same domain and the Cluster service account must have the appropriate permissions.

noteNote:
Geographically dispersed clusters also require that a single Active Directory site be stretched between the datacenters. However, only the clustered node needs to be in the site in the second datacenter. Third-party hardware and replication technology is required to deploy a geographically dispersed SCC solution.

If you are installing SCC on Windows Server 2003, you must use a domain account for the Cluster service account. All nodes in the cluster must be members of the same domain, and all nodes in the cluster must use the same Cluster service account. The Cluster service account must also be a member of the local administrators group on each node that is capable of hosting a clustered mailbox server.

The Cluster service account is responsible for creating and maintaining the computer account identified by and associated with the failover cluster's Network Name resource when that resource is brought online. To ensure that the Cluster service account has the appropriate permissions, see Knowledge Base article 307532, How to troubleshoot the Cluster service account when it modifies computer objects. Additional information can be found in Knowledge Base article 251335, Domain Users Cannot Join Workstation or Server to a Domain.

If you are installing SCC on Windows Server 2008, the Cluster service will run under the LocalSystem (SYSTEM) account.

For more information about failover clusters in Windows Server 2008 and their Windows Server 2003 predecessor, server clusters, see the following resources:

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft