
Network Formation and Configuration
You must have a sufficient number of IP addresses available when you create clustered mailbox servers in an SCC on Windows Server 2008. Windows Server 2008 failover clustering introduces new networking capabilities that are a major shift away from the way things have been done in legacy clusters. For example, Windows Server 2008 failover clusters introduce support for multiple subnets, support for Dynamic Host Configuration Protocol (DHCP) Internet Protocol version 4 (IPv4), and IPv6. When running in a Windows Server 2008 failover cluster, Exchange 2007 Service Pack 1 (SP1) includes support for geographically dispersed clusters for failover across two subnets. This support includes both SCCs, as well as Mailbox servers in a cluster continuous replication (CCR) environment.
Note: |
|---|
|
Although DHCP IPv4 is supported in Windows Server 2008 failover clusters, we recommend using static IP addresses in production environments. If DHCP IPv4 is used in a failover cluster, we recommend that you configure the DHCP servers to grant leases of unlimited length.
|
Beginning with Windows Server 2008 failover clustering, individual cluster nodes can now be located on separate, routed networks. This requires that resources that depend on IP Address resources (for example, Network Name resources), implement an OR logic because it is unlikely that every cluster node will have a direct local connection to every network that the cluster knows about. This facilitates IP Address and Network Name resources coming online when services or applications fail over to remote nodes.
All IP addresses associated with a Network Name resource are dynamically registered in Domain Name System (DNS) (if configured for dynamic updates) with the list ordered such that those IP Address resources that are online are returned first to the clients. Because cluster nodes can be placed on different, routed networks, and the communication mechanisms have been changed to use reliable session protocols implemented over User Datagram Protocol (UDP) (unicast), the networking requirements for geographically dispersed clusters are no longer applicable. As a result, organizations can deploy a failover cluster across two physical datacenters without having to use virtual LAN (VLAN) technology to span the cluster subnets across the two locations.
When a move or a failover occurs for a clustered mailbox server deployed in a geographically dispersed, multiple subnet failover cluster, the name of the clustered mailbox server is maintained, but the IP address assigned to that name is not maintained. The availability of this server to clients and other servers depends on propagation of the new IP address throughout DNS. It may take some time for DNS propagation to occur. For this reason, we recommend configuring a Time to Live (TTL) value for the clustered mailbox server DNS host record to a value of 10 minutes.
Although internal Microsoft Office Outlook clients do not need new or reconfigured profiles to connect using the new IP address, they must wait for their local DNS cache to be cleared so that name resolution of the clustered mailbox server's name will move from its old IP address to its new IP address. After the IP address has been propagated to the appropriate DNS servers, the DNS cache on the Outlook clients can be cleared by using the following command at the command prompt on the client:
ipconfig /flushdns
IP addresses are required for both the private and public networks. Requirements related to private and public addresses are as follows:
- Private addresses Each node requires one IP address for each network adapter that is used for the cluster private network. You can use a static IPv4 address or a dynamically assigned IPv6 address. You must use 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.10 and 10.10.10.11 with a subnet mask of 255.255.255.0 as the private IP addresses for the nodes.
- Public addresses Each node requires one IP address for each network adapter that is used for the cluster public network, sometimes referred to as a mixed network. Additionally, IP addresses are required for the failover cluster and for the clustered mailbox server so that they can be accessed by clients and administrators. You must use IP addresses that are not on the same subnet or network as one of the private networks. You can use static IPv4 addresses, DHCP IPv4 addresses, or static IPv6 addresses.
Important: |
|---|
|
All network adapters for a cluster network must use the same version of TCP/IP, that is, they must all use IPv4, all use IPv6, or all use both IPv4 and IPv6.
|
Network Best Practices for Clustered Mailbox Servers
We also recommend that you follow these best practices for your cluster network:
- Use meaningful names Building a cluster gives you many opportunities to use meaningful names for cluster nodes, cluster network interfaces, the cluster name, and clustered mailbox server names. For example, the network used to communicate with other Exchange servers and clients can be called Public. The network used to communicate between the cluster nodes can be called Private. Use names that can be related to each other without having to review a topology map. Another useful convention is to relate the nodes of a cluster to the name of the clustered mailbox server. As an example, use mbx01, mbx01-node1, and mbx01-node2 for the clustered mailbox server and the two nodes, respectively.
- Use private IP addresses for the private network interfaces For an example address range and subnet mask for the private network interfaces on a two-node failover cluster, see the following table.
Address ranges and subnet masks for private network interfaces
|
Network / Node
|
IP address range
|
Subnet mask
|
| Private / NODE1 | 10.10.10.10-255 | 255.255.255.0 |
| Private / NODE2 | 10.10.10.11-255 | 255.255.255.0 |
Note the following:
-
If your public network uses a 10.x.x.x network and 255.255.255.0 subnet mask, we recommend that you use alternate private network IP addresses and a subnet mask.
-
We do not recommend the use of any type of fault-tolerant adapter or teaming for the private network. If you require redundancy for your private network, use multiple network adapters configured only for cluster use. For more information about this configuration, see the section "Configuring the Cluster Networks" later in this topic.
-
It is important to verify that your firmware and driver are at the most current revision if you use this technology. Contact your network adapter manufacturer for information about compatibility on a server cluster. For more information about network adapter teaming in server cluster deployments, see Microsoft Knowledge Base article 254101, Network adapter teaming and server clustering.