HP Archive Backup System for OpenVMS Guide to Operations
Share Embed Flag
Download ePaper

HP Archive Backup System for OpenVMS Guide to Operations

HP Archive Backup System for OpenVMS Guide to Operations HP Archive Backup System for OpenVMS Guide to Operations

h71000.www7.hp.com
from h71000.www7.hp.com More from this publisher
06.11.2014 Views

Remote Devices 8.4 Monitoring and Tuning Network Performance 8.4.7 Controlling RDF’s Effect on the Network By default, RDF tries to perform I/O requests as fast as possible. In some cases, this can cause the network to slow down. Reducing the network bandwidth used by RDF allows more of the network to become available to other processes. The RDF logical names that control this are: RDEV_WRITE_GROUP_SIZE RDEV_WRITE_GROUP_DELAY Default: The default values for these logical names is zero. The following example shows how to define these logical names on the RDF client node: $ DEFINE/SYSTEM RDEV_WRITE_GROUP_SIZE 30 $ DEFINE/SYSTEM RDEV_WRITE_GROUP_DELAY 1 Further reduction: To further reduce bandwidth, the RDEV_WRITE_GROUP_DELAY logical can be increased to two (2) or three (3). 8.4.8 Surviving Network Failures Note Reducing the bandwidth used by RDF causes slower transfers of RDF’s data across the network. Remote Device Facility (RDF) can survive network failures of up to 15 minutes long. If the network comes back within the 15 minutes allotted time, the RDCLIENT continues processing WITHOUT ANY INTERRUPTION OR DATA LOSS. When a network link drops while RDF is active, after 10 seconds, RDF creates a new network link, synchronizes I/Os between the RDCLIENT and RDSERVER, and continues processing. The following example shows how you can test the RDF’s ability to survive a network failure. (This example assumes that you have both the RDSERVER and RDCLIENT processes running.) $ @tti_rdev:rdallocate tti::mua0: RDF - Remote Device Facility (Version 4.3I) - RDALLOCATE Procedure Copyright (c) 1990, 1996 Touch Technologies, Inc. Device TTI::TTI$MUA0 ALLOCATED, use TAPE01 to reference it $ backup/rewind/log/ignore=label sys$library:*.* tape01:test from a second session: $ run sys$system:NCP NCP> show known links Known Link Volatile Summary as of 13-MAR-1996 14:07:38 Link Node PID Process Remote link Remote user 24593 20.4 (JR) 2040111C MARI_11C_5 8244 CTERM 16790 20.3 (FAST) 20400C3A -rdclient- 16791 tti_rdevSRV 24579 20.6 (CHEERS) 20400113 REMACP 8223 SAMMY 24585 20.6 (CHEERS) 20400113 REMACP 8224 ANDERSON NCP> disconnect link 16790 . . . 8-8 Remote Devices

Remote Devices 8.5 Controlling Access to RDF Resources Backup pauses momentarily before resuming. Sensing the network disconnect, RDF creates a new -rdclient- link. Verify this by entering the following command: NCP> show known links Known Link Volatile Summary as of 13-MAR-1996 16:07:00 Link Node PID Process Remote link Remote user 24593 20.4 (JR) 2040111C MARI_11C_5 8244 CTERM 24579 20.6 (CHEERS) 20400113 REMACP 8223 SAMMY 24585 20.6 (CHEERS) 20400113 REMACP 8224 ANDERSON 24600 20.3 (FAST) 20400C3A -rdclient- 24601 tti_rdevSRV NCP> exit 8.5 Controlling Access to RDF Resources The RDF Security Access feature allows storage administrators to control which remote devices are allowed to be accessed by RDF client nodes. 8.5.1 Allow Specific RDF Clients Access to All Remote Devices You can allow specific RDF client nodes access to all remote devices. Example: For example, if the server node is MIAMI and access to all remote devices is granted only to RDF client nodes OMAHA and DENVER, then do the following: 1. Edit TTI_RDEV:CONFIG_MIAMI.DAT 2. Before the first device designation line, insert the /ALLOW qualifier Edit TTI_RDEV:CONFIG_MIAMI.DAT CLIENT/ALLOW=(OMAHA,DENVER) DEVICE $1$MUA0: MUAO, TK50 DEVICE MSA0: TU80, 1600bpi OMAHA and DENVER (the specific RDF CLIENT nodes) are allowed access to all remote devices (MUA0, TU80) on the server node MIAMI. Requirements: If there is more than one RDF client node being allowed access, separate the node names by commas. 8.5.2 Allow Specific RDF Clients Access to a Specific Remote Device You can allow specific RDF client nodes access to a specific remote device. Example: If the server node is MIAMI and access to MUA0 is allowed by RDF client nodes OMAHA and DENVER, then do the following: 1. Edit TTI_RDEV:CONFIG_MIAMI.DAT 2. Find the device designation line (for example, DEVICE $1$MUA0:) 3. At the end of the device designation line, add the /ALLOW qualifier: $ Edit TTI_RDEV:CONFIG_MIAMI.DAT DEVICE $1$MUA0: MUA0, TK50/ALLOW=(OMAHA,DENVER) DEVICE MSA0: TU80, 1600bpi OMAHA and DENVER (the specific RDF client nodes ) are allowed access only to device MUA0. In this situation, OMAHA is not allowed to access device TU80. Remote Devices 8–9

