Synchronization Modes and Processing
As noted earlier in this chapter, the Synchronization Service, running as LocalSystem, uses the replication engine and its drivers to keep cluster members in sync with the cluster controller. This service operates in one of two basic modes: automatic and on-demand. Each mode determines the timing and scope—members and content—of cluster synchronization.
Automatic Synchronization
By default, the system is configured for automatic updates. Applications will synchronize changes—configuration or content—as they are made, and will do a full synchronization of the entire cluster on an established time interval.
Change-Based Synchronization
When you make changes to the cluster controller, such as changing a member's drain time (a configuration change) or modifying part of an application (a content change), automatic synchronization is started. The changes to the controller are then replicated across the cluster. Change-based synchronization is enabled by the automatic session.
The Automatic Session
When automatic synchronization is first started, a session is created on the cluster controller (for the purpose of illustration, we'll call it the AutoSession). The AutoSession only exists on the controller and its sole purpose is communicating with the replication drivers in order to receive notifications of configuration or content changes. This activity is made possible by the replication engine, which listens for notifications from the replication drivers indicating that a change has occurred in their name space. (You may recall, from "The Replication Drivers" section earlier in this chapter, that each driver is responsible for tracking changes to its namespace[s].)
The AutoSession is a long running session, and it creates all the necessary short-lived synchronization sessions that are required to apply changes to the cluster. When the AutoSession receives a change notification, it creates a new, short-lived session. This new session, which exists on the controller and the members, behaves like any other replication session.
NOTE
Unlike the process described in "Processing Activities During a Full Synchronization" later in this chapter, there is no exchange and comparison of IHave lists, only an Update list is sent to the targets.
The short-lived session only exists for the length of time it takes to complete the synchronization. After the changes are applied to the members, the session is removed.
If there is a failure of either the controller or member, the session is canceled (by either the controller or member). There is no formal retry mechanism for these sessions, except for the hourly automatic sessions that perform a full synchronization.
WARNING
The settings for interval- and change-based automatic synchronization is combined. As Figure 6.7 indicates, disabling automatic updates also disables hourly full synchronization.
Interval-based Synchronization
During the setup process, Application Center is configured to automatically perform a "periodic full synchronization" of the cluster every 60 minutes (the default interval). A full synchronization of the cluster means that all the configuration settings and all the applications are synchronized to each member.
On-Demand Synchronization
Typically, on-demand synchronization is done when you create a new application or deploy an application. This is a partial synchronization, which is to say that only a selected portion of the controller's content is synchronized, rather than a full synchronization of the cluster. However, you can force a full synchronization of the entire cluster at any time. Table 6.2 summarizes both the automatic and on-demand synchronization options that are available to you.
Table 6.2 Synchronizations Summary
| Synchronization type | Invoked by | Resources | Target | System applications replicated? | Requires target in synchronization loop? |
|---|---|---|---|---|---|
| Automatic: change-based | Enable in cluster_name | Any changed files associated with an application or any changed system settings. | All members in loop. | Y | Y |
| Automatic: interval-based | Enable and configure in cluster_name Properties. | All applications and system settings. | All members in loop. | Y | Y |
| On-demand: member | Right-click member_name, and then click Synchronize. | All applications and system settings. | Specified member. | Y | N |
| On-demand: application | In the Applications view, select the application, and then click Synchronize. | Selected application. | All members in loop. | N | Y |
| On-demand: cluster | Right-click cluster_name, and then click Synchronize Cluster. | All applications and system settings. | All members in loop. | Y | Y |
NOTE
You can alter the default configuration settings at the cluster, controller, and individual member levels through their Properties dialog box. For more information, see "Configuring, Managing, and Monitoring Synchronization" later in this chapter.
Processing Activities During a Full Synchronization
The following processing activities typically take place when the entire cluster is synchronized.
The first thing that takes place is a call from the replication engine to all the drivers, instructing them to walk through their individual namespace (for example, application files and directories, metabase settings, and user-specified DSNs) on the controller and compare this information with each cluster member. The information that's different is then copied to the member and applied.
NOTE
In order to optimize the synchronization process, each driver maintains a token that indicates the time when the driver was last synchronized. When a full synchronization occurs, the token is checked to see if it's already in synchronization or not. If it is, the need for lengthy and resource-consuming content comparisons is eliminated.
There is, of course, more inter-server communication going on than indicated in the preceding summary. Figure 6.4 illustrates the communications and data transfer activities that occur between a controller and member during a full synchronization.
Figure 6.4 Controller and member communications during full synchronization
Before stepping through the major communications and data transfer activities, let's examine the lists that provide the foundation for replication: IHave, Action, and Update.
- IHave—lists all the current configuration settings and content with their signature that's stored on the cluster controller.
- Action—specifies the data that the member needs to be in synchronization with the controller.
- Update—contains all the resources that the member requested in its Action list.
Now let's walk through the main processing activities during a full synchronization. First, authentication occurs between the controller and the member. The user name and credentials for the ACC_computername account are used in intra-cluster replication, or administrative credentials (user name and password specified in the New Deployment Wizard) are used for inter-cluster deployment. In an inter-cluster deployment, the account must have administrative rights on the target. After inter-server communication is validated, a session is started for all the source drivers, and the replication engine instructs the target replication engine to do the same.
After the target replication engine gets a session running for its drivers, the controller sends its IHave list to the member. The member compares this list to its own IHave list and generates an Action list, which is sent to the controller. This Action list contains all the items that the member needs to be perfectly synchronized with the controller. How does it deal with deletes? The cluster member will note that the IHave list did not contain something that it has, and will delete those items during the apply phase.
The cluster controller does three things in response to the Action list. First, it processes the Action list and creates an update list that is sent to the member. This update list contains the actual items that have been requested in the Action list. For all the drivers except the File System driver, the items are actually included in the Update list.
The following sample illustrates the XML code that you'd expect to see in an IHave list:
<SCOPE TYPE="IHAVE" LAST="0" RESTYPE="FS" ROOT="c:\inetpub" ETAGTYPE=" STRONG" ITEMSIZE="8810" ENUM="FULL" ITEMCOUNT="2" DIFFUSION="MULTICAST"> <NODE SUBPATH="wwwroot" ENUM="FULL"> <ITEM NAME="default.asp" ETAG="67ED898" SIZE="345"></ITEM> <ITEM NAME="myimg.jpg" ETAG="5656365" SIZE="8465"></ITEM> <NODE SUBPATH="Images"/> <NODE SUBPATH="Apps"/> </NODE> </SCOPE> <SCOPE TYPE="IHAVE" LAST="0" RESTYPE="FS" ROOT="c:\inetpub\wwwroot" ETAGTYPE="STRONG" ITEMSIZE="4" ITEMCOUNT="1"> <NODE SUBPATH="Images" ENUM="FULL"> <ITEM NAME="image2.jpg" ETAG="463ED898" SIZE="4"></ITEM> </NODE> </SCOPE>
During this phase, the replication drivers on the controller copy the updates to a temporary storage location on the member. Then, after all the content has been transferred, the controller signals the target that it's ready to commit the session. When the transfer is finished, the member signals the controller that this phase is complete and it's ready to commit the changes.
Finally, the session is committed and the files and other resources are copied from their temporary location to the appropriate locations on the member. After the member notifies the controller that the commit was successful, the session is ended.
Most cluster synchronization, whether it's interval-based—which is just an instance of a full synchronization—or user-initiated (for example, the manual synchronization of an application), follows the same basic process as the one just described.
NOTE
Some drivers skip one or more parts of this process. For instance, updates to the registry content on the controller generate the UpdateList directly, without going through the IHave/Action phases.
EAN: N/A
Pages: 183