Exchange Replication Service (Exchange 2007 SP1) and Windows 2008 Clusters
If you are reading this blog post I also suggest you read the the following white paper: "White Paper: Continuous Replication Deep Dive" which can be found at https://technet.microsoft.com/en-us/library/cc535020.aspx. This white paper does a fantastic job of covering the operations of the replication service.
Windows 2008 and Windows 2008 clustering introduce changes to the operating system which effect the operation of the Exchange Replication Service. Specifically there are two items of interest. The first is the ability to programmatically create a share to a specific host and the integration of file sharing operations with the cluster service when shared storage is used. (These same concepts also effect Exchange Offline Address List Generation, see Dave Goldman's blog for more info on these topics - https://blogs.msdn.com/dgoldman/archive/2008/12/11/fix-for-oab-generation-failing-on-ccr-and-scc-clusters.aspx.).
Lets take a look at how this effects Exchange 2007 SP1 Cluster Continuous Replication (CCR) clusters.
With Exchange 2007 SP1 CCR clusters there are no shared storage devices. File shares that are created, which are necessary for the replication service to replicate log files, are created on the host.
In Windows 2003 clustering, when a file share was created on a local node it was accessible by any name the resolved to that node. (If the name did not exist as either the node name, or a virtual network name in cluster, it would be necessary to disable strict name checking in order for the host to accept the request - https://support.microsoft.com/kb/281308 - this could possibly happen when using a host file to map a different name or using a CNAME DNS record to map to a host). For example, if I create a share on the host named Files, I could access the share at \\NodeName\Files or \\CMSName\Files if the CMS (clustered mailbox server) was active on that node. In addition, if I used enable-continuousreplicationhostnames to create replication networks to replicate logs on an alternate network interface, I could also access the share at \\ContinuousReplicationHostName\Files
In the below example on Windows 2003, on the root of C, I created a share called Files and placed two text files in the share. There is a cluster network name that runs on the node where I created the share. From another machine in the environment, you can see that the share can be accessed at both \\NodeName and \\CMSName.
In Windows 2008, if I created the same share on the local node, it would only be accessible by \\NodeName\Files. If attempting to access the share at \\CMSName\Files an error is displayed. (In this example node name is 2008-Node1 and CMSName is 2008-MBX3).
On Windows 2008, in server manager-> roles -> file services -> share and storage management, the Files share appears in the list of available shares.
If you get the properties of the share, you can see that it's specifically scoped to the Node Name (review the share path).
In a default configuration for CCR, scoped shares do not have any impact how the replication service replicates log files. The main impact comes when using continuous replication host names. In order for this to function, the replication service has to specifically create the share and have it scoped at both the NodeName and CMSName.
When using continuous replication hostnames, if you review the Share and Storage Management console, you will see two (or more depending on how many continuous replication host names exist) instances of the shares for each storage group.
Each instance of the share uses the same share name and the same physical path on storage. The difference is in the properties of each of these shares. When reviewing the properties, you will see one share specifically scoped to the node name, the other share specifically scoped to the continuous replication host name. (In this example 2008-MBX3-ReplC is the continuous replication host name.)
*Example of share scoped to continuous replication host name.
*Example of share scoped to node name.
By creating scoped shares at both endpoints, the replication service is able to access logs using both the NodeName and ContinuousReplicationHostName.
Lets take a look at how this effects Exchange 2007 SP1 Single Copy Clusters (SCC).
With Exchange 2007 SP1 SCC all databases and log files reside on a shared storage device. This requires that the shares necessary for creation be created against folders that exist on shared volumes. In this instance, there is no local replication activity or replication between nodes of the cluster. The replication service is only used against a single copy cluster when the SCC cluster is acting as a standby continuous replication source.
With Windows 2003 the replication service would create the shares necessary for SCR replication to occur. These shares, by default, were available at both \\NodeName and \\CMSName. There was no tight integration between the sharing functions of the operating system and cluster where shared storage was concerned. (Remember that an SCR target replicates log files from an SCC SCR source at \\CMSName\StorageGroupGuid$).
In Windows 2008 cluster is more aware of shares created on shared storage. By default, when a share is created on a shared disk, the cluster service will automatically intercept that share and scope it only to the virtual name associated with the client access point that owns the disk. This happens when manually creating a share through the operating system or programmatically creating a share (regardless of the endpoint passed into the sharing function). Let's take a look at an example.
In this example I created a empty service or application. In the empty service or application, I created a new client access point. I created a new shared disk on my SAN, added the disk to available storage, and then moved it to the client access point. In my case the disk is the H volume (Cluster Disk 9).
On the node that owns the Empty-Group with the the client access point and disk, through the operating system, I created a folder on the H drive and shared it. After completing the sharing wizard, you can see the share is immediately scoped to the name used in the client access point. In this example my client access point name is EMPTY-GROUP, so the share is available at \\Empty-Group\Files.
When reviewing share and storage management, you will see the share. It's properties also reference the share created to the client access point name.
In additional to the above information, in the cluster administrator, in the service or application that I created, a new FileServer resource is created. The file server resource is dependant on the physical disk that the share resides on, and the client access point name. The share that was created is also viewable in cluster administrator.
How is this handled programmatically?
A common method to create shares was the Share_Info_502 Structure. (https://msdn.microsoft.com/en-us/library/bb525410(VS.85).aspx) When this structure is used on Windows 2008 cluster, the share is automatically created against the node name (as long as the shared folder does not reside on a shared disk). If the folder that is being shared resides on shared disk, cluster automatically intercepts this sharing requests and scopes the share to the client access point that owns the shared disk resource.
A new sharing method was introduced with Windows 2008. This is the Share_Info_503 structure. (https://msdn.microsoft.com/en-us/library/cc462916(VS.85).aspx) This structure allows the programmer to specify the server name as part of the sharing call. Here is an excerpt from the MSDN page.
shi503_servername
A pointer to a string that specifies the DNS or NetBIOS name of the remote server on which the shared resource resides. A value of "*" indicates no configured server name.
When using this sharing structure, the programmer can specify to create the share against the node name, the cms name (in the Exchange case), or both. The only exception is when the folder to be shared resides on a shared disk. Cluster will intercept this sharing call and allow the share to only be scoped to the client access point that owns the physical disk resource.
*Note: When creating shares on a shared storage device in Windows 2008 you should install KB 955733.
Comments
Anonymous
January 01, 2003
Implementing Captcha Validation with OWA 2007 and Forms-Based Authentication Domino to Exchange 2007Anonymous
January 01, 2003
In the recent weeks I've worked several cases where Exchange 2007 SP1 Single Copy Clusters with storageAnonymous
January 01, 2003
Back on Thursday, December 11, 2008 i published a blog that contained information on the fix for OAB