|
|
The MultiSite store-and-forward facility is a file-transfer service that automates the transport phase. This facility can handle packets of any size, can route files through a series of MultiSite hosts, one hop at a time, and includes support for handling data-communications failures. The major components of the store-and-forward facility are illustrated in Figure 23 and described in the following sections.
NOTE: To use store-and-forward, the sending host must be able to communicate with the receiving hosts. To determine whether the hosts can communicate, use the rcp command on the sending host to copy a file to the receiving host. If it fails, you may have to update the hosts file, hosts NIS map, or Domain Name Service before using store-and-forward.
Figure 23 The Store-and-Forward Facility
When a physical packet file is exported from a VOB replica and submitted to the store-and-forward facility, it is accompanied by a shipping order file, which specifies delivery instructions. The packet is stored in one of the storage bay directories on the VOB replica host.
Each storage bay directory contains two directories, incoming and outgoing, which hold the incoming and outgoing packets and their corresponding shipping order files. Shipping operations look in the incoming and outgoing directories for packets. A default storage bay, ms_ship, is created on a host when Rational ClearCase MultiSite is installed there.
NOTE: On Windows, the amount of available space on the disk partition where the shipping bays are located must be at least twice the size of the largest packet that will be stored in the shipping bays. There may be two copies of the same packet in the bay at one time: one on its way to another destination and another waiting to be applied to the replica on the host.
Return bays are similar to storage bays and provide "return-to-sender" storage for packets that could not be delivered successfully. A default return bay, ms_rtn, is created on a host when MultiSite is installed there. This bay has two subdirectories, incoming and outgoing, which hold the incoming and outgoing packets. Shipping operations look in the subdirectories for packets.
The shipping_server program transfers packet files from a storage bay (or return bay) at one site to the corresponding bay at another site.
An explicit command, manual or automated, invokes the shipping_server on the sending host. The shipping_server process contacts the albd_server process on the receiving host, which in turn invokes the shipping_server on the receiving host in receive mode. After a TCP/IP connection has been established between the sending and receiving invocations of shipping_server, the file is transferred.
The settings for the store-and-forward facility are host-specific. You can specify locations of storage and return bays, routing information to support multihop packet delivery, specifications to handle failure-to-deliver situations, receipt handlers, and so on. For more information on specifying settings, see the shipping.conf reference page on UNIX or the MultiSite Control Panel reference page on Windows.
When you generate a replica-creation or update packet, you can specify that the store-and-forward facility must deliver it. Both syncreplica and mkreplica support the following options:
The -fship option places the packet files and shipping order files in one of the host's storage bays, and runs shipping_server to send the packet files to their destination host or route them to an intermediate host.
The -ship option places the packet files and shipping order files in a storage bay, but does not invoke shipping_server. The packet files are sent the next time the shipping_server polls the appropriate bay. For information about setting up shipping_server to run automatically, see Automated Synchronization.
You can send any file using the store-and-forward facility if you create a shipping order for the file with the mkorder utility. You can send the file immediately or wait for the shipping_server to send it.
To send a file immediately, use the -fship option with mkorder:
/usr/atria/etc/mkorder -data /usr/rptgen/brdcst.0702 -fship -copy boston_hub tokyo
To store the file in a shipping bay so that shipping_server will send the file the next time it runs, use the -ship option:
/usr/atria/etc/mkorder -data /usr/rptgen/brdcst.0702 -ship -copy boston_hub tokyo
NOTE: The shipping order must be located in the same directory as the file.
After you invoke the mkorder command, you can delete the original file.
If a file with the same name already exists on the receiving host, the file you send is renamed to filename_1. If you transmit another file with the same name, it is renamed to filename_2, and so on.
The shipping order for a packet includes the host name of the packet's final destination or several such host names. By default, the store-and-forward facility sends the packet directly to its destination host. You can specify that the packet must be sent to an intermediate host by associating it with a routing hop in the shipping.conf file (UNIX) or in the MultiSite Control Panel (Windows).
On a UNIX host, the shipping.conf file includes this line:
ROUTE sydney_fw sanfran_hub boston_hub tokyo
On a Windows host, the Routing Information section in the MultiSite Control Panel specifies host sydney_fw in the Next Routing Hop box and hosts sanfran_hub, boston_hub, and tokyo in the Destination Hostnames box.
Any packet whose final destination is host sanfran_hub, boston_hub, or tokyo is forwarded to host sydney_fw. At this point, the local host has completed its task, and responsibility for delivering the packet now belongs to sydney_fw. Host sydney_fw can transmit the packet to its final destination directly, or send it to yet another intermediate host, depending on the settings in its shipping.conf file or in the MultiSite Control Panel.
NOTE: In a multihop transmission, using the -fship option on the original host causes the first hop to occur immediately. Subsequent hops occur when shipping_server is invoked on the intermediate hosts, which may not be immediately after the packets are received.
The shipping_server makes one attempt to transmit a packet to another host. If the packet cannot be transmitted (for example, because the receiving host is unavailable), shipping_server generates an error message and log file entry and exits. Administrators can set up a retry scheme to control its frequency:
After successful transmission of a packet, shipping_server deletes the packet and its shipping order. After a failure, the packet and shipping order remain in the storage bay.
shipping_server -poll transmits all packets it finds in one or more storage bays. Thus, any packets that remain after a transmission failure are sent (if possible) by the next invocation of shipping_server -poll.
The following job definition performs this operation every hour:
Job.Begin
Job.Id: 16
Job.Name: "Shipping Server Poll"
Job.Description.Begin:
Every hour, run the shipping server to send out any outstanding orders.
Job.Description.End:
Job.Schedule.Daily.Frequency: 1
Job.Schedule.FirstStartTime: 00:00:00
Job.Schedule.StartTimeRestartFrequency: 01:00:00
Job.DeleteWhenCompleted: FALSE
Job.Task: 13
Job.Args: -quiet 1 -poll
Job.End
See the cleartool schedule reference page in the Command Reference and Automated Synchronization.
Attempts to transmit an undelivered packet can continue indefinitely, through repeated invocations of shipping_server. However, administrators usually want to fix problems with failed transmissions instead of letting the attempts continue. Accordingly, each shipping order can include an expiration date-time, specified with one of the following:
The command option -pexpire
(UNIX) An EXPIRATION entry in the shipping.conf file
(Windows) A Packet Expiration value in the MultiSite Control Panel at the sending host
By default, shipping orders expire 14 days after they are created.
When shipping_server encounters a shipping order that has expired, it does not attempt to transmit the corresponding packet to its destination. Instead, it does the following:
It modifies the shipping order to return the packet to the original sending host, where it is placed in a special return bay.
It sends an electronic mail message to one or more addresses on the original sending host. (Another message is sent when the returned packet arrives at the original sending host.)
The return trip may involve multiple hops, as described in Setting Up an Indirect Shipping Route. During such a trip, a packet is placed in the return bay of each intermediate host. Each hop is handled by shipping_server -poll, which processes a host's return bay in addition to its storage bays. The expiration time for a packet's return trip is 14 days; a packet that cannot be returned in that interval is deleted.
If a packet is delivered through a Windows host on which e-mail notification is not enabled, a failure on that Windows host means that no notification message is sent by electronic mail. Instead, a message is written to the event log; this message contains a request that the appropriate users be informed of the failure. For information about enabling e-mail notification, see the MultiSite Control Panel reference page.
You can configure the store-and-forward facility to handle updates for different VOBs in different ways. Each packet can be assigned to a storage class, and each storage class can have its own storage bay, return bay, and expiration period.
NOTE: On UNIX, a storage class can be assigned several storage bays; in this case, shipping_server uses the size of the packet to select one of the bays. Conversely, several storage classes can share one or more storage bays.
You can use multiple storage classes to segregate the packets for VOBs belonging to different groups. By adjusting the operating system permissions on the storage bay directories, you can protect the packets from unauthorized use. You can also use a separate storage class when you use the store-and-forward facility to transfer non-MultiSite files between sites.
For more information on storage classes, see the shipping.conf and MultiSite Control Panel reference pages.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
