15.2 Configuring the DRD

15.2 Configuring the DRD

As the DRD subsystem is designed to auto-configure it generally does not require any setup. There are a couple of things that you can do, however, to modify the configuration, such as changing a device's access member name or server and resetting a device's DRD statistics.

15.2.1 Changing the Access Member Name

Typically, the access member name of a device should not have to be modified; however, since there are a couple of instances where it might be useful, the capability is available via the drdmgr command. One instance when you would need to change the access member name is where you want to load balance the I/O across DRD servers in a cluster where members don't all have physical access to a device as indicated in Figure 15-6.

Figure 15-6: DAIO Device on a Semi-Shared Bus in a Four-Member Cluster

In Figure 15-6, member2 and member3 have direct access to dsk8, but member1 and member4 do not, so they will have to access the dsk8 via member2 or member3. By default, the first member booted will be the server for the other members. In Figure 15-6, member2 was likely booted before member3 and therefore is the "access member" for member1, member4, and itself. However, we may want to distribute the load so that member2 is not handling all of the remote DRD requests. We can do this by modifying the access member for member1 or member4 using the drdmgr command. For example, we will change the access member on member4 from member2 to member3.

 # drdmgr –h n4 –a accessnode=n3 dsk8 

The result of this command is illustrated in Figure 15-7.

Figure 15-7: DAIO Device on a Semi-Shared Bus – After Access Node Change

Notice that the configuration is theoretically more balanced, but depending on the workload of member2 and member3, this may not necessarily have been the best move.

Another solution might be to balance the load of several disks on the semi-shared bus between the two members as illustrated in Figure 15-8.

Figure 15-8: Load Balancing Multiple Devices on a Semi-Shared Bus

In this figure, member2 serves odd numbered disks to member1 and member4, while member3 serves the even numbered disks to member1 and member4. Notice that member2 and member3 will directly access all of the disks since they have direct access.

Note

Even though we have illustrated a cluster that contains a semi-shared bus configuration, we still recommend having all buses shared by all members, if possible, as it is the highest availability solution and easiest to manage. The only situation where we are not opposed to a private bus solution is for swap, /tmp, and/or non-critical data where high-availability is not a priority.

15.2.2 Changing the Server

Changing the server for a device is something that you may want to do for a served device on a shared bus. If you'll recall from section 15.1.2.2, a served device cannot have more than one active server at a time, so if you want a particular member to have direct access to a served device and it is being served by another member, you'll need to change the server.

Say you want to use the tape drive to backup dsk0 (a disk that is on member1's private bus) as shown in Figure 15-9. The tape drive is a "Served Tape" device and is currently served by member2. You will want to run the backup routine on member1 (sheridan) since it is the only member that can directly access the disk.

Figure 15-9: Served Device on a Shared bus in a Two-Member Cluster

The first thing you need to do is check to see who is currently serving the tape device using the drdmgr command.

 # drdmgr -a server -a accessnode tape1    View of Data from member sheridan as of 2001-05-19:23:41:54                 Device Name:  tape1                 Device Type:  Served Tape               Device Status:  OK           Number of Servers:  2                 Server Name:  sheridan                Server State:  Not Server                 Server Name:  molari                Server State:  Server          Access Member Name:  molari 

As you can see by the output of the drdmgr command, sheridan is not currently serving tape1.

It would be more efficient if sheridan had direct access to the tape device so that the I/O to the tape does not have to go across the cluster communications interconnect. To change the server you can use the drdmgr command as follows:

 # drdmgr -a server=sheridan tape1 

The results are shown in Figure 15-10 and verified in the following output from the drdmgr command.

Figure 15-10: Served Device on a Shared Bus in a Two-Member Cluster after Server Relocation

 # drdmgr -a server -a accessnode tape1   View of Data from member sheridan as of 2001-05-19:23:49:25                Device Name: tape1                Device Type: Served Tape              Device Status: OK          Number of Servers: 2                Server Name: sheridan               Server State: Server                Server Name: molari               Server State: Not Server         Access Member Name: sheridan 

Note that you can change the server for more than one device at a time. For example, if tape1 is one of two tape devices in a tape jukebox, you can move tape1 as well as the changer (mc0) and the other tape drive (tape2) as follows:

 # drdmgr -a server=sheridan tape1 tape2 mc0 

You can then verify your results with the following drdmgr command (output not shown):

 # drdmgr -a server -a accessnode tape1 tape2 mc0 

15.2.3 Resetting the Statistics

On occasion it may be useful to reset the statistics on a device for a member to test its connectivity – in fact we'll do this in the following section. To reset the statistics for a device on the member that you are logged in to, issue the following command:

 [sheridan] # drdmgr -a statistics=0 dsk5 

To reset the statistics for the same device on another member, you do not have to login to that member. Simply use the "-h" switch. Device statistics are tallied on a per-member basis.

 [sheridan] # drdmgr –h molari –a statistics=0 dsk5