|
|
The following sections describe the different aspects of your MultiSite use model.
While you are planning your implementation, you need to 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.
With centralized administration, there is a hub site. For each VOB family, all the replicas in the family are mastered by a replica at the hub site. Administrators at the hub site maintain all replicas and all synchronization patterns and schedules. These administrators have permission to access the VOB replica servers at all sites.
Your company does not have to hire a MultiSite administrator for each site.
It is easier to make sure schedules do not conflict with each other.
Some administrative procedures require a replica to be self-mastering.
If ClearCase administration is done at a local level, the MultiSite administrators must have knowledge of all local administrative procedures (for example, backups and server maintenance).
Remote access to all sites is required.
With individual administration, each replica is self-mastering and there is an administrator at each site. Administrators are responsible for creating and maintaining replicas, synchronization patterns, and synchronization schedules at their sites.
No mastership changes are required when an administrator needs to change replica properties.
Administrators can ensure that MultiSite administrative procedures do not conflict with ClearCase administration.
A MultiSite administrator is needed at each site.
Communication among administrators can be difficult if the company has sites in multiple time zones.
You can also have semi-centralized administration. For example, you may have MultiSite administrators at sites with major development efforts and give these administrators control over their MultiSite environment. The responsibility for administering smaller sites is distributed among the MultiSite administrators.
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 VOB objects. After you create the replicas in the VOB family, you can change mastership of objects. For more information, see Enabling Independent VOB Development: Mastership and Changing Mastership.
When you import a replica-creation packet, you must specify whether the new replica is ownership-preserving or non-ownership-preserving. In most cases, your replicas must be non-ownership-preserving. For information about the requirements for creating ownership-preserving replicas, see Element Ownership and Ownership Preservation.
If you plan to create one or more ownership-preserving VOB replicas, follow these steps:
At the exporting site, gather the current VOB ownership and group information and send it along with the packets created by mkreplica -export.
Get the name of the VOB owner and VOB groups, using the cleartool describe command on the VOB object. For example:
Translate the symbolic names to numbers. On UNIX, become the VOB owner and issue the id command. For example:
|
su ccadm |
At each importing site, ensure that the user ID, primary group, and secondary groups match the information from the exporting site, in name and number.
If they do not match, you must modify the user and group information to prevent import failures due to permissions problems, as described in Ownership Preservation.
If the names are the same and the numbers are different, you must create non-ownership-preserving replicas.
There are multiple methods you can use to transport MultiSite packets. The method you choose depends on how your sites are connected, how quickly you must transfer packets, and how important security is. Table 4 lists the recommended methods for various situations.
Your situation | Recommended methods | Source of more information |
|---|---|---|
Sites are connected with high-speed lines | Transferring Packets with Store-and-Forward | |
One or more sites have firewalls | Tape, diskette, CD-ROM, e-mail, ftp, shipping_server | Using MultiSite through a Firewall |
Must transfer packets quickly | E-mail, ftp, shipping_server | shipping_server reference page, syncreplica reference page |
No electronic connection between sites | Tape, diskette, CD-ROM | syncreplica reference page |
The synchronization pattern for a VOB family defines which replicas exchange update packets and the direction of exchange. Your choice of pattern depends on the following factors:
Bandwidth between sites
Network topology
Latency of changes: how quickly changes made at one replica need to be received at another replica in the family
Failure tolerance
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.
Figure 10 Unidirectional and Bidirectional Updating
In most cases, you will use bidirectional updating. Unidirectional updates are suitable in situations like these:
You use a replica as a backup.
Your company supplies source code to another site (or company) for read-only use.
A high-security development project uses the same files as a more open project. In this case, the open project sends updates to the high-security project, but no updates are sent in the other direction.
However, 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; do this by creating triggers or locking the VOB to prevent checkouts and creation of metadata.
Figure 11 One-to-One Synchronization Pattern
Figure 12 Ring Synchronization Pattern
The simple one-to-one and ring (or round-robin) patterns are simple patterns that are most suitable for small numbers of replicas. As the number of replicas grows larger, the amount of time increases for a change made at one replica to be received at a replica at the other side of the ring.
Figure 13 Single-Hub Synchronization Pattern
Figure 14 Multiple-Hub Synchronization Pattern
Figure 15 Tree Synchronization Pattern
More efficient for the spoke and branch replicas, which send to and receive from only one other replica.
If the hub or root site goes down, all spoke/branch sites must reconfigure their pattern to keep communication going.
If you change the synchronization pattern so that replicas that did not synchronize directly now exchange packets, the first packets that are generated may be too large for the system. To avoid this problem, you can run chepoch -actual regularly among the spoke or branch replicas.
Figure 16 Many-to-Many Synchronization Pattern
For companies with few sites, this pattern keeps each replica's epoch table the most accurate for all siblings.
If one site is unavailable, the other sites do not have to change their patterns to continue synchronizing.
Each administrator must maintain more synchronization jobs and spend more time keeping track of packets.
The synchronization schedule for a VOB 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:
Rate of development.
If you schedule synchronizations frequently, merging is simpler because fewer changes have taken place. Also, you lose less work if a replica is deleted accidentally and you must restore it from backup.
Make sure that synchronizations do not overlap with VOB backups. VOBs must be locked while they are being backed up, and the syncreplica command fails if the VOB is locked.
Time zone differences. Be sure to take different time zones into account when you send an update or set up automated updates. Figure 22 here illustrates synchronization taking place among replicas in three time zones.
Use of administrative VOBs. Because local type objects in a client VOB are linked to global type objects in the administrative VOB, we recommend that you synchronize a client VOB and its administrative VOB at the same time. If you do not, users may have trouble accessing type objects.
For example, at the Boston site, the client 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.
Use of ClearCase UCM. 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.
You can use MultiSite as part of your VOB backup strategy. For more information, see Chapter 11, Backing Up VOBs with MultiSite.
When a ClearCase or MultiSite command makes a change to a replica, an oplog entry is recorded in the replica's database. (See VOB Operations and the Oplog for more information on this mechanism.) Also, when you export an update packet, an export_sync record is created for each target replica. These records are stored in the VOB database and 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 on VOB scrubbing, see the ClearCase vob_scrubber reference page.
Oplog entries must be kept in the database for a significant period. In the near term, they are required when the replica generates update packets to be sent to all other replicas. Beyond that, entries 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 VOB family and verify that packets are being exported and imported successfully.
When it is safe to delete oplog entries for a replica, follow these steps:
Coordinate with administrators at other sites to decide how long each site must keep oplog entries.
Each site must keep entries for as long as necessary to allow restorereplica operations to complete successfully. The frequency with which you scrub oplogs depends on the following factors:
The pattern of synchronization among replicas in the VOB family
How often the replicas are synchronized
Frequency of synchronization refers both to how often updates are exported and to how often they are imported at other sites. Also, consider setting up a verification scheme so you can ensure that packets are processed successfully at other replicas before any oplog entries are scrubbed.
How often you back up the replicas
For example, if a VOB 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.
Change the oplog scrubbing parameter for your replica:
Copy ccase-home-dir/config/vob/vob_scrubber_params (UNIX) or ccase-home-dir\config\vob\vob_scrubber_params (Windows) to the VOB storage directory of the replica. This creates a parameter file specific to the VOB.
Make this new file writable.
Edit the oplog line in this file. For example, to keep oplog entries for two months (62 days):
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 VOB 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 VOB 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.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
