The following sections describe the different aspects of your MultiSite use model.
You must decide how much control the individual sites will have over their replicas. Your choices are centralized administration, individual administration, or some combination of the two.
Advantages of this scheme:
Disadvantages:
Advantages of this scheme:
Disadvantages:
You can also have semi-centralized administration. For example, sites with major development efforts have local MultiSite administrators, and responsibility for administering smaller sites is distributed among the MultiSite administrators.
In MultiSite, time stamps are stored in Universal Coordinated Time (UTC) and are printed to reflect the local time. For example, if a developer in Bangalore, India, checks in a version at 14:33 Bangalore time, the creation time is stored as 09:03UTC. When a developer in San Francisco looks at the version, the time is displayed as 01:03 San Francisco time.
When you automate synchronization, you must adjust schedules for time zone differences. For an example, see Synchronization Schedule.
Time rules in config specs are not absolute. The version selected by a time rule can change after an update packet is imported at your replica. For example, your config spec has the following time rule, which selects the latest version on the main branch as of July 10 at 7:00 P.M.:
When you put this rule in the config spec, the latest version on the main branch was 17. However, a developer at another replica created version 18 on July 10 at 6:00 P.M. your time, but this change has not been propagated to your replica. After the update packet that contains the change is imported at your replica, your time rule selects version 18.
The choices you make for your ClearCase use model and MultiSite administration model determine your mastership strategy. Your plan should state which replicas will master branch types, label types, elements, and other objects. After you create the replicas in the family, you can change mastership of objects. For more information, see Enabling Independent Development: Mastership and Changing Mastership of VOB Objects.
When you import a replica-creation packet, you must specify a preservation mode for the new replica. A replica can preserve identities and permissions, preserve permissions only, or preserve neither identities nor permissions. In most cases, your replicas must be permissions preserving or nonpreserving.
The following sections describe the three modes.
Identities- and permissions-preserving replicas maintain the same user and group identities and permissions on elements, and changes to identities or permissions are synchronized among them. The owner and group of the original VOB are not preserved; the user who enters the mkreplica –import command becomes the owner of the new VOB. That user’s group is the primary group of the VOB, and the user’s group list becomes the VOB’s group list. The user must be a member of all the groups that are used for elements in the replica.
To create a replica that preserves identities and permissions, you should run mkreplica –export at an identities- and permissions-preserving replica.
Note: You may need to run cleartool protectvob on the new VOB replica to ensure that the owner, group, and group list of the new VOB match the values in the other identities- and permissions-preserving replicas in the VOB family. Make sure that you update the VOB owner’s group list. When you run mkreplica –import, you may want to run the command as the VOB owner of the other identities- and permissions-preserving replicas in the family. If the VOB owner account has the same group list at the exporting and importing sites, you do not need to run protectvob.
Permissions-preserving replicas maintain the same permissions on elements, and changes to permissions are synchronized among the other replicas in the family that preserve permissions, including those that preserve both identities and permissions.
Read, write, and execute permissions for user, group, and other are preserved. The set-UID bit, set-GID bit, and sticky bit are not preserved.
Caution: If you need to restrict read or execute permissions to certain subgroups, we recommend that you do not use permissions-preserving replicas. It is possible for a malicious user at one site to change the permissions on an element in order to grant read access to a user at another site who is not the element owner or in the element’s group. If you choose to use permissions-preserving replicas, you may want to define a trigger that informs you when a cleartool protect command is run. Also, when you run mkreplica –import and create a permissions-preserving replica, make sure that your primary group is appropriate.
In order for you to change a replica to be permissions preserving or to create a new permissions-preserving replica, the VOB family feature level of the replica must be 4. Also, the cleartool protect command fails if you use the –chmod option, specify an object in a permissions-preserving replica, and your client host is running a version of ClearCase associated with feature level 3 or lower.
Permissions-preserving replicas ignore changes to identities made at other replicas and maintain their own identities information for elements. For permissions-preserving replicas:
To create a replica that preserves permissions, you should run mkreplica –export at an identities- and permissions-preserving replica or a permissions-preserving replica.
Nonpreserving replicas ignore identities and permissions changes made at other replicas and maintain their own identities and permissions information for elements. For nonpreserving replicas:
When an update packet is imported at a permissions-preserving replica, identities information is ignored. When an update packet is imported at a nonpreserving replica, identities and permissions information is ignored. At both kinds of replicas, the information remains in the oplog entries so that it can be transmitted to replicas that preserve identities and permissions or permissions only. For example:
Elements created at a nonpreserving or permissions-preserving replica always get the importing VOB’s owner and group when they are imported, regardless of whether the importing replica preserves identities.
The sites of replicas that preserve both identities and permissions must support the same set of user and group accounts (at least for the accounts that can be assigned to VOB elements). The user and group names and numerical IDs must be the same across sites. For example, on UNIX, the sites must share the same NIS map. On Windows, the replicas must be in the same Windows domain.
On UNIX, you can maintain separate but identical user/group databases across domains. On Windows, ownership modes (UIDs and GIDs) are not consistent across domains.
Therefore, the entire set of replicas cannot preserve identities in either of the following cases:
You can preserve identities in a subset of replicas in a VOB family. For example:
Note: There can be only one subset of identities- and permissions-preserving replicas in a VOB family, even if some replicas do not exchange update packets with all other replicas in the family.
If you plan to create one or more identities- and permissions-preserving VOB replicas, follow these steps:
ccadm
and the group is user
:
On UNIX, as the VOB owner, issue the id command. For example:
On Windows, as the VOB owner, issue the ccase-home-dir\etc\utils\creds command. For example:
If they do not match, you must modify the user and group information to prevent import failures due to permissions problems. (These kinds of import failures are described in Preservation Mode.)
If the names are the same and the numbers are different, you must create nonpreserving or permissions-preserving replicas.
If you run protectvob on a VOB replica that preserves identities, you must follow these steps to prevent metadata divergence or synchronization problems among replicas in the VOB family:
If you do not change the owner or group at all identities-preserving VOB replicas at the same time, metadata divergence can occur for the owner or group of new elements created at nonpreserving replicas. When the oplog entry for the new element is imported at an identities-preserving replica, the element’s owner or group is the owner or group of the VOB at the time the entry is imported. If a change to the VOB owner or group has been made at other identities-preserving replicas, the element’s owner or group will be different at the different replicas.
If you do not add a group to all identities-preserving VOB replicas at the same time, synchronization failures can occur for elements with the new group. The failures occur during import at the replicas where the group was not added.
When you remove a group from the group list of a VOB replica, the group cannot be used for new elements created in the VOB, but existing elements with that group are not changed. (To find these elements, use the find command with the –group option.) If you do not remove the group from all identities-preserving replicas at the same time, synchronization import failures can occur for new elements created with the deleted group. (You can fix the synchronization failure by running protectvob –add_group on the importing VOB replica.) An alternative to using protectvob –delete_group is to leave the group in the VOB’s group list and create a trigger that checks the primary group of the user and prevents creation of the element if the user’s primary group is one of the obsolete groups.
There are several methods for transporting update and replica-creation packets. The method you choose depends on how your sites are connected, how quickly you must transfer packets, and how important security is. For more information, see Choosing a Transport Method.
The synchronization pattern for a family defines which replicas exchange update packets and the direction of exchange. Figure 1 shows a simple synchronization pattern, involving one point-to-point update. All updates need not be point to point, however, because they are cumulative. Suppose that the following updates take place among three replicas:
Update 1: Replica 1 sends changes to Replica 2
Update 2: Replica 2 sends changes to Replica 3
There is no need for Replica 1 to update Replica 3 directly, because the changes from Update 1 are included in Update 2. This feature gives you flexibility in devising update strategies and patterns. For efficiency, a single update can be targeted at multiple replicas, for example, all other replicas in a family.
In general, you can implement any update topology, as dictated by organizational structures, communications/transportation costs, and so on. Figure 8 shows a simple peer-to-peer synchronization pattern, and Figure 9 shows a double-hub hierarchical pattern.
Your choice of pattern depends on the following factors:
The following sections describe unidirectional and bidirectional exchanges and the most common synchronization patterns.
Synchronization can be unidirectional or bidirectional, as shown in Figure 10.
In most cases, you will use bidirectional synchronization. Unidirectional synchronization is suitable in situations like these:
Unidirectional updates carry some risk. For example, an accidental change of mastership cannot be fixed, and restoring from a replica that does not exchange updates directly with the broken replica involves extra work. Also, you must ensure that no work is done accidentally in a read-only replica; you can do this by creating triggers or locking the VOB.
The one-to-one and ring (or round-robin) patterns in Figure 11 and Figure 12 are simple patterns that are most suitable for small numbers of replicas. As the number of replicas increases, so does the amount of time for changes originating at one replica to be received at a replica at the other side of the ring.
In the hub patterns (Figure 13 and Figure 14), the hub replicas exchange packets with all spoke replicas. In the tree pattern (Figure 15), the root replicas exchange packets with branch replicas.
Advantages:
Disadvantages:
In the many-to-many synchronization pattern (Figure 16), each replica exchanges packets with all other replicas
Advantages:
Disadvantages:
The synchronization schedule for a family defines when replicas in the family send and receive updates. The schedule is affected by many factors, including the rate of development at different sites, the connections among sites, and whether you use MultiSite as a backup strategy.
Consider the following issues when planning your synchronization strategy:
If you schedule synchronizations frequently, you lose less work if a replica is deleted accidentally and you must restore it from backup. Also, merging is simpler because fewer changes have been made.
Make sure that synchronizations do not overlap with backups. VOBs must be locked while they are being backed up, and the syncreplica command fails if the VOB is locked.
Take different time zones into account when you send an update or set up automated updates. Figure 17 illustrates synchronization among replicas in multiple time zones.
Because local type objects in VOBs are linked to global type objects in the administrative VOB, we recommend that you synchronize VOBs and their administrative VOB at the same time.
For example, at the Boston site, the VOB /vobs/dev is linked to administrative VOB /vobs/admin, and both VOBs are replicated to San Francisco and Bangalore. You export update packets to replicas sanfran_hub@/vobs/dev and sanfran_hub@/vobs/admin at 11:00 P.M. local time and export update packets to replicas bangalore@/vobs/dev and bangalore@/vobs/admin at 5:00 A.M. local time. The administrator at San Francisco imports both packets at the same time, as does the administrator at Bangalore.
If you do not synchronize VOBs and their administrative VOBs at the same time, users may have trouble accessing type objects.
We recommend that you synchronize a component VOB and its PVOB at the same time. If you do not, users may have trouble accessing baselines and activities and the versions associated with those objects.
For example, the administrators for the family in Figure 9 make the following decisions:
Figure 17 shows the synchronization timeline for the hub-spoke updates (but not the hourly hub-to-hub updates). This timeline accounts for time zone differences and includes extra time to make sure that each synchronization phase completes before another begins.
You can use MultiSite as part of your VOB backup strategy. For more information, see Using MultiSite for VOB Backup and Interoperability.
When a command makes a change to a replica, an entry is recorded in the replica’s operation log. For more information about this mechanism, see The Operation Log. Also, when you export an update packet, an export_sync record is created for each target replica. These records are used by the recoverpacket command to reset a replica’s epoch number matrix.
You can scrub oplog entries and export_sync records to reclaim disk space and database records, but you must keep them long enough to ensure that you can recover from replica failures and packet losses. The following sections give guidelines for configuring scrubbing frequency.
For more information about VOB scrubbing, see the vob_scrubber reference page.
Oplog entries must be kept for a significant period of time. They are required when the replica generates update packets. Oplog entries also may be required to help other replicas recover from catastrophic failures. If no replica can supply these entries, the replica being restored must be re-created. (See Restoring a Replica from Backup.) Because of the need to use oplog entries during synchronization, your synchronization strategy determines how often oplogs can be scrubbed.
By default, an oplog entry is never scrubbed. Do not change this setting until you establish the synchronization pattern in the family and verify that packets are being exported and imported successfully.
When it is safe to delete oplog entries for a replica:
Each replica must keep entries for as long as necessary to allow restorereplica operations to complete successfully. The frequency with which you scrub oplog entries depends on the following factors:
Frequency of synchronization refers to both how often updates are exported and how often they are imported at other replicas. Also, consider setting up a verification scheme to ensure that packets are processed successfully at other replicas before any oplog entries are scrubbed.
For example, if a replica is backed up weekly at all sites and you want to be able to restore to the backup from two weeks ago, each replica must keep three weeks of oplog entries. If replicas synchronize weekly, you must assume that the weekly packet hasn’t been sent to the other replica, and add another week. Finally, for extra security, add another month. The result is a scrubbing time of two months.
oplog –keep 62
Caution: If a replica’s oplog entries are scrubbed before they are included in an update packet, you cannot export update packets from the replica. This is a serious error and compromises the integrity of the entire family.
export_sync records are not necessary for normal synchronization operation. They are different from export event records, which also record synchronization exports and are included in output from the lshistory command and the History Browser.
export_sync records are date-based records used by the recoverpacket command to reset a replica’s epoch number matrix. If you do not use this packet recovery method (because you use chepoch –actual or lsepoch/chepoch), you can scrub these records aggressively. If you use the recoverpacket command, you must keep export_sync records for the number of days that elapse between backups. (See Recovering from Lost Packets.)
By default, the vob_scrubber_params file has no entry for export_sync records, and these records are scrubbed with the same frequency as oplog entries. If you want to scrub export_sync records at a different frequency than oplog entries, you can set the export_sync parameter in the vob_scrubber_params file. For more information, see the vob_scrubber reference page.
On Windows, if the pathname of a receipt handler or a shipping order contains spaces, DOS “short name” resolution must be enabled for the file system on which the receipt handler or shipping order is located. This property is enabled by default. If this property is not enabled, the shipping server cannot invoke the receipt handler or process the shipping order.