Remote Devices<br />

8.5 Controlling Access <strong>to</strong> RDF Resources<br />

<strong>Backup</strong> pauses momentarily be<strong>for</strong>e resuming. Sensing the network disconnect, RDF creates a<br />

new -rdclient- link. Verify this by entering the following command:<br />

NCP> show known links<br />

Known Link Volatile Summary as of 13-MAR-1996 16:07:00<br />

Link Node PID Process Remote link Remote user<br />

24593 20.4 (JR) 2040111C MARI_11C_5 8244 CTERM<br />

24579 20.6 (CHEERS) 20400113 REMACP 8223 SAMMY<br />

24585 20.6 (CHEERS) 20400113 REMACP 8224 ANDERSON<br />

24600 20.3 (FAST) 20400C3A -rdclient- 24601 tti_rdevSRV<br />

NCP> exit<br />

8.5 Controlling Access <strong>to</strong> RDF Resources<br />

The RDF Security Access feature allows s<strong>to</strong>rage administra<strong>to</strong>rs <strong>to</strong> control which remote devices<br />

are allowed <strong>to</strong> be accessed by RDF client nodes.<br />

8.5.1 Allow Specific RDF Clients Access <strong>to</strong> All Remote Devices<br />

You can allow specific RDF client nodes access <strong>to</strong> all remote devices.<br />

Example:<br />

For example, if the server node is MIAMI and access <strong>to</strong> all remote devices is granted only <strong>to</strong><br />

RDF client nodes OMAHA and DENVER, then do the following:<br />

1. Edit TTI_RDEV:CONFIG_MIAMI.DAT<br />

2. Be<strong>for</strong>e the first device designation line, insert the /ALLOW qualifier<br />

Edit TTI_RDEV:CONFIG_MIAMI.DAT<br />

CLIENT/ALLOW=(OMAHA,DENVER)<br />

DEVICE $1$MUA0: MUAO, TK50<br />

DEVICE MSA0: TU80, 1600bpi<br />

OMAHA and DENVER (the specific RDF CLIENT nodes) are allowed access <strong>to</strong> all remote<br />

devices (MUA0, TU80) on the server node MIAMI.<br />

Requirements:<br />

If there is more than one RDF client node being allowed access, separate the node names by<br />

commas.<br />

8.5.2 Allow Specific RDF Clients Access <strong>to</strong> a Specific Remote Device<br />

You can allow specific RDF client nodes access <strong>to</strong> a specific remote device.<br />

Example:<br />

If the server node is MIAMI and access <strong>to</strong> MUA0 is allowed by RDF client nodes OMAHA and<br />

DENVER, then do the following:<br />

1. Edit TTI_RDEV:CONFIG_MIAMI.DAT<br />

2. Find the device designation line (<strong>for</strong> example, DEVICE $1$MUA0:)<br />

3. At the end of the device designation line, add the /ALLOW qualifier:<br />

$ Edit TTI_RDEV:CONFIG_MIAMI.DAT<br />

DEVICE $1$MUA0: MUA0, TK50/ALLOW=(OMAHA,DENVER)<br />

DEVICE MSA0: TU80, 1600bpi<br />

OMAHA and DENVER (the specific RDF client nodes ) are allowed access only <strong>to</strong> device<br />

MUA0. In this situation, OMAHA is not allowed <strong>to</strong> access device TU80.<br />

Remote Devices 8–9

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!